From rtg-dir-admin@www1.ietf.org Thu Nov 14 19:37:19 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10523 for ; Thu, 14 Nov 2002 19:37:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF0e0v05191; Thu, 14 Nov 2002 19:40:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF0dNv05143 for ; Thu, 14 Nov 2002 19:39:23 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10488 for ; Thu, 14 Nov 2002 19:36:40 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18CUVv-0009vk-00 for rtg-dir@ietf.org; Thu, 14 Nov 2002 16:39:15 -0800 Date: Thu, 14 Nov 2002 16:38:59 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <10684236185.20021114163859@psg.com> To: rtg-dir@ietf.org Subject: test. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit _______________________________________________ Rtg-dir mailing list Rtg-dir@www1.ietf.org https://www1.ietf.org/mailman/listinfo/rtg-dir From rtg-dir-admin@www1.ietf.org Thu Nov 14 19:54:21 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11173 for ; Thu, 14 Nov 2002 19:54:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF0v2v05949; Thu, 14 Nov 2002 19:57:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF0uZv05886 for ; Thu, 14 Nov 2002 19:56:35 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11050 for ; Thu, 14 Nov 2002 19:53:52 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18CUmZ-000AuK-00 for rtg-dir@ietf.org; Thu, 14 Nov 2002 16:56:27 -0800 Date: Thu, 14 Nov 2002 16:56:10 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14585267037.20021114165610@psg.com> To: rtg-dir@ietf.org Subject: rtg-dir list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks Welcome to the directorate and the list. The welcome message said the list address was rtg-dir@www1.ietf.org, I'm not sure if this one will work or not, but the rtg-dir@ietf.org is obviously functional. -- Alex From rtg-dir-admin@www1.ietf.org Thu Nov 14 20:00:19 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11459 for ; Thu, 14 Nov 2002 20:00:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF131v06245; Thu, 14 Nov 2002 20:03:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF0xIv06054 for ; Thu, 14 Nov 2002 19:59:18 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11298 for ; Thu, 14 Nov 2002 19:56:34 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18CUpB-000B4J-00 for rtg-dir@ietf.org; Thu, 14 Nov 2002 16:59:10 -0800 Date: Thu, 14 Nov 2002 16:58:53 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5085429711.20021114165853@psg.com> To: rtg-dir@ietf.org Subject: Re: rtg-dir list In-Reply-To: <14585267037.20021114165610@psg.com> References: <14585267037.20021114165610@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit BTW, He's the list of people on the list so far, we're thinking about hiring some more folks from SPs: acee@redback.com aretana@cisco.com chopps@allegronetworks.com dmm@sprint.net fenner@research.att.com jparker@axiowave.com mjh@icir.org mshand@cisco.com prz@net4u.ch Radia.Perlman@sun.com rohit@xebeo.com ruwhite@cisco.com shares@nexthop.com zinin@psg.com -- Alex Thursday, November 14, 2002, 4:56:10 PM, Alex Zinin wrote: > Folks > Welcome to the directorate and the list. > The welcome message said the list address was rtg-dir@www1.ietf.org, > I'm not sure if this one will work or not, but the rtg-dir@ietf.org > is obviously functional. From rtg-dir-admin@www1.ietf.org Thu Nov 14 20:15:18 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12105 for ; Thu, 14 Nov 2002 20:15:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF1I0v07469; Thu, 14 Nov 2002 20:18:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF1Hwv07443 for ; Thu, 14 Nov 2002 20:17:58 -0500 Received: from tahoe.sj.allegronetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12096 for ; Thu, 14 Nov 2002 20:15:14 -0500 (EST) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Nov 2002 17:17:32 -0800 Message-ID: From: Chris Hopps To: "'Alex Zinin'" Cc: "'rtg-dir@ietf.org'" Subject: RE: rtg-dir meeting in Atlana? Date: Thu, 14 Nov 2002 17:17:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Sunday evening (or morning) is fine with me. Chris. -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Thursday, November 14, 2002 5:00 PM To: rtg-dir@ietf.org Subject: rtg-dir meeting in Atlana? Folks- For those of you who'll be in Atlanta, I think it would be a good idea for us to meet. How about Sunday (17th) evening? -- Alex From rtg-dir-admin@www1.ietf.org Thu Nov 14 20:19:19 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12213 for ; Thu, 14 Nov 2002 20:19:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF1M1v07711; Thu, 14 Nov 2002 20:22:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF1Lbv07656 for ; Thu, 14 Nov 2002 20:21:37 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12199 for ; Thu, 14 Nov 2002 20:18:54 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18CVAn-000CHJ-00 for rtg-dir@ietf.org; Thu, 14 Nov 2002 17:21:29 -0800 Date: Thu, 14 Nov 2002 17:21:12 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <18386768726.20021114172112@psg.com> To: rtg-dir@ietf.org Subject: Volunteers for BGP spec reports MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- We're looking for volunteers to work on the reports required to move the new BGP spec to DS. If you would like to volunteer or know someone who would have required expertise and desire, let us know. It would be great to have 1 person from a vendor and 1 person from a SP to do this. Alvaro and Dave M, I'm thinking? ;) -- Alex From rtg-dir-admin@www1.ietf.org Thu Nov 14 20:34:19 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12735 for ; Thu, 14 Nov 2002 20:34:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF1b1v08294; Thu, 14 Nov 2002 20:37:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF1YTv08135 for ; Thu, 14 Nov 2002 20:34:29 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12617 for ; Thu, 14 Nov 2002 20:31:45 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18CVNA-000Czv-00; Thu, 14 Nov 2002 17:34:16 -0800 Date: Thu, 14 Nov 2002 17:33:58 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5987535048.20021114173358@psg.com> To: Radia Perlman - Boston Center for Networking CC: rtg-dir@ietf.org Subject: Re: rtg-dir meeting in Atlana? In-Reply-To: <200211150117.gAF1HGJ03559@sydney.East.Sun.COM> References: <200211150117.gAF1HGJ03559@sydney.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bill and I are in the IESG/IAB retreat Sunday morning and my afternoon is scheduled already. Let's see what other folks reply and choose another day if necessary. It would, however, be better for us to meet before the rtgarea meeting on Monday. We could shoot for a very late meeting on Sunday, starting 10pm, btw :) -- Alex Thursday, November 14, 2002, 5:17:39 PM, Radia Perlman - Boston Center for Networking wrote: > Unfortunately, I have a meeting from 6-10 on Sunday evening. Any change of doing > it Sunday, say 1-4? > Radia From rtg-dir-admin@www1.ietf.org Thu Nov 14 21:22:21 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13908 for ; Thu, 14 Nov 2002 21:22:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF2P1v10925; Thu, 14 Nov 2002 21:25:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF2OOv10894 for ; Thu, 14 Nov 2002 21:24:24 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13901 for ; Thu, 14 Nov 2002 21:21:42 -0500 (EST) Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 8CED4CAB76 for ; Thu, 14 Nov 2002 18:24:15 -0800 (PST) Message-ID: <3DD45BE0.3060807@redback.com> Date: Thu, 14 Nov 2002 21:28:48 -0500 From: Acee Lindem 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 Cc: rtg-dir@ietf.org Subject: Re: rtg-dir meeting in Atlana? References: <200211150117.gAF1HGJ03559@sydney.East.Sun.COM> <5987535048.20021114173358@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex Zinin wrote: > Bill and I are in the IESG/IAB retreat Sunday morning and my afternoon > is scheduled already. > > Let's see what other folks reply and choose another day if necessary. > It would, however, be better for us to meet before the rtgarea meeting > on Monday. We could shoot for a very late meeting on Sunday, starting > 10pm, btw :) > Sunday after dinner is good for me... Thanks, -- Acee From rtg-dir-admin@www1.ietf.org Thu Nov 14 21:24:21 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13963 for ; Thu, 14 Nov 2002 21:24:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF2R1v11018; Thu, 14 Nov 2002 21:27:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF2Q2v10984 for ; Thu, 14 Nov 2002 21:26:02 -0500 Received: from vulture.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13954 for ; Thu, 14 Nov 2002 21:23:18 -0500 (EST) Received: from vulture.icir.org (localhost [127.0.0.1]) by vulture.icir.org (8.12.3/8.12.3) with ESMTP id gAF2Poqa040209; Thu, 14 Nov 2002 18:25:50 -0800 (PST) (envelope-from mjh@vulture.icir.org) From: Mark Handley X-Organisation: ICIR To: radia.perlman@sun.com cc: "Alex Zinin" , rtg-dir@ietf.org Subject: Re: rtg-dir meeting in Atlana? In-reply-to: Your message of "Thu, 14 Nov 2002 20:17:39 EST." <200211150117.gAF1HGJ03559@sydney.East.Sun.COM> Date: Thu, 14 Nov 2002 18:25:49 -0800 Message-ID: <40208.1037327149@vulture.icir.org> Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , >Unfortunately, I have a meeting from 6-10 on Sunday evening. Any change of doi >ng >it Sunday, say 1-4? I'm only arriving around 8pm on Sunday, but I'll be there all week. - Mark From rtg-dir-admin@www1.ietf.org Thu Nov 14 22:16:19 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16085 for ; Thu, 14 Nov 2002 22:16:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF3J0v15204; Thu, 14 Nov 2002 22:19:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF3I0v15150 for ; Thu, 14 Nov 2002 22:18:00 -0500 Received: from net4u.net4u.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16042 for ; Thu, 14 Nov 2002 22:15:17 -0500 (EST) Received: from net4u.ch (gw.xebeo.com [204.192.44.242]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id gAF3HlA01080; Fri, 15 Nov 2002 04:17:47 +0100 Message-ID: <3DD46754.8020605@net4u.ch> Date: Fri, 15 Nov 2002 04:17:40 +0100 From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Acee Lindem CC: rtg-dir@ietf.org Subject: Re: rtg-dir meeting in Atlana? References: <200211150117.gAF1HGJ03559@sydney.East.Sun.COM> <5987535048.20021114173358@psg.com> <3DD45BE0.3060807@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Acee Lindem wrote: > > > Alex Zinin wrote: > >> Bill and I are in the IESG/IAB retreat Sunday morning and my afternoon >> is scheduled already. >> >> Let's see what other folks reply and choose another day if necessary. >> It would, however, be better for us to meet before the rtgarea meeting >> on Monday. We could shoot for a very late meeting on Sunday, starting >> 10pm, btw :) >> > > > Sunday after dinner is good for me... same - tony From rtg-dir-admin@www1.ietf.org Thu Nov 14 23:59:19 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18474 for ; Thu, 14 Nov 2002 23:59:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF521v19992; Fri, 15 Nov 2002 00:02:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF515v19940 for ; Fri, 15 Nov 2002 00:01:05 -0500 Received: from sith.maoz.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18453 for ; Thu, 14 Nov 2002 23:58:20 -0500 (EST) Received: (from dmm@localhost) by sith.maoz.com (8.12.6/8.12.6) id gAF51m4G009019; Thu, 14 Nov 2002 21:01:48 -0800 Date: Thu, 14 Nov 2002 21:01:48 -0800 From: David Meyer To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: rtg-dir meeting in Atlana? Message-ID: <20021114210148.K8912@sprint.net> References: <14085517998.20021114170021@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <14085517998.20021114170021@psg.com>; from zinin@psg.com on Thu, Nov 14, 2002 at 05:00:21PM -0800 Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Sure. Dave On Thu, Nov 14, 2002 at 05:00:21PM -0800, Alex Zinin wrote: >> Folks- >> >> For those of you who'll be in Atlanta, I think >> it would be a good idea for us to meet. >> >> How about Sunday (17th) evening? >> >> -- >> Alex >> From rtg-dir-admin@www1.ietf.org Fri Nov 15 00:06:19 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18666 for ; Fri, 15 Nov 2002 00:06:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF591v20821; Fri, 15 Nov 2002 00:09:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF55gv20104 for ; Fri, 15 Nov 2002 00:05:42 -0500 Received: from sith.maoz.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18590 for ; Fri, 15 Nov 2002 00:02:57 -0500 (EST) Received: (from dmm@localhost) by sith.maoz.com (8.12.6/8.12.6) id gAF56OCe009059; Thu, 14 Nov 2002 21:06:24 -0800 Date: Thu, 14 Nov 2002 21:06:24 -0800 From: David Meyer To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: Volunteers for BGP spec reports Message-ID: <20021114210624.N8912@sprint.net> References: <18386768726.20021114172112@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <18386768726.20021114172112@psg.com>; from zinin@psg.com on Thu, Nov 14, 2002 at 05:21:12PM -0800 Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Sign me up. Dave On Thu, Nov 14, 2002 at 05:21:12PM -0800, Alex Zinin wrote: >> Folks- >> >> We're looking for volunteers to work on the reports required to move >> the new BGP spec to DS. If you would like to volunteer or know >> someone who would have required expertise and desire, let us know. It >> would be great to have 1 person from a vendor and 1 person from a SP >> to do this. Alvaro and Dave M, I'm thinking? ;) >> >> -- >> Alex >> From rtg-dir-admin@www1.ietf.org Fri Nov 15 10:03:26 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09817 for ; Fri, 15 Nov 2002 10:03:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFF61v27605; Fri, 15 Nov 2002 10:06:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFF2qv27528 for ; Fri, 15 Nov 2002 10:02:52 -0500 Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09747 for ; Fri, 15 Nov 2002 10:00:13 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA02854; Fri, 15 Nov 2002 10:02:16 -0500 (EST) Date: Fri, 15 Nov 2002 10:02:16 -0500 (EST) From: Russ White Reply-To: Russ White To: Alex Zinin cc: rtg-dir@ietf.org Subject: Re: Volunteers for BGP spec reports In-Reply-To: <18386768726.20021114172112@psg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Alvaro's in Argentina, then IETF, so he probably won't answer this for a couple of days. I'll be glad to take it if he doesn't. :-) Russ On Thu, 14 Nov 2002, Alex Zinin wrote: > Folks- > > We're looking for volunteers to work on the reports required to move > the new BGP spec to DS. If you would like to volunteer or know > someone who would have required expertise and desire, let us know. It > would be great to have 1 person from a vendor and 1 person from a SP > to do this. Alvaro and Dave M, I'm thinking? ;) > > -- > Alex > > __________________________________ riw@cisco.com CCIE <>< Grace Alone From rtg-dir-admin@www1.ietf.org Fri Nov 15 11:42:24 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12042 for ; Fri, 15 Nov 2002 11:42:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFGj1v00797; Fri, 15 Nov 2002 11:45:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFGi6v00766 for ; Fri, 15 Nov 2002 11:44:06 -0500 Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12010 for ; Fri, 15 Nov 2002 11:41:27 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAFGi1f28273 for rtg-dir@ietf.org; Fri, 15 Nov 2002 11:44:01 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAFGhtC28259 for ; Fri, 15 Nov 2002 11:43:55 -0500 (EST) (envelope-from shares@nexthop.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: rtg-dir meeting in Atlana? Date: Fri, 15 Nov 2002 11:43:55 -0500 Message-ID: Thread-Topic: rtg-dir meeting in Atlana? Thread-Index: AcKMTjXCrFNnFDxpS1apns6amJf7twAd+8pQ From: "Susan Hares" To: "Acee Lindem" Cc: X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAFGi6v00767 Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Sunday evening would be difficult, but possible. sue -----Original Message----- From: Acee Lindem [mailto:acee@redback.com] Sent: Thursday, November 14, 2002 9:29 PM Cc: rtg-dir@ietf.org Subject: Re: rtg-dir meeting in Atlana? Alex Zinin wrote: > Bill and I are in the IESG/IAB retreat Sunday morning and my afternoon > is scheduled already. > > Let's see what other folks reply and choose another day if necessary. > It would, however, be better for us to meet before the rtgarea meeting > on Monday. We could shoot for a very late meeting on Sunday, starting > 10pm, btw :) > Sunday after dinner is good for me... Thanks, -- Acee From rtg-dir-admin@www1.ietf.org Fri Nov 15 13:34:21 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14940 for ; Fri, 15 Nov 2002 13:34:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFIb0v06596; Fri, 15 Nov 2002 13:37:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFIaUv06534 for ; Fri, 15 Nov 2002 13:36:30 -0500 Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14924 for ; Fri, 15 Nov 2002 13:33:49 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAFIaNh30287 for rtg-dir@ietf.org; Fri, 15 Nov 2002 13:36:23 -0500 (EST) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAFIaFC30266 for ; Fri, 15 Nov 2002 13:36:15 -0500 (EST) (envelope-from shares@nexthop.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: rtg-dir meeting in Atlana? Date: Fri, 15 Nov 2002 13:36:14 -0500 Message-ID: Thread-Topic: rtg-dir meeting in Atlana? Thread-Index: AcKMR4TH0Dx3Ir0bTPaR7wqW1xxYSwAjkw4Q From: "Susan Hares" To: "Alex Zinin" , "Radia Perlman - Boston Center for Networking" Cc: X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAFIaUv06548 Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Alex: I've check my arrangements. I will not be able to meet until 11:00pm or later on Sunday. sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Thursday, November 14, 2002 8:34 PM To: Radia Perlman - Boston Center for Networking Cc: rtg-dir@ietf.org Subject: Re: rtg-dir meeting in Atlana? Bill and I are in the IESG/IAB retreat Sunday morning and my afternoon is scheduled already. Let's see what other folks reply and choose another day if necessary. It would, however, be better for us to meet before the rtgarea meeting on Monday. We could shoot for a very late meeting on Sunday, starting 10pm, btw :) -- Alex Thursday, November 14, 2002, 5:17:39 PM, Radia Perlman - Boston Center for Networking wrote: > Unfortunately, I have a meeting from 6-10 on Sunday evening. Any change of doing > it Sunday, say 1-4? > Radia From rtg-dir-admin@www1.ietf.org Fri Nov 15 17:00:24 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21088 for ; Fri, 15 Nov 2002 17:00:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFM33v20553; Fri, 15 Nov 2002 17:03:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFM2Kv20520 for ; Fri, 15 Nov 2002 17:02:20 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21062 for ; Fri, 15 Nov 2002 16:59:39 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18CoXV-000EvV-00 for rtg-dir@ietf.org; Fri, 15 Nov 2002 14:02:13 -0800 Date: Fri, 15 Nov 2002 14:01:18 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <114161175498.20021115140118@psg.com> To: rtg-dir@ietf.org Subject: Fwd: WG Last Call: new BGP spec MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- This one is quite important. Reviews by the end of the WG last call would be _greatly_ appreciated. Thanks. -- Alex This is a forwarded message From: Yakov Rekhter To: idr@merit.edu Cc: Date: Tuesday, November 05, 2002, 5:21:11 PM Subject: WG Last Call ===8<==============Original message text=============== Folks, This is to start the WG Last Call on draft-ietf-idr-bgp4-18.txt. The Last Call ends Nov 29. Yakov. ------- Forwarded Message Date: Tue, 05 Nov 2002 06:08:56 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-bgp4-18.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 : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter et al. Filename : draft-ietf-idr-bgp4-18.txt Pages : 81 Date : 2002-11-4 The Border Gateway Protocol (BGP) is an inter-Autonomous System rout- ing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reacha- bility information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This informa- tion is sufficient to construct a graph of AS connectivity from which routing loops may be pruned and some policy decisions at the AS level may be enforced. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-18.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-18.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-18.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-4172103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-18.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4172103.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message ===8<===========End of original message text=========== From rtg-dir-admin@www1.ietf.org Sun Nov 17 02:56:16 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14378 for ; Sun, 17 Nov 2002 02:56:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAH7x1v32442; Sun, 17 Nov 2002 02:59:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAH7w5v32426 for ; Sun, 17 Nov 2002 02:58:05 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14356 for ; Sun, 17 Nov 2002 02:55:17 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18DKJV-000HyO-00 for rtg-dir@ietf.org; Sat, 16 Nov 2002 23:57:53 -0800 Date: Sat, 16 Nov 2002 23:57:39 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <7858469905.20021116235739@psg.com> To: rtg-dir@ietf.org Subject: Opinions on draft-rosen-mpls-in-ip-or-gre-00.txt ? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit draft-rosen-mpls-in-ip-or-gre-00.txt defines how to encapsulate MPLS packets (including the complete label stack) in IP or GRE packets. As far as I know the reason behind is to make MPLS-based VPNs work across non-MPLS regions. My thinking is if you need IP tunneling, why not just send an IP packet in the first place, and if one needs VPN encap in GRE, just define how the demux field is encoded, don't go to the potential IP/MPLS/IP/MPLS/etc mess... Opinions? -- Alex From rtg-dir-admin@www1.ietf.org Sun Nov 17 10:26:23 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19781 for ; Sun, 17 Nov 2002 10:26:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHFT1v22026; Sun, 17 Nov 2002 10:29:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHFSMv21999 for ; Sun, 17 Nov 2002 10:28:22 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19745 for ; Sun, 17 Nov 2002 10:25:41 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18DRLO-000OZy-00 for rtg-dir@ietf.org; Sun, 17 Nov 2002 07:28:19 -0800 Date: Sun, 17 Nov 2002 07:28:08 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1431167819.20021117072808@psg.com> To: rtg-dir@ietf.org Subject: Re: rtg-dir meeting in Atlana? In-Reply-To: <14085517998.20021114170021@psg.com> References: <14085517998.20021114170021@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ok, why don't we meet 10pm tonight in the Champions bar. Sue, Radia, and Mark would be able join us a little later. Alex From rtg-dir-admin@www1.ietf.org Mon Nov 18 11:44:23 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26227 for ; Mon, 18 Nov 2002 11:44:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIGl1v03663; Mon, 18 Nov 2002 11:47:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIGkgv03640 for ; Mon, 18 Nov 2002 11:46:42 -0500 Received: from net4u.net4u.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26214 for ; Mon, 18 Nov 2002 11:43:59 -0500 (EST) Received: from net4u.ch ([204.42.66.77]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id gAIGkUA26179; Mon, 18 Nov 2002 17:46:30 +0100 Message-ID: <3DD91965.6060906@net4u.ch> Date: Mon, 18 Nov 2002 17:46:29 +0100 From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: rtg-dir@ietf.org Subject: Re: Opinions on draft-rosen-mpls-in-ip-or-gre-00.txt ? References: <7858469905.20021116235739@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex Zinin wrote: >draft-rosen-mpls-in-ip-or-gre-00.txt defines how to encapsulate MPLS >packets (including the complete label stack) in IP or GRE packets. As >far as I know the reason behind is to make MPLS-based VPNs work across >non-MPLS regions. My thinking is if you need IP tunneling, why not >just send an IP packet in the first place, and if one needs VPN encap >in GRE, just define how the demux field is encoded, don't go to >the potential IP/MPLS/IP/MPLS/etc mess... Opinions? > I can think of possible scenarios where you want to preserve the label (e.g. extending a PE-CE link through a GRE tunnel through an IP-only device, if you loose the label, you may loose the capability to demux the frame). On the other hand one can argue that if a stripped label leads to de-muxing, you can de-mux an IP frame immediately into multiple tunnels (one per de-muxing decision). yes, the possible stackings will easily lead to a mess but it could be a life-saving kludge in some deployments just my 2c -- tony From rtg-dir-admin@www1.ietf.org Mon Nov 18 13:50:59 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29825 for ; Mon, 18 Nov 2002 13:50:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIIrcv10885; Mon, 18 Nov 2002 13:53:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIIgCv10447 for ; Mon, 18 Nov 2002 13:42:12 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29490 for ; Mon, 18 Nov 2002 13:39:30 -0500 (EST) Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 68F33F2C4B; Mon, 18 Nov 2002 10:42:00 -0800 (PST) Message-ID: <3DD951A8.BA42AF51@redback.com> Date: Mon, 18 Nov 2002 15:46:32 -0500 From: Acee Lindem Organization: Redback Networks X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: prz@net4u.ch Cc: Alex Zinin , rtg-dir@ietf.org Subject: Re: Opinions on draft-rosen-mpls-in-ip-or-gre-00.txt ? References: <7858469905.20021116235739@psg.com> <3DD91965.6060906@net4u.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tony Przygienda wrote: > > Alex Zinin wrote: > > >draft-rosen-mpls-in-ip-or-gre-00.txt defines how to encapsulate MPLS > >packets (including the complete label stack) in IP or GRE packets. As > >far as I know the reason behind is to make MPLS-based VPNs work across > >non-MPLS regions. My thinking is if you need IP tunneling, why not > >just send an IP packet in the first place, and if one needs VPN encap > >in GRE, just define how the demux field is encoded, don't go to > >the potential IP/MPLS/IP/MPLS/etc mess... Opinions? > > > > I can think of possible scenarios where you want to preserve the label > (e.g. extending > a PE-CE link through a GRE tunnel through an IP-only device, if you > loose the label, you may > loose the capability to > demux the frame). On the other hand one can argue that if a stripped > label leads to de-muxing, > you can de-mux an IP frame immediately into multiple tunnels (one per > de-muxing decision). > > yes, the possible stackings will easily lead to a mess but it could be a > life-saving kludge in some > deployments I spoke to my colleague, Rahul Aggarwal, on this topic and he was in agreement. It is very conveinent to use the RFC 2547 MPLS label mechanisms for BGP advertisement and VPN demux even if there is not in fact an LSP. Thanks, Acee From rtg-dir-admin@www1.ietf.org Mon Nov 18 16:27:19 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04012 for ; Mon, 18 Nov 2002 16:27:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAILU1v20365; Mon, 18 Nov 2002 16:30:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAILTkv20336 for ; Mon, 18 Nov 2002 16:29:46 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03999 for ; Mon, 18 Nov 2002 16:27:02 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18DtSd-0007vq-00; Mon, 18 Nov 2002 13:29:40 -0800 Date: Mon, 18 Nov 2002 16:29:06 -0500 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <3831107560.20021118162906@psg.com> To: rtg-dir@ietf.org CC: jhaas@nexthop.com Subject: new directorate member added: Jeff Haas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff Haas has just been added to the directorate. Welcome, Jeff. -- Alex From rtg-dir-admin@www1.ietf.org Mon Nov 18 20:07:18 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09456 for ; Mon, 18 Nov 2002 20:07:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAJ1A1v00723; Mon, 18 Nov 2002 20:10:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAJ19nv00694 for ; Mon, 18 Nov 2002 20:09:49 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09448 for ; Mon, 18 Nov 2002 20:07:04 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18DwtT-000K6f-00; Mon, 18 Nov 2002 17:09:36 -0800 Date: Mon, 18 Nov 2002 20:08:41 -0500 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <19544281904.20021118200841@psg.com> To: Acee Lindem CC: prz@net4u.ch, rtg-dir@ietf.org Subject: Re: Opinions on draft-rosen-mpls-in-ip-or-gre-00.txt ? In-Reply-To: <3DD951A8.BA42AF51@redback.com> References: <7858469905.20021116235739@psg.com> <3DD91965.6060906@net4u.ch> <3DD951A8.BA42AF51@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Acee, Tony, thanks! This one will be discussed at the MPLS WG meeting, let's see what people say. -- Alex Monday, November 18, 2002, 3:46:32 PM, Acee Lindem wrote: > Tony Przygienda wrote: >> >> Alex Zinin wrote: >> >> >draft-rosen-mpls-in-ip-or-gre-00.txt defines how to encapsulate MPLS >> >packets (including the complete label stack) in IP or GRE packets. As >> >far as I know the reason behind is to make MPLS-based VPNs work across >> >non-MPLS regions. My thinking is if you need IP tunneling, why not >> >just send an IP packet in the first place, and if one needs VPN encap >> >in GRE, just define how the demux field is encoded, don't go to >> >the potential IP/MPLS/IP/MPLS/etc mess... Opinions? >> > >> >> I can think of possible scenarios where you want to preserve the label >> (e.g. extending >> a PE-CE link through a GRE tunnel through an IP-only device, if you >> loose the label, you may >> loose the capability to >> demux the frame). On the other hand one can argue that if a stripped >> label leads to de-muxing, >> you can de-mux an IP frame immediately into multiple tunnels (one per >> de-muxing decision). >> >> yes, the possible stackings will easily lead to a mess but it could be a >> life-saving kludge in some >> deployments > I spoke to my colleague, Rahul Aggarwal, on this topic and he was in > agreement. It is very conveinent to use the RFC 2547 MPLS label mechanisms > for BGP advertisement and VPN demux even if there is not in fact an LSP. > Thanks, > Acee From rtg-dir-admin@www1.ietf.org Tue Nov 26 18:20:18 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25968 for ; Tue, 26 Nov 2002 18:20:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQNN7v02682; Tue, 26 Nov 2002 18:23:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQNIxv02473 for ; Tue, 26 Nov 2002 18:18:59 -0500 Received: from mail-green.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25915 for ; Tue, 26 Nov 2002 18:16:08 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id A3A5B1E028 for ; Tue, 26 Nov 2002 18:18:52 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA28393 for ; Tue, 26 Nov 2002 18:18:52 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id PAA02888; Tue, 26 Nov 2002 15:18:52 -0800 (PST) Message-Id: <200211262318.PAA02888@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-dir@ietf.org Subject: New rtg.ietf.org activated Date: Tue, 26 Nov 2002 15:18:51 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , After going home early from the IETF meeting, I had some time on my hands so installed a shared web content system ("phpnuke") on rtg.ietf.org , to facilitate some of the information sharing that we talked about last Sunday night. I'm still working on a site overview for people (like me) not familiar with this style of interactive system. There are three main types of content: - News. These are things like the working group summaries I've posted, perhaps announcements of working group last calls, etc. - "Content". These are static pages that can be edited by WG chairs or designated users. I put one up in IDMR about IGMPv3, thinking that maybe there would be a page of "Content" per document, but I'm not completely sure. - Forums. I have set up some forums but haven't played with them at all. What I'd like from you as the directorate is to play with this site a little and explore how you think it could be used for the kinds of interactions we'd like to facilitate. (Or, tell me to stop wasting my time on this since it's not going to work). Thanks, Bill From rtg-dir-admin@www1.ietf.org Tue Nov 26 18:42:12 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26916 for ; Tue, 26 Nov 2002 18:42:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQNj2v04422; Tue, 26 Nov 2002 18:45:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQNi2v04375 for ; Tue, 26 Nov 2002 18:44:02 -0500 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26878 for ; Tue, 26 Nov 2002 18:41:10 -0500 (EST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19928; Tue, 26 Nov 2002 15:43:53 -0800 (PST) Received: from sr1-ubur-05 (sr1-ubur-05 [129.148.9.84]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id gAQNhqJ26561; Tue, 26 Nov 2002 18:43:52 -0500 (EST) Message-Id: <200211262343.gAQNhqJ26561@sydney.East.Sun.COM> Date: Tue, 26 Nov 2002 18:43:52 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: New rtg.ietf.org activated To: rtg-dir@ietf.org, fenner@research.att.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /7/WFOh+0uozDKnXeg+vxg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , It is absolutely fantastic! A few nits...you misspelled "resurrected". It would be nice to have a one-page tutorial for each WG, or each protocol within a WG. Perhaps the WG charter fulfills that. Also, I found there were a dizzying selection of links, and it was hard to figure out where each would lead. Perhaps fewer choices per page, with more information for each. But these are just nits. Routing area rocks! Soon everyone in IETF will want to be in the routing area because our web site is so nice! Thanks again! Radia From: Bill Fenner After going home early from the IETF meeting, I had some time on my hands so installed a shared web content system ("phpnuke") on rtg.ietf.org , to facilitate some of the information sharing that we talked about last Sunday night. I'm still working on a site overview for people (like me) not familiar with this style of interactive system. There are three main types of content: - News. These are things like the working group summaries I've posted, perhaps announcements of working group last calls, etc. - "Content". These are static pages that can be edited by WG chairs or designated users. I put one up in IDMR about IGMPv3, thinking that maybe there would be a page of "Content" per document, but I'm not completely sure. - Forums. I have set up some forums but haven't played with them at all. What I'd like from you as the directorate is to play with this site a little and explore how you think it could be used for the kinds of interactions we'd like to facilitate. (Or, tell me to stop wasting my time on this since it's not going to work). Thanks, Bill From rtg-dir-admin@www1.ietf.org Tue Nov 26 18:53:15 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27363 for ; Tue, 26 Nov 2002 18:53:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQNu4v05036; Tue, 26 Nov 2002 18:56:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQNrqv04922 for ; Tue, 26 Nov 2002 18:53:52 -0500 Received: from sith.maoz.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27275 for ; Tue, 26 Nov 2002 18:51:00 -0500 (EST) Received: (from dmm@localhost) by sith.maoz.com (8.12.6/8.12.6) id gAQNsYQw029573; Tue, 26 Nov 2002 15:54:34 -0800 Date: Tue, 26 Nov 2002 15:54:34 -0800 From: David Meyer To: Bill Fenner Cc: rtg-dir@ietf.org Subject: Re: New rtg.ietf.org activated Message-ID: <20021126155434.A29564@sprint.net> References: <200211262318.PAA02888@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200211262318.PAA02888@windsor.research.att.com>; from fenner@research.att.com on Tue, Nov 26, 2002 at 03:18:51PM -0800 Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Nice Bill. Thanks for doing this. Dave On Tue, Nov 26, 2002 at 03:18:51PM -0800, Bill Fenner wrote: >> >> After going home early from the IETF meeting, I had some time on my >> hands so installed a shared web content system ("phpnuke") on rtg.ietf.org , >> to facilitate some of the information sharing that we talked about >> last Sunday night. >> >> I'm still working on a site overview for people (like me) not >> familiar with this style of interactive system. There are three >> main types of content: >> >> - News. These are things like the working group summaries I've posted, >> perhaps announcements of working group last calls, etc. >> - "Content". These are static pages that can be edited by WG chairs or >> designated users. I put one up in IDMR about IGMPv3, thinking that >> maybe there would be a page of "Content" per document, but I'm not >> completely sure. >> - Forums. I have set up some forums but haven't played with them at all. >> >> What I'd like from you as the directorate is to play with this site a little >> and explore how you think it could be used for the kinds of interactions >> we'd like to facilitate. (Or, tell me to stop wasting my time on this >> since it's not going to work). >> >> Thanks, >> Bill From rtg-dir-admin@www1.ietf.org Tue Nov 26 21:33:12 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02151 for ; Tue, 26 Nov 2002 21:33:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAR2a1v13941; Tue, 26 Nov 2002 21:36:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAR2Zrv13916 for ; Tue, 26 Nov 2002 21:35:53 -0500 Received: from mail-green.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02132 for ; Tue, 26 Nov 2002 21:33:01 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 71B5D1E053; Tue, 26 Nov 2002 21:35:45 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id VAA00104; Tue, 26 Nov 2002 21:35:44 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id SAA04505; Tue, 26 Nov 2002 18:35:44 -0800 (PST) Message-Id: <200211270235.SAA04505@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Radia.Perlman@Sun.COM Subject: Re: New rtg.ietf.org activated Cc: rtg-dir@ietf.org Date: Tue, 26 Nov 2002 18:35:43 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , >Also, I found there were a dizzying selection of links, and it was >hard to figure out where each would lead. Perhaps fewer choices per page, >with more information for each. Yup, this is absolutely the hardest problem - this interface defaults to be pretty complex, I've been trying to reduce the extra junk as much as possible. This is part of what I'm looking for help with -- trying to figure out what the right bits to keep are and which are just complexity. Bill From rtg-dir-admin@www1.ietf.org Wed Nov 27 01:32:09 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07433 for ; Wed, 27 Nov 2002 01:32:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAR6Z2v25027; Wed, 27 Nov 2002 01:35:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAR6Yiv24977 for ; Wed, 27 Nov 2002 01:34:44 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07390 for ; Wed, 27 Nov 2002 01:31:49 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18GvmL-000LA7-00 for rtg-dir@ietf.org; Tue, 26 Nov 2002 22:34:33 -0800 Date: Wed, 27 Nov 2002 01:33:58 -0500 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9888953408.20021127013358@psg.com> To: rtg-dir@ietf.org Subject: Re: : WG Last Call: new BGP spec In-Reply-To: <114161175498.20021115140118@psg.com> References: <114161175498.20021115140118@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Guys- The LC ends this coming Fri. I've only gotten comments from Mark (thanks!). Please try to find some time to review this document. It is _really_ important. If you could engage developers from your companies, this would also be very useful. Thanks. -- Alex Friday, November 15, 2002, 5:01:18 PM, Alex Zinin wrote: > Folks- > This one is quite important. Reviews by the end of > the WG last call would be _greatly_ appreciated. > Thanks. From rtg-dir-admin@www1.ietf.org Wed Nov 27 14:23:15 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25137 for ; Wed, 27 Nov 2002 14:23:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARJQ1v18764; Wed, 27 Nov 2002 14:26:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARJPpv18747 for ; Wed, 27 Nov 2002 14:25:51 -0500 Received: from sith.maoz.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25134 for ; Wed, 27 Nov 2002 14:23:03 -0500 (EST) Received: (from dmm@localhost) by sith.maoz.com (8.12.6/8.12.6) id gARJQZq2001049; Wed, 27 Nov 2002 11:26:35 -0800 Date: Wed, 27 Nov 2002 11:26:35 -0800 From: David Meyer To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: : WG Last Call: new BGP spec Message-ID: <20021127112635.A918@sprint.net> References: <114161175498.20021115140118@psg.com> <9888953408.20021127013358@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <9888953408.20021127013358@psg.com>; from zinin@psg.com on Wed, Nov 27, 2002 at 01:33:58AM -0500 Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Alex/All, A few comments (i). I agree with the concern voiced on the IDR list by Tom Petch (and possibly others), namely, that it appears that the FSM specification is inconsistent when describing the action that places a value in a MIB object when a NOTIFICATION is sent. (ii). It might be useful for section 3 to describe the relationship between the various (conceptual) RIBs (Adj-RIB-In, Adj-RIB-Out, and Loc-RIB) and what we are currently calling a FIB. This, however, is not critical to the protocol specification. (iii). Page 23, 3rd paragraph says "The sender of an UPDATE message should order ..." Is this "should" a "SHOULD" (in the RFC 2119 sense)? Likewise section 5.1.2 (AS_PATH), section a): "the advertising speaker shall not modifiy..." Actually, there seems to be a lot of use of the terms "shall" and "shall not" which are not capitalized, so it is unclear what the exact meaning is. "may" is also used in the same way. (iv). I know that we don't want to perturb the spec too much, but maybe the whole of the BTSH stuff could fix in an appendix (somewhat like Appendix E or F) of this document? I don't feel strongly about this, just wondering what people think. Dave From rtg-dir-admin@www1.ietf.org Fri Nov 29 15:17:11 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07242 for ; Fri, 29 Nov 2002 15:17:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gATKK1v18765; Fri, 29 Nov 2002 15:20:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gATKJ5v18729 for ; Fri, 29 Nov 2002 15:19:05 -0500 Received: from tahoe.sj.allegronetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07230 for ; Fri, 29 Nov 2002 15:16:13 -0500 (EST) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Nov 2002 12:19:00 -0800 Message-ID: From: Chris Hopps To: "'Bill Fenner'" Cc: "'rtg-dir@ietf.org'" Subject: RE: New rtg.ietf.org activated Date: Fri, 29 Nov 2002 12:18:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Very nice Bill, and thanks for all the work on this. As you noted in other mail, the system does seem to have an overly complex interface. I wonder if the news links couldn't be more summarized (e.g., more like on www.netbsd.org). Also if we could do that then perhaps below the news summary we could have the documents in last call. Right now the LC documents are stuffed over in the right margin and are hard to read. Having the IETF LC documents listed in some form is a nice aide. It would be nice to standardize how we display the documents, and then have each WG page have its own last call list displayed in the same way. Thanks, Chris. -----Original Message----- From: Bill Fenner [mailto:fenner@research.att.com] Sent: Tuesday, November 26, 2002 3:19 PM To: rtg-dir@ietf.org Subject: New rtg.ietf.org activated After going home early from the IETF meeting, I had some time on my hands so installed a shared web content system ("phpnuke") on rtg.ietf.org , to facilitate some of the information sharing that we talked about last Sunday night. I'm still working on a site overview for people (like me) not familiar with this style of interactive system. There are three main types of content: - News. These are things like the working group summaries I've posted, perhaps announcements of working group last calls, etc. - "Content". These are static pages that can be edited by WG chairs or designated users. I put one up in IDMR about IGMPv3, thinking that maybe there would be a page of "Content" per document, but I'm not completely sure. - Forums. I have set up some forums but haven't played with them at all. What I'd like from you as the directorate is to play with this site a little and explore how you think it could be used for the kinds of interactions we'd like to facilitate. (Or, tell me to stop wasting my time on this since it's not going to work). Thanks, Bill From rtg-dir-admin@www1.ietf.org Fri Nov 29 20:37:08 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13077 for ; Fri, 29 Nov 2002 20:37:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAU1e1v31523; Fri, 29 Nov 2002 20:40:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAU1dLv31484 for ; Fri, 29 Nov 2002 20:39:21 -0500 Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13068 for ; Fri, 29 Nov 2002 20:36:26 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gAU1d6939996; Fri, 29 Nov 2002 20:39:06 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gAU1d3C39989; Fri, 29 Nov 2002 20:39:03 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gAU1d3410198; Fri, 29 Nov 2002 20:39:03 -0500 (EST) Date: Fri, 29 Nov 2002 20:39:03 -0500 From: Jeffrey Haas To: David Meyer Cc: rtg-dir@ietf.org Subject: Re: : WG Last Call: new BGP spec Message-ID: <20021129203903.E10139@nexthop.com> References: <114161175498.20021115140118@psg.com> <9888953408.20021127013358@psg.com> <20021127112635.A918@sprint.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021127112635.A918@sprint.net>; from dmm@sprint.net on Wed, Nov 27, 2002 at 11:26:35AM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Dave, On Wed, Nov 27, 2002 at 11:26:35AM -0800, David Meyer wrote: > (iv). I know that we don't want to perturb the spec too > much, but maybe the whole of the BTSH stuff could > fix in an appendix (somewhat like Appendix E or > F) of this document? I don't feel strongly about > this, just wondering what people think. IMO, it wont hurt. However, we're trying to document what *is* implemented. For that reason, I don't think it will make it into the current effort. It would be nice though. :-) > Dave -- Jeff Haas NextHop Technologies From rtg-dir-admin@www1.ietf.org Sat Nov 30 02:07:10 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28433 for ; Sat, 30 Nov 2002 02:07:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAU7A4v20722; Sat, 30 Nov 2002 02:10:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAU79Xv20607 for ; Sat, 30 Nov 2002 02:09:33 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27698 for ; Sat, 30 Nov 2002 02:06:36 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18I1kf-000Cnt-00; Fri, 29 Nov 2002 23:09:21 -0800 Date: Fri, 29 Nov 2002 23:08:52 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <17135822910.20021129230852@psg.com> To: David Meyer CC: rtg-dir@ietf.org Subject: Re: : WG Last Call: new BGP spec In-Reply-To: <20021127112635.A918@sprint.net> References: <114161175498.20021115140118@psg.com> <9888953408.20021127013358@psg.com> <20021127112635.A918@sprint.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David, Thanks a lot. I will proxy your comments to the list excluding (iv), because, as Jeff said, we're documenting what is already implemented. -- Alex Wednesday, November 27, 2002, 11:26:35 AM, David Meyer wrote: > Alex/All, > A few comments > (i). I agree with the concern voiced on the IDR list > by Tom Petch (and possibly others), namely, that > it appears that the FSM specification is > inconsistent when describing the action that > places a value in a MIB object when a > NOTIFICATION is sent. > (ii). It might be useful for section 3 to describe the > relationship between the various (conceptual) > RIBs (Adj-RIB-In, Adj-RIB-Out, and Loc-RIB) and > what we are currently calling a FIB. This, > however, is not critical to the protocol > specification. > (iii). Page 23, 3rd paragraph says "The sender of an > UPDATE message should order ..." > Is this "should" a "SHOULD" (in the RFC 2119 > sense)? Likewise section 5.1.2 (AS_PATH), section > a): "the advertising speaker shall not > modifiy..." > Actually, there seems to be a lot of use of the > terms "shall" and "shall not" which are not > capitalized, so it is unclear what the exact > meaning is. "may" is also used in the same way. > (iv). I know that we don't want to perturb the spec too > much, but maybe the whole of the BTSH stuff could > fix in an appendix (somewhat like Appendix E or > F) of this document? I don't feel strongly about > this, just wondering what people think. > Dave From mailman-admin@ietf.org Sun Dec 1 08:57:27 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04573 for ; Sun, 1 Dec 2002 08:57:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB1E0Hv09102 for ; Sun, 1 Dec 2002 09:00:17 -0500 Date: Sun, 01 Dec 2002 09:00:17 -0500 Message-ID: <20021201140017.8899.30267.Mailman@www1.ietf.org> Subject: www1.ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rtg-dir-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your www1.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rtg-dir-request@www1.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rtg-dir-archive@ietf.org: List Password // URL ---- -------- rtg-dir@www1.ietf.org utnefe https://www1.ietf.org/mailman/options/rtg-dir/rtg-dir-archive%40ietf.org From rtg-dir-admin@www1.ietf.org Tue Dec 3 11:34:31 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01360 for ; Tue, 3 Dec 2002 11:34:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3GbLv24560; Tue, 3 Dec 2002 11:37:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3Ga7v23879 for ; Tue, 3 Dec 2002 11:36:07 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01238 for ; Tue, 3 Dec 2002 11:33:14 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18JG1h-0009ti-00 for rtg-dir@ietf.org; Tue, 03 Dec 2002 08:36:01 -0800 Date: Tue, 3 Dec 2002 08:35:31 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <13165581761.20021203083531@psg.com> To: rtg-dir@ietf.org Subject: Upcoming discussion on SUB-IP area MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- As you probably know, the IESG is currently discussing the future of the SUB-IP area. We had a SUB-IP area open meeting in Atlanta, where this question was brought up and the IESG will solicit further comments from the community on the ietf-discussion list through an e-mail message, describing the situation and the discussion. It is possible that some WGs currently in SUB-IP (MPLS, and CCAMP in particular) will end up in the RTG area, hence I'd like to encourage you guys to participate in the discussion. I am attaching the discussion part of the IESG note that will be sent this week FYI at the end of the message. Please do NOT distribute it. It is also still a draft. While the IESG will finally need to take all opinions into consideration, my personal position is that changing the SUB-IP status to permanent (or long-term) does not make sense, primarily because there will be a huge overlap btw SUB and RTG, and we'll essentially have two areas dealing with IP fwd'ing and routing, as well as another [two] routing AD(s) on the IESG. For this reason, I believe MPLS, and CCAMP should go to RTG. PPVPN is a big question, looking at what (and how) these guys are doing I'm having mixed feelings... -- Alex > The options seem to be: > 1/ move WGs (back) to permanent areas: migrate the SUB-IP working > groups to other IETF areas sometime soon, likely before next summer and > close the SUB-IP area. Also, reconstitute the SUB-IP (and/or other) > directorates to ensure the continued coordination between the remaining WGs. > > 2/ establish a long-term area: decide that the SUB-IP area will be > a long-term one, clearly define its charter, and ask the nomcom to select > one or two people to be Area Directors > > 3/ status quo: continue the SUB-IP Area as a temporary, ad-hoc > effort, much as it has been, with the IESG selecting two sitting ADs to > continue the effort that Bert & Scott have been doing. But maybe give more > responsibility to the working group's technical advisors, normally the AD > from the area where the working group might otherwise live. > > Data points for the discussion: > > DP1. It does look like a number of the SUB-IP working groups will be > finishing up their main work in the next year and be ready to be closed > until it is time to revise the RFCs based on experience or to advance them > on the standards track. The groups that should be finishing up include ipo, > gsmp and tewg. That would leave mpls, ppvpn and ccamp. > > DP2. WGs in SUB-IP or the work pursued in them came from existing > well-established areas, i.e., tewg came from OPS, gsmp, mpls (with ccamp > and ppvpn as its derivatives) came from RTG. > > DP3. There's still a need for technical oversight from permanent areas, so > some WGs have a technical advisor--normally the AD from the area where the > working group might otherwise live (e.g. CCAMP, and PPVPN with a RTG AD as > the TA). > > DP4. SUB-IP directorate was very useful when the area was just created. It > is currently passive and WGs continue operating just fine. > > DP5. The sense of the SUB-IP session in Atlanta was that the SUB-IP Area > was working and there is no compelling reason to break it up. There is a > need to clarify the charters of some of the working groups so that the > different groups understand what the division of tasks are but it is hard > to identify what problem would be solved by breaking up the area. > > DP6. Extensions to specific IETF technologies should be done in the working > groups responsible for those technologies based on requirements provided by > other working groups. For example, extensions to OSPF should be done by > the OSPF working group based on input from other working groups or > individuals rather than being done someplace else. > > Discussions about the options: > > 1/ Move WGs (back) to permanent areas and close the area > > For: > > Each WG within SUB-IP definitely has a strong feature that maps it to a > given permanent area [1]. The property that logically holds them together > in SUB-IP now is the need for coordination wrt the technologies that are > normally considered below the IP layer. While this was indeed necessary > right after SUB-IP creation, DP4 suggests that the goal has been achieved > and the focus is shifting back to coordination with permanent areas (e.g., > DP3, as well as the fact that RTG WGs are already dealing with SUB-IP > related extensions). DP1 suggests that there will be about three active WGs > within a year; at least two of them can be argued to belong in RTG area > (where they originally came from, see DP2), so it wouldn't make a lot of > sense to have two separate areas overlapping so considerably. PPVPN does > not map strongly to any area, however it doesn't map strongly to SUB-IP > either (MPLS is just one possible encapsulation method) > > Against: > > DP5 suggests that the feeling in the room was against closing the area, > though there was also some support for the idea that moving MPLS and CCAMP > to RTG would be a fine idea if the area were to be closed. The feeling > was that the area has been working and that there is no strong argument > that there is a need to change things at this time. > > > > 2/ Establish a long-term area > > For: > > DP5 suggests that the community believes this is a good idea. See also the > "Against" for option 1. In addition the opinion was expressed that having > a specific area with specifically assigned management, knowledgeable in the > field, would be an advantage. In addition, new SUP-IP work may develop in > the future and it would be good to have a home for it. > > Against: > > See "For" arguments for option 1 above. Also, there was an assumption when > the area was formed that it would be temporary and the size of the IESG is > near max effective size. It is also expected that if the nomcom > needs to find an AD(s) for SUB-IP, the set of required skills would > be extremely similar to those needed for the RTG area, which again brings > up the question of whether it makes sense to have two areas with so > similar expertise scopes. > > > 3/ Status quo > > For: > > DP5 suggests that the way the area operates is fine and does not need > fixing at this time. As DP1 predicts, there may not be many active > SUB-IP working groups within a year and it may be best to wait until > a few of the working groups finish their work and close before deciding on > the long term direction for this work. The IESG would decide which ADs > would be asked to manage the area in March. > > Against: > > A decision has to be made sooner or later, delaying the decision will not > make it any easier to make. > > > The IESG would like to hear from the community on this topic - please > direct your comments to the ietf@ietf.org list. > > -------------------------------------------------- > [1] possible WG to area mappings: > > - IPO has the IP-over-foo property, which is usually addressed in INT, > > - GSMP came from RTG > > - MPLS (aside from the fact that it came from RTG) deals with a > technology that is arguably another IP forwarding paradigm and relies > heavily on regular routing functionality and/or protocols. > > - CCAMP works on a generalized version of MPLS, which could map it to > RTG as well > > - TEWG came from O&M > > - PPVPN: suggestions have been made of INT, because its tunneling which > is closest to INT, RTG because some of the suggested discovery and VPN > routing mechanisms, and TSV, because its related to PWE3 (in TSV because of > congestion control worries) From rtg-dir-admin@www1.ietf.org Wed Dec 4 12:43:11 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24580 for ; Wed, 4 Dec 2002 12:43:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Hk1v06654; Wed, 4 Dec 2002 12:46:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4HjYv06625 for ; Wed, 4 Dec 2002 12:45:34 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24530 for ; Wed, 4 Dec 2002 12:42:40 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18JdaS-000Dx2-00 for rtg-dir@ietf.org; Wed, 04 Dec 2002 09:45:28 -0800 Date: Wed, 4 Dec 2002 09:44:57 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <16156148449.20021204094457@psg.com> To: rtg-dir@ietf.org Subject: Fwd: IETF Sub-IP area: request for input MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@www1.ietf.org Errors-To: rtg-dir-admin@www1.ietf.org X-BeenThere: rtg-dir@www1.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI -- Alex This is a forwarded message From: The IESG To: Cc: Date: Wednesday, December 04, 2002, 8:08:49 AM Subject: IETF Sub-IP area: request for input ===8<==============Original message text=============== IETF SUB-IP area The IESG announced in November of 2000 that a new SUB-IP temporary pseudo-area would be formed as a part of an effort to develop a "systematic approach to dealing with what we used to describe as "sub-IP" technologies." At the time the IESG said: "Over the years the boundary between 'wires' and IP protocols has become harder to define and the interaction has become more intertwined. For example, what appear as 'wires' or 'circuits' in a virtual network may in fact be routed datagrams in an underlying IP network. The topology of dynamic underlying networks such as ATM and soon switched optical networks can interact with IP-level traffic engineering and routing. Additionally, with IETF technologies such as MPLS we are defining a whole new class of 'wires'." (http://www.ietf.org/IESG/STATEMENTS/new-area.txt) After the December 2000 IETF meeting and taking into account the discussion at that meeting the IESG formed a "temporary" SUB-IP Area. IN the announcement of this action the IESG said: "It is temporary because the IESG believes that this concentrated sub-IP effort will likely be of short duration, on the order of a year or two. We feel that much of the work will be done by then, and the working groups closed. Any working groups that have not finished when the IESG determines that the area should be closed will be moved into existing the IETF areas where they seem to have the best fit." and "The IESG expects to review the development process and charters, however; if we conclude that this expectation is incorrect, we will need to make this area more formal. At that point, the nominating committee will be asked to supply dedicated area directors." (http://www.ietf.org/IESG/STATEMENTS/sub_area.txt) Although the SUB-IP working groups have made considerable progress (with 7 RFCs published, another 12 IDs approved for publication, 9 IDs under IESG consideration and an additional 11 IDs having been passed to the ADs for their evaluation) their work is not yet done (with 53 working group IDs currently in progress). It does appear that some of the working groups could finish the work in their charters over the next 6 months but it could be a lot longer for others. Because the end is in sight for some of the working groups and since the IESG had generally assumed that the area would be a temporary one and the second anniversary of the creation of the SUB-IP area is next spring, analysis was started in the IESG to figure out which areas would be the best ones for the SUB-IP working groups to move to so that they could continue their work. As part of that analysis a SUB-IP area session was held during the IETF meeting in Atlanta where this topic was discussed. There was a spirited discussion during the session on the best path forward. The opinions ranged from following the distribution of working groups, to doing so with some specific changes to keeping the working groups in a separate SUB-IP area. A sense of the room was taken at the end of the discussion and that sense was very strongly that the SUB-IP Area should become a "long-term" (the description that was used during the consensus call) one and that the nomcom be asked to nominate a person (or persons) to become director(s) of the SUB-IP area. To help provide more information as input for the IESG discussion we would like to continue the discussion started in Atlanta on the mailing list. It is our intention to keep the discussion on the future of the SUB-IP area open, but short-lived, because it would be a very good idea to let the nomcom know ASAP what the future holds as they need to know what expertise is needed in the ADs for the existing areas and if they need to search for additional people. The IESG aim is to be able to let the nomcom know what the future of the SUB-IP work is by the end of the day of Thursday Dec 12th. That date was chosen because it is the date of the next IESG teleconference yet it provides some time for a public discussion. The options seem to be: 1/ move WGs (back) to permanent areas: migrate the SUB-IP working groups to other IETF areas sometime soon, likely before next summer and close the SUB-IP area. Also, reconstitute the SUB-IP (and/or other) directorates to ensure the continued coordination between the remaining WGs. 2/ establish a long-term area: decide that the SUB-IP area will be a long-term one, clearly define its charter, and ask the nomcom to select one or two people to be Area Directors 3/ status quo: continue the SUB-IP Area as a temporary, ad-hoc effort, much as it has been, with the IESG selecting two sitting ADs to continue the effort that Bert & Scott have been doing. But maybe give more responsibility to the working group's technical advisors, normally the AD from the area where the working group might otherwise live. Data points for the discussion: DP1. It does look like a number of the SUB-IP working groups will be finishing up their main work in the next year and be ready to be closed until it is time to revise the RFCs based on experience or to advance them on the standards track. The groups that should be finishing up include ipo, gsmp and tewg. That would leave mpls, ppvpn and ccamp. DP2. WGs in SUB-IP or the work pursued in them came from existing well-established areas, i.e., tewg came from OPS, gsmp, mpls (with ccamp and ppvpn as its derivatives) came from RTG. DP3. There's still a need for technical oversight from permanent areas, so some WGs have a technical advisor--normally the AD from the area where the working group might otherwise live (e.g. CCAMP, and PPVPN with a RTG AD as the TA). DP4. SUB-IP directorate was very useful when the area was just created. It is currently passive and WGs continue operating just fine. DP5. The sense of the SUB-IP session in Atlanta was that the SUB-IP Area was working and there is no compelling reason to break it up. There is a need to clarify the charters of some of the working groups so that the different groups understand what the division of tasks are but it is hard to identify what problem would be solved by breaking up the area. DP6. Extensions to specific IETF technologies should be done in the working groups responsible for those technologies based on requirements provided by other working groups. For example, extensions to OSPF should be done by the OSPF working group based on input from other working groups or individuals rather than being done someplace else. Discussions about the options: 1/ Move WGs (back) to permanent areas and close the area For: Each WG within SUB-IP definitely has a strong feature that maps it to a given permanent area [1]. The property that logically holds them together in SUB-IP now is the need for coordination wrt the technologies that are normally considered below the IP layer. While this was indeed necessary right after SUB-IP creation, DP4 suggests that the goal has been achieved and the focus is shifting back to coordination with permanent areas (e.g., DP3, as well as the fact that RTG WGs are already dealing with SUB-IP related extensions). DP1 suggests that there will be about three active WGs within a year; at least two of them can be argued to belong in RTG area (where they originally came from, see DP2), so it wouldn't make a lot of sense to have two separate areas overlapping so considerably. PPVPN does not map strongly to any area, however it doesn't map strongly to SUB-IP either (MPLS is just one possible encapsulation method) Against: DP5 suggests that the feeling in the room was against closing the area, though there was also some support for the idea that moving MPLS and CCAMP to RTG would be a fine idea if the area were to be closed. The feeling was that the area has been working and that there is no strong argument that there is a need to change things at this time. 2/ Establish a long-term area For: DP5 suggests that the community believes this is a good idea. See also the "Against" for option 1. In addition the opinion was expressed that having a specific area with specifically assigned management, knowledgeable in the field, would be an advantage. In addition, new SUP-IP work may develop in the future and it would be good to have a home for it. Against: See "For" arguments for option 1 above. Also, there was an assumption when the area was formed that it would be temporary and the size of the IESG is near max effective size. It is also expected that if the nomcom needs to find an AD(s) for SUB-IP, the set of required skills would be extremely similar to those needed for the RTG area, which again brings up the question of whether it makes sense to have two areas with so similar expertise scopes. 3/ Status quo For: DP5 suggests that the way the area operates is fine and does not need fixing at this time. As DP1 predicts, there may not be many active SUB-IP working groups within a year and it may be best to wait until a few of the working groups finish their work and close before deciding on the long term direction for this work. The IESG would decide which ADs would be asked to manage the area in March. Against: A decision has to be made sooner or later, delaying the decision will not make it any easier to make. The IESG would like to hear from the community on this topic - please direct your comments to the ietf@ietf.org list. The IESG will discuss the matter in its next telechat on December 12. -------------------------------------------------- [1] possible WG to area mappings: - IPO has the IP-over-foo property, which is usually addressed in INT, - GSMP came from RTG - MPLS (aside from the fact that it came from RTG) deals with a technology that is arguably another IP forwarding paradigm and relies heavily on regular routing functionality and/or protocols. - CCAMP works on a generalized version of MPLS, which could map it to RTG as well - TEWG came from O&M - PPVPN: suggestions have been made of INT, because its tunneling which is closest to INT, RTG because some of the suggested discovery and VPN routing mechanisms, and TSV, because its related to PWE3 (in TSV because of congestion control worries) ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Thu Dec 5 14:06:09 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24126 for ; Thu, 5 Dec 2002 14:06:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5J92v15554; Thu, 5 Dec 2002 14:09:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5J8nv15512 for ; Thu, 5 Dec 2002 14:08:49 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24121 for ; Thu, 5 Dec 2002 14:05:55 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18K1Ma-000AmC-00 for rtg-dir@ietf.org; Thu, 05 Dec 2002 11:08:44 -0800 Date: Thu, 5 Dec 2002 11:08:11 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <183247541806.20021205110811@psg.com> To: rtg-dir@ietf.org Subject: Fwd: rtg-mibs group MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI. -- Alex This is a forwarded message From: Alex Zinin To: rtg-chairs@ietf.org Cc: Date: Thursday, December 05, 2002, 11:07:38 AM Subject: rtg-mibs group ===8<==============Original message text=============== Folks- Based on Sue's suggestion (thanks Sue!), we're pulling together a group of folks who would be willing to work on routing MIBs, preferably those who actually code them and are clueful enough. Please send me a list of people who are already working on MIBs in your WG or you believe would be useful for this (from the WG, or your company), and I'll subscribe them to the mailing list (rtg-mibs@ops.ietf.org). This would be a good opportunity to get new folks in and give them some visibility. Thanks. -- Alex ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Thu Dec 5 15:56:07 2002 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27977 for ; Thu, 5 Dec 2002 15:56:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Kx1v22142; Thu, 5 Dec 2002 15:59:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5KwHv22126 for ; Thu, 5 Dec 2002 15:58:17 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27973 for ; Thu, 5 Dec 2002 15:55:20 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18K34U-000Eye-00 for rtg-dir@ietf.org; Thu, 05 Dec 2002 12:58:11 -0800 Date: Thu, 5 Dec 2002 12:57:33 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <46254103922.20021205125733@psg.com> To: rtg-dir@ietf.org Subject: I-Ds for IESG telechat on 12/12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- Some I-Ds we'll be considering next Thursday below. Send comments to the list, if you have. Please keep in mind those should be really important issues at this stage. https://www1.ietf.org/internet-drafts/draft-ietf-tls-extensions-05.txt Bundle: https://www1.ietf.org/internet-drafts/draft-ietf-ipsp-config-policy-model-06.txt https://www1.ietf.org/internet-drafts/draft-ietf-ipsp-requirements-02.txt https://www1.ietf.org/internet-drafts/draft-ietf-ipsp-ipsecpib-05.txt https://www1.ietf.org/internet-drafts/draft-ietf-mpls-bundle-04.txt (show-stoppers only, please, I had my DISCUSS cleared) https://www1.ietf.org/internet-drafts/draft-andersson-mpls-sig-decision-03.txt -- Alex From mailman-admin@ietf.org Wed Jan 1 09:19:32 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05111 for ; Wed, 1 Jan 2003 09:19:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h01ERoJ12715 for ; Wed, 1 Jan 2003 09:27:50 -0500 Date: Wed, 01 Jan 2003 09:27:50 -0500 Message-ID: <20030101142750.32165.64780.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rtg-dir-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rtg-dir-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rtg-dir-archive@ietf.org: List Password // URL ---- -------- rtg-dir@ietf.org utnefe https://www1.ietf.org/mailman/options/rtg-dir/rtg-dir-archive%40ietf.org From rtg-dir-admin@ietf.org Thu Jan 2 20:00:00 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18575 for ; Thu, 2 Jan 2003 19:59:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03190J05615; Thu, 2 Jan 2003 20:09:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0318PJ05579 for ; Thu, 2 Jan 2003 20:08:25 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18567 for ; Thu, 2 Jan 2003 19:59:22 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18UGEM-000JlL-00 for rtg-dir@ietf.org; Thu, 02 Jan 2003 17:02:34 -0800 Date: Thu, 2 Jan 2003 17:00:19 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <159245235239.20030102170019@psg.com> To: rtg-dir@ietf.org Subject: IPv6 site-local related documents MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI, below are a couple of docs related to the IPv6 SL discussion. http://psg.com/~mrw/draft-wasserman-ipv6-sl-impact-01.txt http://playground.sun.com/ipng/doc/draft-hinden-ipv6-sl-moderate-00.txt -- Alex From rtg-dir-admin@ietf.org Fri Jan 3 11:50:43 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12777 for ; Fri, 3 Jan 2003 11:50:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03H02J05904; Fri, 3 Jan 2003 12:00:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03GxlJ05868 for ; Fri, 3 Jan 2003 11:59:47 -0500 Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12772 for ; Fri, 3 Jan 2003 11:50:26 -0500 (EST) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h03Grb783365 for rtg-dir@ietf.org; Fri, 3 Jan 2003 11:53:37 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id h03GrXC83358 for ; Fri, 3 Jan 2003 11:53:33 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h03GrXn02944 for rtg-dir@ietf.org; Fri, 3 Jan 2003 11:53:33 -0500 (EST) Date: Fri, 3 Jan 2003 11:53:33 -0500 From: Jeffrey Haas To: rtg-dir@ietf.org Subject: Re: IPv6 site-local related documents Message-ID: <20030103115333.A2729@nexthop.com> References: <159245235239.20030102170019@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <159245235239.20030102170019@psg.com>; from zinin@psg.com on Thu, Jan 02, 2003 at 05:00:19PM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Thu, Jan 02, 2003 at 05:00:19PM -0800, Alex Zinin wrote: > FYI, below are a couple of docs related > to the IPv6 SL discussion. > > http://psg.com/~mrw/draft-wasserman-ipv6-sl-impact-01.txt > http://playground.sun.com/ipng/doc/draft-hinden-ipv6-sl-moderate-00.txt psg.com seems to be down at the moment. Could someone point me to an archive and a rough time frame showing what the issue the WG seems to be concerned with? I haven't been following v6 WG's in the last few years. The sort of meta-question that I thought I was hearing from people is, "Should we actually *have* site local addresses? If so, what does that mean for *foo*." IMO, for the "should we" case - rfc1918 addresses and their pervasiveness should answer that question, academic purity aside. As for the implications the second document seems to have some nice operational consequences summaries that are good to keep in mind. > Alex -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Fri Jan 3 15:44:36 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18724 for ; Fri, 3 Jan 2003 15:44:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03Ks1J23834; Fri, 3 Jan 2003 15:54:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KrBJ23812 for ; Fri, 3 Jan 2003 15:53:11 -0500 Received: from auds953.usa.alcatel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18716; Fri, 3 Jan 2003 15:43:24 -0500 (EST) Received: from 138.120.250.35 (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id h03KkZaN024007; Fri, 3 Jan 2003 14:46:36 -0600 (CST) Date: Fri, 3 Jan 2003 12:46:01 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <168316377086.20030103124601@alcatel.com> To: iesg@ietf.org CC: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: my e-mail MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit While psg.com is down, please use alex.zinin@alcatel.com If you sent me an e-mail since last night, please resend it to my alcatel address. Cheers. -- Alex From rtg-dir-admin@ietf.org Wed Jan 22 00:52:40 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22521 for ; Wed, 22 Jan 2003 00:52:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M6B2J16115; Wed, 22 Jan 2003 01:11:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M6AuJ16092 for ; Wed, 22 Jan 2003 01:10:56 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22517 for ; Wed, 22 Jan 2003 00:52:32 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18bDrh-000OAT-00 for rtg-dir@ietf.org; Tue, 21 Jan 2003 21:55:58 -0800 Date: Tue, 21 Jan 2003 18:58:05 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <369479080.20030121185805@psg.com> To: rtg-dir@ietf.org Subject: review: draft-ietf-msdp-spec MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Guys, I'm starting the AD-review of the MSDP spec. Reviews are welcome. Please indicate if you're willing to take the token (i.e., you commit to doing the review within a week or so.) -- Alex From mailman-admin@ietf.org Sat Feb 1 09:34:06 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06517 for ; Sat, 1 Feb 2003 09:34:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h11EcaJ23111 for ; Sat, 1 Feb 2003 09:38:36 -0500 Date: Sat, 01 Feb 2003 09:38:36 -0500 Message-ID: <20030201143836.8821.98018.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rtg-dir-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rtg-dir-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rtg-dir-archive@ietf.org: List Password // URL ---- -------- rtg-dir@ietf.org utnefe https://www1.ietf.org/mailman/options/rtg-dir/rtg-dir-archive%40ietf.org From rtg-dir-admin@ietf.org Mon Feb 10 07:43:09 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07145 for ; Mon, 10 Feb 2003 07:43:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ACq0p12946; Mon, 10 Feb 2003 07:52:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ACpIp12927 for ; Mon, 10 Feb 2003 07:51:18 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07134 for ; Mon, 10 Feb 2003 07:42:23 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18iDJz-000NaI-00 for rtg-dir@ietf.org; Mon, 10 Feb 2003 04:46:03 -0800 Date: Mon, 10 Feb 2003 07:44:53 -0500 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <83221885163.20030210074453@psg.com> To: rtg-dir@ietf.org Subject: Fwd: AD-review comments on MSDP In-Reply-To: <3178446159.20030207094313@psg.com> References: <3178446159.20030207094313@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I didn't receive comments from anyone on the directorate :( FYI my comments below. -- Alex This is a forwarded message From: Alex Zinin To: David Meyer , Bill Fenner Cc: zinin@psg.com Date: Friday, February 7, 2003, 9:43:13 AM Subject: AD-review comments on MSDP ===8<==============Original message text=============== Dave, Bill- Below are my comments on the MSDP spec. Since you haven't replied to my earlier e-mails about mesh-groups and FSM, I'm including those questions here. > Multicast Source Discovery Protocol (MSDP) > > > > > 1. Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > > Internet Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that other > groups may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > > 2. Abstract Ed: Remove numbering from Status and Abstract > The Multicast Source Discovery Protocol, MSDP, describes a mechanism > to connect multiple PIM-SM domains together. Each PIM-SM domain uses > its own independent RP(s) and does not have to depend on RPs in other > domains. This draft is intended to document existing MSDP > implementations in the field. Ed: Expand "RP" in the abstract ... > 6. Procedure > > When an RP in a PIM-SM domain first learns of a new sender, e.g. via > PIM register messages, it constructs a "Source-Active" (SA) message > and sends it to its MSDP peers. The SA message contains the following > fields: Spell out that RPs always need to be MSDP speakers? ... > 13.3. MSDP mesh-group semantics > > An MSDP mesh-group is a operational mechanism for reducing SA > flooding, typically in an intra-domain setting. In particular, when > some subset of a domain's MSDP speakers are fully meshed, they can be > configured into a mesh-group. > > Note that mesh-groups assume that a member doesn't have to forward an > SA to other members of the mesh-group because the originator will > forward to all members. To be able for the originator to forward to > all members (and to have each member also be a potential originator), > the mesh-group must be a full mesh of MSDP peering among all members. > > The semantics of the mesh-group are as follows: > > (i). If a member R of a mesh-group M receives a SA message from an > MSDP peer that is also a member of mesh-group M, R accepts the > SA message and forwards it to all of its peers that are not > part of any mesh-group. did you mean "any" or mesh-group M? following the text, if R receives an SA from X within mesh group M1, it won't forward it along to Y which may be in M2. If X doesn't have a session in M2, the message won't get flooded. > R MUST NOT forward the SA message to > other members of mesh-group M. > > (ii). If a member R of a mesh-group M receives a SA message from an > MSDP peer that is not a member of mesh-group M, and the SA > message passes the peer-RPF check, then R forwards the SA > message to all members of mesh-group M. Why only within M? what about other peers? > > 14. MSDP Connection State Machine > > MSDP uses TCP as its transport protocol. In a peering relationship, > one MSDP peer listens for new TCP connections on the well-known port > 639. The other side makes an active connect to this port. The peer > with the higher IP address will listen. This connection establishment > algorithm avoids call collision. Therefore, there is no need for a > call collision procedure. It should be noted, however, that the > disadvantage of this approach is that the startup time depends > completely upon the active side and its connect retry timer; the > passive side cannot cause the connection to be established. > > An MSDP peer starts in the DISABLED state. MSDP peers establish > peering sessions according to the following state machine: > > > > > > > --------------->+----------+ > / | DISABLED |<---------- > | ------>+----------+ \ > | / |E1->A1 | > | | | | > | | V |E7->A7 > | | +----------+ E3->A3 +--------+ > | | | INACTIVE |------->| LISTEN | X> | | +----------+ +--------+ > | | E2->A2| ^ |E5->A5 > | | | | | > | |E7->A6 V |E6 | > | \ +------------+ | > | ------| CONNECTING | | > | +------------+ | > E7->A8 | |E4->A4 | > E8->A8 | | | > E9->A8 | V | > \ +-------------+ / > --------------| ESTABLISHED |<--------- > +-------------+ > | ^ > | | > E10->A9\______/ > 14.1. Events > > > E1) Enable MSDP peering with P > E2) Own IP address < P's IP address > E3) Own IP address > P's IP address > E4) TCP established (active side) > E5) TCP established (passive side) > E6) ConnectRetry timer expired > E7) Disable MSDP peering with P > (e.g. when one's own address is changed) > E8) Hold Timer expired > E9) MSDP TLV format error detected > E10) Any other error detected It seems that the FSM is not normalized, specifically the INACTIVE state seems redundant--it is not a "stable" state and the FSM transitions either to CONNECTING or LISTEN directly depending on the IP address comparison. Am I missing something? ... > 15. Packet Formats > > MSDP messages will be encoded in TLV format. If an implementation > receives a TLV that has length that is longer than expected, the TLV > SHOULD be accepted. Any additional data SHOULD be ignored and the > MSDP session should not be reset. > > > 15.1. MSDP TLV format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Value .... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type (8 bits) > Describes the format of the Value field. > > Length (16 bits) > Length of Type, Length, and Value fields in octets. > Minimum length required is 4 octets, except for > Keepalive messages. The maximum TLV length is 9192. > > Value (variable length) > Format is based on the Type value. See below. The length of > the value field is Length field minus 3. All reserved fields > in the Value field MUST be transmitted as zeros and ignored on > receipt. > > > 15.2. Defined TLVs > > The following TLV Types are defined: Do we want IANA to maintain a registry for this? > > Code Type > =========================================================== > 1 IPv4 Source-Active > 2 IPv4 Source-Active Request > 3 IPv4 Source-Active Response > 4 KeepAlive > 5 Reserved (Previously: Notification) > > Each TLV is described below. > > In addition, the following TLV Types are assigned but not described > in this memo: > > Code Type > =========================================================== > 6 MSDP traceroute in progress > 7 MSDP traceroute reply Where are they described though? > > 15.2.1. IPv4 Source-Active TLV > > The maximum size SA message that can be sent is 9192 octets. The 9192 > octet size does not include the TCP, IP, layer-2 headers. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 1 | x + y | Entry Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RP Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | Sprefix Len | \ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ > | Group Address | ) z > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / > | Source Address | / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type > IPv4 Source-Active TLV is type 1. > > Length x > Is the length of the control information in the message. x is > 8 octets (for the first two 32-bit quantities) plus 12 times > Entry Count octets. > > Length y > If 0, then there is no data encapsulated. Otherwise an IPv4 > packet follows and y is the length of the total length field the _value_ of the total length field? > of the IPv4 header encapsulated. in the header of the encapsulated IP packet? > If there are multiple SA TLVs > in a message, and data is also included, y must be 0 in all SA > TLVs except the last one and the last SA TLV must reflect the > source and destination addresses in the IP header of the > encapsulated data. What does "a message" and "the last TLV in the message" really mean given that MSDP uses stream transport? Is TCP segment meant? Note that the receiver has no visibility to TCP segmentation details... > Entry Count > Is the count of z entries (note above) which follow the RP > address field. This is so multiple (S,G)s from the same domain > can be encoded efficiently for the same RP address. An > SA message containing encapsulated data typically has an SA message??? or TLV? > entry count of 1 (i.e. only contains a single entry, for > the (S,G) representing the encapsulated packet). > > RP Address > The address of the RP in the domain the source has become > active in. > > Reserved > The Reserved field MUST be transmitted as zeros and MUST be > ignored by a receiver. > > Sprefix Len > The route prefix length associated with source address. > This field MUST be transmitted as 32 (/32). > > Group Address > The group address the active source has sent data to. > > Source Address > The IP address of the active source. > > Multiple SA TLVs MAY appear in the same message and can be batched Message again? Meaning TCP segment? > for efficiency at the expense of data latency. This would typically > occur on intermediate forwarding of SA messages. > > > 15.2.2. KeepAlive TLV > > > A KeepAlive TLV is sent to an MSDP peer if and only if there were no > MSDP messages sent to the peer within [KeepAlive-Period] seconds. > This message is necessary to keep the MSDP connection alive. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 4 | 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The length of the message is 3 octets which encompasses the one octet > Type field and the two octet Length field. > > > 16. MSDP Error Handling > > If an MSDP SA is received with a TLV format error, the session SHOULD > be reset with that peer. All other errors, received from MSDP peers, > SHOULD silently discard the packets and the session SHOULD not be > reset. "errors should discard..." sounds weird. also, why is TLV format error causes session reset for SA TLV only? When TLV error is detected, it is practically impossible to resync the session without a sequence of flags, and it is not safe to trust the data if it possible that the stream is out of sync, i.e., any TLV format error should reset the session... > 17. SA Data Encapsulation > > As discussed earlier, TCP encapsulation of data in SA messages MAY be > supported for backwards compatibility with legacy MSDP peers. > > > 18. Security Considerations > > An MSDP implementation MAY use IPsec [RFC2401] or MD5 to secure control > messages. In particular, the TCP connection between MSDP peers MAY > be secured using IPsec or MD5. Implementations MUST be capable of > working with peers which do not provide IPsec or MD5 security. Ref to the TCP-MD5 RFC? It seems that a threat analysis maybe required for the Security Considerations section to be useful. On the other hand, this is going Exp, so maybe this is enough... Thanks. Alex ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Mon Feb 10 07:47:08 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07224 for ; Mon, 10 Feb 2003 07:47:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ACu1p13022; Mon, 10 Feb 2003 07:56:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ACtBp12987 for ; Mon, 10 Feb 2003 07:55:11 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07208 for ; Mon, 10 Feb 2003 07:46:16 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18iDNl-000NfJ-00 for rtg-dir@ietf.org; Mon, 10 Feb 2003 04:49:57 -0800 Date: Mon, 10 Feb 2003 07:49:51 -0500 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <129222183502.20030210074951@psg.com> To: rtg-dir@ietf.org Subject: review: draft-ietf-forces-framework-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Starting AD-review for draft-ietf-forces-framework. Please review and send comments to the list. If you want to take the token and review before Fri, pls indicate so on the list today... beware though--I _will_ be bugging you. -- Alex From rtg-dir-admin@ietf.org Fri Feb 21 13:29:21 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10053 for ; Fri, 21 Feb 2003 13:29:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIb1p10864; Fri, 21 Feb 2003 13:37:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIZ9p10773 for ; Fri, 21 Feb 2003 13:35:09 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09983 for ; Fri, 21 Feb 2003 13:27:26 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18mHx6-000CC6-00 for rtg-dir@ietf.org; Fri, 21 Feb 2003 10:31:17 -0800 Date: Fri, 21 Feb 2003 10:31:04 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <10143606975.20030221103104@psg.com> To: rtg-dir@ietf.org Subject: Re: review: draft-ietf-forces-framework-04.txt In-Reply-To: <129222183502.20030210074951@psg.com> References: <129222183502.20030210074951@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit chopps reviewed the doc for me. Thanks, Chris! -- Alex Monday, February 10, 2003, 4:49:51 AM, Alex Zinin wrote: > Starting AD-review for draft-ietf-forces-framework. Please review and > send comments to the list. > If you want to take the token and review before Fri, pls indicate so > on the list today... beware though--I _will_ be bugging you. From rtg-dir-admin@ietf.org Tue Feb 25 01:42:39 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08313 for ; Tue, 25 Feb 2003 01:42:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P6q1p23908; Tue, 25 Feb 2003 01:52:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P6pCp23877 for ; Tue, 25 Feb 2003 01:51:12 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08251 for ; Tue, 25 Feb 2003 01:41:49 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18nYqU-000PS0-00 for rtg-dir@ietf.org; Mon, 24 Feb 2003 22:45:42 -0800 Date: Mon, 24 Feb 2003 22:45:30 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6790938232.20030224224530@psg.com> To: rtg-dir@ietf.org Subject: Quality of document review in RTG WGs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Guys, I'm not sure if I'm the only one who noticed this problem, or even if the problem is real or not, but it seems that the review process at least in our area is not working really great. Before a WG LC is announced, people generally don't have time to review stuff or assume that "folks will take care of this", and when the WG LC is started, many think, that it's really not worth it, as the document is pretty much ready and unlikely to change, etc... Seems that we need to figure out some mechanism to encourage more diligent review throughout the process. Does anyone have any ideas on this topic? Some from me: o pull together a group of reviewers (volunteers) in each WG and make sure that WG chairs kick them periodically to review stuff in progress o use something like "Call for Review" instead of the "Last Call" while the doc is in progress o Have WG chairs bring docs to this directorate periodically AND when the LC is started. Thoughts? -- Alex From rtg-dir-admin@ietf.org Tue Feb 25 05:05:35 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22263 for ; Tue, 25 Feb 2003 05:05:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PAF2p14944; Tue, 25 Feb 2003 05:15:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PAEJp14873 for ; Tue, 25 Feb 2003 05:14:19 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22246 for ; Tue, 25 Feb 2003 05:04:50 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1PA8h6N009151; Tue, 25 Feb 2003 02:08:43 -0800 (PST) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4155.cisco.com [10.61.80.58]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA17048; Tue, 25 Feb 2003 10:08:42 GMT Message-Id: <4.3.2.7.2.20030225100327.04c03200@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Feb 2003 10:08:30 +0000 To: Alex Zinin From: mike shand Subject: Re: Quality of document review in RTG WGs Cc: rtg-dir@ietf.org In-Reply-To: <6790938232.20030224224530@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Alex, One COULD argue that if the drafts were sufficiently interesting, folks would review them without prompting. By "interesting" I mean something which it is in my interest to make sure it is right. I think there is no shortage of reviewers for controversial drafts. That said (and I don't think there is anything we can do about that perception), there is always more incentive to review something if someone asks you to, so I think the idea of a review group MIGHT work. The downside, of course, is that it might encourage even more ambivalence from everyone else. Maybe even something as simple as a kick from the WG chairs to everyone, saying "please review" would help. Mike At 22:45 24/02/2003 -0800, Alex Zinin wrote: >Guys, > > I'm not sure if I'm the only one who noticed this problem, > or even if the problem is real or not, but it seems that > the review process at least in our area is not working > really great. Before a WG LC is announced, people generally > don't have time to review stuff or assume that "folks will > take care of this", and when the WG LC is started, many think, > that it's really not worth it, as the document is pretty much > ready and unlikely to change, etc... > > Seems that we need to figure out some mechanism to encourage > more diligent review throughout the process. Does anyone > have any ideas on this topic? Some from me: > > o pull together a group of reviewers (volunteers) in each WG > and make sure that WG chairs kick them periodically to > review stuff in progress > > o use something like "Call for Review" instead of the "Last > Call" while the doc is in progress > > o Have WG chairs bring docs to this directorate periodically > AND when the LC is started. > > Thoughts? > >-- >Alex From rtg-dir-admin@ietf.org Tue Feb 25 09:04:31 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01459 for ; Tue, 25 Feb 2003 09:04:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PEE2p32000; Tue, 25 Feb 2003 09:14:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PEDLp31965 for ; Tue, 25 Feb 2003 09:13:21 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01455 for ; Tue, 25 Feb 2003 09:03:48 -0500 (EST) Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 0182F31F2A6 for ; Tue, 25 Feb 2003 06:06:21 -0800 (PST) Message-ID: <3E5B78E4.7000003@redback.com> Date: Tue, 25 Feb 2003 09:08:36 -0500 From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rtg-dir@ietf.org Subject: Re: Quality of document review in RTG WGs References: <4.3.2.7.2.20030225100327.04c03200@jaws.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit mike shand wrote: > Alex, > One COULD argue that if the drafts were sufficiently interesting, folks > would review them without prompting. By "interesting" I mean something > which it is in my interest to make sure it is right. I think there is no > shortage of reviewers for controversial drafts. Mike, Alex, I also notice that new drafts are reviewed much more readily than drafts progressing through the process. By WG last call the review seems to be confined to WG chairs and ADs. I'm not sure what to do about this. Thanks, Acee > > That said (and I don't think there is anything we can do about that > perception), there is always more incentive to review something if > someone asks you to, so I think the idea of a review group MIGHT work. > The downside, of course, is that it might encourage even more > ambivalence from everyone else. > > Maybe even something as simple as a kick from the WG chairs to everyone, > saying "please review" would help. > > Mike > > > At 22:45 24/02/2003 -0800, Alex Zinin wrote: > >> Guys, >> >> I'm not sure if I'm the only one who noticed this problem, >> or even if the problem is real or not, but it seems that >> the review process at least in our area is not working >> really great. Before a WG LC is announced, people generally >> don't have time to review stuff or assume that "folks will >> take care of this", and when the WG LC is started, many think, >> that it's really not worth it, as the document is pretty much >> ready and unlikely to change, etc... >> >> Seems that we need to figure out some mechanism to encourage >> more diligent review throughout the process. Does anyone >> have any ideas on this topic? Some from me: >> >> o pull together a group of reviewers (volunteers) in each WG >> and make sure that WG chairs kick them periodically to >> review stuff in progress >> >> o use something like "Call for Review" instead of the "Last >> Call" while the doc is in progress >> >> o Have WG chairs bring docs to this directorate periodically >> AND when the LC is started. >> >> Thoughts? >> >> -- >> Alex > > > -- Acee From rtg-dir-admin@ietf.org Tue Feb 25 12:10:49 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06723 for ; Tue, 25 Feb 2003 12:10:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PHKOp13540; Tue, 25 Feb 2003 12:20:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PHEjp13267 for ; Tue, 25 Feb 2003 12:14:45 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06555 for ; Tue, 25 Feb 2003 12:05:07 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1PH91v67867 for rtg-dir@ietf.org; Tue, 25 Feb 2003 12:09:01 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1PH8t567853 for ; Tue, 25 Feb 2003 12:08:55 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1PH8tc27236 for rtg-dir@ietf.org; Tue, 25 Feb 2003 12:08:55 -0500 (EST) Date: Tue, 25 Feb 2003 12:08:55 -0500 From: Jeffrey Haas To: rtg-dir@ietf.org Subject: Re: Quality of document review in RTG WGs Message-ID: <20030225120855.A26944@nexthop.com> References: <6790938232.20030224224530@psg.com> <4.3.2.7.2.20030225100327.04c03200@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20030225100327.04c03200@jaws.cisco.com>; from mshand@cisco.com on Tue, Feb 25, 2003 at 10:08:30AM +0000 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , I'd have to agree to some extent with Mike. I'd also offer a slight extension on another viewpoint expressed: From the relatively little time I've spent in IETF, people seem willing to look at stuff as it initially comes out. Once the document has reached a certain point where most of the gross details are worked out, the finer details are usually left behind for the small number of people interested in them. This seems to roughly correlate to, "We have rough consensus. We've made *our* implementations work and interoperate. Just declare victory and put our efforts into the Next Great Thing." Its only the people who didn't go through the pain of the process of doing an initial implementation that has to suffer if the spec is sloppy. You have to deduce the details. The BGP-4 spec is a perfect example of this viewpoint. One could more cynically argue that parties who have completed their work have a vested interest in not documenting the "secret mix" that makes things work and interoperate - it serves as a barrier to entry in the market. Part of my motiviation in becoming active in IETF was coming from operating a small network and dealing with things that *didn't* work and some of the problems being due to sloppy specs and poor implmenetations of them. Vijay Gill often makes many of the same points I'd like to make, but he does it far better and with a much sharper tongue. I will also admit that the finishing steps of getting something through the process is not the interesting work. I've been through so many versions of the BGP FSM that I want to be finished with things. Only my overly anal personality keeps me from declaring it "done" until it really is. I'll ask a different question: Compared to the routing area, how active are the other areas? Just keeping up with BGP specs is hard. As part of taking part in the directorate, I've tried to broaden myself a bit more than I used to, but its still a lot of stuff. On Tue, Feb 25, 2003 at 10:08:30AM +0000, mike shand wrote: > Alex, > One COULD argue that if the drafts were sufficiently interesting, folks > would review them without prompting. By "interesting" I mean something > which it is in my interest to make sure it is right. I think there is no > shortage of reviewers for controversial drafts. > > That said (and I don't think there is anything we can do about that > perception), there is always more incentive to review something if someone > asks you to, so I think the idea of a review group MIGHT work. The > downside, of course, is that it might encourage even more ambivalence from > everyone else. > > Maybe even something as simple as a kick from the WG chairs to everyone, > saying "please review" would help. > > Mike -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Tue Feb 25 12:28:26 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07474 for ; Tue, 25 Feb 2003 12:28:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PHc0p15620; Tue, 25 Feb 2003 12:38:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PHbHp15275 for ; Tue, 25 Feb 2003 12:37:17 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07428 for ; Tue, 25 Feb 2003 12:27:39 -0500 (EST) Message-ID: From: Jeff Parker To: "'Jeffrey Haas'" , rtg-dir@ietf.org Subject: RE: Quality of document review in RTG WGs Date: Tue, 25 Feb 2003 12:31:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > From the relatively little time I've spent in IETF, > people seem willing to look at stuff as it initially > comes out. Well said. And your notes on motivation seem spot on. But as well as good intentions, people need time. In this market, I suspect fewer people are being paid to spend a significant amount of time working on standards. So what can be done? I think nagging works, and selective nagging works best of all. That is, when I hear folks complaining that no one is reviewing the TE MIB, the comments rolls off like water down a duck's back. When something I have worked on needs review, comments to the list give me a twing. When an AD writes me a note, I might get busy. - jeff parker From rtg-dir-admin@ietf.org Tue Feb 25 13:08:26 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08927 for ; Tue, 25 Feb 2003 13:08:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PII1p18743; Tue, 25 Feb 2003 13:18:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIGHp18672 for ; Tue, 25 Feb 2003 13:16:17 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08877 for ; Tue, 25 Feb 2003 13:06:40 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1PIAXF70988 for rtg-dir@ietf.org; Tue, 25 Feb 2003 13:10:33 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1PIAR570975 for ; Tue, 25 Feb 2003 13:10:27 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1PIARB27573 for rtg-dir@ietf.org; Tue, 25 Feb 2003 13:10:27 -0500 (EST) Date: Tue, 25 Feb 2003 13:10:27 -0500 From: Jeffrey Haas To: rtg-dir@ietf.org Subject: Re: Quality of document review in RTG WGs Message-ID: <20030225131027.A27505@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jparker@axiowave.com on Tue, Feb 25, 2003 at 12:31:20PM -0500 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Tue, Feb 25, 2003 at 12:31:20PM -0500, Jeff Parker wrote: > But as well as good intentions, people need time. Another question to ask in this regard: Is there some way we can help individual working groups churn less? What seems to have been having some success in the IDR WG with regards to the FSM issues has been something along the following: o Standardization Issues are brought up o A willing individual tracks the issues and provides an issue summary list. This allows issues to be tracked and more importantly, the relevant points. The issues list maintainer operates as an editor and librarian to keep relevant points associated together along with their consensus status. o People who wish to comment on individual items can do so. o Rinse. Repeat. Hopefully we get consensus. Thus, my observation is that our problem isn't so much finding willing people, its finding a way to make them more effective. (oh dear... I feel my hair growing pointy...) Thus, this is an information management issue more than anything else. Some speculation: What we seem to need is a mechanism for automate or help automate the excellent job that Andrew has been doing for IDR. This mechanism should probably be invoked in the following circumstances: o We are working through nitpicks to try to close out issues for standardization. This is late in the process. o Earlier in process, when there are items of specific contention. The properties of this mechanism would include: o Open issues o Thread comments specifically related to the issue. o Allow for moderation/editorial clarification. This involves librarian style skills. o Track consensus. o Reports This seems to be a combination of something like slashdot and a bug reporting tool. The moderator/WG chairs/AD's would be the ones to introduce an issue to be tracked. Anyone should be able to contribute, but the moderator should be able to declare how "focused" the contribution is. The gotcha is to integrate this with our existing mailing list discussion mechanism. -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Wed Feb 26 23:53:42 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08059 for ; Wed, 26 Feb 2003 23:53:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R541p07384; Thu, 27 Feb 2003 00:04:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R53Sp07363 for ; Thu, 27 Feb 2003 00:03:29 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08056 for ; Wed, 26 Feb 2003 23:53:08 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18oG6Q-000Abo-00; Wed, 26 Feb 2003 20:57:02 -0800 Date: Wed, 26 Feb 2003 20:56:44 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <45257212301.20030226205644@psg.com> To: Jeffrey Haas CC: rtg-dir@ietf.org Subject: Re: Quality of document review in RTG WGs In-Reply-To: <20030225131027.A27505@nexthop.com> References: <20030225131027.A27505@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I agree, the issue list approach helps quite a bit, especially when a big number of questions need resolution. We tried it first in isis-update where Jeff P lead the crew, and we're now using the same method in IDR. Let's chat about this more in SF. BTW, we should have a directorate meeting there, which I will send a separate message about for folks who're skipping this thread or filtering me ;-p -- Alex Tuesday, February 25, 2003, 10:10:27 AM, Jeffrey Haas wrote: > On Tue, Feb 25, 2003 at 12:31:20PM -0500, Jeff Parker wrote: >> But as well as good intentions, people need time. > Another question to ask in this regard: Is there some way we can > help individual working groups churn less? > What seems to have been having some success in the IDR WG with > regards to the FSM issues has been something along the following: > o Standardization Issues are brought up > o A willing individual tracks the issues and provides an issue summary > list. This allows issues to be tracked and more importantly, > the relevant points. The issues list maintainer operates as > an editor and librarian to keep relevant points associated together > along with their consensus status. > o People who wish to comment on individual items can do so. > o Rinse. Repeat. Hopefully we get consensus. > Thus, my observation is that our problem isn't so much finding willing > people, its finding a way to make them more effective. > (oh dear... I feel my hair growing pointy...) > Thus, this is an information management issue more than anything else. > Some speculation: > What we seem to need is a mechanism for automate or help automate the > excellent job that Andrew has been doing for IDR. This mechanism should > probably be invoked in the following circumstances: > o We are working through nitpicks to try to close out issues for > standardization. This is late in the process. > o Earlier in process, when there are items of specific contention. > The properties of this mechanism would include: > o Open issues > o Thread comments specifically related to the issue. > o Allow for moderation/editorial clarification. This involves librarian > style skills. > o Track consensus. > o Reports > This seems to be a combination of something like slashdot and a bug > reporting tool. The moderator/WG chairs/AD's would be the ones > to introduce an issue to be tracked. Anyone should be able to > contribute, but the moderator should be able to declare how "focused" > the contribution is. > The gotcha is to integrate this with our existing mailing list > discussion mechanism. > From rtg-dir-admin@ietf.org Wed Feb 26 23:55:42 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08084 for ; Wed, 26 Feb 2003 23:55:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R561p07459; Thu, 27 Feb 2003 00:06:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R55Ip07426 for ; Thu, 27 Feb 2003 00:05:18 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08073 for ; Wed, 26 Feb 2003 23:54:57 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18oG8D-000Ak3-00 for rtg-dir@ietf.org; Wed, 26 Feb 2003 20:58:53 -0800 Date: Wed, 26 Feb 2003 20:58:36 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <77257323661.20030226205836@psg.com> To: rtg-dir@ietf.org Subject: RTG Directorate meeting in SF MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Guys- Please shout if you're coming to SF and what's your availability. So far late bar sessions Sun--Wed look open. -- Alex From rtg-dir-admin@ietf.org Thu Feb 27 06:59:33 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26064 for ; Thu, 27 Feb 2003 06:59:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RCA1p11768; Thu, 27 Feb 2003 07:10:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RC9Vp11744 for ; Thu, 27 Feb 2003 07:09:31 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26061 for ; Thu, 27 Feb 2003 06:59:01 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1RC2uJR008940; Thu, 27 Feb 2003 07:02:56 -0500 (EST) Received: from dhcp-64-102-60-233.cisco.com (dhcp-64-102-60-233.cisco.com [64.102.60.233]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA09754; Thu, 27 Feb 2003 07:02:56 -0500 (EST) Date: Thu, 27 Feb 2003 07:02:56 -0500 (EST) From: Russ White Reply-To: Russ White To: Alex Zinin cc: rtg-dir@ietf.org Subject: Re: RTG Directorate meeting in SF In-Reply-To: <77257323661.20030226205836@psg.com> Message-ID: References: <77257323661.20030226205836@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Sunday night and tuesday lunch I think I'm tied up thus far, but other than that, I'm fine. :-) Russ On Wed, 26 Feb 2003, Alex Zinin wrote: > Guys- > > Please shout if you're coming to SF and what's your availability. > So far late bar sessions Sun--Wed look open. > > -- > Alex > __________________________________ riw@cisco.com CCIE <>< Grace Alone From rtg-dir-admin@ietf.org Thu Feb 27 10:34:29 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08317 for ; Thu, 27 Feb 2003 10:34:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFj1p28903; Thu, 27 Feb 2003 10:45:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFigp28865 for ; Thu, 27 Feb 2003 10:44:42 -0500 Received: from lxmail.xebeo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08307 for ; Thu, 27 Feb 2003 10:34:09 -0500 (EST) Received: (qmail 2932 invoked from network); 27 Feb 2003 15:38:04 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 27 Feb 2003 15:38:04 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id KAA00749 for ; Thu, 27 Feb 2003 10:38:03 -0500 Message-Id: <200302271538.KAA00749@bigbird.xebeo.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: rtg-dir@ietf.org Subject: Re: RTG Directorate meeting in SF In-Reply-To: Message from Alex Zinin of "Wed, 26 Feb 2003 20:58:36 PST." <77257323661.20030226205836@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Feb 2003 10:38:03 -0500 From: Rohit Dube Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , I will be in SF Sunday night to Wednesday Afternoon. Thus far, any time during that duration will work for me. Best, --rohit. On Wed, 26 Feb 2003 20:58:36 -0800 Alex Zinin writes: =>Guys- => => Please shout if you're coming to SF and what's your availability. => So far late bar sessions Sun--Wed look open. => =>-- =>Alex ___ From rtg-dir-admin@ietf.org Thu Feb 27 10:36:29 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08415 for ; Thu, 27 Feb 2003 10:36:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFl0p29041; Thu, 27 Feb 2003 10:47:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFkNp28968 for ; Thu, 27 Feb 2003 10:46:23 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08380 for ; Thu, 27 Feb 2003 10:35:50 -0500 (EST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14358 for ; Thu, 27 Feb 2003 08:39:45 -0700 (MST) Received: from sr1-ubur-03 (sr1-ubur-03 [129.148.9.82]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h1RFdjo25816 for ; Thu, 27 Feb 2003 10:39:45 -0500 (EST) Message-Id: <200302271539.h1RFdjo25816@sydney.East.Sun.COM> Date: Thu, 27 Feb 2003 10:39:45 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: RTG Directorate meeting in SF To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XL07Wp+2V+qWYAIaEcJDrA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.8 SunOS 5.8 sun4u sparc Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Yup. I'm available. Would be nice if the meeting could be in a somewhat quiet place. The bar has the advantage that it keeps it casual, and people don't mind waiting around for other people. But it is noisy (and sometimes smoky too). Radia From rtg-dir-admin@ietf.org Thu Feb 27 12:06:28 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11811 for ; Thu, 27 Feb 2003 12:06:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHH1p04244; Thu, 27 Feb 2003 12:17:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHGsp04214 for ; Thu, 27 Feb 2003 12:16:54 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11791 for ; Thu, 27 Feb 2003 12:06:19 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h1RHAE926588; Thu, 27 Feb 2003 12:10:14 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h1RHAA126581; Thu, 27 Feb 2003 12:10:10 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h1RHAA826744; Thu, 27 Feb 2003 12:10:10 -0500 (EST) Date: Thu, 27 Feb 2003 12:10:10 -0500 From: Jeffrey Haas To: Radia Perlman - Boston Center for Networking Cc: rtg-dir@ietf.org Subject: Re: RTG Directorate meeting in SF Message-ID: <20030227121010.A26124@nexthop.com> References: <200302271539.h1RFdjo25816@sydney.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200302271539.h1RFdjo25816@sydney.East.Sun.COM>; from Radia.Perlman@sun.com on Thu, Feb 27, 2003 at 10:39:45AM -0500 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Thu, Feb 27, 2003 at 10:39:45AM -0500, Radia Perlman - Boston Center for Networking wrote: > Yup. I'm available. Would be nice if the meeting > could be in a somewhat quiet place. The bar has > the advantage that it keeps it casual, and people > don't mind waiting around for other people. > But it is noisy (and sometimes smoky too). This is California, so the smoke shouldn't be a problem. > Radia -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Thu Feb 27 12:22:38 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12577 for ; Thu, 27 Feb 2003 12:22:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHXCp05537; Thu, 27 Feb 2003 12:33:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RHWUp05416 for ; Thu, 27 Feb 2003 12:32:30 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12513 for ; Thu, 27 Feb 2003 12:21:54 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18oRn0-000G3m-00; Thu, 27 Feb 2003 09:25:46 -0800 Date: Thu, 27 Feb 2003 09:25:34 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <136302141967.20030227092534@psg.com> To: Jeffrey Haas CC: Radia Perlman - Boston Center for Networking , rtg-dir@ietf.org Subject: Re: RTG Directorate meeting in SF In-Reply-To: <20030227121010.A26124@nexthop.com> References: <200302271539.h1RFdjo25816@sydney.East.Sun.COM> <20030227121010.A26124@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Indeed, though I would probably go to a restaurant for a useful discussion. Time-wise, how about a dinner together at 7pm on Tue? We don't have anything after, so we can have a relaxed conversation. -- Alex Thursday, February 27, 2003, 9:10:10 AM, Jeffrey Haas wrote: > On Thu, Feb 27, 2003 at 10:39:45AM -0500, Radia Perlman - Boston Center for Networking wrote: >> Yup. I'm available. Would be nice if the meeting >> could be in a somewhat quiet place. The bar has >> the advantage that it keeps it casual, and people >> don't mind waiting around for other people. >> But it is noisy (and sometimes smoky too). > This is California, so the smoke shouldn't be a problem. >> Radia From rtg-dir-admin@ietf.org Fri Feb 28 10:26:02 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01497 for ; Fri, 28 Feb 2003 10:26:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFb1p04085; Fri, 28 Feb 2003 10:37:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SFajp03950 for ; Fri, 28 Feb 2003 10:36:45 -0500 Received: from sith.maoz.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01487 for ; Fri, 28 Feb 2003 10:25:42 -0500 (EST) Received: (from dmm@localhost) by sith.maoz.com (8.12.6/8.12.6) id h1SFUE5m023733; Fri, 28 Feb 2003 07:30:14 -0800 Date: Fri, 28 Feb 2003 07:30:14 -0800 From: David Meyer To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: RTG Directorate meeting in SF Message-ID: <20030228073014.C23625@sprint.net> References: <77257323661.20030226205836@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <77257323661.20030226205836@psg.com>; from zinin@psg.com on Wed, Feb 26, 2003 at 08:58:36PM -0800 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , I'll be there... Dave >> Please shout if you're coming to SF and what's your availability. >> So far late bar sessions Sun--Wed look open. >> >> -- >> Alex From mailman-admin@ietf.org Sat Mar 1 09:28:13 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05736 for ; Sat, 1 Mar 2003 09:28:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21Ebip09969 for ; Sat, 1 Mar 2003 09:37:44 -0500 Date: Sat, 01 Mar 2003 09:37:44 -0500 Message-ID: <20030301143744.26394.84697.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rtg-dir-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rtg-dir-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rtg-dir-archive@ietf.org: List Password // URL ---- -------- rtg-dir@ietf.org utnefe https://www1.ietf.org/mailman/options/rtg-dir/rtg-dir-archive%40ietf.org From rtg-dir-admin@ietf.org Mon Mar 3 13:43:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06977 for ; Mon, 3 Mar 2003 13:43:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Irip14474; Mon, 3 Mar 2003 13:53:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Ihjp13764 for ; Mon, 3 Mar 2003 13:43:45 -0500 Received: from coffee.rawdofmt.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06659 for ; Mon, 3 Mar 2003 13:33:09 -0500 (EST) Received: by coffee.rawdofmt.org (Postfix, from userid 9140) id 2F15A3DCD27; Mon, 3 Mar 2003 10:35:15 -0800 (PST) Date: Mon, 3 Mar 2003 10:35:15 -0800 From: "Christian E. Hopps" To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: RTG Directorate meeting in SF Message-ID: <20030303183515.GA2579@rawdofmt.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , I'll be available those nights. On Wed, Feb 26, 2003 at 08:58:36PM -0800, Alex Zinin wrote: > Guys- > > Please shout if you're coming to SF and what's your availability. > So far late bar sessions Sun--Wed look open. > > -- > Alex From rtg-dir-admin@ietf.org Wed Mar 5 17:23:53 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02741 for ; Wed, 5 Mar 2003 17:23:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MZ3O28970; Wed, 5 Mar 2003 17:35:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25MYoO28925 for ; Wed, 5 Mar 2003 17:34:50 -0500 Received: from mail-green.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02735 for ; Wed, 5 Mar 2003 17:23:35 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id EF7671E0CE; Wed, 5 Mar 2003 17:25:38 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA25557; Wed, 5 Mar 2003 17:25:38 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h25MPbR23409; Wed, 5 Mar 2003 14:25:37 -0800 (PST) Message-Id: <200303052225.h25MPbR23409@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: jhaas@nexthop.com Subject: Re: Quality of document review in RTG WGs Cc: rtg-dir@ietf.org References: <20030225131027.A27505@nexthop.com> Date: Wed, 5 Mar 2003 14:25:36 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , >This seems to be a combination of something like slashdot and a bug >reporting tool. rtg.ietf.org has an as-yet unused forum section. I vaguely envisioned the possibility of having a "forum" per document. The biggest question is how the forums relate to archived WG mailing lists. http://rtg.ietf.org/modules.php?op=modload&name=Forums&file=viewforum&forum=12 (The second biggest question is: exactly how buggy is this stuff?) Bill From rtg-dir-admin@ietf.org Wed Mar 5 20:25:45 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09291 for ; Wed, 5 Mar 2003 20:25:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h261b2O09465; Wed, 5 Mar 2003 20:37:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h261agO09394 for ; Wed, 5 Mar 2003 20:36:42 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09281 for ; Wed, 5 Mar 2003 20:25:23 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18qkAR-000E34-00 for rtg-dir@ietf.org; Wed, 05 Mar 2003 17:27:27 -0800 Date: Wed, 5 Mar 2003 17:27:09 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <17220102445.20030305172709@psg.com> To: rtg-dir@ietf.org Subject: RTG-DIR Dinner Tue 7pm MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Guys, FYI, I have us scheduled for a dinner on Tue 7pm. -- Alex From rtg-dir-admin@ietf.org Wed Mar 5 21:07:45 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10143 for ; Wed, 5 Mar 2003 21:07:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h262J1O12576; Wed, 5 Mar 2003 21:19:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h262IHO12557 for ; Wed, 5 Mar 2003 21:18:17 -0500 Received: from vulture.icir.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10138 for ; Wed, 5 Mar 2003 21:06:58 -0500 (EST) Received: from vulture.icir.org (localhost [127.0.0.1]) by vulture.icir.org (8.12.3/8.12.3) with ESMTP id h26290dv045345; Wed, 5 Mar 2003 18:09:00 -0800 (PST) (envelope-from mjh@vulture.icir.org) From: Mark Handley X-Organisation: ICIR To: Alex Zinin cc: rtg-dir@ietf.org Subject: Re: RTG-DIR Dinner Tue 7pm In-reply-to: Your message of "Wed, 05 Mar 2003 17:27:09 PST." <17220102445.20030305172709@psg.com> Date: Wed, 05 Mar 2003 18:09:00 -0800 Message-ID: <45344.1046916540@vulture.icir.org> Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , >Guys, FYI, I have us scheduled for a dinner on Tue 7pm. Sorry folks, I won't be able to make it - the IAB dinner is also on Tuesday evening. Cheers, Mark From rtg-dir-admin@ietf.org Tue Mar 11 17:51:55 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16147 for ; Tue, 11 Mar 2003 17:51:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN61O08771; Tue, 11 Mar 2003 18:06:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN5TO08750 for ; Tue, 11 Mar 2003 18:05:29 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16135 for ; Tue, 11 Mar 2003 17:51:19 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18sscg-0007ym-00 for rtg-dir@ietf.org; Tue, 11 Mar 2003 14:53:27 -0800 Date: Tue, 11 Mar 2003 14:43:14 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5523738173.20030311144314@psg.com> To: rtg-dir@ietf.org Subject: Review: 4 isis drafts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Guys, We have the following drafts out of the ISIS WG: draft-ietf-isis-admin-tags-01.txt draft-ietf-isis-igp-p2p-over-lan-01.txt draft-ietf-isis-ip-interoperable-00.txt draft-ietf-isis-iso-interoperable-00.txt These need to be reviewed by March 29th (1 week after the SF meeting). I assume they may be interesting for someone, if so, please take the token (cc the list). I'll use round robin for those left unassigned by Friday. -- Alex From rtg-dir-admin@ietf.org Tue Mar 11 17:53:54 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16214 for ; Tue, 11 Mar 2003 17:53:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN81O09643; Tue, 11 Mar 2003 18:08:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN7uO09608 for ; Tue, 11 Mar 2003 18:07:56 -0500 Received: from sith.maoz.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16210 for ; Tue, 11 Mar 2003 17:53:45 -0500 (EST) Received: (from dmm@localhost) by sith.maoz.com (8.12.8/8.12.8) id h2BMuR1E015040; Tue, 11 Mar 2003 14:56:27 -0800 Date: Tue, 11 Mar 2003 14:56:27 -0800 From: David Meyer To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: Review: 4 isis drafts Message-ID: <20030311145627.A15037@sprint.net> References: <5523738173.20030311144314@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5523738173.20030311144314@psg.com>; from zinin@psg.com on Tue, Mar 11, 2003 at 02:43:14PM -0800 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , I'll take draft-ietf-isis-ip-interoperable-00.txt Dave On Tue, Mar 11, 2003 at 02:43:14PM -0800, Alex Zinin wrote: >> Guys, >> >> We have the following drafts out of the ISIS WG: >> >> draft-ietf-isis-admin-tags-01.txt >> draft-ietf-isis-igp-p2p-over-lan-01.txt >> draft-ietf-isis-ip-interoperable-00.txt >> draft-ietf-isis-iso-interoperable-00.txt >> >> These need to be reviewed by March 29th (1 week after the SF meeting). >> I assume they may be interesting for someone, if so, please take the >> token (cc the list). I'll use round robin for those left unassigned by >> Friday. >> >> -- >> Alex From rtg-dir-admin@ietf.org Tue Mar 11 17:54:54 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16252 for ; Tue, 11 Mar 2003 17:54:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN91O09705; Tue, 11 Mar 2003 18:09:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BN8KO09660 for ; Tue, 11 Mar 2003 18:08:20 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16242 for ; Tue, 11 Mar 2003 17:54:09 -0500 (EST) Message-ID: From: Jeff Parker To: "'Alex Zinin'" , rtg-dir@ietf.org Subject: RE: Review: 4 isis drafts Date: Tue, 11 Mar 2003 17:56:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Alex - I must beg off the last two, so I'll review p2p over LAN - jeff parker - axiowave networks - Minutus cantorum, minutus balorum, minutus carborata descendum pantorum - (A little song, a little dance, a little seltzer down your pants) > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Tuesday, March 11, 2003 5:43 PM > To: rtg-dir@ietf.org > Subject: Review: 4 isis drafts > > > Guys, > > We have the following drafts out of the ISIS WG: > > draft-ietf-isis-admin-tags-01.txt > draft-ietf-isis-igp-p2p-over-lan-01.txt > draft-ietf-isis-ip-interoperable-00.txt > draft-ietf-isis-iso-interoperable-00.txt > > These need to be reviewed by March 29th (1 week after the SF meeting). > I assume they may be interesting for someone, if so, please take the > token (cc the list). I'll use round robin for those left unassigned by > Friday. > > -- > Alex > From rtg-dir-admin@ietf.org Tue Mar 11 18:01:53 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16439 for ; Tue, 11 Mar 2003 18:01:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BNG0O09966; Tue, 11 Mar 2003 18:16:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BNF0O09916 for ; Tue, 11 Mar 2003 18:15:00 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16404 for ; Tue, 11 Mar 2003 18:00:50 -0500 (EST) Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 65E43381900 for ; Tue, 11 Mar 2003 15:02:57 -0800 (PST) Message-ID: <3E6E6BCD.6000101@redback.com> Date: Tue, 11 Mar 2003 18:05:49 -0500 From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: rtg-dir@ietf.org Subject: Re: Review: 4 isis drafts References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'll review draft-ietf-isis-admin-tags-01.txt Jeff Parker wrote: > Alex - > I must beg off the last two, so I'll review p2p over LAN > > - jeff parker > - axiowave networks > - Minutus cantorum, minutus balorum, minutus carborata descendum pantorum > - (A little song, a little dance, a little seltzer down your pants) > > >>-----Original Message----- >>From: Alex Zinin [mailto:zinin@psg.com] >>Sent: Tuesday, March 11, 2003 5:43 PM >>To: rtg-dir@ietf.org >>Subject: Review: 4 isis drafts >> >> >>Guys, >> >>We have the following drafts out of the ISIS WG: >> >> draft-ietf-isis-admin-tags-01.txt >> draft-ietf-isis-igp-p2p-over-lan-01.txt >> draft-ietf-isis-ip-interoperable-00.txt >> draft-ietf-isis-iso-interoperable-00.txt >> >>These need to be reviewed by March 29th (1 week after the SF meeting). >>I assume they may be interesting for someone, if so, please take the >>token (cc the list). I'll use round robin for those left unassigned by >>Friday. >> >>-- >>Alex >> > > -- Acee From rtg-dir-admin@ietf.org Tue Mar 11 19:06:54 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19743 for ; Tue, 11 Mar 2003 19:06:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0L3O14486; Tue, 11 Mar 2003 19:21:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0KrO14447 for ; Tue, 11 Mar 2003 19:20:53 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19733 for ; Tue, 11 Mar 2003 19:06:40 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18stnd-000CS5-00 for rtg-dir@ietf.org; Tue, 11 Mar 2003 16:08:49 -0800 Date: Tue, 11 Mar 2003 15:56:10 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5228114045.20030311155610@psg.com> To: rtg-dir@ietf.org Subject: comments on drafts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Guys- Jeff P just asked me a question interesting for all doing a review-- what type of comments the directorate should be bringing and how we should proceed with them. Type of comments: Keep in mind that the documents have passed the WG LC, so there supposed to be a WG consensus on them. On the other hand the review should be useful--it _is_ possible for documents to come out of a WG with bugs. Please also pay attention to the ID nits--the earlier in the process we catch them the better. I usually combine my comments in 3 groups: - Meta issues (something global, like whether the problem is valid, whether the approach is valid, you fundamentally disagree, etc.) - Technical (bugs, inconsistencies, questions...) - Editorial ("while you're at it" type of things: ID nits, grammar, format, etc.) I would recommend staying away from changing the wording to your liking unless it substantially improves readability or clarity of the document. How to proceed: If you feel you better discuss your comments first within the directorate--shoot them on the list. I recommend we do this for some time. Finally the comments should go out to the WG chairs and authors and on the WG mailing list. A reasonable approach is to discuss the comments with the chairs and authors, making clear this is a rtg-dir review, cc'ing this list and then let them bring those to the WG if changes deemed necessary. If further discussion is needed, the reviewer may need to engage on the WG mailing list. Hope this helps. -- Alex From rtg-dir-admin@ietf.org Tue Mar 11 20:57:49 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22797 for ; Tue, 11 Mar 2003 20:57:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C2C1O22527; Tue, 11 Mar 2003 21:12:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C2BEO22471 for ; Tue, 11 Mar 2003 21:11:14 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22777 for ; Tue, 11 Mar 2003 20:56:58 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18svWJ-000JQ4-00; Tue, 11 Mar 2003 17:59:03 -0800 Date: Tue, 11 Mar 2003 17:44:30 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5434613892.20030311174430@psg.com> To: "Putzolu, David" CC: "Patrick Droz (dro@zurich.ibm.com)" , Bill Fenner , Subject: Re: ForCES Framework submission for AD Review In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David, I'm taking this thread to the rtg-dir list so I don't function as a relay. I'll be sending my comments in a separate e-mail. Regards. -- Alex Wednesday, March 5, 2003, 4:48:15 PM, Putzolu, David wrote: > Hi Alex. > My compliments to Chris Hopps - it is clear that he > really did a thorough job reading this stuff and grasped > the essentials quite well. > My responses inline. >> > - NIT: 8-bit set characters in draft. >> > >> > - How does the architecture deal with multiple distinct CEs sharing >> > a single FE. The framework mentions multiple CEs with an Fr link >> > but these CEs actually implement a single logical CE. Does this >> > mean that the physical FE must present multiple virtual FEs if it >> > is to be shared amongst multiple real CEs? Perhaps this restriction >> > should be pointed out. > My understanding of having multiple CEs sharing > a single FE is that it falls into two cases: > * Either the FE is a physical FE that is logically > partitioned into multiple virtual FEs (GSMP wg has > a draft that does this). If this is the case, each > virtual FE only sees a single CE, so the issue becomes > one of defining a robust virtualization (not something > we are trying to do). I remember discussions about this > in the WG, but can't find anything in the framework, so > this may be a missing item. > * The other case is that the FE actually does have > multiple CEs controlling it. In this case the approach > I understand they have taken is that they require that > the CEs must cooperate (via the Fr reference point) to > ensure that the FE receives consistent information via > ForCES. This becomes in effect a multi-master control > problem, which is too difficult for FEs to be asked to > solve (as it would involve some sort of capabilities > or role-based scheme or other similar complexity). See > the 3rd paragraph of section 3.1. >> > - The architecture does not (currently) define Fi >> (forwarding interface >> > between FEs); however, if the goal is promote interchangeability, >> > is this not critical to standardize at some level? > Yes. Fi (and several of the other reference points defined > by the framework) all are necessary to achieve complete > plug and play. ForCES is solving one part of the puzzle. > When ForCES was chartered there was an awareness of these > other problems but it was felt that a single WG was not > the right place to address them all. > Some of the necessary technologies are already happening > in other places. PCIsig is defining hardware and interconnect > standards that can be used to interoperably put blades > together. NPF is defining a way to enable state sharing > between blades of per-packet information. > I would actually like your opinion and advice on this topic. > In particular, I believe it would be valuable for a real > standards body like IETF (as opposed to a forum/sig) to > define the entire standard. At the same time, while some > of the reference points (e.g. Fp, Fc, Ff) are likely to be > run across networks, some others (Fi) will probably remain > "within" boxen for a long time, due to bandwidth/performance > requirements (imho). Are purely within-boxen technologies > the right thing to do @ IETF? >> > - The arch. seems to require single managers (CE and FE). Is there a >> > need for an arbitration mechanism? I'm imagining multiple >> blades (FEs) >> > each with a "bus master" capability. I.e., N of M blades in an NE >> > might be capable of being the FE manager. > The FE and CE managers are logical entities, and their > function is one of initial configuration of FEs and CEs > to be able to find each other (section 1, bottom of p3). > So I'm not really sure I understand the bus master analogy. > If there is a need for multiple managers they > would probably need to arbitrate among themselves to decide > who gets to give the FE or CE its initial config info. >> > - in 5.4 there appears to be no mechanism mentioned to >> allow for the CE >> > to block delivery of exceptional packets from the FE. Is >> this therefore >> > susceptible to DoS attack? > A DoS attack is a real possibility and the filtering > mentioned in para 2 and 3 of 5.4 would be used to drop > such packets when an attack is detected. In addition > to this, the requirements say that a priority mechanism > is necessary - this is needed to deal with a DoS attack > when it first happens (before filters are installed) > to allow prioritization of delivery of the packets > that install the filter on the FE over delivery of > the packets being "aimed at" the CE. See section 7 requirement > 5 in the requirements. > I was unable to find any mention of this in the framework, > but the framework is more about identifying architectural > entities and functions than protocol details. Should this > be included in the framework as well as the > requirements/protocol proposals? >> > - allowing ospf hello and other portions of CE functionality to be >> > implemented by FEs appears to open the architecture so wide it would >> > be impossible to actually achieve the goal of interchangeable operation. > I think a generic framework for offloading anything > would indeed be too open ended (and would seem to me > to be akin to defining some sort of virtual machine > on the FE). My belief is that it would be necessary > to tackle such things on a case-by-case basis, i.e. > define a standard way to do OSPF hello offload for > instance. If the problem is broken into manageable > pieces then I think it is not too wide open. >> > - does the architecture allow for non-stop forwarding? Perhaps this >> > should be directly addressed somewhere. > Good catch. Requirements doc section 5 (arch requirements) item 7 > mentions this. Framework probably should as well. >> > More general: >> > >> > - The document mentions in a few places that ForCES will >> focus on the >> > ForCES protocol only (the CE/FE communication channel). It >> does point out >> > the other communication channels (and therefore possibly protocols) >> > may exist or be required. >> > >> > If the goal of ForCES is to allow for interchangeable >> operation of CEs >> > and FEs (if it isn't why standardize it?), how can we not >> also plan on >> > standardizing the other required protocols (at minimum the >> CE Mgr - FE Mgr, >> > CE Mgr - CE, FE Mgr - FE, and FE - FE). > Are these two questions the same as the Fi one up above? > If so see my response above. If not I'm having trouble > understanding and could use some elaboration :) > Note: I have responded to all of the above based on my > personal understanding in an effort to get a prompt answer > out. Is it ok for me to share the feedback directly with > the authors and/or WG (and if so, should it be anonymized?) > I don't really know what IETF procedure is on this. > Thanks, > David From rtg-dir-admin@ietf.org Tue Mar 11 21:16:50 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23142 for ; Tue, 11 Mar 2003 21:16:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C2V1O23114; Tue, 11 Mar 2003 21:31:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C2U1O23074 for ; Tue, 11 Mar 2003 21:30:01 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23133 for ; Tue, 11 Mar 2003 21:15:44 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18svoT-000KAp-00; Tue, 11 Mar 2003 18:17:49 -0800 Date: Tue, 11 Mar 2003 18:03:16 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <13735739721.20030311180316@psg.com> To: "Putzolu, David" CC: "Patrick Droz (dro@zurich.ibm.com)" , Bill Fenner , Subject: Re: ForCES Framework submission for AD Review In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David, inline below, pls. > Hi Alex. > My compliments to Chris Hopps - it is clear that he > really did a thorough job reading this stuff and grasped > the essentials quite well. > My responses inline. >> > - NIT: 8-bit set characters in draft. >> > >> > - How does the architecture deal with multiple distinct CEs sharing >> > a single FE. The framework mentions multiple CEs with an Fr link >> > but these CEs actually implement a single logical CE. Does this >> > mean that the physical FE must present multiple virtual FEs if it >> > is to be shared amongst multiple real CEs? Perhaps this restriction >> > should be pointed out. > My understanding of having multiple CEs sharing > a single FE is that it falls into two cases: > * Either the FE is a physical FE that is logically > partitioned into multiple virtual FEs (GSMP wg has > a draft that does this). If this is the case, each > virtual FE only sees a single CE, so the issue becomes > one of defining a robust virtualization (not something > we are trying to do). I remember discussions about this > in the WG, but can't find anything in the framework, so > this may be a missing item. I think this is what Chris meant. I have no strong opinion on this topic, and would not have a problem with ForCES addressing the simpler problem first. > * The other case is that the FE actually does have > multiple CEs controlling it. In this case the approach > I understand they have taken is that they require that > the CEs must cooperate (via the Fr reference point) to > ensure that the FE receives consistent information via > ForCES. This becomes in effect a multi-master control > problem, which is too difficult for FEs to be asked to > solve (as it would involve some sort of capabilities > or role-based scheme or other similar complexity). See > the 3rd paragraph of section 3.1. >> > - The architecture does not (currently) define Fi >> (forwarding interface >> > between FEs); however, if the goal is promote interchangeability, >> > is this not critical to standardize at some level? > Yes. Fi (and several of the other reference points defined > by the framework) all are necessary to achieve complete > plug and play. ForCES is solving one part of the puzzle. > When ForCES was chartered there was an awareness of these > other problems but it was felt that a single WG was not > the right place to address them all. > Some of the necessary technologies are already happening > in other places. PCIsig is defining hardware and interconnect > standards that can be used to interoperably put blades > together. NPF is defining a way to enable state sharing > between blades of per-packet information. > I would actually like your opinion and advice on this topic. > In particular, I believe it would be valuable for a real > standards body like IETF (as opposed to a forum/sig) to > define the entire standard. At the same time, while some > of the reference points (e.g. Fp, Fc, Ff) are likely to be > run across networks, some others (Fi) will probably remain > "within" boxen for a long time, due to bandwidth/performance > requirements (imho). Are purely within-boxen technologies > the right thing to do @ IETF? If we didn't have ForCES, I would say 'no' :) Seriously, I think defining only the Fp protocol at this point is fine. When/if we see a lot of interest in the community to define others, we'll discuss this. The framework seems to correctly identify the interface points, it's just that we choose the first step. >> > - The arch. seems to require single managers (CE and FE). Is there a >> > need for an arbitration mechanism? I'm imagining multiple >> blades (FEs) >> > each with a "bus master" capability. I.e., N of M blades in an NE >> > might be capable of being the FE manager. > The FE and CE managers are logical entities, and their > function is one of initial configuration of FEs and CEs > to be able to find each other (section 1, bottom of p3). > So I'm not really sure I understand the bus master analogy. > If there is a need for multiple managers they > would probably need to arbitrate among themselves to decide > who gets to give the FE or CE its initial config info. Chris will correct me if I'm wrong, but I think what is meant here is if, for example, the FE manager is collocated with an FE and there are many of such FEs in an NE, how do they choose whose the one... I would think this would be part of the Fi interface. >> > - in 5.4 there appears to be no mechanism mentioned to >> allow for the CE >> > to block delivery of exceptional packets from the FE. Is >> this therefore >> > susceptible to DoS attack? > A DoS attack is a real possibility and the filtering > mentioned in para 2 and 3 of 5.4 would be used to drop > such packets when an attack is detected. In addition > to this, the requirements say that a priority mechanism > is necessary - this is needed to deal with a DoS attack > when it first happens (before filters are installed) > to allow prioritization of delivery of the packets > that install the filter on the FE over delivery of > the packets being "aimed at" the CE. See section 7 requirement > 5 in the requirements. > I was unable to find any mention of this in the framework, > but the framework is more about identifying architectural > entities and functions than protocol details. Should this > be included in the framework as well as the > requirements/protocol proposals? I think this could be included as a function within the general discussion on sending packets from FEs up to CEs. >> > - allowing ospf hello and other portions of CE functionality to be >> > implemented by FEs appears to open the architecture so wide it would >> > be impossible to actually achieve the goal of interchangeable operation. > I think a generic framework for offloading anything > would indeed be too open ended (and would seem to me > to be akin to defining some sort of virtual machine > on the FE). My belief is that it would be necessary > to tackle such things on a case-by-case basis, i.e. > define a standard way to do OSPF hello offload for > instance. If the problem is broken into manageable > pieces then I think it is not too wide open. I share Chris'es concern here. I'd rather us not go try to specify this, not in the first ver anyways... The same comment applicable to sections 5, 5.2, 5.6. >> > - does the architecture allow for non-stop forwarding? Perhaps this >> > should be directly addressed somewhere. > Good catch. Requirements doc section 5 (arch requirements) item 7 > mentions this. Framework probably should as well. Section 4.3 talks a bit about this-- > The example in Figure 5 is used to illustrate what happens when the > association is broken and later re-established again. Section 3.2 > already explains what happens if CE1 fails and how CE2 can take > over. If no CE redundancy is provided, at the association > establishment phase FEs need to be told what to do in the case of CE > failure. FEs may be told to stop packet processing all together if > its CE fails. Or, FEs may be told to continue forwarding packets > for a limited time even in the face of CE failure. No matter what > the instruction is, it needs to be part of the configuration when > the association is established. --but spelling this out may be a good idea. Let's call it... hmmm... "graceful restart" for consistency :) >> > More general: >> > >> > - The document mentions in a few places that ForCES will >> focus on the >> > ForCES protocol only (the CE/FE communication channel). It >> does point out >> > the other communication channels (and therefore possibly protocols) >> > may exist or be required. >> > >> > If the goal of ForCES is to allow for interchangeable >> operation of CEs >> > and FEs (if it isn't why standardize it?), how can we not >> also plan on >> > standardizing the other required protocols (at minimum the >> CE Mgr - FE Mgr, >> > CE Mgr - CE, FE Mgr - FE, and FE - FE). > Are these two questions the same as the Fi one up above? > If so see my response above. If not I'm having trouble > understanding and could use some elaboration :) > Note: I have responded to all of the above based on my > personal understanding in an effort to get a prompt answer > out. Is it ok for me to share the feedback directly with > the authors and/or WG (and if so, should it be anonymized?) > I don't really know what IETF procedure is on this. My recommendation would be to distill the comments on this list and then bring an agreed upon set back to the WG. Here's some more comments from me: > 4.2.3. Steady-state Communication > |(My port is down, with port #.) > 1|---------------------->| > | | > |(Route to this port instead...) > 2|<----------------------| > | | "route to this port instead" seems wrong, the CE would need to Ack and then come back with updated FIB entries. > 4.3. Association Re-establishment [...] > In the same example in Figure 5, assuming CE1 is the working CE for > the moment, what would happen if one of the FEs, say FE1, leaves the > NE temporarily? FE1 may voluntarily decide to leave the > association. Or, FE1 may stop functioning simply due to unexpected > failure. In former case, CE1 receives a "leave-association request" > from FE1. In the latter, CE1 detects the failure of FE1 by some > other mean. In both cases, CE1 keeps a note of such event from FE1 > while continue commanding FE2. not just "note", but also inform the routing protocols that will need to recalculate their route which will result in FIB updates. > When FE1 decides to rejoin again, or > when it is back up again from the failure, FE1 needs to re-discover > its master (CE). This can be achieved by several means. It may re- > enter the pre-association phase and get that information from its FE > manager. It may retrieve the previous CE information from its > cache, if it can validate the information freshness. Once it > discovers its CE, it starts message exchange with CE to re-establish > the association just as outlined in Figure 9, with the possible > exception that it might be able to bypass the transport of the > complete initialization information. What about the security hand-shake though? > Suppose that FE1 still has its > routing table and other state information from the last association, > instead of sending all the information again from scratch, it can > choose to use more efficient mechanism to re-sync up the state with > its CE. For example, a checksum of the state might give a quick > indication of whether or not the state is in-sync with its CE. By > comparing its state with CE first, it sends information update only > if it is needed. This would require corresponding mechanisms in the protocol itself, right? > 9. Security Considerations Ed: Move before refs? Thanks, Alex From rtg-dir-admin@ietf.org Wed Mar 12 03:15:41 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25931 for ; Wed, 12 Mar 2003 03:15:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C8U1O23234; Wed, 12 Mar 2003 03:30:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C8TuO23210 for ; Wed, 12 Mar 2003 03:29:56 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25928 for ; Wed, 12 Mar 2003 03:15:33 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2C8He0E021889; Wed, 12 Mar 2003 00:17:41 -0800 (PST) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4257.cisco.com [10.61.80.160]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA11980; Wed, 12 Mar 2003 08:17:39 GMT Message-Id: <4.3.2.7.2.20030312081704.030e7c80@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Mar 2003 08:17:38 +0000 To: Alex Zinin From: mike shand Subject: Re: Review: 4 isis drafts Cc: rtg-dir@ietf.org In-Reply-To: <5523738173.20030311144314@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Looks like I get > draft-ietf-isis-iso-interoperable-00.txt Mike From rtg-dir-admin@ietf.org Wed Mar 12 10:56:34 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09183 for ; Wed, 12 Mar 2003 10:56:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGB2O23299; Wed, 12 Mar 2003 11:11:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CGAqO23281 for ; Wed, 12 Mar 2003 11:10:52 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09179 for ; Wed, 12 Mar 2003 10:56:21 -0500 (EST) Message-ID: From: Jeff Parker To: rtg-dir@ietf.org Subject: Questions on draft-ietf-isis-igp-p2p-over-lan-01.txt Date: Wed, 12 Mar 2003 10:58:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > in fact they have passed the WG LC, whatever this means > > Alex So these are questions I should have asked a long time ago. The draft is well written, and solves a real problem. A) Are there any issues interoperating with 3-way handshake? I would think this would be very helpful in catching problems. But I assume the implementations have tried this. B) I'm not sure what the issue is with MAC address gleening. Is it the problem of getting the MAC address itself? If so, did you consider adding a TLV to the hello that include your MAC? If the problem is populating the APR cache, perhaps that is a requirement on the implementation. C) Although you have ruled this out in the algorithm you describe, someone is bound to try dynamic configuration, by sending both LAN and P2P packets over LAN links and prefering a P2P response. You might point out that, say, this is a bad idea as it behaves badly when two routers negotiate a p2p link, to be joined by a third router. D) Does a 3rd rogue router operating on a LAN and "capturing" the adjacency from one or both of the 2 'real' routers constitute a new Security Threat? - jeff parker - axiowave networks From rtg-dir-admin@ietf.org Thu Mar 13 10:03:04 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03260 for ; Thu, 13 Mar 2003 10:03:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFI0O02714; Thu, 13 Mar 2003 10:18:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFD1O02513 for ; Thu, 13 Mar 2003 10:13:01 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03068 for ; Thu, 13 Mar 2003 09:58:01 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DF080E021825 for ; Thu, 13 Mar 2003 07:00:09 -0800 (PST) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4306.cisco.com [10.61.80.209]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA29363 for ; Thu, 13 Mar 2003 15:00:07 GMT Message-Id: <4.3.2.7.2.20030312085829.030f10a8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 15:00:06 +0000 To: rtg-dir@ietf.org From: mike shand Subject: Comments on 10589 ISO interop Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , I've reviewed draft-ietf-isis-iso-interoparable-00.txt I have no serious comments other than to ask whether we have precisely tied down the status of this document, especially since it covers matters germane to ISO/IEC 10589 itself. I know Alex has been working this general issue, and I just wonder whether the current state of that issue requires any changes to this document. Other than that I just have a few nits. See below. Mike 0) Abstract "This document discusses a number of differences between the IS-IS protocol as described in ISO 10589 [1]" insert "and" "the protocol as it is deployed today." and also "A companion document discusses differences between the protocol described in RFC 1195 [3] for routing IP traffic." between is a binary operator. Presumably it should read "and current practice", or some such. 1) last para of 7.2 "appropriate match" ->"appropriate notification" ? 2) last para of 7.3 "SHOULD generate a the" -> "SHOULD generate the" 3) In para 14 the statement "Note that a purged LSP (i.e. an LSP with remaining lifetime set to 0 and/or a zero checksum) is always considered newer than a non-purged copy of the same LSP. " is inconsistent with para 11 (zero checksum) Just omit the reference to the zero checksum. [end] From rtg-dir-admin@ietf.org Thu Mar 13 10:34:02 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05686 for ; Thu, 13 Mar 2003 10:34:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFn0O05494; Thu, 13 Mar 2003 10:49:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFk7O05346 for ; Thu, 13 Mar 2003 10:46:07 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05524 for ; Thu, 13 Mar 2003 10:31:06 -0500 (EST) Message-ID: From: Jeff Parker To: "'mike shand'" , rtg-dir@ietf.org Subject: RE: Comments on 10589 ISO interop Date: Thu, 13 Mar 2003 10:32:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > I have no serious comments other than to ask whether we have > precisely tied down the status of this document, especially > since it covers matters germane to ISO/IEC 10589 itself. I took the agreement that Alex reached to say that this would be informational. Is there any problem with this being only informational? > Other than that I just have a few nits. See below. Thanks for the updates. - jeff parker From rtg-dir-admin@ietf.org Thu Mar 13 22:08:48 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00648 for ; Thu, 13 Mar 2003 22:08:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E3O0O24418; Thu, 13 Mar 2003 22:24:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E3NUO24395 for ; Thu, 13 Mar 2003 22:23:30 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00639 for ; Thu, 13 Mar 2003 22:08:15 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tfaO-000I2G-00; Thu, 13 Mar 2003 19:10:20 -0800 Date: Thu, 13 Mar 2003 19:08:29 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <25212453391.20030313190829@psg.com> To: Jeff Parker CC: rtg-dir@ietf.org, acee@redback.com, jenny@redback.com, zinin@psg.com, riw@cisco.com, , , Naiming Shen Subject: Re: Questions on draft-ietf-isis-igp-p2p-over-lan-01.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks Jeff! Naming, et al., could you guys answer Jeff's questions below? I'm running the draft by the RTG-DIR. Thanks. -- Alex Wednesday, March 12, 2003, 7:58:23 AM, Jeff Parker wrote: >> in fact they have passed the WG LC, whatever this means >> >> Alex > So these are questions I should have asked a long time ago. > The draft is well written, and solves a real problem. > A) Are there any issues interoperating with 3-way handshake? > I would think this would be very helpful in catching > problems. But I assume the implementations have tried this. > B) I'm not sure what the issue is with MAC address gleening. > Is it the problem of getting the MAC address itself? If so, > did you consider adding a TLV to the hello that include your > MAC? > If the problem is populating the APR cache, perhaps > that is a requirement on the implementation. > C) Although you have ruled this out in the algorithm you describe, > someone is bound to try dynamic configuration, by sending > both LAN and P2P packets over LAN links and prefering a P2P > response. You might point out that, say, this is a bad > idea as it behaves badly when two routers negotiate > a p2p link, to be joined by a third router. > D) Does a 3rd rogue router operating on a LAN and > "capturing" the adjacency from one or both of > the 2 'real' routers constitute a new Security > Threat? > - jeff parker > - axiowave networks From rtg-dir-admin@ietf.org Thu Mar 13 22:10:48 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00688 for ; Thu, 13 Mar 2003 22:10:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E3Q0O24496; Thu, 13 Mar 2003 22:26:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E3PRO24480 for ; Thu, 13 Mar 2003 22:25:27 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00672 for ; Thu, 13 Mar 2003 22:10:12 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tfcH-000I7f-00; Thu, 13 Mar 2003 19:12:17 -0800 Date: Thu, 13 Mar 2003 19:10:27 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <30212570720.20030313191027@psg.com> To: Jeff Parker CC: "'mike shand'" , rtg-dir@ietf.org Subject: Re: Comments on 10589 ISO interop In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff, Mike- >> I have no serious comments other than to ask whether we have >> precisely tied down the status of this document, especially >> since it covers matters germane to ISO/IEC 10589 itself. > I took the agreement that Alex reached to say that this > would be informational. That is correct. The document should be going INFO and then referred to JTC1 as a liaison contribution. Alex > Is there any problem with this > being only informational? >> Other than that I just have a few nits. See below. > Thanks for the updates. > - jeff parker From rtg-dir-admin@ietf.org Thu Mar 13 22:46:50 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01561 for ; Thu, 13 Mar 2003 22:46:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E421O26511; Thu, 13 Mar 2003 23:02:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E41XO26488 for ; Thu, 13 Mar 2003 23:01:33 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01545 for ; Thu, 13 Mar 2003 22:46:15 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2E3j2O03250 for ; Fri, 14 Mar 2003 03:45:02 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2E3gmM19442 for ; Fri, 14 Mar 2003 03:42:48 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003031319460726210 ; Thu, 13 Mar 2003 19:46:07 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Mar 2003 19:48:24 -0800 Message-ID: From: "Putzolu, David" To: Alex Zinin , rtg-dir@ietf.org Cc: "Patrick Droz (dro@zurich.ibm.com)" , Bill Fenner Subject: RE: ForCES Framework submission for AD Review Date: Thu, 13 Mar 2003 19:48:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2E9DC.8FFBB570" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_000_01C2E9DC.8FFBB570 Content-Type: text/plain Hi Alex/rtg-dir - detailed responses inline. I have attached a proposed summary of the IESG and rtg-dir questions and feedback for sending to the framework team and to the WG at large. Please review and tell me if the attached summary and responses below are appropriate and accurate. Thanks, David > -----Original Message----- > inline below, pls. > > >> > - How does the architecture deal with multiple distinct > CEs sharing > >> > a single FE. The framework mentions multiple CEs with an Fr link > >> > but these CEs actually implement a single logical CE. Does this > >> > mean that the physical FE must present multiple virtual FEs if it > >> > is to be shared amongst multiple real CEs? Perhaps this > restriction > >> > should be pointed out. > > > My understanding of having multiple CEs sharing > > a single FE is that it falls into two cases: > > * Either the FE is a physical FE that is logically > > partitioned into multiple virtual FEs (GSMP wg has > > a draft that does this). If this is the case, each > > virtual FE only sees a single CE, so the issue becomes > > one of defining a robust virtualization (not something > > we are trying to do). I remember discussions about this > > in the WG, but can't find anything in the framework, so > > this may be a missing item. > > I think this is what Chris meant. > I have no strong opinion on this topic, and would not > have a problem with ForCES addressing the simpler problem > first. I will ask the framework authors to explicitly call out the fact that each FE is a single logical entity, and that partitioning a physical FE into many virtual FEs is something that is out-of-scope of ForCES and is something that happens through other mechanisms. An informational RFC just issued on requirements for doing this, I'll have them reference that. > >> > - The architecture does not (currently) define Fi > >> (forwarding interface > >> > between FEs); however, if the goal is promote interchangeability, > >> > is this not critical to standardize at some level? > > > Yes. Fi (and several of the other reference points defined > > by the framework) all are necessary to achieve complete > > plug and play. ForCES is solving one part of the puzzle. > > When ForCES was chartered there was an awareness of these > > other problems but it was felt that a single WG was not > > the right place to address them all. > > > Some of the necessary technologies are already happening > > in other places. PCIsig is defining hardware and interconnect > > standards that can be used to interoperably put blades > > together. NPF is defining a way to enable state sharing > > between blades of per-packet information. > > Seriously, I think defining only the Fp protocol at this point is > fine. When/if we see a lot of interest in the community to define > others, we'll discuss this. The framework seems to correctly identify > the interface points, it's just that we choose the first step. Also see section 6 for a brief sermon from the authors on this :) > >> > - The arch. seems to require single managers (CE and > FE). Is there a > >> > need for an arbitration mechanism? I'm imagining multiple > >> blades (FEs) > >> > each with a "bus master" capability. I.e., N of M blades in an NE > >> > might be capable of being the FE manager. > > > The FE and CE managers are logical entities, and their > > function is one of initial configuration of FEs and CEs > > to be able to find each other (section 1, bottom of p3). > > So I'm not really sure I understand the bus master analogy. > > If there is a need for multiple managers they > > would probably need to arbitrate among themselves to decide > > who gets to give the FE or CE its initial config info. > > Chris will correct me if I'm wrong, but I think what is meant > here is if, for example, the FE manager is collocated with > an FE and there are many of such FEs in an NE, how do they > choose whose the one... I would think this would be part of > the Fi interface. I agree that the Fi interface is where I'd expect this to happen. I will check with the framework team to confirm this, then ask that they clarify it in the document as one of the interactions across Fi. > >> > - in 5.4 there appears to be no mechanism mentioned to > >> allow for the CE > >> > to block delivery of exceptional packets from the FE. Is > >> this therefore > >> > susceptible to DoS attack? > > > A DoS attack is a real possibility and the filtering > > mentioned in para 2 and 3 of 5.4 would be used to drop > > such packets when an attack is detected. In addition > > to this, the requirements say that a priority mechanism > > is necessary - this is needed to deal with a DoS attack > > when it first happens (before filters are installed) > > to allow prioritization of delivery of the packets > > that install the filter on the FE over delivery of > > the packets being "aimed at" the CE. See section 7 requirement > > 5 in the requirements. > > > I was unable to find any mention of this in the framework, > > but the framework is more about identifying architectural > > entities and functions than protocol details. Should this > > be included in the framework as well as the > > requirements/protocol proposals? > > I think this could be included as a function within the > general discussion on sending packets from FEs up to CEs. I will ask the authors to add text in 4.2.4 about this. In a nutshell it needs to say that Fp could be a vector used by adversaries for DoS attacks on the NE and that the filtering + prioritization of packets across Fp is how such attacks are combated. > >> > - allowing ospf hello and other portions of CE > functionality to be > >> > implemented by FEs appears to open the architecture so > wide it would > >> > be impossible to actually achieve the goal of > interchangeable operation. > > > I think a generic framework for offloading anything > > would indeed be too open ended (and would seem to me > > to be akin to defining some sort of virtual machine > > on the FE). My belief is that it would be necessary > > to tackle such things on a case-by-case basis, i.e. > > define a standard way to do OSPF hello offload for > > instance. If the problem is broken into manageable > > pieces then I think it is not too wide open. > > I share Chris'es concern here. I'd rather us not go try > to specify this, not in the first ver anyways... > > The same comment applicable to sections 5, 5.2, 5.6. Ok - I can see how advanced features such as OSPF offload add complexity better left for later versions. Not sure how the framework team will react but will let them know. I assume you don't mean all the other features described in 5 and 5.2, as many of them are fundamental parts of current router architecture. > >> > - does the architecture allow for non-stop forwarding? > Perhaps this > >> > should be directly addressed somewhere. > > > Good catch. Requirements doc section 5 (arch requirements) item 7 > > mentions this. Framework probably should as well. > > Section 4.3 talks a bit about this-- > > > The example in Figure 5 is used to illustrate what > happens when the > > association is broken and later re-established > again. Section 3.2 > > already explains what happens if CE1 fails and how > CE2 can take > > over. If no CE redundancy is provided, at the association > > establishment phase FEs need to be told what to do > in the case of CE > > failure. FEs may be told to stop packet processing > all together if > > its CE fails. Or, FEs may be told to continue > forwarding packets > > for a limited time even in the face of CE failure. > No matter what > > the instruction is, it needs to be part of the > configuration when > > the association is established. > > --but spelling this out may be a good idea. > Let's call it... hmmm... "graceful restart" for consistency :) A fine name! Will relay this. > > Note: I have responded to all of the above based on my > > personal understanding in an effort to get a prompt answer > > out. Is it ok for me to share the feedback directly with > > the authors and/or WG (and if so, should it be anonymized?) > > I don't really know what IETF procedure is on this. > > My recommendation would be to distill the comments on this list > and then bring an agreed upon set back to the WG. > > Here's some more comments from me: > > > 4.2.3. Steady-state Communication > > > |(My port is down, with port #.) > > 1|---------------------->| > > | | > > |(Route to this port instead...) > > > 2|<----------------------| > > | | > > "route to this port instead" seems wrong, the CE would need to Ack and > then come back with updated FIB entries. Yes - updated FIB is a more appropriate term. Will ask them to change it. > > 4.3. Association Re-establishment > [...] > > In the same example in Figure 5, assuming CE1 is > the working CE for > > the moment, what would happen if one of the FEs, > say FE1, leaves the > > NE temporarily? FE1 may voluntarily decide to leave the > > association. Or, FE1 may stop functioning simply > due to unexpected > > failure. In former case, CE1 receives a > "leave-association request" > > from FE1. In the latter, CE1 detects the failure > of FE1 by some > > other mean. In both cases, CE1 keeps a note of > such event from FE1 > > while continue commanding FE2. > > not just "note", but also inform the routing protocols that will need > to recalculate their route which will result in FIB updates. Agree. The language could be a bit more elegant as well. Will include in summary sent to authors. > > When FE1 decides to rejoin again, or > > when it is back up again from the failure, FE1 > needs to re-discover > > its master (CE). This can be achieved by several > means. It may re- > > enter the pre-association phase and get that > information from its FE > > manager. It may retrieve the previous CE > information from its > > cache, if it can validate the information freshness. Once it > > discovers its CE, it starts message exchange with > CE to re-establish > > the association just as outlined in Figure 9, with > the possible > > exception that it might be able to bypass the > transport of the > > complete initialization information. > > What about the security hand-shake though? Looks like they only refer to the security part of connection establishment through a direct reference in section 9 to the requirements doc, which covers this pretty thoroughly. Would be better if they talked about this in 4.2.2 and 4.2.4 as well, something along the lines of "establishment & re-establishment use appropriate security mechanisms for authentication as specified in section xx of [forces-req]". > > Suppose that FE1 still has its > > routing table and other state information from the > last association, > > instead of sending all the information again from > scratch, it can > > choose to use more efficient mechanism to re-sync > up the state with > > its CE. For example, a checksum of the state might > give a quick > > indication of whether or not the state is in-sync > with its CE. By > > comparing its state with CE first, it sends > information update only > > if it is needed. > > This would require corresponding mechanisms in the protocol itself, > right? Yes - I don't think the framework team means to mandate or preclude this, instead they are identifying the possibility that this sort of interaction may occur. Whether it is actually supported depends on the protocol selected for ForCES - they should probably say as much. > > 9. Security Considerations > > Ed: Move before refs? Hmm - I told them to do this already when they revved from 3 to 4. Will get this fixed once and for all. Thanks, David ------_=_NextPart_000_01C2E9DC.8FFBB570 Content-Type: message/rfc822 Content-Description: ForCES Framework-04 feedback from IESG & routing directorate To: "Lily Yang (Yang, Lily L)" , ram.dantu@utdallas.edu, todd.a.anderson@intel.com, forces@peach.ease.lsoft.com Subject: ForCES Framework-04 feedback from IESG & routing directorate Date: Thu, 13 Mar 2003 19:22:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain All, The IESG and the routing directorate have reviewed the ForCES framework. They had the following feedback on the draft. I assume that a new rev will be needed, after which it can be re-submitted to the IESG for publication as an RFC. 1) FE Virtualization A single physical FE might be partitioned into multiple virtual FEs. I think the requirements talks abut this but the framework doesn't explicitly call out how this is handled. I believe the approach being taken is one where each FE (where FE is defined as the slave endpoint of an Fp connection) is a single logical entity, and partitioning of a phyisical FE into multiple such entities is beyond the scope of Fp and is instead a pre-association phase issue. The framework should probably explicitly call this out and may also want to include a reference to the new informational RFC that just issued on requirements for accomplishing this from the GSMP wg. 2) Multiple FEMgrs The framework seems to say that there is one FE manager. It is possible that in some architectures each FE may have associated with it a FEMgr, thus necessitating selection of a single FEMgr among many. The rtg-dir questioned where such an interaction fits in the framework. Initial impression was that this would be a Fi interaction (if the FEMgrs are colocated with the FEs). Is this the right place, and if so, it should be documented. 3) DoS attacks 4.2.4 should explicitly call out that Fp could be a vector used by adversaries for DoS attacks on the NE and that the filtering + prioritization of packets across Fp is how such attacks are combatted. 4) OSPF Offload The ADs and the rtg-dir where both concerned that features such as OSPF offload, while useful, are probably so new that standardizing support for them is not practical in the first rev of forces. They suggested that support for that be removed from sections 5, 5.2, and 5.6. 5) Non-stop forwarding/Graceful restart Section 4.3 talks a bit about features needed for graceful restart, and requirements section 5 item 7 discusses this topic. The framework should explicitly spell out the need to support this and name it appropriately ("graceful restart") 6) Terminology issue: route vs. forward Section 4.2.3 shows a "route to this port instead" message going from CE to FE. Would be more accurate to indicate that the CE is downloading a new FIB to the FE here. 7) Vagueness of CE action in response to FE loss/reestablishment Section 4.3 says a CE would "note" the event of FE loss or reestablishment. Would be more informative to say that the CE would inform routing protocols of such an event, most likely prompting a reachability and SPF recalculation and associated downloading of new FIB and other calculations. 8) Security handshakes as part of association establishment and re-establishment Sections 4.2.2 and 4.2.4 should explicitly call out the fact that FEs and CEs will perform security handshakes as part of the association establishment/re-establishment interaction. 9) Cached state in re-establishment The end of section 4.3 mentions the possibility that a FE may reuse cached state to save Fp interactions during a connection re-establishment. While it is ok for the framework to call out such a possibility, it should also make it clear that whether such a feature is actually part of Fp will depend on protocol selection/definition. 10) Editorial changes Security considerations belongs before references. There are 8 bit characters in the draft that need to be excised. Cheers, David Putzolu (co-chair, ForCES) ------_=_NextPart_000_01C2E9DC.8FFBB570-- From rtg-dir-admin@ietf.org Fri Mar 14 20:04:22 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21682 for ; Fri, 14 Mar 2003 20:04:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F1K0O26276; Fri, 14 Mar 2003 20:20:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F1IxO26200 for ; Fri, 14 Mar 2003 20:18:59 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21650 for ; Fri, 14 Mar 2003 20:03:18 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 86B76204FCC; Fri, 14 Mar 2003 17:05:28 -0800 (PST) To: Alex Zinin Cc: Jeff Parker , rtg-dir@ietf.org, acee@redback.com, jenny@redback.com, riw@cisco.com, sprevidi@cisco.com, tli@procket.com Subject: Re: Questions on draft-ietf-isis-igp-p2p-over-lan-01.txt In-reply-to: Mail from Alex Zinin dated Thu, 13 Mar 2003 19:08:29 PST <25212453391.20030313190829@psg.com> Date: Fri, 14 Mar 2003 17:05:28 -0800 From: Naiming Shen Message-Id: <20030315010528.86B76204FCC@prattle.redback.com> Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Hi Jeff & Alex, thanks for the good questions regarding p2p-over-lan draft. ] ] > The draft is well written, and solves a real problem. ] ] > A) Are there any issues interoperating with 3-way handshake? ] > I would think this would be very helpful in catching ] > problems. But I assume the implementations have tried this. there should not be any interoperability issues with 3-way handshake. from isis point of view, this is just a "normal" p2p circuit. everything needs to be done for p2p circuit applies here. ] ] > B) I'm not sure what the issue is with MAC address gleening. ] > Is it the problem of getting the MAC address itself? If so, ] > did you consider adding a TLV to the hello that include your ] > MAC? ] ] > If the problem is populating the APR cache, perhaps ] > that is a requirement on the implementation. how to populate the local arp cache is an implementation issue, so it should not be a requirement. regular arp mechansim works perfectly when a data packet needs to go to this nexthop, it will get it through the arp request/reply. even if it's a p2p-over-lan unnumbered interface, as long as proxy arp is enabled(implementation can put filter/policy on this proxy arp), it still works perfectly. now in the case people want to populate the arp entry directly from isis, that's fine too(lets avoid talking about the layering violation here). one of the way is to gleen the mac address for the peer. since this packet is sent with the LAN(ethernet) format, the receiver does have the ways to "gleen" the source mac from it. how to "gleen" this into isis, then into arp, it's completely local implementation issue. ] ] > C) Although you have ruled this out in the algorithm you describe, ] > someone is bound to try dynamic configuration, by sending ] > both LAN and P2P packets over LAN links and prefering a P2P ] > response. You might point out that, say, this is a bad ] > idea as it behaves badly when two routers negotiate ] > a p2p link, to be joined by a third router. i think this again is an implementation issue. a node is welcome to try what you suggested: determine the p2p/lan status base on experiment, but they have to accept the fact that it may not be deterministic each time a circuit is up/down. i would think, also so far all the vendor's implementations, people want this to be a static/configured parameter. ] ] > D) Does a 3rd rogue router operating on a LAN and ] > "capturing" the adjacency from one or both of ] > the 2 'real' routers constitute a new Security ] > Threat? well, even it's a true LAN case, an additional rogue router can send out the duplicated src mac addresses, or proxy arp for all the packets over the LAN. this probably is not special to p2p-over-lan here. thanks. ] ] > - jeff parker ] > - axiowave networks ] - Naiming From rtg-dir-admin@ietf.org Sat Mar 15 07:44:12 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15083 for ; Sat, 15 Mar 2003 07:44:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FD03O05818; Sat, 15 Mar 2003 08:00:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FCxrO05767 for ; Sat, 15 Mar 2003 07:59:53 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15079 for ; Sat, 15 Mar 2003 07:43:58 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2FCjaSc023814; Sat, 15 Mar 2003 07:45:36 -0500 (EST) Received: from russpc (rtp-vpn2-406.cisco.com [10.82.241.150]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA09593; Sat, 15 Mar 2003 07:45:35 -0500 (EST) Date: Sat, 15 Mar 2003 07:45:05 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: Jeff Parker cc: rtg-dir@ietf.org Subject: Re: Questions on draft-ietf-isis-igp-p2p-over-lan-01.txt In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > The draft is well written, and solves a real problem. > A) Are there any issues interoperating with 3-way handshake? I would > think this would be very helpful in catching problems. But I assume the > implementations have tried this. There aren't any that I've seen in the work we've done with it. > B) I'm not sure what the issue is with MAC address gleening. Is it the > problem of getting the MAC address itself? If so, did you consider > adding a TLV to the hello that include your MAC? Yes--and we did consider that. On the other hand, we decided there are so many other good ways of getting this information, there didn't seem to be any point in adding such a tlv. > C) Although you have ruled this out in the algorithm you describe, > someone is bound to try dynamic configuration, by sending both LAN and > P2P packets over LAN links and prefering a P2P response. You might point > out that, say, this is a bad idea as it behaves badly when two routers > negotiate a p2p link, to be joined by a third router. That could be added, I think. > D) Does a 3rd rogue router operating on a LAN and "capturing" the > adjacency from one or both of the 2 'real' routers constitute a new > Security Threat? I don't think so, any more than on a "normal" network. :-) Russ -- riw@cisco.com CCIE <>< Grace Alone From rtg-dir-admin@ietf.org Sat Mar 15 18:05:56 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28413 for ; Sat, 15 Mar 2003 18:05:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FNM1O07739; Sat, 15 Mar 2003 18:22:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FNLMO07690 for ; Sat, 15 Mar 2003 18:21:22 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28332 for ; Sat, 15 Mar 2003 18:05:13 -0500 (EST) Message-ID: From: Jeff Parker To: "'Russ White'" Cc: rtg-dir@ietf.org Subject: RE: Questions on draft-ietf-isis-igp-p2p-over-lan-01.txt Date: Sat, 15 Mar 2003 18:07:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > > B) Is it the problem of getting the MAC address > > itself? If so, did you consider adding a TLV > > to the hello that include your MAC? > > Yes--and we did consider that. On the other hand, > we decided there are so many other good ways of > getting this information, there didn't seem to be > any point in adding such a tlv. My memory is that this topic takes up more space in the draft than any other. That often translates into lots of questions. But the techniques you describe certainly cover the problem. > > C) Although you have ruled this out in the > > algorithm you describe, someone is bound to > > try dynamic configuration, by sending > > both LAN and P2P packets ... > {Prohibiting that] could be added, I think. Great. > > D) Does a 3rd rogue router operating on a LAN and > > "capturing" the adjacency from one or both of the > > 2 'real' routers constitute a new Security Threat? > > I don't think so, any more than on a "normal" network. > > Russ Naiming Shen made the same observation. However, unlike proxy ARP or sending bogus packets, there is little evidence of the hack: No complaints from ARP, no traps from the fooled router. (I'll call this "the second router" with the attacker being the first.) The second router just drops the packets from the third router. The third router does have "evidence" that the configuration doesn't match the network, modulo the comments about point C. Perhaps we could add a notification that says something like "Evidence of 3rd P2P IS on P2P network" This could be edge-triggered so that it is only sent once per router per circuit. This should be sent by the second router as well as the third, as we may have just shut the third router out of the network, so it is unable to reach the management station. If a router wiht an adjacency gets a P2P hello that matches any appropriate filters (VLAN, matching area for L1 interfaces or routers) then it should register a notification before dropping the packet. I'd be happy to add such a notification to the MIB, should you decide to call for it here. - jeff parker From rtg-dir-admin@ietf.org Sat Mar 15 21:31:51 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02901 for ; Sat, 15 Mar 2003 21:31:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2m0O18477; Sat, 15 Mar 2003 21:48:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2G2lMO18460 for ; Sat, 15 Mar 2003 21:47:22 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02887 for ; Sat, 15 Mar 2003 21:31:10 -0500 (EST) Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 5EBB795B23; Sat, 15 Mar 2003 18:33:03 -0800 (PST) Message-ID: <3E73E362.3010802@redback.com> Date: Sat, 15 Mar 2003 21:37:22 -0500 From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Martin , Stefano Previdi , Brad Neal Cc: Routing Area Directorate Subject: Comments on Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As a member of the routing area directorate, I have reviewed the subject document. Here are my comments: Comments: 1. The last sentence of the abstract doesn't make sense. "Additionally, the information can be placed in LSPs that have TLVs as yet undefined, if this information is used to convey the same meaning in these future TLVs as it used in the currently defined TLVs". Suggested - "The administrative tag sub-TLVs may be used with with future TLVs as long as their semantics are preserved." 2. Section 5.2 - The value of the type is wrong - it should be 2 rather than 1. 3. Section 6 says the ordering of tags is not significant. However, the previous sections (5.1 and 5.2) say that an implementation may only consider the first tag. 4. Section 7 - List the requirements for receiving the new Sub-TLVs in this compliance section as well (even if they were stated previously). 5. Section 8 - The example talks about R2 associating tag 110 with property A and prefix 1.1.1.0/24. Yet in Figure 1, prefix 1.1.1.0/24 with property A is adjacent to R1 (which applies to me that R1 originate the prefix). Please fix either the example or the figure. Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): 1. The abstract contains references. The documents should be specified by name since the abstract can be excerpted. 2. Line 323 over 72 chars. Line 323 length is 74 Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April 3. Pages 2, 3, 4, and 5 have over 58 lines. -- Acee From rtg-dir-admin@ietf.org Sun Mar 16 18:40:34 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13289 for ; Sun, 16 Mar 2003 18:40:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNv9O02325; Sun, 16 Mar 2003 18:57:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GNsuO02260 for ; Sun, 16 Mar 2003 18:54:56 -0500 Received: from sith.maoz.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13244 for ; Sun, 16 Mar 2003 18:38:18 -0500 (EST) Received: (from dmm@localhost) by sith.maoz.com (8.12.8/8.12.8) id h2GNewDE012912; Sun, 16 Mar 2003 15:40:58 -0800 Date: Sun, 16 Mar 2003 15:40:58 -0800 From: David Meyer To: rtg-dir@ietf.org Cc: jparker@axiowave.com Subject: Comments on Message-ID: <20030316154058.A12903@sprint.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Overall, a well written and informative draft which does a good job of classifying where interoperability issues arise, and provides solutions to those situations. I have only 2 minor comments: I. Section 7, discussion of the Overload Bit: "An implementation MAY use the Overload Bit to signal that it is not ready to accept transit traffic." We might consider making this a little stronger, e.g., "SHOULD". II. Section 17, full copyright: "Copyright (C) The Internet Society (1997)." From rtg-dir-admin@ietf.org Tue Mar 18 17:23:29 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03030 for ; Tue, 18 Mar 2003 17:23:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMf2O26309; Tue, 18 Mar 2003 17:41:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IMeHO26279 for ; Tue, 18 Mar 2003 17:40:17 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03024 for ; Tue, 18 Mar 2003 17:22:41 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18vPVw-000JTm-00 for rtg-dir@ietf.org; Tue, 18 Mar 2003 14:24:56 -0800 Date: Tue, 18 Mar 2003 14:24:42 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <15894180424.20030318142442@psg.com> To: rtg-dir@ietf.org Subject: Re: RTG-DIR Dinner Tue 7pm In-Reply-To: <17220102445.20030305172709@psg.com> References: <17220102445.20030305172709@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Guys, we're meeting 7pm next to IETF registration. -- Alex Wednesday, March 5, 2003, 5:27:09 PM, Alex Zinin wrote: > Guys, FYI, I have us scheduled for a dinner on Tue 7pm. From rtg-dir-admin@ietf.org Thu Mar 20 14:07:34 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29802 for ; Thu, 20 Mar 2003 14:07:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJQ0O16964; Thu, 20 Mar 2003 14:26:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJPnO16941 for ; Thu, 20 Mar 2003 14:25:49 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29781 for ; Thu, 20 Mar 2003 14:07:20 -0500 (EST) Message-ID: From: Jeff Parker To: rtg-dir@ietf.org Cc: "'naiming@redback.com'" , "'ruwhite@cisco.com'" Subject: Comments draft-ietf-isis-igp-p2p-over-lan-01.txt Date: Thu, 20 Mar 2003 14:09:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > The draft is well written, and solves a real problem. > > - jeff parker Having my questions sorted out, here are some nits. 0) Use of 'ISIS' rather than 'IS-IS' throughout. 1) Page 2 "flooding of link-state information" "flooding link-state information" sounds better to me. 2) Page 2 "if there are more than two routers on the LAN media, [using DIS is better than a full mesh]" Isn't the break-even point above three? With three routers, the LAN version has 3 x 2 directed links, as does the p2p scheme, but the LAN version has an additional PNode LSP, so the p2p scheme is still better. 3) Page 6, line 1. Section 4 ("Broadcast/multicast/proprietary") in 4.4 has a heading, but no body, and thus looks like an error rather than a complete thought. Add something, even something as short as: "Other schemes include using a broadcast or multicast MAC address to forward packets, or proprietary schemes to forward packets." 4) Page 6, section 6, first line. "There is obvious advantage to use of this extension..." It is always hard to know what others find obvious. At the start of the second paragraph of the section, there is thumbnail recap of the advantages. Perhaps this sentence could be moved to the start of the section and the assertion dropped. 5) Section 6, first paragraph "The scalability impact is less of a concern..." The phrase is ambiguous, as we are contrasting two scheme, each of which has scaling advantages in some situations. Further, 'impact' could mean 'increase' or 'decrease'. If pressed, I would guess that this sentence means "If all the vLANs are withing a single OSPF area or IS-IS level, there is no particular advantage to using this scheme." - jeff parker From rtg-dir-admin@ietf.org Fri Mar 21 14:43:03 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24320 for ; Fri, 21 Mar 2003 14:43:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LK22O00630; Fri, 21 Mar 2003 15:02:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LK1TO00605 for ; Fri, 21 Mar 2003 15:01:29 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24314 for ; Fri, 21 Mar 2003 14:42:27 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id BED7922D4A9; Fri, 21 Mar 2003 11:44:44 -0800 (PST) To: Jeff Parker Cc: rtg-dir@ietf.org, "'ruwhite@cisco.com'" , acee@redback.com, jenny@redback.com, zinin@psg.com, sprevidi@cisco.com Subject: Re: Comments draft-ietf-isis-igp-p2p-over-lan-01.txt In-reply-to: Mail from Jeff Parker dated Thu, 20 Mar 2003 14:09:24 EST Date: Fri, 21 Mar 2003 11:44:44 -0800 From: Naiming Shen Message-Id: <20030321194444.BED7922D4A9@prattle.redback.com> Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Jeff, thanks for the comment. more inline. ] ] > The draft is well written, and solves a real problem. ] > ] > - jeff parker ] ] Having my questions sorted out, here are some nits. ] ] 0) Use of 'ISIS' rather than 'IS-IS' throughout. ] ] 1) Page 2 "flooding of link-state information" ] "flooding link-state information" sounds better to me. ] ] 2) Page 2 ] "if there are more than two routers on the LAN media, [using DIS is better ] than a full mesh]" ] ] Isn't the break-even point above three? With three routers, the LAN version ] has 3 x 2 directed links, as does the p2p scheme, but the LAN version has an ] additional PNode LSP, so the p2p scheme is still better. Well, this is not meant to count exact nodes on a LAN for the benefits. This scheme is only meant for two nodes on a LAN/vLAN. if you have more than two nodes: - you have to introduce vLAN into the picture - if you have three nodes, then it's possible also to have the 4th node, and 5th node later on, etc. so if the LAN/vLAN is not meant to use by only two nodes(in the case of back-to-back ethernet cabling, for example), then operators probably should not be bothered with this scheme. ] ] ] 3) Page 6, line 1. ] Section 4 ("Broadcast/multicast/proprietary") in 4.4 has a heading, but no ] body, and thus looks like an error rather than a complete thought. Add ] something, even something as short as: ] ] "Other schemes include using a broadcast or multicast MAC address to forward ] packets, or proprietary schemes to forward packets." ] ] ] 4) Page 6, section 6, first line. ] "There is obvious advantage to use of this extension..." It is always hard ] to know what others find obvious. ] At the start of the second paragraph of the section, there is thumbnail ] recap of the advantages. Perhaps this sentence could be moved to the start ] of the section and the assertion dropped. ] ] ] 5) Section 6, first paragraph ] "The scalability impact is less of a concern..." ] The phrase is ambiguous, as we are contrasting two scheme, each of which has ] scaling advantages in some situations. Further, 'impact' could mean ] 'increase' or 'decrease'. If pressed, I would guess that this sentence ] means ] "If all the vLANs are withing a single OSPF area or IS-IS level, there is no ] particular advantage to using this scheme." ] the above sentence didn't translate into the original intention of the paragraph. it was meant to say that: if people are running hierarchical level/area, then the link-state database may not be very large, such the operator may decide to run full-mesh p2p over the LAN if there is some other compelling reasons. one of the reason to run full-mesh p2p circuits over the LAN media would be to have fine control of link cost to each neighbor rather than use the single cost for all the neighbors over the LAN. we can change this into: "The negative scalability impact is ..."... thanks. ] - jeff parker - Naiming From rtg-dir-admin@ietf.org Fri Mar 21 15:37:53 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26840 for ; Fri, 21 Mar 2003 15:37:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LKupO04534; Fri, 21 Mar 2003 15:56:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LKnvO04249 for ; Fri, 21 Mar 2003 15:49:57 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26619 for ; Fri, 21 Mar 2003 15:30:57 -0500 (EST) Message-ID: From: Jeff Parker To: "'Naiming Shen'" Cc: rtg-dir@ietf.org, "'ruwhite@cisco.com'" , acee@redback.com, jenny@redback.com, zinin@psg.com, sprevidi@cisco.com Subject: RE: Comments draft-ietf-isis-igp-p2p-over-lan-01.txt Date: Fri, 21 Mar 2003 15:33:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > ] Isn't the break-even point above three? With three > ] routers, the LAN version has 3 x 2 directed links, > ] as does the p2p scheme, but the LAN version has an > ] additional PNode LSP, so the p2p scheme is still better. > > Well, this is not meant to count exact nodes on a LAN for > the benefits. This scheme is only meant for two nodes > on a LAN/vLAN. if you have more than two nodes: > > - you have to introduce vLAN into the picture > - if you have three nodes, then it's possible also to have > the 4th node, > and 5th node later on, etc. so if the LAN/vLAN is not meant to use > by only two nodes(in the case of back-to-back ethernet cabling, for > example), then operators probably should not be bothered with this > scheme. Naiming - I agree with your analysis, and I think the proposal is a good idea. However, the document makes a claim which I don't think is quite right. You don't want people to be able to use a mistake that has no bearing on your idea to discredit the whole draft. > ] "If all the vLANs are withing a single OSPF area or IS-IS > level, there is no > ] particular advantage to using this scheme." > > the above sentence didn't translate into the original intention of the > paragraph. ... > > if people are running hierarchical level/area, then the link-state > database may not be very large, such the operator may decide to > run full-mesh p2p over the LAN if there is some other compelling > reasons. > > one of the reason to run full-mesh p2p circuits over the LAN media > would be to have fine control of link cost to each neighbor rather > than use the single cost for all the neighbors over the LAN. > > we can change this into: "The negative scalability impact is ..."... > > - Naiming My problem was really with the terms "scalability" (you have just finished a discussion of places in which p2p is more scalable, vs places where bcast is more scalable) and "impact", which are ambiguous. A fuller statement, such as the paragraph you suggested, would be clearer. - jeff parker From rtg-dir-admin@ietf.org Fri Mar 21 17:59:59 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00319 for ; Fri, 21 Mar 2003 17:59:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNJ0O16255; Fri, 21 Mar 2003 18:19:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNIAO16234 for ; Fri, 21 Mar 2003 18:18:10 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00294 for ; Fri, 21 Mar 2003 17:59:06 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18wVVq-000L5A-00 for rtg-dir@ietf.org; Fri, 21 Mar 2003 15:01:22 -0800 Date: Fri, 21 Mar 2003 15:01:02 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <752516198.20030321150102@psg.com> To: rtg-dir@ietf.org Subject: rtg-dir += rcallon; /* Make sure nothing's left to take away... */ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- FYI, Ross Callon has been announced as a new member of the directorate. I have just added Ross to the list. Please welcome him. Regards. -- Alex From rtg-dir-admin@ietf.org Fri Mar 21 21:15:54 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05474 for ; Fri, 21 Mar 2003 21:15:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M2Z1O27555; Fri, 21 Mar 2003 21:35:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M2YTO27529 for ; Fri, 21 Mar 2003 21:34:29 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05470 for ; Fri, 21 Mar 2003 21:15:20 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18wYZl-000CUj-00 for rtg-dir@ietf.org; Fri, 21 Mar 2003 18:17:37 -0800 Date: Fri, 21 Mar 2003 18:17:13 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <3114286783.20030321181713@psg.com> To: rtg-dir@ietf.org Subject: Your impressions from the SF meeting MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- It would be very useful if we used this mailing list to exchange the impressions taken away from the meetings. If you liked something in a WG meeting or have a concern about what has happened or something left you with an uncomfortable feeling, or you have heard something you think all of us should know--send it here for a discussion. -- Alex From rtg-dir-admin@ietf.org Sat Mar 22 16:36:33 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05573 for ; Sat, 22 Mar 2003 16:36:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MLu1O07018; Sat, 22 Mar 2003 16:56:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MLtKO06936 for ; Sat, 22 Mar 2003 16:55:20 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05555 for ; Sat, 22 Mar 2003 16:35:49 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2MLc494054312; Sat, 22 Mar 2003 16:38:04 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2MLc0Np054305; Sat, 22 Mar 2003 16:38:01 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2MLbtY18735; Sat, 22 Mar 2003 16:37:55 -0500 (EST) Date: Sat, 22 Mar 2003 16:37:55 -0500 From: Jeffrey Haas To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: Your impressions from the SF meeting Message-ID: <20030322163755.A18728@nexthop.com> References: <3114286783.20030321181713@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3114286783.20030321181713@psg.com>; from zinin@psg.com on Fri, Mar 21, 2003 at 06:17:13PM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Fri, Mar 21, 2003 at 06:17:13PM -0800, Alex Zinin wrote: > It would be very useful if we used this mailing list to > exchange the impressions taken away from the meetings. A general impression that I took away from most of the meetings is that regardless of which working group I was attending, the security drum was banging quite loudly. rpsec will undoubtedly help the various working groups come to a more common and sane definition of security for their individual protocols. The trick, I believe, is to either convince the various WG's that they should make sure they have a foot in rpsec and get their issues dealt with in there, or make a strong case why their security issues are particular to their particular group. Another general observation is that the standardization drum was beating loudly. Work is being completed or tied up and strong progress is being made towards trying to bring things towards standardization. I would contrast this with several previous sessions of IETF that I've attended where most of the work seems to be targeted towards the discussion of new features. -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Tue Mar 25 19:55:59 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13266 for ; Tue, 25 Mar 2003 19:55:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q1H1O01776; Tue, 25 Mar 2003 20:17:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q1G8O01733 for ; Tue, 25 Mar 2003 20:16:08 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13262 for ; Tue, 25 Mar 2003 19:55:03 -0500 (EST) Received: by mail-blue.research.att.com (Postfix, from userid 612) id ACB6BB7D8A; Tue, 25 Mar 2003 19:59:34 -0500 (EST) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mail-blue.research.att.com (Postfix) with ESMTP id 6788AB7D83 for ; Tue, 25 Mar 2003 19:59:34 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h2Q0upVq021268 for ; Tue, 25 Mar 2003 19:56:51 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h2Q0vNe09393; Tue, 25 Mar 2003 16:57:23 -0800 (PST) Message-Id: <200303260057.h2Q0vNe09393@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-dir@ietf.org Subject: Making rtg-dir draft reviews public Date: Tue, 25 Mar 2003 16:57:22 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d X-Spam-Status: No, hits=-106.6 required=5.0 tests=BAYES_01,USER_IN_WHITELIST version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , We'd like to make rtg-dir draft reviews public via the datatracker. If you're sending review comments to the list, please explicitly mark discussions that you'd like to remain within the directorate. Our default with well-formed comments and questions like Jeff Parker's recent list on the isis p2p draft will be to place them in the datatracker. The default will be to include the email address of the originator; if you want to provide comments but not be contacted by the general IETF public in response to them, please make a note of it in your message and we will anonymize the comments. However, our preferred mode is fully public and open. Thanks, Bill & Alex From rtg-dir-admin@ietf.org Tue Mar 25 20:33:01 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14142 for ; Tue, 25 Mar 2003 20:33:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q1s1O03939; Tue, 25 Mar 2003 20:54:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q1rKO03893 for ; Tue, 25 Mar 2003 20:53:20 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14123 for ; Tue, 25 Mar 2003 20:32:17 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18xzoH-000Hx3-00; Tue, 25 Mar 2003 17:34:33 -0800 Date: Tue, 25 Mar 2003 17:34:15 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1718503507.20030325173415@psg.com> To: Jeff Parker CC: rtg-dir@ietf.org Subject: draft-ietf-isis-iso-interoperable-00.txt and 10589:2002 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff, Quick question: JTC1 recently published the 2002 rev of 10589. Did you happen to check if the stuff in the draft is affected by the changes? -- Alex From rtg-dir-admin@ietf.org Wed Mar 26 10:23:43 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00533 for ; Wed, 26 Mar 2003 10:23:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QFj0O06102; Wed, 26 Mar 2003 10:45:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QFiSO06063 for ; Wed, 26 Mar 2003 10:44:28 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00512 for ; Wed, 26 Mar 2003 10:23:07 -0500 (EST) Message-ID: From: Jeff Parker To: "'Alex Zinin'" Cc: rtg-dir@ietf.org Subject: RE: draft-ietf-isis-iso-interoperable-00.txt and 10589:2002 Date: Wed, 26 Mar 2003 10:25:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > Jeff, > > Quick question: JTC1 recently published the 2002 rev of 10589. Did > you happen to check if the stuff in the draft is affected by the > changes? > > -- > Alex I've looked in my files: I have a July 2001 revision, but I can't find a 2002, so I must not have reviewed it. Can you send me a link? Les G. did review the drafts very closely, but I wouldn't hold him responsible for any omissions. - jeff parker From rtg-dir-admin@ietf.org Wed Mar 26 11:21:41 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02522 for ; Wed, 26 Mar 2003 11:21:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGh0O10820; Wed, 26 Mar 2003 11:43:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGgUO10781 for ; Wed, 26 Mar 2003 11:42:30 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02519 for ; Wed, 26 Mar 2003 11:21:07 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2QGMq4c003456; Wed, 26 Mar 2003 08:22:52 -0800 (PST) Received: from mshand-w2k.cisco.com (rtp-vpn1-78.cisco.com [10.82.224.78]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA19172; Wed, 26 Mar 2003 16:22:50 GMT Message-Id: <4.3.2.7.2.20030326161254.02c06da8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Mar 2003 16:21:41 +0000 To: Jeff Parker From: mike shand Subject: RE: draft-ietf-isis-iso-interoperable-00.txt and 10589:2002 Cc: "'Alex Zinin'" , rtg-dir@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Jeff, I THINK there were only trivial editorial changes between the 2001 version (2001-7-4) and the final published 2002 version (2002-11-15). The most noticeable change is that the 2002 version is in single column format which makes it tricky to spot changes:-) However, it is probably worth checking with the editor (Micah Bartell). I can send you a .pdf of the 2002 version if that would be any help. Mike At 10:25 26/03/2003 -0500, Jeff Parker wrote: > > Jeff, > > > > Quick question: JTC1 recently published the 2002 rev of 10589. Did > > you happen to check if the stuff in the draft is affected by the > > changes? > > > > -- > > Alex > >I've looked in my files: I have a July 2001 revision, but I can't >find a 2002, so I must not have reviewed it. Can you send me a link? > >Les G. did review the drafts very closely, but I wouldn't hold him >responsible for any omissions. > >- jeff parker From rtg-dir-admin@ietf.org Wed Mar 26 11:27:41 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02647 for ; Wed, 26 Mar 2003 11:27:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGn1O11187; Wed, 26 Mar 2003 11:49:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QGmHO11142 for ; Wed, 26 Mar 2003 11:48:17 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02640 for ; Wed, 26 Mar 2003 11:26:55 -0500 (EST) Message-ID: From: Jeff Parker To: "'mike shand'" Cc: rtg-dir@ietf.org Subject: RE: draft-ietf-isis-iso-interoperable-00.txt and 10589:2002 Date: Wed, 26 Mar 2003 11:29:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > Jeff, > I can send you a .pdf of the 2002 > version if that would be any help. > > Mike Mike - That would help. I can go over the sections we cite and see if there are any conflicts. - jeff parker From rtg-dir-admin@ietf.org Wed Mar 26 11:44:39 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03425 for ; Wed, 26 Mar 2003 11:44:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QH60O12588; Wed, 26 Mar 2003 12:06:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QH59O12544 for ; Wed, 26 Mar 2003 12:05:09 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03395 for ; Wed, 26 Mar 2003 11:43:46 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18yE2N-000PQo-00; Wed, 26 Mar 2003 08:46:03 -0800 Date: Wed, 26 Mar 2003 08:45:48 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <16848952169.20030326084548@psg.com> To: Jeff Parker CC: rtg-dir@ietf.org Subject: Re: draft-ietf-isis-iso-interoperable-00.txt and 10589:2002 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff, Here's the URL where you can find it http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm??Redirect=1 -- Alex Wednesday, March 26, 2003, 7:25:22 AM, Jeff Parker wrote: >> Jeff, >> >> Quick question: JTC1 recently published the 2002 rev of 10589. Did >> you happen to check if the stuff in the draft is affected by the >> changes? >> >> -- >> Alex > I've looked in my files: I have a July 2001 revision, but I can't > find a 2002, so I must not have reviewed it. Can you send me a link? > Les G. did review the drafts very closely, but I wouldn't hold him > responsible for any omissions. > - jeff parker From rtg-dir-admin@ietf.org Thu Mar 27 00:49:26 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04350 for ; Thu, 27 Mar 2003 00:49:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R6B1O08228; Thu, 27 Mar 2003 01:11:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R6AsO08214 for ; Thu, 27 Mar 2003 01:10:54 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04343 for ; Thu, 27 Mar 2003 00:49:13 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18yQIW-0005Pv-00; Wed, 26 Mar 2003 21:51:32 -0800 Date: Wed, 26 Mar 2003 21:51:13 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <19096076871.20030326215113@psg.com> To: "Putzolu, David" CC: rtg-dir@ietf.org, "Patrick Droz (dro@zurich.ibm.com)" , Bill Fenner Subject: Re: ForCES Framework submission for AD Review In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David, > Hi Alex/rtg-dir - detailed responses inline. I have attached > a proposed summary of the IESG and rtg-dir questions see my comment to the summary > and feedback for sending to the framework team and to > the WG at large. Please review and tell me if the > attached summary and responses below are appropriate > and accurate. > Thanks, > David OK, please see inline below. >> I think this is what Chris meant. >> I have no strong opinion on this topic, and would not >> have a problem with ForCES addressing the simpler problem >> first. > I will ask the framework authors to explicitly call out > the fact that each FE is a single logical entity, and > that partitioning a physical FE into many virtual FEs > is something that is out-of-scope of ForCES and is > something that happens through other mechanisms. Fine. > An > informational RFC just issued on requirements for doing > this, I'll have them reference that. Did you mean the requirements draft (rather than RFC) here? >> I think this could be included as a function within the >> general discussion on sending packets from FEs up to CEs. > I will ask the authors to add text in 4.2.4 about this. > In a nutshell it needs to say that Fp could be a vector > used by adversaries for DoS attacks on the NE and > that the filtering + prioritization of packets across > Fp is how such attacks are combated. Fp itself is one, the CPU is another, so rate-limiting is also needed. >> I share Chris'es concern here. I'd rather us not go try >> to specify this, not in the first ver anyways... >> >> The same comment applicable to sections 5, 5.2, 5.6. > Ok - I can see how advanced features such as OSPF offload > add complexity better left for later versions. Not sure > how the framework team will react but will let them know. > I assume you don't mean all the other features described in > 5 and 5.2, as many of them are fundamental parts of current > router architecture. As far as I remember, others were fine. I was somewhat concerned though when I saw things like "we can implement it at both CE and FE"... Take ARP, for instance. Usually the CE needs to know IP-to-MAC mapping because it needs to provide complete FIB to the FE... Whether ARP is implemented at the CE or the FE level will affect this process... What was the thinking here? >> > When FE1 decides to rejoin again, or >> > when it is back up again from the failure, FE1 >> needs to re-discover >> > its master (CE). This can be achieved by several >> means. It may re- >> > enter the pre-association phase and get that >> information from its FE >> > manager. It may retrieve the previous CE >> information from its >> > cache, if it can validate the information freshness. Once it >> > discovers its CE, it starts message exchange with >> CE to re-establish >> > the association just as outlined in Figure 9, with >> the possible >> > exception that it might be able to bypass the >> transport of the >> > complete initialization information. >> >> What about the security hand-shake though? > Looks like they only refer to the security part of > connection establishment through a direct reference > in section 9 to the requirements doc, which covers > this pretty thoroughly. Would be better if they talked > about this in 4.2.2 and 4.2.4 as well, something along > the lines of "establishment & re-establishment use > appropriate security mechanisms for authentication as > specified in section xx of [forces-req]". Right, but please make sure it does not sound like they have to specify the security handshake itself. >> > Suppose that FE1 still has its >> > routing table and other state information from the >> last association, >> > instead of sending all the information again from >> scratch, it can >> > choose to use more efficient mechanism to re-sync >> up the state with >> > its CE. For example, a checksum of the state might >> give a quick >> > indication of whether or not the state is in-sync >> with its CE. By >> > comparing its state with CE first, it sends >> information update only >> > if it is needed. >> >> This would require corresponding mechanisms in the protocol itself, >> right? > Yes - I don't think the framework team means to mandate or > preclude this, instead they are identifying the possibility > that this sort of interaction may occur. Whether it is > actually supported depends on the protocol selected for ForCES - > they should probably say as much. Right. Plus, I would remove that example with the checksum--one could argue against relying on the checksum, because it does not give 100% accuracy and a single missing route in the table may be a huge problem. More comments on your proposed summary below > All, > > The IESG and the routing directorate have reviewed the ForCES > framework. This should be "the AD and the routing directorate"--the document has not been to the IESG yet. > They had the following feedback on the draft. > I assume that a new rev will be needed, after which it can > be re-submitted to the IESG for publication as an RFC. > > > 1) FE Virtualization > > A single physical FE might be partitioned into multiple virtual > FEs. I think the requirements talks abut this but the framework > doesn't explicitly call out how this is handled. I believe the > approach being taken is one where each FE (where FE is defined as > the slave endpoint of an Fp connection) is a single logical > entity, and partitioning of a phyisical FE into multiple such > entities is beyond the scope of Fp and is instead a pre-association > phase issue. The framework should probably explicitly call this > out and may also want to include a reference to the new > informational RFC that just issued on requirements for > accomplishing this from the GSMP wg. > > 2) Multiple FEMgrs > > The framework seems to say that there is one FE manager. > It is possible that in some architectures each FE may have > associated with it a FEMgr, thus necessitating selection > of a single FEMgr among many. The rtg-dir questioned > where such an interaction fits in the framework. Initial > impression was that this would be a Fi interaction (if > the FEMgrs are colocated with the FEs). Is this the > right place, and if so, it should be documented. > > 3) DoS attacks > > 4.2.4 should explicitly call out that Fp could be a vector > used by adversaries for DoS attacks on the NE and > that the filtering + prioritization of packets across > Fp is how such attacks are combatted. + CPU + rate limiting... I don't know how much we can say about the protocol itself here, but the FEs should be able to do this, plus ideally even have separated resources for different types of traffic, e.g. different queues for L2 keepalives, IGPs, BGP, and ICMP+stuff. We should also admit, that this won't solve all problems, as the attacker can still exhaust the resources if it floods faked packets. > 4) OSPF Offload > > The ADs and the rtg-dir where both concerned that features > such as OSPF offload, while useful, are probably so new > that standardizing support for them is not practical in > the first rev of forces. They suggested that support for > that be removed from sections 5, 5.2, and 5.6. > > 5) Non-stop forwarding/Graceful restart > > Section 4.3 talks a bit about features needed for graceful > restart, and requirements section 5 item 7 discusses this > topic. The framework should explicitly spell out the need > to support this and name it appropriately ("graceful restart") plus also provide the framework on how this will be done. > 6) Terminology issue: route vs. forward > > Section 4.2.3 shows a "route to this port instead" message > going from CE to FE. Would be more accurate to indicate > that the CE is downloading a new FIB to the FE here. > > 7) Vagueness of CE action in response to FE loss/reestablishment > > Section 4.3 says a CE would "note" the event of FE loss or > reestablishment. Would be more informative to say that the > CE would inform routing protocols of such an event, most > likely prompting a reachability and SPF recalculation and > associated downloading of new FIB and other calculations. > > 8) Security handshakes as part of association establishment > and re-establishment > > Sections 4.2.2 and 4.2.4 should explicitly call out the > fact that FEs and CEs will perform security handshakes > as part of the association establishment/re-establishment > interaction. This may sound like the handshake is part of the protocol. I don't think this is the intention. > 9) Cached state in re-establishment > > The end of section 4.3 mentions the possibility that a FE > may reuse cached state to save Fp interactions during a > connection re-establishment. While it is ok for the > framework to call out such a possibility, it should also > make it clear that whether such a feature is actually part > of Fp will depend on protocol selection/definition. I would also add the following (pls feel free to discuss this before shipping to the WG): Security Considerations This is where the IESG will expect the security analysis of the framework and outlining the actual security mechanisms that should be present in the architecture. The document should provide vulnerability analysis of the framework, and how identified vulnerabilities should be covered. Alex > 10) Editorial changes > > Security considerations belongs before references. > There are 8 bit characters in the draft that need to be excised. > Cheers, > David Putzolu (co-chair, ForCES) From rtg-dir-admin@ietf.org Fri Mar 28 11:31:42 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06206 for ; Fri, 28 Mar 2003 11:31:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SGs1O18969; Fri, 28 Mar 2003 11:54:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SGrdO18936 for ; Fri, 28 Mar 2003 11:53:39 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06202 for ; Fri, 28 Mar 2003 11:31:17 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18ywnU-000GGf-00 for rtg-dir@ietf.org; Fri, 28 Mar 2003 08:33:40 -0800 Date: Fri, 28 Mar 2003 08:33:26 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <26221010025.20030328083326@psg.com> To: rtg-dir@ietf.org Subject: Directorate charter MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- Please find below the first rev of the directorate charter. We'd like to post it on the area's web site to clarify the functions it performs. Comments welcome. -- Alex The notion of a directorate is defined in RFC 2418 as follows: In many areas, the Area Directors have formed an advisory group or directorate. These comprise experienced members of the IETF and the technical community represented by the area. The specific name and the details of the role for each group differ from area to area, but the primary intent is that these groups assist the Area Director(s), e.g., with the review of specifications produced in the area. The Routing Area Directorate is an advisory group of routing experts selected by the Area Directors. The Directorate is not just a group of all WG chairs in the Routing area--many directorate members do not have enough time or desire to lead a WG, yet participate in the Directorate because of their deep expertise in Internet routing. The Area Directors use the feedback from the Directorate while making decisions on a range of topics related to the IETF Routing area. Specifically, the Directorate is involved in the following activities: 1. Review of the documents submitted to the IESG from the WGs within the Routing area. To minimize the additional delay, the WG chairs are encouraged to forward the WG Last Call announcements to the Directorate so that the directorate review happens during the Last Call. Otherwise, the directorate review will happen as part of the AD-review process. 2. Technical advisory function. Members of the Directorate may be asked to provide consultation to or (more formally) serve as Technical Advisors in WGs within the Routing area, as well as other areas. 3. Review of new WG and existing WG rechartering proposals. When deemed necessary, the ADs will consult the Directorate regarding the proposals for creation of a new WG, or when an existing WG is being rechartered. 4. Review of documents under IESG review. When deemed necessary, the ADs will consult the Directorate while forming their opinion on the documents being reviewed within the IESG. The Routing Area Directorate can be reached at rtg-dir@ietf.org. The Directorate currently includes the following advisors: Acee Lindem (acee@redback.com) Alvaro Retana (aretana@cisco.com) Chris Hopps (chopps@procket.com) Dave Meyer (dmm@sprint.net) Jeff Haas (jhaas@nexthop.com) Jeff Parker (jparker@axiowave.com) Mark Handley (mjh@icir.org) Mike Shand (mshand@cisco.com) Tony Przygienda (prz@net4u.ch) Radia Perlman (Radia.Perlman@sun.com) Rohit Dube (rohit@xebeo.com) Ross Callon (rcallon@juniper.net) Russ White (ruwhite@cisco.com) Sue Hares (shares@nexthop.com) From rtg-dir-admin@ietf.org Sat Mar 29 00:27:29 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02057 for ; Sat, 29 Mar 2003 00:27:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2T5o4O06699; Sat, 29 Mar 2003 00:50:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2T5njO06658 for ; Sat, 29 Mar 2003 00:49:45 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02053 for ; Sat, 29 Mar 2003 00:27:07 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18z8uG-000H42-00; Fri, 28 Mar 2003 21:29:28 -0800 Date: Fri, 28 Mar 2003 21:29:09 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <18128531986.20030328212909@psg.com> To: Jeff Parker CC: rtg-dir@ietf.org Subject: Re: draft-ietf-isis-iso-interoperable-00.txt and 10589:2002 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff, Any news on this one? -- Alex Wednesday, March 26, 2003, 7:25:22 AM, Jeff Parker wrote: >> Jeff, >> >> Quick question: JTC1 recently published the 2002 rev of 10589. Did >> you happen to check if the stuff in the draft is affected by the >> changes? >> >> -- >> Alex > I've looked in my files: I have a July 2001 revision, but I can't > find a 2002, so I must not have reviewed it. Can you send me a link? > Les G. did review the drafts very closely, but I wouldn't hold him > responsible for any omissions. > - jeff parker From rtg-dir-admin@ietf.org Sat Mar 29 11:33:13 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24968 for ; Sat, 29 Mar 2003 11:33:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2TGu2O19488; Sat, 29 Mar 2003 11:56:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2TGtoO19444 for ; Sat, 29 Mar 2003 11:55:50 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24959 for ; Sat, 29 Mar 2003 11:32:59 -0500 (EST) Message-ID: From: Jeff Parker To: "'Alex Zinin'" Cc: rtg-dir@ietf.org Subject: RE: draft-ietf-isis-iso-interoperable-00.txt and 10589:2002 Date: Sat, 29 Mar 2003 11:35:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > Wednesday, March 26, 2003, 7:25:22 AM, Jeff Parker wrote: > >> Jeff, > >> > >> Quick question: JTC1 recently published the 2002 rev of 10589. Did > >> you happen to check if the stuff in the draft is affected by the > >> changes? > >> > >> -- > >> Alex Alex - I have the 2002 revision: I have not sat down to review. Will try to get to it in the next few days. - jeff parker From rtg-dir-admin@ietf.org Sat Mar 29 13:57:07 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27116 for ; Sat, 29 Mar 2003 13:57:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2TJK0O28188; Sat, 29 Mar 2003 14:20:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2TJJtO28154 for ; Sat, 29 Mar 2003 14:19:55 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27111 for ; Sat, 29 Mar 2003 13:56:55 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18zLXz-0006jH-00 for rtg-dir@ietf.org; Sat, 29 Mar 2003 10:59:19 -0800 Date: Sat, 29 Mar 2003 10:59:03 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <2077125700.20030329105903@psg.com> To: rtg-dir@ietf.org Subject: Under IESG review: draft-coene-sctp-multihome-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- Comments on this one would be appreciated... It has "Interaction with routing"... -- Alex From rtg-dir-admin@ietf.org Sun Mar 30 00:46:59 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09330 for ; Sun, 30 Mar 2003 00:46:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2U6A3O31723; Sun, 30 Mar 2003 01:10:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2U69FO31681 for ; Sun, 30 Mar 2003 01:09:15 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09326 for ; Sun, 30 Mar 2003 00:46:08 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18zVgA-000C73-00; Sat, 29 Mar 2003 21:48:26 -0800 Date: Sat, 29 Mar 2003 21:48:12 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <79116074676.20030329214812@psg.com> To: Jeff Parker CC: Tony Li , prz@net4u.ch, rtg-dir@ietf.org Subject: AD-review for draft-ietf-isis-*-interoperable MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff, I have one real comment on the two drafts plus some nits. Security: > 14. Security Implications Nit: above should be "Security Considerations" in both drafts > The clarifications in this document do not raise any new security > concerns, as there is no change in the underlying protocol described > in ISO 10589 [1] and RFC 1195 [2]. Section 6.2 of the IP document essentially deprecates TLV 133 and tells to use TLV 10 for authentication. This should be mentioned in this section. It would also be a good idea to go through every section in both documents and see if what's described there changes the security aspects of the protocol, i.e., creates new or removes old attack possibilities. I would also remove words saying that the underlying protocol is not changed. Nits: > 2. Abstract for both docs, the abstract should not have any refs in it. Just remove "[?]" from it. > 15. References You need to specify whether references are normative or informative. My guess for the IP doc would be that refs 1--5 are normative and [6] is informative. What you should do is have two sections: 15. Normative References 16. Informative References Some more comments have been provided during the rtg-dir review and are available at https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=9699&rfc_flag=0 (Jeff has gotten them directly from Mike) -- Alex From rtg-dir-admin@ietf.org Sun Mar 30 01:03:56 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09495 for ; Sun, 30 Mar 2003 01:03:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2U6R1O32142; Sun, 30 Mar 2003 01:27:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2U6Q3O32114 for ; Sun, 30 Mar 2003 01:26:03 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09484 for ; Sun, 30 Mar 2003 01:02:55 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18zVwV-000CqM-00; Sat, 29 Mar 2003 22:05:19 -0800 Date: Sat, 29 Mar 2003 22:05:05 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <13117088053.20030329220505@psg.com> To: Routing Area Directorate CC: Acee Lindem , Brad Neal , Christian Martin , Stefano Previdi , Tony Li , Tony Przygienda Subject: Re: Comments on In-Reply-To: <3E73E362.3010802@redback.com> References: <3E73E362.3010802@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I noticed that the WG chairs have not been CC'ed on this one. I'll be reviewing this draft early next week. Thanks, Acee. -- Alex Saturday, March 15, 2003, 6:37:22 PM, Acee Lindem wrote: > As a member of the routing area directorate, I have reviewed the > subject document. Here are my comments: > Comments: > 1. The last sentence of the abstract doesn't make sense. "Additionally, > the information can be placed in LSPs that have TLVs as yet > undefined, if this information is used to convey the same > meaning in these future TLVs as it used in the currently defined > TLVs". Suggested - "The administrative tag sub-TLVs may be used with > with future TLVs as long as their semantics are preserved." > 2. Section 5.2 - The value of the type is wrong - it should be 2 rather > than 1. > 3. Section 6 says the ordering of tags is not significant. However, the > previous sections (5.1 and 5.2) say that an implementation may only > consider the first tag. > 4. Section 7 - List the requirements for receiving the new Sub-TLVs in > this compliance section as well (even if they were stated previously). > 5. Section 8 - The example talks about R2 associating tag 110 with property > A and prefix 1.1.1.0/24. Yet in Figure 1, prefix 1.1.1.0/24 with property > A is adjacent to R1 (which applies to me that R1 originate the prefix). > Please fix either the example or the figure. > Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): > 1. The abstract contains references. The documents should be specified > by name since the abstract can be excerpted. > 2. Line 323 over 72 chars. > Line 323 length is 74 > Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April > 3. Pages 2, 3, 4, and 5 have over 58 lines. From rtg-dir-admin@ietf.org Mon Mar 31 19:10:06 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03897 for ; Mon, 31 Mar 2003 19:10:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h310Y2K30780; Mon, 31 Mar 2003 19:34:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h310XMK30727 for ; Mon, 31 Mar 2003 19:33:22 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03864 for ; Mon, 31 Mar 2003 19:09:23 -0500 (EST) Message-ID: From: Jeff Parker To: "'Alex Zinin'" Cc: Tony Li , prz@net4u.ch, rtg-dir@ietf.org Subject: RE: AD-review for draft-ietf-isis-*-interoperable Date: Mon, 31 Mar 2003 19:11:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Alex - I have gone over the drafts, looking up the references in the 2002 draft of 10589. There are more nits that I would like to fix (mostly adding citations for things I couldn't find references to) but there are no significant changes. The only security issue I saw this time was the one you pointed out: TLV 10 vs 133. My take on the normative issue is that in the IP draft, only sections 6.1 and 6.2 (TLV 131 and 133 depricated) are normative. In contrast, there are a number of issues in the ISO version that are 'normative' - but we can't call them that. I will try to rev the drafts later this week, and will resend to the 'update' list formed for the draft. - jeff parker From rtg-dir-admin@ietf.org Mon Mar 31 20:49:02 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06615 for ; Mon, 31 Mar 2003 20:49:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h312D0K05087; Mon, 31 Mar 2003 21:13:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h312CLK05064 for ; Mon, 31 Mar 2003 21:12:21 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06585 for ; Mon, 31 Mar 2003 20:48:19 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 190Av9-0007e5-00; Mon, 31 Mar 2003 17:50:39 -0800 Date: Mon, 31 Mar 2003 17:50:04 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <3274586684.20030331175004@psg.com> To: Jeff Parker CC: Tony Li , prz@net4u.ch, rtg-dir@ietf.org Subject: Re: AD-review for draft-ietf-isis-*-interoperable In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff, Monday, March 31, 2003, 4:11:24 PM, Jeff Parker wrote: > Alex - > I have gone over the drafts, looking up the references in the 2002 > draft of 10589. There are more nits that I would like to fix (mostly adding > citations for things I couldn't find references to) but there are no > significant changes. OK > The only security issue I saw this time was the one you pointed out: > TLV 10 vs 133. I didn't think about this in detail, but it seems that no purging invalid LSPs may have a security aspect too.. > My take on the normative issue is that in the IP draft, only > sections 6.1 and 6.2 (TLV 131 and 133 depricated) are normative. In > contrast, there are a number of issues in the ISO version that are > 'normative' - but we can't call them that. Oh, the comment I had was about the references, not about the text itself... or am I missing your point? > I will try to rev the drafts later this week, and will resend to the > 'update' list formed for the draft. Great. I will start the IETF LC then. Thanks. Alex From rtg-dir-admin@ietf.org Tue Apr 1 03:18:57 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01014 for ; Tue, 1 Apr 2003 03:18:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h318h4K09078; Tue, 1 Apr 2003 03:43:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h318goK09061 for ; Tue, 1 Apr 2003 03:42:50 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01011 for ; Tue, 1 Apr 2003 03:18:41 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id D6BB934435; Mon, 31 Mar 2003 23:34:29 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h318L6YB019690; Tue, 1 Apr 2003 00:21:06 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: AD-review for draft-ietf-isis-*-interoperable Date: Tue, 1 Apr 2003 00:21:05 -0800 Message-ID: Thread-Topic: AD-review for draft-ietf-isis-*-interoperable Thread-Index: AcL38R4RwDN5/u0mQWGqOLDKIGLxAQANlUWA From: "Tony Li" To: "Alex Zinin" , "Jeff Parker" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h318goK09062 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit | > The only security issue I saw this time was the | one you pointed out: | > TLV 10 vs 133. | | I didn't think about this in detail, but it seems that no purging | invalid LSPs may have a security aspect too.. Purging invalid LSPs are a trivial way to turn your own network into its own distributed DoS self-attack system. On the flip, not purging them and just ignoring them just wastes a bit of memory. Tony From mailman-admin@ietf.org Tue Apr 1 09:18:32 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12618 for ; Tue, 1 Apr 2003 09:18:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31EgnK14263 for ; Tue, 1 Apr 2003 09:42:49 -0500 Date: Tue, 01 Apr 2003 09:42:49 -0500 Message-ID: <20030401144249.29326.20581.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rtg-dir-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rtg-dir-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rtg-dir-archive@ietf.org: List Password // URL ---- -------- rtg-dir@ietf.org utnefe https://www1.ietf.org/mailman/options/rtg-dir/rtg-dir-archive%40ietf.org From rtg-dir-admin@ietf.org Tue Apr 1 13:42:40 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07560 for ; Tue, 1 Apr 2003 13:42:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31J71K08650; Tue, 1 Apr 2003 14:07:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31J55K08420 for ; Tue, 1 Apr 2003 14:05:05 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07480 for ; Tue, 1 Apr 2003 13:40:42 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 190Qit-000OQ9-00; Tue, 01 Apr 2003 10:43:03 -0800 Date: Tue, 1 Apr 2003 10:42:03 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <325631557.20030401104203@psg.com> To: "Tony Li" CC: "Jeff Parker" , prz@net4u.ch, rtg-dir@ietf.org Subject: Re: AD-review for draft-ietf-isis-*-interoperable In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tony, > | I didn't think about this in detail, but it seems that no purging > | invalid LSPs may have a security aspect too.. > Purging invalid LSPs are a trivial way to turn your own network into > its own distributed DoS self-attack system. Yes, persistent errors in the originating IS would be a valid scenario, which, if I'm not mistaken, was observed in the wild and lead to changes in the code. An insider attacker originating corrupted LSPs would be another, I guess... Alex > On the flip, not purging them and just ignoring them just wastes a bit > of memory. > Tony From rtg-dir-admin@ietf.org Tue Apr 1 14:47:38 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10444 for ; Tue, 1 Apr 2003 14:47:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31KC1K15103; Tue, 1 Apr 2003 15:12:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31KBTK15076 for ; Tue, 1 Apr 2003 15:11:29 -0500 Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10435 for ; Tue, 1 Apr 2003 14:47:04 -0500 (EST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10966 for ; Tue, 1 Apr 2003 12:49:31 -0700 (MST) Received: from sr1-ubur-05 (sr1-ubur-05 [129.148.9.84]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h31JnV024997 for ; Tue, 1 Apr 2003 14:49:31 -0500 (EST) Message-Id: <200304011949.h31JnV024997@sydney.East.Sun.COM> Date: Tue, 1 Apr 2003 14:49:31 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: AD-review for draft-ietf-isis-*-interoperable To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 49KMwnQsavjPXxzbmoSwhQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , From: "Tony Li" Purging invalid LSPs are a trivial way to turn your own network into its own distributed DoS self-attack system. On the flip, not purging them and just ignoring them just wastes a bit of memory. Tony From my distant memory...I believe I introduced the concept of purging other routers' LSPs. My reason was worry about a router R1 having a very fast clock relative to the other routers. In that case, R1 might purge R2's LSP long before anyone else does. And then R1 would be calculating paths on a different LSP database than the other routers. So it seemed like a good idea to have all routers purge LSPs at the clock of the fastest router, so their LSP databases would be the same. I have to admit I don't have a copy of 10589, so I'll ask a stupid question here...I'm assuming even if you don't synchronize the purge, that if R1's age on R2's LSP gets to 0 that R1 would throw away R2's LSP? Or has it changed to be that only R2 gets to purge its own LSP? Perhaps LSPs should never be purged, (memory's free these days, right?) or perhaps the rule should be "never purge R2's LSP if R2 is actually reachable" (seems a little dangerous...R2 or actually a whole portion of the net might be temporarily unreachable to some other portion of the net, and so only some nodes might purge R2's LSP). On LANs (because of periodic CSNPs) LSP databases would get resynchronized. But maybe there might be some scenarios in which things could remain unsynchronized. If the rule is that only R2 can cause a purge of R2's LSP, then we have the router-with-the-fast-clock issue (assuming you throw away an LSP when the age expires). And a really really stupid question. What do you mean by "the IP document" in the following: >>Section 6.2 of the IP document essentially deprecates TLV 133 and >>tells to use TLV 10 for authentication. This should be mentioned in >>this section. I assumed you meant RFC 1195, but there is no section 6.2 there. Radia From rtg-dir-admin@ietf.org Tue Apr 1 15:43:44 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14302 for ; Tue, 1 Apr 2003 15:43:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31L86K19515; Tue, 1 Apr 2003 16:08:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31L7pK19458 for ; Tue, 1 Apr 2003 16:07:51 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14283 for ; Tue, 1 Apr 2003 15:43:26 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 190Sdj-000CsA-00; Tue, 01 Apr 2003 12:45:51 -0800 Date: Tue, 1 Apr 2003 12:45:33 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1884294144.20030401124533@psg.com> To: Radia Perlman - Boston Center for Networking CC: rtg-dir@ietf.org Subject: Re: AD-review for draft-ietf-isis-*-interoperable In-Reply-To: <200304011949.h31JnV024997@sydney.East.Sun.COM> References: <200304011949.h31JnV024997@sydney.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Radia, Tuesday, April 1, 2003, 11:49:31 AM, Radia Perlman - Boston Center for Networking wrote: >>From my distant memory...I believe I introduced the concept of purging other > routers' LSPs. My reason was worry about a router R1 having a very > fast clock relative to the other routers. In that case, R1 might purge > R2's LSP long before anyone else does. And then R1 would be > calculating paths on a different LSP database than the other > routers. So it seemed like a good idea to have all routers purge > LSPs at the clock of the fastest router, so their LSP databases would > be the same. > I have to admit I don't have a copy of 10589, so I'll ask a stupid > question here...I'm assuming even if you don't synchronize the > purge, that if R1's age on R2's LSP gets to 0 that R1 would > throw away R2's LSP? Or has it changed to be that only R2 gets > to purge its own LSP? > Perhaps LSPs should never be purged, (memory's free these > days, right?) or perhaps the rule should be "never purge R2's > LSP if R2 is actually reachable" (seems a little dangerous...R2 > or actually a whole portion of the net might be temporarily > unreachable to some other portion of the net, and so only some > nodes might purge R2's LSP). On LANs (because of periodic CSNPs) > LSP databases would get resynchronized. But maybe there might > be some scenarios in which things could remain unsynchronized. > If the rule is that only R2 can cause a purge of R2's LSP, then > we have the router-with-the-fast-clock issue (assuming you > throw away an LSP when the age expires). Oh, purging expired LSPs is definitely fine and does ensure LSDB synchronization. The part of the document in question talks about purging _invalid_ received LSPs. > And a really really stupid question. What do you mean by > "the IP document" in the following: >>>Section 6.2 of the IP document essentially deprecates TLV 133 and >>>tells to use TLV 10 for authentication. This should be mentioned in >>>this section. > I assumed you meant RFC 1195, but there is no section 6.2 there. this was regarding draft-ietf-isis-ip-interoperable-00.txt Regards Alex From rtg-dir-admin@ietf.org Tue Apr 1 18:59:36 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22248 for ; Tue, 1 Apr 2003 18:59:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h320O1K01596; Tue, 1 Apr 2003 19:24:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h320N1K01555 for ; Tue, 1 Apr 2003 19:23:01 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22240 for ; Tue, 1 Apr 2003 18:58:31 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 190VgY-000Emh-00 for rtg-dir@ietf.org; Tue, 01 Apr 2003 16:00:58 -0800 Date: Tue, 1 Apr 2003 16:00:07 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <16415968120.20030401160007@psg.com> To: rtg-dir@ietf.org Subject: BGP spec for final review In-Reply-To: <200304011530.h31FUxS57191@merlot.juniper.net> References: <200304011530.h31FUxS57191@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- This is the version that is expected to go to the IESG. I'd like to ask for at least 3 volunteers to go through it. The deadline is 2 weeks from today, i.e., April 15th. The list of issues documenting the discussion in the WG should be available on the WG mailing list. -- Alex This is a forwarded message From: Yakov Rekhter To: idr@merit.edu Cc: Date: Tuesday, April 1, 2003, 7:30:59 AM Subject: draft-ietf-idr-bgp4-20.txt ===8<==============Original message text=============== Folks, The -20 version contains several (minor) editorial fixes. In addition to the editorial fixes it contains the following in the FSM section (the text was proposed by the Routing ADs): The data structures and FSM described in this document are conceptual and do not have to be implemented precisely as described here, as long as the implementations support the described functionality and their externally visible behavior is the same. Yakov. ------- Forwarded Message Date: Tue, 01 Apr 2003 06:49:45 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-bgp4-20.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 : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter Filename : draft-ietf-idr-bgp4-20.txt Pages : 86 Date : 2003-3-31 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protoco l. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reacha- bility information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This informa- tion is sufficient to construct a graph of AS connectivity from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix and eliminating the concept of network 'class' within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy deci- sions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-20.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-20.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-20.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-31131036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-20.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-31131036.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Tue Apr 1 20:12:33 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23988 for ; Tue, 1 Apr 2003 20:12:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321b1K06078; Tue, 1 Apr 2003 20:37:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321asK06016 for ; Tue, 1 Apr 2003 20:36:54 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23771; Tue, 1 Apr 2003 20:00:56 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 190Wew-000KUa-00; Tue, 01 Apr 2003 17:03:22 -0800 Date: Tue, 1 Apr 2003 17:02:21 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <2619701969.20030401170221@psg.com> To: rtg-mibs@ops.ietf.org CC: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: RTG-MIBs group MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- To complete what's been started a while ago--the rtg-mibs group has been created, the mailing list (rtg-mibs@ops.ietf.org) is setup. Sue kindly agreed to be responsible for the group. I will send another message to the area mailing list inviting volunteers to work on MIBs, but please check again with your friends if anyone wants to be in the group. Here's the list of people subscribed so far: zinin@psg.com fenner@research.att.com shares@nexthop.com bwijnen@lucent.com mukesh.gupta@nokia.com mrw@windriver.com jkuhfeld@redback.com hans.de_vleeschouwer@alcatel.be jhaas@nexthop.com shafiq.pirbhai@alcatel.com -- Alex From rtg-dir-admin@ietf.org Wed Apr 2 05:10:23 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02640 for ; Wed, 2 Apr 2003 05:10:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32AZ1K23870; Wed, 2 Apr 2003 05:35:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32AWXK23741 for ; Wed, 2 Apr 2003 05:32:33 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02538 for ; Wed, 2 Apr 2003 05:07:52 -0500 (EST) Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h32AAFOV003799; Wed, 2 Apr 2003 02:10:16 -0800 (PST) Received: from mshand-w2k.cisco.com (dhcp-rea-gp250-64-103-65-117.cisco.com [64.103.65.117]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA10862; Wed, 2 Apr 2003 11:10:15 +0100 (BST) Message-Id: <4.3.2.7.2.20030402110505.02b5ac20@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Apr 2003 11:10:15 +0100 To: Radia Perlman - Boston Center for Networking From: mike shand Subject: RE: AD-review for draft-ietf-isis-*-interoperable Cc: rtg-dir@ietf.org In-Reply-To: <200304011949.h31JnV024997@sydney.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Radia, This isn't about purging LSP per se. Its about doing it when you detect a "bad" LSP (checksum failure, corrupt format etc. etc.) The original spec said that if you receive a bad LSP you had to purge it all the way back to the source. That's fine in theory, but operationally it caused problems when there was a flakey link which was corrupting LSPs. Every time it caused the LSP in question to be purged from the network and then replaced by the source (until it got to the flakey link, which then caused it to be purged again). The simple resolution is to say that you simply ignore such an LSP. In which case the transmitter simply keeps trying to send it every few seconds across the link (or in the case of a LAN as a result of CSNP action etc. etc.). But the upshot is that the problem is simply confined to the flakey link and doesn't upset the entire network. Mike At 14:49 01/04/2003 -0500, Radia Perlman - Boston Center for Networking wrote: > From: "Tony Li" > > > Purging invalid LSPs are a trivial way to turn your own network into > its own distributed DoS self-attack system. > > On the flip, not purging them and just ignoring them just wastes > a bit > of memory. > > Tony > > From my distant memory...I believe I introduced the concept of purging other >routers' LSPs. My reason was worry about a router R1 having a very >fast clock relative to the other routers. In that case, R1 might purge >R2's LSP long before anyone else does. And then R1 would be >calculating paths on a different LSP database than the other >routers. So it seemed like a good idea to have all routers purge >LSPs at the clock of the fastest router, so their LSP databases would >be the same. > >I have to admit I don't have a copy of 10589, so I'll ask a stupid >question here...I'm assuming even if you don't synchronize the >purge, that if R1's age on R2's LSP gets to 0 that R1 would >throw away R2's LSP? Or has it changed to be that only R2 gets >to purge its own LSP? > >Perhaps LSPs should never be purged, (memory's free these >days, right?) or perhaps the rule should be "never purge R2's >LSP if R2 is actually reachable" (seems a little dangerous...R2 >or actually a whole portion of the net might be temporarily >unreachable to some other portion of the net, and so only some >nodes might purge R2's LSP). On LANs (because of periodic CSNPs) >LSP databases would get resynchronized. But maybe there might >be some scenarios in which things could remain unsynchronized. > >If the rule is that only R2 can cause a purge of R2's LSP, then >we have the router-with-the-fast-clock issue (assuming you >throw away an LSP when the age expires). > >And a really really stupid question. What do you mean by >"the IP document" in the following: > > >>Section 6.2 of the IP document essentially deprecates TLV 133 and > >>tells to use TLV 10 for authentication. This should be mentioned in > >>this section. > >I assumed you meant RFC 1195, but there is no section 6.2 there. > >Radia From rtg-dir-admin@ietf.org Wed Apr 2 14:24:11 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24133 for ; Wed, 2 Apr 2003 14:24:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32Jn2K08447; Wed, 2 Apr 2003 14:49:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32JmvK08429 for ; Wed, 2 Apr 2003 14:48:57 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24116 for ; Wed, 2 Apr 2003 14:24:02 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h32JMio07020 for ; Wed, 2 Apr 2003 19:22:46 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h32JRcI15515 for ; Wed, 2 Apr 2003 19:27:38 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040211263421934 ; Wed, 02 Apr 2003 11:26:34 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Apr 2003 11:26:21 -0800 Message-ID: From: "Putzolu, David" To: "'Alex Zinin'" , "Putzolu, David" Cc: rtg-dir@ietf.org, "Patrick Droz (dro@zurich.ibm.com)" , Bill Fenner Subject: RE: ForCES Framework submission for AD Review Date: Wed, 2 Apr 2003 11:26:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Thanks Alex. My responses inline (most of it snipped as I had no argument). I am going to go ahead and send the note (with edits based on your feedback) to the fwk authors and WG to get them started while we iron out the remaining issues below. > > An> informational RFC just issued on requirements for doing > > this, I'll have them reference that. (where "this" = partition > > a single FE into multiple virtual FEs) > Did you mean the requirements draft (rather than RFC) here? http://www.ietf.org/internet-drafts/draft-ietf-gsmp-dyn-part-reqs-03.txt It is for partitioning ATM/MPLS switches, but has quite a bit of relevance here as well. AFAIK it just got posted to the IETF list as approved for RFC but the RFC editor hasn't gotten around to it yet. > >> I think this could be included as a function within the > >> general discussion on sending packets from FEs up to CEs. > > > I will ask the authors to add text in 4.2.4 about this. > > In a nutshell it needs to say that Fp could be a vector > > used by adversaries for DoS attacks on the NE and > > that the filtering + prioritization of packets across > > Fp is how such attacks are combated. > > Fp itself is one, the CPU is another, so rate-limiting is > also needed. Lost me here. Fp is a vector by which one could attach the CPU on the CE. I agree that rate limiting of packets sent across Fp by FEs is necessary to protect the CPU on the CE. How is the CPU itself an attack vector, and if it is, a vector to what target? It seems to me the CE CPU is the target, not the vector. > > Ok - I can see how advanced features such as OSPF offload > > add complexity better left for later versions. Not sure > > how the framework team will react but will let them know. > > > I assume you don't mean all the other features described in > > 5 and 5.2, as many of them are fundamental parts of current > > router architecture. > > As far as I remember, others were fine. I was somewhat concerned > though when I saw things like "we can implement it at both CE > and FE"... Take ARP, for instance. Usually the CE needs to know > IP-to-MAC mapping because it needs to provide complete FIB to > the FE... Whether ARP is implemented at the CE or the FE level > will affect this process... What was the thinking here? ARP running on FEs instead of CEs is realistic. There are good reasons for taking either approach. Putting ARP on the FE means the CE provides a prefix->NextHopIP FIB (or more accurately, a prefix->nextFE FIB to all FEs, and a prefix->NHIP+outport for the egress FE), and each FE maintains and updates the address resolution table for its interfaces via the ARP protocol. There are cases (having multiple interfaces on different FEs on a directly attached subnet is one) that require CE access to the ARP and other L2-specific tables on each FE, but that doesn't invalidate the approach of running ARP on FEs. The thinking here is that there are many functions that are nearly always on the FE (basic forwarding, queuing, etc.), many functions that are nearly always on the CE (SPF calculations, system SNMP, system CAC, etc.) and some functions which can be on either one. The latter category will add some logical blocks (such as a block for twiddling ARP timers) to the library of FE blocks that may or may not be present, depending on how the FE vendor implements their FE. > >> What about the security hand-shake though? > > > Looks like they only refer to the security part of > > connection establishment through a direct reference > > in section 9 to the requirements doc, which covers > > this pretty thoroughly. Would be better if they talked > > about this in 4.2.2 and 4.2.4 as well, something along > > the lines of "establishment & re-establishment use > > appropriate security mechanisms for authentication as > > specified in section xx of [forces-req]". > > Right, but please make sure it does not sound like they > have to specify the security handshake itself. Agreed, inventing yet another security handshake or security system is to be avoided. > > 3) DoS attacks > > > > 4.2.4 should explicitly call out that Fp could be a vector > > used by adversaries for DoS attacks on the NE and > > that the filtering + prioritization of packets across > > Fp is how such attacks are combated. > > + CPU + rate limiting... I don't know how much we can say about the > protocol itself here, but the FEs should be able to do this, plus > ideally even have separated resources for different types of traffic, > e.g. different queues for L2 keepalives, IGPs, BGP, and ICMP+stuff. > > We should also admit, that this won't solve all problems, > as the attacker can still exhaust the resources if it floods > faked packets. Rate limiting of FE->CE traffic I agree as it is something one can externally observe about a FE. Mandating CE CPU support rate limiting (e.g. dedicate 30% of cycles at most to OSPF/BGP packets received via FEs, reserve 5% of CE CPU cycles no matter what to keep OSPF HELLO processing done in timely fashion) seems dangerous to me. I think the definition of CE internals is out of scope. Maybe just include this as a note in the framework but not a MUST/SHOULD/MAY level architectural guidance. > > 5) Non-stop forwarding/Graceful restart > > > > Section 4.3 talks a bit about features needed for graceful > > restart, and requirements section 5 item 7 discusses this > > topic. The framework should explicitly spell out the need > > to support this and name it appropriately ("graceful restart") > > plus also provide the framework on how this will be done. I'd like to be careful here. The framework should identify a set of mechanisms for doing graceful restart. Thus a FE should specify whether it can retain state across FE reboots. However, the actual definition of how graceful restart is done is best left to RFCs specific to the subject. Put another way: ForCES framework should say "FEs SHOULD provide X and Y capabilities, which are useful for graceful restart". Separate (non-ForCES) RFCs should say: "Graceful restart is done by using use X and Y capability on FEs, along with Z capability on peer routers, and W extension to the routing protocols." > > 8) Security handshakes as part of association establishment > > and re-establishment > > > > Sections 4.2.2 and 4.2.4 should explicitly call out the > > fact that FEs and CEs will perform security handshakes > > as part of the association establishment/re-establishment > > interaction. > > This may sound like the handshake is part of the protocol. > I don't think this is the intention. Agreed. Will reword. > I would also add the following (pls feel free to discuss this > before shipping to the WG): > > Security Considerations > > This is where the IESG will expect the security analysis of > the framework and outlining the actual security mechanisms > that should be present in the architecture. The document should > provide vulnerability analysis of the framework, and how > identified vulnerabilities should be covered. Yes, I agree. Will cause some headache because at least one of the proposed protocol teams (Netlink2) is toying with the idea of their own security mechanisms. However, good to get that out in the open and dealt with sooner rather than later. -David From rtg-dir-admin@ietf.org Wed Apr 2 15:30:11 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07924 for ; Wed, 2 Apr 2003 15:30:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32Kt4K15303; Wed, 2 Apr 2003 15:55:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32KstK15261 for ; Wed, 2 Apr 2003 15:54:55 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07918 for ; Wed, 2 Apr 2003 15:29:59 -0500 (EST) Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 94595893E25; Wed, 2 Apr 2003 12:31:04 -0800 (PST) Message-ID: <3E8B48A2.7020905@redback.com> Date: Wed, 02 Apr 2003 15:31:30 -0500 From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: Under IESG review: draft-coene-sctp-multihome-03.txt References: <2077125700.20030329105903@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex, I don't really see any problems with this one. Sort of a loose discussion of the transport using multiple endpoints and fate sharing. However I didn't see anything blatantly incorrect (other than there is a statement that multiple addresses, aka secondary addresses are new for IPv6 ;^). I really don't like the fact that their examples use some sort of ID rather than IP addresses but one has to pick their battles. Here is the link: http://www.ietf.org/internet-drafts/draft-coene-sctp-multihome-03.txt Alex Zinin wrote: > Folks- > > Comments on this one would be appreciated... > It has "Interaction with routing"... > -- Acee From rtg-dir-admin@ietf.org Wed Apr 2 18:05:07 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14418 for ; Wed, 2 Apr 2003 18:05:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NU2K30615; Wed, 2 Apr 2003 18:30:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NTJK30550 for ; Wed, 2 Apr 2003 18:29:19 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14399 for ; Wed, 2 Apr 2003 18:04:22 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 190rJh-000KcP-00; Wed, 02 Apr 2003 15:06:49 -0800 Date: Wed, 2 Apr 2003 15:06:36 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14099157040.20030402150636@psg.com> To: Acee Lindem CC: rtg-dir@ietf.org Subject: Re: Under IESG review: draft-coene-sctp-multihome-03.txt In-Reply-To: <3E8B48A2.7020905@redback.com> References: <2077125700.20030329105903@psg.com> <3E8B48A2.7020905@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Acee, Hmmm... What about the fact that hosts would need to run routing protocols in order to figure out what addresses to use? Imagine a server... -- Alex Wednesday, April 2, 2003, 12:31:30 PM, Acee Lindem wrote: > Alex, > I don't really see any problems with this one. Sort of a loose > discussion of the transport using multiple endpoints and fate > sharing. However I didn't see anything blatantly incorrect > (other than there is a statement that multiple addresses, aka > secondary addresses are new for IPv6 ;^). I really don't like > the fact that their examples use some sort of ID rather than > IP addresses but one has to pick their battles. > Here is the link: > http://www.ietf.org/internet-drafts/draft-coene-sctp-multihome-03.txt > Alex Zinin wrote: >> Folks- >> >> Comments on this one would be appreciated... >> It has "Interaction with routing"... >> From rtg-dir-admin@ietf.org Wed Apr 2 18:13:34 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14928 for ; Wed, 2 Apr 2003 18:13:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NG0K31285; Wed, 2 Apr 2003 18:16:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32NF8K31224 for ; Wed, 2 Apr 2003 18:15:08 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14903 for ; Wed, 2 Apr 2003 18:12:39 -0500 (EST) Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 30CA048D43; Wed, 2 Apr 2003 15:15:04 -0800 (PST) Message-ID: <3E8B6F10.10309@redback.com> Date: Wed, 02 Apr 2003 18:15:28 -0500 From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: Under IESG review: draft-coene-sctp-multihome-03.txt References: <2077125700.20030329105903@psg.com> <3E8B48A2.7020905@redback.com> <14099157040.20030402150636@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex, I said it was a loose discussion ;^) Under the assumption that every IP address will have a different, seperate path towards the remote endpoint, (this is the responsibility of the routing protocols or of manual configuration) ~~~~~~~~~~~~~~~~~ , if the transport to one of the IP addresses (= 1 particular path) fails then the traffic can migrate to the other remaining IP address (= other paths) within the SCTP association. Alex Zinin wrote: > Acee, > > Hmmm... What about the fact that hosts would need > to run routing protocols in order to figure out what > addresses to use? Imagine a server... > -- Acee From rtg-dir-admin@ietf.org Wed Apr 2 19:36:32 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18949 for ; Wed, 2 Apr 2003 19:36:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h330d1K06040; Wed, 2 Apr 2003 19:39:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h330caK06016 for ; Wed, 2 Apr 2003 19:38:36 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18932 for ; Wed, 2 Apr 2003 19:36:05 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 190skS-000Dy2-00; Wed, 02 Apr 2003 16:38:32 -0800 Date: Wed, 2 Apr 2003 16:37:40 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <162104621577.20030402163740@psg.com> To: Acee Lindem CC: rtg-dir@ietf.org Subject: Re: Under IESG review: draft-coene-sctp-multihome-03.txt In-Reply-To: <3E8B6F10.10309@redback.com> References: <2077125700.20030329105903@psg.com> <3E8B48A2.7020905@redback.com> <14099157040.20030402150636@psg.com> <3E8B6F10.10309@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Acee, That part was fine. How about this: > 2.2 SCTP multihoming and the size of routing tables > > > > As multihoming means that more than one destination address is used > on the host, that would mean that a routing descision must be made > on the host in IP. The host does not know beforehand to which other > host it is going to send something, so that would in theory require > that all possible paths to all possible destinations should be known > on that host. This amounts to the host being a part of the > distribution of the routing information in the network. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Alex Wednesday, April 2, 2003, 3:15:28 PM, Acee Lindem wrote: > Alex, > I said it was a loose discussion ;^) > Under the assumption that every IP address will have a different, > seperate path towards the remote endpoint, (this is the > responsibility of the routing protocols or of manual configuration) > ~~~~~~~~~~~~~~~~~ > , if the transport to one of the IP addresses (= 1 particular path) > fails then the traffic can migrate to the other remaining IP address > (= other paths) within the SCTP association. > Alex Zinin wrote: >> Acee, >> >> Hmmm... What about the fact that hosts would need >> to run routing protocols in order to figure out what >> addresses to use? Imagine a server... >> From rtg-dir-admin@ietf.org Thu Apr 3 02:44:24 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09389 for ; Thu, 3 Apr 2003 02:44:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h337l1K17364; Thu, 3 Apr 2003 02:47:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h337kCK17316 for ; Thu, 3 Apr 2003 02:46:12 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09382 for ; Thu, 3 Apr 2003 02:43:31 -0500 (EST) Received: by mail-blue.research.att.com (Postfix, from userid 612) id 8F4DDB7C4A; Thu, 3 Apr 2003 02:49:57 -0500 (EST) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mail-blue.research.att.com (Postfix) with ESMTP id 3E973B7C38 for ; Thu, 3 Apr 2003 02:49:57 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h337jKVq028666 for ; Thu, 3 Apr 2003 02:45:20 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h337jxN25590; Wed, 2 Apr 2003 23:45:59 -0800 (PST) Message-Id: <200304030745.h337jxN25590@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-dir@ietf.org Subject: Re: Under IESG review: draft-coene-sctp-multihome-03.txt Date: Wed, 2 Apr 2003 23:45:59 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d X-Spam-Status: No, hits=-106.6 required=5.0 tests=BAYES_01,USER_IN_WHITELIST version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Here's my take. ----- Begin forwarded message: From: Bill Fenner Subject: draft-coene-sctp-multihome Date: Wed, 2 Apr 2003 16:13:51 -0800 To: iesg@ietf.org There are a lot of grammar / spelling / sentence structure / document structure issues, which I won't go into. It certainly made the document hard to read. I think my biggest concern is from section 2.2; my previous assumption was that if you really wanted to use SCTP multihoming you would make arrangements a priori to get routing tables that would make it work. The most obvious answer there was static routing and letting the SCTP probes learn what paths were or weren't alive; alternately you could run a seperate instance of the routing protocol specifically to distribute a known subset of the routes to an SCTP speaker. However, the second sentence of 2.2 says "The host does not know beforehand to which other host it is going to send something". I had not previously considered this as a usage mode of SCTP multihoming, simply because it was inconceivable to me that there was a way to make it work properly with routing without teaching end systems every single route, which in itself is a non-starter except in very special situations. I'm not sure what to suggest here. While it's reasonable to distribute a small amount of routing information to a multi-homed host, I'm not particularly comfortable with having that information dynamically based on what multihomed SCTP peers the host currently has associations with (as is proposed in the second paragraph). I'm not sure what the actual direction would be for the proposal in the final paragraph (of not requiring any information at the host for multihoming) - perhaps this means there's an SCTP proxy that knows how to do multihoming and the host forwards all of its connections through the proxy? *Something* needs to have enough information. I guess I need to get my expectations set (or set someone else's). I've been expecting that complete use of SCTP multihoming requires a very special network configuration that most sites would not have, and either end-systems capable of handling full routing tables or a special routing setup for the known destinations. If this is acceptable, then section 2.2 could say that; if it's not, then I need to understand better what the expected usage model of SCTP multihoming is. On a seperate topic, Section 2.4 seems to be obsoleted by draft-ietf-ipsec-sctp-04.txt (it has a reference to -02; I don't know if it has changed significantly). Since draft-ietf-ipsec-sctp-04.txt is on this week's telechat, does it make sense for the "issues" document to raise a solved issue [presuming that ipsec-sctp-04 passes] in the same way as it talks about the others? Bill ----- End forwarded message: From rtg-dir-admin@ietf.org Thu Apr 3 13:34:14 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05907 for ; Thu, 3 Apr 2003 13:34:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33Ib5K13042; Thu, 3 Apr 2003 13:37:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IarK12909 for ; Thu, 3 Apr 2003 13:36:53 -0500 Received: from presque.nexthop.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05890 for ; Thu, 3 Apr 2003 13:33:59 -0500 (EST) Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h33IaQWV046415; Thu, 3 Apr 2003 13:36:26 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h33IaN9c046408; Thu, 3 Apr 2003 13:36:23 -0500 (EST) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h33IaIQ11308; Thu, 3 Apr 2003 13:36:18 -0500 (EST) Date: Thu, 3 Apr 2003 13:36:18 -0500 From: Jeffrey Haas To: Bill Fenner Cc: rtg-dir@ietf.org Subject: Re: Under IESG review: draft-coene-sctp-multihome-03.txt Message-ID: <20030403133618.A9979@nexthop.com> References: <200304030745.h337jxN25590@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200304030745.h337jxN25590@windsor.research.att.com>; from fenner@research.att.com on Wed, Apr 02, 2003 at 11:45:59PM -0800 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Folk, I'll admit up front that I haven't studied SCTP in detail. Alex asked for some input. Given that I just got back from vacation, here's some random observations based on a perhaps incomplete understanding of SCTP. If my premises are wrong, please set your flamethrowers to 1/2. :-) On Wed, Apr 02, 2003 at 11:45:59PM -0800, Bill Fenner wrote: > I think my biggest concern is from section 2.2; my previous assumption > was that if you really wanted to use SCTP multihoming you would make > arrangements a priori to get routing tables that would make it work. > The most obvious answer there was static routing and letting the SCTP > probes learn what paths were or weren't alive; alternately you could > run a seperate instance of the routing protocol specifically to distribute > a known subset of the routes to an SCTP speaker. The impression I had from my initial read of SCTP some months ago was that an end system would be assigned one or more addresses that had been assigned to systems within that routing domain. In a typical Internet attached network, this end system would typically have just a single default route towards a router that knows what to do for both sets of addresses and routing your packets towards the appropriate destinations. The fault protection that SCTP seems to provide seems best applicable to existing inter-AS multihoming situations where multiple address ranges have been allocated from multiple upstreams. Given that providers tend to announce their allocations out all of their connections, where policy allows it, the paths are likely to be much the same. In order for SCTP multihoming to be effective, the announced routes *must* be done in such a way as to introduce path redundancy in the routing system. I say this because, in general, routing failures are due to a failure in the path to an AS and thus usually to all prefixes (or perhaps "atoms" to borrow the caida work) announced by that AS. I *believe* but can't support through empircal data that attempts to introduce actual path redundancy are done as a side effect of trying to introduce load balancing in a network. > I'm not sure what to suggest here. While it's reasonable to distribute > a small amount of routing information to a multi-homed host, I'm not > particularly comfortable with having that information dynamically based > on what multihomed SCTP peers the host currently has associations with > (as is proposed in the second paragraph). I'm not sure what the actual > direction would be for the proposal in the final paragraph (of not > requiring any information at the host for multihoming) - perhaps this > means there's an SCTP proxy that knows how to do multihoming and the host > forwards all of its connections through the proxy? *Something* needs > to have enough information. Right. This is what has confused me most about this document. The impression I got is that the knowledge would exist as part of the routing system and the routing system allows for the distribution of the redundant paths. This document seems largely to focus upon the idea that the redundancy exists in the end-systems and would require a lot more routing intelligence than we've been wont to put into an end-system. > I guess I need to get my expectations set (or set someone else's). > I've been expecting that complete use of SCTP multihoming requires a > very special network configuration that most sites would not have, > and either end-systems capable of handling full routing tables or > a special routing setup for the known destinations. If this is > acceptable, then section 2.2 could say that; if it's not, then > I need to understand better what the expected usage model of SCTP > multihoming is. Yeah, having this clarified would be useful. I suspect I'm sort of on the right track. One useful side effect of SCTP everywhere is that you can reduce the Internet routing table a bit since you wouldn't need provider independant address space quite as much. You can live strictly with one or more sets of provider assigned addresses and never worry about announcing them out your other network connections. However, I don't think SCTP addresses primary address assignment in a useful enough way to deal with traffic balancing issues appropriately. > Bill -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Thu Apr 3 19:39:02 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21331 for ; Thu, 3 Apr 2003 19:39:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h340g0K15894; Thu, 3 Apr 2003 19:42:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h340fKK15872 for ; Thu, 3 Apr 2003 19:41:20 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21304 for ; Thu, 3 Apr 2003 19:38:20 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 191FGC-0007ib-00 for rtg-dir@ietf.org; Thu, 03 Apr 2003 16:40:48 -0800 Date: Thu, 3 Apr 2003 16:40:14 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <198191174884.20030403164014@psg.com> To: rtg-dir@ietf.org Subject: rtg-dir += dkatz; /* Make sure we don't show up on front page of Wall Street Journal... */ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- We have recruited Dave Katz to the directorate. He's just been added to the list. Welcome, Dave! -- Alex From rtg-dir-admin@ietf.org Sat Apr 5 01:00:21 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19121 for ; Sat, 5 Apr 2003 01:00:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3563u824033; Sat, 5 Apr 2003 01:03:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h355rE823605 for ; Sat, 5 Apr 2003 00:53:14 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19000 for ; Sat, 5 Apr 2003 00:49:37 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 191gb1-000CCr-00 for rtg-dir@ietf.org; Fri, 04 Apr 2003 21:52:07 -0800 Date: Fri, 4 Apr 2003 21:51:37 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4789942059.20030404215137@psg.com> To: rtg-dir@ietf.org Subject: Fwd: Re: My Thoughts on Site-Locals In-Reply-To: <6589172773.20030404213848@psg.com> References: <963621801C6D3E4A9CF454A1972AE8F504F731@server2000.arneill-py.sacramento.ca.us> <6589172773.20030404213848@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- For those of you not following the ipv6 WG, they are now verifying the consensus to remove SLs that was reached in SF. Feel free to chime in and inject some routing clue there. -- Alex This is a forwarded message From: Alex Zinin To: "Michel Py" Cc: "Margaret Wasserman" , ipng@sunroof.eng.sun.com Date: Friday, April 4, 2003, 9:38:48 PM Subject: My Thoughts on Site-Locals ===8<==============Original message text=============== Michel, > Agreed. I don't like the word "area" myself in this context; I was > simply quoting Margaret's words. Well, it's not that I don't like the word "area" here, in fact it would not be unreasonable to assume that people would want to map sites to areas... > There are plenty of other cases like > this, for example using two different IGPs as the result of a > merger-never-finished-the-cleanup or related; I have seen a site where > half of it was EIGRP the other half OSPF with mutual bidirectional > redistribution and eBGP in the middle. :-( > Mmmm thinking about it, :-) job security. Sounds really bad. Mutual redistribution is a very risky thing, but if done properly does not need eBGP... anyways, it's a mess and we don't want the architecture to encourage this... > Anyway, I suggested earlier that the site boundaries should be the > administrative control boundaries of the organization. It might not be > the correct wording, but my feeling is that we could come with some text > that will detail the position of site boundaries. > I have made the point earlier many times that the definition of "site" > is ambiguous and/or imprecise, there is some geographical connotation > attached to the word, we need a good definition anyway. I don't think a "better" definition is going to help here. No matter what we say a site should be, the day people start deploying them we'll hear back from the customers smiling at the definition and giving us their reasons why they have to ignore it (e.g. my organization has just become a department within a bigger one, what should I consider a site now?) Again, there is a disconnect between the driving factors defining site boundaries and those defining routing hierarchy elements. > I agree, but the other side of this coin is that if the feature is not > implemented in the architecture it will be implemented by the > configuration at the site. In other words, if as a site administrator I > am not happy about the way the site-local traffic flows I am going to > tweak it using route-maps, prefix-lists, route tags and whatever I feel > like doing for my intra-site traffic engineering. Each site will end up > being configured differently. Although there still is a lot of work to > be done on the topic, I think that the convexity of the site is a good > idea to incorporate in the architecture. I think there might be some confusion here. Even if site support was introduced into routing, SL topology and global one would be congruent (making them non-congruent would be too much complexity), which means that the path taken by packets that belong to a connection within a site would be the same regardless of whether SL or public addresses are used. So, SL do not add anything here at all. > In short: > - If site convexity is not built-in the architecture, it might or might > not work depending on implementation, network topology, etc. This will > lead in many cases to manual policy routing config to make it work the > may it should. > - If site convexity is built-in the architecture, the only case where it > would require manual policy routing config is if the site administrator > wants to break convexity. I can't think of a reason but I'm sure they > are some valid ones. If you are interested in convexity as a feature (rather than a requirement to make SLs work), we already have a similar notion in routing, but it is applied to areas and AS'es--for example, OSPF area are logically convex, i.e., traffic between hosts within the same area will be contained within the area because routers prefer intra-area routes over inter-area ones. You don't need the notion of sites here. > As some others have commented, IPv6 is not only IPv4 with more bits. The > issue of "automatic site convexity" is definitively a pain to implement > in router code, but is also a feature that simplifies the life of > network administrators and as such a factor of success for IPv6. I guess we disagree on the "simplifies" part here :) Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Sat Apr 5 16:55:11 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15391 for ; Sat, 5 Apr 2003 16:55:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Lx4823218; Sat, 5 Apr 2003 16:59:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35Lwk823183 for ; Sat, 5 Apr 2003 16:58:46 -0500 Received: from net4u.net4u.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15384 for ; Sat, 5 Apr 2003 16:54:49 -0500 (EST) Received: from net4u.ch (zux006-019-035.adsl.green.ch [81.6.19.35]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h35LvH830867; Sat, 5 Apr 2003 23:57:17 +0200 Message-ID: <3E8F50F5.6080809@net4u.ch> Date: Sat, 05 Apr 2003 23:56:05 +0200 From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: rtg-dir@ietf.org Subject: Re: Fwd: Re: My Thoughts on Site-Locals References: <963621801C6D3E4A9CF454A1972AE8F504F731@server2000.arneill-py.sacramento.ca.us> <6589172773.20030404213848@psg.com> <4789942059.20030404215137@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex Zinin wrote: >Folks- > > For those of you not following the ipv6 WG, they are now verifying > the consensus to remove SLs that was reached in SF. Feel free to > chime in and inject some routing clue there. > > > good work, sense prevails (for once) --- tony From rtg-dir-admin@ietf.org Mon Apr 7 13:27:16 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28407 for ; Mon, 7 Apr 2003 13:27:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37HW2829528; Mon, 7 Apr 2003 13:32:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37HVL829485 for ; Mon, 7 Apr 2003 13:31:21 -0400 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28361 for ; Mon, 7 Apr 2003 13:26:31 -0400 (EDT) Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA18153 for ; Mon, 7 Apr 2003 10:29:02 -0700 (PDT) Received: from sunlabs-sr1 (sunlabs-sr1 [129.148.75.32]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h37HT1016467 for ; Mon, 7 Apr 2003 13:29:01 -0400 (EDT) Message-Id: <200304071729.h37HT1016467@sydney.East.Sun.COM> Date: Mon, 7 Apr 2003 13:29:01 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Site-Locals To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QC0tAs4CkKVzRYE/0Vy8Xg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , There seems to be a lot of emotion here, and I will admit I have not been following the arguments. So I don't even have an opinion, since I don't do that until I think I understand all the arguments. Could someone summarize what the arguments are on each side? I'm a little afraid that "consensus" will never be really reached if people on the other side do not feel their arguments were listened to and understood. This is a fairly contentious issue and will benefit from a document that explains what "site locals" are, and what the arguments were on each side. Otherwise, this will keep coming up, it will cause undue divisiveness, etc. I will start, without doing my homework (reading the mailing list), but just to hopefully inspire someone who has been following it to write a real summary. *************** 1) What are site locals? These are IPv6 addresses that are not globally administered, and therefore not guaranteed to be globally unique. 2) How would you use them? You'd use them purely locally, or through a NAT, if a site-local-addressed node wishes to communicate outside its "site" 3) Why people think they are useful: . security: things are more secure if the resources on your own network are not directly addressable from outside . ease of deployment: you don't need to first obtain globally assigned addresses (perhaps this is a cost issue to if addresses aren't free) 3a) Counterarguments to 3) . security needs to be cryptographic. This is only the perception of security (though sometimes the perception of security sells) 4) Why people think they are bad: . confusion can exist about what a "site" is. You can have two locally addressed sites, merge them, and then have duplicate addresses . this will mean that NATs will still exist, and protocols will not be able to use IP addresses as endpoint identifiers . you need to make sure your border routers don't allow anything with site-locals to escape, otherwise confusion will exist Radia From rtg-dir-admin@ietf.org Mon Apr 7 13:55:16 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29129 for ; Mon, 7 Apr 2003 13:55:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37I01831382; Mon, 7 Apr 2003 14:00:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37HxV831340 for ; Mon, 7 Apr 2003 13:59:31 -0400 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29105 for ; Mon, 7 Apr 2003 13:54:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 192ari-000KO2-00; Mon, 07 Apr 2003 10:57:06 -0700 Date: Mon, 7 Apr 2003 10:56:19 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <190133858458.20030407105619@psg.com> To: "Putzolu, David" , Patrick Droz (dro@zurich.ibm.com) CC: rtg-dir@ietf.org, Pekka Savola , randy@psg.com Subject: Fwd: Re: draft-ietf-forces-requirements-08.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David, Patrick- Below are the comments from Pekka (an OPS-DIR member), consider them backed up by Randy as part of IESG review. Thanks. -- Alex http://psg.com/~zinin/ Comments on forces-reqs-08. In summary, I'd like to express a very grave concern of trying to address every possible problem, a path that seems doomed to failure. Note a list of dozen different forwarding functionalities that still fail to capture all of them -- and the associated complexity of handling all the different nuances and orderings of these functions. Seems way, WAY too complex to make interoperable and useful. I wonder how far we have to go with this effort to see it as a dead-end. Or alternatively, some other architectural/approach revamp might be able to salvage some of the mechanisms (e.g. concentrate on certain core tasks only, but then again, one might question how useful the mechanism is). Substantial: ------------ 1) it is not clear how different efforts (most of which referenced in the draft) interconnect: e.g. midcom (similar protocol between hosts, typically), gsmp, ccamp. 2) I find the justification a bit questionable: A standard set of mechanisms for connecting these components provides increased scalability and allows the control and forwarding planes to evolve independently, thus promoting faster innovation. .. it seems to me that in practice, such independent evolution and innovations typically require changes in both elements: I doubt one can create such a generic architecture which would accommodate anything happening to the other in the future. Again in: By allowing the control and forwarding planes to evolve independently, different types of FEs can be developed - some general purpose and others more specialized. .. this seems a bit questionable: different types of FEs can already be developed, and have been developed for a long time now. What you're aiming for is mixing and matching a CE one or more FE's with a standard protocol with different characteristics and possibly different vendors. 3) the applicability of ForCES seems to be unclear, for example: Addressable Entity (AE) - A physical device that is directly addressable given some interconnect technology. For example, on IP networks, it is a device to which we can communicate using an IP address; and on a switch fabric, it is a device to which we can communicate using a switch fabric port number. .. the latter would seem to indicate some support for non-IP devices too, or should this use some rewording to clarify which kind of switch fabric was the question was all about? 4) I haven't delved into ForCES, but the last two sentences look a bit scary: Forwarding Element (FE) - A logical entity that implements the ForCES protocol. FEs use the underlying hardware to provide per- packet processing and handling as directed by a CE via the ForCES protocol. FEs may use PFE partitions, whole PFEs, or multiple PFEs. .. this seems to imply that CE's instruct logical FE's to perform some tasks, while there exists some protocol between FE->PFE. - what is used between FE and PFE's? - are there interoperability reqs between FE / PFE's (can they be from different vendor)? - is this useful at all? Seems like very dangerous to me -- because might require an additional abstraction layer at FE's -- which might make the CE-FE control even more useless (too generic) and less powerful. 5) Is the partitioning concept really useful? Could you list some applicability scenarios? 6) Is it possible to have multiple CE's manage one FE? This probably would have tradeoffs and drawbacks, but is integral when you consider the applicability of the protocol (ie. is it a network management protocol or control-dataplane protocol). 7) Is it necessary/useful to keep the ForCES protocol open-ended even now? I fail to see valid reasons for multiple protocols..: ForCES Post-Association Phase Protocol - [...] This protocol could be a single protocol or could consist of multiple protocols working together. 8) Again, the ForCES model seems quite open-ended: FE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which CE(s) a FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. A FE manager may use anything from a static configuration to a pre- association phase protocol (see below) to determine which CE(s) to use. Being a logical entity, a FE manager might be physically combined with any of the other logical entities mentioned in this section. ... I fail to see the usability of FE's discovering CE(s). Being a master-slave association where CE's are masters, I would think it would be natural to assume CE's are the masters and thus _they_ discover their slave FE's. 9) In the snippet above and some others: it seems to be typical in the requirements to overload the terminology with rather long architectural descriptions. This has both good and bad sides, but in any case it should be considered whether some other way to achieve the big picture would be more usable. Also, there are some terms in the terminology which are not used in the document. If this is also meant as a terminology document, this might be ok, but otherwise keeping to the minimum might be useful. 10) The list of FE functions below is extensive: Some functions that FEs could perform include layer 3 forwarding, metering, shaping, firewall, NAT, encapsulation (e.g., tunneling), decapsulation, encryption, accounting, etc. Nearly all combinations of these functions may be present in practical FEs. .. but in reality, gives little hope, as the list is far from complete, and completely evolving. It seems apparent that if one tries to standardize all the possible functions, with *a lot* of abstractization, this is a source of a LOT of work, and work that's never going to end. .. so, it might be useful to consider the scope: deal with the most basic form of forwarding, and that only, for now. 11) The last sentence here implies a possible disconnect in the architecture: 1) CEs and FEs MUST be able to connect by a variety of interconnect technologies. Examples of interconnect technologies used in current architectures include Ethernet,bus backplanes, and ATM (cell) fabrics. FEs MAY be connected to each other via a different technology than that used for CE/FE communication. ==> Is it intended to connect FE's to CE or provide a FE-FE protocol? Having some interconnection and/or protocol between FE's seems useful in a sense, but also potentially out of scope of this architecture. 12) This sounds very challenging: The variety of FE functionality that the ForCES architecture allows poses a potential problem for CEs. In order for a CE to effectively control a FE, the CE must understand how the FE processes packets. We therefore REQUIRE that a FE model be created that can express the logical packet processing capabilities of a FE. .. I'd say that most functionalities differ *a lot* from vendor to vendor. Are you really, really sure that you should (or can) express all of these in completely independent way *AND* that subsequent use if it's understood would be *effective*. Also see other subsections here, like 6.2. 13) Another architectural problem..: 6.3. Ordering of Logical Functions The model MUST be capable of describing the order in which these logical functions are applied in a FE. The ordering of logical functions is important in many cases. For example, a NAT function may change a packet's source or destination IP address. Any number of other logical functions (e.g., layer 3 forwarding, ingress/egress firewall, shaping, accounting) may make use of the source or destination IP address when making decisions. The CE needs to know whether to configure these logical functions with the pre-NAT or post-NAT IP address. [...] .. so are we talking about N! possible orderings (with N possible logical functions). Seems like a horror ("pre-nat post-qos-meter pre-qos-classification pre-forward-do-something foo bar boo baf"-state). Same again in: The FE model MUST be capable of expressing complex sets of filtering functions. The model MUST be able to express the existence of these functions at arbitrary points in the sequence of a FE's packet processing functions. 14) I'm having difficulties parsing the actual requirements in: 8)Off-loaded Functions .. do you require that basically any piece of code CE wants to offload to FE's must be supported as long it's expressed as a finite state machine.. or what? That that code is to be executed on all (or a specified portion of) the packets? 15) I don't disagree that security must be supported (btw. nit: s/make private/encrypt/), but..: 2)Support for Secure Communication a) FE configuration will contain information critical to the functioning of a network (e.g. IP Forwarding Tables). As such, it MUST be possible to ensure the authenticity and integrity of ForCES protocol messages. b) FE configuration information may also contain information derived from business relationships (e.g. service level agreements). Therefore, it MUST be possible to secure (make private) ForCES protocol messages. .. I'm not sure how applicable this is in in most/some scenarios. For example, if the interconnect between CE and FE's is a shared/dedicated bus, e.g. an ethernet link, I'm not sure how applicable these are. Basically if the control messages traverse over the Internet, they should be securable. I'm not sure how one considers the possible deployment scenarios, but I don't think over-the-Internet case is too common (typically hinting at CE/FE located in a different NE). 16) on the use of reliable protocols: 4)Multihop When the CEs and FEs are separated beyond a single hop, the ForCES protocol will make use of an existing RFC2914 compliant L4 protocol with adequate reliability, security and congestion control (e.g. TCP, SCTP) for transport purposes. ==> I fail to see the added value of a separate protocol for singlehop links; there, the latency is low and reliable protocols should be quite usable. 17) security considerations should be properly written out, a blind referral insufficient: 9. Security Considerations See architecture requirement #5 and protocol requirement #2. Semi-editorial: --------------- CEs may consist of PCE partitions or whole PCEs. ==> what about 'multiple PCEs' (compare to the text of FE's) ? Post-association Phase - The period of time during which a FE does know which CE is to control it and vice versa, ==> is "FE controlling CE" (through vice versa) ? I think not? 2) FEs MUST support a minimal set of capabilities necessary for establishing network connectivity (e.g., interface discovery, port up/down functions). Beyond this minimal set, the ForCES architecture MUST NOT restrict the types or numbers of capabilities that FEs may contain. ==> it is not unambiguous what the last sentence tries to say; does it take a stance that at least a minimum set of capability types must be supported, that ForCES must work in the presence of any possible set of capabilities, or what.. 9) Any proposed ForCES architectures MUST explain how that architecture supports all of the router functions as defined in [RFC1812]. ==> this must be elaborated. RFC1812 is a long RFC, and no proposal should be expected to go through all of these functions! Clearly there are certain specific issues which need to be addressed here... 10) In a ForCES NE, the FEs MUST be able to provide their topology information (topology by which the FEs in the NE are connected) to the CE(s). ==> the wording in ()'s doesn't really clarify much and should be rewritten; also, it's rather difficult to understand. Same in the second version of this req. We therefore REQUIRE that a FE model be created that can express the ==> REQUIRE is not a proper RFC2119 keyword. 2)Forwarding Functions The FE model MUST be capable of expressing the data that can be used by the forwarding function to make a forwarding decision. Support for IPv4 and IPv6 unicast and multicast forwarding functions MUST be provided by the model. ==> just as a comment, I fear multicast functions may be significantly more difficult to provide than unicast. The FE model SHOULD be extensible so that new, currently unknown FE functionality can be expressed. The FE Model SHOULD NOT be extended to express standard/common functions in a proprietary manner. This would NOT be ForCES compliant. ==> NOT is not a proper RFC2119 keyword. 5)Message Priority The ForCES protocol MUST provide a means to express the protocol message priorities. ==> should this be elaborated? Ie., do you mean in the case protocol messages get queued and some messages are more important than others so they'll be able to overtake the queue? (and not e.g. in TOS/traffic class context.) Note that this may have quite interesting implications for multipart or sequenced commands, so prioritizing should be used with care. 9)Packet Redirection/Mirroring a) The ForCES protocol MUST define a way to redirect packets from the FE to the CE and vice-versa. Packet redirection terminates any further processing of the redirected packet at the FE. ==> when redirected from CE to FE, the latter sentence does not parse properly. Editorial: ---------- Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. [...] ==> the boilerplate is not as-is. Conventions used in this document ==> I'd place this under a numbered section, at the introduction or something, but I'm not sure if there is a strict policy on that. 1. Abstract ==> abstract must not be numbered, per ID-nits etc. Khosravi, Anderson, et. al. Expires July 2003 [Page 1] ==> this should be either "Khosravi, et al." or "Khosravi & Anderson" (rfc-ed policy) 8. References.....................................................13 8.1. Normative References...........................................13 8.2. Informative References.........................................13 9. Security Considerations........................................13 10. Authors' Addresses & Acknowledgments..........................14 11. Editors' Contact Information..................................15 ==> personally I'd like sec considerations before references (that's the more typical way), but that's not a strict rule. ==> note that IPR & copyright statements are also missing, but those can be added later on too. entities that cooperate to provide a given functionality (such as a routing or IP switching) and yet appear as a normal integrated ==> s/a routing/routing/ For the purpose of illustration, let us consider the architecture of a router to illustrate the concept of separate control and ==> please try not to use the word "illustrate" twice. architectures include Ethernet,bus backplanes, and ATM (cell) ==> s/,bus/, bus/ ForCES protocol elements from joining a NE.(For more protocol ==> s/(/ (/ requirement #1) details, refer to section 7 requirement# 2) ==> choose the format how to refer to requirements and be consistent; I prefer " #x" rather than "# x" but YMMV. From rtg-dir-admin@ietf.org Mon Apr 7 20:28:05 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11849 for ; Mon, 7 Apr 2003 20:28:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h380X1826530; Mon, 7 Apr 2003 20:33:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h380WF826510 for ; Mon, 7 Apr 2003 20:32:15 -0400 Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11815 for ; Mon, 7 Apr 2003 20:27:17 -0400 (EDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h380MtS24851 for ; Tue, 8 Apr 2003 00:22:55 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by petasus.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h380Nrl05515 for ; Tue, 8 Apr 2003 00:23:53 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040717300031380 ; Mon, 07 Apr 2003 17:30:00 -0700 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Apr 2003 17:29:48 -0700 Message-ID: From: "Putzolu, David" To: Alex Zinin , "Putzolu, David" , Patrick Droz Cc: rtg-dir@ietf.org, Pekka Savola , randy@psg.com Subject: RE: Re: draft-ietf-forces-requirements-08.txt Date: Mon, 7 Apr 2003 17:29:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , From rtg-dir-admin@ietf.org Tue Apr 8 13:05:50 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22330 for ; Tue, 8 Apr 2003 13:05:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38HB3811813; Tue, 8 Apr 2003 13:11:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38HAs811771 for ; Tue, 8 Apr 2003 13:10:54 -0400 Received: from hermes.sc.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22321 for ; Tue, 8 Apr 2003 13:05:30 -0400 (EDT) Received: from talaria.sc.intel.com (talaria.sc.intel.com [10.3.253.5]) by hermes.sc.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h38H56h22020 for ; Tue, 8 Apr 2003 17:05:06 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.sc.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h38H3Hg08044 for ; Tue, 8 Apr 2003 17:03:18 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003040810112621708 ; Tue, 08 Apr 2003 10:11:26 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Apr 2003 10:08:02 -0700 Message-ID: From: "Putzolu, David" To: "'Alex Zinin'" , "Putzolu, David" , "'Patrick Droz'" Cc: "'rtg-dir@ietf.org'" , "'Pekka Savola'" , "'randy@psg.com'" Subject: RE: Re: draft-ietf-forces-requirements-08.txt Date: Tue, 8 Apr 2003 10:07:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , (Apologies for the previous empty email. Outlook has decided that when I use the "offline" mode that certain emails should go out w/out any body text. I am resending this in online mode, hopefully it will go through.) --- Thanks for the feedback - responses inlined... > Comments on forces-reqs-08. In summary, I'd like to express > a very grave > concern of trying to address every possible problem, a path that seems > doomed to failure. Note a list of dozen different forwarding > functionalities that still fail to capture all of them -- and the > associated complexity of handling all the different nuances > and orderings > of these functions. > > Seems way, WAY too complex to make interoperable and useful. > I wonder how > far we have to go with this effort to see it as a dead-end. Or > alternatively, some other architectural/approach revamp might > be able to > salvage some of the mechanisms (e.g. concentrate on certain core tasks > only, but then again, one might question how useful the mechanism is). I agree that trying to define all possible features is infeasible, as the list is ever-evolving. I also agree that a reduction to a single feature (e.g. only address IPv4 forwarding and nothing else), while feasible, is useless. The initial goal of forces is to try to capture that 20% of features/configurations that applies to 80% of the applicable scenarios. > 1) it is not clear how different efforts (most of which > referenced in the > draft) interconnect: e.g. midcom (similar protocol between hosts, > typically), gsmp, ccamp. This seems like a framework question, not a requirements question. That being said, I will answer as best I can. Midcom is primarily focused on NAT and ALGs. One could construct a NAT box using CE/FE separation. If that is the case, ForCES might be present. Midcom would deliver information to the CE (e.g. "open this port for a RTP stream as part of this H.323 call"), the CE would then configure the FE appropriately ("add ACL entry: pass ports 3310/3311 between hosts A and B"). GSMP controls switches. The GSMP authors are following ForCES pretty closely (one is a co-author on the requirements). Thus far ForCES has focused on CE/FE separation routers (not switches). Could GSMP be used to control FE routing functions? Yes, but the GSMP authors have so far not indicated a desire to extend GSMP for that. Could ForCES be used to control FE switching functions? Yes, but that would be extending the scope of ForCES significantly. Is routing enough to satisfy the 80/20 rule, or do you think that switching must be thrown in as well? Sounds like a scope/charter- level change, so I'm hesitant to jump into that debate. CCAMP is everything from GMPLS to LMP to OSPF extensions. A few of the things CCAMP is relevant to might show up in routing FEs, seems to me more would fall into the GSMP lap. > 2) I find the justification a bit questionable: > > A standard set of mechanisms for connecting > these components provides increased scalability and allows the > control and forwarding planes to evolve independently, thus > promoting faster innovation. > > .. it seems to me that in practice, such independent evolution and > innovations typically require changes in both elements: I > doubt one can > create such a generic architecture which would accommodate anything > happening to the other in the future. Anything talking to anything is impossible. A CE talking to successively faster generations of FEs with IPv4 forwarding and DS support, using the same standard ForCES protocol, is possible. > Again in: > > By allowing the control and > forwarding planes to evolve independently, different types of FEs > can be developed - some general purpose and others more > specialized. > > .. this seems a bit questionable: different types of FEs can > already be > developed, and have been developed for a long time now. What you're > aiming for is mixing and matching a CE one or more FE's with > a standard protocol with different characteristics and possibly > different vendors. Within the context of the 80/20 rule mentioned above, yes. > 3) the applicability of ForCES seems to be unclear, for example: > > Addressable Entity (AE) - A physical device that is directly > addressable given some interconnect technology. For example, on IP > networks, it is a device to which we can communicate using an IP > address; and on a switch fabric, it is a device to which we can > communicate using a switch fabric port number. > > .. the latter would seem to indicate some support for non-IP > devices too, > or should this use some rewording to clarify which kind of > switch fabric was the question was all about? ForCES will define a model that applies to FEs that are network-connected and backplane/fabric connected. ForCES protocol will then run over IP, ForCES model will be likely reused for non-IP CE<->FE link scenarios (analogous to GSMP over Ethernet/GSMP over ATM/GSMP over IP). AE is an effort to get a term which works equally well in both cases. > 4) I haven't delved into ForCES, but the last two sentences > look a bit > scary: > > Forwarding Element (FE) - A logical entity that implements the > ForCES protocol. FEs use the underlying hardware to provide per- > packet processing and handling as directed by a CE via the ForCES > protocol. FEs may use PFE partitions, whole PFEs, or > multiple PFEs. > > .. this seems to imply that CE's instruct logical FE's to > perform some > tasks, while there exists some protocol between FE->PFE. > > - what is used between FE and PFE's? > - are there interoperability reqs between FE / PFE's (can > they be from > different vendor)? > - is this useful at all? Seems like very dangerous to me -- > because might > require an additional abstraction layer at FE's -- which > might make the > CE-FE control even more useless (too generic) and less powerful. I agree the wording is bad and it should be fixed. What should be coming across here is that a FE is what a CE controls. If under the covers the FE happens to be a single blade, a partition of a blade, of two physical blades that through proprietary magic appear as a single very reliable blade to the CE, is beyond the scope of concern of forces. > 5) Is the partitioning concept really useful? Could you list some > applicability scenarios? I will provide some scenarios because you ask, but I personally am not comfortable arguing for it. The main point I'd like to make is that ForCES should be agnostic about partitioning issues, and forcing ForCES to define/care about/create partitioning would be an undesirable complexity. Potential applicability scenario: Service provider wants a capability to offer hard guarantees to customers that they get access, performance, and control of what looks like their own virtual router. SP can either buy a physical box per customer (expensive) or partition a single physical box into logical partitions. Again - this isn't and shouldn't be for ForCES to spec out. Main point here is that ForCES shouldn't care if somebody does partitioning under the covers ahead of time - a FE is a FE. > 6) Is it possible to have multiple CE's manage one FE? This probably > would have tradeoffs and drawbacks, but is integral when you > consider the applicability of the protocol (ie. is it a network management > protocol or control-dataplane protocol). Yes - multiple CEs may control one FE. When this happens the CEs had better make sure to coordinate among each other so that they don't give contradictory orders to the FE. Simple case: 1 CE talking to FE. Possible case: 2 CEs, from same vendor, speaking proprietary CE<->CE protocol to coordinate with each other, control parts of the same FE. Theoretical case: Somebody defines that CE<->CE protocol and heterogeneous CEs used. Hard problem and beyond the scope of ForCES. > 7) Is it necessary/useful to keep the ForCES protocol > open-ended even now? > I fail to see valid reasons for multiple protocols..: > > ForCES Post-Association Phase Protocol - [...] > This protocol could be a single protocol or > could consist of multiple protocols working together. Looking at router functions, there can be a fairly large difference between the proportion of CE<->FE "control" traffic (that is: CE giving new FIB entries to FE, FE reporting alarms to CE, etc.) and the CE<->FE "data" traffic (that is: OSPF HELLO and other packets, the SNMP SET/GETs, the TCP SYN arriving from a peer router setting up a BGP connection). Also: The CE<->FE data traffic has quite different reliability requirements. That is: If a SNMP packet, which arrived over UDP, gets dropped in transport between FE and CE, it is much less of a problem than if a CE packet adding an ACL entry gets dropped going from CE to FE. Also: In some architectures there is a physically, or at least logically (different queue etc) distinct control channel from data channel. Given these different requirements and characterizations, the ForCES architecture might specify that some traffic ("data" traffic) gets transported over a lightweight, unreliable protocol, and other traffic ("control" traffic) gets transported over a reliable, perhaps even secure, protocol. Mandating in the requirements that all types of CE<->FE traffic all run over a single protocol/connection just doesn't seem something a requirements doc should do. > 8) Again, the ForCES model seems quite open-ended: > > FE Manager - A logical entity that operates in the pre-association > phase and is responsible for determining to which CE(s) a FE should > communicate. This process is called CE discovery and may involve > the FE manager learning the capabilities of available CEs. A FE > manager may use anything from a static configuration to a pre- > association phase protocol (see below) to determine which CE(s) to > use. Being a logical entity, a FE manager might be physically > combined with any of the other logical entities mentioned in this > section. > > ... I fail to see the usability of FE's discovering CE(s). Being a > master-slave association where CE's are masters, I would > think it would be > natural to assume CE's are the masters and thus _they_ discover their > slave FE's. FEM/CEM discovering each other is outside the ForCES scope. The FEM/CEM concept is included to be able to say basically "look, we know CEs and FEs need to find each other - and we don't define how it is done, because we wanted to limit our scope". For the near future I'd expect that a CEM/FEM might be little more than a human being typing in a CE IP address via the serial port of the FE and v.v. on the FE. > 9) In the snippet above and some others: it seems to be > typical in the > requirements to overload the terminology with rather long > architectural > descriptions. This has both good and bad sides, but in any > case it should > be considered whether some other way to achieve the big > picture would be > more usable. > > Also, there are some terms in the terminology which are not > used in the > document. If this is also meant as a terminology document, > this might be > ok, but otherwise keeping to the minimum might be useful. This is actually something I've never gotten a good answer to. In dealing with terminology, what is the BKM? Is it: A) Put all terms we know we will need in the first doc (in this case reqs), adding deltas to later docs once reqs is published, or B) Put in reqs only terms used in reqs - each doc defines all the terms it uses, or C) Put a separate terminology doc. I think C doesn't work because it would be a normative ref that would hold up other docs from progressing. Not sure whether to do A or B though - do you think B is the best approach? > 10) The list of FE functions below is extensive: > > Some functions that FEs could perform include layer 3 forwarding, > metering, shaping, firewall, NAT, encapsulation (e.g., tunneling), > decapsulation, encryption, accounting, etc. Nearly all > combinations > of these functions may be present in practical FEs. > > .. but in reality, gives little hope, as the list is far from > complete, > and completely evolving. It seems apparent that if one tries to > standardize all the possible functions, with *a lot* of > abstractization, > this is a source of a LOT of work, and work that's never going to end. > > .. so, it might be useful to consider the scope: deal with > the most basic form of forwarding, and that only, for now. The section that appears with is just giving an architectural overview. The model document is chartered with specifying exactly what functions will be tackled by ForCES v1. Most likely it will be a shorter list as you suggest. > 11) The last sentence here implies a possible disconnect in the > architecture: > > 1) CEs and FEs MUST be able to connect by a variety of interconnect > technologies. Examples of interconnect technologies used > in current > architectures include Ethernet,bus backplanes, and ATM (cell) > fabrics. FEs MAY be connected to each other via a different > technology than that used for CE/FE communication. > > ==> Is it intended to connect FE's to CE or provide a FE-FE > protocol? > Having some interconnection and/or protocol between FE's > seems useful in a > sense, but also potentially out of scope of this architecture. The goal of this section is to explain that the CE<->FE wire (which is what forces cares about) may or may not be the same as the FE<->FE wire. There are some efforts going on to look at FE<->FE protocol. However, the expertise involved (fast path data plane issues, state sharing between forwarding devices) is somewhat less likely to be found in IETF than the expertise for CE<->FE protocol issues. That, in combination to keep ForCES at a manageable scale, excluded FE<->FE as a deliverable in the ForCES protocol. > 12) This sounds very challenging: > > The variety of FE functionality that the ForCES architecture allows > poses a potential problem for CEs. In order for a CE to > effectively > control a FE, the CE must understand how the FE processes packets. > We therefore REQUIRE that a FE model be created that can > express the > logical packet processing capabilities of a FE. > > .. I'd say that most functionalities differ *a lot* from > vendor to vendor. > Are you really, really sure that you should (or can) express > all of these > in completely independent way *AND* that subsequent use if > it's understood > would be *effective*. Also see other subsections here, like 6.2. The functions do sometimes differ from vendor to vendor. There is an opposing trend going on with the emergence of merchant silicon and network processors that is leading to some convergence of (at least the basic) FE functionalities around one or a few basic models. > 13) Another architectural problem..: > > 6.3. Ordering of Logical Functions > The model MUST be capable of describing the order in which these > logical functions are applied in a FE. The ordering of logical > functions is important in many cases. For example, a NAT function > may change a packet's source or destination IP address. Any number > of other logical functions (e.g., layer 3 forwarding, > ingress/egress > firewall, shaping, accounting) may make use of the source or > destination IP address when making decisions. The CE needs to know > whether to configure these logical functions with the pre-NAT or > post-NAT IP address. [...] > > .. so are we talking about N! possible orderings (with N > possible logical > functions). Seems like a horror ("pre-nat post-qos-meter > pre-qos-classification pre-forward-do-something foo bar boo > baf"-state). The difference between English and nonsense is that one can combine letters (and words) in any order, but one can only make an English word or sentence if one follows certain rules of grammar. Same for routers. Given a repertoire of the most well known functions (words), it is likely that a few particular configurations (sentences) will be common. That being said: I expect initially that ForCES will only work for the most basic configs, enabling interoperability between simple devices, or devices that have been pre-tested with each other. That is a good step forward from today, even if it isn't the ultimate goal of plug-n-play any CE to FE. This is not uncommon in IETF. VoIP (RTP/SIP/etc) is a good example of where a complex problem required starting simple, doing interop tests, interop profiles, plugfests, etc., and still doesn't have true off-the-shelf 100% interop, but has nevertheless provided significant value. > 14) I'm having difficulties parsing the actual requirements in: > > 8)Off-loaded Functions > > .. do you require that basically any piece of code CE wants > to offload to > FE's must be supported as long it's expressed as a finite > state machine.. > or what? That that code is to be executed on all (or a > specified portion > of) the packets? Others felt the same way, this is being removed as we speak. > 15) I don't disagree that security must be supported (btw. > nit: s/make private/encrypt/), but..: Disagree on the nit: Making private might be a secure Ethernet cable, but encrypt is a mathematic function. What we want is privacy, the means arrived at doesn't matter (for the reqs at least). > 2)Support for Secure Communication > a) FE configuration will contain information critical to the > functioning of a network (e.g. IP Forwarding Tables). > As such, it > MUST be possible to ensure the authenticity and integrity of > ForCES protocol messages. > b) FE configuration information may also contain > information derived > from business relationships (e.g. service level agreements). > Therefore, it MUST be possible to secure (make private) ForCES > protocol messages. > > .. I'm not sure how applicable this is in in most/some > scenarios. For > example, if the interconnect between CE and FE's is a > shared/dedicated > bus, e.g. an Ethernet link, I'm not sure how applicable these are. > Basically if the control messages traverse over the Internet, > they should > be securable. I'm not sure how one considers the possible deployment > scenarios, but I don't think over-the-Internet case is too common > (typically hinting at CE/FE located in a different NE). See above & I agree. A shared/dedicated bus is private, but not encrypted. The privacy requirement is there, just met by other means (physically secure wire). Requirements are being updated to capture this. > 16) on the use of reliable protocols: > > 4)Multihop > When the CEs and FEs are separated beyond a single hop, the ForCES > protocol will make use of an existing RFC2914 compliant L4 protocol > with adequate reliability, security and congestion control (e.g. > TCP, SCTP) for transport purposes. > > ==> I fail to see the added value of a separate protocol for > singlehop links; there, the latency is low and reliable protocols > should be quite usable. Running TCP over a tightly coupled backplane e.g. PCI seems to some like overkill. I think it might be ok even there but the requirements isn't the place to say that - requirements is instead being slightly rewritten to focus on what the actual reliability/retransmit requirements are. The framework and protocol drafts will then specify how they answer those requirements, and one valid answer might be "we do this by using TCP in all cases". I personally am a fan of assuming a reliable transport, however, at least one of the proposed forces protocol builds in reliability itself as needed. Excluding it via requirements seems an improper approach. > 17) security considerations should be properly written out, a > blind referral insufficient: > > 9. Security Considerations > > See architecture requirement #5 and protocol requirement #2. Will be done. > > > Semi-editorial: > --------------- > > CEs may consist of PCE partitions or whole > PCEs. > > ==> what about 'multiple PCEs' (compare to the text of FE's) ? Ok. > Post-association Phase - The period of time during which a FE does > know which CE is to control it and vice versa, > > ==> is "FE controlling CE" (through vice versa) ? I think not? Good catch. Will be fixed. > 2) FEs MUST support a minimal set of capabilities necessary for > establishing network connectivity (e.g., interface discovery, port > up/down functions). Beyond this minimal set, the ForCES > architecture MUST NOT restrict the types or numbers of capabilities > that FEs may contain. > > ==> it is not unambiguous what the last sentence tries to > say; does it > take a stance that at least a minimum set of capability types must be > supported, that ForCES must work in the presence of any > possible set of > capabilities, or what.. It says the first thing you posited, that being said, will have text clarified. > 9) Any proposed ForCES architectures MUST explain how that > architecture supports all of the router functions as defined in > [RFC1812]. > > ==> this must be elaborated. RFC1812 is a long RFC, and no proposal > should be expected to go through all of these functions! > Clearly there are certain specific issues which need to be addressed here... Framework document actually does go through 1812 pretty well. > 10) In a ForCES NE, the FEs MUST be able to provide their topology > information (topology by which the FEs in the NE are connected) to > the CE(s). > > ==> the wording in ()'s doesn't really clarify much and should be > rewritten; also, it's rather difficult to understand. Same > in the second version of this req. OK > > We therefore REQUIRE that a FE model be created that can > express the > > ==> REQUIRE is not a proper RFC2119 keyword. Will fix. > 2)Forwarding Functions > The FE model MUST be capable of expressing the data that > can be used > by the forwarding function to make a forwarding decision. Support > for IPv4 and IPv6 unicast and multicast forwarding > functions MUST be > provided by the model. > > ==> just as a comment, I fear multicast functions may be > significantly more difficult to provide than unicast. I agree, I know of at least two quite different ways multicast has been internally supported in routers. Will be one of the more difficult parts of forces imho. > The FE model SHOULD be extensible so that new, currently > unknown FE > functionality can be expressed. The FE Model SHOULD NOT be extended > to express standard/common functions in a proprietary manner. This > would NOT be ForCES compliant. > > ==> NOT is not a proper RFC2119 keyword. Ok. > 5)Message Priority > The ForCES protocol MUST provide a means to express the protocol > message priorities. > > ==> should this be elaborated? Ie., do you mean in the case protocol > messages get queued and some messages are more important than > others so > they'll be able to overtake the queue? (and not e.g. in > TOS/traffic class > context.) Note that this may have quite interesting implications for > multipart or sequenced commands, so prioritizing should be > used with care. Will be elaborated. Example of what is meant here is that the message to install a filter to drop all SYNs from a certain attacker should get priority treatment over nearly all the other traffic going across the backplane (including those SYNs). > 9)Packet Redirection/Mirroring > a) The ForCES protocol MUST define a way to redirect > packets from the > FE to the CE and vice-versa. Packet redirection terminates any > further processing of the redirected packet at the FE. > > ==> when redirected from CE to FE, the latter sentence does not parse > properly. True - redirected from FE to CE, and originated by CE and sent via FE to another network element. Will get fixed. > > > Editorial: > ---------- > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. Internet-Drafts are > working documents of the Internet Engineering Task Force (IETF), > its areas, and its working groups. Note that other groups may > also distribute working documents as Internet-Drafts. > [...] > > ==> the boilerplate is not as-is. Ok, will fix. > Conventions used in this document > > ==> I'd place this under a numbered section, at the introduction or > something, but I'm not sure if there is a strict policy on that. Will check nits. > 1. Abstract > > ==> abstract must not be numbered, per ID-nits etc. Hmm. Damn sneaky nits always get through. Been over this doc twice looking for nits already! > Khosravi, Anderson, et. al. Expires July 2003 [Page 1] > > ==> this should be either "Khosravi, et al." or "Khosravi & Anderson" > (rfc-ed policy) Didn't know this one, will get fixed. Does this apply even when there are two editors? > 8. > References.....................................................13 > 8.1. Normative > References...........................................13 > 8.2. Informative > References.........................................13 > 9. Security > Considerations........................................13 > 10. Authors' Addresses & > Acknowledgments..........................14 > 11. Editors' Contact > Information..................................15 > > ==> personally I'd like sec considerations before references > (that's the more typical way), but that's not a strict rule. Seems reasonable. > ==> note that IPR & copyright statements are also missing, > but those can be added later on too. Assumed those would be added by RFC-editor, can add it now. > entities that cooperate to provide a given functionality (such as a > routing or IP switching) and yet appear as a normal integrated > > ==> s/a routing/routing/ > > For the purpose of illustration, let us consider the > architecture of > a router to illustrate the concept of separate control and > > ==> please try not to use the word "illustrate" twice. > > architectures include Ethernet,bus backplanes, and ATM (cell) > > ==> s/,bus/, bus/ > > ForCES protocol elements from joining a NE.(For more protocol > > ==> s/(/ (/ > > requirement #1) > details, refer to section 7 requirement# 2) > > ==> choose the format how to refer to requirements and be > consistent; I > prefer " #x" rather than "# x" but YMMV. Will make it so. Thanks for the detailed technical and editorial feedback! -David From rtg-dir-admin@ietf.org Wed Apr 9 14:27:18 2003 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08715 for ; Wed, 9 Apr 2003 14:27:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39IX4816626; Wed, 9 Apr 2003 14:33:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39IWo816578 for ; Wed, 9 Apr 2003 14:32:50 -0400 Received: from merlot.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08680 for ; Wed, 9 Apr 2003 14:27:01 -0400 (EDT) Received: from rcallon-lt.juniper.net (securepptp025.static.jnpr.net [172.24.253.25]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h39ITSu68755; Wed, 9 Apr 2003 11:29:28 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20030409124113.02c5e340@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 09 Apr 2003 12:45:43 -0400 To: Alex Zinin , "Putzolu, David" , Patrick Droz (dro@zurich.ibm.com) From: Ross Callon Subject: Terminology NIT Re: Fwd: Re: draft-ietf-forces-requirements-08.txt Cc: rtg-dir@ietf.org, Pekka Savola , randy@psg.com In-Reply-To: <190133858458.20030407105619@psg.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > By allowing the control and > forwarding planes to evolve independently, different types of FEs > can be developed - some general purpose and others more specialized. > >.. this seems a bit questionable: different types of FEs can already be >developed, and have been developed for a long time now. What you're >aiming for is mixing and matching a CE one or more FE's with a standard >protocol with different characteristics and possibly different vendors. Are we concerned about the fact that the abbreviation CE refers to a Control Element in Forces, and also refers to Customer Edge devices for L2 and L3 VPNs? This seems slightly worse than the double use of LSP (Link State Packet, and Label Switched Path) since if FORCES is used at all then the context is likely to overlap: Specifically, customer edge equipment which supports VPNs might use Forces technology. Thus the CE (customer edge device in VPN speak) consists of an NE (Network Element in Forces speak) which in turn is made up of a CE (Control Element) and an FE. How about Control Processor or CP? Ross From rtg-dir-admin@ietf.org Fri Apr 11 10:22:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14358 for ; Fri, 11 Apr 2003 10:22:35 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193zAB-0002Xh-00 for rtg-dir-archive@ietf.org; Fri, 11 Apr 2003 10:05:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193zAB-0002Xe-00 for rtg-dir-archive@ietf.org; Fri, 11 Apr 2003 10:05:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BETE830188; Fri, 11 Apr 2003 10:29:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BESU830100 for ; Fri, 11 Apr 2003 10:28: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 KAA14314 for ; Fri, 11 Apr 2003 10:21:49 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193z9R-0002X1-00 for rtg-dir@ietf.org; Fri, 11 Apr 2003 10:05:09 -0400 Received: from dns.nexthop.com ([64.211.218.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 193z9Q-0002Wl-00 for rtg-dir@ietf.org; Fri, 11 Apr 2003 10:05:08 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h3BENqtM026389; Fri, 11 Apr 2003 10:23:52 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h3BENnox026382; Fri, 11 Apr 2003 10:23:49 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h3BENih15527; Fri, 11 Apr 2003 10:23:44 -0400 (EDT) Date: Fri, 11 Apr 2003 10:23:44 -0400 From: Jeffrey Haas To: Radia Perlman - Boston Center for Networking Cc: rtg-dir@ietf.org Subject: Re: Site-Locals Message-ID: <20030411102343.F3481@nexthop.com> References: <200304071729.h37HT1016467@sydney.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200304071729.h37HT1016467@sydney.East.Sun.COM>; from Radia.Perlman@sun.com on Mon, Apr 07, 2003 at 01:29:01PM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Mon, Apr 07, 2003 at 01:29:01PM -0400, Radia Perlman - Boston Center for Networking wrote: > There seems to be a lot of emotion here, and I will admit > I have not been following the arguments. I'm behind in my e-mail, so apologies if this has been noted before. I would like to draw the directorate's attention to: http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-00.txt -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Fri Apr 11 10:34:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15708 for ; Fri, 11 Apr 2003 10:34:21 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193zLZ-0002vQ-00 for rtg-dir-archive@ietf.org; Fri, 11 Apr 2003 10:17:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193zLY-0002vN-00 for rtg-dir-archive@ietf.org; Fri, 11 Apr 2003 10:17:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BEf2831905; Fri, 11 Apr 2003 10:41:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BEex831875 for ; Fri, 11 Apr 2003 10:40: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 KAA15682 for ; Fri, 11 Apr 2003 10:34:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193zLV-0002uq-00 for rtg-dir@ietf.org; Fri, 11 Apr 2003 10:17:37 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 193zLT-0002sX-00 for rtg-dir@ietf.org; Fri, 11 Apr 2003 10:17:36 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h3BEa6J21823; Fri, 11 Apr 2003 17:36:07 +0300 Date: Fri, 11 Apr 2003 17:36:06 +0300 (EEST) From: Pekka Savola To: "Putzolu, David" cc: "'Alex Zinin'" , "'Patrick Droz'" , "'rtg-dir@ietf.org'" , "'randy@psg.com'" Subject: RE: Re: draft-ietf-forces-requirements-08.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Hi, Sorry for the delay in responding. On Tue, 8 Apr 2003, Putzolu, David wrote: > Thanks for the feedback - responses inlined... > > > Comments on forces-reqs-08. In summary, I'd like to express a very > > grave concern of trying to address every possible problem, a path that > > seems doomed to failure. Note a list of dozen different forwarding > > functionalities that still fail to capture all of them -- and the > > associated complexity of handling all the different nuances and > > orderings of these functions. > > > > Seems way, WAY too complex to make interoperable and useful. I wonder > > how far we have to go with this effort to see it as a dead-end. Or > > alternatively, some other architectural/approach revamp might be able > > to salvage some of the mechanisms (e.g. concentrate on certain core > > tasks only, but then again, one might question how useful the > > mechanism is). > > I agree that trying to define all possible features is > infeasible, as the list is ever-evolving. I also agree > that a reduction to a single feature (e.g. only address > IPv4 forwarding and nothing else), while feasible, is > useless. > > The initial goal of forces is to try to capture that 20% > of features/configurations that applies to 80% of the > applicable scenarios. Ok, I guess it remains to be seen later whether this is the right approach. My worry is that if we don't define the "applicable scenarios" properly (or define wrong scenarios), we might end up specifying the wrong 20%. > > 1) it is not clear how different efforts (most of which referenced in > > the draft) interconnect: e.g. midcom (similar protocol between hosts, > > typically), gsmp, ccamp. > > This seems like a framework question, not a requirements > question. That being said, I will answer as best I can. > Midcom is primarily focused on NAT and ALGs. One could > construct a NAT box using CE/FE separation. If that is the > case, ForCES might be present. Midcom would deliver information > to the CE (e.g. "open this port for a RTP stream as part of > this H.323 call"), the CE would then configure the FE appropriately > ("add ACL entry: pass ports 3310/3311 between hosts A and B"). Yes, that was my impression. > GSMP controls switches. The GSMP authors are following ForCES > pretty closely (one is a co-author on the requirements). Thus > far ForCES has focused on CE/FE separation routers (not switches). > Could GSMP be used to control FE routing functions? Yes, but the > GSMP authors have so far not indicated a desire to extend GSMP for > that. Could ForCES be used to control FE switching functions? > Yes, but that would be extending the scope of ForCES significantly. > Is routing enough to satisfy the 80/20 rule, or do you think that > switching must be thrown in as well? Sounds like a scope/charter- > level change, so I'm hesitant to jump into that debate. I got the impression that Ethernet switches (or at least the quite typical switch/routers) were in scope, but I may have misread. > > 2) I find the justification a bit questionable: > > > > A standard set of mechanisms for connecting > > these components provides increased scalability and allows the > > control and forwarding planes to evolve independently, thus > > promoting faster innovation. > > > > .. it seems to me that in practice, such independent evolution and > > innovations typically require changes in both elements: I doubt one > > can create such a generic architecture which would accommodate > > anything happening to the other in the future. > > Anything talking to anything is impossible. A CE talking to successively > faster generations of FEs with IPv4 forwarding and DS support, using the > same standard ForCES protocol, is possible. My experience indicates that typically CE's develop faster than FE's -- due to simplicity of generic programming, rather than implementing hardware functions. But CE's supporting more features than FE's doesn't seem all too useful. > > 3) the applicability of ForCES seems to be unclear, for example: > > > > Addressable Entity (AE) - A physical device that is directly > > addressable given some interconnect technology. For example, on IP > > networks, it is a device to which we can communicate using an IP > > address; and on a switch fabric, it is a device to which we can > > communicate using a switch fabric port number. > > > > .. the latter would seem to indicate some support for non-IP devices > > too, or should this use some rewording to clarify which kind of switch > > fabric was the question was all about? > > ForCES will define a model that applies to FEs that are > network-connected and backplane/fabric connected. > ForCES protocol will then run over IP, ForCES model will be > likely reused for non-IP CE<->FE link scenarios (analogous to > GSMP over Ethernet/GSMP over ATM/GSMP over IP). AE is an > effort to get a term which works equally well in both cases. Ok. > > 4) I haven't delved into ForCES, but the last two sentences look a bit > > scary: > > > > Forwarding Element (FE) - A logical entity that implements the > > ForCES protocol. FEs use the underlying hardware to provide per- > > packet processing and handling as directed by a CE via the ForCES > > protocol. FEs may use PFE partitions, whole PFEs, or > > multiple PFEs. > > > > .. this seems to imply that CE's instruct logical FE's to perform some > > tasks, while there exists some protocol between FE->PFE. > > > > - what is used between FE and PFE's? > > - are there interoperability reqs between FE / PFE's (can > > they be from > > different vendor)? > > - is this useful at all? Seems like very dangerous to me -- > > because might > > require an additional abstraction layer at FE's -- which > > might make the > > CE-FE control even more useless (too generic) and less powerful. > > I agree the wording is bad and it should be fixed. What should > be coming across here is that a FE is what a CE controls. If > under the covers the FE happens to be a single blade, a partition > of a blade, of two physical blades that through proprietary magic > appear as a single very reliable blade to the CE, is beyond the > scope of concern of forces. Yep, clarification will be helpful. > > 5) Is the partitioning concept really useful? Could you list some > > applicability scenarios? > > I will provide some scenarios because you ask, but I personally > am not comfortable arguing for it. The main point I'd like to > make is that ForCES should be agnostic about partitioning issues, > and forcing ForCES to define/care about/create partitioning would > be an undesirable complexity. I totally agree here. > Potential applicability scenario: Service provider wants a > capability to offer hard guarantees to customers that they > get access, performance, and control of what looks like their > own virtual router. SP can either buy a physical box per > customer (expensive) or partition a single physical box into > logical partitions. > > Again - this isn't and shouldn't be for ForCES to spec out. > Main point here is that ForCES shouldn't care if somebody > does partitioning under the covers ahead of time - a FE is a FE. > > > > 6) Is it possible to have multiple CE's manage one FE? This probably > > would have tradeoffs and drawbacks, but is integral when you consider > > the applicability of the protocol (ie. is it a network management > > protocol or control-dataplane protocol). > > Yes - multiple CEs may control one FE. When this happens the CEs > had better make sure to coordinate among each other so that they > don't give contradictory orders to the FE. > > Simple case: 1 CE talking to FE. > Possible case: 2 CEs, from same vendor, speaking proprietary > CE<->CE protocol to coordinate with each other, control parts > of the same FE. > Theoretical case: Somebody defines that CE<->CE protocol and > heterogeneous CEs used. Hard problem and beyond the scope of > ForCES. Perhaps this could be spelled out in the requirements, to some degree; like: Multiple CE's controlling one FE MAY be supported. However, coordination between CE's is out of scope. (or even a bit more, or even more harsh wording.) In addition to listing requirements, it's IMO also useful to list _non-requirements_. But YMMV. > > 7) Is it necessary/useful to keep the ForCES protocol > > open-ended even now? > > I fail to see valid reasons for multiple protocols..: > > > > ForCES Post-Association Phase Protocol - [...] > > This protocol could be a single protocol or > > could consist of multiple protocols working together. > > Looking at router functions, there can be a fairly large > difference between the proportion of CE<->FE "control" traffic > (that is: CE giving new FIB entries to FE, FE reporting alarms > to CE, etc.) and the CE<->FE "data" traffic (that is: OSPF > HELLO and other packets, the SNMP SET/GETs, the TCP SYN > arriving from a peer router setting up a BGP connection). > > Also: The CE<->FE data traffic has quite different reliability > requirements. That is: If a SNMP packet, which arrived over > UDP, gets dropped in transport between FE and CE, it is much > less of a problem than if a CE packet adding an ACL entry > gets dropped going from CE to FE. > > Also: In some architectures there is a physically, or at least > logically (different queue etc) distinct control channel from > data channel. > > Given these different requirements and characterizations, > the ForCES architecture might specify that some traffic > ("data" traffic) gets transported over a lightweight, > unreliable protocol, and other traffic ("control" traffic) > gets transported over a reliable, perhaps even secure, > protocol. > > Mandating in the requirements that all types of CE<->FE > traffic all run over a single protocol/connection just > doesn't seem something a requirements doc should do. Ok, sounds reasonable. I was thinking of specifying multiple protocols for achieving about the same function, which would seem to be wasteful. > > 8) Again, the ForCES model seems quite open-ended: > > > > FE Manager - A logical entity that operates in the pre-association > > phase and is responsible for determining to which CE(s) a FE should > > communicate. This process is called CE discovery and may involve > > the FE manager learning the capabilities of available CEs. A FE > > manager may use anything from a static configuration to a pre- > > association phase protocol (see below) to determine which CE(s) to > > use. Being a logical entity, a FE manager might be physically > > combined with any of the other logical entities mentioned in this > > section. > > > > ... I fail to see the usability of FE's discovering CE(s). Being a > > master-slave association where CE's are masters, I would think it > > would be natural to assume CE's are the masters and thus _they_ > > discover their slave FE's. > > FEM/CEM discovering each other is outside the ForCES scope. > The FEM/CEM concept is included to be able to say basically > "look, we know CEs and FEs need to find each other - and > we don't define how it is done, because we wanted to limit > our scope". > > For the near future I'd expect that a CEM/FEM might be little > more than a human being typing in a CE IP address via the > serial port of the FE and v.v. on the FE. Yep -- could be clarified slightly. > > 9) In the snippet above and some others: it seems to be typical in the > > requirements to overload the terminology with rather long > > architectural descriptions. This has both good and bad sides, but in > > any case it should be considered whether some other way to achieve the > > big picture would be more usable. > > > > Also, there are some terms in the terminology which are not used in > > the document. If this is also meant as a terminology document, this > > might be ok, but otherwise keeping to the minimum might be useful. > > This is actually something I've never gotten a good answer > to. In dealing with terminology, what is the BKM? Is it: > A) Put all terms we know we will need in the first doc > (in this case reqs), adding deltas to later docs once > reqs is published, or > B) Put in reqs only terms used in reqs - each doc defines > all the terms it uses, or > C) Put a separate terminology doc. > > I think C doesn't work because it would be a normative > ref that would hold up other docs from progressing. > Not sure whether to do A or B though - do you think B > is the best approach? C is not all that useful here. I don't have a strong opinion on A) vs B). Personally, I'd probably try to keep the list as simple as possible, to the extent of understanding the requirements .. and put the rest in framework, usage model or other documents where the model is expanded. > > > 10) The list of FE functions below is extensive: > > > > Some functions that FEs could perform include layer 3 forwarding, > > metering, shaping, firewall, NAT, encapsulation (e.g., tunneling), > > decapsulation, encryption, accounting, etc. Nearly all > > combinations > > of these functions may be present in practical FEs. > > > > .. but in reality, gives little hope, as the list is far from > > complete, and completely evolving. It seems apparent that if one > > tries to standardize all the possible functions, with *a lot* of > > abstractization, this is a source of a LOT of work, and work that's > > never going to end. > > > > .. so, it might be useful to consider the scope: deal with > > the most basic form of forwarding, and that only, for now. > > The section that appears with is just giving an architectural > overview. The model document is chartered with specifying exactly > what functions will be tackled by ForCES v1. Most likely it will > be a shorter list as you suggest. Then my suggestion would be to shorten the list of functions a bit. E.g. encapsulation, NAT, decapsulation, and encryption seem something that seem the most redundant of those listed. Or cut it even more dramatically. > > 11) The last sentence here implies a possible disconnect in the > > architecture: > > > > 1) CEs and FEs MUST be able to connect by a variety of interconnect > > technologies. Examples of interconnect technologies used > > in current > > architectures include Ethernet,bus backplanes, and ATM (cell) > > fabrics. FEs MAY be connected to each other via a different > > technology than that used for CE/FE communication. > > > > ==> Is it intended to connect FE's to CE or provide a FE-FE protocol? > > Having some interconnection and/or protocol between FE's seems useful > > in a sense, but also potentially out of scope of this architecture. > > The goal of this section is to explain that the CE<->FE wire (which is > what forces cares about) may or may not be the same as the FE<->FE wire. Please state that the latter is out of scope ? > There are some efforts going on to look at FE<->FE protocol. > However, the expertise involved (fast path data plane issues, > state sharing between forwarding devices) is somewhat less > likely to be found in IETF than the expertise for CE<->FE > protocol issues. That, in combination to keep ForCES at a > manageable scale, excluded FE<->FE as a deliverable in the > ForCES protocol. Good. > > 12) This sounds very challenging: > > > > The variety of FE functionality that the ForCES architecture allows > > poses a potential problem for CEs. In order for a CE to > > effectively > > control a FE, the CE must understand how the FE processes packets. > > We therefore REQUIRE that a FE model be created that can express > > the > > logical packet processing capabilities of a FE. > > > > .. I'd say that most functionalities differ *a lot* from vendor to > > vendor. Are you really, really sure that you should (or can) express > > all of these in completely independent way *AND* that subsequent use > > if it's understood would be *effective*. Also see other subsections > > here, like 6.2. > > The functions do sometimes differ from vendor to vendor. > There is an opposing trend going on with the emergence of > merchant silicon and network processors that is leading > to some convergence of (at least the basic) FE > functionalities around one or a few basic models. If you say so. > > 13) Another architectural problem..: > > > > 6.3. Ordering of Logical Functions > > The model MUST be capable of describing the order in which these > > logical functions are applied in a FE. The ordering of logical > > functions is important in many cases. For example, a NAT function > > may change a packet's source or destination IP address. Any number > > of other logical functions (e.g., layer 3 forwarding, > > ingress/egress > > firewall, shaping, accounting) may make use of the source or > > destination IP address when making decisions. The CE needs to know > > whether to configure these logical functions with the pre-NAT or > > post-NAT IP address. [...] > > > > .. so are we talking about N! possible orderings (with N > > possible logical > > functions). Seems like a horror ("pre-nat post-qos-meter > > pre-qos-classification pre-forward-do-something foo bar boo > > baf"-state). > > The difference between English and nonsense is that one > can combine letters (and words) in any order, but one > can only make an English word or sentence if one follows > certain rules of grammar. > > Same for routers. Given a repertoire of the most well known > functions (words), it is likely that a few particular > configurations (sentences) will be common. I seem to have different kind of routers in mind. Of course, one could try to do some "pattern recognition" or whatever, but I'm not sure how useful such would be. > That being said: I expect initially that ForCES will only > work for the most basic configs, enabling interoperability > between simple devices, or devices that have been pre-tested > with each other. That is a good step forward from today, > even if it isn't the ultimate goal of plug-n-play any CE > to FE. This is not uncommon in IETF. VoIP (RTP/SIP/etc) > is a good example of where a complex problem required starting > simple, doing interop tests, interop profiles, plugfests, etc., > and still doesn't have true off-the-shelf 100% interop, but > has nevertheless provided significant value. There is a difference of "interoperability issues due to differently implemented standards" and "interoperability issues due to different ways non-standard, purposely implementation-specific features are implemented". In ForCES, the problem space is of the latter, which is much more difficult. It can be attacked e.g. by abstraction layers, but a danger is that by too much abstraction, the operation becomes very complex and you may lose the original data the abstractization is based on. > > 14) I'm having difficulties parsing the actual requirements in: > > > > 8)Off-loaded Functions > > > > .. do you require that basically any piece of code CE wants to offload > > to FE's must be supported as long it's expressed as a finite state > > machine.. or what? That that code is to be executed on all (or a > > specified portion of) the packets? > > Others felt the same way, this is being removed as we speak. Ok, good. > > 15) I don't disagree that security must be supported (btw. > > nit: s/make private/encrypt/), but..: > > Disagree on the nit: Making private might be a secure Ethernet > cable, but encrypt is a mathematic function. What we want is > privacy, the means arrived at doesn't matter (for the reqs at > least). Ok, I can agree with the distinction but I'd still argue on rewording it otherwise; "make private" doesn't sound too good. "Ensure privacy"? (privacy is also a bit dubious word..). > > 2)Support for Secure Communication > > a) FE configuration will contain information critical to the > > functioning of a network (e.g. IP Forwarding Tables). > > As such, it > > MUST be possible to ensure the authenticity and integrity of > > ForCES protocol messages. > > b) FE configuration information may also contain > > information derived > > from business relationships (e.g. service level agreements). > > Therefore, it MUST be possible to secure (make private) ForCES > > protocol messages. > > > > .. I'm not sure how applicable this is in in most/some scenarios. > > For example, if the interconnect between CE and FE's is a > > shared/dedicated bus, e.g. an Ethernet link, I'm not sure how > > applicable these are. Basically if the control messages traverse over > > the Internet, they should be securable. I'm not sure how one > > considers the possible deployment scenarios, but I don't think > > over-the-Internet case is too common (typically hinting at CE/FE > > located in a different NE). > > See above & I agree. A shared/dedicated bus is private, but not > encrypted. The privacy requirement is there, just met by other means > (physically secure wire). Requirements are being updated to capture this. Ok. > > 16) on the use of reliable protocols: > > > > 4)Multihop > > When the CEs and FEs are separated beyond a single hop, the ForCES > > protocol will make use of an existing RFC2914 compliant L4 protocol > > with adequate reliability, security and congestion control (e.g. > > TCP, SCTP) for transport purposes. > > > > ==> I fail to see the added value of a separate protocol for > > singlehop links; there, the latency is low and reliable protocols > > should be quite usable. > > Running TCP over a tightly coupled backplane e.g. PCI seems to some > like overkill. I agree -- but then again, such backplanes are not places for an IP protocols, probably. > I think it might be ok even there but the requirements > isn't the place to say that - requirements is instead being slightly > rewritten to focus on what the actual reliability/retransmit requirements > are. The framework and protocol drafts will then specify how they answer > those requirements, and one valid answer might be "we do this by using TCP > in all cases". Ok. [snip] > > 9) Any proposed ForCES architectures MUST explain how that > > architecture supports all of the router functions as defined in > > [RFC1812]. > > > > ==> this must be elaborated. RFC1812 is a long RFC, and no proposal > > should be expected to go through all of these functions! > > Clearly there are certain specific issues which need to be addressed > here... > > Framework document actually does go through 1812 pretty well. Good .. but here, the requirement above will need to be clarified too, though. [snip] > > Khosravi, Anderson, et. al. Expires July 2003 [Page 1] > > > > ==> this should be either "Khosravi, et al." or "Khosravi & Anderson" > > (rfc-ed policy) > > Didn't know this one, will get fixed. Does this apply even > when there are two editors? For one author: Doe for two authors, it can be: Doe & Dee for more: Doe et al. (or so I've understood it.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-dir-admin@ietf.org Fri Apr 11 15:28:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26428 for ; Fri, 11 Apr 2003 15:28:15 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1944Ed-00054Q-00 for rtg-dir-archive@ietf.org; Fri, 11 Apr 2003 15:30:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1944Ed-00054M-00 for rtg-dir-archive@ietf.org; Fri, 11 Apr 2003 15:30:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BJZ1820993; Fri, 11 Apr 2003 15:35:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BJY7820958 for ; Fri, 11 Apr 2003 15:34: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 PAA26415 for ; Fri, 11 Apr 2003 15:27:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1944Dh-00054I-00 for rtg-dir@ietf.org; Fri, 11 Apr 2003 15:29:54 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1944Dh-00054E-00 for rtg-dir@ietf.org; Fri, 11 Apr 2003 15:29:53 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 1944Dg-000GLQ-00; Fri, 11 Apr 2003 12:29:52 -0700 Date: Fri, 11 Apr 2003 12:29:34 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <19510103067.20030411122934@psg.com> To: Ross Callon CC: Acee Lindem , rtg-dir@ietf.org Subject: Re: Under IESG review: draft-coene-sctp-multihome-03.txt In-Reply-To: <4.3.2.20030409135817.02c5c208@zircon.juniper.net> References: <3E8B6F10.10309@redback.com> <2077125700.20030329105903@psg.com> <3E8B48A2.7020905@redback.com> <14099157040.20030402150636@psg.com> <3E8B6F10.10309@redback.com> <4.3.2.20030409135817.02c5c208@zircon.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ross, Thanks a lot for your comments! I'll forward them to the IESG. -- Alex http://www.psg.com/~zinin/ Wednesday, April 9, 2003, 11:24:41 AM, Ross Callon wrote: > At 04:37 PM 4/2/2003 -0800, Alex Zinin wrote: >>...That part was fine. How about this: >> >> > 2.2 SCTP multihoming and the size of routing tables >> > >> > As multihoming means that more than one destination address is used >> > on the host, that would mean that a routing descision must be made >> > on the host in IP. The host does not know beforehand to which other >> > host it is going to send something, so that would in theory require >> > that all possible paths to all possible destinations should be known >> > on that host. This amounts to the host being a part of the >> > distribution of the routing information in the network. > I think that it would be a big mistake to have hosts (including servers) > running routing protocols, for several reasons (there are probably other > reasons as well): > 1. It increases the number of nodes running routing, which may have > scaling implications. > 2. It makes it harder to secure the routing infrastructure (the set of all > hosts in any given network have a larger number of services turned on > than the set of routers -- making them more susceptible to worms, > for example -- also, some of the hosts listening in might be looking > for information that they can use to attack, for example, by highjacking > a BGP session). I think that there are many ways that this opens up > holes in the security of the routing infrastructure. > On the other hand, the above paragraph is not completely clear to me > regarding whether it says that hosts run routing protocols. It might mean > that hosts listen in on routing protocols (which has other implications, > such as the need to figure out whether to reliably transfer LSAs/LSPs > to hosts, and how hosts listen in on BGP -- which we might not want > them to do). Alternatively, it might mean that routers pass routing > information to hosts in some manner. > This ambiguity would appear to be another problem. > Also, an excerpt from section 2.1 (just after figure 2.1.4): >> As a practical matter, it is recommended that IP addresses in a >> multihomed endpoint be assigned IP endpoints from different TLA's >> to ensure against network failure. > Aren't TLAs "top level aggregates"? This doesn't make any sense to > me. Are they saying that hosts should be multi-homed to completely > different backbone providers, so that if one major provider goes down > it can use another one? In many cases hosts might want to be multi- > homed to the same provider, and use two addresses which are both > from that provider's space. Alternatively, hosts might be multi-homed > to two different network segments internal to the same corporate > network, and the corporate network might itself be multi-homed to > the same large service provider. The host might have two different > addresses, but not necessarily from different TLAs. > One minor nit: The acronym TLA is not actually defined in this document. > The document only lists some issues, and in most cases doesn't give > a clear indication regarding what the solution to the issues are. I don't > think that it even clearly states the issues. > Thus I guess at some level I don't see the point. > Ross From rtg-dir-admin@ietf.org Wed Apr 16 14:32:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11186 for ; Wed, 16 Apr 2003 14:32:48 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195rkc-000354-00 for rtg-dir-archive@ietf.org; Wed, 16 Apr 2003 14:35:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195rkc-000350-00 for rtg-dir-archive@ietf.org; Wed, 16 Apr 2003 14:35:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GIg0812784; Wed, 16 Apr 2003 14:42:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GIfN812750 for ; Wed, 16 Apr 2003 14:41: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 OAA11105 for ; Wed, 16 Apr 2003 14:32:09 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195rjz-00034m-00 for rtg-dir@ietf.org; Wed, 16 Apr 2003 14:34:39 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 195rjy-00034i-00 for rtg-dir@ietf.org; Wed, 16 Apr 2003 14:34:38 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 195rjk-0008X4-00; Wed, 16 Apr 2003 18:34:24 +0000 Date: Wed, 16 Apr 2003 11:33:51 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <16144077670.20030416113351@psg.com> To: Alex Zinin CC: Routing Area Directorate , Acee Lindem , Brad Neal , Christian Martin , Stefano Previdi , Tony Li , Tony Przygienda Subject: Re: Comments on In-Reply-To: <13117088053.20030329220505@psg.com> References: <3E73E362.3010802@redback.com> <13117088053.20030329220505@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Guys, Below's the list of my thoughts in addition to the comments Acee brought. Regards. -- Alex http://www.psg.com/~zinin/ Comments: In order to preserve interoperability with tag-unaware routers, I think we should add some words saying that the implementations MUST NOT change their SPF calculation based on the contents of the introduced TLVs. Thinking aloud: though the mechanism is inherently opaque, if we want the implementations claiming their compliance to it to really be usable for [from the doc] "controlling redistribution between levels and areas, different routing protocols", should we say that compliant implementations SHOULD support such filtering? On the one hand, there's a wide spectrum of applications that can use these tags and we don't want to say foo and bar are the only ones, on the other hand if I were deploying this in a multi-vendor environment, I'd likely want to see a consistent minimal set of features, i.e., not just attaching a tag, but also executing on it if the router is a L1/L2 or an ASBR. Did you guys think about this? What I think is missing in the draft is specification of how multiple instances of the same sub-TLV should be treated, i.e., I could see some implementations deciding to merge the tag sets, and some using just the first (or the last) instance, which would result in interop issues. Should be spelled out, I think. A similar, and somewhat more interesting question is about the two types of tags--32 bits and 64 bits. Since the value spaces for the two are overlapping, i.e., there's a range {x}, where X can be coded as both 32 and 64 bits, should the implementations consider the two TLVs as operating on a single large 64-bit space (with one covering only half the space, and one covering the whole thing), or on two separate ones with different sizes. In other words, if my policy says "match tag 234", should it match both a 32- and a 64-bit tag, or should it differentiate between the two and operate more in a way of "match tag-32 234" and "match tag-64 234"? I could see how different implementations could treat this differently and I could get different route filtering results given the same input data. There will also be a question in the IESG on why do we need a 32-bit tag if we have a 64-bit one, which could accommodate 32-bit values too. Do we have an answer besides "some folks believed 32 bits is enough in most cases, but other folks had a case where 64 bits would be more convenient"? > 6. Ordering of Tags > > The semantics of the tag order are implementation-dependent. That > is, there is no implied meaning to the ordering of the tags that > indicates a certain operation or set of operations need be performed, > based on the order of the tags. Each tag SHOULD be treated as an > autonomous identifier that MAY be used in policy to perform a policy > action. Whether or not tag A preceeds or succeeds tag B SHOULD not > change the meaning of the tag set. However, an implementation MAY > wish to preserve tag ordering such that an ordered set of tags has > meaning to the local policy. To preserve tag ordering where? Within the TLV? (a pseudo-question really, since one shouldn't change someone else's TLV contents) > 7. A compliant IS-IS implementation: > MUST be able to assign one tag to any IP prefix in TLV(s) 135 and/or > 235. There will be a question on whether attaching both TLV types MUST be supported by an implementation, or just one of them. I think we need to say both. > 10. IANA Considerations > > The authors have chosen "1" as the typecode of the 32-bit > Administrative Tag sub-TLV and "2" as the typecode of the 64-bt > Administrative Tag SubTLV. These values must be allocated by IANA. Change to "This document defines..."? Nits below: > 1. Status of this Memo Shouldn't be numbered > 2. Abstract The rfc-ed will not like the references in the abstract, please remove. > 5.1. 32-bit Administrative Tag Sub-TLV 1 > > The Administrative Tag shall be encoded as one or more 4 octet > unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 235 [6]. The > Administrative Tag Sub-TLV has following structure: > > 1 octet of type (value: 1) > 1 octet of length (value: multiple of 4) > one or more instances of 4 octets of administrative tag Would be great if we had the same format as in RFC1195, or 3373 for consistency. Using IETF format is an option too. Ditto for 5.2 > 12. References Please split them to normative and informative like below: 12. Normative References [1] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO 10589. [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering", Internet Draft, "Work in Progress", September 2000. [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution with Two-Level IS-IS" RFC 2966, October 2000 13. Informative References [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus, J., "Requirements for Traffic Engineering Over MPLS," RFC 2702, September 1999. [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April 2002. From rtg-dir-admin@ietf.org Thu Apr 17 09:26:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20251 for ; Thu, 17 Apr 2003 09:26:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1969Rr-0007mR-00 for rtg-dir-archive@ietf.org; Thu, 17 Apr 2003 09:29:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1969Rq-0007mO-00 for rtg-dir-archive@ietf.org; Thu, 17 Apr 2003 09:29:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HDaF802386; Thu, 17 Apr 2003 09:36:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HDY0802256 for ; Thu, 17 Apr 2003 09:34: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 JAA20202 for ; Thu, 17 Apr 2003 09:24:23 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1969Pe-0007m4-00 for rtg-dir@ietf.org; Thu, 17 Apr 2003 09:26:50 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1969Pd-0007lj-00 for rtg-dir@ietf.org; Thu, 17 Apr 2003 09:26:49 -0400 Received: from there (ams-clip-vpn-dhcp4256.cisco.com [10.61.80.159]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id h3HDQRR06975; Thu, 17 Apr 2003 15:26:27 +0200 (CEST) Message-Id: <200304171326.h3HDQRR06975@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: Alex Zinin Subject: Re: Comments on Date: Thu, 17 Apr 2003 15:26:13 +0200 X-Mailer: KMail [version 1.3.1] Cc: Routing Area Directorate , Acee Lindem , Brad Neal , Christian Martin , Tony Li , Tony Przygienda References: <3E73E362.3010802@redback.com> <13117088053.20030329220505@psg.com> <16144077670.20030416113351@psg.com> In-Reply-To: <16144077670.20030416113351@psg.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3HDY1802259 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Alex, thanks for your comments... see mine below... and sorry for the delay. On Wednesday 16 April 2003 20:33, Alex Zinin wrote: > Guys, > > Below's the list of my thoughts in addition to the comments > Acee brought. > > Regards. > > -- > Alex > http://www.psg.com/~zinin/ > > Comments: > > In order to preserve interoperability with tag-unaware routers, I > think we should add some words saying that the implementations MUST > NOT change their SPF calculation based on the contents of the > introduced TLVs. I disagree mainly because the two things (tags and SPF computation) are not related. You _may_ want to give to SPF some indications about tagged prefixes, but this is a local matter and your routing tables should be consistent across the network (and you don't need a draft telling you this). Specifying that you "MUST NOT" do this or that, is outside of the scope of this draft. > Thinking aloud: though the mechanism is inherently opaque, if we want > the implementations claiming their compliance to it to really be > usable for [from the doc] "controlling redistribution between levels > and areas, different routing protocols", should we say that compliant > implementations SHOULD support such filtering? no. it's just a feature that could hlep (and not even in all cases). > On the one hand, > there's a wide spectrum of applications that can use these tags and we > don't want to say foo and bar are the only ones, on the other hand if > I were deploying this in a multi-vendor environment, I'd likely want > to see a consistent minimal set of features, i.e., not just attaching > a tag, but also executing on it if the router is a L1/L2 or an ASBR. > Did you guys think about this? yes, and again I don't believe it's the role of the draft to tell you what to do with this subTLV. The draft just specifies the data. What you do with this data is a matter of applications that are well outside the scope of the draft. > What I think is missing in the draft is specification of how multiple > instances of the same sub-TLV should be treated, i.e., I could see > some implementations deciding to merge the tag sets, and some using > just the first (or the last) instance, which would result in interop > issues. Should be spelled out, I think. yes, you can give some hints. At the origin we said that in case of multiple tags and a router supporting only one, then you should take the first. I know at least one major implementation that does this...;-) > A similar, and somewhat more interesting question is about the two > types of tags--32 bits and 64 bits. don't tell me this...;-) > Since the value spaces for the two > are overlapping, i.e., there's a range {x}, where X can be coded as > both 32 and 64 bits, should the implementations consider the two TLVs > as operating on a single large 64-bit space (with one covering only > half the space, and one covering the whole thing), or on two separate > ones with different sizes. In other words, if my policy says "match > tag 234", should it match both a 32- and a 64-bit tag, or should it > differentiate between the two and operate more in a way of "match > tag-32 234" and "match tag-64 234"? it's a local matter... I believe. Also, I believe the implementation should not have a command like "match tag" but rather I prefer to see "match tag-32" or "match tag-64". If you want to cover the case where only "match tag" is available, then you enter the complicated world of default interpretation of values... I don't really like this... > I could see how different > implementations could treat this differently and I could get different > route filtering results given the same input data. > > There will also be a question in the IESG on why do we need a 32-bit > tag if we have a 64-bit one, which could accommodate 32-bit values > too. because we already have an implementation using 32 bits and sincerely I did never understand the need of 64 bits... > Do we have an answer besides "some folks believed 32 bits is > enough in most cases, but other folks had a case where 64 bits would > be more convenient"? the answer is "we _had_ 32 bits and someone said that 64 is needed"... I'm waiting for thew next one asking me 128 bits... > > 6. Ordering of Tags > > > > The semantics of the tag order are implementation-dependent. That > > is, there is no implied meaning to the ordering of the tags that > > indicates a certain operation or set of operations need be performed, > > based on the order of the tags. Each tag SHOULD be treated as an > > autonomous identifier that MAY be used in policy to perform a policy > > action. Whether or not tag A preceeds or succeeds tag B SHOULD not > > change the meaning of the tag set. However, an implementation MAY > > wish to preserve tag ordering such that an ordered set of tags has > > meaning to the local policy. > > To preserve tag ordering where? Within the TLV? (a pseudo-question > really, since one shouldn't change someone else's TLV contents) except when you do route-leaking. You may receive a set of tags in one level and change them for the other level. Please, don't ask me a real case scenario for this...;-) > > 7. A compliant IS-IS implementation: > > > MUST be able to assign one tag to any IP prefix in TLV(s) 135 and/or > > 235. > > There will be a question on whether attaching both TLV types MUST be > supported by an implementation, or just one of them. I think we need > to say both. I don't think so. the subTLV is optional anyway. > > 10. IANA Considerations > > > > The authors have chosen "1" as the typecode of the 32-bit > > Administrative Tag sub-TLV and "2" as the typecode of the 64-bt > > Administrative Tag SubTLV. These values must be allocated by IANA. > > Change to "This document defines..."? I'll let the original author to fix the editorial issues. Brad, Christian ? s. > Nits below: > > > 1. Status of this Memo > > Shouldn't be numbered > > > 2. Abstract > > The rfc-ed will not like the references in the abstract, > please remove. > > > 5.1. 32-bit Administrative Tag Sub-TLV 1 > > > > The Administrative Tag shall be encoded as one or more 4 octet > > unsigned integers using Sub-TLV 1 in TLV-135 [3] and TLV 235 [6]. The > > Administrative Tag Sub-TLV has following structure: > > > > 1 octet of type (value: 1) > > 1 octet of length (value: multiple of 4) > > one or more instances of 4 octets of administrative tag > > Would be great if we had the same format as in RFC1195, or 3373 > for consistency. Using IETF format is an option too. > > Ditto for 5.2 > > > > 12. References > > Please split them to normative and informative like below: > > 12. Normative References > > [1] "Intermediate System to Intermediate System Intra-Domain Routeing > Exchange Protocol for use in Conjunction with the Protocol for > Providing the Connectionless-mode Network Service (ISO 8473)", > ISO 10589. > > [2] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and > dual environments", RFC 1195, December 1990. > > [3] Li, T., and Smit, H., "IS-IS extensions for Traffic Engineering", > Internet Draft, "Work in Progress", September 2000. > > [5] Li,T., Przygienda, T., Smit, H., "Domain-wide Prefix Distribution > with Two-Level IS-IS" RFC 2966, October 2000 > > 13. Informative References > > [4] Adwuche, D., Malcolm, J., Agogbua, M., O'Dell, M. and McManus, > J., "Requirements for Traffic Engineering Over MPLS," RFC 2702, > September 1999. > > [6] Przygienda, T., Shen, N., Sheth, N., "M-ISIS: Multi Topology > Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April > 2002. > > From rtg-dir-admin@ietf.org Tue Apr 22 14:58:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20568 for ; Tue, 22 Apr 2003 14:58:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198310-0004E6-00 for rtg-dir-archive@ietf.org; Tue, 22 Apr 2003 15:01:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198310-0004E2-00 for rtg-dir-archive@ietf.org; Tue, 22 Apr 2003 15:01:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MJB2832089; Tue, 22 Apr 2003 15:11:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MJAU832054 for ; Tue, 22 Apr 2003 15:10: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 OAA20183; Tue, 22 Apr 2003 14:50:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1982t9-0004AQ-00; Tue, 22 Apr 2003 14:53:07 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1982t8-0004AL-00; Tue, 22 Apr 2003 14:53:06 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 1982tV-000NOn-00; Tue, 22 Apr 2003 18:53:29 +0000 Date: Tue, 22 Apr 2003 11:53:10 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <664455336.20030422115310@psg.com> To: iesg@ietf.org CC: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Taking Tue--Thur off MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit , will try to read my e-mail very irregularly :) Alex From rtg-dir-admin@ietf.org Mon Apr 28 16:14:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13298 for ; Mon, 28 Apr 2003 16:14:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AF3f-00058z-00 for rtg-dir-archive@ietf.org; Mon, 28 Apr 2003 16:17:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AF3e-00058s-00 for rtg-dir-archive@ietf.org; Mon, 28 Apr 2003 16:17:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKK0809679; Mon, 28 Apr 2003 16:20:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKJ4809605 for ; Mon, 28 Apr 2003 16:19: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 QAA13283 for ; Mon, 28 Apr 2003 16:13:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AF2j-00058c-00 for rtg-dir@ietf.org; Mon, 28 Apr 2003 16:16:05 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19AF2h-00058Z-00 for rtg-dir@ietf.org; Mon, 28 Apr 2003 16:16:04 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19AF2r-000HcC-00; Mon, 28 Apr 2003 20:16:15 +0000 Date: Mon, 28 Apr 2003 10:18:29 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <18672778890.20030428101829@psg.com> To: jparker@axiowave.com, prz@net4u.ch, rcallon@juniper.net, rohit@xebeo.com CC: rtg-dir@ietf.org Subject: Fwd: BGP spec for final review In-Reply-To: <16415968120.20030401160007@psg.com> References: <200304011530.h31FUxS57191@merlot.juniper.net> <16415968120.20030401160007@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Since I haven't heard from anyone, I need to assign reviewers for this draft. I'm asking the following members: Jeff P, Tony P, Ross, Rohit Let me know how much time each of you needs to complete this. Thanks. -- Alex This is a forwarded message From: Alex Zinin To: rtg-dir@ietf.org Cc: Date: Tuesday, April 1, 2003, 5:00:07 PM Subject: BGP spec for final review ===8<==============Original message text=============== Folks- This is the version that is expected to go to the IESG. I'd like to ask for at least 3 volunteers to go through it. The deadline is 2 weeks from today, i.e., April 15th. The list of issues documenting the discussion in the WG should be available on the WG mailing list. -- Alex This is a forwarded message From: Yakov Rekhter To: idr@merit.edu Cc: Date: Tuesday, April 1, 2003, 7:30:59 AM Subject: draft-ietf-idr-bgp4-20.txt ===8<==============Original message text=============== Folks, The -20 version contains several (minor) editorial fixes. In addition to the editorial fixes it contains the following in the FSM section (the text was proposed by the Routing ADs): The data structures and FSM described in this document are conceptual and do not have to be implemented precisely as described here, as long as the implementations support the described functionality and their externally visible behavior is the same. Yakov. ------- Forwarded Message Date: Tue, 01 Apr 2003 06:49:45 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-bgp4-20.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 : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter Filename : draft-ietf-idr-bgp4-20.txt Pages : 86 Date : 2003-3-31 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protoco l. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reacha- bility information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This informa- tion is sufficient to construct a graph of AS connectivity from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include support for advertising a set of destinations as an IP prefix and eliminating the concept of network 'class' within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy deci- sions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-20.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-20.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-20.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-31131036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-20.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-31131036.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message ===8<===========End of original message text=========== ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Mon Apr 28 16:18:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13432 for ; Mon, 28 Apr 2003 16:18:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AF7W-0005AV-00 for rtg-dir-archive@ietf.org; Mon, 28 Apr 2003 16:21:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AF7V-0005AS-00 for rtg-dir-archive@ietf.org; Mon, 28 Apr 2003 16:21:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKO0809904; Mon, 28 Apr 2003 16:24:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKNf809876 for ; Mon, 28 Apr 2003 16:23: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 QAA13182; Mon, 28 Apr 2003 16:07:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AEwN-00056r-00; Mon, 28 Apr 2003 16:09:31 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19AEwN-00056m-00; Mon, 28 Apr 2003 16:09:31 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19AEwq-000Gea-00; Mon, 28 Apr 2003 20:10:02 +0000 Date: Mon, 28 Apr 2003 08:51:17 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <19467547297.20030428085117@psg.com> To: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Fwd: Re: [iesg-secretary #6378] IPR statement not fwd'ed to the WG In-Reply-To: <200304221618.h3MGIpd18169@www1.ietf.org> References: <200304221618.h3MGIpd18169@www1.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI below. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Amy Katherine To: zinin@psg.com Cc: Date: Tuesday, April 22, 2003, 9:18:51 AM Subject: [iesg-secretary #6378] IPR statement not fwd'ed to the WG ===8<==============Original message text=============== Your request #6378 was updated by amyk: Dear Alex, It has now been decided that we will notify the WG Chair(s) and the responsible Area Director(s) whenever an IPR notice related to a Working Group has been posted on the "IETF Page of Intellectual Property Rights Notices." Thank you, The IRTF Secretariat ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Mon Apr 28 16:40:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13968 for ; Mon, 28 Apr 2003 16:40:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AFSo-0005Hy-00 for rtg-dir-archive@ietf.org; Mon, 28 Apr 2003 16:43:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AFSo-0005Hv-00 for rtg-dir-archive@ietf.org; Mon, 28 Apr 2003 16:43:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKk0812034; Mon, 28 Apr 2003 16:46:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKjw812012 for ; Mon, 28 Apr 2003 16:45: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 QAA13960 for ; Mon, 28 Apr 2003 16:40:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AFSk-0005Hm-00 for rtg-dir@ietf.org; Mon, 28 Apr 2003 16:42:58 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19AFSk-0005HF-00 for rtg-dir@ietf.org; Mon, 28 Apr 2003 16:42:58 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h3SKhOZ1002675; Mon, 28 Apr 2003 13:43:24 -0700 Date: Mon, 28 Apr 2003 13:43:24 -0700 From: David Meyer To: rtg-dir@ietf.org Subject: please take a look at draft-ietf-idr-bgp-analysis-01.txt Message-ID: <20030428134324.A2672@sprint.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Folks, Please take a look at the bgp analysis document. Comments greatly appreciated. Dave From rtg-dir-admin@ietf.org Mon Apr 28 16:47:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14046 for ; Mon, 28 Apr 2003 16:47:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AFZb-0005JM-00 for rtg-dir-archive@ietf.org; Mon, 28 Apr 2003 16:50:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AFZa-0005JJ-00 for rtg-dir-archive@ietf.org; Mon, 28 Apr 2003 16:50:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKr1812239; Mon, 28 Apr 2003 16:53:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKqA812199 for ; Mon, 28 Apr 2003 16: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 QAA14034 for ; Mon, 28 Apr 2003 16:46:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AFYj-0005JA-00 for rtg-dir@ietf.org; Mon, 28 Apr 2003 16:49:09 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19AFYj-0005J6-00 for rtg-dir@ietf.org; Mon, 28 Apr 2003 16:49:09 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h3SKnaEA002737 for rtg-dir@ietf.org; Mon, 28 Apr 2003 13:49:36 -0700 Date: Mon, 28 Apr 2003 13:49:36 -0700 From: David Meyer To: rtg-dir@ietf.org Subject: Make that draft-ietf-idr-bgp-analysis-02.txt [Re: please take a look at draft-ietf-idr-bgp-analysis-01.txt] Message-ID: <20030428134935.A2734@sprint.net> References: <20030428134324.A2672@sprint.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030428134324.A2672@sprint.net>; from dmm@sprint.net on Mon, Apr 28, 2003 at 01:43:24PM -0700 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Sorry about that. Thanks for taking a look, Dave On Mon, Apr 28, 2003 at 01:43:24PM -0700, David Meyer wrote: >> Folks, >> >> Please take a look at the bgp analysis document. Comments >> greatly appreciated. >> >> Dave From rtg-dir-admin@ietf.org Tue Apr 29 14:30:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04748 for ; Tue, 29 Apr 2003 14:30:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AZu9-0006uB-00 for rtg-dir-archive@ietf.org; Tue, 29 Apr 2003 14:32:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AZu8-0006u8-00 for rtg-dir-archive@ietf.org; Tue, 29 Apr 2003 14:32:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TIa1809315; Tue, 29 Apr 2003 14:36:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TIZH809182 for ; Tue, 29 Apr 2003 14:35: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 OAA04674 for ; Tue, 29 Apr 2003 14:29:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AZtN-0006ty-00 for rtg-dir@ietf.org; Tue, 29 Apr 2003 14:31:49 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19AZtM-0006tv-00 for rtg-dir@ietf.org; Tue, 29 Apr 2003 14:31:49 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 56BF1E46AC for ; Tue, 29 Apr 2003 11:31:10 -0700 (PDT) Message-ID: <3EAEC46F.2080909@redback.com> Date: Tue, 29 Apr 2003 14:29:03 -0400 From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Routing Area Directorate Subject: [Fwd: RE: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit One issue that seems to come up over and over again is how does the OSPF MIB support multiple OSPF instances. Is the context (as defined in RFC 3411) the standard mechanism for supporting multiple routing protocol instances? Thanks, Acee -------- Original Message -------- Subject: RE: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt Date: Tue, 29 Apr 2003 10:52:47 -0400 From: "Daniel Joyal" To: "'Acee Lindem'" I was just going to include a reference to the SNMP RFC that defines contexts (See RFC 3411, section 3.3.1) and the RFC that defines the entity MIB (RFC 2737). The Entity MIB entLogicalTable provides information about what contexts exist in an agent, and how to get to them. From John Flick: "In short, add a reference to the appropriate RFCs for contexts, but don't try to overspecify." -Dan > -----Original Message----- > From: Acee Lindem [mailto:acee@redback.com] > Sent: Tuesday, April 29, 2003 10:15 AM > To: Joyal, Daniel [BL60:NP30:EXCH] > Subject: Re: Working Group Last Call for > draft-ietf-ospf-mib-update-06.txt > > > Hi Dan, > > What are you going to say about multiple instances? > > Thanks, > Acee > > Daniel Joyal wrote: > > Version -06 of the OSPFv2 MIB update includes: > > > > - Add General group object for configuring reference bandwidth > > - Change General group object ospfOpaqueLsaSupport MAX-ACCESS from > > read-write to read-only > > - Deprecate ospfExtLsdbTable and add ospfAsLsdbTable > > - Add external route tag object to ospfAreaAggregateTable > for NSSA (RFC > > 3101) > > - Change status of RFC 1850 compliance and conformance groups from > > "deprecated" to > > "current" > > - Add support for Graceful Restart > > > > Pending updates for version -07 > > > > - Configuration objects to support detection of inactive neighbors > > - Resolution of issues raised by IESG's OAM expert reviewer > on version > > -05 > > - Remaining open issues on traps > > - Add section on MIB support for multiple OSPF instances > > - Fix smilint errors/warnings > > - Fix ospfStubRouterAdvertisement Description clause per > Don's comment > > - Change "hitless restart" to "graceful restart" per Don's comment > > - Any additional issues from WG > > > > -Dan > > > > > -----Original Message----- > > > From: Don Goodspeed [mailto:dgoodspe@EXCITE.COM] > > > Sent: Monday, April 28, 2003 6:49 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: Working Group Last Call for > > > draft-ietf-ospf-mib-update-06.txt > > > > > > > > > All, > > > > > > From my review of the diff's file between these two > > > revisions, I have one specific comment and two general > comments. > > > > 1. (specific comment) At the end of page 17, the description > > > for the new ospfStubRouterAdvertisement attribute needs to > > > end with a double-quote. I see an o with an umlaut above it. > > > > > > 2. (general comment) In the description for all of the new > > > restart objects and notifications, replace the text "hitless > > > restart" with "graceful restart". This reflects the recent > > > name change of that draft from Acee's last update (Graceful > > > OSPF Restart). > > > > > > 3. (general comment) All in all, the objects, their > > > definitions, etc., look well thought out and well-defined. > > > In my last email on this MIB, I suggested including all the > > > needed items to "complete" this MIB update per most common > > > implementations and per the most recent drafts. I think > > > we've met this goal. > > > > > > Thanks for moving this forward, > > > Don Goodspeed > > > > > > --- On Wed 04/23, Acee Lindem < acee@REDBACK.COM > wrote: > > > From: Acee Lindem [mailto: acee@REDBACK.COM] > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Date: Wed, 23 Apr 2003 14:30:00 -0400 > > > Subject: Re: Working Group Last Call for > > > draft-ietf-ospf-mib-update-06.txt > > > > > > We've decided do another revision of this draft prior to > > > WG
last call. If you forward comments quickly (I don't > > > have an
exact date), they can be incorporated into the > > > next revision.

Thanks,
Acee

Acee Lindem > > > wrote:
> This is the start of a Working Group last call > > > for
> draft-ietf-ospf-mib-update-06.txt, OSPF Version 2 > > > Management
> Information Base. All comments must be > > > received by Wednesday,
> May 7th, 2003.
>
> This > > > document reached the AD review phase once before but
> we > > > decided to add MIB support for recent OSPF > > > extensions.
>
>
> A URL for this Internet-Draft > > > is:
> > > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update -06.txt


--
Acee
> > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > -- Acee -- Acee From rtg-dir-admin@ietf.org Tue Apr 29 23:19:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23337 for ; Tue, 29 Apr 2003 23:19:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ai9s-0003Cz-00 for rtg-dir-archive@ietf.org; Tue, 29 Apr 2003 23:21:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ai9r-0003Cv-00 for rtg-dir-archive@ietf.org; Tue, 29 Apr 2003 23:21:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U3P1829827; Tue, 29 Apr 2003 23:25:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U3OW829790 for ; Tue, 29 Apr 2003 23:24: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 XAA23314 for ; Tue, 29 Apr 2003 23:18:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ai9N-0003Cj-00 for rtg-dir@ietf.org; Tue, 29 Apr 2003 23:20:53 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Ai9M-0003Cf-00 for rtg-dir@ietf.org; Tue, 29 Apr 2003 23:20:52 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19Ai9u-0002rp-00; Wed, 30 Apr 2003 03:21:26 +0000 Date: Tue, 29 Apr 2003 23:20:44 -0400 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <688942318.20030429232044@psg.com> To: Acee Lindem CC: Routing Area Directorate , rtg-mibs@ops.ietf.org Subject: Re: [Fwd: RE: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt] In-Reply-To: <3EAEC46F.2080909@redback.com> References: <3EAEC46F.2080909@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cc'ing rtg-mibs. Bert might help with the general question of multiple protocol instances. -- Alex http://www.psg.com/~zinin/ Tuesday, April 29, 2003, 2:29:03 PM, Acee Lindem wrote: > One issue that seems to come up over and over again is > how does the OSPF MIB support multiple OSPF instances. Is the context > (as defined in RFC 3411) the standard mechanism for supporting multiple > routing protocol instances? > Thanks, > Acee > -------- Original Message -------- > Subject: RE: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt > Date: Tue, 29 Apr 2003 10:52:47 -0400 > From: "Daniel Joyal" > To: "'Acee Lindem'" > I was just going to include a reference to the SNMP RFC > that defines contexts (See RFC 3411, section 3.3.1) and > the RFC that defines the entity MIB (RFC 2737). > The Entity MIB entLogicalTable provides information about what > contexts exist in an agent, and how to get to them. > From John Flick: > "In short, add a reference to the appropriate RFCs for contexts, but > don't try to overspecify." > -Dan > > -----Original Message----- > > From: Acee Lindem [mailto:acee@redback.com] > > Sent: Tuesday, April 29, 2003 10:15 AM > > To: Joyal, Daniel [BL60:NP30:EXCH] > > Subject: Re: Working Group Last Call for > > draft-ietf-ospf-mib-update-06.txt > > > > > > Hi Dan, > > > > What are you going to say about multiple instances? > > > > Thanks, > > Acee > > > > Daniel Joyal wrote: > > > Version -06 of the OSPFv2 MIB update includes: > > > > > > - Add General group object for configuring reference bandwidth > > > - Change General group object ospfOpaqueLsaSupport MAX-ACCESS from > > > read-write to read-only > > > - Deprecate ospfExtLsdbTable and add ospfAsLsdbTable > > > - Add external route tag object to ospfAreaAggregateTable > > for NSSA (RFC > > > 3101) > > > - Change status of RFC 1850 compliance and conformance groups from > > > "deprecated" to > > > "current" > > > - Add support for Graceful Restart > > > > > > Pending updates for version -07 > > > > > > - Configuration objects to support detection of inactive neighbors > > > - Resolution of issues raised by IESG's OAM expert reviewer > > on version > > > -05 > > > - Remaining open issues on traps > > > - Add section on MIB support for multiple OSPF instances > > > - Fix smilint errors/warnings > > > - Fix ospfStubRouterAdvertisement Description clause per > > Don's comment > > > - Change "hitless restart" to "graceful restart" per Don's comment > > > - Any additional issues from WG > > > > > > -Dan > > > > > > > -----Original Message----- > > > > From: Don Goodspeed [mailto:dgoodspe@EXCITE.COM] > > > > Sent: Monday, April 28, 2003 6:49 PM > > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > > Subject: Re: Working Group Last Call for > > > > draft-ietf-ospf-mib-update-06.txt > > > > > > > > > > > > All, > > > > > > > > From my review of the diff's file between these two > > > > revisions, I have one specific comment and two general > > comments. > > > > > 1. (specific comment) At the end of page 17, the description > > > > for the new ospfStubRouterAdvertisement attribute needs to > > > > end with a double-quote. I see an o with an umlaut above it. > > > > > > > > 2. (general comment) In the description for all of the new > > > > restart objects and notifications, replace the text "hitless > > > > restart" with "graceful restart". This reflects the recent > > > > name change of that draft from Acee's last update (Graceful > > > > OSPF Restart). > > > > > > > > 3. (general comment) All in all, the objects, their > > > > definitions, etc., look well thought out and well-defined. > > > > In my last email on this MIB, I suggested including all the > > > > needed items to "complete" this MIB update per most common > > > > implementations and per the most recent drafts. I think > > > > we've met this goal. > > > > > > > > Thanks for moving this forward, > > > > Don Goodspeed > > > > > > > > --- On Wed 04/23, Acee Lindem < acee@REDBACK.COM > wrote: > > > > From: Acee Lindem [mailto: acee@REDBACK.COM] > > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > > Date: Wed, 23 Apr 2003 14:30:00 -0400 > > > > Subject: Re: Working Group Last Call for > > > > draft-ietf-ospf-mib-update-06.txt > > > > > > > > We've decided do another revision of this draft prior to > > > > WG
last call. If you forward comments quickly (I don't > > > > have an
exact date), they can be incorporated into the > > > > next revision.

Thanks,
Acee

Acee Lindem > > > > wrote:
> This is the start of a Working Group last call > > > > for
> draft-ietf-ospf-mib-update-06.txt, OSPF Version 2 > > > > Management
> Information Base. All comments must be > > > > received by Wednesday,
> May 7th, 2003.
>
> This > > > > document reached the AD review phase once before but
> we > > > > decided to add MIB support for recent OSPF > > > > extensions.
>
>
> A URL for this Internet-Draft > > > > is:
> > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update > -06.txt


--
Acee
> > > > > > _______________________________________________ > > Join Excite! - http://www.excite.com > > The most personalized portal on the Web! > > > -- > Acee From rtg-dir-admin@ietf.org Tue Apr 29 23:47:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24204 for ; Tue, 29 Apr 2003 23:47:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Aiaw-0003Sh-00 for rtg-dir-archive@ietf.org; Tue, 29 Apr 2003 23:49:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Aiav-0003Se-00 for rtg-dir-archive@ietf.org; Tue, 29 Apr 2003 23:49:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U3r0800749; Tue, 29 Apr 2003 23:53:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U3qU800730 for ; Tue, 29 Apr 2003 23:52: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 XAA24200 for ; Tue, 29 Apr 2003 23:46:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AiaQ-0003Sb-00 for rtg-dir@ietf.org; Tue, 29 Apr 2003 23:48:50 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19AiaQ-0003SX-00 for rtg-dir@ietf.org; Tue, 29 Apr 2003 23:48:50 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3U3muI14500 for ; Tue, 29 Apr 2003 23:48:57 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R196KX9>; Wed, 30 Apr 2003 05:48:56 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155017C1047@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Alex Zinin , Acee Lindem Cc: Routing Area Directorate , rtg-mibs@ops.ietf.org Subject: RE: [Fwd: RE: Working Group Last Call for draft-ietf-ospf-mib-upd ate-06.txt] Date: Wed, 30 Apr 2003 05:48:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , I believe that using the contextName to do multiple instances of the same MIB on the same system (agent) is indeed the proper approach. That is why we edxplain it that way in the SNMP Architecture document in RFC3411 ((page 27 and 28). SNMPv3 directly supports contextName in the SNMPv3 message wrapper. For SNMPv1/v2c, there is a mapping from communityName to a proper contextName via the snmpCommunityMIB as defined in RFC2576. Hope this helps explains Thanks, Bert > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: woensdag 30 april 2003 5:21 > To: Acee Lindem > Cc: Routing Area Directorate; rtg-mibs@ops.ietf.org > Subject: Re: [Fwd: RE: Working Group Last Call for > draft-ietf-ospf-mib-update-06.txt] > > > Cc'ing rtg-mibs. Bert might help with the general > question of multiple protocol instances. > > -- > Alex > http://www.psg.com/~zinin/ > > Tuesday, April 29, 2003, 2:29:03 PM, Acee Lindem wrote: > > One issue that seems to come up over and over again is > > how does the OSPF MIB support multiple OSPF instances. Is > the context > > (as defined in RFC 3411) the standard mechanism for > supporting multiple > > routing protocol instances? > > > Thanks, > > Acee > > -------- Original Message -------- > > Subject: RE: Working Group Last Call for > draft-ietf-ospf-mib-update-06.txt > > Date: Tue, 29 Apr 2003 10:52:47 -0400 > > From: "Daniel Joyal" > > To: "'Acee Lindem'" > > > > > I was just going to include a reference to the SNMP RFC > > that defines contexts (See RFC 3411, section 3.3.1) and > > the RFC that defines the entity MIB (RFC 2737). > > The Entity MIB entLogicalTable provides information about what > > contexts exist in an agent, and how to get to them. > > > From John Flick: > > "In short, add a reference to the appropriate RFCs for > contexts, but > > don't try to overspecify." > > > -Dan > > > > -----Original Message----- > > > From: Acee Lindem [mailto:acee@redback.com] > > > Sent: Tuesday, April 29, 2003 10:15 AM > > > To: Joyal, Daniel [BL60:NP30:EXCH] > > > Subject: Re: Working Group Last Call for > > > draft-ietf-ospf-mib-update-06.txt > > > > > > > > > Hi Dan, > > > > > > What are you going to say about multiple instances? > > > > > > Thanks, > > > Acee > > > > > > Daniel Joyal wrote: > > > > Version -06 of the OSPFv2 MIB update includes: > > > > > > > > - Add General group object for configuring reference bandwidth > > > > - Change General group object ospfOpaqueLsaSupport > MAX-ACCESS from > > > > read-write to read-only > > > > - Deprecate ospfExtLsdbTable and add ospfAsLsdbTable > > > > - Add external route tag object to ospfAreaAggregateTable > > > for NSSA (RFC > > > > 3101) > > > > - Change status of RFC 1850 compliance and > conformance groups from > > > > "deprecated" to > > > > "current" > > > > - Add support for Graceful Restart > > > > > > > > Pending updates for version -07 > > > > > > > > - Configuration objects to support detection of > inactive neighbors > > > > - Resolution of issues raised by IESG's OAM expert reviewer > > > on version > > > > -05 > > > > - Remaining open issues on traps > > > > - Add section on MIB support for multiple OSPF instances > > > > - Fix smilint errors/warnings > > > > - Fix ospfStubRouterAdvertisement Description clause per > > > Don's comment > > > > - Change "hitless restart" to "graceful restart" per > Don's comment > > > > - Any additional issues from WG > > > > > > > > -Dan > > > > > > > > > -----Original Message----- > > > > > From: Don Goodspeed [mailto:dgoodspe@EXCITE.COM] > > > > > Sent: Monday, April 28, 2003 6:49 PM > > > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > > > Subject: Re: Working Group Last Call for > > > > > draft-ietf-ospf-mib-update-06.txt > > > > > > > > > > > > > > > All, > > > > > > > > > > From my review of the diff's file between these two > > > > > revisions, I have one specific comment and two general > > > comments. > > > > > > 1. (specific comment) At the end of page 17, the > description > > > > > for the new ospfStubRouterAdvertisement attribute needs to > > > > > end with a double-quote. I see an o with an > umlaut above it. > > > > > > > > > > 2. (general comment) In the description for all of the new > > > > > restart objects and notifications, replace the > text "hitless > > > > > restart" with "graceful restart". This reflects the recent > > > > > name change of that draft from Acee's last update (Graceful > > > > > OSPF Restart). > > > > > > > > > > 3. (general comment) All in all, the objects, their > > > > > definitions, etc., look well thought out and well-defined. > > > > > In my last email on this MIB, I suggested including all the > > > > > needed items to "complete" this MIB update per most common > > > > > implementations and per the most recent drafts. I think > > > > > we've met this goal. > > > > > > > > > > Thanks for moving this forward, > > > > > Don Goodspeed > > > > > > > > > > --- On Wed 04/23, Acee Lindem < acee@REDBACK.COM > wrote: > > > > > From: Acee Lindem [mailto: acee@REDBACK.COM] > > > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > > > Date: Wed, 23 Apr 2003 14:30:00 -0400 > > > > > Subject: Re: Working Group Last Call for > > > > > draft-ietf-ospf-mib-update-06.txt > > > > > > > > > > We've decided do another revision of this draft prior to > > > > > WG
last call. If you forward comments quickly (I don't > > > > > have an
exact date), they can be incorporated into the > > > > > next revision.

Thanks,
Acee

Acee Lindem > > > > > wrote:
> This is the start of a Working Group last call > > > > > for
> draft-ietf-ospf-mib-update-06.txt, OSPF Version 2 > > > > > Management
> Information Base. All comments must be > > > > > received by Wednesday,
> May 7th, 2003.
>
> This > > > > > document reached the AD review phase once before > but
> we > > > > > decided to add MIB support for recent OSPF > > > > > extensions.
>
>
> A URL for this Internet-Draft > > > > > is:
> > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update > > -06.txt


--
Acee
> > > > > > > > > _______________________________________________ > > > Join Excite! - http://www.excite.com > > > The most personalized portal on the Web! > > > > > > > -- > > Acee > > From mailman-admin@ietf.org Thu May 1 09:34:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09200 for ; Thu, 1 May 2003 09:34:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BEEv-0001Cm-00 for rtg-dir-archive@ietf.org; Thu, 01 May 2003 09:36:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BEEu-0001CT-00 for rtg-dir-archive@ietf.org; Thu, 01 May 2003 09:36:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Df1830624 for ; Thu, 1 May 2003 09:41:01 -0400 Date: Thu, 01 May 2003 09:41:01 -0400 Message-ID: <20030501134101.17986.31656.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rtg-dir-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rtg-dir-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rtg-dir-archive@ietf.org: List Password // URL ---- -------- rtg-dir@ietf.org utnefe https://www1.ietf.org/mailman/options/rtg-dir/rtg-dir-archive%40ietf.org From rtg-dir-admin@ietf.org Fri May 2 02:18:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07164 for ; Fri, 2 May 2003 02:18:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BTuD-0002IJ-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 02:20:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BTuC-0002IG-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 02:20:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h426P2824036; Fri, 2 May 2003 02:25:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h426NZ823898 for ; Fri, 2 May 2003 02:23: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 CAA07026 for ; Fri, 2 May 2003 02:16:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BTsh-0002I8-00 for rtg-dir@ietf.org; Fri, 02 May 2003 02:18:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19BTsb-0002I2-00 for rtg-dir@ietf.org; Fri, 02 May 2003 02:18:45 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19BTsc-0000Oz-00; Fri, 02 May 2003 06:18:46 +0000 Date: Fri, 2 May 2003 02:17:49 -0400 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <19761784301.20030502021749@psg.com> To: Ross Callon CC: "Putzolu, David" , Patrick Droz (dro@zurich.ibm.com), , Pekka Savola , Subject: Re: Terminology NIT Re: Fwd: Re: draft-ietf-forces-requirements-08.txt In-Reply-To: <4.3.2.20030409124113.02c5e340@zircon.juniper.net> References: <4.3.2.20030409124113.02c5e340@zircon.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ross, Just noticed I missed this e-mail. It seems that this is not a big deal. Just like we can be more specific and say ISIS LSP and MPLS LSP, we can also be more specific and say VPN CE, and ForCES CE, when necessary. One abbreviation overload that I kind of hate is IP used for "Intellectual Property"... unfortunately the IETF can't do anything about this ;) -- Alex http://www.psg.com/~zinin/ Wednesday, April 9, 2003, 12:45:43 PM, Ross Callon wrote: >> By allowing the control and >> forwarding planes to evolve independently, different types of FEs >> can be developed - some general purpose and others more specialized. >> >>.. this seems a bit questionable: different types of FEs can already be >>developed, and have been developed for a long time now. What you're >>aiming for is mixing and matching a CE one or more FE's with a standard >>protocol with different characteristics and possibly different vendors. > Are we concerned about the fact that the abbreviation CE refers to > a Control Element in Forces, and also refers to Customer Edge > devices for L2 and L3 VPNs? This seems slightly worse than the > double use of LSP (Link State Packet, and Label Switched Path) > since if FORCES is used at all then the context is likely to overlap: > Specifically, customer edge equipment which supports VPNs might > use Forces technology. Thus the CE (customer edge device in VPN > speak) consists of an NE (Network Element in Forces speak) which > in turn is made up of a CE (Control Element) and an FE. > How about Control Processor or CP? > Ross From rtg-dir-admin@ietf.org Fri May 2 02:20:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07375 for ; Fri, 2 May 2003 02:20:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BTw8-0002J9-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 02:22:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BTw7-0002J3-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 02:22:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h426R1824203; Fri, 2 May 2003 02:27:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h426Pp824086 for ; Fri, 2 May 2003 02:25: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 CAA07274 for ; Fri, 2 May 2003 02:18:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BTut-0002In-00 for rtg-dir@ietf.org; Fri, 02 May 2003 02:21:07 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19BTun-0002Ib-00 for rtg-dir@ietf.org; Fri, 02 May 2003 02:21:01 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19BTvI-0000nO-00; Fri, 02 May 2003 06:21:32 +0000 Date: Fri, 2 May 2003 02:20:36 -0400 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <3661951050.20030502022036@psg.com> To: stefano previdi CC: Routing Area Directorate , Acee Lindem , Brad Neal , Christian Martin , Tony Li , Tony Przygienda Subject: Re: Comments on In-Reply-To: <200304171326.h3HDQRR06975@strange-brew.cisco.com> References: <3E73E362.3010802@redback.com> <13117088053.20030329220505@psg.com> <16144077670.20030416113351@psg.com> <200304171326.h3HDQRR06975@strange-brew.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stefano, Sorry for a long delay. I had an opportunity to discuss the comments brought up below with Tony P. We agreed on many points which I will summarize below, except that the need for two tags is still unclear to me, and I need someone to talk about this. See below for more details, pls. Once we have some sort of agreement, I'll post my comments to the WG list, so the process is open. >> Comments: >> >> In order to preserve interoperability with tag-unaware routers, I >> think we should add some words saying that the implementations MUST >> NOT change their SPF calculation based on the contents of the >> introduced TLVs. > I disagree mainly because the two things (tags and SPF > computation) are not related. You _may_ want to give to SPF > some indications about tagged prefixes, but this is a local > matter and your routing tables should be consistent across > the network (and you don't need a draft telling you this). > Specifying that you "MUST NOT" do this or that, is outside of > the scope of this draft. There is a case where one could potentially use a tag value to decide to not install a prefix in the routing table and get into loops. On the one hand, I agree with Mike's opinion he expressed in his message to the list on the auto-encaps draft, that we can't possibly specify all wrong things that could be but should not be done, on the other, the nature of the tag is quite opaque and sort of encourages creativity ;) and discouraging intra-area SPF filtering could be useful. However, since I can argue both ways myself, I will leave this up to you. >> On the one hand, >> there's a wide spectrum of applications that can use these tags and we >> don't want to say foo and bar are the only ones, on the other hand if >> I were deploying this in a multi-vendor environment, I'd likely want >> to see a consistent minimal set of features, i.e., not just attaching >> a tag, but also executing on it if the router is a L1/L2 or an ASBR. >> Did you guys think about this? > yes, and again I don't believe it's the role of the draft to > tell you what to do with this subTLV. The draft just > specifies the data. What you do with this data is a matter of > applications that are well outside the scope of the draft. The draft definitely reads like filtering at the area boundaries is one of the major applications of this TLV. However, because the document requests the compliant implementations to only be able to insert the tag, but not filter using it at the L1/L2 IS'es, an operator cannot expect all compliant implementations to be useful for this function, i.e., they will need to ask if functions outside the scope of this document are supported by specific vendors, go into details of how they do that to make sure different implementations can work together in a consistent way. Putting in 'MUST support filtering at the area boundaries' would solve this. >> What I think is missing in the draft is specification of how multiple >> instances of the same sub-TLV should be treated, i.e., I could see >> some implementations deciding to merge the tag sets, and some using >> just the first (or the last) instance, which would result in interop >> issues. Should be spelled out, I think. > yes, you can give some hints. At the origin we said that in > case of multiple tags and a router supporting only one, then > you should take the first. I know at least one major > implementation that does this...;-) Let's put text in the draft saying that only the first copy of the TLV must be considered. We need consistency in behavior. ... >> A similar, and somewhat more interesting question is about the two >> types of tags--32 bits and 64 bits. > don't tell me this...;-) ... >> There will also be a question in the IESG on why do we need a 32-bit >> tag if we have a 64-bit one, which could accommodate 32-bit values >> too. > because we already have an implementation using 32 bits and > sincerely I did never understand the need of 64 bits... Does any of the co-authors know the reason? >> To preserve tag ordering where? Within the TLV? (a pseudo-question >> really, since one shouldn't change someone else's TLV contents) > except when you do route-leaking. You may receive a set of > tags in one level and change them for the other level. Please, > don't ask me a real case scenario for this...;-) That's fine. It's just that the text didn't explicitly say it was the case of route leaking between levels. Some word tweaking should help. Alex From rtg-dir-admin@ietf.org Fri May 2 04:19:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09055 for ; Fri, 2 May 2003 04:19:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BVnG-00033Z-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 04:21:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BVnF-00033Q-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 04:21:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h428Q1800763; Fri, 2 May 2003 04:26:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h428M9800558 for ; Fri, 2 May 2003 04:22: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 EAA08982 for ; Fri, 2 May 2003 04:15:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BVjP-00032M-00 for rtg-dir@ietf.org; Fri, 02 May 2003 04:17:23 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19BVjJ-00032A-00 for rtg-dir@ietf.org; Fri, 02 May 2003 04:17:18 -0400 Received: from there (ams-clip-vpn-dhcp4102.cisco.com [10.61.80.5]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id h428H1R21140; Fri, 2 May 2003 10:17:01 +0200 (CEST) Message-Id: <200305020817.h428H1R21140@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: Alex Zinin Subject: Re: Comments on Date: Fri, 2 May 2003 10:16:28 +0200 X-Mailer: KMail [version 1.3.1] Cc: Routing Area Directorate , Acee Lindem , Brad Neal , Christian Martin , Tony Li , Tony Przygienda References: <3E73E362.3010802@redback.com> <200304171326.h3HDQRR06975@strange-brew.cisco.com> <3661951050.20030502022036@psg.com> In-Reply-To: <3661951050.20030502022036@psg.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h428Mt800573 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Alex, On Friday 02 May 2003 08:20, Alex Zinin wrote: > Stefano, > > Sorry for a long delay. I had an opportunity to discuss the comments > brought up below with Tony P. We agreed on many points which I will > summarize below, except that the need for two tags is still unclear to > me, to me too... > and I need someone to talk about this. See below for more details, > pls. Once we have some sort of agreement, I'll post my comments to the > WG list, so the process is open. > > >> Comments: > >> > >> In order to preserve interoperability with tag-unaware routers, I > >> think we should add some words saying that the implementations MUST > >> NOT change their SPF calculation based on the contents of the > >> introduced TLVs. > > > I disagree mainly because the two things (tags and SPF > > computation) are not related. You _may_ want to give to SPF > > some indications about tagged prefixes, but this is a local > > matter and your routing tables should be consistent across > > the network (and you don't need a draft telling you this). > > Specifying that you "MUST NOT" do this or that, is outside of > > the scope of this draft. > > There is a case where one could potentially use a tag value to decide > to not install a prefix in the routing table and get into loops. On > the one hand, I agree with Mike's opinion he expressed in his message > to the list on the auto-encaps draft, that we can't possibly specify > all wrong things that could be but should not be done, on the other, > the nature of the tag is quite opaque and sort of encourages > creativity ;) and discouraging intra-area SPF filtering could be > useful. However, since I can argue both ways myself, I will leave > this up to you. I can tell you that there is already an implemented aplication that changes the way SPF installs prefixes in rib according to tagged prefixes... Also, I still do not believe drafts should be so restrictive in things that are not related to what they describe. > >> On the one hand, > >> there's a wide spectrum of applications that can use these tags and we > >> don't want to say foo and bar are the only ones, on the other hand if > >> I were deploying this in a multi-vendor environment, I'd likely want > >> to see a consistent minimal set of features, i.e., not just attaching > >> a tag, but also executing on it if the router is a L1/L2 or an ASBR. > >> Did you guys think about this? > > > yes, and again I don't believe it's the role of the draft to > > tell you what to do with this subTLV. The draft just > > specifies the data. What you do with this data is a matter of > > applications that are well outside the scope of the draft. > > The draft definitely reads like filtering at the area boundaries is > one of the major applications of this TLV. just one... I can tell you that from our side I don't see filtering beeing deployed very soon (mostly because there are no levels) however, I can see need for another tag application (the one I mentionned above). > However, because the > document requests the compliant implementations to only be able to > insert the tag, but not filter using it at the L1/L2 IS'es, an > operator cannot expect all compliant implementations to be useful for > this function, i.e., they will need to ask if functions outside the > scope of this document are supported by specific vendors, go into > details of how they do that to make sure different implementations can > work together in a consistent way. Putting in 'MUST support filtering > at the area boundaries' would solve this. well, what if a vendor doesn't want to implement filtering (because no customer ever asked for it) but he wants to implement the spf/rib modification ? Again, I don't believe filtering is the first/major application of tags that will be deployed. but I'm not reluctant to put "MUST" if you believe it's necessary (it's anyway in my code, ... ) it's just that I don't believe it is. > >> A similar, and somewhat more interesting question is about the two > >> types of tags--32 bits and 64 bits. > > > don't tell me this...;-) > ... > >> There will also be a question in the IESG on why do we need a 32-bit > >> tag if we have a 64-bit one, which could accommodate 32-bit values > >> too. > > > because we already have an implementation using 32 bits and > > sincerely I did never understand the need of 64 bits... > > Does any of the co-authors know the reason? no, the only one who can help you is Hannes Gredler (hannes@juniper.net) who made the request. I believe the request came from some obscure reasons related to mpls-vpn extended community attribute (64 bits) that could be propagated through the igp... have no clue about the scenario that would require such a thing... > >> To preserve tag ordering where? Within the TLV? (a pseudo-question > >> really, since one shouldn't change someone else's TLV contents) > > > except when you do route-leaking. You may receive a set of > > tags in one level and change them for the other level. Please, > > don't ask me a real case scenario for this...;-) > > That's fine. It's just that the text didn't explicitly say > it was the case of route leaking between levels. Some word > tweaking should help. well, I believe it falls under "filtering prefix propagation between levels" since the same issue happen in both ways (l1->l2, l2->l1). s. From rtg-dir-admin@ietf.org Fri May 2 12:14:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19227 for ; Fri, 2 May 2003 12:14:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BdCn-0005Jw-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 12:16:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BdCm-0005Jp-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 12:16:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42GL2803084; Fri, 2 May 2003 12:21:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42GK0802965 for ; Fri, 2 May 2003 12:20: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 MAA19178 for ; Fri, 2 May 2003 12:12:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BdBg-0005IK-00 for rtg-dir@ietf.org; Fri, 02 May 2003 12:15:04 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19BdBa-0005HL-00 for rtg-dir@ietf.org; Fri, 02 May 2003 12:14:58 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19Bd9c-0006Of-00; Fri, 02 May 2003 16:12:56 +0000 Date: Fri, 2 May 2003 12:12:11 -0400 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <18297446420.20030502121211@psg.com> To: stefano previdi CC: Routing Area Directorate , Acee Lindem , Brad Neal , Christian Martin , Tony Li , Tony Przygienda Subject: Re: Comments on In-Reply-To: <200305020817.h428H1R21140@strange-brew.cisco.com> References: <3E73E362.3010802@redback.com> <200304171326.h3HDQRR06975@strange-brew.cisco.com> <3661951050.20030502022036@psg.com> <200305020817.h428H1R21140@strange-brew.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stefano, >> There is a case where one could potentially use a tag value to decide >> to not install a prefix in the routing table and get into loops. On >> the one hand, I agree with Mike's opinion he expressed in his message >> to the list on the auto-encaps draft, that we can't possibly specify >> all wrong things that could be but should not be done, on the other, >> the nature of the tag is quite opaque and sort of encourages >> creativity ;) and discouraging intra-area SPF filtering could be >> useful. However, since I can argue both ways myself, I will leave >> this up to you. > I can tell you that there is already an implemented > aplication that changes the way SPF installs prefixes in rib > according to tagged prefixes... Hmmm... seems that my thoughts were not just out of the blue ;) can you describe what the application is and how it is compatible with standard ISIS implementations? > Also, I still do not believe drafts should be so restrictive > in things that are not related to what they describe. ... > well, what if a vendor doesn't want to implement filtering > (because no customer ever asked for it) but he wants to > implement the spf/rib modification ? Again, I don't believe > filtering is the first/major application of tags that will > be deployed. > but I'm not reluctant to put "MUST" if you believe it's > necessary (it's anyway in my code, ... ) it's just that I > don't believe it is. Yes, I think we should put a requirement for this. >> > because we already have an implementation using 32 bits and >> > sincerely I did never understand the need of 64 bits... >> >> Does any of the co-authors know the reason? > no, the only one who can help you is Hannes Gredler > (hannes@juniper.net) who made the request. I believe the > request came from some obscure reasons related to mpls-vpn > extended community attribute (64 bits) that could be > propagated through the igp... have no clue about the scenario > that would require such a thing... OK, seems that this is best taken to the list. >> >> To preserve tag ordering where? Within the TLV? (a pseudo-question >> >> really, since one shouldn't change someone else's TLV contents) >> >> > except when you do route-leaking. You may receive a set of >> > tags in one level and change them for the other level. Please, >> > don't ask me a real case scenario for this...;-) >> >> That's fine. It's just that the text didn't explicitly say >> it was the case of route leaking between levels. Some word >> tweaking should help. > well, I believe it falls under "filtering prefix propagation > between levels" since the same issue happen in both ways (l1->>l2, l2->l1). Right, it's just that the doc could be more clear about this. Alex From rtg-dir-admin@ietf.org Fri May 2 12:21:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19439 for ; Fri, 2 May 2003 12:21:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BdJY-0005OG-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 12:23:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BdJY-0005Nx-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 12:23:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42GS2803419; Fri, 2 May 2003 12:28:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42GRx803371 for ; Fri, 2 May 2003 12:27: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 MAA19427 for ; Fri, 2 May 2003 12:20:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BdJD-0005Nq-00 for rtg-dir@ietf.org; Fri, 02 May 2003 12:22:52 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19BdJ7-0005NR-00 for rtg-dir@ietf.org; Fri, 02 May 2003 12:22:46 -0400 Received: from there (ams-clip-vpn-dhcp4195.cisco.com [10.61.80.98]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id h42GMKR26136; Fri, 2 May 2003 18:22:20 +0200 (CEST) Message-Id: <200305021622.h42GMKR26136@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: Alex Zinin Subject: Re: Comments on Date: Fri, 2 May 2003 18:22:09 +0200 X-Mailer: KMail [version 1.3.1] Cc: Routing Area Directorate , Acee Lindem , Brad Neal , Christian Martin , Tony Li , Tony Przygienda References: <3E73E362.3010802@redback.com> <200305020817.h428H1R21140@strange-brew.cisco.com> <18297446420.20030502121211@psg.com> In-Reply-To: <18297446420.20030502121211@psg.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h42GRx803372 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Alex, On Friday 02 May 2003 18:12, Alex Zinin wrote: > Stefano, > > >> There is a case where one could potentially use a tag value to decide > >> to not install a prefix in the routing table and get into loops. On > >> the one hand, I agree with Mike's opinion he expressed in his message > >> to the list on the auto-encaps draft, that we can't possibly specify > >> all wrong things that could be but should not be done, on the other, > >> the nature of the tag is quite opaque and sort of encourages > >> creativity ;) and discouraging intra-area SPF filtering could be > >> useful. However, since I can argue both ways myself, I will leave > >> this up to you. > > > I can tell you that there is already an implemented > > aplication that changes the way SPF installs prefixes in rib > > according to tagged prefixes... > > Hmmm... seems that my thoughts were not just out of the blue ;) > > can you describe what the application is and how it is compatible with > standard ISIS implementations? spf computation and rib installation are not part of any protocol standardisation (I believe). The only requirement is that route computation should be consistent all along the area/network. routing computation has been already modified in different ways (incremental-spf is one of them and prc is another one). without revealing secrets I can tell you that there are ways to improve routing convergence for some prefixes... if you know which prefixes you want to converge faster... and tags is one mechanism to use. s. From rtg-dir-admin@ietf.org Fri May 2 12:28:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19684 for ; Fri, 2 May 2003 12:28:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BdQJ-0005R9-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 12:30:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BdQI-0005R6-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 12:30:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42GZ0803740; Fri, 2 May 2003 12:35:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42GY3803694 for ; Fri, 2 May 2003 12:34: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 MAA19668 for ; Fri, 2 May 2003 12:26:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BdPH-0005Qt-00 for rtg-dir@ietf.org; Fri, 02 May 2003 12:29:07 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19BdPB-0005Qp-00 for rtg-dir@ietf.org; Fri, 02 May 2003 12:29:01 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19BdPb-0009Yy-00; Fri, 02 May 2003 16:29:27 +0000 Date: Fri, 2 May 2003 12:28:39 -0400 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1698434050.20030502122839@psg.com> To: stefano previdi CC: Routing Area Directorate , Acee Lindem , Brad Neal , Christian Martin , Tony Li , Tony Przygienda Subject: Re: Comments on In-Reply-To: <200305021622.h42GMKR26136@strange-brew.cisco.com> References: <3E73E362.3010802@redback.com> <200305020817.h428H1R21140@strange-brew.cisco.com> <18297446420.20030502121211@psg.com> <200305021622.h42GMKR26136@strange-brew.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stefano, > spf computation and rib installation are not part of any > protocol standardisation (I believe). Yes and no. Clearly if different routers choose different SPTs they won't be able to work with each other. So, the basic algo is needed to be standard, the exact implementations of it, or optimizations like incremental SPF, etc. are definitely not. > The only requirement is > that route computation should be consistent all along the > area/network. Plus compatible with existing STD implementations. > routing computation has been already modified in different > ways (incremental-spf is one of them and prc is another one). > without revealing secrets I can tell you that there are ways > to improve routing convergence for some prefixes... if you > know which prefixes you want to converge faster... and tags > is one mechanism to use. If it produces the same set of routes as the standard SPF, we're fine. Alex From rtg-dir-admin@ietf.org Fri May 2 12:36:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19962 for ; Fri, 2 May 2003 12:36:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BdYY-0005V5-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 12:38:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BdYD-0005Uu-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 12:38:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Gh1805108; Fri, 2 May 2003 12:43:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Gh0805082 for ; Fri, 2 May 2003 12:43: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 MAA19951 for ; Fri, 2 May 2003 12:35:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BdXq-0005Um-00 for rtg-dir@ietf.org; Fri, 02 May 2003 12:37:58 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19BdXV-0005UO-00 for rtg-dir@ietf.org; Fri, 02 May 2003 12:37:37 -0400 Received: from there (ams-clip-vpn-dhcp4195.cisco.com [10.61.80.98]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id h42GbWR09139; Fri, 2 May 2003 18:37:32 +0200 (CEST) Message-Id: <200305021637.h42GbWR09139@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: Alex Zinin Subject: Re: Comments on Date: Fri, 2 May 2003 18:37:20 +0200 X-Mailer: KMail [version 1.3.1] Cc: Routing Area Directorate , Acee Lindem , Brad Neal , Christian Martin , Tony Li , Tony Przygienda References: <3E73E362.3010802@redback.com> <200305021622.h42GMKR26136@strange-brew.cisco.com> <1698434050.20030502122839@psg.com> In-Reply-To: <1698434050.20030502122839@psg.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h42Gh0805083 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Friday 02 May 2003 18:28, Alex Zinin wrote: > Stefano, > > > spf computation and rib installation are not part of any > > protocol standardisation (I believe). > > Yes and no. > > Clearly if different routers choose different SPTs they won't > be able to work with each other. by definition SPT are never equal... they are just consistent each others... but I believe it's what you itended as well. > So, the basic algo is needed > to be standard, the exact implementations of it, or optimizations > like incremental SPF, etc. are definitely not. theoretically speaking I don't agree... practically speaking I do. > > The only requirement is > > that route computation should be consistent all along the > > area/network. > > Plus compatible with existing STD implementations. I don't understand "compatible". For me only consistency matters. > > routing computation has been already modified in different > > ways (incremental-spf is one of them and prc is another one). > > > without revealing secrets I can tell you that there are ways > > to improve routing convergence for some prefixes... if you > > know which prefixes you want to converge faster... and tags > > is one mechanism to use. > > If it produces the same set of routes as the standard SPF, > we're fine. yes, and of course it does... otherwise my nights would be very short ...;-) s. From rtg-dir-admin@ietf.org Fri May 2 13:41:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22472 for ; Fri, 2 May 2003 13:41:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BeYz-00061h-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 13:43:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BeYf-00061E-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 13:42:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Hl1810613; Fri, 2 May 2003 13:47:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Hjx810557 for ; Fri, 2 May 2003 13:45: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 NAA22288 for ; Fri, 2 May 2003 13:38:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BeWm-0005zl-00 for rtg-dir@ietf.org; Fri, 02 May 2003 13:40:56 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19BeWR-0005y6-00 for rtg-dir@ietf.org; Fri, 02 May 2003 13:40:35 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h42Hbjua022688; Fri, 2 May 2003 10:37:46 -0700 (PDT) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp17.cisco.com [10.61.64.17]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA13875; Fri, 2 May 2003 18:37:41 +0100 (BST) Message-Id: <4.3.2.7.2.20030502183057.050e4240@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 May 2003 18:37:36 +0100 To: Alex Zinin From: mike shand Subject: Re: Comments on Cc: stefano previdi , Routing Area Directorate , Acee Lindem , Brad Neal , Christian Martin , Tony Li , Tony Przygienda In-Reply-To: <1698434050.20030502122839@psg.com> References: <200305021622.h42GMKR26136@strange-brew.cisco.com> <3E73E362.3010802@redback.com> <200305020817.h428H1R21140@strange-brew.cisco.com> <18297446420.20030502121211@psg.com> <200305021622.h42GMKR26136@strange-brew.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Just a point here. You may or may not agree with their "wisdom", but ISO didn't standardize the SPF in ISO/IEC 10589, they put it in an informational appendix, and said "Any implementation of an SPF algorithm meeting both the static and dynamic conformance requirements of clause 12 of this International Standard may be used. Recommended implementations are described in detail in annex C." Mike At 12:28 02/05/2003 -0400, Alex Zinin wrote: >Stefano, > > > spf computation and rib installation are not part of any > > protocol standardisation (I believe). > >Yes and no. > >Clearly if different routers choose different SPTs they won't >be able to work with each other. So, the basic algo is needed >to be standard, the exact implementations of it, or optimizations >like incremental SPF, etc. are definitely not. > > > The only requirement is > > that route computation should be consistent all along the > > area/network. > >Plus compatible with existing STD implementations. > > > routing computation has been already modified in different > > ways (incremental-spf is one of them and prc is another one). > > > without revealing secrets I can tell you that there are ways > > to improve routing convergence for some prefixes... if you > > know which prefixes you want to converge faster... and tags > > is one mechanism to use. > >If it produces the same set of routes as the standard SPF, >we're fine. > >Alex From rtg-dir-admin@ietf.org Fri May 2 14:56:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25898 for ; Fri, 2 May 2003 14:56:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BfkS-0006hN-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 14:59:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BfkS-0006hD-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 14:59:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42J41816832; Fri, 2 May 2003 15:04:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42J3T816747 for ; Fri, 2 May 2003 15:03: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 OAA25855 for ; Fri, 2 May 2003 14:56:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bfjo-0006gP-00 for rtg-dir@ietf.org; Fri, 02 May 2003 14:58:29 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Bfji-0006gD-00 for rtg-dir@ietf.org; Fri, 02 May 2003 14:58:23 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19Bfjn-000CGo-00; Fri, 02 May 2003 18:58:27 +0000 Date: Fri, 2 May 2003 14:56:56 -0400 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <196107331254.20030502145656@psg.com> To: mike shand CC: stefano previdi , Routing Area Directorate , Acee Lindem , Brad Neal , Christian Martin , Tony Li , Tony Przygienda Subject: Re: Comments on In-Reply-To: <4.3.2.7.2.20030502183057.050e4240@jaws.cisco.com> References: <200305021622.h42GMKR26136@strange-brew.cisco.com> <3E73E362.3010802@redback.com> <200305020817.h428H1R21140@strange-brew.cisco.com> <18297446420.20030502121211@psg.com> <200305021622.h42GMKR26136@strange-brew.cisco.com> <4.3.2.7.2.20030502183057.050e4240@jaws.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mike, I think we're in agreement. See my message to Stefano. -- Alex http://www.psg.com/~zinin/ Friday, May 2, 2003, 1:37:36 PM, mike shand wrote: > Just a point here. You may or may not agree with their "wisdom", but ISO > didn't standardize the SPF in ISO/IEC 10589, they put it in an > informational appendix, and said > "Any implementation of an SPF algorithm meeting both the > static and dynamic conformance requirements of clause 12 of > this International Standard may be used. Recommended implementations > are described in detail in annex C." > Mike From rtg-dir-admin@ietf.org Fri May 2 15:01:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26180 for ; Fri, 2 May 2003 15:01:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bfop-0006lL-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 15:03:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Bfop-0006lH-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 15:03:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42J8W817990; Fri, 2 May 2003 15:08:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42J3T816749 for ; Fri, 2 May 2003 15:03: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 OAA25856 for ; Fri, 2 May 2003 14:56:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bfjp-0006gQ-00 for rtg-dir@ietf.org; Fri, 02 May 2003 14:58:29 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Bfjj-0006fl-00 for rtg-dir@ietf.org; Fri, 02 May 2003 14:58:23 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19Bfj3-000CAw-00; Fri, 02 May 2003 18:57:42 +0000 Date: Fri, 2 May 2003 14:56:11 -0400 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <126107285748.20030502145611@psg.com> To: stefano previdi CC: Routing Area Directorate , Acee Lindem , Brad Neal , Christian Martin , Tony Li , Tony Przygienda Subject: Re: Comments on In-Reply-To: <200305021637.h42GbWR09139@strange-brew.cisco.com> References: <3E73E362.3010802@redback.com> <200305021622.h42GMKR26136@strange-brew.cisco.com> <1698434050.20030502122839@psg.com> <200305021637.h42GbWR09139@strange-brew.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stefano, >> Clearly if different routers choose different SPTs they won't >> be able to work with each other. > by definition SPT are never equal... they are just consistent > each others... but I believe it's what you itended as well. Right, as long as routers use the _shortest_ paths to calculate route metrics _and_ install the same set of routes within an area, they will work together fine, i.e., SPTs are consistent because of the "shortest" word. One could even use centralized Bellman-Ford to calculate shortest paths, it's just that it's computationally much worse than Dijkstra. Anyways, we're playing words here, while we both understand what the matter is ;) >> So, the basic algo is needed >> to be standard, the exact implementations of it, or optimizations >> like incremental SPF, etc. are definitely not. > theoretically speaking I don't agree... practically speaking > I do. I guess a refinement that should satisfy everyone should be to say that as long as implementations come up with the same results as the algorithm described in the spec, they are good. >> > The only requirement is >> > that route computation should be consistent all along the >> > area/network. >> >> Plus compatible with existing STD implementations. > I don't understand "compatible". For me only consistency > matters. by compatible I mean able to work correctly (without loops and blackholes) with existing implementations present in the network, so it is indeed consistency, I guess. >> > routing computation has been already modified in different >> > ways (incremental-spf is one of them and prc is another one). >> >> > without revealing secrets I can tell you that there are ways >> > to improve routing convergence for some prefixes... if you >> > know which prefixes you want to converge faster... and tags >> > is one mechanism to use. >> >> If it produces the same set of routes as the standard SPF, >> we're fine. > yes, and of course it does... otherwise my nights would be > very short ...;-) I would be surprised if you said otherwise! :) So maybe we should put in the text some words saying that implementations should not use tags to change their routing table calculation in a way that would affect interoperability with preexisting implementations, or something like this. Alex From rtg-dir-admin@ietf.org Fri May 2 16:12:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00521 for ; Fri, 2 May 2003 16:12:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bgw0-0007Tz-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 16:15:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Bgvz-0007Tv-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 16:15:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42KK2823714; Fri, 2 May 2003 16:20:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42KJK823624 for ; Fri, 2 May 2003 16:19: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 QAA00478 for ; Fri, 2 May 2003 16:12:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bgtp-0007Sh-00 for rtg-dir@ietf.org; Fri, 02 May 2003 16:12:53 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Bgtj-0007Sc-00 for rtg-dir@ietf.org; Fri, 02 May 2003 16:12:47 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19Bgtz-00027j-00; Fri, 02 May 2003 20:13:03 +0000 Date: Fri, 2 May 2003 16:11:23 -0400 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <33111798617.20030502161123@psg.com> To: "Martin, Christian" CC: stefano previdi , Routing Area Directorate , Acee Lindem , Brad Neal , Tony Li , Tony Przygienda Subject: Re: Comments on In-Reply-To: <94B9091E1149D411A45C00508BACEB3503E2898B@entmail.gnilink.com> References: <94B9091E1149D411A45C00508BACEB3503E2898B@entmail.gnilink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christian, > This is probably the best solution. The intention was (in my view) > transparent to the SPT construction piece in that the only place where > deletion or modification could/would occur is at LSP creation and on the > area boundary (which in and of itself is an LSP re-creation process). I am > not sure that we intended to employ any real filtering in a standard > implementation, although vendors do add knobs (or rope). That's definitely reasonable. > WRT to 64 bit tags, that was not my original intent - it came in later as a > means to carry extended communties for carrier of carrier type applications. > The semantics seemed such that stackin 32 bit tags for this purpose may > introduce some ambiguity, so a separate sub-TLV was introduced. I would > think it would be easier to code in this fashion - Stefano? That was also my reading of the discussion on the list I got from the archives. My thinking would be that if the 64-bit TLV application is really ext comm transportation, then it is not a tag that is used to control prefix distribution within the domain any more, and this TLV should be specified as "VPN foo:bar", instead of confusing implementers and operators with two tags, which we clearly don't need. Alex From rtg-dir-admin@ietf.org Fri May 2 16:23:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01039 for ; Fri, 2 May 2003 16:23:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bh6c-0007al-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 16:26:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Bh6c-0007ag-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 16:26:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42KV1824182; Fri, 2 May 2003 16:31:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42KUK824122 for ; Fri, 2 May 2003 16:30: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 QAA00997 for ; Fri, 2 May 2003 16:23:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bh5r-0007a3-00 for rtg-dir@ietf.org; Fri, 02 May 2003 16:25:19 -0400 Received: from entmail.gnilink.net ([199.45.47.10]) by ietf-mx with esmtp (Exim 4.12) id 19Bh5l-0007Zg-00 for rtg-dir@ietf.org; Fri, 02 May 2003 16:25:13 -0400 Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59) id ; Fri, 2 May 2003 15:59:25 -0400 Message-ID: <94B9091E1149D411A45C00508BACEB3503E2898B@entmail.gnilink.com> From: "Martin, Christian" To: "'Alex Zinin'" , stefano previdi Cc: Routing Area Directorate , Acee Lindem , Brad Neal , "Martin, Christian" , Tony Li , Tony Przygienda Subject: RE: Comments on Date: Fri, 2 May 2003 15:59:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C310E5.541D08D0" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C310E5.541D08D0 Content-Type: text/plain Alex, >So maybe we should put in the text some words saying that >implementations should not use tags to change their routing >table calculation in a way that would affect interoperability >with preexisting implementations, or something like this. This is probably the best solution. The intention was (in my view) transparent to the SPT construction piece in that the only place where deletion or modification could/would occur is at LSP creation and on the area boundary (which in and of itself is an LSP re-creation process). I am not sure that we intended to employ any real filtering in a standard implementation, although vendors do add knobs (or rope). Thanks for taking the time to get this clarified. Chris PS WRT to 64 bit tags, that was not my original intent - it came in later as a means to carry extended communties for carrier of carrier type applications. The semantics seemed such that stackin 32 bit tags for this purpose may introduce some ambiguity, so a separate sub-TLV was introduced. I would think it would be easier to code in this fashion - Stefano? >Alex > ------_=_NextPart_001_01C310E5.541D08D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments on = <draft-ietf-isis-admin-tages-01.txt>

Alex,

>So maybe we should put in the text some words = saying that
>implementations should not use tags to change = their routing
>table calculation in a way that would affect = interoperability
>with preexisting implementations, or something = like this.

This is probably the best solution.  The = intention was (in my view) transparent to the SPT construction piece in = that the only place where deletion or modification could/would occur is = at LSP creation and on the area boundary (which in and of itself is an = LSP re-creation process).  I am not sure that we intended to = employ any real filtering in a standard implementation, although = vendors do add knobs (or rope).

Thanks for taking the time to get this = clarified.

Chris

PS

WRT to 64 bit tags, that was not my original intent - = it came in later as a means to carry extended communties for carrier of = carrier type applications.  The semantics seemed such that stackin = 32 bit tags for this purpose may introduce some ambiguity, so a = separate sub-TLV was introduced.  I would think it would be easier = to code in this fashion - Stefano?


>Alex
>

------_=_NextPart_001_01C310E5.541D08D0-- From rtg-dir-admin@ietf.org Fri May 2 22:22:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09740 for ; Fri, 2 May 2003 22:22:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bmhu-0001g0-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 22:24:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Bmht-0001fx-00 for rtg-dir-archive@ietf.org; Fri, 02 May 2003 22:24:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h432U1818074; Fri, 2 May 2003 22:30:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h432To818051 for ; Fri, 2 May 2003 22:29: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 WAA09734 for ; Fri, 2 May 2003 22:22:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bmhc-0001fq-00 for rtg-dir@ietf.org; Fri, 02 May 2003 22:24:40 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19BmhW-0001fk-00 for rtg-dir@ietf.org; Fri, 02 May 2003 22:24:34 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19Bmhp-000GZc-00 for rtg-dir@ietf.org; Sat, 03 May 2003 02:24:53 +0000 Date: Fri, 2 May 2003 19:22:48 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <27134083782.20030502192248@psg.com> To: rtg-dir@ietf.org Subject: Fwd: On BGP and VPLS In-Reply-To: <51133594448.20030502191439@psg.com> References: <51133594448.20030502191439@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI below. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: ppvpn@nortelnetworks.com Cc: Date: Friday, May 2, 2003, 7:14:39 PM Subject: On BGP and VPLS ===8<==============Original message text=============== Folks, As an Area Director, and an IESG member, I try to express my technical opinions during WG discussions only when it really matters, e.g., when I think a WG is going in a wrong direction, or a technically bad idea is being considered. However, I believe that ADs do need to do this to prevent surprises when documents get to the IESG. Also, when documents are ready to go to the RFC status, it is the responsible AD who takes them to the IESG and defends them there, so I think it is useful for ADs to communicate their concerns to the WGs when such exist. I have been watching the discussion about draft-kompella-ppvpn-vpls on the mailing list and didn't get the feeling that certain aspects of it have been taken seriously enough. Without an attempt to respin the heated discussion again, it seems it would be useful for the WG if I provided some feedback on the topic now, when the WG is discussing the direction in which it should proceed. First of all, let me remind you the message Scott and I brought to the WG in Yokohama--the IESG is very concerned about the tendency of using routing protocols (and BGP in particular) as a universal transport mechanism, and a _very_ strong case would need to be made if the WG decided to go with such a proposal. More specifically, below I tried to put together a list of concerns I have about the approach described in draft-kompella-ppvpn-vpls, that I would like the WG to consider. 1. Use of the NLRI field As an IP routing protocol, BGP uses the NLRI field to carry IP reachability information in the form of IP prefixes. Prefixes within the NLRI field are used for two main purposes in BGP: a) as the destination/mask pair in the routes installed by BGP in the routing table, and b) as a handle to an entry in the BGP RIBs. The document in subject changes the semantics of the NLRI field quite substantially even when compared to 2547. First, all of its IP prefix-related properties are lost. There is no more IP routing, or any addressing information in it. Second, the notion of TLVs is introduced inside this field, which a) is not needed in BGP as an IP routing protocol, and b) because of its variable length property changes the nature of the NLRI contents, i.e., it's being a stable handle in the BGP database. To solve these problems the implementations would need to use only a part of the contents of the NLRI field as the handle used to index within the RIBs, and store the rest as attributes. 2. Distribution of information When used as an IP routing protocol, BGP distributes routes among all participating routers. Each router (PE or P using VPN terminology) is interested in _all_ routes received from its peers; it selects the best path for each prefix if multiple are available and installs it in it's routing table; the best paths are propagated further to other peers. The way BGP is used in the document results in a situation where information relevant only to a subset of routers (e.g. PW-specific, or VPLS-specific info) is sent to all PEs participating in the BGP domain. More than that, P routers, usually used as route reflectors in IP routing, end up storing all information while they are not using any of it locally. Note also, that best path selection that is normally performed by BGP when it receives information about the same prefix from multiple peers, is not needed in the VPLS case, and (even if implementations decided to apply the same algo as in regular BGP) would just be an artifact. The above exposes the difference between the routing nature of BGP when used for IP (where reachability info is distributed and the path properties are as important as the info itself), and its purely transport application in the proposal (where only the fact of information delivery is important.) Interestingly enough, from the transport perspective, BGP, though reduces the number of sessions a given PE has to maintain (and thus the sender's complexity), introduces additional overhead from the receiver's perspective--if a PE router has multiple BGP sessions (which is normally the case), it will receive the same information more than once, while clearly a single copy is enough. 3. Aggregation of information for large-scale operation When distributing information among a large number of systems, it is important to be able to aggregate information as it travels further ahead to ensure scalability of the system. In routing this is achieved by summarizing a set of prefixes and announcing them as a less specific prefix. For example, AS'es in the Internet do not exchange granular IP prefixes visible inside IGPs, but instead send each other aggregate prefixes via BGP. It is not clear to me how, given the format of the NLRI field, VPLS information can be aggregated using the proposal in the document. The above gives me a very uncomfortable feeling that the proposal is stretching BGP to perform functions it was not designed for. Below are some additional points that should be taken into consideration. 4. Backwards compatibility and SW upgrade requirements Because the proposal suggests using a new AFI/SAFI combination, PE routers will not be able to announce VPLS information using the existing BGP infrastructure. All BGP speakers in a SP's network, including the P routers, will have to be upgraded with new SW, though information needs to be exchanged only among the PEs. 5. Coupling of VPLS and BGP SW Putting VPLS-related functions in BGP leads to two unwanted consequences: a) Lesser BGP code stability--bugs in the VPLS part of the code will likely affect parts of BGP used for Internet routing, thus increasing the chances of BGP failures in SP networks. The same argument works in the opposite direction. b) Potential dynamic effects--since with a BGP-based approach, VPLS- and routing-related processes are likely to share the same internal router resources (such as timers, threads, locks/mutex'es, queues, memory pools), dynamics of the VPLS system are likely to influence the dynamics of the routing- related functions and vice versa. The larger the overlap between the two systems, the higher are the chances of such interference. My recommendation would be for the WG to consider these points. Also, one quite important question I saw brought up by Eric in this discussion was about the p2p nature of PW signaling in VPLS. I think this is one of the key questions that we need an agreement on. The question asked by Robert today is also quite interesting. Regards. -- Alex Zinin IETF SUB-IP Area Co-Director ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Sat May 3 01:43:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12133 for ; Sat, 3 May 2003 01:43:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BpqO-0002N4-00 for rtg-dir-archive@ietf.org; Sat, 03 May 2003 01:45:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BpqN-0002N0-00 for rtg-dir-archive@ietf.org; Sat, 03 May 2003 01:45:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h435p2830921; Sat, 3 May 2003 01:51:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h435m0830778 for ; Sat, 3 May 2003 01:48: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 BAA12087 for ; Sat, 3 May 2003 01:40:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bpn6-0002M8-00 for rtg-dir@ietf.org; Sat, 03 May 2003 01:42:32 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19Bpn0-0002Ls-00 for rtg-dir@ietf.org; Sat, 03 May 2003 01:42:26 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id F120A3442A; Fri, 2 May 2003 21:56:24 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h435gDYB014427; Fri, 2 May 2003 22:42:14 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on Date: Fri, 2 May 2003 22:42:13 -0700 Message-ID: Thread-Topic: Comments on Thread-Index: AcMQ3OzEJ/v1fkXvTWmyQXKOtWlHrgAWaYLw From: "Tony Li" To: "Alex Zinin" , "stefano previdi" Cc: "Routing Area Directorate" , "Acee Lindem" , "Brad Neal" , "Christian Martin" , "Tony Przygienda" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h435mj830805 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit | >> If it produces the same set of routes as the standard SPF, | >> we're fine. | | > yes, and of course it does... otherwise my nights would be | > very short ...;-) | | I would be surprised if you said otherwise! :) | | So maybe we should put in the text some words saying that | implementations should not use tags to change their routing table | calculation in a way that would affect interoperability with | preexisting implementations, or something like this. Specifically, if the computation is functionally equivalent to ISO 10589, then they would be acceptable. Paraphrasing the text that Mike noted would not be inappropriate. Tony From rtg-dir-admin@ietf.org Sat May 3 18:38:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11122 for ; Sat, 3 May 2003 18:38:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19C5fr-0006Vn-00 for rtg-dir-archive@ietf.org; Sat, 03 May 2003 18:40:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19C5fX-0006Vc-00 for rtg-dir-archive@ietf.org; Sat, 03 May 2003 18:39:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h43Mj1815261; Sat, 3 May 2003 18:45:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h43Mhi815203 for ; Sat, 3 May 2003 18:43: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 SAA11105 for ; Sat, 3 May 2003 18:35:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19C5dd-0006V6-00 for rtg-dir@ietf.org; Sat, 03 May 2003 18:37:49 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19C5dI-0006Uy-00 for rtg-dir@ietf.org; Sat, 03 May 2003 18:37:28 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19C5dM-000Gfk-00; Sat, 03 May 2003 22:37:32 +0000 Date: Sat, 3 May 2003 11:45:28 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <67193043622.20030503114528@psg.com> To: "Tony Li" CC: "stefano previdi" , "Routing Area Directorate" , "Acee Lindem" , "Brad Neal" , "Christian Martin" , "Tony Przygienda" Subject: Re: Comments on In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tony, Agreed. I think we all have a good idea of what needs to be done. -- Alex Friday, May 2, 2003, 10:42:13 PM, Tony Li wrote: | >>> If it produces the same set of routes as the standard SPF, | >>> we're fine. > | | >> yes, and of course it does... otherwise my nights would be | >> very short ...;-) > | > | I would be surprised if you said otherwise! :) > | > | So maybe we should put in the text some words saying that > | implementations should not use tags to change their routing table > | calculation in a way that would affect interoperability with > | preexisting implementations, or something like this. > Specifically, if the computation is functionally equivalent to ISO > 10589, > then they would be acceptable. Paraphrasing the text that Mike noted > would > not be inappropriate. > Tony From rtg-dir-admin@ietf.org Mon May 5 19:42:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21615 for ; Mon, 5 May 2003 19:42:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CpdI-0001uS-00 for rtg-dir-archive@ietf.org; Mon, 05 May 2003 19:44:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19CpdH-0001uN-00 for rtg-dir-archive@ietf.org; Mon, 05 May 2003 19:44:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Np2814662; Mon, 5 May 2003 19:51:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45NoM814636 for ; Mon, 5 May 2003 19:50: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 TAA21579 for ; Mon, 5 May 2003 19:41:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CpcX-0001u5-00 for rtg-dir@ietf.org; Mon, 05 May 2003 19:43:45 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19CpcQ-0001tm-00 for rtg-dir@ietf.org; Mon, 05 May 2003 19:43:39 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19CpbJ-000FaJ-00; Mon, 05 May 2003 23:42:29 +0000 Date: Mon, 5 May 2003 16:38:15 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <177177649135.20030505163815@psg.com> To: idr@merit.edu CC: rtg-dir@ietf.org Subject: AD-review comments on draft-ietf-idr-bgp4-20 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, Please find below my AD-review comments. Hopefully they will help improve the document. I tried to consult Andrew's list as much as possible, but do feel free to point out if something has already been discussed and agreed upon. Thanks go to Yakov for kicking me often enough ;) -- Alex Zinin Some nits: - run it by a spelling checker, please - disable hyphenation if possible - include boilerplates for IPR notice, Copyright notice General comment: in some places I highlighted the fact that required behavior is not described using the 2119 language, so it is not clear if a MUST or SHOULD or MAY is applicable. I am sure I've missed some more places like this. I'd like to ask the editors to go through the doc and check this. > A Border Gateway Protocol 4 (BGP-4) > > > > Status of this Memo > > ... > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > Specification of Requirements Nit: move Abstract here. Move requirements after the Acks. > Abstract Should the Abstract say that this spec covers IPv4 only? > 3. Summary of Operation ... > This document uses the term `Autonomous System' (AS) throughout. The > classic definition of an Autonomous System is a set of routers under > a single technical administration, using an interior gateway protocol > (IGP) and common metrics to determine how to route packets within the > AS, and using an inter-AS routing protocol to determine how to route > packets to other ASs. Since this classic definition was developed, it > has become common for a single AS to use several IGPs and sometimes > several sets of metrics within an AS. The use of the term Autonomous > System here stresses the fact that, even when multiple IGPs and met- > rics are used, the administration of an AS appears to other ASs to > have a single coherent interior routing plan and presents a consis- > tent picture of what destinations are reachable through it. Ed: Since 'AS' has been defined before, do we need to repeat the definition here? ... > peer in the same AS is referred to as an internal peer. Internal BGP > and external BGP are commonly abbreviated IBGP and EBGP. Ed: These two have been defined before too ... > Care must be taken to > ensure that the interior routers have all been updated with transit > information before the BGP speakers announce to other ASs that tran- > sit service is being provided. What does the last sentence really mean from the implementation perspective? It used to mean the BGP/IGP synchronization check. Now that iBGP everywhere is assumed, how do we check this condition? > This document specifies the base behavior of the BGP protocol. This > behavior can and is modified by extention specifications. When the Ed: "extension" > protocol is extended the new behavior is fully documented in the > extention specifications. Ed: "extension" > 3.1 Routes: Advertisement and Storage > > For the purpose of this protocol, a route is defined as a unit of > information that pairs a set of destinations with the attributes of a > path to those destinations. The set of destinations are systems whose > IP addresses are contained in one IP address prefix carried in the > Network Layer Reachability Information (NLRI) field of an UPDATE mes- > sage, and the path is the information reported in the path attributes > field of the same UPDATE message. Ed: Repeated definition again ... > If a BGP speaker chooses to advertise the route, it MAY add to or > modify the path attributes of the route before advertising it to a > peer. The intent here is to say that it's ok to modify the attribute set of a previously received route when it's announced further. The way it reads though is that self-originated routes are also within the context and MAY sounds like you don't have to add attributes when announcing those. ... > Changing attribute of a route is accomplished by advertising a > replacement route. The replacement route carries new (changed) > attributes and has the same NLRI as the original route. "same NLRI" implies the same prefix, but not the NLRI field, which can be different (containing other routes), should the use of this term be normalized throughout the document? > 4.2 OPEN Message Format > > After a TCP is established, the first message sent by each side is an "TCP connection" > 5. Path Attributes ... > If a path with recognized transitive optional attribute is accepted > and passed along to other BGP peers and the Partial bit in the > Attribute Flags octet is set to 1 by some previous AS, it is not 'MUST NOT' here? > set > back to 0 by the current AS. Unrecognized non-transitive optional > attributes MUST be quietly ignored and not passed along to other BGP > peers. ... > The same attribute (attribute with the same type) can not appear more > than once within the Path Attributes field of a particular UPDATE > message. What should an implementation do if this happens? > The mandatory category refers to an attribute which MUST be present > in both IBGP and EBGP exchanges if NLRI are contained in the UPDATE Ed: "if the NLRI field is contained" instead? > 5.1.2 AS_PATH ... > b) When a given BGP speaker advertises the route to an external > peer, then the advertising speaker updates the AS_PATH attribute > as follows: > > 1) if the first path segment of the AS_PATH is of type > AS_SEQUENCE, the local system prepends its own AS number as the > last element of the sequence (put it in the leftmost position). 'Leftmost position'... isn't this still open for interpretation? How about wording this relative to the position of the octets in the protocol message? > If the act of prepending will cause an overflow in the AS_PATH > segment, i.e. more than 255 ASs, it is legal What's the recommended behavior here? > to prepend a new > segment of type AS_SEQUENCE and prepend its own AS number to > this new segment. > 5.1.4 MULTI_EXIT_DISC > > > The MULTI_EXIT_DISC is an optional non-transitive attribute which is > intended to be used on external (inter-AS) links to discriminate > among multiple exit or entry points to the same neighboring AS. The > value of the MULTI_EXIT_DISC attribute is a four octet unsigned num- > ber which is called a metric. All other factors being equal, the exit > point with lower metric SHOULD be preferred. If received over EBGP, > the MULTI_EXIT_DISC attribute MAY be propagated over IBGP to other > BGP speakers within the same AS. The MULTI_EXIT_DISC attribute seems that a reference to 9.1.2.2 is due here, as using MED in local route calculation and not propagating it further is dangerous > received from a neighboring AS MUST NOT be propagated to other neigh- > boring ASs. > > A BGP speaker MUST IMPLEMENT a mechanism based on local configuration ^^^^^^^^^lower-case > which allows the MULTI_EXIT_DISC attribute to be removed from a > route. This MAY be done prior to determining the degree of preference what's the recommended behavior here? > of the route and performing route selection (decision process phases > 1 and 2). > > An implementation MAY also (based on local configuration) alter the > value of the MULTI_EXIT_DISC attribute received over EBGP. This MAY > be done prior to determining the degree of preference of the route what's the recommended behavior here? > 5.1.5 LOCAL_PREF ... > A BGP speaker SHALL calculate the degree of preference for > each external route based on the locally configured policy, and Should we be more honest here and say that the implementation must allow the admin to SET the degree of preference through the local policy to influence the best-path selection process, i.e., I don't think any implementation really *calculates* it. > 5.1.6 ATOMIC_AGGREGATE ... > A BGP speaker that receives a route with the ATOMIC_AGGREGATE > attribute MUST NOT make any NLRI of that route more specific (as > defined in 9.1.4) when advertising this route to other BGP speakers. Since deaggregation is not described in this document, do we need this para? > A BGP speaker that receives a route with the ATOMIC_AGGREGATE > attribute needs to be cognizant of the fact that the actual path to > destinations, as specified in the NLRI of the route, while having the > loop-free property, may not be the path specified in the AS_PATH > attribute of the route. What does this really mean from the implementation perspective? > 5.1.7 AGGREGATOR > > > AGGREGATOR is an optional transitive attribute which MAY be included > in updates which are formed by aggregation (see Section 9.2.2.2). A > BGP speaker which performs route aggregation MAY add the AGGREGATOR What's the recommended behavior here? Include or not, and under what circumstances? > 6. BGP Error Handling. ... > The phrase "the BGP connection is closed" means that the TCP connec- > tion has been closed, the associated Adj-RIB-In has been cleared, and > that all resources for that BGP connection have been deallocated. > Entries in the Loc-RIB associated with the remote peer are marked as > invalid. The fact that the routes have become invalid is passed to > other BGP peers before the routes are deleted from the system. What does "the fact is passed" mean? Should we instead say that local route recalculation happens and peers are sent either updated best routes or withdrawals? > 6.2 OPEN message error handling. ... > If the Autonomous System field of the OPEN message is unacceptable, > then the Error Subcode is set to Bad Peer AS. The determination of > acceptable Autonomous System numbers is outside the scope of this > protocol. Shouldn't we say that configuration based detection should be supported, i.e., when remote-as is configured for the peer? ... > If the BGP Identifier field of the OPEN message is syntactically > incorrect, then the Error Subcode is set to Bad BGP Identifier. Syn- > tactic correctness means that the BGP Identifier field represents a > valid IP host address. Is "valid IP host address" defined somewhere, btw? > 6.3 UPDATE message error handling. > > > All errors detected while processing the UPDATE message are indicated > by sending the NOTIFICATION message with Error Code UPDATE Message > Error. The error subcode elaborates on the specific nature of the > error. "are indicated..." is this a MUST, SHOULD, or MAY? ... > If the ORIGIN attribute has an undefined value, then the Error Sub- > code is set to Invalid Origin Attribute. The Data field contains the > unrecognized attribute (type, length and value). Curious: do we really have to drop a session on this condition? Given that the attribute was syntactically correct and the TLV was not broken, so the stream is still in sync and we can move on? Of course, if this is what current implementations do, we have no other choice. ... > If the UPDATE message is received from an external peer, the local > system MAY check whether the leftmost AS in the AS_PATH attribute is Same comment about 'leftmost'... Maybe we should define this somewhere in the beginning of the spec? ... > The NLRI field in the UPDATE message is checked for syntactic valid- > ity. If the field is syntactically incorrect, then the Error Subcode > is set to Invalid Network Field. Should we give more data on what syntactic validity means in this case so people behave consistently? > 6.7 Cease. ... > If the BGP speaker decides to terminate its BGP > connection with a neighbor because the number of address prefixes > received from the neighbor exceeds the locally configured upper > bound, then the speaker MUST send to the neighbor a NOTIFICATION mes- > sage with the Error Code Cease. Should we also say that when the peer decides to discard incoming prefixes, this event should be logged locally? > 8. BGP Finite State machine General comment: I would _really_ appreciate more people looking at this section. > The optional Session attributes are listed below. These optional > attributes may be supported either per connection or per local sys- > tem: > > 1) Delay Open flag Where's the description of this flag and how/when is it set? Same for others below. Should we have a brief description for each attribute? > 2) Open Delay Timer > 3) Perform automatic start flag > 4) Perform automatic stop flag > 5) Passive TCP establishment flag > 6) Perform BGP peer oscillation damping flag > (which will be denoted as stop_peer_flap in text) > 7) Idle Hold timer > 8) Perform Collision detect in Established flag > 9) Accept connections from un-configured peers > 10) Track TCP state flag > 11) Send NOTIFICATION without an OPEN flag > Suggestion: to make reading of the FSM description below easier, we could "merge" the multiword flag names and normalize them, e.g. 'perform automatic start flag' to 'PerformAutoStart flag'. 'Passive TCP establishment flag' to 'PassiveTCPEstablishment flag', 'stop_peer_flap' to 'StopPeerFlag'. > 8.1.1 Administrative Events > > > Please note that only Event 1 (manual start) and Event 2 (manual > stop) are mandatory administrative events. All other administrative > events are optional. The optional attributes do not have to be sup- > ported. However, if these attributes are supported, the state of the > flags should be as indicated. 'flags should be as indicated' does not give a clear understanding of what they are used for. Should the events be sanity-checked by checking those attributes? what's the recommended behavior when the flags are in a different state? > Event3: Automatic start > > Definition: Local system automatically starts the > BGP connection. > When is this event generated by the system? Under what conditions? > Status: Optional depending on local system. > > Optional > attributes: 1) Perform automatic start flag SHOULD be set > if this event occurs. > 2) if the passive Passive TCP establishment flag passive Passive? > Event5: Automatic start with passive TCP flag > > Definition: Local system automatically starts the > BGP connection with the passive flag > enabled. The passive flag indicates > Same question about generation conditions .. > Event23: Open collision dump > > Definition: An event generated administratively > when a connection collision has been > detected while processing an incoming > OPEN message and this connection has been > selected to disconnected. See Section 'to be disconnected' > 6.8 for more information on collision > detection. > > Event23 is an administrative based only 'based on'? > implementation specific policy. This > Event may occur if the FSM is implemented > as two linked state machines. > > > Status: Optional, depending on local system > > Optional > Attributes: If the state machine is to process this > attribute in Established state, > 1) Peform Collision detect in Established 'Perform' > flag SHOULD be set. ... > Event25: NotifMsg > > Definition: An event is generated when a > NOTIFICATION messages is received and message > the error code is anything but > "version error". > > Status: Mandatory > 8.2.1 FSM Definition > > > BGP MUST maintain a separate FSM for each configured peer, Each BGP > peer paired in a potential connection unless configured to remain in > the idle state, or configured to remain passive, will attempt to to to to > connect to the other. For the purpose of this discussion, the active > or connect side of the TCP connection (the side of a TCP connection 'active or connecting'? > sending the first TCP SYN packet) is called outgoing. The passive or > listening side (the sender of the first SYN ACK) is called an incom- > ing connection (see Section 8.2.1.1 on the terms active and passive > below). > > A BGP implementation MUST connect to and listen on TCP port 179 for > incoming connections in addition to trying to connect to peers. For > each incoming connection, a state machine MUST be instantiated. Is this true for implementations that resolve connection collision through one FSM with two transport connections? > 8.2.1.1 Terms "active" and "passive" > > > The terms active and passive have been in our vocabulary for almost a > decade and have proven useful. Ed: The style here is quite different from the rest of the document (i.e., personalization), plus time values tend become outdated with time :) > 8.2.1.2 FSM and collision detection > > > There is one FSM per BGP connection. Prior to determining what peer > a connection is associated with there may be two connections for a > given peer. There SHOULD be no more than one connection per peer. Is above "SHOULD" normative? I.e., should be "should" instead? > The collision detection identifies the case where there is more than > one connection per peer and provides guidance for which connection to > get rid of. When this occurs, the corresponding FSM for the connec- > tion that is closed SHOULD be disposed of. > BTW, I think the specification would really benefit from a section that describes processing of incoming transport connections. > 8.2.2 Finite State Machine > > > Idle state: > > Initially BGP is in the Idle state. Not BGP, but the peer FSM, right? > > In this state BGP refuses all incoming BGP connections. No all incoming connections from that peer? > > resources are allocated to the peer. In response to a > manual start event(Event1) or an automatic start > event(Event3), the local system: > - initializes all BGP resources, all BGP resources or only those needed for the peer? also, what does 'initialize' mean here? > - sets ConnectRetryCnt (the connect retry counter) to zero Seems we have inconsistency in FSM parameter naming here. > In response to a manual start event with the passive TCP connection > flag (Event 4) or automatic start with the passive TCP connection > flag (Event 5), the local system: > - initializes all BGP resources, > - sets ConnectRetryCnt (the connect retry counter) to zero, > - starts the Connect Retry timer with initial value, > - listens for a connection that may be initiated by > the remote peer, and > - changes its state to Active. Ditto comments here > The method of preventing persistent peer oscillation is > outside the scope of this document. So we have these events, but we don't define how to handle them? > Any other events [Events 9-12, 15-28] received in the Idle state > does not cause change in the state of the local system. 'do not cause changes' ? > In response to a manual stop event [Event2], the local system: > - drops the TCP connection, > - releases all BGP resources, > - sets ConnectRetryCnt (the connect retry count) to zero > - sets the Connect Retry timer to zero, and sets timer to zero? 'Stops the timer' instead? > - changes its state to Idle. ... > If the BGP port receives a valid TCP connection indication BGP port? > [Event 14], the TCP connection is processed and > the connection remains in the Connect state. > > If the TCP connection receives an invalid indication [Event 15]: TCP connection receives? > the local system rejects the TCP connection and the connection > remains in the Connect state. > > If the TCP connection succeeds [Event 16 or Event 17], > the local system checks the Delay Open flag prior to > processing. If the Delay Open flag is set, the local system: > - sets the Connect Retry timer to zero, "stops" instead? > - set the Open Delay timer to the initial value, and sets > - stays in the Connect state. > If the Delay Open flag is not set, the local system: > - sets the Connect Retry timer to zero, stops > - completes BGP initialization What does the above really mean? ... > the Open Delay Timer. If the Open Delay timer is running, > the local system: > - restarts the connect retry time with initial value, > - stops the Open Delay timer and resets value to zero, > - continues to listen for a connection that may be > initiated by the remote BGP peer, and > - changes its state to Active. > If the open Delay timer is not running, the local system: > - sets the Connect Retry timer to zero, > - drops the TCP connection, > - releases all BGP resources, and all BGP resources? > - changes its state to Idle. > > If an OPEN message is received with the Open Delay timer is > running [Event 20], the local system: > - sets the Connect Retry timer to zero, > - completes the BGP initialization, What does it mean? > - stops and clears the Open Delay timer (sets the value to zero), > - sends an OPEN message, > - sends a KEEPALIVE message, > - If the hold timer value is non-zero, > - start the keepalive timer to inital value, "starts"... start to initial value? > - reset the hold timer to the negotiated value, Resets > else if hold timer value is zero, > - reset the keepalive timer, and resets > - reset the hold timer value to zero resets > - and changes its state to OpenConfirm. > OK, I'll stop reviewing the FSM text here and will skip to the next section. Given the number of English grammar mistakes, it is clear to me that either it has not been sufficiently reviewed or even read by someone carefully enough or the comments have not been incorporated. Please address. ... > 9. UPDATE Message Handling > > > An UPDATE message may be received only in the Established state. What if it is received in another state? ... > 9.1 Decision Process > > > The Decision Process selects routes for subsequent advertisement by > applying the policies in the local Policy Information Base (PIB) to > the routes stored in its Adj-RIBs-In. The output of the Decision Pro- > cess is the set of routes that will be advertised to peers; the > selected routes will be stored in the local speaker's Adj-RIB-Out RIB-Out or RIBs-out (plural)? > according to policy. > > The selection process is formalized by defining a function that takes > the attribute of a given route as an argument and returns either (a) > a non-negative integer denoting the degree of preference for the > route, or (b) a value denoting that this route is ineligible to be > installed in LocRib and will be excluded from the next phase of route Loc-RIB > selection. ... > The Decision Process operates on routes contained in the Adj-RIB-In, Adj-RIBs-In (plural) ? > and is responsible for: > 9.1.1 Phase 1: Calculation of Degree of Preference ... > If the route is learned from an external peer, then the local BGP > speaker computes the degree of preference based on preconfigured > policy information. If the return value indicates that the route > is ineligible, the route MAY NOT serve as an input to the next > phase of route selection; otherwise the return value is used as > the LOCAL_PREF value in any IBGP readvertisement. So, AFAIK, the major implementations do not follow this step (calculating the degree of preference, and then announcing). Instead, implementations allow setting the LOCAL_PREF value locally, which is taken into consideration during the best path selection, and is also reannounced further. Also "is used" is not specific enough. Is it SHOULD or MUST? > 9.1.2 Phase 2: Route Selection ... > If the AS_PATH attribute of a BGP route contains an AS loop, the BGP > route should be excluded from the Phase 2 decision function. AS loop > detection is done by scanning the full AS path (as specified in the > AS_PATH attribute), and checking that the autonomous system number of > the local system does not appear in the AS path. Operations of a BGP > speaker that is configured to accept routes with its own autonomous > system number in the AS path are outside the scope of this document. If we're checking for an AS loop here (in Phase 2) as opposed to during the UPDATE message sanity checking, the route is already received and accepted in the peer's Adj-RIB-In. Those implementations I know don't even install such routes in the RIB... > 9.1.2.2 Breaking Ties (Phase 2) ... > Similarly, neighborAS(n) is a function which returns the neighbor > AS from which the route was received. If the route is learned via > IBGP, and the other IBGP speaker didn't originate the route, it is > the neighbor AS from which the other IBGP speaker learned the > route. If the route is learned via IBGP, and the other IBGP > speaker originated the route, it is the local AS. What if the route is locally originated? > 9.1.4 Overlapping Routes ... > When overlapping routes are present in the same Adj-RIB-In, the more > specific route takes precedence, in order from more specific to least > specific. > Doesn't this happen at the packet forwarding stage? > > The set of destinations described by the overlap represents a portion > of the less specific route that is feasible, but is not currently in > use. If a more specific route is later withdrawn, the set of desti- > nations described by the overlap will still be reachable using the > less specific route. > > If a BGP speaker receives overlapping routes, the Decision Process > MUST consider both routes based on the configured acceptance policy. > If both a less and a more specific route are accepted, then the Deci- > sion Process MUST either install both the less and the more specific Install where? > routes or it MUST aggregate the two routes and install the aggregated > route, provided that both routes have the same value of the NEXT_HOP > attribute. anyone really does the latter? > If a BGP speaker chooses to aggregate, then it SHOULD either include > all AS used to form the aggreagate in an AS_SET or add the > ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- > marily informational. With the elimination of IP routing protocols > that do not support classless routing and the elimination of router > and host implementations that do not support classless routing, there > is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- > gated. A route that carries ATOMIC_AGGREGATE attribute in particular > MUST NOT be de-aggregated. That is, the NLRI of this route can not be > made more specific. Forwarding along such a route does not guarantee > that IP packets will actually traverse only ASs listed in the AS_PATH > attribute of the route. Since we don't do deaggregation any more, should we remove the discussion about it completely and indicate in the "changes" section that deaggregation has been deprecated? > 9.2 Update-Send Process ... > When a BGP speaker receives an UPDATE message from an internal peer, > the receiving BGP speaker SHALL NOT re-distribute the routing infor- > mation contained in that UPDATE message to other internal peers, > unless the speaker acts as a BGP Route Reflector [RFC2796]. Suggest to put "unless..." in brackets () to make it more apparent that this is not a normative ref. > 9.2.1.1 Frequency of Route Advertisement > Since fast convergence is needed within an autonomous system, either > (a) the MinRouteAdvertisementInterval used for internal peers SHOULD > be shorter than the MinRouteAdvertisementInterval used for external > peers, or (b) the procedure describe in this section SHOULD NOT apply > for routes sent to internal peers. It sounded like MinRouteAdvertisementInterval was an architectural constant, but now it sounds like either this is a timer that can be assigned different settings or there are two constants: MinRouteAdvIntIBGP and MinRouteAdvIntEBGP. > 9.2.2.2 Aggregating Routing Information > Hmmm... I expected to see in this section some text talking about when and how an aggregate would be announced, i.e., when an aggregate prefix is configured, and more specific routes are present, the aggregate is announced, when no specifics are left--withdraw the aggregate. I haven't found anything on this topic... > 9.3 Route Selection Criteria > > Generally speaking, additional rules for comparing routes among sev- > eral alternatives are outside the scope of this document. There are > two exceptions: > > - If the local AS appears in the AS path of the new route being > considered, then that new route can not be viewed as better than > any other route (provided that the speaker is configured to accept > such routes). If such a route were ever used, a routing loop could > result. > > - In order to achieve successful distributed operation, only > routes with a likelihood of stability can be chosen. Thus, an AS > SHOULD avoid using unstable routes, and it SHOULD NOT make rapid > spontaneous changes to its choice of route. Quantifying the terms > "unstable" and "rapid" in the previous sentence will require expe- > rience, but the principle is clear. > Where does this (the second one) fit within and how does this affect the route selection criteria? > Care must be taken to ensure that BGP speakers in the same AS do not > make inconsistent decisions. How? What does this mean for the implementor? > 9.4 Originating BGP routes > > A BGP speaker may originate BGP routes by injecting routing informa- > tion acquired by some other means (e.g. via an IGP) into BGP. A BGP > speaker that originates BGP routes assigns the degree of preference > "assigns the degree of preference"... how do the implementations really do that? > 10 BGP Timers ... > The suggested default value for the MinRouteAdvertisementInterval is > 30 seconds. This was described as a parameter, not a timer. Further, it was earlier suggested that it should be shorter for iBGP than it is for eBGP. I'd expect the document to specify the recommended value for both. > IANA Considerations ... > All extensions to this protocol, including new message types and Path > Attributes MUST only be made using the Standards Action process > defined in [RFC2434]. This section should include the description of each registry that needs to be created (if needed) and maintained by IANA, as well as the allocation policy that is in the text already. From rtg-dir-admin@ietf.org Wed May 7 08:18:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27289 for ; Wed, 7 May 2003 08:18:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DNuZ-0000Zw-00 for rtg-dir-archive@ietf.org; Wed, 07 May 2003 08:20:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DNuY-0000Zs-00 for rtg-dir-archive@ietf.org; Wed, 07 May 2003 08:20:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47CS1810306; Wed, 7 May 2003 08:28:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47CRf810284 for ; Wed, 7 May 2003 08:27: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 IAA27272 for ; Wed, 7 May 2003 08:18:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DNuE-0000ZQ-00 for rtg-dir@ietf.org; Wed, 07 May 2003 08:20:18 -0400 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by ietf-mx with esmtp (Exim 4.12) id 19DNuB-0000Yh-00 for rtg-dir@ietf.org; Wed, 07 May 2003 08:20:15 -0400 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h47CKRju058600; Wed, 7 May 2003 14:20:27 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h47CGhx5020552; Wed, 7 May 2003 14:16:44 +0200 Received: from dhcp69-86.zurich.ibm.com by sihl.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA53834 from ; Wed, 7 May 2003 14:16:40 +0200 Message-Id: <3EB8F928.3000103@zurich.ibm.com> Date: Wed, 07 May 2003 14:16:40 +0200 From: Patrick Droz Organization: IBM Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en Mime-Version: 1.0 To: Pekka Savola Cc: "Putzolu, David" , "'Alex Zinin'" , "'rtg-dir@ietf.org'" , "'randy@psg.com'" Subject: Re: draft-ietf-forces-requirements-08.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Pekka, sorry for the late response I thought my co-chair had already answered. Pekka Savola wrote: > Hi, > > Sorry for the delay in responding. > > On Tue, 8 Apr 2003, Putzolu, David wrote: > >>Thanks for the feedback - responses inlined... >> >> >>>Comments on forces-reqs-08. In summary, I'd like to express a very >>>grave concern of trying to address every possible problem, a path that >>>seems doomed to failure. Note a list of dozen different forwarding >>>functionalities that still fail to capture all of them -- and the >>>associated complexity of handling all the different nuances and >>>orderings of these functions. >>> >>>Seems way, WAY too complex to make interoperable and useful. I wonder >>>how far we have to go with this effort to see it as a dead-end. Or >>>alternatively, some other architectural/approach revamp might be able >>>to salvage some of the mechanisms (e.g. concentrate on certain core >>>tasks only, but then again, one might question how useful the >>>mechanism is). >> >>I agree that trying to define all possible features is >>infeasible, as the list is ever-evolving. I also agree >>that a reduction to a single feature (e.g. only address >>IPv4 forwarding and nothing else), while feasible, is >>useless. >> >>The initial goal of forces is to try to capture that 20% >>of features/configurations that applies to 80% of the >>applicable scenarios. > > > Ok, I guess it remains to be seen later whether this is the right > approach. My worry is that if we don't define the "applicable scenarios" > properly (or define wrong scenarios), we might end up specifying the > wrong 20%. > > >>>1) it is not clear how different efforts (most of which referenced in >>>the draft) interconnect: e.g. midcom (similar protocol between hosts, >>>typically), gsmp, ccamp. >> >>This seems like a framework question, not a requirements >>question. That being said, I will answer as best I can. >>Midcom is primarily focused on NAT and ALGs. One could >>construct a NAT box using CE/FE separation. If that is the >>case, ForCES might be present. Midcom would deliver information >>to the CE (e.g. "open this port for a RTP stream as part of >>this H.323 call"), the CE would then configure the FE appropriately >>("add ACL entry: pass ports 3310/3311 between hosts A and B"). > > > Yes, that was my impression. > > >>GSMP controls switches. The GSMP authors are following ForCES >>pretty closely (one is a co-author on the requirements). Thus >>far ForCES has focused on CE/FE separation routers (not switches). >>Could GSMP be used to control FE routing functions? Yes, but the >>GSMP authors have so far not indicated a desire to extend GSMP for >>that. Could ForCES be used to control FE switching functions? >>Yes, but that would be extending the scope of ForCES significantly. >>Is routing enough to satisfy the 80/20 rule, or do you think that >>switching must be thrown in as well? Sounds like a scope/charter- >>level change, so I'm hesitant to jump into that debate. > > > I got the impression that Ethernet switches (or at least the quite typical > switch/routers) were in scope, but I may have misread. > > >>>2) I find the justification a bit questionable: >>> >>> A standard set of mechanisms for connecting >>> these components provides increased scalability and allows the >>> control and forwarding planes to evolve independently, thus >>> promoting faster innovation. >>> >>>.. it seems to me that in practice, such independent evolution and >>>innovations typically require changes in both elements: I doubt one >>>can create such a generic architecture which would accommodate >>>anything happening to the other in the future. >> >>Anything talking to anything is impossible. A CE talking to successively >>faster generations of FEs with IPv4 forwarding and DS support, using the >>same standard ForCES protocol, is possible. > > > My experience indicates that typically CE's develop faster than FE's -- > due to simplicity of generic programming, rather than implementing > hardware functions. But CE's supporting more features than FE's > doesn't seem all too useful. > I think here we have a misunderstanding. FE's are supposed to mainly address the "fast pass" of the "data path" which is a fraction of what the "data path" as part of the CE can do (example: handling IP options). It is actually better that CE's are developing faster which makes it always possible that the CE's can make best use of the offerings of the FE's. It would be bad to have FE's that can offer a lot of features which the CE's can not configure and manage. > >>>3) the applicability of ForCES seems to be unclear, for example: >>> >>> Addressable Entity (AE) - A physical device that is directly >>> addressable given some interconnect technology. For example, on IP >>> networks, it is a device to which we can communicate using an IP >>> address; and on a switch fabric, it is a device to which we can >>> communicate using a switch fabric port number. >>> >>>.. the latter would seem to indicate some support for non-IP devices >>>too, or should this use some rewording to clarify which kind of switch >>>fabric was the question was all about? >> >>ForCES will define a model that applies to FEs that are >>network-connected and backplane/fabric connected. >>ForCES protocol will then run over IP, ForCES model will be >>likely reused for non-IP CE<->FE link scenarios (analogous to >>GSMP over Ethernet/GSMP over ATM/GSMP over IP). AE is an >>effort to get a term which works equally well in both cases. > > > Ok. > > >>>4) I haven't delved into ForCES, but the last two sentences look a bit >>>scary: >>> >>> Forwarding Element (FE) - A logical entity that implements the >>> ForCES protocol. FEs use the underlying hardware to provide per- >>> packet processing and handling as directed by a CE via the ForCES >>> protocol. FEs may use PFE partitions, whole PFEs, or >>> multiple PFEs. >>> >>>.. this seems to imply that CE's instruct logical FE's to perform some >>>tasks, while there exists some protocol between FE->PFE. >>> >>>- what is used between FE and PFE's? >>>- are there interoperability reqs between FE / PFE's (can >>>they be from >>>different vendor)? >>>- is this useful at all? Seems like very dangerous to me -- >>>because might >>>require an additional abstraction layer at FE's -- which >>>might make the >>>CE-FE control even more useless (too generic) and less powerful. >> >>I agree the wording is bad and it should be fixed. What should >>be coming across here is that a FE is what a CE controls. If >>under the covers the FE happens to be a single blade, a partition >>of a blade, of two physical blades that through proprietary magic >>appear as a single very reliable blade to the CE, is beyond the >>scope of concern of forces. > > > Yep, clarification will be helpful. > I will bring it to the DT to clarify. > >>>5) Is the partitioning concept really useful? Could you list some >>>applicability scenarios? >> >>I will provide some scenarios because you ask, but I personally >>am not comfortable arguing for it. The main point I'd like to >>make is that ForCES should be agnostic about partitioning issues, >>and forcing ForCES to define/care about/create partitioning would >>be an undesirable complexity. > > > I totally agree here. I have not seen scenarios by David but let me try to step in. The GSMP did the full exercise in terms of partitioning. Partitioning sometimes also called virtualization seems to be a rather hot topic. The main argument for it is that a single user will not be able to make use the total available resources so you want to share it among many different users but preventing that they get on each others turf. I completely agree it is difficult to achieve but it is doable. Another example would be to assign certain resources to certain VPN. I will poll the DT on the subject. > > >>Potential applicability scenario: Service provider wants a >>capability to offer hard guarantees to customers that they >>get access, performance, and control of what looks like their >>own virtual router. SP can either buy a physical box per >>customer (expensive) or partition a single physical box into >>logical partitions. >> >>Again - this isn't and shouldn't be for ForCES to spec out. >>Main point here is that ForCES shouldn't care if somebody >>does partitioning under the covers ahead of time - a FE is a FE. >> >> >> >>>6) Is it possible to have multiple CE's manage one FE? This probably >>>would have tradeoffs and drawbacks, but is integral when you consider >>>the applicability of the protocol (ie. is it a network management >>>protocol or control-dataplane protocol). >> >>Yes - multiple CEs may control one FE. When this happens the CEs >>had better make sure to coordinate among each other so that they >>don't give contradictory orders to the FE. >> >>Simple case: 1 CE talking to FE. >>Possible case: 2 CEs, from same vendor, speaking proprietary >> CE<->CE protocol to coordinate with each other, control parts >> of the same FE. >>Theoretical case: Somebody defines that CE<->CE protocol and >> heterogeneous CEs used. Hard problem and beyond the scope of >> ForCES. > > > Perhaps this could be spelled out in the requirements, to some degree; > like: > > Multiple CE's controlling one FE MAY be supported. However, > coordination between CE's is out of scope. > I think this what reflects the consensus of the group. So I will ask the DT to spell it out. > (or even a bit more, or even more harsh wording.) > > In addition to listing requirements, it's IMO also useful to list > _non-requirements_. But YMMV. > > >>>7) Is it necessary/useful to keep the ForCES protocol >>>open-ended even now? >>>I fail to see valid reasons for multiple protocols..: >>> >>> ForCES Post-Association Phase Protocol - [...] >>> This protocol could be a single protocol or >>> could consist of multiple protocols working together. >> >>Looking at router functions, there can be a fairly large >>difference between the proportion of CE<->FE "control" traffic >>(that is: CE giving new FIB entries to FE, FE reporting alarms >>to CE, etc.) and the CE<->FE "data" traffic (that is: OSPF >>HELLO and other packets, the SNMP SET/GETs, the TCP SYN >>arriving from a peer router setting up a BGP connection). >> >>Also: The CE<->FE data traffic has quite different reliability >>requirements. That is: If a SNMP packet, which arrived over >>UDP, gets dropped in transport between FE and CE, it is much >>less of a problem than if a CE packet adding an ACL entry >>gets dropped going from CE to FE. >> >>Also: In some architectures there is a physically, or at least >>logically (different queue etc) distinct control channel from >>data channel. >> >>Given these different requirements and characterizations, >>the ForCES architecture might specify that some traffic >>("data" traffic) gets transported over a lightweight, >>unreliable protocol, and other traffic ("control" traffic) >>gets transported over a reliable, perhaps even secure, >>protocol. >> >>Mandating in the requirements that all types of CE<->FE >>traffic all run over a single protocol/connection just >>doesn't seem something a requirements doc should do. > > > Ok, sounds reasonable. > > I was thinking of specifying multiple protocols for achieving about the > same function, which would seem to be wasteful. > > >>>8) Again, the ForCES model seems quite open-ended: >>> >>> FE Manager - A logical entity that operates in the pre-association >>> phase and is responsible for determining to which CE(s) a FE should >>> communicate. This process is called CE discovery and may involve >>> the FE manager learning the capabilities of available CEs. A FE >>> manager may use anything from a static configuration to a pre- >>> association phase protocol (see below) to determine which CE(s) to >>> use. Being a logical entity, a FE manager might be physically >>> combined with any of the other logical entities mentioned in this >>> section. >>> >>>... I fail to see the usability of FE's discovering CE(s). Being a >>>master-slave association where CE's are masters, I would think it >>>would be natural to assume CE's are the masters and thus _they_ >>>discover their slave FE's. >> >>FEM/CEM discovering each other is outside the ForCES scope. >>The FEM/CEM concept is included to be able to say basically >>"look, we know CEs and FEs need to find each other - and >>we don't define how it is done, because we wanted to limit >>our scope". >> >>For the near future I'd expect that a CEM/FEM might be little >>more than a human being typing in a CE IP address via the >>serial port of the FE and v.v. on the FE. > > > Yep -- could be clarified slightly. ok > > >>>9) In the snippet above and some others: it seems to be typical in the >>>requirements to overload the terminology with rather long >>>architectural descriptions. This has both good and bad sides, but in >>>any case it should be considered whether some other way to achieve the >>>big picture would be more usable. >>> >>>Also, there are some terms in the terminology which are not used in >>>the document. If this is also meant as a terminology document, this >>>might be ok, but otherwise keeping to the minimum might be useful. >> >>This is actually something I've never gotten a good answer >>to. In dealing with terminology, what is the BKM? Is it: >>A) Put all terms we know we will need in the first doc >> (in this case reqs), adding deltas to later docs once >> reqs is published, or >>B) Put in reqs only terms used in reqs - each doc defines >> all the terms it uses, or >>C) Put a separate terminology doc. >> >>I think C doesn't work because it would be a normative >>ref that would hold up other docs from progressing. >>Not sure whether to do A or B though - do you think B >>is the best approach? > > > C is not all that useful here. I don't have a strong opinion on A) vs B). > Personally, I'd probably try to keep the list as simple as possible, to > the extent of understanding the requirements .. and put the rest in > framework, usage model or other documents where the model is expanded. > I will ask the DT to go with your suggestion only putting the relevant terminology in the document. >> >> >>>10) The list of FE functions below is extensive: >>> >>> Some functions that FEs could perform include layer 3 forwarding, >>> metering, shaping, firewall, NAT, encapsulation (e.g., tunneling), >>> decapsulation, encryption, accounting, etc. Nearly all >>>combinations >>> of these functions may be present in practical FEs. >>> >>>.. but in reality, gives little hope, as the list is far from >>>complete, and completely evolving. It seems apparent that if one >>>tries to standardize all the possible functions, with *a lot* of >>>abstractization, this is a source of a LOT of work, and work that's >>>never going to end. >>> >>>.. so, it might be useful to consider the scope: deal with >>>the most basic form of forwarding, and that only, for now. >> >>The section that appears with is just giving an architectural >>overview. The model document is chartered with specifying exactly >>what functions will be tackled by ForCES v1. Most likely it will >>be a shorter list as you suggest. > > > Then my suggestion would be to shorten the list of functions a bit. E.g. > encapsulation, NAT, decapsulation, and encryption seem something that seem > the most redundant of those listed. Or cut it even more dramatically. > ok I ask the DT to come up with a shorter list as an initial ForCES v1 > >>>11) The last sentence here implies a possible disconnect in the >>>architecture: >>> >>> 1) CEs and FEs MUST be able to connect by a variety of interconnect >>> technologies. Examples of interconnect technologies used >>> in current >>> architectures include Ethernet,bus backplanes, and ATM (cell) >>> fabrics. FEs MAY be connected to each other via a different >>> technology than that used for CE/FE communication. >>> >>>==> Is it intended to connect FE's to CE or provide a FE-FE protocol? >>>Having some interconnection and/or protocol between FE's seems useful >>>in a sense, but also potentially out of scope of this architecture. >> >>The goal of this section is to explain that the CE<->FE wire (which is >>what forces cares about) may or may not be the same as the FE<->FE wire. > > > Please state that the latter is out of scope ? > I agree with my co-charis statement. At the moment we have to leave this open. There are certain things that have to be exchanged between an FE and CE as well as among FE. A good example of this is ARP cache synchronization. What we want to avoid in ForCES to come up with things that concern only FE <-> FE relevant things. > >>There are some efforts going on to look at FE<->FE protocol. >>However, the expertise involved (fast path data plane issues, >>state sharing between forwarding devices) is somewhat less >>likely to be found in IETF than the expertise for CE<->FE >>protocol issues. That, in combination to keep ForCES at a >>manageable scale, excluded FE<->FE as a deliverable in the >>ForCES protocol. > > > Good. > > >>>12) This sounds very challenging: >>> >>> The variety of FE functionality that the ForCES architecture allows >>> poses a potential problem for CEs. In order for a CE to >>>effectively >>> control a FE, the CE must understand how the FE processes packets. >>> We therefore REQUIRE that a FE model be created that can express >>>the >>> logical packet processing capabilities of a FE. >>> >>>.. I'd say that most functionalities differ *a lot* from vendor to >>>vendor. Are you really, really sure that you should (or can) express >>>all of these in completely independent way *AND* that subsequent use >>>if it's understood would be *effective*. Also see other subsections >>>here, like 6.2. >> >>The functions do sometimes differ from vendor to vendor. >>There is an opposing trend going on with the emergence of >>merchant silicon and network processors that is leading >>to some convergence of (at least the basic) FE >>functionalities around one or a few basic models. > > > If you say so. > > >>>13) Another architectural problem..: >>> >>>6.3. Ordering of Logical Functions >>> The model MUST be capable of describing the order in which these >>> logical functions are applied in a FE. The ordering of logical >>> functions is important in many cases. For example, a NAT function >>> may change a packet's source or destination IP address. Any number >>> of other logical functions (e.g., layer 3 forwarding, >>>ingress/egress >>> firewall, shaping, accounting) may make use of the source or >>> destination IP address when making decisions. The CE needs to know >>> whether to configure these logical functions with the pre-NAT or >>> post-NAT IP address. [...] >>> >>>.. so are we talking about N! possible orderings (with N >>>possible logical >>>functions). Seems like a horror ("pre-nat post-qos-meter >>>pre-qos-classification pre-forward-do-something foo bar boo >>>baf"-state). >> >>The difference between English and nonsense is that one >>can combine letters (and words) in any order, but one >>can only make an English word or sentence if one follows >>certain rules of grammar. >> >>Same for routers. Given a repertoire of the most well known >>functions (words), it is likely that a few particular >>configurations (sentences) will be common. > > > I seem to have different kind of routers in mind. Of course, one could > try to do some "pattern recognition" or whatever, but I'm not sure how > useful such would be. > I agree with my co-chair on this. Let me try to explain. Take a traditional centralized router with all the functionality a router can do in software. When you look at the data plane code you can draw a clear graph (nodes representing the functionality) a packet can travel through a router. This different paths through the graph represent the set of possible sequences. Such a graph has a single entry point and a single exit point, and some node a probability assigned that the packet will be dropped or lost. > >>That being said: I expect initially that ForCES will only >>work for the most basic configs, enabling interoperability >>between simple devices, or devices that have been pre-tested >>with each other. That is a good step forward from today, >>even if it isn't the ultimate goal of plug-n-play any CE >>to FE. This is not uncommon in IETF. VoIP (RTP/SIP/etc) >>is a good example of where a complex problem required starting >>simple, doing interop tests, interop profiles, plugfests, etc., >>and still doesn't have true off-the-shelf 100% interop, but >>has nevertheless provided significant value. > > > There is a difference of "interoperability issues due to differently > implemented standards" and "interoperability issues due to different ways > non-standard, purposely implementation-specific features are implemented". > > In ForCES, the problem space is of the latter, which is much more > difficult. It can be attacked e.g. by abstraction layers, but a danger is > that by too much abstraction, the operation becomes very complex and you > may lose the original data the abstractization is based on. > > >>>14) I'm having difficulties parsing the actual requirements in: >>> >>> 8)Off-loaded Functions >>> >>>.. do you require that basically any piece of code CE wants to offload >>>to FE's must be supported as long it's expressed as a finite state >>>machine.. or what? That that code is to be executed on all (or a >>>specified portion of) the packets? >> >>Others felt the same way, this is being removed as we speak. > > > Ok, good. here I think I have to kick in against my co-chair. This was heavily discussed on the official mailing list and it was put in there because a significant amount of people had advocated for it. It was never the intend to off-load any piece of code to an FE. Offloading was standing to protocol off-load e.g. TCP / SCTP off-load. As part of the ForCES we have capability discovery during which a FE a signal to the CE "hey I can do TCP offload". Another example would be OSPF hello offload. There are FEs out there that are not doing anything else than TCP off- loading combined with IP forwarding. I completely disagree that something that was put into the document by consensus of the official mailing list ought to be dropped just like this! > > >>>15) I don't disagree that security must be supported (btw. >>>nit: s/make private/encrypt/), but..: >> >>Disagree on the nit: Making private might be a secure Ethernet >>cable, but encrypt is a mathematic function. What we want is >>privacy, the means arrived at doesn't matter (for the reqs at >>least). > > > Ok, I can agree with the distinction but I'd still argue on rewording it > otherwise; "make private" doesn't sound too good. "Ensure privacy"? > (privacy is also a bit dubious word..). > I will ask the DT to come up with a better explanation. > >>> 2)Support for Secure Communication >>> a) FE configuration will contain information critical to the >>> functioning of a network (e.g. IP Forwarding Tables). >>>As such, it >>> MUST be possible to ensure the authenticity and integrity of >>> ForCES protocol messages. >>> b) FE configuration information may also contain >>>information derived >>> from business relationships (e.g. service level agreements). >>> Therefore, it MUST be possible to secure (make private) ForCES >>> protocol messages. >>> >>>.. I'm not sure how applicable this is in in most/some scenarios. >>>For example, if the interconnect between CE and FE's is a >>>shared/dedicated bus, e.g. an Ethernet link, I'm not sure how >>>applicable these are. Basically if the control messages traverse over >>>the Internet, they should be securable. I'm not sure how one >>>considers the possible deployment scenarios, but I don't think >>>over-the-Internet case is too common (typically hinting at CE/FE >>>located in a different NE). >> >>See above & I agree. A shared/dedicated bus is private, but not >>encrypted. The privacy requirement is there, just met by other means >>(physically secure wire). Requirements are being updated to capture this. > > > Ok. > > >>>16) on the use of reliable protocols: >>> >>> 4)Multihop >>> When the CEs and FEs are separated beyond a single hop, the ForCES >>> protocol will make use of an existing RFC2914 compliant L4 protocol >>> with adequate reliability, security and congestion control (e.g. >>> TCP, SCTP) for transport purposes. >>> >>>==> I fail to see the added value of a separate protocol for >>>singlehop links; there, the latency is low and reliable protocols >>>should be quite usable. >> >>Running TCP over a tightly coupled backplane e.g. PCI seems to some >>like overkill. > > > I agree -- but then again, such backplanes are not places for an IP > protocols, probably. > yes, but the same ForCES message format / data structures can be used without being inside an IP packet. > >>I think it might be ok even there but the requirements >>isn't the place to say that - requirements is instead being slightly >>rewritten to focus on what the actual reliability/retransmit requirements >>are. The framework and protocol drafts will then specify how they answer >>those requirements, and one valid answer might be "we do this by using TCP >>in all cases". > > > Ok. > > [snip] > > >>> 9) Any proposed ForCES architectures MUST explain how that >>> architecture supports all of the router functions as defined in >>> [RFC1812]. >>> >>>==> this must be elaborated. RFC1812 is a long RFC, and no proposal >>>should be expected to go through all of these functions! >>>Clearly there are certain specific issues which need to be addressed >> >>here... >> >>Framework document actually does go through 1812 pretty well. > > > Good .. but here, the requirement above will need to be clarified too, > though. > > [snip] > ok I will ask the DT to do so. > >>>Khosravi, Anderson, et. al. Expires July 2003 [Page 1] >>> >>>==> this should be either "Khosravi, et al." or "Khosravi & Anderson" >>>(rfc-ed policy) >> >>Didn't know this one, will get fixed. Does this apply even >>when there are two editors? > > > For one author: > > Doe > > for two authors, it can be: > > Doe & Dee > > for more: > > Doe et al. > I will ask the editor to do so. > (or so I've understood it.) > Thanks, Patrick -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 From rtg-dir-admin@ietf.org Thu May 8 08:12:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20606 for ; Thu, 8 May 2003 08:12:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DkHo-0002VH-00 for rtg-dir-archive@ietf.org; Thu, 08 May 2003 08:14:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DkHo-0002VE-00 for rtg-dir-archive@ietf.org; Thu, 08 May 2003 08:14:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48CM1806268; Thu, 8 May 2003 08:22:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48CLA806230 for ; Thu, 8 May 2003 08:21: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 IAA20585 for ; Thu, 8 May 2003 08:11:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DkGy-0002Ur-00 for rtg-dir@ietf.org; Thu, 08 May 2003 08:13:16 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19DkGx-0002UZ-00 for rtg-dir@ietf.org; Thu, 08 May 2003 08:13:15 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h48CDLT25273; Thu, 8 May 2003 15:13:21 +0300 Date: Thu, 8 May 2003 15:13:21 +0300 (EEST) From: Pekka Savola To: Patrick Droz cc: "Putzolu, David" , "'Alex Zinin'" , "'rtg-dir@ietf.org'" , "'randy@psg.com'" Subject: Re: draft-ietf-forces-requirements-08.txt In-Reply-To: <3EB8F928.3000103@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Wed, 7 May 2003, Patrick Droz wrote: > >>>2) I find the justification a bit questionable: > >>> > >>> A standard set of mechanisms for connecting > >>> these components provides increased scalability and allows the > >>> control and forwarding planes to evolve independently, thus > >>> promoting faster innovation. > >>> > >>>.. it seems to me that in practice, such independent evolution and > >>>innovations typically require changes in both elements: I doubt one > >>>can create such a generic architecture which would accommodate > >>>anything happening to the other in the future. > >> > >>Anything talking to anything is impossible. A CE talking to successively > >>faster generations of FEs with IPv4 forwarding and DS support, using the > >>same standard ForCES protocol, is possible. > > > > My experience indicates that typically CE's develop faster than FE's -- > > due to simplicity of generic programming, rather than implementing > > hardware functions. But CE's supporting more features than FE's > > doesn't seem all too useful. > > I think here we have a misunderstanding. FE's are supposed to > mainly address the "fast pass" of the "data path" which is a fraction > of what the "data path" as part of the CE can do (example: handling > IP options). It is actually better that CE's are developing > faster which makes it always possible that the CE's can make > best use of the offerings of the FE's. It would be bad to have > FE's that can offer a lot of features which the CE's can not > configure and manage. I can agree with this, but I don't think it has bene stated that FE's do not have to implement all the functionality, but that control plane can also handle forwarding plane functionality, if the specific FE element doesn't know how to do them. With some vendors, this "CE overload" may be a typical practice, but not so for all of them. Perhaps trying to insert some discussion on the features of FE/CE like these could clarify the sentence. > >>>5) Is the partitioning concept really useful? Could you list some > >>>applicability scenarios? > >> > >>I will provide some scenarios because you ask, but I personally > >>am not comfortable arguing for it. The main point I'd like to > >>make is that ForCES should be agnostic about partitioning issues, > >>and forcing ForCES to define/care about/create partitioning would > >>be an undesirable complexity. > > > > > > I totally agree here. > > I have not seen scenarios by David but let me try to step > in. The GSMP did the full exercise in terms of partitioning. > Partitioning sometimes also called virtualization seems to > be a rather hot topic. The main argument for it is that a > single user will not be able to make use the total available > resources so you want to share it among many different users > but preventing that they get on each others turf. I completely > agree it is difficult to achieve but it is doable. Another > example would be to assign certain resources to certain VPN. > I will poll the DT on the subject. Ok. > >>>9) In the snippet above and some others: it seems to be typical in the > >>>requirements to overload the terminology with rather long > >>>architectural descriptions. This has both good and bad sides, but in > >>>any case it should be considered whether some other way to achieve the > >>>big picture would be more usable. > >>> > >>>Also, there are some terms in the terminology which are not used in > >>>the document. If this is also meant as a terminology document, this > >>>might be ok, but otherwise keeping to the minimum might be useful. > >> > >>This is actually something I've never gotten a good answer > >>to. In dealing with terminology, what is the BKM? Is it: > >>A) Put all terms we know we will need in the first doc > >> (in this case reqs), adding deltas to later docs once > >> reqs is published, or > >>B) Put in reqs only terms used in reqs - each doc defines > >> all the terms it uses, or > >>C) Put a separate terminology doc. > >> > >>I think C doesn't work because it would be a normative > >>ref that would hold up other docs from progressing. > >>Not sure whether to do A or B though - do you think B > >>is the best approach? > > > > > > C is not all that useful here. I don't have a strong opinion on A) vs B). > > Personally, I'd probably try to keep the list as simple as possible, to > > the extent of understanding the requirements .. and put the rest in > > framework, usage model or other documents where the model is expanded. > > > > I will ask the DT to go with your suggestion only putting the > relevant terminology in the document. Ok. > >>>10) The list of FE functions below is extensive: > >>> > >>> Some functions that FEs could perform include layer 3 forwarding, > >>> metering, shaping, firewall, NAT, encapsulation (e.g., tunneling), > >>> decapsulation, encryption, accounting, etc. Nearly all > >>>combinations > >>> of these functions may be present in practical FEs. > >>> > >>>.. but in reality, gives little hope, as the list is far from > >>>complete, and completely evolving. It seems apparent that if one > >>>tries to standardize all the possible functions, with *a lot* of > >>>abstractization, this is a source of a LOT of work, and work that's > >>>never going to end. > >>> > >>>.. so, it might be useful to consider the scope: deal with > >>>the most basic form of forwarding, and that only, for now. > >> > >>The section that appears with is just giving an architectural > >>overview. The model document is chartered with specifying exactly > >>what functions will be tackled by ForCES v1. Most likely it will > >>be a shorter list as you suggest. > > > > > > Then my suggestion would be to shorten the list of functions a bit. E.g. > > encapsulation, NAT, decapsulation, and encryption seem something that seem > > the most redundant of those listed. Or cut it even more dramatically. > > > > ok I ask the DT to come up with a shorter list as an initial > ForCES v1 Thanks. > >>>11) The last sentence here implies a possible disconnect in the > >>>architecture: > >>> > >>> 1) CEs and FEs MUST be able to connect by a variety of interconnect > >>> technologies. Examples of interconnect technologies used > >>> in current > >>> architectures include Ethernet,bus backplanes, and ATM (cell) > >>> fabrics. FEs MAY be connected to each other via a different > >>> technology than that used for CE/FE communication. > >>> > >>>==> Is it intended to connect FE's to CE or provide a FE-FE protocol? > >>>Having some interconnection and/or protocol between FE's seems useful > >>>in a sense, but also potentially out of scope of this architecture. > >> > >>The goal of this section is to explain that the CE<->FE wire (which is > >>what forces cares about) may or may not be the same as the FE<->FE wire. > > > > > > Please state that the latter is out of scope ? > > I agree with my co-charis statement. At the moment we have to > leave this open. There are certain things that have to be > exchanged between an FE and CE as well as among FE. A good > example of this is ARP cache synchronization. What we want > to avoid in ForCES to come up with things that concern only > FE <-> FE relevant things. Umm. I don't know the details so bear with me: is ARP cache synchronization to be specified or already specified in ForCES, or is this just something implementations will/may have to do? In the latter case, the last sentence: FEs MAY be connected to each other via a different technology than that used for CE/FE communication. should be rephrased slightly, like: FEs MAY be connected to each other via a different technology than that used for CE/FE communication; however, FE-FE interconnection is out of scope. (obviously this is not an optimal wording, but you get the picture what I meant..) > >>>13) Another architectural problem..: > >>> > >>>6.3. Ordering of Logical Functions > >>> The model MUST be capable of describing the order in which these > >>> logical functions are applied in a FE. The ordering of logical > >>> functions is important in many cases. For example, a NAT function > >>> may change a packet's source or destination IP address. Any number > >>> of other logical functions (e.g., layer 3 forwarding, > >>>ingress/egress > >>> firewall, shaping, accounting) may make use of the source or > >>> destination IP address when making decisions. The CE needs to know > >>> whether to configure these logical functions with the pre-NAT or > >>> post-NAT IP address. [...] > >>> > >>>.. so are we talking about N! possible orderings (with N > >>>possible logical > >>>functions). Seems like a horror ("pre-nat post-qos-meter > >>>pre-qos-classification pre-forward-do-something foo bar boo > >>>baf"-state). > >> > >>The difference between English and nonsense is that one > >>can combine letters (and words) in any order, but one > >>can only make an English word or sentence if one follows > >>certain rules of grammar. > >> > >>Same for routers. Given a repertoire of the most well known > >>functions (words), it is likely that a few particular > >>configurations (sentences) will be common. > > > > > > I seem to have different kind of routers in mind. Of course, one could > > try to do some "pattern recognition" or whatever, but I'm not sure how > > useful such would be. > > I agree with my co-chair on this. Let me try to explain. > Take a traditional centralized router with all the > functionality a router can do in software. When you > look at the data plane code you can draw a clear graph > (nodes representing the functionality) a packet can > travel through a router. This different paths through > the graph represent the set of possible sequences. Yes, you can do that, but my argument is that I fear that the graph could be very dense, interconnected. But I'm having trouble figuring out what you actually mean with this "ordering of logical functions". Do you have for example some specific examples? That might help in trying to see the intent here. > >>>14) I'm having difficulties parsing the actual requirements in: > >>> > >>> 8)Off-loaded Functions > >>> > >>>.. do you require that basically any piece of code CE wants to offload > >>>to FE's must be supported as long it's expressed as a finite state > >>>machine.. or what? That that code is to be executed on all (or a > >>>specified portion of) the packets? > >> > >>Others felt the same way, this is being removed as we speak. > > > > Ok, good. > > here I think I have to kick in against my co-chair. This was > heavily discussed on the official mailing list and it was put > in there because a significant amount of people had advocated > for it. It was never the intend to off-load any piece of code > to an FE. Offloading was standing to protocol off-load e.g. > TCP / SCTP off-load. As part of the ForCES we have capability > discovery during which a FE a signal to the CE "hey I can do > TCP offload". Another example would be OSPF hello offload. There > are FEs out there that are not doing anything else than TCP off- > loading combined with IP forwarding. > I completely disagree that something that was put into the document > by consensus of the official mailing list ought to be dropped > just like this! Well, in any case I think the section was not clear exactly what kind of features were to be offloaded. The title says "functions" ("NAT", "filtering"), but what it seems to me are just details of the functions, to make them as lightweigh to the CE as possible. > >>>16) on the use of reliable protocols: > >>> > >>> 4)Multihop > >>> When the CEs and FEs are separated beyond a single hop, the ForCES > >>> protocol will make use of an existing RFC2914 compliant L4 protocol > >>> with adequate reliability, security and congestion control (e.g. > >>> TCP, SCTP) for transport purposes. > >>> > >>>==> I fail to see the added value of a separate protocol for > >>>singlehop links; there, the latency is low and reliable protocols > >>>should be quite usable. > >> > >>Running TCP over a tightly coupled backplane e.g. PCI seems to some > >>like overkill. > > > > I agree -- but then again, such backplanes are not places for an IP > > protocols, probably. > > yes, but the same ForCES message format / data structures > can be used without being inside an IP packet. Is exchanging ForCES messages in PCI backplanes (or where you don't use IP protocols) in scope? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-dir-admin@ietf.org Fri May 9 10:11:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17101 for ; Fri, 9 May 2003 10:11:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E8cx-0004Zj-00 for rtg-dir-archive@ietf.org; Fri, 09 May 2003 10:13:35 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19E8cx-0004Zf-00 for rtg-dir-archive@ietf.org; Fri, 09 May 2003 10:13:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49EM1810606; Fri, 9 May 2003 10:22:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49ELP810566 for ; Fri, 9 May 2003 10: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 KAA17029 for ; Fri, 9 May 2003 10:10:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E8cM-0004ZJ-00 for rtg-dir@ietf.org; Fri, 09 May 2003 10:12:58 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19E8cL-0004ZE-00 for rtg-dir@ietf.org; Fri, 09 May 2003 10:12:57 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h49EDNNE019286; Fri, 9 May 2003 10:13:23 -0400 (EDT) Received: from russpc (rtp-vpn1-91.cisco.com [10.82.224.91]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA11527; Fri, 9 May 2003 10:13:22 -0400 (EDT) Date: Fri, 9 May 2003 10:13:14 -0400 (Eastern Daylight Time) From: Russ White Reply-To: Russ White To: idr@merit.edu cc: rtg-dir@ietf.org Subject: Comments on BGP Draft 20..... Message-ID: X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Some of these are going to echo Alex's comments, but that's okay, I think. Mostly just nits.... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone ----- Abstract: This information is sufficeint to construct a graph of the AS connectivity from which routing loops may be pruned and some policy decisions at the AS level may be enforced. UPDATE Message Format: The information in the UPDATE message can be used to construct a graph describing the relationships of the various Autonomous Systems. In both cases this is true, I suppose, but in neither case does this really describe what the AS Path is used for, right? I would think we'd want to describe it less in terms of a "graph of the connectivity in the internetwork," and more in terms of "a graph of the path through Autonomous Systems ued to reach the destination advertised." It could be confusing, since there isn't anyplace where we discuss building a graph of inconnectivity between the Autonomous Systems.... ----- Forwarding Paradigm: This document uses the term "Autonomous System" (AS) throughout.... This entire paragraph is a repeat--I'd leave it just in the definitions. ----- Forwarding Paradigms: The initial data flow.... This paragraph has two different thoughts in it, one about incremental updates, and the other about keeping data that you've received. It seems like just putting a return after "as the routing tables change." ----- Forwarding Paradigms: The paragraph starting "KEEPALIVE messages" should, I think, be moved up above the section on route exchange. I don't know why, it just seems less like it's jumping all over the place that way. ----- 3.1 Routes: Advertisement and Storage It almost seems like the section about The initial data flow should maybe be put entirely under this section someplace (?). The first paragraph in this section is really a definition of a route vs a prefix, and should probably be in the definitions. The paragraph "Changing attribute of a route...." needs a "the," or attribute needs an "s." ----- 3.2 Routing Information Bases b) Loc-RIB.... I think it might be useful to state the contents of the Loc-RIB are actually installed in the local routing table, and thus used for forwarding packets on this router. I don't see anyplace this connection is made explicit, it seems more like it's implicit throughout the doc. ----- Page 18, a) LOCAL_PREF "....to inform other peers...." should be "....to inform its other peers...." ----- Network Layer Reachability Information "This varibale length field contains a list of IP address prefixes." I think we can kill "address" here. a) Length "The Length field inidicates...." The sentence can start with "Indicates..." b) Prefix "The Prefix field indicates...." The sentence can start with "Indicates...." ----- Network Layer Reachability Information "An UPDATE message can list multiple routes to be withdrawn...." Actually, we don't withdraw routes, we withdraw prefixes, right? The next paragraph shows this confusion, by talking about routes without attributes, but routes are prefixes combined with attributes, so.... They aren't routes, they're prefixes. You remove routes based on withdrawn prefixes, I think. ------ 5. Path Attributes "Well-known attributes MUST be recognized by all BGP implementations." This sentence, as strange as it may sound, implies it's the attributes fault if the BGP implementation doesn't recogonize it, that it's up to the attribute definers to, in some way, make certain that BGP implementations will recognize it. I think it should probably be worded the other way 'round: "BGP implementations MUST recognize all well-known attributes." ----- 5. Path Attributes "All well-known attributes MUST be passed along (after proper updating, if necessary) to other BGP peers." This just seems a little rough. Maybe this: "Once a BGP peer has updated any well-known attributes, it MUST pass these attributes in any updates it transmits to its peers." ----- 5.1.1 ORIGIN "Its value SHOULD NOT be changed by any other speaker." I really think this should be "MUST NOT." I can't think of any reason it wouldn't be, except in the case of aggregation, and that case could be mentioned here as the only known exception (?). From rtg-dir-admin@ietf.org Tue May 13 02:37:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28917 for ; Tue, 13 May 2003 02:37:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FTRv-0000MV-00 for rtg-dir-archive@ietf.org; Tue, 13 May 2003 02:39:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FTRu-0000MQ-00 for rtg-dir-archive@ietf.org; Tue, 13 May 2003 02:39:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D641B06742; Tue, 13 May 2003 02:04:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D63hB06725 for ; Tue, 13 May 2003 02:03: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 CAA28912 for ; Tue, 13 May 2003 02:37:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FTRT-0000MB-00 for rtg-dir@ietf.org; Tue, 13 May 2003 02:39:15 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19FTRS-0000M2-00 for rtg-dir@ietf.org; Tue, 13 May 2003 02:39:14 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4D6dlmJ025718 for ; Mon, 12 May 2003 23:39:47 -0700 (PDT) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp212.cisco.com [10.61.64.212]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA01323 for ; Tue, 13 May 2003 07:39:46 +0100 (BST) Message-Id: <4.3.2.7.2.20030513073628.04d96c50@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 May 2003 07:39:28 +0100 To: rtg-dir@ietf.org From: mike shand Subject: Fwd: Re: Routing Directorate Review Comments on draft-ietf-manet-tbrpf-08.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , >To: mike shand >cc: ogier@erg.sri.com, lewis@erg.sri.com, ftemplin@iprg.nokia.com, > Joseph Macker , > Scott Corson >Reply-To: ogier@erg.sri.com >From: ogier@erg.sri.com >Subject: Re: Routing Directorate Review Comments on >draft-ietf-manet-tbrpf-08.txt >Date: Mon, 12 May 2003 12:54:09 -0700 >Sender: ogier@erg.sri.com > > >Hello Mike, > >Thank you for comments/questions. I have discussed them with >Mark Lewis and Fred Templin. Please see our responses below. > > > I am conducting a routing directorate (rtg-dir) review of this draft, and > > I have a few (relatively trivial) comments/questions. I would be grateful > > for your responses. > > > > Mike Shand > > > > > > > > > > 1. Introduction > > > > The term "proactive routing protocol" has a specific meaning > within the > > MANET context. It might be useful for readers unfamiliar with the concept > > to give a brief definition in the "terminology" section. > >We can add the following definition: > > Proactive routing protocol > A routing prototocol in which each node maintains routes to all > reachable > destinations at all times, whether or not there is currently any need to > deliver packets to those destinations. In contrast, an "on-demand" > routing > protocol discovers and maintains routes only when they are needed. > > > > > 4. Applicability Section > > > > Is there some evidence to support the claim "it can support networks with > > up to a few hundred nodes".? > > e.g. that is the design scope, or simulations and or implementations > > support this. > >We can change this to the following: > > Simulations have shown that TBRPF can support up to 250 nodes > in mobile networks using IEEE 802.11 with a data rate of 2 Mbps. > The number of nodes that can be supported depends on several factors, > including the data rate, the rate of topology changes, and the network > density (average number of neighbors)." > > > 5.1 Overview of neighbor discovery > > > > There seems to be an inconsistency in the use of MUST/MAY in this section > > (and possibly in other sections as well). > > > > In para 7 "must" appears uncapitalized. This seems reasonable, given that > > this is just an overview. > > > > However, in the last para we have "MAY". > >We will change this so that only lower case "must"s and "may"s are used in >the overview section. There is another "MAY" in Section 5.2 (Overview of >Routing) that will also be changed to lower case. > > > 6.1 TBRFP Packet header > > F- flag extension. Should it say that when using F to insert single octet > > of padding, the flag extension bits MUST be zero? > >OK, we will change this to make it clear. >(However, I think it is already implied.) > > > C- Checksum included. > > The phrase "a 16 bit checksum beginning in the first octet of the header > > extension" is ambiguous, since it is not (yet) clear whether the > > "beginning" refers to the data over which the checksum is calculated, or > > the location of the computed checksum. Subsequent text reveals that it is > > the latter, but this could be made clear by saying something like > > > > "a 16 bit checksum in the first two octets of the header extension". > >OK. We will use your suggested wording. > > > Also, this mechanism means that a single bit error (clearing the C bit) > can > > result in undetected corruption. Note that in this case the 16 bits of > > checksum will be interpreted as something else. Is that a concern? > >Good point. We can fix this by eliminating the C bit and always including >the checksum. > > > > > 6.2 TBRPF Packet Body > > > > This use of TLVs is somewhat strange. Normally the L field is always > > present immediately after the T field and hence a new (and not recognized) > > type can be introduced, such that it is simply parsed over and ignored. > > This cannot be done with the proposed structure. IPv6 option TLVs DO have > > the normal property. It is probably confusing to call the TBRPF > messages TLVs > >Good point. We will remove the reference to TLV. I think this was left >over from a previous version of TBRPF that included the L field. >We omitted the L field in order to minimize overhead, which is an >important objective for MANETs. > > > The draft doesn't say what to do with non-recognized type values. Drop the > > packet? > >Yes, we will add that no further messages in the packet are to be >processed when a non-recognized type is encountered. (Since messages >are processed in order, this still allows new types to be introduced >in future versions, as long as new message types are placed after >old message types in a given packet.) > > > > > 6.2.1 Padding Options > > > > Senders MAY > >OK. > > > Is the use of the F bit to insert a one octet pad redundant because of > the > > existence of the Pad1 option? Or are the two intended to serve different > > purposes. (the former inserts padding prior to the length and router ID > > header extensions). It seems odd to have TWO mechanisms to achieve the > same > > ends. > >You are correct that the two mechanisms are intended to serve different >purposes, since the Pad1 option cannot be used to separate the first >octet of the header from any header extensions that follow. > > > > > 7.8 Configurable parameters. > > > > MAX_JITTER Jitter is usually expressed as a percentage, not an absolute > > value, and value of 25% is typical. Is there a particular reason for > > specifying it this way? > >I have seen it both ways. Is there a good technical reason for using >percentage instead of an absolute value? >Can you give me a well-known reference that uses percentage? > >It seems to me that the amount of jitter required to avoid collisions is >best expressed as an absolute value (e.g., 0.1 sec), which does not depend >on the HELLO interval. > >One reason for not expressing it as a percentage is that this might >unintentionally imply that it is OK, for example, to reduce the HELLO >interval from 1 sec to .1 sec while keeping the jitter at 10%. >(10% would be OK for 1 sec but is probably too small for .1 sec.) > >Also, a larger jitter increases overhead (since it is subtracted and >therefore >results in more frequent messages) so we want to keep it at a minimum. >For example, we would not want to use .25 sec if .1 sec is sufficient. > > > > > 10.6 Support for nonMANET Hosts > > > > Should there be a section about how a TBRPF domain interfaces with the > > internet at large? Are there any special considerations? Or is everything > > which needs to be covered dealt with in section 10.5? > >Note that Network Prefix messages are described in in detail Section 8. >(Section 10.5 discusses how these messages might be used in MANETs.) > >We believe that anything beyond this is beyond the scope of the document >(e.g., how to obtain a global address from a gateway or the use of mobile >IP). >We do note in Section 8.1 that gateway routers can advertise default >prefixes. >If you think it would help, we could explain more clearly (in a few sentences) >that gateway routers can be used to provide Internet connectivity and that >they can use Network Prefix messages to advertise external prefixes to the >MANET nodes. > > > > > That's all I have. I haven't reviewed the protocol specification for > > correctness. I assume the authors and WG have already done that:-) > > > >----------------------- >Richard Ogier >Sr. Research Engineer >SRI International >333 Ravenswood Ave. >Menlo Park, CA 94025 >Tel: 650-859-4216 >Fax: 650-859-4812 >Email: ogier@erg.sri.com >------------------------ From rtg-dir-admin@ietf.org Fri May 16 15:11:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08010 for ; Fri, 16 May 2003 15:11:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GkeJ-0002Je-00 for rtg-dir-archive@ietf.org; Fri, 16 May 2003 15:13:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19GkeJ-0002JY-00 for rtg-dir-archive@ietf.org; Fri, 16 May 2003 15:13:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GIe0B03487; Fri, 16 May 2003 14:40:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GIdYB03442 for ; Fri, 16 May 2003 14:39: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 PAA07956 for ; Fri, 16 May 2003 15:11:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Gkdr-0002JP-00 for rtg-dir@ietf.org; Fri, 16 May 2003 15:13:19 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19Gkdq-0002JL-00 for rtg-dir@ietf.org; Fri, 16 May 2003 15:13:18 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 10B7A5EDF35; Fri, 16 May 2003 12:09:49 -0700 (PDT) Message-ID: <3EC537B1.2010800@redback.com> Date: Fri, 16 May 2003 15:10:41 -0400 From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Meyer Cc: rtg-dir@ietf.org Subject: Re: Make that draft-ietf-idr-bgp-analysis-02.txt [Re: please take a look at draft-ietf-idr-bgp-analysis-01.txt] References: <20030428134324.A2672@sprint.net> <20030428134935.A2734@sprint.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dave, Looks good. Comments: Section 5.1.1 - Replace "matter local to an autonomous system matter" with "matter local to an autonomous system". Section 6.1 - Replace "and AS4 is a multihomed customer of both AS3 and AS4" with and "and AS4 is a multihomed customer of both AS3 and AS2". - Replace "ASes" with "AS's"."AS's" is used in the performance tables in section 5.1. - In the diagrams, I think "V" is a better textual down arrow than "\|/". This threw me off since I thought it implied more than the preferred routed path. Thanks, Acee David Meyer wrote: > Sorry about that. > > Thanks for taking a look, > > Dave > > On Mon, Apr 28, 2003 at 01:43:24PM -0700, David Meyer wrote: > >>> Folks, >>> >>> Please take a look at the bgp analysis document. Comments >>> greatly appreciated. >>> >>> Dave >> > -- Acee From rtg-dir-admin@ietf.org Fri May 16 15:14:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08378 for ; Fri, 16 May 2003 15:14:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GkhD-0002La-00 for rtg-dir-archive@ietf.org; Fri, 16 May 2003 15:16:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19GkhC-0002LV-00 for rtg-dir-archive@ietf.org; Fri, 16 May 2003 15:16:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GIh1B03699; Fri, 16 May 2003 14:43:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GIg5B03624 for ; Fri, 16 May 2003 14:42: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 PAA08273 for ; Fri, 16 May 2003 15:13:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GkgI-0002L4-00 for rtg-dir@ietf.org; Fri, 16 May 2003 15:15:51 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19GkgI-0002Kl-00 for rtg-dir@ietf.org; Fri, 16 May 2003 15:15:50 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h4GJGmAo004332; Fri, 16 May 2003 12:16:48 -0700 Date: Fri, 16 May 2003 12:16:48 -0700 From: David Meyer To: Acee Lindem Cc: David Meyer , rtg-dir@ietf.org Subject: Re: Make that draft-ietf-idr-bgp-analysis-02.txt [Re: please take a look at draft-ietf-idr-bgp-analysis-01.txt] Message-ID: <20030516121648.A4324@1-4-5.net> References: <20030428134324.A2672@sprint.net> <20030428134935.A2734@sprint.net> <3EC537B1.2010800@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3EC537B1.2010800@redback.com>; from acee@redback.com on Fri, May 16, 2003 at 03:10:41PM -0400 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Acee, On Fri, May 16, 2003 at 03:10:41PM -0400, Acee Lindem wrote: >> Dave, >> >> Looks good. Comments: >> >> Section 5.1.1 >> >> - Replace "matter local to an autonomous system matter" with >> "matter local to an autonomous system". >> >> Section 6.1 >> >> - Replace "and AS4 is a multihomed customer of both AS3 and AS4" with >> and "and AS4 is a multihomed customer of both AS3 and AS2". >> >> - Replace "ASes" with "AS's"."AS's" is used in the performance >> tables in section 5.1. >> >> - In the diagrams, I think "V" is a better textual down arrow >> than "\|/". This threw me off since I thought it implied more >> than the preferred routed path. Thanks. I will incorporate your comments. Dave From rtg-dir-admin@ietf.org Sat May 17 01:13:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19489 for ; Sat, 17 May 2003 01:13:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Gu2i-0004oA-00 for rtg-dir-archive@ietf.org; Sat, 17 May 2003 01:15:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Gu2h-0004o7-00 for rtg-dir-archive@ietf.org; Sat, 17 May 2003 01:15:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4H4g1B08132; Sat, 17 May 2003 00:42:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4H4fqB08111 for ; Sat, 17 May 2003 00:41: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 BAA19486 for ; Sat, 17 May 2003 01:13:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Gu2W-0004o4-00 for rtg-dir@ietf.org; Sat, 17 May 2003 01:15:24 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Gu2V-0004o1-00 for rtg-dir@ietf.org; Sat, 17 May 2003 01:15:24 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19Gu3f-0008cd-00; Sat, 17 May 2003 05:16:35 +0000 Date: Fri, 16 May 2003 22:10:35 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <92465699530.20030516221035@psg.com> To: mike shand CC: rtg-dir@ietf.org, ogier@erg.sri.com, lewis@erg.sri.com, ftemplin@iprg.nokia.com, Joseph Macker , Scott Corson Subject: Re: : Re: Routing Directorate Review Comments on draft-ietf-manet-tbrpf-08.txt In-Reply-To: <4.3.2.7.2.20030513073628.04d96c50@jaws.cisco.com> References: <4.3.2.7.2.20030513073628.04d96c50@jaws.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mike, Joe, Scott- Could you guys pls send a message to the WG with the comments that Mike sent and the follow-ups? Thanks. -- Alex http://www.psg.com/~zinin/ Monday, May 12, 2003, 11:39:28 PM, mike shand wrote: >>To: mike shand >>cc: ogier@erg.sri.com, lewis@erg.sri.com, ftemplin@iprg.nokia.com, >> Joseph Macker , >> Scott Corson >>Reply-To: ogier@erg.sri.com >>From: ogier@erg.sri.com >>Subject: Re: Routing Directorate Review Comments on >>draft-ietf-manet-tbrpf-08.txt >>Date: Mon, 12 May 2003 12:54:09 -0700 >>Sender: ogier@erg.sri.com >> >> >>Hello Mike, >> >>Thank you for comments/questions. I have discussed them with >>Mark Lewis and Fred Templin. Please see our responses below. >> >> > I am conducting a routing directorate (rtg-dir) review of this draft, and >> > I have a few (relatively trivial) comments/questions. I would be grateful >> > for your responses. >> > >> > Mike Shand >> > >> > >> > >> > >> > 1. Introduction >> > >> > The term "proactive routing protocol" has a specific meaning >> within the >> > MANET context. It might be useful for readers unfamiliar with the concept >> > to give a brief definition in the "terminology" section. >> >>We can add the following definition: >> >> Proactive routing protocol >> A routing prototocol in which each node maintains routes to all >> reachable >> destinations at all times, whether or not there is currently any need to >> deliver packets to those destinations. In contrast, an "on-demand" >> routing >> protocol discovers and maintains routes only when they are needed. >> >> > >> > 4. Applicability Section >> > >> > Is there some evidence to support the claim "it can support networks with >> > up to a few hundred nodes".? >> > e.g. that is the design scope, or simulations and or implementations >> > support this. >> >>We can change this to the following: >> >> Simulations have shown that TBRPF can support up to 250 nodes >> in mobile networks using IEEE 802.11 with a data rate of 2 Mbps. >> The number of nodes that can be supported depends on several factors, >> including the data rate, the rate of topology changes, and the network >> density (average number of neighbors)." >> >> > 5.1 Overview of neighbor discovery >> > >> > There seems to be an inconsistency in the use of MUST/MAY in this section >> > (and possibly in other sections as well). >> > >> > In para 7 "must" appears uncapitalized. This seems reasonable, given that >> > this is just an overview. >> > >> > However, in the last para we have "MAY". >> >>We will change this so that only lower case "must"s and "may"s are used in >>the overview section. There is another "MAY" in Section 5.2 (Overview of >>Routing) that will also be changed to lower case. >> >> > 6.1 TBRFP Packet header >> > F- flag extension. Should it say that when using F to insert single octet >> > of padding, the flag extension bits MUST be zero? >> >>OK, we will change this to make it clear. >>(However, I think it is already implied.) >> >> > C- Checksum included. >> > The phrase "a 16 bit checksum beginning in the first octet of the header >> > extension" is ambiguous, since it is not (yet) clear whether the >> > "beginning" refers to the data over which the checksum is calculated, or >> > the location of the computed checksum. Subsequent text reveals that it is >> > the latter, but this could be made clear by saying something like >> > >> > "a 16 bit checksum in the first two octets of the header extension". >> >>OK. We will use your suggested wording. >> >> > Also, this mechanism means that a single bit error (clearing the C bit) >> can >> > result in undetected corruption. Note that in this case the 16 bits of >> > checksum will be interpreted as something else. Is that a concern? >> >>Good point. We can fix this by eliminating the C bit and always including >>the checksum. >> >> > >> > 6.2 TBRPF Packet Body >> > >> > This use of TLVs is somewhat strange. Normally the L field is always >> > present immediately after the T field and hence a new (and not recognized) >> > type can be introduced, such that it is simply parsed over and ignored. >> > This cannot be done with the proposed structure. IPv6 option TLVs DO have >> > the normal property. It is probably confusing to call the TBRPF >> messages TLVs >> >>Good point. We will remove the reference to TLV. I think this was left >>over from a previous version of TBRPF that included the L field. >>We omitted the L field in order to minimize overhead, which is an >>important objective for MANETs. >> >> > The draft doesn't say what to do with non-recognized type values. Drop the >> > packet? >> >>Yes, we will add that no further messages in the packet are to be >>processed when a non-recognized type is encountered. (Since messages >>are processed in order, this still allows new types to be introduced >>in future versions, as long as new message types are placed after >>old message types in a given packet.) >> >> > >> > 6.2.1 Padding Options >> > >> > Senders MAY >> >>OK. >> >> > Is the use of the F bit to insert a one octet pad redundant because of >> the >> > existence of the Pad1 option? Or are the two intended to serve different >> > purposes. (the former inserts padding prior to the length and router ID >> > header extensions). It seems odd to have TWO mechanisms to achieve the >> same >> > ends. >> >>You are correct that the two mechanisms are intended to serve different >>purposes, since the Pad1 option cannot be used to separate the first >>octet of the header from any header extensions that follow. >> >> > >> > 7.8 Configurable parameters. >> > >> > MAX_JITTER Jitter is usually expressed as a percentage, not an absolute >> > value, and value of 25% is typical. Is there a particular reason for >> > specifying it this way? >> >>I have seen it both ways. Is there a good technical reason for using >>percentage instead of an absolute value? >>Can you give me a well-known reference that uses percentage? >> >>It seems to me that the amount of jitter required to avoid collisions is >>best expressed as an absolute value (e.g., 0.1 sec), which does not depend >>on the HELLO interval. >> >>One reason for not expressing it as a percentage is that this might >>unintentionally imply that it is OK, for example, to reduce the HELLO >>interval from 1 sec to .1 sec while keeping the jitter at 10%. >>(10% would be OK for 1 sec but is probably too small for .1 sec.) >> >>Also, a larger jitter increases overhead (since it is subtracted and >>therefore >>results in more frequent messages) so we want to keep it at a minimum. >>For example, we would not want to use .25 sec if .1 sec is sufficient. >> >> > >> > 10.6 Support for nonMANET Hosts >> > >> > Should there be a section about how a TBRPF domain interfaces with the >> > internet at large? Are there any special considerations? Or is everything >> > which needs to be covered dealt with in section 10.5? >> >>Note that Network Prefix messages are described in in detail Section 8. >>(Section 10.5 discusses how these messages might be used in MANETs.) >> >>We believe that anything beyond this is beyond the scope of the document >>(e.g., how to obtain a global address from a gateway or the use of mobile >>IP). >>We do note in Section 8.1 that gateway routers can advertise default >>prefixes. >>If you think it would help, we could explain more clearly (in a few sentences) >>that gateway routers can be used to provide Internet connectivity and that >>they can use Network Prefix messages to advertise external prefixes to the >>MANET nodes. >> >> > >> > That's all I have. I haven't reviewed the protocol specification for >> > correctness. I assume the authors and WG have already done that:-) >> > >> >>----------------------- >>Richard Ogier >>Sr. Research Engineer >>SRI International >>333 Ravenswood Ave. >>Menlo Park, CA 94025 >>Tel: 650-859-4216 >>Fax: 650-859-4812 >>Email: ogier@erg.sri.com >>------------------------ From rtg-dir-admin@ietf.org Sun May 18 07:11:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06780 for ; Sun, 18 May 2003 07:11:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HM66-0003AT-00 for rtg-dir-archive@ietf.org; Sun, 18 May 2003 07:12:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19HM66-0003AP-00 for rtg-dir-archive@ietf.org; Sun, 18 May 2003 07:12:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4IAe1B03569; Sun, 18 May 2003 06:40:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4IAdUB03526 for ; Sun, 18 May 2003 06:39: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 HAA06769 for ; Sun, 18 May 2003 07:10:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HM5Z-0003AL-00 for rtg-dir@ietf.org; Sun, 18 May 2003 07:12:25 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=rrmail01.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 19HM5Y-0003AB-00 for rtg-dir@ietf.org; Sun, 18 May 2003 07:12:24 -0400 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sun, 18 May 2003 07:13:02 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01510DF7@ftmail.lab.flarion.com> From: Scott Corson To: "'Alex Zinin'" , "'mike shand'" Cc: "'rtg-dir@ietf.org'" , "'ogier@erg.sri.com'" , "'lewis@erg.sri.com'" , "'ftemplin@iprg.nokia.com'" , "'Joseph Macker'" , Scott Corson Subject: RE: : Re: Routing Directorate Review Comments on draft-ietf-mane t-tbrpf-08.txt Date: Sun, 18 May 2003 07:13:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Will do. > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Saturday, May 17, 2003 1:11 AM > To: mike shand > Cc: rtg-dir@ietf.org; ogier@erg.sri.com; lewis@erg.sri.com; > ftemplin@iprg.nokia.com; Joseph Macker; Scott Corson > Subject: Re: : Re: Routing Directorate Review Comments on > draft-ietf-manet-tbrpf-08.txt > > > Mike, Joe, Scott- > > Could you guys pls send a message to the WG with > the comments that Mike sent and the follow-ups? > > Thanks. > > -- > Alex > http://www.psg.com/~zinin/ > > Monday, May 12, 2003, 11:39:28 PM, mike shand wrote: > > >>To: mike shand > >>cc: ogier@erg.sri.com, lewis@erg.sri.com, ftemplin@iprg.nokia.com, > >> Joseph Macker , > >> Scott Corson > >>Reply-To: ogier@erg.sri.com > >>From: ogier@erg.sri.com > >>Subject: Re: Routing Directorate Review Comments on > >>draft-ietf-manet-tbrpf-08.txt > >>Date: Mon, 12 May 2003 12:54:09 -0700 > >>Sender: ogier@erg.sri.com > >> > >> > >>Hello Mike, > >> > >>Thank you for comments/questions. I have discussed them with > >>Mark Lewis and Fred Templin. Please see our responses below. > >> > >> > I am conducting a routing directorate (rtg-dir) review > of this draft, and > >> > I have a few (relatively trivial) comments/questions. I > would be grateful > >> > for your responses. > >> > > >> > Mike Shand > >> > > >> > > >> > > >> > > >> > 1. Introduction > >> > > >> > The term "proactive routing protocol" has a > specific meaning > >> within the > >> > MANET context. It might be useful for readers unfamiliar > with the concept > >> > to give a brief definition in the "terminology" section. > >> > >>We can add the following definition: > >> > >> Proactive routing protocol > >> A routing prototocol in which each node maintains > routes to all > >> reachable > >> destinations at all times, whether or not there is > currently any need to > >> deliver packets to those destinations. In contrast, an > "on-demand" > >> routing > >> protocol discovers and maintains routes only when they > are needed. > >> > >> > > >> > 4. Applicability Section > >> > > >> > Is there some evidence to support the claim "it can > support networks with > >> > up to a few hundred nodes".? > >> > e.g. that is the design scope, or simulations and or > implementations > >> > support this. > >> > >>We can change this to the following: > >> > >> Simulations have shown that TBRPF can support up to 250 nodes > >> in mobile networks using IEEE 802.11 with a data rate of 2 Mbps. > >> The number of nodes that can be supported depends on > several factors, > >> including the data rate, the rate of topology changes, > and the network > >> density (average number of neighbors)." > >> > >> > 5.1 Overview of neighbor discovery > >> > > >> > There seems to be an inconsistency in the use of > MUST/MAY in this section > >> > (and possibly in other sections as well). > >> > > >> > In para 7 "must" appears uncapitalized. This seems > reasonable, given that > >> > this is just an overview. > >> > > >> > However, in the last para we have "MAY". > >> > >>We will change this so that only lower case "must"s and > "may"s are used in > >>the overview section. There is another "MAY" in Section > 5.2 (Overview of > >>Routing) that will also be changed to lower case. > >> > >> > 6.1 TBRFP Packet header > >> > F- flag extension. Should it say that when using F to > insert single octet > >> > of padding, the flag extension bits MUST be zero? > >> > >>OK, we will change this to make it clear. > >>(However, I think it is already implied.) > >> > >> > C- Checksum included. > >> > The phrase "a 16 bit checksum beginning in the first > octet of the header > >> > extension" is ambiguous, since it is not (yet) clear whether the > >> > "beginning" refers to the data over which the checksum > is calculated, or > >> > the location of the computed checksum. Subsequent text > reveals that it is > >> > the latter, but this could be made clear by saying something like > >> > > >> > "a 16 bit checksum in the first two octets of the header > extension". > >> > >>OK. We will use your suggested wording. > >> > >> > Also, this mechanism means that a single bit error > (clearing the C bit) > >> can > >> > result in undetected corruption. Note that in this case > the 16 bits of > >> > checksum will be interpreted as something else. Is that > a concern? > >> > >>Good point. We can fix this by eliminating the C bit and > always including > >>the checksum. > >> > >> > > >> > 6.2 TBRPF Packet Body > >> > > >> > This use of TLVs is somewhat strange. Normally the L > field is always > >> > present immediately after the T field and hence a new > (and not recognized) > >> > type can be introduced, such that it is simply parsed > over and ignored. > >> > This cannot be done with the proposed structure. IPv6 > option TLVs DO have > >> > the normal property. It is probably confusing to call the TBRPF > >> messages TLVs > >> > >>Good point. We will remove the reference to TLV. I think > this was left > >>over from a previous version of TBRPF that included the L field. > >>We omitted the L field in order to minimize overhead, which is an > >>important objective for MANETs. > >> > >> > The draft doesn't say what to do with non-recognized > type values. Drop the > >> > packet? > >> > >>Yes, we will add that no further messages in the packet are to be > >>processed when a non-recognized type is encountered. (Since messages > >>are processed in order, this still allows new types to be introduced > >>in future versions, as long as new message types are placed after > >>old message types in a given packet.) > >> > >> > > >> > 6.2.1 Padding Options > >> > > >> > Senders MAY > >> > >>OK. > >> > >> > Is the use of the F bit to insert a one octet pad > redundant because of > >> the > >> > existence of the Pad1 option? Or are the two intended to > serve different > >> > purposes. (the former inserts padding prior to the > length and router ID > >> > header extensions). It seems odd to have TWO mechanisms > to achieve the > >> same > >> > ends. > >> > >>You are correct that the two mechanisms are intended to > serve different > >>purposes, since the Pad1 option cannot be used to separate the first > >>octet of the header from any header extensions that follow. > >> > >> > > >> > 7.8 Configurable parameters. > >> > > >> > MAX_JITTER Jitter is usually expressed as a percentage, > not an absolute > >> > value, and value of 25% is typical. Is there a > particular reason for > >> > specifying it this way? > >> > >>I have seen it both ways. Is there a good technical reason > for using > >>percentage instead of an absolute value? > >>Can you give me a well-known reference that uses percentage? > >> > >>It seems to me that the amount of jitter required to avoid > collisions is > >>best expressed as an absolute value (e.g., 0.1 sec), which > does not depend > >>on the HELLO interval. > >> > >>One reason for not expressing it as a percentage is that this might > >>unintentionally imply that it is OK, for example, to reduce > the HELLO > >>interval from 1 sec to .1 sec while keeping the jitter at 10%. > >>(10% would be OK for 1 sec but is probably too small for .1 sec.) > >> > >>Also, a larger jitter increases overhead (since it is > subtracted and > >>therefore > >>results in more frequent messages) so we want to keep it at > a minimum. > >>For example, we would not want to use .25 sec if .1 sec is > sufficient. > >> > >> > > >> > 10.6 Support for nonMANET Hosts > >> > > >> > Should there be a section about how a TBRPF domain > interfaces with the > >> > internet at large? Are there any special considerations? > Or is everything > >> > which needs to be covered dealt with in section 10.5? > >> > >>Note that Network Prefix messages are described in in > detail Section 8. > >>(Section 10.5 discusses how these messages might be used in MANETs.) > >> > >>We believe that anything beyond this is beyond the scope of > the document > >>(e.g., how to obtain a global address from a gateway or the > use of mobile > >>IP). > >>We do note in Section 8.1 that gateway routers can > advertise default > >>prefixes. > >>If you think it would help, we could explain more clearly > (in a few sentences) > >>that gateway routers can be used to provide Internet > connectivity and that > >>they can use Network Prefix messages to advertise external > prefixes to the > >>MANET nodes. > >> > >> > > >> > That's all I have. I haven't reviewed the protocol > specification for > >> > correctness. I assume the authors and WG have already > done that:-) > >> > > >> > >>----------------------- > >>Richard Ogier > >>Sr. Research Engineer > >>SRI International > >>333 Ravenswood Ave. > >>Menlo Park, CA 94025 > >>Tel: 650-859-4216 > >>Fax: 650-859-4812 > >>Email: ogier@erg.sri.com > >>------------------------ > From rtg-dir-admin@ietf.org Tue May 20 12:41:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20752 for ; Tue, 20 May 2003 12:41:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IAAT-0006jq-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 12:40:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IAAT-0006jl-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 12:40:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KG91B15014; Tue, 20 May 2003 12:09:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KG2oB13506 for ; Tue, 20 May 2003 12:02: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 MAA20517 for ; Tue, 20 May 2003 12:35:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IA4S-0006fw-00 for rtg-dir@ietf.org; Tue, 20 May 2003 12:34:36 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19IA4S-0006fF-00 for rtg-dir@ietf.org; Tue, 20 May 2003 12:34:36 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h4KGZ7u19549; Tue, 20 May 2003 09:35:07 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200305201635.h4KGZ7u19549@merlot.juniper.net> To: Russ White cc: idr@merit.edu, rtg-dir@ietf.org Subject: Re: Comments on BGP Draft 20..... In-Reply-To: Your message of "Fri, 09 May 2003 10:13:14 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26545.1053448507.1@juniper.net> Date: Tue, 20 May 2003 09:35:07 -0700 From: Yakov Rekhter Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Russ, > > Some of these are going to echo Alex's comments, but that's okay, I think. > Mostly just nits.... > > :-) Thanks for the comments. My response is in-line... > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > ----- > > Abstract: > > This information is sufficeint to construct a graph of the AS connectivity > from which routing loops may be pruned and some policy decisions at the AS > level may be enforced. > > UPDATE Message Format: > > The information in the UPDATE message can be used to construct a graph > describing the relationships of the various Autonomous Systems. > > In both cases this is true, I suppose, but in neither case does this really > describe what the AS Path is used for, right? Wrong. As the abstract states quite clearly that this information is used to prune routing loops and make some policy decisions at the AS level. > I would think we'd want to > describe it less in terms of a "graph of the connectivity in the > internetwork," and more in terms of "a graph of the path through Autonomous > Systems ued to reach the destination advertised." It could be confusing, > since there isn't anyplace where we discuss building a graph of > inconnectivity between the Autonomous Systems.... > > ----- > > Forwarding Paradigm: > > This document uses the term "Autonomous System" (AS) throughout.... > > This entire paragraph is a repeat--I'd leave it just in the definitions. The definition section suppose to have a *summary* of the definitions used in the spec. > ----- > > Forwarding Paradigms: > > The initial data flow.... > > This paragraph has two different thoughts in it, one about incremental > updates, and the other about keeping data that you've received. It seems > like just putting a return after "as the routing tables change." The two are related, as the reason for keeing updates you've received is because the exchange of information is based on incremental updates. > ----- > > Forwarding Paradigms: > > The paragraph starting "KEEPALIVE messages" should, I think, be moved up > above the section on route exchange. I don't know why, it just seems less > like it's jumping all over the place that way. Disagree. > ----- > > 3.1 Routes: Advertisement and Storage > > It almost seems like the section about The initial data flow should maybe > be put entirely under this section someplace (?). > > The first paragraph in this section is really a definition of a route vs a > prefix, and should probably be in the definitions. see above. > The paragraph "Changing attribute of a route...." needs a "the," or > attribute needs an "s." Ok. > ----- > > 3.2 Routing Information Bases > > b) Loc-RIB.... > > I think it might be useful to state the contents of the Loc-RIB are > actually installed in the local routing table, and thus used for forwarding > packets on this router. I don't see anyplace this connection is made > explicit, it seems more like it's implicit throughout the doc. Please propose the text. > ----- > > Page 18, a) LOCAL_PREF > > "....to inform other peers...." should be "....to inform its other > peers...." Sure. > ----- > > Network Layer Reachability Information > > "This varibale length field contains a list of IP address prefixes." > > I think we can kill "address" here. Sure. > > a) Length > > "The Length field inidicates...." The sentence can start with > "Indicates..." I prefer to keep the current text. > > b) Prefix > > "The Prefix field indicates...." The sentence can start with > "Indicates...." Ditto. > > ----- > > Network Layer Reachability Information > > "An UPDATE message can list multiple routes to be withdrawn...." > > Actually, we don't withdraw routes, we withdraw prefixes, right? The next > paragraph shows this confusion, by talking about routes without attributes, > but routes are prefixes combined with attributes, so.... They aren't > routes, they're prefixes. You remove routes based on withdrawn prefixes, I > think. We withdraw routes. The way BGP withdraws routes is by advertising the NLRI field of these routes in the Withdrawn Routes field of the UPDATE message. And that is precisely what the text said: An UPDATE message can list multiple routes to be withdrawn from service. Each such route is identified by its destination (expressed as an IP prefix), which unambiguously identifies the route in the context of the BGP speaker - BGP speaker connection to which it has been previously advertised. > > ------ > > 5. Path Attributes > > "Well-known attributes MUST be recognized by all BGP implementations." > > This sentence, as strange as it may sound, implies it's the attributes > fault if the BGP implementation doesn't recogonize it, that it's up to the > attribute definers to, in some way, make certain that BGP implementations > will recognize it. I think it should probably be worded the other way > 'round: > > "BGP implementations MUST recognize all well-known attributes." Sure. > ----- > > 5. Path Attributes > > "All well-known attributes MUST be passed along (after proper updating, if > necessary) to other BGP peers." > > This just seems a little rough. Maybe this: > > "Once a BGP peer has updated any well-known attributes, it MUST pass these > attributes in any updates it transmits to its peers." Sure. > > ----- > > 5.1.1 ORIGIN > > "Its value SHOULD NOT be changed by any other speaker." > > I really think this should be "MUST NOT." I can't think of any reason it > wouldn't be, except in the case of aggregation, and that case could be > mentioned here as the only known exception (?). Please propose the text. Yakov. From rtg-dir-admin@ietf.org Tue May 20 13:46:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22733 for ; Tue, 20 May 2003 13:46:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBAN-0007Bx-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 13:44:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IBAN-0007Bt-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 13:44:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHD0B19595; Tue, 20 May 2003 13:13:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHBiB19456 for ; Tue, 20 May 2003 13:11: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 NAA22647 for ; Tue, 20 May 2003 13:44:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IB97-0007B6-00 for rtg-dir@ietf.org; Tue, 20 May 2003 13:43:29 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19IB96-0007B2-00 for rtg-dir@ietf.org; Tue, 20 May 2003 13:43:28 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4KHiGJh027888; Tue, 20 May 2003 13:44:17 -0400 (EDT) Received: from dhcp-64-102-60-183.cisco.com (dhcp-64-102-60-183.cisco.com [64.102.60.183]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA17560; Tue, 20 May 2003 13:44:16 -0400 (EDT) Date: Tue, 20 May 2003 13:44:16 -0400 (EDT) From: Russ White Reply-To: Russ White To: Yakov Rekhter cc: idr@merit.edu, rtg-dir@ietf.org Subject: Re: Comments on BGP Draft 20..... In-Reply-To: <200305201635.h4KGZ7u19549@merlot.juniper.net> Message-ID: References: <200305201635.h4KGZ7u19549@merlot.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > > This information is sufficeint to construct a graph of the AS connectivity > > from which routing loops may be pruned and some policy decisions at the AS > > level may be enforced. > > > > UPDATE Message Format: > > > > The information in the UPDATE message can be used to construct a graph > > describing the relationships of the various Autonomous Systems. > > > > In both cases this is true, I suppose, but in neither case does this really > > describe what the AS Path is used for, right? > > Wrong. As the abstract states quite clearly that this information is used > to prune routing loops and make some policy decisions at the AS level. Yes, but it's not used for inscribing a graph of interconnectivity between the AS' in the internetwork, is it? It can be used for that, I suppose, so the text is fine, but it's not used for that--I think that's what's confusing about it. > > 3.2 Routing Information Bases > > > > b) Loc-RIB.... > > > > I think it might be useful to state the contents of the Loc-RIB are > > actually installed in the local routing table, and thus used for forwarding > > packets on this router. I don't see anyplace this connection is made > > explicit, it seems more like it's implicit throughout the doc. > > Please propose the text. Okay: The Loc-RIB contains routes which are installed in the local routing table and used for forwarding packets received, based on the destination address, by the router. > > Network Layer Reachability Information > > > > "An UPDATE message can list multiple routes to be withdrawn...." > > > > Actually, we don't withdraw routes, we withdraw prefixes, right? The next > > paragraph shows this confusion, by talking about routes without attributes, > > but routes are prefixes combined with attributes, so.... They aren't > > routes, they're prefixes. You remove routes based on withdrawn prefixes, I > > think. > > We withdraw routes. The way BGP withdraws routes is by advertising > the NLRI field of these routes in the Withdrawn Routes field of > the UPDATE message. And that is precisely what the text said: > > An UPDATE message can list multiple routes to be withdrawn from service. > Each such route is identified by its destination (expressed as an IP > prefix), which unambiguously identifies the route in the context of the > BGP speaker - BGP speaker connection to which it has been previously > advertised. Hmmm... So, if you receive an update with no attributes, just prefixes in the withdrawn section, you won't consider that a withdraw, and remove the routes you have from the sending peer from the local tables? A route without the attributes is a prefix. :-) It depends on whether you are thinking of it in terms of what you're sending, or what you're causing on the receiver. > > 5.1.1 ORIGIN > > > > "Its value SHOULD NOT be changed by any other speaker." > > > > I really think this should be "MUST NOT." I can't think of any reason it > > wouldn't be, except in the case of aggregation, and that case could be > > mentioned here as the only known exception (?). > > Please propose the text. It's value MUST NOT be changed by any other speaker. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From rtg-dir-admin@ietf.org Tue May 20 14:06:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23370 for ; Tue, 20 May 2003 14:06:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBTi-0007Kv-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 14:04:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IBTi-0007Ks-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 14:04:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHX1B20687; Tue, 20 May 2003 13:33:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHX0B20669 for ; Tue, 20 May 2003 13:33: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 OAA23367 for ; Tue, 20 May 2003 14:06:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBTh-0007Kp-00 for rtg-dir@ietf.org; Tue, 20 May 2003 14:04:45 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19IBTg-0007Ka-00 for rtg-dir@ietf.org; Tue, 20 May 2003 14:04:44 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h4KI5NB6025817; Tue, 20 May 2003 14:05:23 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h4KI5HWB025810; Tue, 20 May 2003 14:05:19 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h4KI5Cl17752; Tue, 20 May 2003 14:05:12 -0400 (EDT) Date: Tue, 20 May 2003 14:05:12 -0400 From: Jeffrey Haas To: Russ White Cc: Yakov Rekhter , idr@merit.edu, rtg-dir@ietf.org Subject: Re: Comments on BGP Draft 20..... Message-ID: <20030520140512.D16646@nexthop.com> References: <200305201635.h4KGZ7u19549@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ruwhite@cisco.com on Tue, May 20, 2003 at 01:44:16PM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Tue, May 20, 2003 at 01:44:16PM -0400, Russ White wrote: > Yes, but it's not used for inscribing a graph of interconnectivity between > the AS' in the internetwork, is it? It can be used for that, I suppose, so > the text is fine, but it's not used for that--I think that's what's > confusing about it. Perhaps to elaborate on Russ's point, the AS Path gives us the graph for this prefix. Even with a collection of a bunch of routes, we're not guaranteed to have the Internet's AS graph. The text is a *little* vague in this context, but I can't think of better wording. -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Tue May 20 14:09:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23512 for ; Tue, 20 May 2003 14:09:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBWd-0007MP-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 14:07:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IBWc-0007MM-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 14:07:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHa1B20895; Tue, 20 May 2003 13:36:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHZmB20876 for ; Tue, 20 May 2003 13:35: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 OAA23508 for ; Tue, 20 May 2003 14:08:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBWP-0007MH-00 for rtg-dir@ietf.org; Tue, 20 May 2003 14:07:33 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19IBWP-0007MB-00 for rtg-dir@ietf.org; Tue, 20 May 2003 14:07:33 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4KI8LkL002486; Tue, 20 May 2003 14:08:21 -0400 (EDT) Received: from dhcp-64-102-60-183.cisco.com (dhcp-64-102-60-183.cisco.com [64.102.60.183]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA19469; Tue, 20 May 2003 14:08:19 -0400 (EDT) Date: Tue, 20 May 2003 14:08:18 -0400 (EDT) From: Russ White Reply-To: Russ White To: Jeffrey Haas cc: Yakov Rekhter , idr@merit.edu, rtg-dir@ietf.org Subject: Re: Comments on BGP Draft 20..... In-Reply-To: <20030520140512.D16646@nexthop.com> Message-ID: References: <200305201635.h4KGZ7u19549@merlot.juniper.net> <20030520140512.D16646@nexthop.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > > Yes, but it's not used for inscribing a graph of interconnectivity between > > the AS' in the internetwork, is it? It can be used for that, I suppose, so > > the text is fine, but it's not used for that--I think that's what's > > confusing about it. > > Perhaps to elaborate on Russ's point, the AS Path gives us the > graph for this prefix. Even with a collection of a bunch of routes, > we're not guaranteed to have the Internet's AS graph. > > The text is a *little* vague in this context, but I can't think > of better wording. I agree--I've been trying to come up with a better wayh of working it, but I can't think of one. I'd say it's too much of a nit to worry about it . :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From rtg-dir-admin@ietf.org Tue May 20 14:14:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23674 for ; Tue, 20 May 2003 14:14:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBbS-0007Om-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 14:12:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IBbR-0007Oi-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 14:12:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHf0B21998; Tue, 20 May 2003 13:41:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHcBB21858 for ; Tue, 20 May 2003 13:38: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 OAA23597 for ; Tue, 20 May 2003 14:11:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBYi-0007NL-00 for rtg-dir@ietf.org; Tue, 20 May 2003 14:09:56 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19IBYh-0007Mx-00 for rtg-dir@ietf.org; Tue, 20 May 2003 14:09:55 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h4KIAbu27841; Tue, 20 May 2003 11:10:37 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200305201810.h4KIAbu27841@merlot.juniper.net> To: Russ White cc: idr@merit.edu, rtg-dir@ietf.org Subject: Re: Comments on BGP Draft 20..... In-Reply-To: Your message of "Tue, 20 May 2003 13:44:16 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <68386.1053454237.1@juniper.net> Date: Tue, 20 May 2003 11:10:37 -0700 From: Yakov Rekhter Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Russ, > > > This information is sufficeint to construct a graph of the AS connectivity > > > from which routing loops may be pruned and some policy decisions at the AS > > > level may be enforced. > > > > > > UPDATE Message Format: > > > > > > The information in the UPDATE message can be used to construct a graph > > > describing the relationships of the various Autonomous Systems. > > > > > > In both cases this is true, I suppose, but in neither case does this > > > really describe what the AS Path is used for, right? > > > > Wrong. As the abstract states quite clearly that this information is used > > to prune routing loops and make some policy decisions at the AS level. > > Yes, but it's not used for inscribing a graph of interconnectivity between > the AS' in the internetwork, is it? It can be used for that, I suppose, so > the text is fine, but it's not used for that--I think that's what's > confusing about it. > > > > 3.2 Routing Information Bases > > > > > > b) Loc-RIB.... > > > > > > I think it might be useful to state the contents of the Loc-RIB are > > > actually installed in the local routing table, and thus used for forwardi ng > > > packets on this router. I don't see anyplace this connection is made > > > explicit, it seems more like it's implicit throughout the doc. > > > > Please propose the text. > > Okay: > > The Loc-RIB contains routes which are installed in the local routing table > and used for forwarding packets received, based on the destination address, > by the router. In the absence of any objections within a week I'll put this in the text. > > > Network Layer Reachability Information > > > > > > "An UPDATE message can list multiple routes to be withdrawn...." > > > > > > Actually, we don't withdraw routes, we withdraw prefixes, right? The next > > > paragraph shows this confusion, by talking about routes without attribute s, > > > but routes are prefixes combined with attributes, so.... They aren't > > > routes, they're prefixes. You remove routes based on withdrawn prefixes, I > > > think. > > > > We withdraw routes. The way BGP withdraws routes is by advertising > > the NLRI field of these routes in the Withdrawn Routes field of > > the UPDATE message. And that is precisely what the text said: > > > > An UPDATE message can list multiple routes to be withdrawn from service. > > Each such route is identified by its destination (expressed as an IP > > prefix), which unambiguously identifies the route in the context of the > > BGP speaker - BGP speaker connection to which it has been previously > > advertised. > > Hmmm... So, if you receive an update with no attributes, just prefixes in > the withdrawn section, you won't consider that a withdraw, and remove the > routes you have from the sending peer from the local tables? > > A route without the attributes is a prefix. :-) > > It depends on whether you are thinking of it in terms of what you're > sending, or what you're causing on the receiver. > > > > 5.1.1 ORIGIN > > > > > > "Its value SHOULD NOT be changed by any other speaker." > > > > > > I really think this should be "MUST NOT." I can't think of any reason it > > > wouldn't be, except in the case of aggregation, and that case could be > > > mentioned here as the only known exception (?). > > > > Please propose the text. > > It's value MUST NOT be changed by any other speaker. In the absence of any objections within a week I'll put this in the text. Yakov. From rtg-dir-admin@ietf.org Tue May 20 14:30:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24311 for ; Tue, 20 May 2003 14:30:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBqx-0007XT-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 14:28:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IBqw-0007XP-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 14:28:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHv1B22849; Tue, 20 May 2003 13:57:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHuDB22801 for ; Tue, 20 May 2003 13:56: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 OAA24234 for ; Tue, 20 May 2003 14:29:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBq9-0007WE-00 for rtg-dir@ietf.org; Tue, 20 May 2003 14:27:57 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19IBq8-0007W6-00 for rtg-dir@ietf.org; Tue, 20 May 2003 14:27:57 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h4KISbge028126; Tue, 20 May 2003 14:28:37 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h4KISX8o028114; Tue, 20 May 2003 14:28:33 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h4KISSp17972; Tue, 20 May 2003 14:28:28 -0400 (EDT) Date: Tue, 20 May 2003 14:28:28 -0400 From: Jeffrey Haas To: Yakov Rekhter Cc: Russ White , idr@merit.edu, rtg-dir@ietf.org Subject: Re: Comments on BGP Draft 20..... Message-ID: <20030520142828.E16646@nexthop.com> References: <200305201810.h4KIAbu27841@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200305201810.h4KIAbu27841@merlot.juniper.net>; from yakov@juniper.net on Tue, May 20, 2003 at 11:10:37AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Tue, May 20, 2003 at 11:10:37AM -0700, Yakov Rekhter wrote: > > Okay: > > > > The Loc-RIB contains routes which are installed in the local routing table > > and used for forwarding packets received, based on the destination address, > > by the router. > > In the absence of any objections within a week I'll put this in the text. Except: : Whether or not the new BGP route replaces an existing : non-BGP route in the Routing Table depends on the policy configured : on the BGP speaker. I think the existing text is fine. The gotcha is one has to read ahead a bit in the document to find the bit I just quoted. > > It's value MUST NOT be changed by any other speaker. > > > In the absence of any objections within a week I'll put this in the text. Good grief. I refer all parties concerned back to the thread titled "Re: issue 32.1", specifically the consensus mail from Andrew with message-id: <20020927115144.F13901@demiurge.exodus.net Short summary: 1. You shouldn't change it. 2. People *do* change it, and do so for policy reasons. 3. You shouldn't change it, but since people do, we're going to tell you that you shouldn't and thus imply that you can if you really want to. :-) My own preference was to *not* change it and MUST would be fine with me, but consensus was previously reached. > Yakov. -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Tue May 20 14:57:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25079 for ; Tue, 20 May 2003 14:57:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ICH5-0007g1-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 14:55:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ICH4-0007fx-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 14:55:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KIO2B24802; Tue, 20 May 2003 14:24:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KINaB24767 for ; Tue, 20 May 2003 14:23: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 OAA25034 for ; Tue, 20 May 2003 14:56:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ICGd-0007fc-00 for rtg-dir@ietf.org; Tue, 20 May 2003 14:55:20 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19ICGd-0007fE-00 for rtg-dir@ietf.org; Tue, 20 May 2003 14:55:19 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h4KIu8Q3028978; Tue, 20 May 2003 14:56:08 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h4KIu28o028964; Tue, 20 May 2003 14:56:02 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h4KItv618075; Tue, 20 May 2003 14:55:57 -0400 (EDT) Date: Tue, 20 May 2003 14:55:57 -0400 From: Jeffrey Haas To: idr@merit.edu Cc: rtg-dir@ietf.org Subject: [ruwhite@cisco.com: Re: Comments on BGP Draft 20.....] Message-ID: <20030520145557.G16646@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Yakov, ----- Forwarded message from Russ White ----- Date: Tue, 20 May 2003 14:33:38 -0400 (EDT) From: Russ White To: Jeffrey Haas Subject: Re: Comments on BGP Draft 20..... Reply-To: Russ White X-Virus-Scanned: by AMaViS perl-11 X-OriginalArrivalTime: 20 May 2003 18:33:51.0941 (UTC) FILETIME=[5C876750:01C31EFE] Yeah, this sounds better.... :-) Russ On Tue, 20 May 2003, Jeffrey Haas wrote: > [off-list] > > Howzabout: > The primary function of a BGP speaking system is to exchange network > reachability information with other BGP systems. This network reacha- > bility information includes information on the list of Autonomous > Systems (ASs) that reachability information traverses. This informa- > tion is sufficient to construct a graph of AS connectivity > + for this reachability > from which > routing loops may be pruned and some policy decisions at the AS level > may be enforced. > > -- > Jeff Haas > NextHop Technologies > __________________________________ riw@cisco.com CCIE <>< Grace Alone ----- End forwarded message ----- -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Tue May 20 17:55:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01634 for ; Tue, 20 May 2003 17:55:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IF3H-00010g-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 17:53:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IF3H-00010d-00 for rtg-dir-archive@ietf.org; Tue, 20 May 2003 17:53:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KLM1B05263; Tue, 20 May 2003 17:22:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KLKXB05204 for ; Tue, 20 May 2003 17:20: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 RAA01622 for ; Tue, 20 May 2003 17:53:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IF1p-00010U-00 for rtg-dir@ietf.org; Tue, 20 May 2003 17:52:13 -0400 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 19IF1p-00010R-00 for rtg-dir@ietf.org; Tue, 20 May 2003 17:52:13 -0400 Received: from user-2ivfk4l.dialup.mindspring.com ([165.247.208.149] helo=earthlink.net) by mallard.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19IF31-0001Es-00; Tue, 20 May 2003 14:53:28 -0700 Message-ID: <3ECAA418.CA3A7FE2@earthlink.net> Date: Tue, 20 May 2003 14:54:32 -0700 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: Russ White , idr@merit.edu, rtg-dir@ietf.org Subject: Re: Comments on BGP Draft 20..... References: <200305201635.h4KGZ7u19549@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is a re-send. Just want to make sure that it was seen.. Subject: A Border Gateway Protocol-4 Draft : comment / suggestion: AS_PATH Date: Wed, 14 May 2003 17:35:38 -0700 From: Erblichs To: idr@merit.edu References: 1 Authors, Should section for AS_PATH 5.1.2 include at the end of the section something like: The insertion of two or more AS's within the AS_PATH may decrease the detection of routing loops in favor of a optimal routing path. Mitchell Erblich Sr Software Engineer =========================== ============================ Yakov Rekhter wrote: > > Russ, > > > > > Some of these are going to echo Alex's comments, but that's okay, I think. > > Mostly just nits.... > > > > :-) > > Thanks for the comments. My response is in-line... > > > > > Russ > > > > __________________________________ > > riw@cisco.com CCIE <>< Grace Alone > > > > ----- > > > > Abstract: > > > > This information is sufficeint to construct a graph of the AS connectivity > > from which routing loops may be pruned and some policy decisions at the AS > > level may be enforced. > > > > UPDATE Message Format: > > > > The information in the UPDATE message can be used to construct a graph > > describing the relationships of the various Autonomous Systems. > > > > In both cases this is true, I suppose, but in neither case does this really > > describe what the AS Path is used for, right? > > Wrong. As the abstract states quite clearly that this information is used > to prune routing loops and make some policy decisions at the AS level. > > > I would think we'd want to > > describe it less in terms of a "graph of the connectivity in the > > internetwork," and more in terms of "a graph of the path through Autonomous > > Systems ued to reach the destination advertised." It could be confusing, > > since there isn't anyplace where we discuss building a graph of > > inconnectivity between the Autonomous Systems.... > > > > ----- > > > > Forwarding Paradigm: > > > > This document uses the term "Autonomous System" (AS) throughout.... > > > > This entire paragraph is a repeat--I'd leave it just in the definitions. > > The definition section suppose to have a *summary* of the definitions > used in the spec. > > > ----- > > > > Forwarding Paradigms: > > > > The initial data flow.... > > > > This paragraph has two different thoughts in it, one about incremental > > updates, and the other about keeping data that you've received. It seems > > like just putting a return after "as the routing tables change." > > The two are related, as the reason for keeing updates you've received > is because the exchange of information is based on incremental updates. > > > ----- > > > > Forwarding Paradigms: > > > > The paragraph starting "KEEPALIVE messages" should, I think, be moved up > > above the section on route exchange. I don't know why, it just seems less > > like it's jumping all over the place that way. > > Disagree. > > > ----- > > > > 3.1 Routes: Advertisement and Storage > > > > It almost seems like the section about The initial data flow should maybe > > be put entirely under this section someplace (?). > > > > The first paragraph in this section is really a definition of a route vs a > > prefix, and should probably be in the definitions. > > see above. > > > The paragraph "Changing attribute of a route...." needs a "the," or > > attribute needs an "s." > > Ok. > > > ----- > > > > 3.2 Routing Information Bases > > > > b) Loc-RIB.... > > > > I think it might be useful to state the contents of the Loc-RIB are > > actually installed in the local routing table, and thus used for forwarding > > packets on this router. I don't see anyplace this connection is made > > explicit, it seems more like it's implicit throughout the doc. > > Please propose the text. > > > ----- > > > > Page 18, a) LOCAL_PREF > > > > "....to inform other peers...." should be "....to inform its other > > peers...." > > Sure. > > > ----- > > > > Network Layer Reachability Information > > > > "This varibale length field contains a list of IP address prefixes." > > > > I think we can kill "address" here. > > Sure. > > > > > a) Length > > > > "The Length field inidicates...." The sentence can start with > > "Indicates..." > > I prefer to keep the current text. > > > > > b) Prefix > > > > "The Prefix field indicates...." The sentence can start with > > "Indicates...." > > Ditto. > > > > > ----- > > > > Network Layer Reachability Information > > > > "An UPDATE message can list multiple routes to be withdrawn...." > > > > Actually, we don't withdraw routes, we withdraw prefixes, right? The next > > paragraph shows this confusion, by talking about routes without attributes, > > but routes are prefixes combined with attributes, so.... They aren't > > routes, they're prefixes. You remove routes based on withdrawn prefixes, I > > think. > > We withdraw routes. The way BGP withdraws routes is by advertising > the NLRI field of these routes in the Withdrawn Routes field of > the UPDATE message. And that is precisely what the text said: > > An UPDATE message can list multiple routes to be withdrawn from service. > Each such route is identified by its destination (expressed as an IP > prefix), which unambiguously identifies the route in the context of the > BGP speaker - BGP speaker connection to which it has been previously > advertised. > > > > > ------ > > > > 5. Path Attributes > > > > "Well-known attributes MUST be recognized by all BGP implementations." > > > > This sentence, as strange as it may sound, implies it's the attributes > > fault if the BGP implementation doesn't recogonize it, that it's up to the > > attribute definers to, in some way, make certain that BGP implementations > > will recognize it. I think it should probably be worded the other way > > 'round: > > > > "BGP implementations MUST recognize all well-known attributes." > > Sure. > > > ----- > > > > 5. Path Attributes > > > > "All well-known attributes MUST be passed along (after proper updating, if > > necessary) to other BGP peers." > > > > This just seems a little rough. Maybe this: > > > > "Once a BGP peer has updated any well-known attributes, it MUST pass these > > attributes in any updates it transmits to its peers." > > Sure. > > > > > ----- > > > > 5.1.1 ORIGIN > > > > "Its value SHOULD NOT be changed by any other speaker." > > > > I really think this should be "MUST NOT." I can't think of any reason it > > wouldn't be, except in the case of aggregation, and that case could be > > mentioned here as the only known exception (?). > > Please propose the text. > > Yakov. From rtg-dir-admin@ietf.org Fri May 23 13:20:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14732 for ; Fri, 23 May 2003 13:20:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JGCK-0007Kp-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 13:19:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JGCJ-0007I1-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 13:19:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NHKKB04956; Fri, 23 May 2003 13:20:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4N1OLB26143 for ; Thu, 22 May 2003 21:24: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 VAA08266 for ; Thu, 22 May 2003 21:56:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19J1lo-0007XO-00 for rtg-dir@ietf.org; Thu, 22 May 2003 21:54:56 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19J1ln-0007XK-00 for rtg-dir@ietf.org; Thu, 22 May 2003 21:54:55 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19J1n9-000B6x-00 for rtg-dir@ietf.org; Fri, 23 May 2003 01:56:19 +0000 Date: Thu, 22 May 2003 18:56:06 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <93972307354.20030522185606@psg.com> To: rtg-dir@ietf.org Subject: Meta: routing protocol abuse MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- /* * The topic is quite sensitive, so handle with care please. I know some * of you may have a conflict of interest given what your companies do, * so I'd like to explicitly ask you to take your vendor hat off and put * your IETF rtg-dir member hat on when you participate in this * discussion (no offense). */ The discussion about appropriate and inappropriate applications of IP routing protocols has been going on for quite a while. The most noticeable outburst of it could be correlated with appearance of 2547 ;), however, this is not what I'd like us to talk about now. I'd like to draw your attention to the following draft-- draft-kompella-ppvpn-vpls-01.txt --which proposes to use BGP for VPLS (L2 VPN service) discovery and signaling. In particular, please pay attention to the way the semantics of the NLRI field have been changed (section 3.2.1), and to the fact the best path selection algorithm is not employed at all. These two facts--loss of any addressing semantics, and loss of best path selection--make me think that the proposed approach essentially transforms BGP into what I call a "universal transport system." There two questions here: 1. Where is the line between appropriate and inappropriate use of routing protocols in general, and BGP in particular (there maybe different aspects between LS IGPs that have a pure transport/flooding component, and BGP whose info relaying behavior is tightly coupled with the best path selection algo.) 2. Does the draft in question cross this line? Before this sort of discussion starts in public, I'd like to hear opinions (preferably with technical and architectural arguments) of the folk whose technical judgement I trust. Thanks. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Fri May 23 13:54:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17101 for ; Fri, 23 May 2003 13:54:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JGij-0000Nk-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 13:52:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JGii-0000Nf-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 13:52:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NHsEB13770; Fri, 23 May 2003 13:54:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NHoWB12468 for ; Fri, 23 May 2003 13:50: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 NAA16876 for ; Fri, 23 May 2003 13:50:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JGf8-0000GI-00 for rtg-dir@ietf.org; Fri, 23 May 2003 13:49:02 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19JGf7-0000GB-00 for rtg-dir@ietf.org; Fri, 23 May 2003 13:49:01 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id A38793CB187; Fri, 23 May 2003 10:50:25 -0700 (PDT) Message-ID: <3ECE5F3A.4000601@redback.com> Date: Fri, 23 May 2003 13:49:46 -0400 From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Acee Lindem Cc: Christian Martin , Stefano Previdi , Brad Neal , Routing Area Directorate Subject: Re: Comments on References: <3E73E362.3010802@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christian, Stefano, Brad, The follow-up discussion on the necessity for both 32 bit and 64 bit tags raises the question as to whether or not it is wise to allow an arbitrary number of tags to be advertised. This draft proposes 2 new "Administrative Tag" sub-TLVs to be added to TLV 135 and 235. These TLVs specify one or more ordered, 32 or 64 ~~~~~~~~~~~~~~~ bit unsigned integers that may be associated with an IP prefix. However, the receiver need only use the first. An implementation may consider only one of the encoded tags, in which case the first encoded tag must be considered. A tag value of zero is reserved and should be treated as "no tag". IMHO, allowing an arbitrary number of tags affords more potential for interoperability and deviant applications than the 64 bit tag. Acee Lindem wrote: > As a member of the routing area directorate, I have reviewed the > subject document. Here are my comments: > > Comments: > > 1. The last sentence of the abstract doesn't make sense. "Additionally, > the information can be placed in LSPs that have TLVs as yet > undefined, if this information is used to convey the same > meaning in these future TLVs as it used in the currently defined > TLVs". Suggested - "The administrative tag sub-TLVs may be used with > with future TLVs as long as their semantics are preserved." > > 2. Section 5.2 - The value of the type is wrong - it should be 2 rather > than 1. > > 3. Section 6 says the ordering of tags is not significant. However, the > previous sections (5.1 and 5.2) say that an implementation may only > consider the first tag. > > 4. Section 7 - List the requirements for receiving the new Sub-TLVs in > this compliance section as well (even if they were stated previously). > > 5. Section 8 - The example talks about R2 associating tag 110 with > property > A and prefix 1.1.1.0/24. Yet in Figure 1, prefix 1.1.1.0/24 with > property > A is adjacent to R1 (which applies to me that R1 originate the > prefix). > Please fix either the example or the figure. > > Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): > > 1. The abstract contains references. The documents should be specified > by name since the abstract can be excerpted. > > 2. Line 323 over 72 chars. > > Line 323 length is 74 > Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April > > 3. Pages 2, 3, 4, and 5 have over 58 lines. > -- Acee From rtg-dir-admin@ietf.org Fri May 23 14:18:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18576 for ; Fri, 23 May 2003 14:18:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JH6k-0000sm-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 14:17:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JH6j-0000sj-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 14:17:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NIJ0B17813; Fri, 23 May 2003 14:19:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NIIDB17755 for ; Fri, 23 May 2003 14:18: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 OAA18530 for ; Fri, 23 May 2003 14:18:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JH5y-0000sJ-00 for rtg-dir@ietf.org; Fri, 23 May 2003 14:16:46 -0400 Received: from net4u.net4u.ch ([194.191.0.1] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19JH5x-0000sG-00 for rtg-dir@ietf.org; Fri, 23 May 2003 14:16:45 -0400 Received: from net4u.ch (zux006-029-237.adsl.green.ch [81.6.29.237]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h4NII8R28645; Fri, 23 May 2003 20:18:08 +0200 Message-ID: <3ECE65A7.6050004@net4u.ch> Date: Fri, 23 May 2003 20:17:11 +0200 From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse References: <93972307354.20030522185606@psg.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Let me give you an outlook of possible outcomes I see rather than an opinion. > > The discussion about appropriate and inappropriate applications of IP > routing protocols has been going on for quite a while. The most > noticeable outburst of it could be correlated with appearance of 2547 > ;), however, this is not what I'd like us to talk about now. > this one's lost for sure. > > I'd like to draw your attention to the following draft-- > draft-kompella-ppvpn-vpls-01.txt > > --which proposes to use BGP for VPLS (L2 VPN service) discovery and > signaling. In particular, please pay attention to the way the > semantics of the NLRI field have been changed (section 3.2.1), and to > the fact the best path selection algorithm is not employed at all. > These two facts--loss of any addressing semantics, and loss of best > path selection--make me think that the proposed approach essentially > transforms BGP into what I call a "universal transport system." > yes, many more such approaches are around in different stages (translation of E.164 fields in NLRIs and so on). > > There two questions here: > > 1. Where is the line between appropriate and inappropriate use > of routing protocols in general, and BGP in particular (there > maybe different aspects between LS IGPs that have a pure > transport/flooding component, and BGP whose info relaying > behavior is tightly coupled with the best path selection algo.) > There is no line IMHO, it's just a hues-of-grey-border, especially in IP. Strictly speaking, something like BGP is a routing protocol which means, it should answer the 'How do I get from A to B' question or even stricter, in ISO terms, it must involve relaying between layer-3 entities. That's the theoretical one and based on that, things like 2547 are a layer that needs its own protocol and things like L2 info have no business whatsoever in routing protocol data. The practical one is that vendors piggy-back lots of garb into routing protocols that have no business there since it's the fastest way to ship features that involve anything that needs reasonable amount of quickly but loosely synchronized data and there is piles such stuff. Moreover, building partitioned, loosely synchronized, distributed databases is hard like hell. So, Pedro's 'discussion' on idr was basically euphemistically gold-platting these very facts by some pseudo-philosophical contortions. HOWEVER, this is vendor-reality and a good local solution for the problem space they are faced with or rather maybe, created for themselves (insanely short development cycles, feature creep, disregard for any S [stability, scalability, security, ...] in the first release). The ethics of IP, namely 'running code' have been since long modified into 'quick-and-dirty running code' and is used as excuse for lack of a unifying architecture that underlies today's IP-networking realities and their variations. So, where am I going with this rant ? Well, vendor reality is that routing protocols are being force-fed anything they can bear and has the promise to generate revenue and this won't be changed anytime soon since engineering 'ethics' is gone since a while and IETF has no power whatever these days to stop anything major vendors are doing and deploying. In the short term, IETF can just hang on for the ride. How to change this situation is yes another topic and not one I want to touch here or rather at all. My advice as to the whole issue: IETF is a documenting and not a defining body since a while and directions you [or maybe whole IESG] are trying to push it into (tightening specifications to the point of over-specifying [and delaying documents ridiculously] and an retrofited-'architecture' which however is not laid down anywhere as I saw it) are not very promising IMHO and the vendor will happilly trot on. On a larger scale, two outcomes I envision possible: either IP is the combustion engine of networking and it will hang on for next 100 years despite being smelly, inefficient and ripe to be displaced by better solutions and we will preserve this status-quo OR the whole thing will flame out and end up overridden by something small and elegant that will come out of the dark. The 2nd outcome would be unlikely BUT for the fact that technology is almost weightless and the daemon of 6-months-product-cycles made displacement of existing solutions much easier than in the case of combustion-engine-driven toys. so, just food for thought -- tony From rtg-dir-admin@ietf.org Fri May 23 15:21:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21928 for ; Fri, 23 May 2003 15:21:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JI5i-0001Uu-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 15:20:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JI5i-0001Ur-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 15:20:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NJM1B23130; Fri, 23 May 2003 15:22:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NJLIB23088 for ; Fri, 23 May 2003 15:21: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 PAA21917; Fri, 23 May 2003 15:21:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JI4z-0001UT-00; Fri, 23 May 2003 15:19:49 -0400 Received: from entmail.gnilink.net ([199.45.47.10]) by ietf-mx with esmtp (Exim 4.12) id 19JI4z-0001UI-00; Fri, 23 May 2003 15:19:49 -0400 Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59) id ; Fri, 23 May 2003 15:20:45 -0400 Message-ID: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> From: "Martin, Christian" To: "'Acee Lindem'" Cc: "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: RE: Comments on Date: Fri, 23 May 2003 15:20:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32160.6687F8F0" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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. ------_=_NextPart_001_01C32160.6687F8F0 Content-Type: text/plain Acee, As the original goal was to create a capability similar to OSPF's route tag, it may be wise to drop this capability. On the otherhand, having multiple tags per route can provide more information about the route than a single tag. In this regard, the 32 bit tag operates more like a community, and the 64 bit tag operates like an extended community. From an implementation perspective, the same routines for matching and setting these fields should be similar to the community fields in BGP. I would like to solicit the WG for comments on which capability is most attractive. The goal is not to introduce too much bloat (is it too late for that?!) while still providing some flexibility. As soon as I receive any final comments, I will release the updated draft. Thanks for pointing out this critical piece! Regards, chris >-----Original Message----- >From: Acee Lindem [mailto:acee@redback.com] >Sent: Friday, May 23, 2003 1:50 PM >To: Acee Lindem >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area >Directorate >Subject: Re: Comments on > > >Christian, Stefano, Brad, > >The follow-up discussion on the necessity for both 32 bit and >64 bit tags raises the question as to whether or not it is >wise to allow an arbitrary number of tags to be advertised. > > This draft proposes 2 new "Administrative Tag" sub-TLVs >to be added > to TLV 135 and 235. These TLVs specify one or more >ordered, 32 or 64 > ~~~~~~~~~~~~~~~ > bit unsigned integers that may be associated with an IP prefix. > >However, the receiver need only use the first. > > An implementation may consider only one of the encoded >tags, in which > case the first encoded tag must be considered. A tag >value of zero > is reserved and should be treated as "no tag". > >IMHO, allowing an arbitrary number of tags affords more >potential for interoperability and deviant applications than >the 64 bit tag. > > > > > >Acee Lindem wrote: >> As a member of the routing area directorate, I have reviewed the >> subject document. Here are my comments: >> >> Comments: >> >> 1. The last sentence of the abstract doesn't make sense. >"Additionally, >> the information can be placed in LSPs that have TLVs as yet >> undefined, if this information is used to convey the same >> meaning in these future TLVs as it used in the currently defined >> TLVs". Suggested - "The administrative tag sub-TLVs may >be used with >> with future TLVs as long as their semantics are preserved." >> >> 2. Section 5.2 - The value of the type is wrong - it >should be 2 rather >> than 1. >> >> 3. Section 6 says the ordering of tags is not significant. >However, the >> previous sections (5.1 and 5.2) say that an >implementation may only >> consider the first tag. >> >> 4. Section 7 - List the requirements for receiving the new >Sub-TLVs in >> this compliance section as well (even if they were stated >> previously). >> >> 5. Section 8 - The example talks about R2 associating tag 110 with >> property >> A and prefix 1.1.1.0/24. Yet in Figure 1, prefix >1.1.1.0/24 with >> property >> A is adjacent to R1 (which applies to me that R1 originate the >> prefix). >> Please fix either the example or the figure. >> >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): >> >> 1. The abstract contains references. The documents should >be specified >> by name since the abstract can be excerpted. >> >> 2. Line 323 over 72 chars. >> >> Line 323 length is 74 >> Routing in IS-IS", >draft-ietf-isis-wg-multi-topology-03.txt, >> April >> >> 3. Pages 2, 3, 4, and 5 have over 58 lines. >> > > >-- >Acee > ------_=_NextPart_001_01C32160.6687F8F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments on = <draft-ietf-isis-admin-tages-01.txt>

Acee,

As the original goal was to create a capability = similar to OSPF's route tag, it may be wise to drop this = capability.  On the otherhand, having multiple tags per route can = provide more information about the route than a single tag.  In = this regard, the 32 bit tag operates more like a community, and the 64 = bit tag operates like an extended community.  From an = implementation perspective, the same routines for matching and setting = these fields should be similar to the community fields in = BGP.

I would like to solicit the WG for comments on which = capability is most attractive.  The goal is not to introduce too = much bloat (is it too late for that?!) while still providing some = flexibility.

As soon as I receive any final comments, I will = release the updated draft.

Thanks for pointing out this critical piece!

Regards,
chris

>-----Original Message-----
>From: Acee Lindem [mailto:acee@redback.com]
>Sent: Friday, May 23, 2003 1:50 PM
>To: Acee Lindem
>Cc: Christian Martin; Stefano Previdi; Brad = Neal; Routing Area
>Directorate
>Subject: Re: Comments on = <draft-ietf-isis-admin-tages-01.txt>
>
>
>Christian, Stefano, Brad,
>
>The follow-up discussion on the necessity for = both 32 bit and
>64 bit tags raises the question as to whether or = not it is
>wise to allow an arbitrary number of tags to be = advertised.
>
>       This draft = proposes 2 new "Administrative Tag" sub-TLVs
>to be added
>       to TLV 135 = and 235.  These TLVs specify one or more
>ordered, 32 or 64
>          = ;            = ;            = ;            = ;    ~~~~~~~~~~~~~~~
>       bit = unsigned integers that may be associated with an IP prefix.
>
>However, the receiver need only use the = first.
>
>       An = implementation may consider only one of the encoded
>tags, in which
>       case the = first encoded tag must be considered.  A tag
>value of zero
>       is reserved = and should be treated as "no tag".
>
>IMHO, allowing an arbitrary number of tags = affords more
>potential for interoperability and deviant = applications than
>the 64 bit tag.
>
>
>
>
>
>Acee Lindem wrote:
>> As a member of the routing area = directorate, I have reviewed the
>> subject document. Here are my = comments:
>>
>> Comments:
>>
>>   1. The last sentence of the = abstract doesn't make sense.
>"Additionally,
>>      the = information can be placed in LSPs that have TLVs as yet
>>      undefined, if = this information is used to convey the same
>>      meaning in = these future TLVs as it used in the currently defined
>>      TLVs". = Suggested - "The administrative tag sub-TLVs may
>be used with
>>      with future = TLVs as long as their semantics are preserved."
>>
>>   2. Section 5.2 - The value of = the type is wrong - it
>should be 2 rather
>>      than = 1.
>>
>>   3. Section 6 says the ordering = of tags is not significant.
>However, the
>>      previous = sections (5.1 and 5.2) say that an
>implementation may only
>>      consider the = first tag.
>>
>>   4. Section 7 - List the = requirements for receiving the new
>Sub-TLVs in
>>      this = compliance section as well (even if they were stated
>> previously).
>>
>>   5. Section 8 - The example = talks about R2 associating tag 110 with
>> property
>>      A and prefix = 1.1.1.0/24. Yet in Figure 1, prefix
>1.1.1.0/24 with
>> property
>>      A is adjacent = to R1 (which applies to me that R1 originate the
>> prefix).
>>      Please fix = either the example or the figure.
>>
>> Nit Comments (see = draft-rfc-editor-rfc2223bis-03.txt):
>>
>>   1. The abstract contains = references. The documents should
>be specified
>>      by name since = the abstract can be excerpted.
>>
>>   2. Line 323 over 72 = chars.
>>
>>     Line 323 length is = 74
>>          = Routing in IS-IS",
>draft-ietf-isis-wg-multi-topology-03.txt, =
>> April
>>
>>   3. Pages 2, 3, 4, and 5 have = over 58 lines.
>>
>
>
>--
>Acee
>

------_=_NextPart_001_01C32160.6687F8F0-- From rtg-dir-admin@ietf.org Fri May 23 15:44:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22561 for ; Fri, 23 May 2003 15:44:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JIRw-0001fb-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 15:43:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JIRw-0001fY-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 15:43:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NJj0B25193; Fri, 23 May 2003 15:45:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NJiYB25173 for ; Fri, 23 May 2003 15:44: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 PAA22551 for ; Fri, 23 May 2003 15:44:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JIRV-0001fO-00 for rtg-dir@ietf.org; Fri, 23 May 2003 15:43:05 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19JIRU-0001f2-00 for rtg-dir@ietf.org; Fri, 23 May 2003 15:43:04 -0400 Received: from there (ams-clip-vpn-dhcp167.cisco.com [10.61.64.167]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id h4NJhoR23425; Fri, 23 May 2003 21:43:50 +0200 (CEST) Message-Id: <200305231943.h4NJhoR23425@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: Acee Lindem Subject: Re: Comments on , Brad Neal , Routing Area Directorate References: <3E73E362.3010802@redback.com> <3ECE5F3A.4000601@redback.com> In-Reply-To: <3ECE5F3A.4000601@redback.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4NJiYB25174 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Friday 23 May 2003 19:49, Acee Lindem wrote: > Christian, Stefano, Brad, > > The follow-up discussion on the necessity for both 32 bit and > 64 bit tags raises the question as to whether or not it is wise > to allow an arbitrary number of tags to be advertised. > > This draft proposes 2 new "Administrative Tag" sub-TLVs to be added > to TLV 135 and 235. These TLVs specify one or more ordered, 32 or 64 > ~~~~~~~~~~~~~~~ > bit unsigned integers that may be associated with an IP prefix. > > However, the receiver need only use the first. > > An implementation may consider only one of the encoded tags, in which > case the first encoded tag must be considered. A tag value of zero > is reserved and should be treated as "no tag". > > IMHO, allowing an arbitrary number of tags affords more potential for > interoperability and deviant applications than the 64 bit tag. is your suggestion to allow a single 32bits tag and use a separate TLV for the extComm-tag (4bits) ? If yes, I subscribe to it. s. > > > > > > Acee Lindem wrote: > > As a member of the routing area directorate, I have reviewed the > > subject document. Here are my comments: > > > > Comments: > > > > 1. The last sentence of the abstract doesn't make sense. "Additionally, > > the information can be placed in LSPs that have TLVs as yet > > undefined, if this information is used to convey the same > > meaning in these future TLVs as it used in the currently defined > > TLVs". Suggested - "The administrative tag sub-TLVs may be used with > > with future TLVs as long as their semantics are preserved." > > > > 2. Section 5.2 - The value of the type is wrong - it should be 2 rather > > than 1. > > > > 3. Section 6 says the ordering of tags is not significant. However, the > > previous sections (5.1 and 5.2) say that an implementation may only > > consider the first tag. > > > > 4. Section 7 - List the requirements for receiving the new Sub-TLVs in > > this compliance section as well (even if they were stated previously). > > > > 5. Section 8 - The example talks about R2 associating tag 110 with > > property > > A and prefix 1.1.1.0/24. Yet in Figure 1, prefix 1.1.1.0/24 with > > property > > A is adjacent to R1 (which applies to me that R1 originate the > > prefix). > > Please fix either the example or the figure. > > > > Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): > > > > 1. The abstract contains references. The documents should be specified > > by name since the abstract can be excerpted. > > > > 2. Line 323 over 72 chars. > > > > Line 323 length is 74 > > Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, April > > > > 3. Pages 2, 3, 4, and 5 have over 58 lines. > > > > > -- > Acee > > From rtg-dir-admin@ietf.org Fri May 23 16:08:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23580 for ; Fri, 23 May 2003 16:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JIpC-0001vy-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 16:07:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JIpB-0001vv-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 16:07:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NK91B27593; Fri, 23 May 2003 16:09:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NK8hB27550 for ; Fri, 23 May 2003 16:08: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 QAA23570 for ; Fri, 23 May 2003 16:08:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JIor-0001vg-00 for rtg-dir@ietf.org; Fri, 23 May 2003 16:07:13 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19JIoq-0001vd-00 for rtg-dir@ietf.org; Fri, 23 May 2003 16:07:13 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 72B8175A3C2; Fri, 23 May 2003 13:08:37 -0700 (PDT) Message-ID: <3ECE7F9C.7050707@redback.com> Date: Fri, 23 May 2003 16:07:56 -0400 From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stefano previdi Cc: Christian Martin , Brad Neal , Routing Area Directorate Subject: Re: Comments on <3ECE5F3A.4000601@redback.com> <200305231943.h4NJhoR23425@strange-brew.cisco.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit stefano previdi wrote: > On Friday 23 May 2003 19:49, Acee Lindem wrote: > >>Christian, Stefano, Brad, >> >>The follow-up discussion on the necessity for both 32 bit and >>64 bit tags raises the question as to whether or not it is wise >>to allow an arbitrary number of tags to be advertised. >> >> This draft proposes 2 new "Administrative Tag" sub-TLVs to be added >> to TLV 135 and 235. These TLVs specify one or more ordered, 32 or 64 >> ~~~~~~~~~~~~~~~ >> bit unsigned integers that may be associated with an IP prefix. >> >>However, the receiver need only use the first. >> >> An implementation may consider only one of the encoded tags, in which >> case the first encoded tag must be considered. A tag value of zero >> is reserved and should be treated as "no tag". >> >>IMHO, allowing an arbitrary number of tags affords more potential for >>interoperability and deviant applications than the 64 bit tag. > > > is your suggestion to allow a single 32bits tag and use a > separate TLV for the extComm-tag (4bits) ? If yes, I > subscribe to it. Yes - that would be great. I feel more strongly about limiting the number of tags than the usage of the 64 bit tag. Thanks, Acee > > s. > > >> >> >> >> >>Acee Lindem wrote: >> >>>As a member of the routing area directorate, I have reviewed the >>>subject document. Here are my comments: >>> >>>Comments: >>> >>> 1. The last sentence of the abstract doesn't make sense. "Additionally, >>> the information can be placed in LSPs that have TLVs as yet >>> undefined, if this information is used to convey the same >>> meaning in these future TLVs as it used in the currently defined >>> TLVs". Suggested - "The administrative tag sub-TLVs may be used with >>> with future TLVs as long as their semantics are preserved." >>> >>> 2. Section 5.2 - The value of the type is wrong - it should be 2 rather >>> than 1. >>> >>> 3. Section 6 says the ordering of tags is not significant. However, the >>> previous sections (5.1 and 5.2) say that an implementation may only >>> consider the first tag. >>> >>> 4. Section 7 - List the requirements for receiving the new Sub-TLVs in >>> this compliance section as well (even if they were stated >> > previously). > >>> 5. Section 8 - The example talks about R2 associating tag 110 with >>>property >>> A and prefix 1.1.1.0/24. Yet in Figure 1, prefix 1.1.1.0/24 with >>>property >>> A is adjacent to R1 (which applies to me that R1 originate the >>>prefix). >>> Please fix either the example or the figure. >>> >>>Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): >>> >>> 1. The abstract contains references. The documents should be specified >>> by name since the abstract can be excerpted. >>> >>> 2. Line 323 over 72 chars. >>> >>> Line 323 length is 74 >>> Routing in IS-IS", draft-ietf-isis-wg-multi-topology-03.txt, >> > April > >>> 3. Pages 2, 3, 4, and 5 have over 58 lines. >>> >> >> >>-- >>Acee >> > > > -- Acee From rtg-dir-admin@ietf.org Fri May 23 21:55:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03632 for ; Fri, 23 May 2003 21:55:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JOEw-0004YX-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 21:54:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JOEw-0004YU-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 21:54:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O1u1B18919; Fri, 23 May 2003 21:56:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O1tMB18874 for ; Fri, 23 May 2003 21:55: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 VAA03621 for ; Fri, 23 May 2003 21:55:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JOEH-0004Xn-00 for rtg-dir@ietf.org; Fri, 23 May 2003 21:53:49 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19JOEG-0004XZ-00 for rtg-dir@ietf.org; Fri, 23 May 2003 21:53:48 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4O1sPXg004353; Fri, 23 May 2003 21:54:26 -0400 (EDT) Received: from [192.168.1.103] (rtp-vpn2-557.cisco.com [10.82.242.45]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA29044; Fri, 23 May 2003 21:54:25 -0400 (EDT) Date: Fri, 23 May 2003 21:54:30 -0400 (EDT) From: Russ White X-X-Sender: ruwhite@rwlaptop.local Reply-To: Russ White To: Alex Zinin cc: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse In-Reply-To: <93972307354.20030522185606@psg.com> Message-ID: References: <93972307354.20030522185606@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , So, my general feeling is that if it's related to routing, carrying it in a routing protocol is fine. I've not looked at the ppvpn stuff close enough to say one way or the other, but BGP has already drawn these lines rather wide for us, as have other protocols, really. Tags for admin filtering, like communities, and other policy information--this information isn't really needed for finding a route to the destination, per se. I'd probably draw the lines pretty wide, including policy and security information, but I've not looked at the ppvpn stuff close enough to know if I'd include that. :-) Russ On Thu, 22 May 2003, Alex Zinin wrote: > Folks- > > /* > * The topic is quite sensitive, so handle with care please. I know some > * of you may have a conflict of interest given what your companies do, > * so I'd like to explicitly ask you to take your vendor hat off and put > * your IETF rtg-dir member hat on when you participate in this > * discussion (no offense). > */ > > The discussion about appropriate and inappropriate applications of IP > routing protocols has been going on for quite a while. The most > noticeable outburst of it could be correlated with appearance of 2547 > ;), however, this is not what I'd like us to talk about now. > > I'd like to draw your attention to the following draft-- > draft-kompella-ppvpn-vpls-01.txt > > --which proposes to use BGP for VPLS (L2 VPN service) discovery and > signaling. In particular, please pay attention to the way the > semantics of the NLRI field have been changed (section 3.2.1), and to > the fact the best path selection algorithm is not employed at all. > These two facts--loss of any addressing semantics, and loss of best > path selection--make me think that the proposed approach essentially > transforms BGP into what I call a "universal transport system." > > There two questions here: > > 1. Where is the line between appropriate and inappropriate use > of routing protocols in general, and BGP in particular (there > maybe different aspects between LS IGPs that have a pure > transport/flooding component, and BGP whose info relaying > behavior is tightly coupled with the best path selection algo.) > > 2. Does the draft in question cross this line? > > Before this sort of discussion starts in public, I'd like to hear > opinions (preferably with technical and architectural arguments) > of the folk whose technical judgement I trust. > > Thanks. > > -- > Alex > http://www.psg.com/~zinin/ > __________________________________ riw@cisco.com CCIE <>< Grace Alone From rtg-dir-admin@ietf.org Fri May 23 22:07:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03946 for ; Fri, 23 May 2003 22:07:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JOQX-0004eE-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 22:06:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JOQW-0004eB-00 for rtg-dir-archive@ietf.org; Fri, 23 May 2003 22:06:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O280B20184; Fri, 23 May 2003 22:08:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O27TB20026 for ; Fri, 23 May 2003 22:07: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 WAA03913 for ; Fri, 23 May 2003 22:07:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JOPz-0004dQ-00 for rtg-dir@ietf.org; Fri, 23 May 2003 22:05:55 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19JOPx-0004ca-00 for rtg-dir@ietf.org; Fri, 23 May 2003 22:05:53 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19JOPQ-000EeP-00; Sat, 24 May 2003 02:05:20 +0000 Date: Fri, 23 May 2003 19:04:56 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <201059237092.20030523190456@psg.com> To: Russ White CC: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse In-Reply-To: References: <93972307354.20030522185606@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Russ, > So, my general feeling is that if it's related to routing, carrying it in a > routing protocol is fine. I've not looked at the ppvpn stuff close enough > to say one way or the other, but BGP has already drawn these lines rather > wide for us, as have other protocols, really. Tags for admin filtering, > like communities, and other policy information--this information isn't > really needed for finding a route to the destination, per se. > I'd probably draw the lines pretty wide, including policy and security > information, Agreed. > but I've not looked at the ppvpn stuff close enough to know if > I'd include that. Could you look at it, pls? Alex From rtg-dir-admin@ietf.org Sat May 24 01:15:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07459 for ; Sat, 24 May 2003 01:15:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JRMP-0005e8-00 for rtg-dir-archive@ietf.org; Sat, 24 May 2003 01:14:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JRMP-0005e5-00 for rtg-dir-archive@ietf.org; Sat, 24 May 2003 01:14:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O5G1B30518; Sat, 24 May 2003 01:16:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O5FjB30500 for ; Sat, 24 May 2003 01:15: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 BAA07456 for ; Sat, 24 May 2003 01:15:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JRM8-0005e2-00 for rtg-dir@ietf.org; Sat, 24 May 2003 01:14:08 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19JRM7-0005dz-00 for rtg-dir@ietf.org; Sat, 24 May 2003 01:14:07 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19JRNT-00093X-00; Sat, 24 May 2003 05:15:31 +0000 Date: Fri, 23 May 2003 22:13:46 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1959127013.20030523221346@psg.com> To: Tony Przygienda CC: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse In-Reply-To: <3ECE65A7.6050004@net4u.ch> References: <93972307354.20030522185606@psg.com> <3ECE65A7.6050004@net4u.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tony, > Let me give you an outlook of possible outcomes I see rather than an > opinion. Thanks, see below, pls. >> noticeable outburst of it could be correlated with appearance of 2547 >> ;), however, this is not what I'd like us to talk about now. >> > this one's lost for sure. agreed > There is no line IMHO, it's just a hues-of-grey-border, especially > in IP. Strictly speaking, something like BGP is a routing protocol > which means, it should answer the 'How do I get from A to B' > question or even stricter, in ISO terms, it must involve relaying > between layer-3 entities. That's the theoretical one and based on > that, things like 2547 are a layer that needs its own protocol and > things like L2 info have no business whatsoever in routing protocol > data. > The practical one is that vendors piggy-back lots of garb into > routing protocols that have no business there since it's the fastest > way to ship features that involve anything that needs reasonable > amount of quickly but loosely synchronized data and there is piles > such stuff. Moreover, building partitioned, loosely synchronized, > distributed databases is hard like hell. So, Pedro's 'discussion' on > idr was basically euphemistically gold-platting these very facts by > some pseudo-philosophical contortions. HOWEVER, this is > vendor-reality and a good local solution for the problem space they > are faced with or rather maybe, created for themselves (insanely > short development cycles, feature creep, disregard for any S > [stability, scalability, security, ...] in the first release). The > ethics of IP, namely 'running code' have been since long modified > into 'quick-and-dirty running code' and is used as excuse for lack > of a unifying architecture that underlies today's IP-networking > realities and their variations. So, where am I going with this rant > ? Well, vendor reality is that routing protocols are being force-fed > anything they can bear and has the promise to generate revenue and > this won't be changed anytime soon since engineering 'ethics' is > gone since a while and The above is an honest description of reality > IETF has no power whatever these days to stop anything major vendors > are doing and deploying. In the short term, IETF can just hang on > for the ride. How to change this situation is yes another topic and > not one I want to touch here or rather at all. > My advice as to the whole issue: IETF is a documenting and not a > defining body since a while and Some questions: Q1: what should we do if someone brings a complete BS to a WG (let's say someone decided that TCP over ISIS was a cool thing to do) and says it's coded and possibly deployed? Q2: will the answer be different depending on whether the guy comes from a major vendor or from whoknowswhere.com? > directions you [or maybe whole IESG] are trying to push it into > (tightening specifications to the point of over-specifying [and > delaying documents ridiculously] and an retrofited-'architecture' > which however is not laid down anywhere as I saw it) are not very > promising IMHO and the vendor will happilly trot on. I'd say the direction is to avoid _under_specification, not to promote over-specification. It would also seem as somewhat orthogonal topic, but I am indeed interested in discussing this, so I'll start a separate thread on this. > On a larger scale, two outcomes I envision possible: either IP is > the combustion engine of networking and it will hang on for next 100 > years despite being smelly, inefficient and ripe to be displaced by > better solutions and we will preserve this status-quo OR the whole > thing will flame out and end up overridden by something small and > elegant that will come out of the dark. The 2nd outcome would be > unlikely BUT for the fact that technology is almost weightless and > the daemon of 6-months-product-cycles made displacement of existing > solutions much easier than in the case of combustion-engine-driven > toys. > so, just food for thought Thanks again! Alex From rtg-dir-admin@ietf.org Sat May 24 02:08:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17468 for ; Sat, 24 May 2003 02:08:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JSBf-0005xj-00 for rtg-dir-archive@ietf.org; Sat, 24 May 2003 02:07:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JSBf-0005xg-00 for rtg-dir-archive@ietf.org; Sat, 24 May 2003 02:07:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O690B06374; Sat, 24 May 2003 02:09:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O68jB06311 for ; Sat, 24 May 2003 02:08: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 CAA17186 for ; Sat, 24 May 2003 02:08:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JSBP-0005xX-00 for rtg-dir@ietf.org; Sat, 24 May 2003 02:07:07 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19JSBO-0005xQ-00 for rtg-dir@ietf.org; Sat, 24 May 2003 02:07:06 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19JSCm-000GOg-00 for rtg-dir@ietf.org; Sat, 24 May 2003 06:08:32 +0000 Date: Fri, 23 May 2003 23:05:10 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <18512211459.20030523230510@psg.com> To: rtg-dir@ietf.org Subject: Meta: goals for IETF Routing area MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- I started writing the message to start the discussion on under-specification vs over-specification and quickly realized that my thoughts are based on some fundamental assumptions about the IETF and the Routing area in particular. It seems that a discussion on this would be useful to at least realize where we all stand so we can understand where people come from. Here are some of the most basic statements I have in mind, by no means complete, but roughly what I think: S1: The goal of the IETF process is to produce technical specifications that can be used to develop multiple independent implementations that can interoperate with each other. S2: One of the direct responsibilities of the WGs within the Routing area is to ensure continuos operational status of the Internet routing system by maintaining scalability and stability characteristics of the existing routing protocols, as well as developing new protocols, extensions, and bug fixes in a timely manner. Corollaries from the above: C1: Specifications produced within the Routing area need to specify enough details to ensure that an informed reader unfamiliar with the specific subject of the document can write an implementation that a) can interoperate with others and b) does not affect the aspects described in S2 above. C2: We (the routing community, including vendors, and users) need to be able to conduct adequate review of proposals affecting the Internet routing protocols so that we can filter out bad ideas, fix bugs and improve the mechanisms by leveraging the collective wisdom. Let's keep this warm and friendly, but open ;) Regards. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Sat May 24 03:09:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21076 for ; Sat, 24 May 2003 03:09:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JT8j-0006Ra-00 for rtg-dir-archive@ietf.org; Sat, 24 May 2003 03:08:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JT8i-0006RX-00 for rtg-dir-archive@ietf.org; Sat, 24 May 2003 03:08:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O7A3B16206; Sat, 24 May 2003 03:10:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4O79pB16182 for ; Sat, 24 May 2003 03:09: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 DAA21073 for ; Sat, 24 May 2003 03:09:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JT8W-0006RU-00 for rtg-dir@ietf.org; Sat, 24 May 2003 03:08:12 -0400 Received: from net4u.net4u.ch ([194.191.0.1] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19JT8V-0006RR-00 for rtg-dir@ietf.org; Sat, 24 May 2003 03:08:11 -0400 Received: from net4u.ch (zux006-029-237.adsl.green.ch [81.6.29.237]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h4O79ZR09025; Sat, 24 May 2003 09:09:35 +0200 Message-ID: <3ECF1A5F.2050401@net4u.ch> Date: Sat, 24 May 2003 09:08:15 +0200 From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse References: <93972307354.20030522185606@psg.com> <3ECE65A7.6050004@net4u.ch> <1959127013.20030523221346@psg.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex Zinin wrote: >Tony, > > > >>Let me give you an outlook of possible outcomes I see rather than an >>opinion. >> >> > >Thanks, see below, pls. > sorry for the tannic truth ;-/ I'll be speaking in riddles again I fear. > > > > > > >>... used as excuse for lack >>of a unifying architecture that underlies today's IP-networking >>realities and their variations. So, where am I going with this rant >>? Well, vendor reality is that routing protocols are being force-fed >>anything they can bear and has the promise to generate revenue and >>this won't be changed anytime soon since engineering 'ethics' is >>gone since a while and >> >> > >The above is an honest description of reality > ok > > >>My advice as to the whole issue: IETF is a documenting and not a >>defining body since a while and >> >> > >Some questions: > > Q1: what should we do if someone brings a complete BS to a WG > (let's say someone decided that TCP over ISIS was a cool thing > to do) and says it's coded and possibly deployed? > the moment somebody coded and deployed such a thing (given it's a major vendor, whereas I define major as someone with decent customer base that won't go chapter 11 tommorow, so it's a shifting target) it's too late. That's the trick. Ye shall have your ear on the ground and listen carefully before stuff shows up and influence it then. How ? Well, command respect by any of the organization managament approaches (a book on group dynamics and organizational behavior 101 may do the trick) and learn to put the right people into right places and pretty soon you'll know stuff before drafts show up. Then a certain influence can be taken. If something shows up coded & deployed by major vendor, you only very, very marginally influence the outcome these days. Basically the 15secs attention span of sillicon valley has passed by then and changing the code is a major pain. You remember that I'm sure. If something is criminally stupid, then it should die by the virtue of the process in any case, however I observe that IETF in last couple years had only a sketchy record on that one. It's heretic to say here but in a sense I think that the ATM Forum approach of voting was doing a better job in producing good specs. However, good specs are not necessarily what makes the technology successfull I learned. > > Q2: will the answer be different depending on whether the guy > comes from a major vendor or from whoknowswhere.com? > > > > >>directions you [or maybe whole IESG] are trying to push it into >>(tightening specifications to the point of over-specifying [and >>delaying documents ridiculously] and an retrofited-'architecture' >>which however is not laid down anywhere as I saw it) are not very >>promising IMHO and the vendor will happilly trot on. >> >> > >I'd say the direction is to avoid _under_specification, not to promote >over-specification. It would also seem as somewhat orthogonal topic, >but I am indeed interested in discussing this, so I'll start a >separate thread on this. > ok, I think we agree in principle here but in terms of tactics we butt-head most of the times. -- tony From rtg-dir-admin@ietf.org Sat May 24 16:25:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04492 for ; Sat, 24 May 2003 16:25:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JfZ1-0001wV-00 for rtg-dir-archive@ietf.org; Sat, 24 May 2003 16:24:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19JfZ1-0001wR-00 for rtg-dir-archive@ietf.org; Sat, 24 May 2003 16:24:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4OKQ1B29365; Sat, 24 May 2003 16:26:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4OKPuB29347 for ; Sat, 24 May 2003 16:25: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 QAA04479 for ; Sat, 24 May 2003 16:25:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JfYu-0001wN-00 for rtg-dir@ietf.org; Sat, 24 May 2003 16:24:16 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19JfYt-0001wK-00 for rtg-dir@ietf.org; Sat, 24 May 2003 16:24:15 -0400 Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4OKPgYU027339; Sat, 24 May 2003 14:25:42 -0600 (MDT) Received: from sydney.East.Sun.COM (esun1as-be21-ge0.Central.Sun.COM [129.147.60.148]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4OKPV416406; Sat, 24 May 2003 16:25:34 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Message-Id: <200305242025.h4OKPV416406@sydney.East.Sun.COM> Date: Sat, 24 May 2003 16:26:59 -0400 To: "Alex Zinin" , Reply-To: Subject: Re: Meta: goals for IETF Routing area X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit What you wrote certainly seems correct. Recently I've stumbled across a bunch of things in which you can't count on implementation behavior. One example is handling of router alert option, and in general what can be trapped in the fast path. Some implementations, apparently, will only trap things with router alert (so you can't trap based on a new protocol type, or a UDP port). Other implementations throw away packets with router alert. Some implementations think router alert takes a parameter. Others don't. This sort of thing... And then there's NAT. NAT wouldn't be nearly as bad to design around if it were written down what NATs do, and all NATs adhered to it. So it's not just a matter of getting the designs sound and the documentation comprehensible and complete. Maybe we also need some sort of conformance hurdle, so that there won't be widely deployed hacks that sort of work, that interact badly with other deployed hacks that sort of work. Radia "Alex Zinin" wrote: >Folks- > > I started writing the message to start the discussion on > under-specification vs over-specification and quickly realized that > my thoughts are based on some fundamental assumptions about the IETF > and the Routing area in particular. It seems that a discussion on > this would be useful to at least realize where we all stand so we can > understand where people come from. > > Here are some of the most basic statements I have in mind, by no > means complete, but roughly what I think: > > S1: The goal of the IETF process is to produce technical specifications > that can be used to develop multiple independent implementations > that can interoperate with each other. > > S2: One of the direct responsibilities of the WGs within the Routing > area is to ensure continuos operational status of the Internet > routing system by maintaining scalability and stability > characteristics of the existing routing protocols, as well as > developing new protocols, extensions, and bug fixes in a timely > manner. > > Corollaries from the above: > > C1: Specifications produced within the Routing area need to specify > enough details to ensure that an informed reader unfamiliar with > the specific subject of the document can write an implementation > that a) can interoperate with others and b) does not affect > the aspects described in S2 above. > > C2: We (the routing community, including vendors, and users) need to > be able to conduct adequate review of proposals affecting the > Internet routing protocols so that we can filter out bad ideas, > fix bugs and improve the mechanisms by leveraging the collective > wisdom. > > Let's keep this warm and friendly, but open ;) > > Regards. > >-- >Alex >http://www.psg.com/~zinin/ > From rtg-dir-admin@ietf.org Sun May 25 11:07:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03417 for ; Sun, 25 May 2003 11:07:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Jx4p-0006YL-00 for rtg-dir-archive@ietf.org; Sun, 25 May 2003 11:06:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Jx4o-0006YI-00 for rtg-dir-archive@ietf.org; Sun, 25 May 2003 11:06:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PF7vB09921; Sun, 25 May 2003 11:07:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PF4wB08960 for ; Sun, 25 May 2003 11:04: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 LAA03394; Sun, 25 May 2003 11:04:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Jx1u-0006XR-00; Sun, 25 May 2003 11:03:22 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19Jx1r-0006XL-00; Sun, 25 May 2003 11:03:20 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h4PF3VV15108; Sun, 25 May 2003 17:03:31 +0200 Date: Sun, 25 May 2003 17:03:31 +0200 From: Hannes Gredler To: "Martin, Christian" Cc: "'Acee Lindem'" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on Message-ID: <20030525150331.GA15087@juniper.net> References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> User-Agent: Mutt/1.3.28i X-MIME-Autoconverted: from 8bit to quoted-printable by ghostrider.gredler.at id h4PF3VV15108 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4PF4wB08962 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4PF7vB09921 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA03417 pls, keep in mind that there is already code in production that allows more than one tag; common use i have seen so far is tag #1 controls L2L1 leakage tag #2 for informational purposes and points to the area of origin; /hannes On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote: | RE: Comments on | | Acee, | | As the original goal was to create a capability similar to OSPF's route tag, | it may be wise to drop this capability.  On the otherhand, having multiple | tags per route can provide more information about the route than a single | tag.  In this regard, the 32 bit tag operates more like a community, and the | 64 bit tag operates like an extended community.  From an implementation | perspective, the same routines for matching and setting these fields should | be similar to the community fields in BGP. | | I would like to solicit the WG for comments on which capability is most | attractive.  The goal is not to introduce too much bloat (is it too late for | that?!) while still providing some flexibility. | | As soon as I receive any final comments, I will release the updated draft. | | Thanks for pointing out this critical piece! | | Regards, | chris | | >-----Original Message----- | >From: Acee Lindem [mailto:acee@redback.com] | >Sent: Friday, May 23, 2003 1:50 PM | >To: Acee Lindem | >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area | >Directorate | >Subject: Re: Comments on | > | > | >Christian, Stefano, Brad, | > | >The follow-up discussion on the necessity for both 32 bit and | >64 bit tags raises the question as to whether or not it is | >wise to allow an arbitrary number of tags to be advertised. | > | >       This draft proposes 2 new "Administrative Tag" sub-TLVs | >to be added | >       to TLV 135 and 235.  These TLVs specify one or more | >ordered, 32 or 64 | >                                                  ~~~~~~~~~~~~~~~ | >       bit unsigned integers that may be associated with an IP prefix. | > | >However, the receiver need only use the first. | > | >       An implementation may consider only one of the encoded | >tags, in which | >       case the first encoded tag must be considered.  A tag | >value of zero | >       is reserved and should be treated as "no tag". | > | >IMHO, allowing an arbitrary number of tags affords more | >potential for interoperability and deviant applications than | >the 64 bit tag. | > | > | > | > | > | >Acee Lindem wrote: | >> As a member of the routing area directorate, I have reviewed the | >> subject document. Here are my comments: | >> | >> Comments: | >> | >>   1. The last sentence of the abstract doesn't make sense. | >"Additionally, | >>      the information can be placed in LSPs that have TLVs as yet | >>      undefined, if this information is used to convey the same | >>      meaning in these future TLVs as it used in the currently defined | >>      TLVs". Suggested - "The administrative tag sub-TLVs may | >be used with | >>      with future TLVs as long as their semantics are preserved." | >> | >>   2. Section 5.2 - The value of the type is wrong - it | >should be 2 rather | >>      than 1. | >> | >>   3. Section 6 says the ordering of tags is not significant. | >However, the | >>      previous sections (5.1 and 5.2) say that an | >implementation may only | >>      consider the first tag. | >> | >>   4. Section 7 - List the requirements for receiving the new | >Sub-TLVs in | >>      this compliance section as well (even if they were stated | >> previously). | >> | >>   5. Section 8 - The example talks about R2 associating tag 110 with | >> property | >>      A and prefix 1.1.1.0/24. Yet in Figure 1, prefix | >1.1.1.0/24 with | >> property | >>      A is adjacent to R1 (which applies to me that R1 originate the | >> prefix). | >>      Please fix either the example or the figure. | >> | >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): | >> | >>   1. The abstract contains references. The documents should | >be specified | >>      by name since the abstract can be excerpted. | >> | >>   2. Line 323 over 72 chars. | >> | >>     Line 323 length is 74 | >>          Routing in IS-IS", | >draft-ietf-isis-wg-multi-topology-03.txt, | >> April | >> | >>   3. Pages 2, 3, 4, and 5 have over 58 lines. | >> | > | > | >-- | >Acee | > From rtg-dir-admin@ietf.org Mon May 26 11:29:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16234 for ; Mon, 26 May 2003 11:29:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KJso-0007J8-00 for rtg-dir-archive@ietf.org; Mon, 26 May 2003 11:27:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KJsn-0007J4-00 for rtg-dir-archive@ietf.org; Mon, 26 May 2003 11:27:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QFT2B16308; Mon, 26 May 2003 11:29:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QFSxB16290 for ; Mon, 26 May 2003 11:28: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 LAA16229 for ; Mon, 26 May 2003 11:28:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KJsf-0007J0-00 for rtg-dir@ietf.org; Mon, 26 May 2003 11:27:21 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19KJse-0007Iw-00 for rtg-dir@ietf.org; Mon, 26 May 2003 11:27:20 -0400 Message-ID: From: Jeff Parker To: "'radia.perlman@sun.com'" , rtg-dir@ietf.org Subject: RE: Meta: goals for IETF Routing area Date: Mon, 26 May 2003 11:28:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > And then there's NAT. NAT wouldn't be nearly as bad to > design around if it were written down what NATs do, and > all NATs adhered to it. > > So it's not just a matter of getting the designs sound and > the documentation comprehensible and complete. Maybe > we also need some sort of conformance hurdle, so that > there won't be widely deployed hacks that sort of work, > that interact badly with other deployed hacks that sort > of work. > > Radia Interesting idea. Many have pointed out that the larger companies have been very effective at getting clearance for their new ideas. What has been less discussed, but is the other side of this, is that they have the opportunity to block standardization of any new ideas that they are not ready to ship. There are a number of new products that came out in the last decade, such as pure firewalls or load-splitters for web server farms, that could have been held in IP traffic court by a conformance hurdle. By the time a startup jumped through all the hoops required and explained and documented any IP-specific behaviors they had made, any advantage provided by early release would be long gone. Staffing standards-geeks is an expense than many startups can't afford these days, so this would erect another barrier to entry. The trick is to allow innovation and experimentation while preserving the integrity of the architecture. - jeff parker From rtg-dir-admin@ietf.org Tue May 27 11:09:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16120 for ; Tue, 27 May 2003 11:09:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kg3u-0005FT-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 11:08:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Kg3u-0005FQ-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 11:08:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFA1B27411; Tue, 27 May 2003 11:10:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RF9kB27384 for ; Tue, 27 May 2003 11:09: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 LAA16111 for ; Tue, 27 May 2003 11:09:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kg3d-0005FI-00 for rtg-dir@ietf.org; Tue, 27 May 2003 11:08:09 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19Kg3c-0005F5-00 for rtg-dir@ietf.org; Tue, 27 May 2003 11:08:08 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h4RF9D6a055823; Tue, 27 May 2003 11:09:13 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h4RF998o055812; Tue, 27 May 2003 11:09:09 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h4RF93713981; Tue, 27 May 2003 11:09:03 -0400 (EDT) Date: Tue, 27 May 2003 11:09:03 -0400 From: Jeffrey Haas To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse Message-ID: <20030527110903.A13656@nexthop.com> References: <93972307354.20030522185606@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <93972307354.20030522185606@psg.com>; from zinin@psg.com on Thu, May 22, 2003 at 06:56:06PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Thu, May 22, 2003 at 06:56:06PM -0700, Alex Zinin wrote: > draft-kompella-ppvpn-vpls-01.txt Could someone tell me what draft the following reference is supposed to refer to: [ 4] Kompella, K., et al, "MPLS-based Layer 2 VPNs", work in progress. These drafts all seem to have the habit of referring to things as "work in progress" without even a "draft-ietf-ppvpn-blah" -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Tue May 27 11:18:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16410 for ; Tue, 27 May 2003 11:18:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KgBh-0005KF-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 11:16:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KgBg-0005KA-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 11:16:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFI0B27755; Tue, 27 May 2003 11:18:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFH3B27687 for ; Tue, 27 May 2003 11:17: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 LAA16316 for ; Tue, 27 May 2003 11:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KgAi-0005Il-00 for rtg-dir@ietf.org; Tue, 27 May 2003 11:15:28 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19KgAh-0005IO-00 for rtg-dir@ietf.org; Tue, 27 May 2003 11:15:27 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h4RFGTu17871; Tue, 27 May 2003 08:16:29 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200305271516.h4RFGTu17871@merlot.juniper.net> To: Alex Zinin cc: idr@merit.edu, rtg-dir@ietf.org Subject: Re: AD-review comments on draft-ietf-idr-bgp4-20 In-Reply-To: Your message of "Mon, 05 May 2003 16:38:15 PDT." <177177649135.20030505163815@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77283.1054048589.1@juniper.net> Date: Tue, 27 May 2003 08:16:29 -0700 From: Yakov Rekhter Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Alex, > Folks, > > Please find below my AD-review comments. Hopefully they will help > improve the document. I tried to consult Andrew's list as much as > possible, but do feel free to point out if something has already been > discussed and agreed upon. > > Thanks go to Yakov for kicking me often enough ;) > -- > Alex Zinin > > Some nits: > - run it by a spelling checker, please > - disable hyphenation if possible > - include boilerplates for IPR notice, Copyright notice Sure. > > General comment: > > in some places I highlighted the fact that required behavior is not > described using the 2119 language, so it is not clear if a MUST or > SHOULD or MAY is applicable. I am sure I've missed some more places > like this. I'd like to ask the editors to go through the doc and > check this. Sure. > > Status of this Memo > > > > > ... > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > > > > Specification of Requirements > > Nit: move Abstract here. Move requirements after the Acks. Ok. > > Abstract > > Should the Abstract say that this spec covers IPv4 only? Sure. > > 3. Summary of Operation > ... > > This document uses the term `Autonomous System' (AS) throughout. The > > classic definition of an Autonomous System is a set of routers under > > a single technical administration, using an interior gateway protocol > > (IGP) and common metrics to determine how to route packets within the > > AS, and using an inter-AS routing protocol to determine how to route > > packets to other ASs. Since this classic definition was developed, it > > has become common for a single AS to use several IGPs and sometimes > > several sets of metrics within an AS. The use of the term Autonomous > > System here stresses the fact that, even when multiple IGPs and met- > > rics are used, the administration of an AS appears to other ASs to > > have a single coherent interior routing plan and presents a consis- > > tent picture of what destinations are reachable through it. > > Ed: Since 'AS' has been defined before, do we need to repeat the > definition here? The definition section before presents a *summary* of the definitions used in the document. I think that the text reads fine as is, so I would prefer not to change it. > ... > > peer in the same AS is referred to as an internal peer. Internal BGP > > and external BGP are commonly abbreviated IBGP and EBGP. > > Ed: These two have been defined before too See my previous comment. > ... > > Care must be taken to > > ensure that the interior routers have all been updated with transit > > information before the BGP speakers announce to other ASs that tran- > > sit service is being provided. > > What does the last sentence really mean from the implementation > perspective? It used to mean the BGP/IGP synchronization check. Now > that iBGP everywhere is assumed, how do we check this condition? In the absence of any objections by June 10 I suggest to take this sentence out. > > This document specifies the base behavior of the BGP protocol. This > > behavior can and is modified by extention specifications. When the > Ed: "extension" Sure. > > protocol is extended the new behavior is fully documented in the > > extention specifications. > Ed: "extension" Sure. > > > 3.1 Routes: Advertisement and Storage > > > > For the purpose of this protocol, a route is defined as a unit of > > information that pairs a set of destinations with the attributes of a > > path to those destinations. The set of destinations are systems whose > > IP addresses are contained in one IP address prefix carried in the > > Network Layer Reachability Information (NLRI) field of an UPDATE mes- > > sage, and the path is the information reported in the path attributes > > field of the same UPDATE message. > Ed: Repeated definition again See above. > ... > > If a BGP speaker chooses to advertise the route, it MAY add to or > > modify the path attributes of the route before advertising it to a > > peer. > > The intent here is to say that it's ok to modify the attribute set of > a previously received route when it's announced further. The way it > reads though is that self-originated routes are also within the > context and MAY sounds like you don't have to add attributes when > announcing those. I will replace "If a BGP speaker chooses to advertise the route" with "If a BGP speaker chooses to advertise a previously received route". > > ... > > > Changing attribute of a route is accomplished by advertising a > > replacement route. The replacement route carries new (changed) > > attributes and has the same NLRI as the original route. > > "same NLRI" implies the same prefix, but not the NLRI field, which can > be different (containing other routes), should the use of this term be > normalized throughout the document? I will replace "the same NLRI" with "the same address prefix". > > > 4.2 OPEN Message Format > > > > After a TCP is established, the first message sent by each side is an > > "TCP connection" ok. > > 5. Path Attributes > ... > > If a path with recognized transitive optional attribute is accepted > > and passed along to other BGP peers and the Partial bit in the > > Attribute Flags octet is set to 1 by some previous AS, it is not > > 'MUST NOT' here? Sure. > > set > > back to 0 by the current AS. Unrecognized non-transitive optional > > attributes MUST be quietly ignored and not passed along to other BGP > > peers. > ... > > The same attribute (attribute with the same type) can not appear more > > than once within the Path Attributes field of a particular UPDATE > > message. > > What should an implementation do if this happens? See section 6.3: If any attribute appears more than once in the UPDATE message, then the Error Subcode is set to Malformed Attribute List. > > The mandatory category refers to an attribute which MUST be present > > in both IBGP and EBGP exchanges if NLRI are contained in the UPDATE > > Ed: "if the NLRI field is contained" instead? No, as the NLRI field is always present in the UPDATE message (although if NLRI is not present, then the NLRI field is empty). > > > 5.1.2 AS_PATH > ... > > b) When a given BGP speaker advertises the route to an external > > peer, then the advertising speaker updates the AS_PATH attribute > > as follows: > > > > 1) if the first path segment of the AS_PATH is of type > > AS_SEQUENCE, the local system prepends its own AS number as the > > last element of the sequence (put it in the leftmost position). > > 'Leftmost position'... isn't this still open for interpretation? How > about wording this relative to the position of the octets in the > protocol message? I'll replace "the leftmost position" with "the leftmost position with respect to the position of octets in the protocol message". > > If the act of prepending will cause an overflow in the AS_PATH > > segment, i.e. more than 255 ASs, it is legal to prepend a new > > segment of type AS_SEQUENCE and prepend its own AS number to > > this new segment. > > What's the recommended behavior here? "it is legal to prepend" really means "it SHOULD prepend". In the absence of any objections by June 10 I'll update the text. > > > > 5.1.4 MULTI_EXIT_DISC > > > > > > The MULTI_EXIT_DISC is an optional non-transitive attribute which is > > intended to be used on external (inter-AS) links to discriminate > > among multiple exit or entry points to the same neighboring AS. The > > value of the MULTI_EXIT_DISC attribute is a four octet unsigned num- > > ber which is called a metric. All other factors being equal, the exit > > point with lower metric SHOULD be preferred. If received over EBGP, > > the MULTI_EXIT_DISC attribute MAY be propagated over IBGP to other > > BGP speakers within the same AS. The MULTI_EXIT_DISC attribute > > seems that a reference to 9.1.2.2 is due here, as using MED in local > route calculation and not propagating it further is dangerous Sure. > > received from a neighboring AS MUST NOT be propagated to other neigh- > > boring ASs. > > > > A BGP speaker MUST IMPLEMENT a mechanism based on local configuration > ^^^^^^^^^lower-case Sure. > > which allows the MULTI_EXIT_DISC attribute to be removed from a > > route. This MAY be done prior to determining the degree of preference > > what's the recommended behavior here? What the text is saying is that a BGP speaker optionally (MAY) remove MED from a route. If the speaker does this, then this *has to* happen prior to determining the degree of preference for the route. So, what "This MAY" refers to is the fact that removing MED is optional. To clarify I would replace "This MAY be done" with "Removal of the MULTI_EXIT_DISC attribute MAY be done". > > of the route and performing route selection (decision process phases > > 1 and 2). > > > > An implementation MAY also (based on local configuration) alter the > > value of the MULTI_EXIT_DISC attribute received over EBGP. This MAY > > be done prior to determining the degree of preference of the route > > what's the recommended behavior here? The same as the previous comment. > > 5.1.5 LOCAL_PREF > ... > > A BGP speaker SHALL calculate the degree of preference for > > each external route based on the locally configured policy, and > > Should we be more honest here and say that the implementation must > allow the admin to SET the degree of preference through the local > policy to influence the best-path selection process, i.e., I don't > think any implementation really *calculates* it. Please see my answer to you comment on 9.1.1 > > 5.1.6 ATOMIC_AGGREGATE > ... > > A BGP speaker that receives a route with the ATOMIC_AGGREGATE > > attribute MUST NOT make any NLRI of that route more specific (as > > defined in 9.1.4) when advertising this route to other BGP speakers. > > Since deaggregation is not described in this document, do we need this > para? I would prefer to keep the current text, as to make sure that an implementation wouldn't do deaggregation. > > A BGP speaker that receives a route with the ATOMIC_AGGREGATE > > attribute needs to be cognizant of the fact that the actual path to > > destinations, as specified in the NLRI of the route, while having the > > loop-free property, may not be the path specified in the AS_PATH > > attribute of the route. > > What does this really mean from the implementation perspective? This is mostly FYI. It has to do with the user of BGP... > > 5.1.7 AGGREGATOR > > > > > > AGGREGATOR is an optional transitive attribute which MAY be included > > in updates which are formed by aggregation (see Section 9.2.2.2). A > > BGP speaker which performs route aggregation MAY add the AGGREGATOR > > What's the recommended behavior here? Include or not, and under what > circumstances? The spec doesn't provide any recommendation on this, as it is optional. > > 6. BGP Error Handling. > ... > > The phrase "the BGP connection is closed" means that the TCP connec- > > tion has been closed, the associated Adj-RIB-In has been cleared, and > > that all resources for that BGP connection have been deallocated. > > Entries in the Loc-RIB associated with the remote peer are marked as > > invalid. The fact that the routes have become invalid is passed to > > other BGP peers before the routes are deleted from the system. > > What does "the fact is passed" mean? Should we instead say that local > route recalculation happens and peers are sent either updated best > routes or withdrawals? How about the following replacement for the last sentence: The local system recalculates its best routes for the destinations of the routes marked as invalid, and advertises to its peers either withdraws for the routes marked as invalid, or the new best routes before the invalid routes are deleted from the system. > > 6.2 OPEN message error handling. > ... > > If the Autonomous System field of the OPEN message is unacceptable, > > then the Error Subcode is set to Bad Peer AS. The determination of > > acceptable Autonomous System numbers is outside the scope of this > > protocol. > > Shouldn't we say that configuration based detection should be > supported, i.e., when remote-as is configured for the peer? No. > ... > > If the BGP Identifier field of the OPEN message is syntactically > > incorrect, then the Error Subcode is set to Bad BGP Identifier. Syn- > > tactic correctness means that the BGP Identifier field represents a > > valid IP host address. > > Is "valid IP host address" defined somewhere, btw? Certainly not in this document. Perhaps for clarity I'll add "unicast" in front of "IP host address". > > 6.3 UPDATE message error handling. > > > > > > All errors detected while processing the UPDATE message are indicated > > by sending the NOTIFICATION message with Error Code UPDATE Message > > Error. The error subcode elaborates on the specific nature of the > > error. > > "are indicated..." is this a MUST, SHOULD, or MAY? MUST. > ... > > If the ORIGIN attribute has an undefined value, then the Error Sub- > > code is set to Invalid Origin Attribute. The Data field contains the > > unrecognized attribute (type, length and value). > > Curious: do we really have to drop a session on this condition? Given > that the attribute was syntactically correct and the TLV was not > broken, so the stream is still in sync and we can move on? Of course, > if this is what current implementations do, we have no other choice. In the current spec all the errors are fatal. Including errors in the ORIGIN attribute. > ... > > If the UPDATE message is received from an external peer, the local > > system MAY check whether the leftmost AS in the AS_PATH attribute is > > Same comment about 'leftmost'... Maybe we should define this somewhere > in the beginning of the spec? I will replace "the leftmost AS" with "the leftmost AS with respect to the position of octets in the protocol message". > ... > > The NLRI field in the UPDATE message is checked for syntactic valid- > > ity. If the field is syntactically incorrect, then the Error Subcode > > is set to Invalid Network Field. > > Should we give more data on what syntactic validity means in this case > so people behave consistently? As Curtis suggested a while ago: If the document is unclear to the well qualified reader (one possessing a thorough understanding of foundations of this work, including IP routing, TCP, TCP programming, and the referenced documents) then the document may need to be changed to improve clarity. The case you mentioned above suggests that the reader is not well qualified. > > 6.7 Cease. > ... > > If the BGP speaker decides to terminate its BGP > > connection with a neighbor because the number of address prefixes > > received from the neighbor exceeds the locally configured upper > > bound, then the speaker MUST send to the neighbor a NOTIFICATION mes- > > sage with the Error Code Cease. > > Should we also say that when the peer decides to discard incoming > prefixes, this event should be logged locally? In the absence of any objections by June 10 I'll add the following to the text: The speaker MAY also log this locally. > > 9. UPDATE Message Handling > > > > > > An UPDATE message may be received only in the Established state. > > What if it is received in another state? It is an error. To make this clear I'll add the following to the text: Receiving an UPDATE message in any other state is an error. > ... > > 9.1 Decision Process > > > > > > The Decision Process selects routes for subsequent advertisement by > > applying the policies in the local Policy Information Base (PIB) to > > the routes stored in its Adj-RIBs-In. The output of the Decision Pro- > > cess is the set of routes that will be advertised to peers; the > > selected routes will be stored in the local speaker's Adj-RIB-Out > RIB-Out or RIBs-out (plural)? Plural. > > according to policy. > > > > The selection process is formalized by defining a function that takes > > the attribute of a given route as an argument and returns either (a) > > a non-negative integer denoting the degree of preference for the > > route, or (b) a value denoting that this route is ineligible to be > > installed in LocRib and will be excluded from the next phase of route > > Loc-RIB Ok. > > selection. > ... > > The Decision Process operates on routes contained in the Adj-RIB-In, > Adj-RIBs-In (plural) ? Plural. > > and is responsible for: > > > 9.1.1 Phase 1: Calculation of Degree of Preference > ... > > If the route is learned from an external peer, then the local BGP > > speaker computes the degree of preference based on preconfigured > > policy information. If the return value indicates that the route > > is ineligible, the route MAY NOT serve as an input to the next > > phase of route selection; otherwise the return value is used as > > the LOCAL_PREF value in any IBGP readvertisement. > > So, AFAIK, the major implementations do not follow this step > (calculating the degree of preference, and then announcing). Instead, > implementations allow setting the LOCAL_PREF value locally, which is > taken into consideration during the best path selection, and is also > reannounced further. It is important to keep in mind that the whole section on the BGP decision process does *not* mean that an implementation must implement it precisely as it is described in the spec, as long as the implementation support the described functionality and its externally visible behavior is the same. With this in mind how about if I'll add the following: The BGP Decision Process in this document is conceptual and do not have to be implemented precisely as described here, as long as the implementations support the described functionality and their externally visible behavior is the same. > Also "is used" is not specific enough. Is it SHOULD or MUST? MUST. > > 9.1.2 Phase 2: Route Selection > ... > > If the AS_PATH attribute of a BGP route contains an AS loop, the BGP > > route should be excluded from the Phase 2 decision function. AS loop > > detection is done by scanning the full AS path (as specified in the > > AS_PATH attribute), and checking that the autonomous system number of > > the local system does not appear in the AS path. Operations of a BGP > > speaker that is configured to accept routes with its own autonomous > > system number in the AS path are outside the scope of this document. > > If we're checking for an AS loop here (in Phase 2) as opposed to > during the UPDATE message sanity checking, the route is already > received and accepted in the peer's Adj-RIB-In. Those implementations > I know don't even install such routes in the RIB... This is the text that the WG agreed on (see e-mail from John Scudder on Mon, 02 Dec 2002 10:54:45 EST). Also, see my response to your previous comment. > > 9.1.2.2 Breaking Ties (Phase 2) > ... > > Similarly, neighborAS(n) is a function which returns the neighbor > > AS from which the route was received. If the route is learned via > > IBGP, and the other IBGP speaker didn't originate the route, it is > > the neighbor AS from which the other IBGP speaker learned the > > route. If the route is learned via IBGP, and the other IBGP > > speaker originated the route, it is the local AS. > > What if the route is locally originated? Breaking ties has to do with the routes received from other BGP speakers, not with the routes locally originated. > > 9.1.4 Overlapping Routes > ... > > When overlapping routes are present in the same Adj-RIB-In, the more > > specific route takes precedence, in order from more specific to least > > specific. > > > Doesn't this happen at the packet forwarding stage? Yes, it does. But only if both routes are present in the FIB. I also think that this sentence isn't needed, so in the absence of any objections by June 10 I propose to remove it. > > The set of destinations described by the overlap represents a portion > > of the less specific route that is feasible, but is not currently in > > use. If a more specific route is later withdrawn, the set of desti- > > nations described by the overlap will still be reachable using the > > less specific route. > > > > If a BGP speaker receives overlapping routes, the Decision Process > > MUST consider both routes based on the configured acceptance policy. > > If both a less and a more specific route are accepted, then the Deci- > > sion Process MUST either install both the less and the more specific > > Install where? In Loc-RIB. I'll insert "in Loc-RIB" to make this clear. > > routes or it MUST aggregate the two routes and install the aggregated > > route, provided that both routes have the same value of the NEXT_HOP > > attribute. > > anyone really does the latter? Will find this from the implemenation report. > > If a BGP speaker chooses to aggregate, then it SHOULD either include > > all AS used to form the aggreagate in an AS_SET or add the > > ATOMIC_AGGREGATE attribute to the route. This attribute is now pri- > > marily informational. With the elimination of IP routing protocols > > that do not support classless routing and the elimination of router > > and host implementations that do not support classless routing, there > > is no longer a need to deaggregate. Routes SHOULD NOT be de-aggre- > > gated. A route that carries ATOMIC_AGGREGATE attribute in particular > > MUST NOT be de-aggregated. That is, the NLRI of this route can not be > > made more specific. Forwarding along such a route does not guarantee > > that IP packets will actually traverse only ASs listed in the AS_PATH > > attribute of the route. > > Since we don't do deaggregation any more, should we remove the > discussion about it completely and indicate in the "changes" section > that deaggregation has been deprecated? As I said before, I would prefer to keep the text on de-aggregation in. > > 9.2 Update-Send Process > ... > > When a BGP speaker receives an UPDATE message from an internal peer, > > the receiving BGP speaker SHALL NOT re-distribute the routing infor- > > mation contained in that UPDATE message to other internal peers, > > unless the speaker acts as a BGP Route Reflector [RFC2796]. > > Suggest to put "unless..." in brackets () to make it more apparent > that this is not a normative ref. Ok. > > 9.2.1.1 Frequency of Route Advertisement > > Since fast convergence is needed within an autonomous system, either > > (a) the MinRouteAdvertisementInterval used for internal peers SHOULD > > be shorter than the MinRouteAdvertisementInterval used for external > > peers, or (b) the procedure describe in this section SHOULD NOT apply > > for routes sent to internal peers. > > It sounded like MinRouteAdvertisementInterval was an architectural > constant, but now it sounds like either this is a timer that can be > assigned different settings or there are two constants: > MinRouteAdvIntIBGP and MinRouteAdvIntEBGP. There is a timer (MinRouteAdvertisementInterval) that can be assigned different settings. > > 9.2.2.2 Aggregating Routing Information > > > > Hmmm... I expected to see in this section some text talking about when > and how an aggregate would be announced, i.e., when an aggregate > prefix is configured, and more specific routes are present, the > aggregate is announced, when no specifics are left--withdraw the > aggregate. I haven't found anything on this topic... That is outside the scope of the *protocol* spec. See rfc1519 for more on this. > > 9.3 Route Selection Criteria > > > > Generally speaking, additional rules for comparing routes among sev- > > eral alternatives are outside the scope of this document. There are > > two exceptions: > > > > - If the local AS appears in the AS path of the new route being > > considered, then that new route can not be viewed as better than > > any other route (provided that the speaker is configured to accept > > such routes). If such a route were ever used, a routing loop could > > result. > > > > - In order to achieve successful distributed operation, only > > routes with a likelihood of stability can be chosen. Thus, an AS > > SHOULD avoid using unstable routes, and it SHOULD NOT make rapid > > spontaneous changes to its choice of route. Quantifying the terms > > "unstable" and "rapid" in the previous sentence will require expe- > > rience, but the principle is clear. > > Where does this (the second one) fit within and how does this affect > the route selection criteria? Routes that flap often can be "penalize" (e.g., route dampening). I'll add a pointer to the route dampening spec here. > > Care must be taken to ensure that BGP speakers in the same AS do not > > make inconsistent decisions. > > How? By means outside of the protocol. How about if I'll just remove this sentence ? > What does this mean for the implementor? > > > 9.4 Originating BGP routes > > > > A BGP speaker may originate BGP routes by injecting routing informa- > > tion acquired by some other means (e.g. via an IGP) into BGP. A BGP > > speaker that originates BGP routes assigns the degree of preference > > > > "assigns the degree of preference"... how do the implementations > really do that? E.g., via CLI. I'll add "(e.g., via CLI") after "assigns the degree of preference". > > 10 BGP Timers > ... > > The suggested default value for the MinRouteAdvertisementInterval is > > 30 seconds. > > This was described as a parameter, not a timer. Further, it was > earlier suggested that it should be shorter for iBGP than it is for > eBGP. I'd expect the document to specify the recommended value for > both. This is for eBGP. For iBGP the suggested value is 5 secs (I'll add this to the draft). > > IANA Considerations > ... > > All extensions to this protocol, including new message types and Path > > Attributes MUST only be made using the Standards Action process > > defined in [RFC2434]. > > This section should include the description of each registry that > needs to be created (if needed) and maintained by IANA, as well as the > allocation policy that is in the text already. Sure. Yakov. From rtg-dir-admin@ietf.org Tue May 27 11:34:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17011 for ; Tue, 27 May 2003 11:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KgRB-0005Sh-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 11:32:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KgRB-0005Sd-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 11:32:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFY0B28476; Tue, 27 May 2003 11:34:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RFXbB28450 for ; Tue, 27 May 2003 11:33: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 LAA17003 for ; Tue, 27 May 2003 11:33:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KgQk-0005SZ-00 for rtg-dir@ietf.org; Tue, 27 May 2003 11:32:02 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19KgQj-0005Rr-00 for rtg-dir@ietf.org; Tue, 27 May 2003 11:32:01 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h4RFWbJe056542; Tue, 27 May 2003 11:32:37 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h4RFWX8o056535; Tue, 27 May 2003 11:32:33 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h4RFWSN14074; Tue, 27 May 2003 11:32:28 -0400 (EDT) Date: Tue, 27 May 2003 11:32:28 -0400 From: Jeffrey Haas To: Russ White Cc: Alex Zinin , rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse Message-ID: <20030527113228.C13656@nexthop.com> References: <93972307354.20030522185606@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ruwhite@cisco.com on Fri, May 23, 2003 at 09:54:30PM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Fri, May 23, 2003 at 09:54:30PM -0400, Russ White wrote: > I'd probably draw the lines pretty wide, including policy and security > information, but I've not looked at the ppvpn stuff close enough to know if > I'd include that. I'm going to make it a point to try to read all of the current ppvpn documents sometime this week along with trying to make progress on the BGP MIB work. :-) Without having read the supporting documents, here are some observations. 1. We're distributing stuff in BGP that is *useful* to distribute in bgp. Namely, this is stuff that allows us to do inter-domain binding of VPLS networks. 2. We're using extended communities for this stuff again. Given their "optional" status and the knobs for tweaking them are pretty broad, it introduces some fragility into anything that uses them, but this is a broad argument and should be considered secondary. 3. We aren't passing around things that are IP reachability. However, we're passing around stuff that is associated with VPN reachability as defined by route distinguishers. Essentially, we seem to be doing the equivalent of "foreign key" work in sql. Its not directly associated, but is one step away. BGP cares about its best-path rules a bunch. Anything that goes in NLRI should care about it. This looks like it might not. (Again, I need to read the rest of the dox.) 4. The presence of TLV's in the NLRI is problematic. I don't know all of what is supposed to be there, but traditionally an NLRI is meant to convey "this *thing* is reachable". Even in 2547, the "thing" is a NLRI bound with a RD and label stack to reach that end-thing. The fact that the BGP Nexthop is used in 2547 to derive the LSP to reach the end-thing that is transmitted in the NLRI successfully leverages things and using extended communities for VPN membership makes sense. (The lack of useful documentation on how aggregation of extended community attributes in some situations seems like an interoperability accident waiting to happen, but the authors don't seem to care.) The one thing that is immediately referenced in the document that I've read (draft-kompella-ppvpn-vpls-02) is the relearn sequence number. This *immediately* implies an amount of churn that has very little to do with an "end-point thing" and is a property of it. Traditionally, that belongs in the BGP path attributes. I'm now wondering what else is being put in there. I have a gut reaction as to how "things should look", but I want to see the other dox before getting too preachy. > Russ -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Tue May 27 13:57:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21775 for ; Tue, 27 May 2003 13:57:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KigS-0006hR-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 13:56:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KigR-0006hO-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 13:56:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RHw1B07085; Tue, 27 May 2003 13:58:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RHvbB07067 for ; Tue, 27 May 2003 13: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 NAA21766 for ; Tue, 27 May 2003 13:57:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kig3-0006hI-00 for rtg-dir@ietf.org; Tue, 27 May 2003 13:55:59 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Kig2-0006hF-00 for rtg-dir@ietf.org; Tue, 27 May 2003 13:55:58 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19KihT-000GJI-00; Tue, 27 May 2003 17:57:27 +0000 Date: Tue, 27 May 2003 10:45:03 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <91313404381.20030527104503@psg.com> To: Jeffrey Haas CC: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse In-Reply-To: <20030527110903.A13656@nexthop.com> References: <93972307354.20030522185606@psg.com> <20030527110903.A13656@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff, I'm pretty sure it is the following draft: http://www.ietf.org/internet-drafts/draft-kompella-ppvpn-l2vpn-03.txt -- Alex http://www.psg.com/~zinin/ Tuesday, May 27, 2003, 8:09:03 AM, Jeffrey Haas wrote: > On Thu, May 22, 2003 at 06:56:06PM -0700, Alex Zinin wrote: >> draft-kompella-ppvpn-vpls-01.txt > Could someone tell me what draft the following reference is > supposed to refer to: > [ 4] Kompella, K., et al, "MPLS-based Layer 2 VPNs", work in > progress. > These drafts all seem to have the habit of referring to things > as "work in progress" without even a "draft-ietf-ppvpn-blah" From rtg-dir-admin@ietf.org Tue May 27 15:56:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28665 for ; Tue, 27 May 2003 15:56:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KkXe-0000X0-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 15:55:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KkXd-0000Ww-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 15:55:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RJv1B16621; Tue, 27 May 2003 15:57:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RJuhB16589 for ; Tue, 27 May 2003 15:56: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 PAA28645 for ; Tue, 27 May 2003 15:56:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KkXK-0000Wf-00 for rtg-dir@ietf.org; Tue, 27 May 2003 15:55:06 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19KkXJ-0000Wb-00 for rtg-dir@ietf.org; Tue, 27 May 2003 15:55:06 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19KkYj-0004Oz-00; Tue, 27 May 2003 19:56:33 +0000 Date: Tue, 27 May 2003 12:43:31 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <151320512392.20030527124331@psg.com> To: Tony Przygienda CC: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse In-Reply-To: <3ECF1A5F.2050401@net4u.ch> References: <93972307354.20030522185606@psg.com> <3ECE65A7.6050004@net4u.ch> <1959127013.20030523221346@psg.com> <3ECF1A5F.2050401@net4u.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tony, > sorry for the tannic truth ;-/ I'll be speaking in riddles again I fear. I appreciate you being honest, really. >>Some questions: >> >> Q1: what should we do if someone brings a complete BS to a WG >> (let's say someone decided that TCP over ISIS was a cool thing >> to do) and says it's coded and possibly deployed? >> > the moment somebody coded and deployed such a thing (given it's a > major vendor, whereas I define major as someone with decent customer > base that won't go chapter 11 tommorow, so it's a shifting target) > it's too late. That's the trick. Agreed that it is too late to (at least) usefully influence their code and its deployment. At that moment the IETF process also becomes quite painful, because the vendor will have a deep vested interest in that mechanism. At that point I see a couple potential outcomes: 1. The mechanism is considered by the WG as generally good, gets accepted with [possibly] minor tweaks, and goes STD track. No questions here. 2. The WG believes the problem needs to be solved, but there is a strong push back on the actual solution. A question here: Does it make sense for the WG to say "well, ok, you guys did your job, publish it as INFO so folks can work with you if needed, but let's work on the IETF STD spec where the WG will decide what's good", in other words, does "coded & deployed" mean it's too late for the IETF to work on this problem? 3. The WG is not interested in solving the problem. The proposal may again go INFO (assuming it documents a vendor's approach). > Ye shall have your ear on the ground and listen carefully before > stuff shows up and influence it then. How ? Well, command respect by > any of the organization managament approaches (a book on group > dynamics and organizational behavior 101 may do the trick) and learn > to put the right people into right places and pretty soon you'll > know stuff before drafts show up. Then a certain influence can be > taken. Agree completely. Good that you formulated this. They way I put it when I talk to WG chairs is "you should keep your eyes open and ears clean to make sure you know what folks want to do and that the right people talk to each other even before stuff comes to the WG." > If something shows up coded & deployed by major vendor, you only > very, very marginally influence the outcome these days. Basically > the 15secs attention span of sillicon valley has passed by then and > changing the code is a major pain. You remember that I'm sure. > If something is criminally stupid, then it should die by the virtue > of the process in any case, Do you mean the IETF process? Which part of it? > however I observe that IETF in last couple years had only a sketchy > record on that one. It's heretic to say here but in a sense I think > that the ATM Forum approach of voting was doing a better job in > producing good specs. However, good specs are not necessarily what > makes the technology successfull I learned. >>I'd say the direction is to avoid _under_specification, not to promote >>over-specification. It would also seem as somewhat orthogonal topic, >>but I am indeed interested in discussing this, so I'll start a >>separate thread on this. >> > ok, I think we agree in principle here but in terms of tactics we > butt-head most of the times. Looks like we're converging... Alex From rtg-dir-admin@ietf.org Tue May 27 16:02:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29094 for ; Tue, 27 May 2003 16:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KkdS-0000e9-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 16:01:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KkdR-0000e6-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 16:01:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RK31B16845; Tue, 27 May 2003 16:03:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RK2VB16821 for ; Tue, 27 May 2003 16:02: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 QAA29022 for ; Tue, 27 May 2003 16:02:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kkcw-0000cn-00 for rtg-dir@ietf.org; Tue, 27 May 2003 16:00:54 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Kkcv-0000cY-00 for rtg-dir@ietf.org; Tue, 27 May 2003 16:00:53 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19KkeK-0006WM-00; Tue, 27 May 2003 20:02:20 +0000 Date: Tue, 27 May 2003 12:49:17 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <10320858379.20030527124917@psg.com> To: Radia Perlman - Boston Center for Networking CC: rtg-dir@ietf.org Subject: Re: Meta: goals for IETF Routing area In-Reply-To: <200305242025.h4OKPV416406@sydney.East.Sun.COM> References: <200305242025.h4OKPV416406@sydney.East.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Radia, ... > So it's not just a matter of getting the designs sound and > the documentation comprehensible and complete. Maybe > we also need some sort of conformance hurdle, so that > there won't be widely deployed hacks that sort of work, > that interact badly with other deployed hacks that sort > of work. My impression is that the IETF has historically tried to avoid getting into the "interoperability/compliance testing" space. The only way it is touched upon in the process is by requiring the implementation and interop report when progressing specs along the STD track to ensure high quality. Cheers. Alex From rtg-dir-admin@ietf.org Tue May 27 16:08:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29352 for ; Tue, 27 May 2003 16:08:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KkjG-0000ix-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 16:07:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KkjG-0000it-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 16:07:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RK92B17969; Tue, 27 May 2003 16:09:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RK6tB17033 for ; Tue, 27 May 2003 16:06: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 QAA29308 for ; Tue, 27 May 2003 16:06:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KkhC-0000iG-00 for rtg-dir@ietf.org; Tue, 27 May 2003 16:05:18 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19KkhB-0000hp-00 for rtg-dir@ietf.org; Tue, 27 May 2003 16:05:18 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h4RK6K2Z064876; Tue, 27 May 2003 16:06:20 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h4RK6G8o064855; Tue, 27 May 2003 16:06:16 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h4RK6Bi16171; Tue, 27 May 2003 16:06:11 -0400 (EDT) Date: Tue, 27 May 2003 16:06:11 -0400 From: Jeffrey Haas To: Alex Zinin Cc: Tony Przygienda , rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse Message-ID: <20030527160611.I14247@nexthop.com> References: <93972307354.20030522185606@psg.com> <3ECE65A7.6050004@net4u.ch> <1959127013.20030523221346@psg.com> <3ECF1A5F.2050401@net4u.ch> <151320512392.20030527124331@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <151320512392.20030527124331@psg.com>; from zinin@psg.com on Tue, May 27, 2003 at 12:43:31PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Tue, May 27, 2003 at 12:43:31PM -0700, Alex Zinin wrote: > Agreed that it is too late to (at least) usefully influence their code > and its deployment. At that moment the IETF process also becomes quite > painful, because the vendor will have a deep vested interest in that > mechanism. At that point I see a couple potential outcomes: And really the only question comes of when its an existing mechanism that is being hijacked/overloaded. Then its up to whoever the custodian of that thing, whether it be protocol or routing protocol, to deal with it. Especially when its the big companies that do this. It argues to have spaces in our protocols for vendor-specific extension mechanisms, but it also argues to *not* have them there so that something that is vendor-specific but well-deployed doesn't sit in a funny spot in the protocol. All said and done, anything that is a well thought out and scalable extension to a routing protocol, no matter how clunky it "feels", is probably ok so long as it doesn't hamper other potential later extensions to a protocol. But it will take people *talking* to figure that out. Preferably before you have product that you can't change without huge compatability problems. -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Tue May 27 17:48:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03931 for ; Tue, 27 May 2003 17:48:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KmI0-0001vL-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 17:47:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KmI0-0001vG-00 for rtg-dir-archive@ietf.org; Tue, 27 May 2003 17:47:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RLn1B25980; Tue, 27 May 2003 17:49:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RLmeB25955 for ; Tue, 27 May 2003 17:48: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 RAA03924 for ; Tue, 27 May 2003 17:48:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KmHd-0001vD-00 for rtg-dir@ietf.org; Tue, 27 May 2003 17:47:01 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19KmHd-0001uu-00 for rtg-dir@ietf.org; Tue, 27 May 2003 17:47:01 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4RLm4FV028229; Tue, 27 May 2003 17:48:04 -0400 (EDT) Received: from russpc (rtp-vpn2-13.cisco.com [10.82.240.13]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA12471; Tue, 27 May 2003 17:48:03 -0400 (EDT) Date: Tue, 27 May 2003 17:48:03 -0400 (Eastern Daylight Time) From: Russ White Reply-To: Russ White To: Alex Zinin cc: rtg-dir@ietf.org Subject: Re: Meta: goals for IETF Routing area In-Reply-To: <18512211459.20030523230510@psg.com> Message-ID: References: <18512211459.20030523230510@psg.com> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > Here are some of the most basic statements I have in mind, by no > means complete, but roughly what I think: > > S1: The goal of the IETF process is to produce technical specifications > that can be used to develop multiple independent implementations > that can interoperate with each other. Agreed. > S2: One of the direct responsibilities of the WGs within the Routing > area is to ensure continuos operational status of the Internet > routing system by maintaining scalability and stability > characteristics of the existing routing protocols, as well as > developing new protocols, extensions, and bug fixes in a timely > manner. Agreed. > Corollaries from the above: > > C1: Specifications produced within the Routing area need to specify > enough details to ensure that an informed reader unfamiliar with > the specific subject of the document can write an implementation > that a) can interoperate with others and b) does not affect > the aspects described in S2 above. This is much harder--what do you mean by "an informed reader," and "enough details?" For instance, SPF operation. How should you sort the TENT? What sort of SPF should you use (there are other than djikstra, after all)? There are a lot of questions here that, if the reader is not informed about, you could clearly argue that they should be described to handle S2 above. But.... You are not just treading on implementation stuff here, you're also treading on the ability to improve the protocol through real world experiments. For instance, what if the OSPF specs said you would use Djikstra SPF, and someone wanted to try something different? Let's say this other implementation produces performance that is dramatically faster than other implementations. Should this implementation be called "nonstandard," because it doesn't use djkistra? There is an art in deciding where to draw the line, and it all depends on what you consider "a well informed implementor." Is this someone who's had x amount of years of school? Experience at a major implementor? Or, what other requirements would you name? I don't think it's all that easy to say. We should probably sway more towards examples of how things work, without making those examples normative. There's nothing to gain to the community, imho, in making things obtuse simply to make them obtuse. There's also nothing to gain to the community by specifying a lot of things. So, we need to balance, somehow. > C2: We (the routing community, including vendors, and users) need to > be able to conduct adequate review of proposals affecting the > Internet routing protocols so that we can filter out bad ideas, > fix bugs and improve the mechanisms by leveraging the collective > wisdom. Yes, and this is more difficult, on multiple fronts. For one, we all have a different view of who this "well informed implementor" dude (or gal) is. This means we all have different ideas of what needs to be documented, and what doesn't. Second, we all play the "balance game" of how to keep our competative edges for out company's, and how we work to grow the internet as a whole. Because, we have to face it, the more stable and faster routing is, the more attractive the internet, and networks in general, look for carrying various things, and thus, the more the internet will grow, and thus the larger market each of our companies will have to work in. You can either work to make the pie bigger, or work to make your piece of the pie bigger. There has to be a balance between these two. Some people are on one extreme (hey, the pie is going to get bigger on its own, so we should just snatch up as much of a piece as we can while the gettin's good), and others are on the other extreme (unless I publish my company's internal information, the pie wont' grow). I think we all know it's someplace in the middle, but the motiviations are different in big and little vendors, and even in big and little operators. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From rtg-dir-admin@ietf.org Wed May 28 03:43:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19915 for ; Wed, 28 May 2003 03:43:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KvYs-0007Ob-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 03:41:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KvYr-0007OX-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 03:41:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S7h1B11902; Wed, 28 May 2003 03:43:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S7g7B11871 for ; Wed, 28 May 2003 03:42: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 DAA19889 for ; Wed, 28 May 2003 03:42:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KvXy-0007O8-00 for rtg-dir@ietf.org; Wed, 28 May 2003 03:40:30 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19KvXx-0007O5-00 for rtg-dir@ietf.org; Wed, 28 May 2003 03:40:29 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19KvZM-000O1E-00; Wed, 28 May 2003 07:41:56 +0000 Date: Wed, 28 May 2003 00:41:38 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <148363598777.20030528004138@psg.com> To: Jeffrey Haas CC: Tony Przygienda , rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse In-Reply-To: <20030527160611.I14247@nexthop.com> References: <93972307354.20030522185606@psg.com> <3ECE65A7.6050004@net4u.ch> <1959127013.20030523221346@psg.com> <3ECF1A5F.2050401@net4u.ch> <151320512392.20030527124331@psg.com> <20030527160611.I14247@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tuesday, May 27, 2003, 1:06:11 PM, Jeffrey Haas wrote: > On Tue, May 27, 2003 at 12:43:31PM -0700, Alex Zinin wrote: >> Agreed that it is too late to (at least) usefully influence their code >> and its deployment. At that moment the IETF process also becomes quite >> painful, because the vendor will have a deep vested interest in that >> mechanism. At that point I see a couple potential outcomes: > And really the only question comes of when its an existing mechanism > that is being hijacked/overloaded. Not sure if I got it right--do you mean this is not applicable to a situation where a new protocol is being developed? > Then its up to whoever the > custodian of that thing, whether it be protocol or routing protocol, > to deal with it. Do you mean an IETF WG or a vendor who "feels" like owning the protocol for whatever reason? > Especially when its the big companies that do this. > It argues to have spaces in our protocols for vendor-specific > extension mechanisms, What do you see as arguments for this? > but it also argues to *not* have them there > so that something that is vendor-specific but well-deployed doesn't > sit in a funny spot in the protocol. So we had this discussion in the IESG and the feeling was that vendor-specific extensions, in the form of legitimate, non-experimental (i.e., not for lab-only use) mechanisms are rather problematic. The IETF don't get to review the specs, we don't see changes in security and protocol characteristics, etc. and the SPs can't make an informed decision. > All said and done, anything that is a well thought out and scalable > extension to a routing protocol, no matter how clunky it "feels", > is probably ok so long as it doesn't hamper other potential later > extensions to a protocol. But it will take people *talking* to > figure that out. Should an extension be "routing-related" or just any? I.e., if I come up with a well thought out proposal to distribute DNS records in BGP, would that be good? Alex > Preferably before you have product that you can't change without > huge compatability problems. From rtg-dir-admin@ietf.org Wed May 28 04:16:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20835 for ; Wed, 28 May 2003 04:16:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kw4o-0007bx-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 04:14:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Kw4n-0007bu-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 04:14:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S8G2B14373; Wed, 28 May 2003 04:16:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S8FeB14338 for ; Wed, 28 May 2003 04:15: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 EAA20826 for ; Wed, 28 May 2003 04:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kw4Q-0007bd-00 for rtg-dir@ietf.org; Wed, 28 May 2003 04:14:02 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Kw4P-0007bY-00 for rtg-dir@ietf.org; Wed, 28 May 2003 04:14:01 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19Kw5t-0002oS-00; Wed, 28 May 2003 08:15:33 +0000 Date: Wed, 28 May 2003 01:15:05 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <38365606394.20030528011505@psg.com> To: Russ White CC: rtg-dir@ietf.org Subject: Re: Meta: goals for IETF Routing area In-Reply-To: References: <18512211459.20030523230510@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Russ, >> Corollaries from the above: >> >> C1: Specifications produced within the Routing area need to specify >> enough details to ensure that an informed reader unfamiliar with >> the specific subject of the document can write an implementation >> that a) can interoperate with others and b) does not affect >> the aspects described in S2 above. > This is much harder--what do you mean by "an informed reader," I like Curtis'es definition: ...one possessing a thorough understanding of foundations of this work, including IP routing, TCP, TCP programming, and the referenced documents... > and "enough details?" Just enough, overspecification is not a goal. > For instance, SPF operation. How should you sort the TENT? What > sort of SPF should you use (there are other than djikstra, after all)? > There are a lot of questions here that, if the reader is not informed > about, you could clearly argue that they should be described to handle S2 > above. I think we had a good agreement on this during the discussion on the isis-admin-tags document--i.e., specify that next-hop calculation should be based on the SPT, and provide the description of a way to calculate it (e.g. Dijkstra) for informational purposes. The point here is that all implementations should end up with the same routes and next-hops. > But.... You are not just treading on implementation stuff here, you're also > treading on the ability to improve the protocol through real world > experiments. For instance, what if the OSPF specs said you would use > Djikstra SPF, and someone wanted to try something different? Let's say this > other implementation produces performance that is dramatically faster than > other implementations. Do you think the above approach would leave enough space for innovation? > Should this implementation be called "nonstandard," because it doesn't use > djkistra? Nope. > There is an art in deciding where to draw the line, and it all depends on > what you consider "a well informed implementor." Is this someone who's had > x amount of years of school? Experience at a major implementor? Or, what > other requirements would you name? > I don't think it's all that easy to say. We should probably sway more > towards examples of how things work, without making those examples > normative. Agree that examples are useful even if informative, especially in situations where there are potentially multiple ways of doing something and one doesn't want to/there's no reason to limit implementations to do it one way. On the other hand, just examples, without any normative text specifying the framework does not seem enough. > There's nothing to gain to the community, imho, in making things > obtuse simply to make them obtuse. There's also nothing to gain to the > community by specifying a lot of things. > So, we need to balance, somehow. Agreed. Would "just enough details" be a better wording choice? >> C2: We (the routing community, including vendors, and users) need to >> be able to conduct adequate review of proposals affecting the >> Internet routing protocols so that we can filter out bad ideas, >> fix bugs and improve the mechanisms by leveraging the collective >> wisdom. > Yes, and this is more difficult, on multiple fronts. For one, we all have a > different view of who this "well informed implementor" dude (or gal) is. > This means we all have different ideas of what needs to be documented, and > what doesn't. > Second, we all play the "balance game" of how to keep our competative edges > for out company's, and how we work to grow the internet as a whole. > Because, we have to face it, the more stable and faster routing is, the > more attractive the internet, and networks in general, look for carrying > various things, and thus, the more the internet will grow, and thus the > larger market each of our companies will have to work in. > You can either work to make the pie bigger, or work to make your piece of > the pie bigger. There has to be a balance between these two. Some people > are on one extreme (hey, the pie is going to get bigger on its own, so we > should just snatch up as much of a piece as we can while the gettin's > good), and others are on the other extreme (unless I publish my company's > internal information, the pie wont' grow). I think we all know it's > someplace in the middle, but the motiviations are different in big and > little vendors, and even in big and little operators. It seems that there should still be a way to agree on the criteria for what should be specified and what may be left out. Quick thoughts: If potential deviations of an implementation wrt a certain part of the spec can: a) affect interoperability with other new or existing implementations, OR b) affect characteristics of the distributed system (read: scalability and stability), OR c) affect the ability of the SPs to effectively deploy, configure, or troubleshoot the protocol then the spec should provide recommended behavior. Comments? Alex From rtg-dir-admin@ietf.org Wed May 28 07:05:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24746 for ; Wed, 28 May 2003 07:05:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KyjG-0000qT-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 07:04:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KyjF-0000qQ-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 07:04:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SB62B25664; Wed, 28 May 2003 07:06:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SB5MB25642 for ; Wed, 28 May 2003 07:05: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 HAA24736 for ; Wed, 28 May 2003 07:05:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kyia-0000qA-00 for rtg-dir@ietf.org; Wed, 28 May 2003 07:03:41 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19KyiZ-0000pv-00 for rtg-dir@ietf.org; Wed, 28 May 2003 07:03:40 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h4SB4jeU080372; Wed, 28 May 2003 07:04:45 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h4SB4f8o080365; Wed, 28 May 2003 07:04:41 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h4SB4as20092; Wed, 28 May 2003 07:04:36 -0400 (EDT) Date: Wed, 28 May 2003 07:04:36 -0400 From: Jeffrey Haas To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse Message-ID: <20030528070436.A20071@nexthop.com> References: <93972307354.20030522185606@psg.com> <3ECE65A7.6050004@net4u.ch> <1959127013.20030523221346@psg.com> <3ECF1A5F.2050401@net4u.ch> <151320512392.20030527124331@psg.com> <20030527160611.I14247@nexthop.com> <148363598777.20030528004138@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <148363598777.20030528004138@psg.com>; from zinin@psg.com on Wed, May 28, 2003 at 12:41:38AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Wed, May 28, 2003 at 12:41:38AM -0700, Alex Zinin wrote: > > And really the only question comes of when its an existing mechanism > > that is being hijacked/overloaded. > > Not sure if I got it right--do you mean this is not applicable > to a situation where a new protocol is being developed? Lets put it this way: If its a completely new protocol, let them do whatever they want. If it succeeds wildly, document it informationally so people can make compatibile implementations. The process of documenting it is enough to start shaking out interoperability issues and a second version of the protocol may fix brokenness in the first version. However, if its something that is overloading an existing mechanism, then there are people who already care. I'll be blunt here: No one would care about what is being done with VPLS or rfc2547 vpns if it didn't sit on top of BGP. Sure, *we* would since we're trying to help you as AD Get Things Done Right, but it wouldn't matter *in the same way*. What I see a bit of here is that BGP is an IETF protocol and thus is "owned" by the IETF community. However, it is also "owned" by the IDR working group, and these things that seem "unclean" about it are happening outside of IDR. Hence, there is some feeling of protocol hijack by another WG. The fact that one of the hijacking parties is Ye Ancient and Venerable (he'll kill me next IDR session I'm sure) author and editor of the specification in question doesn't change the fact that the WG feels some ownership over it. Then again, I may be channeling my own feelings in the matter and not those of the WG. Regardless of those feelings of hijack, this is the IETF. We can resolve the process issues at some later date or concurrently, but the real question for now, at least with regard to VPLS, is does this stuff make sense within the context of the protocol? Pedro made some interesting arguments to me privately. I need to digest them a bit. > > Especially when its the big companies that do this. > > > It argues to have spaces in our protocols for vendor-specific > > extension mechanisms, > > What do you see as arguments for this? If you're going to hijack, here's a private space to go off and do so without necessarily dragging the entire WG to hell with you. If your hell is pleasantly warm and we want to implement it too... > So we had this discussion in the IESG and the feeling was that > vendor-specific extensions, in the form of legitimate, > non-experimental (i.e., not for lab-only use) mechanisms are rather > problematic. Ya think? :-) > Should an extension be "routing-related" or just any? It depends on what it sits on. Thus, the argument is situational. > I.e., if I come up with a well thought out proposal to distribute > DNS records in BGP, would that be good? Or policy data in DNS? As I griped in IDR a while back, now I know how the DNS group feels about having its mechanisms hijacked. -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Wed May 28 12:31:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11010 for ; Wed, 28 May 2003 12:31:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L3nr-0004xi-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 12:29:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L3nr-0004xf-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 12:29:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SGV4B18756; Wed, 28 May 2003 12:31:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SGUIB18687 for ; Wed, 28 May 2003 12:30: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 MAA10977 for ; Wed, 28 May 2003 12:30:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L3n5-0004x7-00 for rtg-dir@ietf.org; Wed, 28 May 2003 12:28:39 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19L3n5-0004wh-00 for rtg-dir@ietf.org; Wed, 28 May 2003 12:28:39 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h4SGTh5Z010473; Wed, 28 May 2003 09:29:43 -0700 Date: Wed, 28 May 2003 09:29:43 -0700 From: David Meyer To: Alex Zinin Cc: Russ White , rtg-dir@ietf.org Subject: Re: Meta: goals for IETF Routing area Message-ID: <20030528092943.A10416@1-4-5.net> References: <18512211459.20030523230510@psg.com> <38365606394.20030528011505@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <38365606394.20030528011505@psg.com>; from zinin@psg.com on Wed, May 28, 2003 at 01:15:05AM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Alex/Russ/All, >> >> Corollaries from the above: >> >> >> >> C1: Specifications produced within the Routing area need to specify >> >> enough details to ensure that an informed reader unfamiliar with >> >> the specific subject of the document can write an implementation >> >> that a) can interoperate with others and b) does not affect >> >> the aspects described in S2 above. >> >> > This is much harder--what do you mean by "an informed reader," >> >> I like Curtis'es definition: >> >> ...one >> possessing a thorough understanding of foundations of this work, >> including IP routing, TCP, TCP programming, and the referenced >> documents... >> >> > and "enough details?" Unfortunately, "thorough understanding of foundations of this work" really doesn't add any information, as we would then need to define/understand what constitutes "thorough understanding of foundations...". As Russ said, this is *harder*. All of this being said, I don't have any better language here. >> Just enough, overspecification is not a goal. >> >> > For instance, SPF operation. How should you sort the TENT? What >> > sort of SPF should you use (there are other than djikstra, after all)? >> > There are a lot of questions here that, if the reader is not informed >> > about, you could clearly argue that they should be described to handle S2 >> > above. >> >> I think we had a good agreement on this during the discussion on the >> isis-admin-tags document--i.e., specify that next-hop calculation >> should be based on the SPT, and provide the description of a way >> to calculate it (e.g. Dijkstra) for informational purposes. The point >> here is that all implementations should end up with the same routes >> and next-hops. But why do we care how they computed it (for whatever value if "it") if they come out with the same (external) behavior? Isn't this is the on-the-wire issue: That is, what do we care what is "inside the box" if the implementation behaves according to spec? Does it really matter? In fact, specification at this level may cross the so-called vendor-differentiation/innovation-space line. >> > But.... You are not just treading on implementation stuff >> > here, you're also treading on the ability to improve the >> > protocol through real world experiments. For instance, what >> > if the OSPF specs said you would use Djikstra SPF, and >> > someone wanted to try something different? Let's say this >> > other implementation produces performance that is >> > dramatically faster than other implementations. >> >> Do you think the above approach would leave enough space for >> innovation? See my comment above. >> > Should this implementation be called "nonstandard," because it doesn't use >> > djkistra? >> >> Nope. Good. >> > There is an art in deciding where to draw the line, and it all depends on >> > what you consider "a well informed implementor." Is this someone who's had >> > x amount of years of school? Experience at a major implementor? Or, what >> > other requirements would you name? >> >> > I don't think it's all that easy to say. We should probably sway more >> > towards examples of how things work, without making those examples >> > normative. >> >> Agree that examples are useful even if informative, especially in >> situations where there are potentially multiple ways of doing >> something and one doesn't want to/there's no reason to limit >> implementations to do it one way. >> >> On the other hand, just examples, without any normative text >> specifying the framework does not seem enough. I agree with this. But perhaps we want to focus on (external-to-the-box) behavior rather than (internal-to-the-box) mechanism? >> > There's nothing to gain to the community, imho, in making things >> > obtuse simply to make them obtuse. There's also nothing to gain to the >> > community by specifying a lot of things. >> >> > So, we need to balance, somehow. >> >> Agreed. Would "just enough details" be a better wording choice? Again, this seems to be at least ambiguous (i.e., please define "just enough detail"). >> >> C2: We (the routing community, including vendors, and users) need to >> >> be able to conduct adequate review of proposals affecting the >> >> Internet routing protocols so that we can filter out bad ideas, >> >> fix bugs and improve the mechanisms by leveraging the collective >> >> wisdom. >> >> > Yes, and this is more difficult, on multiple fronts. For one, we all have a >> > different view of who this "well informed implementor" dude (or gal) is. >> > This means we all have different ideas of what needs to be documented, and >> > what doesn't. >> >> > Second, we all play the "balance game" of how to keep our competative edges >> > for out company's, and how we work to grow the internet as a whole. >> > Because, we have to face it, the more stable and faster routing is, the >> > more attractive the internet, and networks in general, look for carrying >> > various things, and thus, the more the internet will grow, and thus the >> > larger market each of our companies will have to work in. >> >> > You can either work to make the pie bigger, or work to make your piece of >> > the pie bigger. There has to be a balance between these two. Some people >> > are on one extreme (hey, the pie is going to get bigger on its own, so we >> > should just snatch up as much of a piece as we can while the gettin's >> > good), and others are on the other extreme (unless I publish my company's >> > internal information, the pie wont' grow). I think we all know it's >> > someplace in the middle, but the motiviations are different in big and >> > little vendors, and even in big and little operators. >> >> It seems that there should still be a way to agree on the criteria >> for what should be specified and what may be left out. Quick thoughts: >> >> If potential deviations of an implementation wrt >> a certain part of the spec can: >> >> a) affect interoperability with other new or existing >> implementations, OR Good. >> b) affect characteristics of the distributed system >> (read: scalability and stability), OR Good. >> c) affect the ability of the SPs to effectively deploy, >> configure, or troubleshoot the protocol This one is likely an artifact of something else (likely a) and b) above, at least). >> >> then the spec should provide recommended behavior. The provide the recommended external behavior, I would imagine. Dave From rtg-dir-admin@ietf.org Wed May 28 12:58:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11854 for ; Wed, 28 May 2003 12:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L4Es-0005Ax-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 12:57:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L4Es-0005Au-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 12:57:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SGx1B20777; Wed, 28 May 2003 12:59:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SGwWB20746 for ; Wed, 28 May 2003 12:58: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 MAA11829 for ; Wed, 28 May 2003 12:58:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L4EO-0005Ad-00 for rtg-dir@ietf.org; Wed, 28 May 2003 12:56:52 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19L4EN-0005Aa-00 for rtg-dir@ietf.org; Wed, 28 May 2003 12:56:51 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19L4Fp-000JWH-00; Wed, 28 May 2003 16:58:21 +0000 Date: Wed, 28 May 2003 09:58:04 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <134396985054.20030528095804@psg.com> To: Jeffrey Haas CC: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse In-Reply-To: <20030528070436.A20071@nexthop.com> References: <93972307354.20030522185606@psg.com> <3ECE65A7.6050004@net4u.ch> <1959127013.20030523221346@psg.com> <3ECF1A5F.2050401@net4u.ch> <151320512392.20030527124331@psg.com> <20030527160611.I14247@nexthop.com> <148363598777.20030528004138@psg.com> <20030528070436.A20071@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff- Thanks for being direct, this is what I'd like our conversations here to be. See below, pls. Wednesday, May 28, 2003, 4:04:36 AM, Jeffrey Haas wrote: > On Wed, May 28, 2003 at 12:41:38AM -0700, Alex Zinin wrote: >> > And really the only question comes of when its an existing mechanism >> > that is being hijacked/overloaded. >> >> Not sure if I got it right--do you mean this is not applicable >> to a situation where a new protocol is being developed? > Lets put it this way: > If its a completely new protocol, let them do whatever they want. > If it succeeds wildly, document it informationally so people can > make compatibile implementations. The process of documenting it is > enough to start shaking out interoperability issues and a second version > of the protocol may fix brokenness in the first version. Unless, of course, there is an interest within the IETF community sufficient to start an WG, where the protocol would be developed. In this case the spec would be sent to STD track > However, if its something that is overloading an existing mechanism, > then there are people who already care. Agreed. > I'll be blunt here: No one would care about what is being done with > VPLS or rfc2547 vpns if it didn't sit on top of BGP. Sure, *we* would > since we're trying to help you as AD Get Things Done Right, but it > wouldn't matter *in the same way*. Agreed > What I see a bit of here is that BGP is an IETF protocol and thus is > "owned" by the IETF community. However, it is also "owned" by the > IDR working group, and these things that seem "unclean" about it are > happening outside of IDR. Hence, there is some feeling of protocol > hijack by another WG. Agreed. In fact recently I've been pushing for making sure that protocol-specific mechanisms are owned by the protocol-specific WGs, and one of the things I was going to do is bring this document to IDR. What is still a question to me is the 2547bis spec. Essentially it also changes BGP. The right way would be to take that piece out of the spec and bring to IDR, but it has the potential of substantially delaying the spec and will be perceived as an attempt to stall this work, so I am leaning towards asking IDR to review the spec, but leaving it in PPVPN, with the caveat that this will be considered as an exception, not the rule... > The fact that one of the hijacking parties is Ye Ancient and Venerable > (he'll kill me next IDR session I'm sure) author and editor of the > specification in question doesn't change the fact that the WG feels > some ownership over it. Exactly. > Then again, I may be channeling my own feelings in the matter and not > those of the WG. No, I think you are not the only one who has this feeling. > Regardless of those feelings of hijack, this is the IETF. We can > resolve the process issues at some later date or concurrently, but the > real question for now, at least with regard to VPLS, is does this > stuff make sense within the context of the protocol? > Pedro made some interesting arguments to me privately. I need to > digest them a bit. OK, would be interesting to see what you think. ... >> I.e., if I come up with a well thought out proposal to distribute >> DNS records in BGP, would that be good? > Or policy data in DNS? > As I griped in IDR a while back, now I know how the DNS group feels > about having its mechanisms hijacked. At least here we have an opportunity to get it right (I mean bring it to the right WG). Alex From rtg-dir-admin@ietf.org Wed May 28 13:28:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12779 for ; Wed, 28 May 2003 13:28:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L4hw-0005QK-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 13:27:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L4hw-0005QH-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 13:27:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SHT1B23005; Wed, 28 May 2003 13:29:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SHSiB22989 for ; Wed, 28 May 2003 13:28: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 NAA12770 for ; Wed, 28 May 2003 13:28:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L4hc-0005Q6-00 for rtg-dir@ietf.org; Wed, 28 May 2003 13:27:04 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19L4hO-0005Q0-00 for rtg-dir@ietf.org; Wed, 28 May 2003 13:26:50 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19L4ik-000LhO-00; Wed, 28 May 2003 17:28:14 +0000 Date: Wed, 28 May 2003 10:27:48 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <147398769049.20030528102748@psg.com> To: David Meyer CC: Russ White , rtg-dir@ietf.org Subject: Re: Meta: goals for IETF Routing area In-Reply-To: <20030528092943.A10416@1-4-5.net> References: <18512211459.20030523230510@psg.com> <38365606394.20030528011505@psg.com> <20030528092943.A10416@1-4-5.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dave, >>> I like Curtis'es definition: >>> >>> ...one >>> possessing a thorough understanding of foundations of this work, >>> including IP routing, TCP, TCP programming, and the referenced >>> documents... >>> >>> > and "enough details?" > Unfortunately, "thorough understanding of foundations of > this work" really doesn't add any information, as we > would then need to define/understand what constitutes > "thorough understanding of foundations...". As Russ said, > this is *harder*. All of this being said, I don't have > any better language here. The way I look at it myself is: a) for a completely new protocol specification, the reader should know how IP in general and IP routing in particular work (i.e., the notions of a route, routing table, the packet forwarding process) b) for a protocol extension, add the base protocol specification to the list of prerequisites. The gray area is in how well/thorough understanding is, but I guess the main thing here is that you don't have to re-explain those ideas again, and can instead assume the reader has the knowledge and just include a ref in the spec. >>> Just enough, overspecification is not a goal. >>> >>> > For instance, SPF operation. How should you sort the TENT? What >>> > sort of SPF should you use (there are other than djikstra, after all)? >>> > There are a lot of questions here that, if the reader is not informed >>> > about, you could clearly argue that they should be described to handle S2 >>> > above. >>> >>> I think we had a good agreement on this during the discussion on the >>> isis-admin-tags document--i.e., specify that next-hop calculation >>> should be based on the SPT, and provide the description of a way >>> to calculate it (e.g. Dijkstra) for informational purposes. The point >>> here is that all implementations should end up with the same routes >>> and next-hops. > But why do we care how they computed it (for whatever > value if "it") We don't. Note "for informational purposes above" > if they come out with the same (external) > behavior? Isn't this is the on-the-wire issue: That is, > what do we care what is "inside the box" if the > implementation behaves according to spec? Does it really > matter? In fact, specification at this level may cross > the so-called vendor-differentiation/innovation-space line. I am pessimistic about the concept of specifying only what's on the wire. Clearly there are a number of node-local decisions (such as route calculation, LSP origination/refreshment rates) that affect the behavior of the distributed system. However, it is not the intent to get into the "how to implement" space, but rather make sure the specs contain sufficient details to setup the framework that guarantees interoperability and domain/Internet-wide behavior, yet leaving enough space for implementation creativity. >>> > But.... You are not just treading on implementation stuff >>> > here, you're also treading on the ability to improve the >>> > protocol through real world experiments. For instance, what >>> > if the OSPF specs said you would use Djikstra SPF, and >>> > someone wanted to try something different? Let's say this >>> > other implementation produces performance that is >>> > dramatically faster than other implementations. >>> >>> Do you think the above approach would leave enough space for >>> innovation? > See my comment above. >>> > Should this implementation be called "nonstandard," because it doesn't use >>> > djkistra? >>> >>> Nope. > Good. >>> > There is an art in deciding where to draw the line, and it all depends on >>> > what you consider "a well informed implementor." Is this someone who's had >>> > x amount of years of school? Experience at a major implementor? Or, what >>> > other requirements would you name? >>> >>> > I don't think it's all that easy to say. We should probably sway more >>> > towards examples of how things work, without making those examples >>> > normative. >>> >>> Agree that examples are useful even if informative, especially in >>> situations where there are potentially multiple ways of doing >>> something and one doesn't want to/there's no reason to limit >>> implementations to do it one way. >>> >>> On the other hand, just examples, without any normative text >>> specifying the framework does not seem enough. > I agree with this. But perhaps we want to focus on > (external-to-the-box) behavior rather than > (internal-to-the-box) mechanism? See above >>> > There's nothing to gain to the community, imho, in making things >>> > obtuse simply to make them obtuse. There's also nothing to gain to the >>> > community by specifying a lot of things. >>> >>> > So, we need to balance, somehow. >>> >>> Agreed. Would "just enough details" be a better wording choice? > Again, this seems to be at least ambiguous (i.e., please > define "just enough detail"). Let's see below. >>> It seems that there should still be a way to agree on the criteria >>> for what should be specified and what may be left out. Quick thoughts: >>> >>> If potential deviations of an implementation wrt >>> a certain part of the spec can: >>> >>> a) affect interoperability with other new or existing >>> implementations, OR > Good. >>> b) affect characteristics of the distributed system >>> (read: scalability and stability), OR > Good. >>> c) affect the ability of the SPs to effectively deploy, >>> configure, or troubleshoot the protocol > This one is likely an artifact of something else (likely > a) and b) above, at least). Could be, but not necessarily. Example: when I read the isis-admin-tags spec, it required conformant systems to be able to originate tag TLVs, but it did not require them to be able to act on those. In this situation, while the spec talks about controlling prefix distribution throughout the domain, conformance to such spec would not mean being able to actually control prefix distribution. In other words, if you asked a vendor a question "do you support RFC XXXX" and got a positive answer, it wouldn't mean you can use that implementation to actually control prefix distribution. >>> then the spec should provide recommended behavior. > The provide the recommended external behavior, I would > imagine. I think we should agree on the terminology here. I guess what you mean here is "externally visible behavior" vs "implementation specific". Note though that there's a class of node-local decisions that are externally visible, e.g., route calculation or LSA/LSP origination as I mentioned earlier. Alex From rtg-dir-admin@ietf.org Wed May 28 13:36:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13013 for ; Wed, 28 May 2003 13:36:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L4pd-0005SG-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 13:35:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L4pd-0005SD-00 for rtg-dir-archive@ietf.org; Wed, 28 May 2003 13:35:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SHb0B23261; Wed, 28 May 2003 13:37:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SHapB23217 for ; Wed, 28 May 2003 13:36: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 NAA13010 for ; Wed, 28 May 2003 13:36:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L4pT-0005S9-00 for rtg-dir@ietf.org; Wed, 28 May 2003 13:35:11 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19L4pS-0005Rz-00 for rtg-dir@ietf.org; Wed, 28 May 2003 13:35:10 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h4SHaKiL011772; Wed, 28 May 2003 10:36:20 -0700 Date: Wed, 28 May 2003 10:36:20 -0700 From: David Meyer To: Alex Zinin Cc: Russ White , rtg-dir@ietf.org Subject: Re: Meta: goals for IETF Routing area Message-ID: <20030528103620.A11763@1-4-5.net> References: <18512211459.20030523230510@psg.com> <38365606394.20030528011505@psg.com> <20030528092943.A10416@1-4-5.net> <147398769049.20030528102748@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <147398769049.20030528102748@psg.com>; from zinin@psg.com on Wed, May 28, 2003 at 10:27:48AM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , >> > The provide the recommended external behavior, I would >> > imagine. >> >> I think we should agree on the terminology here. I guess what you mean >> here is "externally visible behavior" vs "implementation specific". >> Note though that there's a class of node-local decisions that are >> externally visible, e.g., route calculation or LSA/LSP origination as >> I mentioned earlier. Yes, externally visable. But your point is well taken on the overall behavior of a distributed system. Dave From rtg-dir-admin@ietf.org Thu May 29 09:30:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02982 for ; Thu, 29 May 2003 09:30:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LNT7-0007A6-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 09:29:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LNT6-0007A2-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 09:29:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TDV0B21581; Thu, 29 May 2003 09:31:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TDUmB21526 for ; Thu, 29 May 2003 09:30: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 JAA02960 for ; Thu, 29 May 2003 09:30:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LNSt-00079t-00 for rtg-dir@ietf.org; Thu, 29 May 2003 09:29:07 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19LNSs-00079j-00 for rtg-dir@ietf.org; Thu, 29 May 2003 09:29:06 -0400 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4TDUB9N003370; Thu, 29 May 2003 06:30:11 -0700 (PDT) Received: from mshand-w2k.cisco.com (dhcp-rea-gp250-64-103-64-161.cisco.com [64.103.64.161]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA11751; Thu, 29 May 2003 14:30:10 +0100 (BST) Message-Id: <4.3.2.7.2.20030529113532.04abd228@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 May 2003 14:26:28 +0100 To: Alex Zinin From: mike shand Subject: Re: Fwd: Meta: routing protocol abuse Cc: rtg-dir@ietf.org In-Reply-To: <74441469820.20030528221929@psg.com> References: <93972307354.20030522185606@psg.com> <93972307354.20030522185606@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Alex, I'm going to answer this mostly in the context of IS-IS, since I have a stronger emotional attachment to that protocol:-) 1. Should a routing protocol be used as a general purpose reliable multicast transport system? Absolutely not, for two reasons. a) The routing protocol is designed to accommodate a certain volume of "database" traffic, and we are already in many cases pushing the scaling boundaries with genuine routing related data. Allowing the addition of unbounded and uncontrolled additional data (especially if the frequency of change is uncontrolled) could easily cause a breakdown of the routing infrastructure. b) The routing protocols are designed to operate "a priori", without any assistance from any other information. If you already have reasonably correct routing information, then it is possible to design "reliable multicast" systems which are much more efficient than those used by most routing protocols. 2. Where is the line between appropriate and inappropriate use? I would say that anything which was related to the computation of routing information (i.e. that is used to influence the FIB) is fair game, BUT (and note the shouting), it MUST be subject to analysis to show that the volume and frequency of the information will stay within reasonable bounds. It is easy to design bad routing protocols which don't scale and this mustn't be taken as carte blanche to allow anyone to do so. However, I accept that certain other information which is "related" to routing information, while it may not strictly be used to compute routes, is nevertheless better carried along with the routing information than elsewhere (especially if there are some synchronization issues involved). So like others, I don't think there can be a hard and fast rule. We already have instances where we have gone well beyond a strict interpretation, and I don't think we do any good by trying to reign these in. I think it has to be a case by case analysis, but in the case of obviously non-routing related usage, the onus is on the proposer to show:- a) why the use of a routing protocol is appropriate (and by inference, why some other mechanism isn't), and b) why this use cannot break the routing protocol. One possible (but rather unpalatable) work around to (b) would be to use a separate instance of the "routing protocol" isolated from the "real" route bearing one. 3. So what about adding 1 byte of information per router which changes only every year and has nothing to do with routing but would be really useful for something else? This is the difficult one. The temptation is strong, and the argument that it could cause any problems is hard to defend, but in an ideal world I would still say "don't do it". Pragmatism may dictate otherwise. 4. What about proprietary extensions? People will always make proprietary extensions for experimental purposes. Nothing will stop that. Historically we just choose an "unused" code point. e.g. 42 :-) Theoretically we may run into problems with two different vendors choosing the same number for unrelated extensions. Has this ever happened? I don't think so. Is it likely? Not very. Is it the end of the world if it does? You shouldn't really be running two different vendors' experimental code in your production network! Would "official" vendor specific extensions help? Marginal. But in any case, such extensions MUST NOT be considered "blessed" by the wg until they have been subject to a reviewed draft which MUST use "real" code points assigned by IANA (or in the case of ISIS whatever workaround we have in place). My personal 2c. Mike >Folks- > > /* > * The topic is quite sensitive, so handle with care please. I know some > * of you may have a conflict of interest given what your companies do, > * so I'd like to explicitly ask you to take your vendor hat off and put > * your IETF rtg-dir member hat on when you participate in this > * discussion (no offense). > */ > > The discussion about appropriate and inappropriate applications of IP > routing protocols has been going on for quite a while. The most > noticeable outburst of it could be correlated with appearance of 2547 > ;), however, this is not what I'd like us to talk about now. > > I'd like to draw your attention to the following draft-- > draft-kompella-ppvpn-vpls-01.txt > > --which proposes to use BGP for VPLS (L2 VPN service) discovery and > signaling. In particular, please pay attention to the way the > semantics of the NLRI field have been changed (section 3.2.1), and to > the fact the best path selection algorithm is not employed at all. > These two facts--loss of any addressing semantics, and loss of best > path selection--make me think that the proposed approach essentially > transforms BGP into what I call a "universal transport system." > > There two questions here: > > 1. Where is the line between appropriate and inappropriate use > of routing protocols in general, and BGP in particular (there > maybe different aspects between LS IGPs that have a pure > transport/flooding component, and BGP whose info relaying > behavior is tightly coupled with the best path selection algo.) > > 2. Does the draft in question cross this line? > > Before this sort of discussion starts in public, I'd like to hear > opinions (preferably with technical and architectural arguments) > of the folk whose technical judgement I trust. > > Thanks. > >-- >Alex >http://www.psg.com/~zinin/ > > >===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Thu May 29 15:30:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16476 for ; Thu, 29 May 2003 15:30:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LT4Z-0001o0-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 15:28:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LT4Z-0001nx-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 15:28:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TJU2B14954; Thu, 29 May 2003 15:30:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TJTtB14923 for ; Thu, 29 May 2003 15:29: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 PAA16473 for ; Thu, 29 May 2003 15:29:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LT4R-0001nq-00 for rtg-dir@ietf.org; Thu, 29 May 2003 15:28:15 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19LT4Q-0001nl-00 for rtg-dir@ietf.org; Thu, 29 May 2003 15:28:14 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19LT60-000NqO-00 for rtg-dir@ietf.org; Thu, 29 May 2003 19:29:52 +0000 Date: Thu, 29 May 2003 12:28:45 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <136492425890.20030529122845@psg.com> To: rtg-dir@ietf.org Subject: IESG soliciting comments on use of BGP for VPN Resent-from: Alex Zinin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-Id: Resent-Date: Thu, 29 May 2003 19:29:52 +0000 Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- The PPVPN WG has two WG documents that propose using BGP for VPN purposes: draft-ietf-ppvpn-bgpvpn-auto-05.txt describing how BGP can be used to disseminate VPN membership information draft-kompella-ppvpn-vpls-02.txt extending the above mechanism to also perform signaling for Virtual Private LAN Service (VPLS) The IESG is currently considering the following questions which we would like to solicit comments on: 1. What is the line between appropriate and inappropriate use of routing protocols in general, and BGP in particular. 2. Whether the specific approaches described in the documents above represent an appropriate use of BGP. 3. If the answer to question 2 above is negative, what alternative mechanisms could be used. Please send your comments on the questions above by June 12th (two weeks from today.) Thanks. -- Alex Zinin From rtg-dir-admin@ietf.org Thu May 29 16:57:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19301 for ; Thu, 29 May 2003 16:57:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LUQy-0002Rd-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 16:55:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LUQx-0002Ra-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 16:55:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TKvHB20876; Thu, 29 May 2003 16:57:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TKuHB20791 for ; Thu, 29 May 2003 16:56: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 QAA19263 for ; Thu, 29 May 2003 16:56:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LUQ0-0002Ql-00 for rtg-dir@ietf.org; Thu, 29 May 2003 16:54:36 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19LUPz-0002Qg-00 for rtg-dir@ietf.org; Thu, 29 May 2003 16:54:35 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19LURZ-0005JF-00 for rtg-dir@ietf.org; Thu, 29 May 2003 20:56:13 +0000 Date: Thu, 29 May 2003 13:54:40 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <137497580673.20030529135440@psg.com> To: rtg-dir@ietf.org Subject: Re: IESG soliciting comments on use of BGP for VPN In-Reply-To: <136492425890.20030529122845@psg.com> References: <136492425890.20030529122845@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit So, this is a more official version of the request for the same type of discussion. Same message has been sent to the ops-dir and IAB. Essentially this means that I will bring a summary of the discussion on this list back to the IESG (checking here first, of course) as the rtg-dir position. -- Alex http://www.psg.com/~zinin/ Thursday, May 29, 2003, 12:28:45 PM, Alex Zinin wrote: > Folks- > The PPVPN WG has two WG documents that propose using BGP for VPN > purposes: > draft-ietf-ppvpn-bgpvpn-auto-05.txt > describing how BGP can be used to disseminate VPN membership > information > draft-kompella-ppvpn-vpls-02.txt > extending the above mechanism to also perform signaling for > Virtual Private LAN Service (VPLS) > The IESG is currently considering the following questions which > we would like to solicit comments on: > 1. What is the line between appropriate and inappropriate use > of routing protocols in general, and BGP in particular. > 2. Whether the specific approaches described in the documents > above represent an appropriate use of BGP. > 3. If the answer to question 2 above is negative, what alternative > mechanisms could be used. > Please send your comments on the questions above by June 12th (two > weeks from today.) > Thanks. > -- > Alex Zinin From rtg-dir-admin@ietf.org Thu May 29 17:07:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20008 for ; Thu, 29 May 2003 17:07:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LUbN-0002cp-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 17:06:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LUbN-0002cm-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 17:06:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TL81B22743; Thu, 29 May 2003 17:08:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TL7tB22728 for ; Thu, 29 May 2003 17:07: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 RAA19995 for ; Thu, 29 May 2003 17:07:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LUbF-0002cX-00 for rtg-dir@ietf.org; Thu, 29 May 2003 17:06:13 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19LUbE-0002cN-00 for rtg-dir@ietf.org; Thu, 29 May 2003 17:06:12 -0400 Message-ID: From: Jeff Parker To: "'Alex Zinin'" Cc: "'rtg-dir@ietf.org'" Subject: RE: IESG soliciting comments on use of BGP for VPN Date: Thu, 29 May 2003 17:07:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > The IESG is currently considering the following questions which > we would like to solicit comments on: > > 1. What is the line between appropriate and inappropriate use > of routing protocols in general, and BGP in particular. > > 2. Whether the specific approaches described in the documents > above represent an appropriate use of BGP. > > 3. If the answer to question 2 above is negative, what alternative > mechanisms could be used. Mike Shand proposed an answer for #1. > Where is the line between appropriate and inappropriate use? > .. anything which was related to the computation of routing > information (i.e. that is used to influence the FIB) is fair > game, BUT (and note the shouting), it MUST be subject to > analysis to show that the volume and frequency of the > information will stay within reasonable bounds. The document draft-kompella-ppvpn-vpls-02.txt seems to meet both clauses: it affects forwarding, and given some assumptions about the rate of joining and leaving, the refresh rate could be kept in check. It does seem odd to be using NLRI that does not match the expectations of other BGP speakers. It seems to me that the actions when updating VLAN membership and merging routes introduces new behaviors which are not spelled out. In fact, there is a great deal of behavior that is not described here. A full solution would need to agree on the details of signaling the tunnels used to distribute data, decide on the encapsulation, etc. It isn't clear to me if this is described elsewhere, or if this is a private matter between consenting adults. Clearly, if a new use of an old protocol would A) Confuse other speakers of the protocol B) Require new behaviors of old speakers then the change would be harmful. I don't see evidence of either, and fall back to trusting the authors' supperior knowledge of the protocol. The draft suggests that this information would be exchanged within an AS. What would happen should this leaks to an E-BGP peer, who might have clients using similar NLRIs? Since there are multiple possible encapsulations and signaling protocols, this would be a fruitful source of misunderstandings. - jeff parker From rtg-dir-admin@ietf.org Thu May 29 17:23:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20553 for ; Thu, 29 May 2003 17:23:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LUqr-0002lc-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 17:22:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LUqq-0002lZ-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 17:22:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TLO1B23448; Thu, 29 May 2003 17:24:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TLNRB23410 for ; Thu, 29 May 2003 17:23: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 RAA20539; Thu, 29 May 2003 17:23:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LUqH-0002lJ-00; Thu, 29 May 2003 17:21:45 -0400 Received: from ms-smtp-01.southeast.rr.com ([24.93.67.82]) by ietf-mx with esmtp (Exim 4.12) id 19LUqG-0002lG-00; Thu, 29 May 2003 17:21:44 -0400 Received: from redback.com (rdu162-241-056.nc.rr.com [24.162.241.56]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h4TLHhd2006080; Thu, 29 May 2003 17:17:43 -0400 (EDT) Message-ID: <3ED679BC.4060307@redback.com> Date: Thu, 29 May 2003 17:21:00 -0400 From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Gredler CC: "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hannes, If we agree that having a single 32 bit and/or 64 bit tag is a good idea then perhaps we could change the wording of the draft to say that an implementation SHOULD only send and interpret a single tag and SHOULD ignore data past the first tag. This would allow the usage of multiple tags to be gracefully deprecated. If this isn't acceptable then can we can agree on a small finite/known number of tags with suggested usage? Thanks, Acee Hannes Gredler wrote: > pls, keep in mind that there is already code in production that allows > more than one tag; > > common use i have seen so far is > > tag #1 controls L2L1 leakage > tag #2 for informational purposes and points to the area of origin; > > /hannes > > On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote: > | RE: Comments on > | > | Acee, > | > | As the original goal was to create a capability similar to OSPF's route tag, > | it may be wise to drop this capability. On the otherhand, having multiple > | tags per route can provide more information about the route than a single > | tag. In this regard, the 32 bit tag operates more like a community, and the > | 64 bit tag operates like an extended community. From an implementation > | perspective, the same routines for matching and setting these fields should > | be similar to the community fields in BGP. > | > | I would like to solicit the WG for comments on which capability is most > | attractive. The goal is not to introduce too much bloat (is it too late for > | that?!) while still providing some flexibility. > | > | As soon as I receive any final comments, I will release the updated draft. > | > | Thanks for pointing out this critical piece! > | > | Regards, > | chris > | > | >-----Original Message----- > | >From: Acee Lindem [mailto:acee@redback.com] > | >Sent: Friday, May 23, 2003 1:50 PM > | >To: Acee Lindem > | >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area > | >Directorate > | >Subject: Re: Comments on > | > > | > > | >Christian, Stefano, Brad, > | > > | >The follow-up discussion on the necessity for both 32 bit and > | >64 bit tags raises the question as to whether or not it is > | >wise to allow an arbitrary number of tags to be advertised. > | > > | > This draft proposes 2 new "Administrative Tag" sub-TLVs > | >to be added > | > to TLV 135 and 235. These TLVs specify one or more > | >ordered, 32 or 64 > | > ~~~~~~~~~~~~~~~ > | > bit unsigned integers that may be associated with an IP prefix. > | > > | >However, the receiver need only use the first. > | > > | > An implementation may consider only one of the encoded > | >tags, in which > | > case the first encoded tag must be considered. A tag > | >value of zero > | > is reserved and should be treated as "no tag". > | > > | >IMHO, allowing an arbitrary number of tags affords more > | >potential for interoperability and deviant applications than > | >the 64 bit tag. > | > > | > > | > > | > > | > > | >Acee Lindem wrote: > | >> As a member of the routing area directorate, I have reviewed the > | >> subject document. Here are my comments: > | >> > | >> Comments: > | >> > | >> 1. The last sentence of the abstract doesn't make sense. > | >"Additionally, > | >> the information can be placed in LSPs that have TLVs as yet > | >> undefined, if this information is used to convey the same > | >> meaning in these future TLVs as it used in the currently defined > | >> TLVs". Suggested - "The administrative tag sub-TLVs may > | >be used with > | >> with future TLVs as long as their semantics are preserved." > | >> > | >> 2. Section 5.2 - The value of the type is wrong - it > | >should be 2 rather > | >> than 1. > | >> > | >> 3. Section 6 says the ordering of tags is not significant. > | >However, the > | >> previous sections (5.1 and 5.2) say that an > | >implementation may only > | >> consider the first tag. > | >> > | >> 4. Section 7 - List the requirements for receiving the new > | >Sub-TLVs in > | >> this compliance section as well (even if they were stated > | >> previously). > | >> > | >> 5. Section 8 - The example talks about R2 associating tag 110 with > | >> property > | >> A and prefix 1.1.1.0/24. Yet in Figure 1, prefix > | >1.1.1.0/24 with > | >> property > | >> A is adjacent to R1 (which applies to me that R1 originate the > | >> prefix). > | >> Please fix either the example or the figure. > | >> > | >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): > | >> > | >> 1. The abstract contains references. The documents should > | >be specified > | >> by name since the abstract can be excerpted. > | >> > | >> 2. Line 323 over 72 chars. > | >> > | >> Line 323 length is 74 > | >> Routing in IS-IS", > | >draft-ietf-isis-wg-multi-topology-03.txt, > | >> April > | >> > | >> 3. Pages 2, 3, 4, and 5 have over 58 lines. > | >> > | > > | > > | >-- > | >Acee > | > > > -- Acee From rtg-dir-admin@ietf.org Thu May 29 19:03:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26102 for ; Thu, 29 May 2003 19:03:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LWOj-0003sJ-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 19:01:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LWOj-0003sG-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 19:01:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TN31B30382; Thu, 29 May 2003 19:03:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TN21B30340 for ; Thu, 29 May 2003 19:02: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 TAA26047 for ; Thu, 29 May 2003 19:01:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LWNc-0003rM-00 for rtg-dir@ietf.org; Thu, 29 May 2003 19:00:16 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19LWNc-0003rJ-00 for rtg-dir@ietf.org; Thu, 29 May 2003 19:00:16 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19LWP8-000IbY-00; Thu, 29 May 2003 23:01:50 +0000 Date: Thu, 29 May 2003 15:59:38 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <136505079395.20030529155938@psg.com> To: mike shand CC: rtg-dir@ietf.org Subject: Re: : Meta: routing protocol abuse In-Reply-To: <4.3.2.7.2.20030529113532.04abd228@jaws.cisco.com> References: <93972307354.20030522185606@psg.com> <93972307354.20030522185606@psg.com> <4.3.2.7.2.20030529113532.04abd228@jaws.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mike, Thanks a lot for your thoughts! See below, please. > Alex, > I'm going to answer this mostly in the context of IS-IS, since I > have a stronger emotional attachment to that protocol:-) > 1. Should a routing protocol be used as a general purpose reliable > multicast transport system? Absolutely not, for two reasons. Agreed on all points. > 2. Where is the line between appropriate and inappropriate use? > I would say that anything which was related to the computation of routing > information (i.e. that is used to influence the FIB) is fair game, BUT (and > note the shouting), it MUST be subject to analysis to show that the volume > and frequency of the information will stay within reasonable bounds. It is > easy to design bad routing protocols which don't scale and this mustn't be > taken as carte blanche to allow anyone to do so. Agreed > However, I accept that certain other information which is "related" to > routing information, while it may not strictly be used to compute routes, > is nevertheless better carried along with the routing information than > elsewhere (especially if there are some synchronization issues involved). Agreed. MPLS TE attributes, strictly not needed for IP routing, would be a good example, I think. > So like others, I don't think there can be a hard and fast rule. We already > have instances where we have gone well beyond a strict interpretation, and > I don't think we do any good by trying to reign these in. I think it has to > be a case by case analysis, but in the case of obviously non-routing > related usage, the onus is on the proposer to show:- > a) why the use of a routing protocol is appropriate (and by inference, why > some other mechanism isn't), and > b) why this use cannot break the routing protocol. I like that. So, though we are not drawing a single line, we can identify three possible areas and associate actions with them: 1. Clearly routing-related: fair, but with due analysis by the right people (read: has to be done in appropriate IETF WGs) 2. Clearly non-routing related: Ouch! Please go to the appropriate WG and explain: a) what other alternatives you considered, and why you think using a routing protocol is appropriate and is the best choice here b) why is this not going to break the protocol and a routing domain 3. Not clear: Hmmm... go to the WG and see what people say One relevant point here is whether the mechanism in case 2 should be asked to become a WG document in the responsible WG, and what happens if the WG doesn't agree to take it. My opinion is that the default mode is that all protocol-specific mechanisms belong the protocol-specific WG. If the WG does not want to take it for technical reasons ("this smells") the proposal should be dumped. If the WG is technically OK, but does not want to put this on the charter, it's ok for WGs like PPVPN to host such work )provided that cross-reviews and mutual LCs are done). > One possible (but rather unpalatable) work around to (b) would be to use a > separate instance of the "routing protocol" isolated from the "real" route > bearing one. You got right to the point. This is exactly the argument that guys overloading BGP bring (though don't always specify). What is happening essentially is that BGP is transformed into a separate protocol, with completely different goals, though sharing message formats, neighbor machinery, and (clearly) the code. The argument is that INET-BGP sessions and blah-BGP sessions could be different. In fact, the two distributed systems would be separate. How do we deal with these cases? Thanks. Alex From rtg-dir-admin@ietf.org Thu May 29 19:17:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26896 for ; Thu, 29 May 2003 19:17:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LWcF-00046u-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 19:15:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LWcE-00046r-00 for rtg-dir-archive@ietf.org; Thu, 29 May 2003 19:15:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TNH1B31755; Thu, 29 May 2003 19:17:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TNG2B31731 for ; Thu, 29 May 2003 19:16: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 TAA26877 for ; Thu, 29 May 2003 19:15:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LWbG-00046e-00 for rtg-dir@ietf.org; Thu, 29 May 2003 19:14:22 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19LWbF-00046Z-00 for rtg-dir@ietf.org; Thu, 29 May 2003 19:14:21 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19LWcl-000KA9-00; Thu, 29 May 2003 23:15:55 +0000 Date: Thu, 29 May 2003 16:13:39 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <116505919974.20030529161339@psg.com> To: Jeff Parker CC: "'rtg-dir@ietf.org'" Subject: Re: IESG soliciting comments on use of BGP for VPN In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff, >> .. anything which was related to the computation of routing >> information (i.e. that is used to influence the FIB) is fair >> game, BUT (and note the shouting), it MUST be subject to >> analysis to show that the volume and frequency of the >> information will stay within reasonable bounds. > The document draft-kompella-ppvpn-vpls-02.txt seems to > meet both clauses: it affects forwarding, and given > some assumptions about the rate of joining and leaving, > the refresh rate could be kept in check. Hmmm... I got the impression that the mechanism described there carried exactly zero bit of routing information. It affects data plane, but not the IP routing data plane... > It does seem odd to be using NLRI that does not match > the expectations of other BGP speakers. It seems to > me that the actions when updating VLAN membership > and merging routes introduces new behaviors which > are not spelled out. Is the best-path algo even applicable there? I.e., aren't they interested in just the fact of the presence of a piece of info, rather than the best path to it? > In fact, there is a great deal > of behavior that is not described here. A full > solution would need to agree on the details of > signaling the tunnels used to distribute data, > decide on the encapsulation, etc. It isn't clear > to me if this is described elsewhere, or if this > is a private matter between consenting adults. The WG should be reusing tunnels defined in PWE3. > Clearly, if a new use of an old protocol would > A) Confuse other speakers of the protocol > B) Require new behaviors of old speakers > then the change would be harmful. I don't see > evidence of either, and Hmmm... what do you mean in B above? To explain a bit more, supporting new AFI/SAFI and/or BGP attributes always means modifying the BGP code. > fall back to trusting > the authors' supperior knowledge of the protocol. To what extent? Would you trust as much as not asking them to show up before IDR? Thanks. Alex > The draft suggests that this information would be > exchanged within an AS. What would happen should > this leaks to an E-BGP peer, who might have clients > using similar NLRIs? Since there are multiple possible > encapsulations and signaling protocols, this would > be a fruitful source of misunderstandings. > - jeff parker From rtg-dir-admin@ietf.org Fri May 30 10:26:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10243 for ; Fri, 30 May 2003 10:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lkop-00055w-00 for rtg-dir-archive@ietf.org; Fri, 30 May 2003 10:25:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Lkoo-00055s-00 for rtg-dir-archive@ietf.org; Fri, 30 May 2003 10:25:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UER1B07175; Fri, 30 May 2003 10:27:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UENdB07006 for ; Fri, 30 May 2003 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 KAA10116 for ; Fri, 30 May 2003 10:23:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LklW-00054z-00 for rtg-dir@ietf.org; Fri, 30 May 2003 10:21:54 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19LklV-00054o-00 for rtg-dir@ietf.org; Fri, 30 May 2003 10:21:53 -0400 Message-ID: From: Jeff Parker To: "'Alex Zinin'" Cc: "'rtg-dir@ietf.org'" Subject: RE: IESG soliciting comments on use of BGP for VPN Date: Fri, 30 May 2003 10:22:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > >> .. anything which was related to the computation of routing > >> information (i.e. that is used to influence the FIB) is fair > >> game, BUT (and note the shouting), it MUST be subject to > >> analysis to show that the volume and frequency of the > >> information will stay within reasonable bounds. > > > The document draft-kompella-ppvpn-vpls-02.txt seems to > > meet both clauses: it affects forwarding, and given > > some assumptions about the rate of joining and leaving, > > the refresh rate could be kept in check. > > Hmmm... I got the impression that the mechanism described there > carried exactly zero bit of routing information. It affects > data plane, but not the IP routing data plane... Let's go back to the proposed text. The issue may boil down to forwarding vs. routing. The question becomes: Is it proper to use BGP (or some other P) to exchange forwarding, rather than routing, info? I'm struggling with this, as there aren't good guidelines or examples on this. TE information in IGPs allows someone to make MPLS tunnels. Is this an outrage, or appropriate re-use of proven technology? If we look at the refresh rate, I think Mike's next point would raise a flag on this use, but we aren't laying on the tracks to stop MPLS. This is like refereering a basketball game. We have some rules, and we could blow the whistle often and call each infraction. But when that happens, we slow the game down so much that the athletes and the fans pick a different venue and continue the fast-paced game that they both enjoy. So we are trying to figure out realistic guidelines that allow innovation while protecting the stability and integrity of the current technology. Clearly A and B below are fouls. > The WG should be reusing tunnels defined in PWE3. But late binding on the choice of tunnels is a savvy political move. > > Clearly, if a new use of an old protocol would > > > A) Confuse other speakers of the protocol > > B) Require new behaviors of old speakers > > > then the change would be harmful. I don't see > > evidence of either, and > > Hmmm... what do you mean in B above? To explain a bit more, supporting > new AFI/SAFI and/or BGP attributes always means modifying the BGP > code. Well, it is simpler than it may look. A protocol that allows old implementations to co-exist, without understanding the new info, is less harmful that a protocol which requires new behavior of old implementations. - jeff parker From rtg-dir-admin@ietf.org Fri May 30 18:31:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01834 for ; Fri, 30 May 2003 18:31:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LsNa-0002EM-00 for rtg-dir-archive@ietf.org; Fri, 30 May 2003 18:29:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LsNa-0002EJ-00 for rtg-dir-archive@ietf.org; Fri, 30 May 2003 18:29:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UMVPB12425; Fri, 30 May 2003 18:31:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UMU1B12294 for ; Fri, 30 May 2003 18:30: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 SAA01793; Fri, 30 May 2003 18:29:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LsMB-0002Do-00; Fri, 30 May 2003 18:28:15 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19LsM9-0002DL-00; Fri, 30 May 2003 18:28:13 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h4UMT3f11604; Sat, 31 May 2003 00:29:03 +0200 Date: Sat, 31 May 2003 00:29:03 +0200 From: Hannes Gredler To: Acee Lindem Cc: "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on Message-ID: <20030530222903.GA11581@juniper.net> References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ED679BC.4060307@redback.com> User-Agent: Mutt/1.3.28i Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , acee, our implementation currently support two tags and we pass it on in a ordered way for internal policy-processing e.g. first tag found is copied to the variable "tag" and the second tag is copied to the variable "tag2"; both variables can be matched against in our internal policy processing language; and thats IMHO the only place where the draft needs to be more specific: how an implementation [order, etc.] maps IS-IS-tags to match-clauses in the local policy processor; i am unsure about the ordering and number of supported tags of other implementations; stefano, can you shed some light ? --- SHOULD is IMO a bit too strong wording, i'd be happy with something like "MAY have more than one tag" /hannes On Thu, May 29, 2003 at 05:21:00PM -0400, Acee Lindem wrote: | Hannes, | | If we agree that having a single 32 bit and/or 64 bit tag is a | good idea then perhaps we could change the wording of the draft to | say that an implementation SHOULD only send and interpret a single | tag and SHOULD ignore data past the first tag. This would allow | the usage of multiple tags to be gracefully deprecated. | | If this isn't acceptable then can we can agree on a small | finite/known number of tags with suggested usage? | | Thanks, | Acee | | Hannes Gredler wrote: | >pls, keep in mind that there is already code in production that allows | >more than one tag; | > | >common use i have seen so far is | > | >tag #1 controls L2L1 leakage | >tag #2 for informational purposes and points to the area of origin; | > | >/hannes | > | >On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote: | >| RE: Comments on | >| | >| Acee, | >| | >| As the original goal was to create a capability similar to OSPF's route | >tag, | >| it may be wise to drop this capability. On the otherhand, having | >multiple | >| tags per route can provide more information about the route than a single | >| tag. In this regard, the 32 bit tag operates more like a community, and | >the | >| 64 bit tag operates like an extended community. From an implementation | >| perspective, the same routines for matching and setting these fields | >should | >| be similar to the community fields in BGP. | >| | >| I would like to solicit the WG for comments on which capability is most | >| attractive. The goal is not to introduce too much bloat (is it too late | >for | >| that?!) while still providing some flexibility. | >| | >| As soon as I receive any final comments, I will release the updated | >draft. | >| | >| Thanks for pointing out this critical piece! | >| | >| Regards, | >| chris | >| | >| >-----Original Message----- | >| >From: Acee Lindem [mailto:acee@redback.com] | >| >Sent: Friday, May 23, 2003 1:50 PM | >| >To: Acee Lindem | >| >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area | >| >Directorate | >| >Subject: Re: Comments on | >| > | >| > | >| >Christian, Stefano, Brad, | >| > | >| >The follow-up discussion on the necessity for both 32 bit and | >| >64 bit tags raises the question as to whether or not it is | >| >wise to allow an arbitrary number of tags to be advertised. | >| > | >| > This draft proposes 2 new "Administrative Tag" sub-TLVs | >| >to be added | >| > to TLV 135 and 235. These TLVs specify one or more | >| >ordered, 32 or 64 | >| > ~~~~~~~~~~~~~~~ | >| > bit unsigned integers that may be associated with an IP prefix. | >| > | >| >However, the receiver need only use the first. | >| > | >| > An implementation may consider only one of the encoded | >| >tags, in which | >| > case the first encoded tag must be considered. A tag | >| >value of zero | >| > is reserved and should be treated as "no tag". | >| > | >| >IMHO, allowing an arbitrary number of tags affords more | >| >potential for interoperability and deviant applications than | >| >the 64 bit tag. | >| > | >| > | >| > | >| > | >| > | >| >Acee Lindem wrote: | >| >> As a member of the routing area directorate, I have reviewed the | >| >> subject document. Here are my comments: | >| >> | >| >> Comments: | >| >> | >| >> 1. The last sentence of the abstract doesn't make sense. | >| >"Additionally, | >| >> the information can be placed in LSPs that have TLVs as yet | >| >> undefined, if this information is used to convey the same | >| >> meaning in these future TLVs as it used in the currently defined | >| >> TLVs". Suggested - "The administrative tag sub-TLVs may | >| >be used with | >| >> with future TLVs as long as their semantics are preserved." | >| >> | >| >> 2. Section 5.2 - The value of the type is wrong - it | >| >should be 2 rather | >| >> than 1. | >| >> | >| >> 3. Section 6 says the ordering of tags is not significant. | >| >However, the | >| >> previous sections (5.1 and 5.2) say that an | >| >implementation may only | >| >> consider the first tag. | >| >> | >| >> 4. Section 7 - List the requirements for receiving the new | >| >Sub-TLVs in | >| >> this compliance section as well (even if they were stated | >| >> previously). | >| >> | >| >> 5. Section 8 - The example talks about R2 associating tag 110 with | >| >> property | >| >> A and prefix 1.1.1.0/24. Yet in Figure 1, prefix | >| >1.1.1.0/24 with | >| >> property | >| >> A is adjacent to R1 (which applies to me that R1 originate the | >| >> prefix). | >| >> Please fix either the example or the figure. | >| >> | >| >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): | >| >> | >| >> 1. The abstract contains references. The documents should | >| >be specified | >| >> by name since the abstract can be excerpted. | >| >> | >| >> 2. Line 323 over 72 chars. | >| >> | >| >> Line 323 length is 74 | >| >> Routing in IS-IS", | >| >draft-ietf-isis-wg-multi-topology-03.txt, | >| >> April | >| >> | >| >> 3. Pages 2, 3, 4, and 5 have over 58 lines. | >| >> | >| > | >| > | >| >-- | >| >Acee From rtg-dir-admin@ietf.org Fri May 30 23:10:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09661 for ; Fri, 30 May 2003 23:10:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LwkA-0004RV-00 for rtg-dir-archive@ietf.org; Fri, 30 May 2003 23:09:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Lwk9-0004RS-00 for rtg-dir-archive@ietf.org; Fri, 30 May 2003 23:09:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V3B2B30484; Fri, 30 May 2003 23:11:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V3ApB30469 for ; Fri, 30 May 2003 23:10: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 XAA09658 for ; Fri, 30 May 2003 23:10:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lwjw-0004RP-00 for rtg-dir@ietf.org; Fri, 30 May 2003 23:09:04 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Lwjw-0004RM-00 for rtg-dir@ietf.org; Fri, 30 May 2003 23:09:04 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19LwlY-000Drf-00 for rtg-dir@ietf.org; Sat, 31 May 2003 03:10:44 +0000 Date: Fri, 30 May 2003 20:08:18 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1606398955.20030530200818@psg.com> To: rtg-dir@ietf.org Subject: Review: draft-ietf-ospf-hitless-restart-07.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I'm starting AD-review for the OSPF graceful restart draft. Please send your comments by next Friday. Token holders: Tony P., Radia. Please confirm. Thanks. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Sat May 31 06:02:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28136 for ; Sat, 31 May 2003 06:02:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M3AQ-0006La-00 for rtg-dir-archive@ietf.org; Sat, 31 May 2003 06:00:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19M3AP-0006LX-00 for rtg-dir-archive@ietf.org; Sat, 31 May 2003 06:00:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VA2YB01601; Sat, 31 May 2003 06:02:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VA1PB01537 for ; Sat, 31 May 2003 06:01: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 GAA28107; Sat, 31 May 2003 06:01:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M39H-0006LE-00; Sat, 31 May 2003 05:59:39 -0400 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19M39G-0006L3-00; Sat, 31 May 2003 05:59:38 -0400 Received: from SPREVIDI-W2K1.cisco.com ([10.49.250.97]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h4VA0dR11890; Sat, 31 May 2003 12:00:40 +0200 (CEST) Message-Id: <4.3.2.7.2.20030531114157.01a3d2e0@strange-brew.cisco.com> X-Sender: sprevidi@strange-brew.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 31 May 2003 12:00:37 +0200 To: Hannes Gredler From: stefano previdi Subject: Re: [Isis-wg] RE: Comments on Cc: Acee Lindem , "Martin, Christian" , Brad Neal , Routing Area Directorate , isis-wg@ietf.org In-Reply-To: <20030530222903.GA11581@juniper.net> References: <3ED679BC.4060307@redback.com> <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , At 12:29 AM 5/31/2003, Hannes Gredler wrote: >acee, > >our implementation currently support two tags > and we pass it on in a ordered way for > internal policy-processing e.g. first tag found is copied > to the variable "tag" and the second tag is > copied to the variable "tag2"; both variables can be > matched against in our internal policy processing > language; > > and thats IMHO the only place > where the draft needs to be more specific: > how an implementation [order, etc.] maps IS-IS-tags > to match-clauses in the local policy processor; > >i am unsure about the ordering and number of supported tags >of other implementations; > stefano, can you shed some light ? I have no specific requirement on this matter... as long as an applicatin is considered compliant when handling the first encountered tag. s. >--- > >SHOULD is IMO a bit too strong wording, i'd be happy >with something like "MAY have more than one tag" > >/hannes > >On Thu, May 29, 2003 at 05:21:00PM -0400, Acee Lindem wrote: >| Hannes, >| >| If we agree that having a single 32 bit and/or 64 bit tag is a >| good idea then perhaps we could change the wording of the draft to >| say that an implementation SHOULD only send and interpret a single >| tag and SHOULD ignore data past the first tag. This would allow >| the usage of multiple tags to be gracefully deprecated. >| >| If this isn't acceptable then can we can agree on a small >| finite/known number of tags with suggested usage? >| >| Thanks, >| Acee >| >| Hannes Gredler wrote: >| >pls, keep in mind that there is already code in production that allows >| >more than one tag; >| > >| >common use i have seen so far is >| > >| >tag #1 controls L2L1 leakage >| >tag #2 for informational purposes and points to the area of origin; >| > >| >/hannes >| > >| >On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote: >| >| RE: Comments on >| >| >| >| Acee, >| >| >| >| As the original goal was to create a capability similar to OSPF's route >| >tag, >| >| it may be wise to drop this capability. On the otherhand, having >| >multiple >| >| tags per route can provide more information about the route than a single >| >| tag. In this regard, the 32 bit tag operates more like a community, and >| >the >| >| 64 bit tag operates like an extended community. From an implementation >| >| perspective, the same routines for matching and setting these fields >| >should >| >| be similar to the community fields in BGP. >| >| >| >| I would like to solicit the WG for comments on which capability is most >| >| attractive. The goal is not to introduce too much bloat (is it too late >| >for >| >| that?!) while still providing some flexibility. >| >| >| >| As soon as I receive any final comments, I will release the updated >| >draft. >| >| >| >| Thanks for pointing out this critical piece! >| >| >| >| Regards, >| >| chris >| >| >| >| >-----Original Message----- >| >| >From: Acee Lindem [mailto:acee@redback.com] >| >| >Sent: Friday, May 23, 2003 1:50 PM >| >| >To: Acee Lindem >| >| >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area >| >| >Directorate >| >| >Subject: Re: Comments on >| >| > >| >| > >| >| >Christian, Stefano, Brad, >| >| > >| >| >The follow-up discussion on the necessity for both 32 bit and >| >| >64 bit tags raises the question as to whether or not it is >| >| >wise to allow an arbitrary number of tags to be advertised. >| >| > >| >| > This draft proposes 2 new "Administrative Tag" sub-TLVs >| >| >to be added >| >| > to TLV 135 and 235. These TLVs specify one or more >| >| >ordered, 32 or 64 >| >| > ~~~~~~~~~~~~~~~ >| >| > bit unsigned integers that may be associated with an IP prefix. >| >| > >| >| >However, the receiver need only use the first. >| >| > >| >| > An implementation may consider only one of the encoded >| >| >tags, in which >| >| > case the first encoded tag must be considered. A tag >| >| >value of zero >| >| > is reserved and should be treated as "no tag". >| >| > >| >| >IMHO, allowing an arbitrary number of tags affords more >| >| >potential for interoperability and deviant applications than >| >| >the 64 bit tag. >| >| > >| >| > >| >| > >| >| > >| >| > >| >| >Acee Lindem wrote: >| >| >> As a member of the routing area directorate, I have reviewed the >| >| >> subject document. Here are my comments: >| >| >> >| >| >> Comments: >| >| >> >| >| >> 1. The last sentence of the abstract doesn't make sense. >| >| >"Additionally, >| >| >> the information can be placed in LSPs that have TLVs as yet >| >| >> undefined, if this information is used to convey the same >| >| >> meaning in these future TLVs as it used in the currently defined >| >| >> TLVs". Suggested - "The administrative tag sub-TLVs may >| >| >be used with >| >| >> with future TLVs as long as their semantics are preserved." >| >| >> >| >| >> 2. Section 5.2 - The value of the type is wrong - it >| >| >should be 2 rather >| >| >> than 1. >| >| >> >| >| >> 3. Section 6 says the ordering of tags is not significant. >| >| >However, the >| >| >> previous sections (5.1 and 5.2) say that an >| >| >implementation may only >| >| >> consider the first tag. >| >| >> >| >| >> 4. Section 7 - List the requirements for receiving the new >| >| >Sub-TLVs in >| >| >> this compliance section as well (even if they were stated >| >| >> previously). >| >| >> >| >| >> 5. Section 8 - The example talks about R2 associating tag 110 with >| >| >> property >| >| >> A and prefix 1.1.1.0/24. Yet in Figure 1, prefix >| >| >1.1.1.0/24 with >| >| >> property >| >| >> A is adjacent to R1 (which applies to me that R1 originate the >| >| >> prefix). >| >| >> Please fix either the example or the figure. >| >| >> >| >| >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): >| >| >> >| >| >> 1. The abstract contains references. The documents should >| >| >be specified >| >| >> by name since the abstract can be excerpted. >| >| >> >| >| >> 2. Line 323 over 72 chars. >| >| >> >| >| >> Line 323 length is 74 >| >| >> Routing in IS-IS", >| >| >draft-ietf-isis-wg-multi-topology-03.txt, >| >| >> April >| >| >> >| >| >> 3. Pages 2, 3, 4, and 5 have over 58 lines. >| >| >> >| >| > >| >| > >| >| >-- >| >| >Acee >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg From rtg-dir-admin@ietf.org Sun Jun 1 06:03:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03645 for ; Sun, 1 Jun 2003 06:03:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MPfL-00059B-00 for rtg-dir-archive@ietf.org; Sun, 01 Jun 2003 06:02:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MPfL-000597-00 for rtg-dir-archive@ietf.org; Sun, 01 Jun 2003 06:02:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51A41B01544; Sun, 1 Jun 2003 06:04:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51A3RB01519 for ; Sun, 1 Jun 2003 06:03: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 GAA03637; Sun, 1 Jun 2003 06:03:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MPel-00058x-00; Sun, 01 Jun 2003 06:01:39 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19MPek-00058q-00; Sun, 01 Jun 2003 06:01:38 -0400 Received: from net4u.ch (zux006-013-060.adsl.green.ch [81.6.13.60]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h51A3xf1014092; Sun, 1 Jun 2003 12:04:00 +0200 Message-ID: <3ED9CF5A.7010306@net4u.ch> Date: Sun, 01 Jun 2003 12:03:06 +0200 From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Acee Lindem CC: Hannes Gredler , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Acee Lindem wrote: > Hannes, > > If we agree that having a single 32 bit and/or 64 bit tag is a > good idea then perhaps we could change the wording of the draft to > say that an implementation SHOULD only send and interpret a single > tag and SHOULD ignore data past the first tag. This would allow > the usage of multiple tags to be gracefully deprecated. > > If this isn't acceptable then can we can agree on a small > finite/known number of tags with suggested usage? So, I watched for a while Alex and now Acee trying to influence the direction of this thing (after a last call funny enough) and I definitely do _NOT_ like the direction this is going. I have an understanding for 'exact specification' and 'understanding what the tags are doing' and 'we don't want 64 and 32 bits in place' __BUT__ 1) Slashing the whole thing to things like 1 tag only and squeezing it in size may feel good in terms of specification but it will probably make it as flexible and useful as the OSPF tag, namely completely useless. Just look at the unnatural contortions of RFC 1994. 2) I am lacking to follow the arguments here why multiple tags are so harmfull, why we have to know _exactly_ what every tag means and why the 32 and 64 bit tags together are such a big issue. The only ones I saw were basically 'it may blackhole routes or lead to problems when misconfiguration or implementaion errors occur'. Well, guess what, that's true for almost any RFC that ends up implenented in a screwy way. ISIS is a small implementor's community and we do not have to build specs in a way that every kid hacking Linux can implement it perfectly without having written a protocol in their life before. Therefore, I would encourage the implementors to think whether they want to end up in an OSPF-like tag corset or they want to preserve the flexibility of having multiple tags that can be used in a global or local fashion (global shall necessitate a description for interop-purposes, probaby 2547 extcomm being carried around would be such a thing) or otheriwse for all kind of nice local/proprietary things. BGP extscomms are already used in such way couple of nice & smart ways (I won't go into d3etails to protect the usually suspect vendors ;-) Some of those mechanisms could be used for ISIS to e.g. accelerate convergence on routers supporting these extensions. So, if implementors feel strongly here, please push back on all that 'we'll make it soo much nicer' tweaking and let's try to get this draft out in some decent time rather than the usual 3-infinity years it takes an ISIS RFC to be issued. I would strongly encourage keeping multiple, ordered tags and the draft not touching on their application. I would also encourage a 32 and a 64 bit tag, both being independent address spaces. It's not ideal but what's the point redoing stuff in the field just so the encoding is tad nicer? I would encourage a draft on how the 2547 stuff is being sloshed around using tags. And I think we added a paragraph that when the route selection supresses a route based on a tag we may end up with a blackhole. thanks -- tony > > > Thanks, > Acee > > Hannes Gredler wrote: > >> pls, keep in mind that there is already code in production that allows >> more than one tag; >> >> common use i have seen so far is >> >> tag #1 controls L2L1 leakage >> tag #2 for informational purposes and points to the area of origin; >> >> /hannes >> >> On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote: >> | RE: Comments on >> | | Acee, >> | | As the original goal was to create a capability similar to OSPF's >> route tag, >> | it may be wise to drop this capability. On the otherhand, having >> multiple >> | tags per route can provide more information about the route than a >> single >> | tag. In this regard, the 32 bit tag operates more like a >> community, and the >> | 64 bit tag operates like an extended community. From an >> implementation >> | perspective, the same routines for matching and setting these >> fields should >> | be similar to the community fields in BGP. >> | | I would like to solicit the WG for comments on which capability >> is most >> | attractive. The goal is not to introduce too much bloat (is it too >> late for >> | that?!) while still providing some flexibility. >> | | As soon as I receive any final comments, I will release the >> updated draft. >> | | Thanks for pointing out this critical piece! >> | | Regards, >> | chris >> | | >-----Original Message----- >> | >From: Acee Lindem [mailto:acee@redback.com] >> | >Sent: Friday, May 23, 2003 1:50 PM >> | >To: Acee Lindem >> | >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area >> | >Directorate >> | >Subject: Re: Comments on >> | > >> | > >> | >Christian, Stefano, Brad, >> | > >> | >The follow-up discussion on the necessity for both 32 bit and >> | >64 bit tags raises the question as to whether or not it is >> | >wise to allow an arbitrary number of tags to be advertised. >> | > >> | > This draft proposes 2 new "Administrative Tag" sub-TLVs >> | >to be added >> | > to TLV 135 and 235. These TLVs specify one or more >> | >ordered, 32 or 64 >> | > ~~~~~~~~~~~~~~~ >> | > bit unsigned integers that may be associated with an IP >> prefix. >> | > >> | >However, the receiver need only use the first. >> | > >> | > An implementation may consider only one of the encoded >> | >tags, in which >> | > case the first encoded tag must be considered. A tag >> | >value of zero >> | > is reserved and should be treated as "no tag". >> | > >> | >IMHO, allowing an arbitrary number of tags affords more >> | >potential for interoperability and deviant applications than >> | >the 64 bit tag. >> | > >> | > >> | > >> | > >> | > >> | >Acee Lindem wrote: >> | >> As a member of the routing area directorate, I have reviewed the >> | >> subject document. Here are my comments: >> | >> >> | >> Comments: >> | >> >> | >> 1. The last sentence of the abstract doesn't make sense. >> | >"Additionally, >> | >> the information can be placed in LSPs that have TLVs as yet >> | >> undefined, if this information is used to convey the same >> | >> meaning in these future TLVs as it used in the currently >> defined >> | >> TLVs". Suggested - "The administrative tag sub-TLVs may >> | >be used with >> | >> with future TLVs as long as their semantics are preserved." >> | >> >> | >> 2. Section 5.2 - The value of the type is wrong - it >> | >should be 2 rather >> | >> than 1. >> | >> >> | >> 3. Section 6 says the ordering of tags is not significant. >> | >However, the >> | >> previous sections (5.1 and 5.2) say that an >> | >implementation may only >> | >> consider the first tag. >> | >> >> | >> 4. Section 7 - List the requirements for receiving the new >> | >Sub-TLVs in >> | >> this compliance section as well (even if they were stated >> | >> previously). >> | >> >> | >> 5. Section 8 - The example talks about R2 associating tag 110 >> with >> | >> property >> | >> A and prefix 1.1.1.0/24. Yet in Figure 1, prefix >> | >1.1.1.0/24 with >> | >> property >> | >> A is adjacent to R1 (which applies to me that R1 originate the >> | >> prefix). >> | >> Please fix either the example or the figure. >> | >> >> | >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): >> | >> >> | >> 1. The abstract contains references. The documents should >> | >be specified >> | >> by name since the abstract can be excerpted. >> | >> >> | >> 2. Line 323 over 72 chars. >> | >> >> | >> Line 323 length is 74 >> | >> Routing in IS-IS", >> | >draft-ietf-isis-wg-multi-topology-03.txt, >> | >> April >> | >> >> | >> 3. Pages 2, 3, 4, and 5 have over 58 lines. >> | >> >> | > >> | > >> | >-- >> | >Acee >> | > >> >> > > From rtg-dir-admin@ietf.org Sun Jun 1 06:21:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03908 for ; Sun, 1 Jun 2003 06:21:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MPw4-0005EZ-00 for rtg-dir-archive@ietf.org; Sun, 01 Jun 2003 06:19:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MPw3-0005EW-00 for rtg-dir-archive@ietf.org; Sun, 01 Jun 2003 06:19:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51ALIB02987; Sun, 1 Jun 2003 06:21:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51AKYB02941 for ; Sun, 1 Jun 2003 06:20: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 GAA03893; Sun, 1 Jun 2003 06:20:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MPvJ-0005EF-00; Sun, 01 Jun 2003 06:18:46 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19MPvJ-0005EC-00; Sun, 01 Jun 2003 06:18:45 -0400 Received: from net4u.ch (zux006-013-060.adsl.green.ch [81.6.13.60]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h51ALCf1016726; Sun, 1 Jun 2003 12:21:13 +0200 Message-ID: <3ED9D362.3080400@net4u.ch> Date: Sun, 01 Jun 2003 12:20:18 +0200 From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: prz@net4u.ch CC: Acee Lindem , Hannes Gredler , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> <3ED9CF5A.7010306@net4u.ch> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > >I would strongly encourage keeping multiple, ordered tags > oops, glas of wine here, it's 'not-ordered' ... -- tony From rtg-dir-admin@ietf.org Sun Jun 1 07:32:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04737 for ; Sun, 1 Jun 2003 07:32:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MR2Y-0005Qn-00 for rtg-dir-archive@ietf.org; Sun, 01 Jun 2003 07:30:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MR2X-0005Qk-00 for rtg-dir-archive@ietf.org; Sun, 01 Jun 2003 07:30:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51BW1B06497; Sun, 1 Jun 2003 07:32:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51BVYB06457 for ; Sun, 1 Jun 2003 07:31: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 HAA04713; Sun, 1 Jun 2003 07:31:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MR24-0005QL-00; Sun, 01 Jun 2003 07:29:49 -0400 Received: from ms-smtp-01.southeast.rr.com ([24.93.67.82]) by ietf-mx with esmtp (Exim 4.12) id 19MR23-0005QD-00; Sun, 01 Jun 2003 07:29:47 -0400 Received: from redback.com (rdu26-54-058.nc.rr.com [66.26.54.58]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h51BQ7d2018308; Sun, 1 Jun 2003 07:26:08 -0400 (EDT) Message-ID: <3ED9E375.20009@redback.com> Date: Sun, 01 Jun 2003 07:28:53 -0400 From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: prz@net4u.ch CC: Hannes Gredler , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> <3ED9CF5A.7010306@net4u.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tony Przygienda wrote: > Acee Lindem wrote: > > >>Hannes, >> >>If we agree that having a single 32 bit and/or 64 bit tag is a >>good idea then perhaps we could change the wording of the draft to >>say that an implementation SHOULD only send and interpret a single >>tag and SHOULD ignore data past the first tag. This would allow >>the usage of multiple tags to be gracefully deprecated. >> >>If this isn't acceptable then can we can agree on a small >>finite/known number of tags with suggested usage? > > > So, I watched for a while Alex and now Acee trying to influence the > direction of this thing (after a last call funny enough) and I definitely > do _NOT_ like the direction this is going. I have an understanding for > 'exact specification' and 'understanding what the tags are doing' and > 'we don't want 64 and 32 bits in place' __BUT__ > > 1) Slashing the whole thing to things like 1 tag only and squeezing it > in size may feel good in terms of specification but it will probably > make > it as flexible and useful as the OSPF tag, namely completely useless. > Just look at the unnatural contortions of RFC 1994. > 2) I am lacking to follow the arguments here why multiple tags are so > harmfull, > why we have to know _exactly_ what every tag means and why the > 32 and 64 bit tags together are such a big issue. The only ones > I saw were basically 'it may blackhole routes or lead to problems > when misconfiguration or implementaion errors occur'. Well, guess > what, that's true for almost any RFC that ends up implenented in > a screwy way. ISIS is a small implementor's community and we do > not have to build specs in a way that every kid hacking Linux can > implement it perfectly without having written a protocol in their life > before. > > Therefore, I would encourage the implementors to think whether they want > to end up in an OSPF-like tag corset or they want to preserve the > flexibility of having multiple tags that can be used in a global or > local fashion > (global shall necessitate a description for interop-purposes, probaby > 2547 extcomm being carried around would be such a thing) or otheriwse > for all kind of nice local/proprietary things. BGP extscomms are already > used in such way couple of nice & smart ways (I won't go into d3etails > to protect the usually suspect vendors ;-) Some of those mechanisms > could be used for ISIS to e.g. accelerate convergence on routers > supporting these extensions. So, if implementors feel strongly here, > please push back on all that 'we'll make it soo much nicer' tweaking and > let's try to get this draft out in some decent time rather than the usual > 3-infinity years it takes an ISIS RFC to be issued. > > I would strongly encourage keeping multiple, ordered tags and the draft > not touching on their application. I would also encourage a 32 and a > 64 bit tag, both being independent address spaces. It's not ideal but > what's the point redoing stuff in the field just so the encoding is tad > nicer? I would encourage a draft on how the 2547 stuff is being sloshed > around using tags. And I think we added a paragraph that when the > route selection supresses a route based on a tag we may end up with > a blackhole. So if we step back, what we have here is a pair of generic TLVs (32 and 64 bits tags) which can be used to send an arbitrary amount of opaque information. Will the tag encodings and their respective applications be described in future drafts? Thanks, -- Acee From rtg-dir-admin@ietf.org Sun Jun 1 07:57:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05043 for ; Sun, 1 Jun 2003 07:57:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MRQp-0005XF-00 for rtg-dir-archive@ietf.org; Sun, 01 Jun 2003 07:55:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MRQo-0005XC-00 for rtg-dir-archive@ietf.org; Sun, 01 Jun 2003 07:55:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51Bv7B08201; Sun, 1 Jun 2003 07:57:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51BuCB08140 for ; Sun, 1 Jun 2003 07:56: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 HAA05003; Sun, 1 Jun 2003 07:56:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MRPu-0005WY-00; Sun, 01 Jun 2003 07:54:26 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19MRPt-0005WV-00; Sun, 01 Jun 2003 07:54:25 -0400 Received: from net4u.ch (zux006-013-060.adsl.green.ch [81.6.13.60]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h51Bupf1030881; Sun, 1 Jun 2003 13:56:52 +0200 Message-ID: <3ED9E9CE.9070803@net4u.ch> Date: Sun, 01 Jun 2003 13:55:58 +0200 From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Acee Lindem CC: Hannes Gredler , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> <3ED9CF5A.7010306@net4u.ch> <3ED9E375.20009@redback.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > >> >> >> I would strongly encourage keeping multiple, ordered tags and the draft >> not touching on their application. I would also encourage a 32 and a >> 64 bit tag, both being independent address spaces. It's not ideal but >> what's the point redoing stuff in the field just so the encoding is tad >> nicer? I would encourage a draft on how the 2547 stuff is being sloshed >> around using tags. And I think we added a paragraph that when the >> route selection supresses a route based on a tag we may end up with >> a blackhole. > > > So if we step back, what we have here is a pair of generic TLVs (32 > and 64 bits tags) which can be used to send an arbitrary amount of > opaque information. yes, you could send in 64 bit tags Finnegan's Wake up to couple hundred bytes per prefix if you really want to but then, I assume to fix this problem in OSPF you will decleare RFC2370 unlawfull really soon? If the 'hidden communication channel' is the problem you try to solve, security groups will yield a much more fruitfull harvest. > Will the tag encodings and their respective > applications be described in future drafts? That would be very, very desirable but given e.g. EXTCOMMs realities, may only partially come to fruition. I would expect that stuff that has to interoperate would be documented, stuff that does not (e.g. an extension that improves protocol behavior if the other receipient understands it, otherwise yields nothing) not necessarily. Again, RFC2370 comes to mind. thanks - tony From mailman-admin@ietf.org Sun Jun 1 09:27:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07692 for ; Sun, 1 Jun 2003 09:27:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MSqX-0006GN-00 for rtg-dir-archive@ietf.org; Sun, 01 Jun 2003 09:26:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MSqX-0006GI-00 for rtg-dir-archive@ietf.org; Sun, 01 Jun 2003 09:26:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51DRmB22619 for ; Sun, 1 Jun 2003 09:27:48 -0400 Date: Sun, 01 Jun 2003 09:27:48 -0400 Message-ID: <20030601132748.11734.21916.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rtg-dir-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rtg-dir-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rtg-dir-archive@ietf.org: List Password // URL ---- -------- rtg-dir@ietf.org utnefe https://www1.ietf.org/mailman/options/rtg-dir/rtg-dir-archive%40ietf.org From rtg-dir-admin@ietf.org Sun Jun 1 09:37:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08287 for ; Sun, 1 Jun 2003 09:37:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MT0R-0006SC-00 for rtg-dir-archive@ietf.org; Sun, 01 Jun 2003 09:36:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19MT0Q-0006S9-00 for rtg-dir-archive@ietf.org; Sun, 01 Jun 2003 09:36:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51Dc1B26227; Sun, 1 Jun 2003 09:38:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51Db6B25252 for ; Sun, 1 Jun 2003 09:37: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 JAA08233; Sun, 1 Jun 2003 09:37:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MSzW-0006Qu-00; Sun, 01 Jun 2003 09:35:18 -0400 Received: from ms-smtp-03.southeast.rr.com ([24.93.67.84]) by ietf-mx with esmtp (Exim 4.12) id 19MSzV-0006Qr-00; Sun, 01 Jun 2003 09:35:17 -0400 Received: from redback.com (rdu26-54-058.nc.rr.com [66.26.54.58]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h51DZMtL026526; Sun, 1 Jun 2003 09:35:22 -0400 (EDT) Message-ID: <3EDA00DD.3030408@redback.com> Date: Sun, 01 Jun 2003 09:34:21 -0400 From: Acee Lindem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: prz@net4u.ch CC: Hannes Gredler , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> <3ED9CF5A.7010306@net4u.ch> <3ED9E375.20009@redback.com> <3ED9E9CE.9070803@net4u.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tony Przygienda wrote: >> >>> >>>I would strongly encourage keeping multiple, ordered tags and the draft >>>not touching on their application. I would also encourage a 32 and a >>>64 bit tag, both being independent address spaces. It's not ideal but >>>what's the point redoing stuff in the field just so the encoding is tad >>>nicer? I would encourage a draft on how the 2547 stuff is being sloshed >>>around using tags. And I think we added a paragraph that when the >>>route selection supresses a route based on a tag we may end up with >>> a blackhole. >> >> >>So if we step back, what we have here is a pair of generic TLVs (32 >>and 64 bits tags) which can be used to send an arbitrary amount of >>opaque information. > > > yes, you could send in 64 bit tags Finnegan's Wake up to couple hundred > bytes per prefix if you really want to but then, I assume to fix this > problem in OSPF > you will decleare RFC2370 unlawfull really soon? Actually, to the best of my knowledge, most of the opaque LSA applications are documented in RFCs and/or drafts (although I know there are undocumented TLVs sent within TE LSAs). > thanks > > - tony > > > -- Acee From rtg-dir-admin@ietf.org Mon Jun 2 21:24:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02701 for ; Mon, 2 Jun 2003 21:24:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N0Vd-0000W2-00 for rtg-dir-archive@ietf.org; Mon, 02 Jun 2003 21:22:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19N0Vd-0000Vy-00 for rtg-dir-archive@ietf.org; Mon, 02 Jun 2003 21:22:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h531OTB10030; Mon, 2 Jun 2003 21:24:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h531NUB09929 for ; Mon, 2 Jun 2003 21:23: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 VAA02689; Mon, 2 Jun 2003 21:23:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N0Ud-0000Vo-00; Mon, 02 Jun 2003 21:21:39 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19N0Uc-0000Vk-00; Mon, 02 Jun 2003 21:21:38 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19N0WL-000Eqt-00; Tue, 03 Jun 2003 01:23:25 +0000 Date: Mon, 2 Jun 2003 18:22:56 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <3859276824.20030602182256@psg.com> To: isis-wg@ietf.org CC: Routing Area Directorate Subject: Re: [Isis-wg] RE: Comments on MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tony, Acee, et al. I think I should clarify some points here, specifically what I am and am not concerned with and why. What I do NOT have a problem with (non-issues): NI-1. The opaque nature of a route tag as an integer attached to a route NI-2. Presence of a 32-bit and a 64-bit tag simultaneously if there is a real reason for this. NI-3. Even more than one tag, as long as they are used as _tags_, though I can't see how more than 2 or 3 tags would be useful. However, what concerns me is (issues with discussions, please feel free to comment): I-1. Tag TLVs introduced as any-size opaque transport containers, such inflatable "goodie-bags" with practically no internal structure (except for n x 32, or n x 64) where one can find tags, but also "all kind of nice proprietary things". Is there a risk that these TLVs will be used to carry "stuff" around? Reviewing the thread, seems that Acee, Tony P. and I agree that this is possible: "...yes, you could send in 64 bit tags Finnegan's Wake up to couple hundred bytes per prefix if you really want to..." What's the risk that this will happen? What is the risk that more than one vendor will do that? Is this dangerous? Are we going to see collisions among vendors in the field? Plus all arguments we have seen against vendor-specific extensions during the discussion on experimental TLVs are applicable (issues with interop, security, changes in proto dynamics, lack of community review, etc.) It seems that the WG needs to consider these arguments. I-2. The problem of distributing 2547-related attributes addressed by introduction of the n x 64-bit opaque TLV, called 'tag'. Why are we overloading the notion of tag from the very beginning? Why not have a separate TLV and a proper spec for this? This goes hand in hand with the question of why we need another tag. If we assume that the right answer to transportation of the 2547 attributes is a separate TLV with a proper specification of what is put there and how to act on it, then we need to answer the question "do we need the second tag?" If we read the draft as it stands, with the main application being route "color" and control over prefix distribution, the second tag does not seem necessary. Also, the size of the tag (8 octets) raises the risk of "stuff" being put into it, though it is admittedly much lower than the risk introduced by I-1 To comment on some points Tony P. brought up (those not implicitly addressed above): 1. Why we should know what every tag means? I don't believe we should (see NI-1). On the other hand, if the document intends to say that one of the applications of the tag is to control route distribution, it should request that compliant implementations support tag-based prefix filtering. Otherwise compliance to the spec will not mean anything to the SP who want to actually control prefix distribution. 2. What about OSPF Opaque LSAs and BGP Extended Communities? It seems to me that the difference between them and the current tag proposal is in the level at which opaqueness is introduced and presence of the internal structure. More specifically, before Opaque LSAs were introduced, each new LSA type required modification of OSPF SW. Opaque LSAs abstract transport details of LSA flooding from the description of LSA payload. This helps to avoid having to modify the SW every time a new LSA is introduced. (However, each Opaque LSA type needs to be registered by IANA through the OSPF WG, which outlaws just grabbing an LSA to distribute proprietary stuff.) ISIS already has this level of opaqueness through the notion of TLVs. Regular BGP communities (RFC1997) are constructed as a set of one or more 32-bit values, which seems very close to the description of the 32-bit tag TLV in the draft. The difference is in the fact that some internal structure is provided at least for admin assignment, and that some values are reserved and defined as well-known, with well-defined behavior, which enforces their use as tags. Extended communities are also different, since each ext community is encoded as Type/Value couple, with internal structure specific to a type, sub-types allocated by IANA, and fixed-length values. I hope this clarifies my concerns and will help the discussion. Thanks. Alex From rtg-dir-admin@ietf.org Mon Jun 2 21:25:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02737 for ; Mon, 2 Jun 2003 21:25:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N0X5-0000Wx-00 for rtg-dir-archive@ietf.org; Mon, 02 Jun 2003 21:24:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19N0X5-0000Wu-00 for rtg-dir-archive@ietf.org; Mon, 02 Jun 2003 21:24:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h531Q0B10102; Mon, 2 Jun 2003 21:26:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h531PUB10081 for ; Mon, 2 Jun 2003 21:25: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 VAA02729; Mon, 2 Jun 2003 21:25:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N0Wa-0000Wo-00; Mon, 02 Jun 2003 21:23:40 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19N0WZ-0000Wl-00; Mon, 02 Jun 2003 21:23:39 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19N0YE-000EwM-00; Tue, 03 Jun 2003 01:25:22 +0000 Date: Mon, 2 Jun 2003 18:24:53 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <44859393983.20030602182453@psg.com> To: Hannes Gredler CC: Acee Lindem , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , Subject: Re: [Isis-wg] RE: Comments on In-Reply-To: <20030530222903.GA11581@juniper.net> References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> <20030530222903.GA11581@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hannes, Are the tag and tag2 both 32-bit tags taken from the same TLV or do you have the 64-bit tags coded/deployed also? -- Alex http://www.psg.com/~zinin/ Friday, May 30, 2003, 3:29:03 PM, Hannes Gredler wrote: > acee, > our implementation currently support two tags > and we pass it on in a ordered way for > internal policy-processing e.g. first tag found is copied > to the variable "tag" and the second tag is > copied to the variable "tag2"; both variables can be > matched against in our internal policy processing > language; > and thats IMHO the only place > where the draft needs to be more specific: > how an implementation [order, etc.] maps IS-IS-tags > to match-clauses in the local policy processor; > i am unsure about the ordering and number of supported tags > of other implementations; > stefano, can you shed some light ? > --- > SHOULD is IMO a bit too strong wording, i'd be happy > with something like "MAY have more than one tag" > /hannes > On Thu, May 29, 2003 at 05:21:00PM -0400, Acee Lindem wrote: > | Hannes, > | > | If we agree that having a single 32 bit and/or 64 bit tag is a > | good idea then perhaps we could change the wording of the draft to > | say that an implementation SHOULD only send and interpret a single > | tag and SHOULD ignore data past the first tag. This would allow > | the usage of multiple tags to be gracefully deprecated. > | > | If this isn't acceptable then can we can agree on a small > | finite/known number of tags with suggested usage? > | > | Thanks, > | Acee > | > | Hannes Gredler wrote: | >>pls, keep in mind that there is already code in production that allows | >>more than one tag; | >> | >>common use i have seen so far is | >> | >>tag #1 controls L2L1 leakage | >>tag #2 for informational purposes and points to the area of origin; | >> | >>/hannes | >> | >>On Fri, May 23, 2003 at 03:20:41PM -0400, Martin, Christian wrote: | >>| RE: Comments on | >>| | >>| Acee, | >>| | >>| As the original goal was to create a capability similar to OSPF's route | >>tag, | >>| it may be wise to drop this capability. On the otherhand, having | >>multiple | >>| tags per route can provide more information about the route than a single | >>| tag. In this regard, the 32 bit tag operates more like a community, and | >>the | >>| 64 bit tag operates like an extended community. From an implementation | >>| perspective, the same routines for matching and setting these fields | >>should | >>| be similar to the community fields in BGP. | >>| | >>| I would like to solicit the WG for comments on which capability is most | >>| attractive. The goal is not to introduce too much bloat (is it too late | >>for | >>| that?!) while still providing some flexibility. | >>| | >>| As soon as I receive any final comments, I will release the updated | >>draft. | >>| | >>| Thanks for pointing out this critical piece! | >>| | >>| Regards, | >>| chris | >>| | >>| >-----Original Message----- | >>| >From: Acee Lindem [mailto:acee@redback.com] | >>| >Sent: Friday, May 23, 2003 1:50 PM | >>| >To: Acee Lindem | >>| >Cc: Christian Martin; Stefano Previdi; Brad Neal; Routing Area | >>| >Directorate | >>| >Subject: Re: Comments on | >>| > | >>| > | >>| >Christian, Stefano, Brad, | >>| > | >>| >The follow-up discussion on the necessity for both 32 bit and | >>| >64 bit tags raises the question as to whether or not it is | >>| >wise to allow an arbitrary number of tags to be advertised. | >>| > | >>| > This draft proposes 2 new "Administrative Tag" sub-TLVs | >>| >to be added | >>| > to TLV 135 and 235. These TLVs specify one or more | >>| >ordered, 32 or 64 | >>| > ~~~~~~~~~~~~~~~ | >>| > bit unsigned integers that may be associated with an IP prefix. | >>| > | >>| >However, the receiver need only use the first. | >>| > | >>| > An implementation may consider only one of the encoded | >>| >tags, in which | >>| > case the first encoded tag must be considered. A tag | >>| >value of zero | >>| > is reserved and should be treated as "no tag". | >>| > | >>| >IMHO, allowing an arbitrary number of tags affords more | >>| >potential for interoperability and deviant applications than | >>| >the 64 bit tag. | >>| > | >>| > | >>| > | >>| > | >>| > | >>| >Acee Lindem wrote: | >>| >> As a member of the routing area directorate, I have reviewed the | >>| >> subject document. Here are my comments: | >>| >> | >>| >> Comments: | >>| >> | >>| >> 1. The last sentence of the abstract doesn't make sense. | >>| >"Additionally, | >>| >> the information can be placed in LSPs that have TLVs as yet | >>| >> undefined, if this information is used to convey the same | >>| >> meaning in these future TLVs as it used in the currently defined | >>| >> TLVs". Suggested - "The administrative tag sub-TLVs may | >>| >be used with | >>| >> with future TLVs as long as their semantics are preserved." | >>| >> | >>| >> 2. Section 5.2 - The value of the type is wrong - it | >>| >should be 2 rather | >>| >> than 1. | >>| >> | >>| >> 3. Section 6 says the ordering of tags is not significant. | >>| >However, the | >>| >> previous sections (5.1 and 5.2) say that an | >>| >implementation may only | >>| >> consider the first tag. | >>| >> | >>| >> 4. Section 7 - List the requirements for receiving the new | >>| >Sub-TLVs in | >>| >> this compliance section as well (even if they were stated | >>| >> previously). | >>| >> | >>| >> 5. Section 8 - The example talks about R2 associating tag 110 with | >>| >> property | >>| >> A and prefix 1.1.1.0/24. Yet in Figure 1, prefix | >>| >1.1.1.0/24 with | >>| >> property | >>| >> A is adjacent to R1 (which applies to me that R1 originate the | >>| >> prefix). | >>| >> Please fix either the example or the figure. | >>| >> | >>| >> Nit Comments (see draft-rfc-editor-rfc2223bis-03.txt): | >>| >> | >>| >> 1. The abstract contains references. The documents should | >>| >be specified | >>| >> by name since the abstract can be excerpted. | >>| >> | >>| >> 2. Line 323 over 72 chars. | >>| >> | >>| >> Line 323 length is 74 | >>| >> Routing in IS-IS", | >>| >draft-ietf-isis-wg-multi-topology-03.txt, | >>| >> April | >>| >> | >>| >> 3. Pages 2, 3, 4, and 5 have over 58 lines. | >>| >> | >>| > | >>| > | >>| >-- | >>| >Acee From rtg-dir-admin@ietf.org Tue Jun 3 00:49:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07219 for ; Tue, 3 Jun 2003 00:49:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N3iE-0001c4-00 for rtg-dir-archive@ietf.org; Tue, 03 Jun 2003 00:47:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19N3iE-0001c1-00 for rtg-dir-archive@ietf.org; Tue, 03 Jun 2003 00:47:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h534ngB24679; Tue, 3 Jun 2003 00:49:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h534mNB24572 for ; Tue, 3 Jun 2003 00:48: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 AAA07168; Tue, 3 Jun 2003 00:48:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N3gv-0001ai-00; Tue, 03 Jun 2003 00:46:33 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19N3gu-0001aH-00; Tue, 03 Jun 2003 00:46:32 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 1D8823446D; Mon, 2 Jun 2003 21:02:41 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h534lhYB012823; Mon, 2 Jun 2003 21:47:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] RE: Comments on Date: Mon, 2 Jun 2003 21:47:43 -0700 Message-ID: Thread-Topic: [Isis-wg] RE: Comments on Thread-Index: AcMpcix4hHkYN4+bSz2XGX4wFZDV0wAF9trQ From: "Tony Li" To: "Alex Zinin" , Cc: "Routing Area Directorate" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h534mNB24574 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Let me respond to all of Alex's comments at once... How do I see vendor defined tags being used? I see them being used for experimental purposes, for shipping some new functionality before the implementation is wholly stable. As with any experimental object, I would hope that it would eventually be documented and become standardized. Just so we don't have to play proprietary IGP games yet again. | I-1. Tag TLVs introduced as any-size opaque transport containers, | such inflatable "goodie-bags" with practically no internal | structure (except for n x 32, or n x 64) where one can find | tags, but also "all kind of nice proprietary things". I submit to you that almost any experimental TLV can be used for this purpose, or any obsolete TLV value, or any hijacked TLV could be used fairly safely. So I don't believe that even if you eliminated this proposal, you would deter anyone from including Finnegan's Wake in the slightest. The issue that I have with using this (or any TLV) for such fun is that it's basically dishonest and unnecessarily so. If folks feel the need to carry A Tale of Two Cities in their IGP, well, I'm not going to stop them, but please, let's allocate some intelligent and opaque TLV so that we all realize that this is someone's private sandbox. That said, that doesn't seem like an issue that should deter this proposal. | I-2. The problem of distributing 2547-related attributes addressed | by introduction of the n x 64-bit opaque TLV, called 'tag'. | Why are we overloading the notion of tag from the | very beginning? | Why not have a separate TLV and a proper spec for this? Or, why not just explicitly allocate global tag values for 2547 attributes? I have no issue with this (above and beyond my general distaste for 2547). Tony From rtg-dir-admin@ietf.org Tue Jun 3 05:43:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24751 for ; Tue, 3 Jun 2003 05:43:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N8J2-0003VQ-00 for rtg-dir-archive@ietf.org; Tue, 03 Jun 2003 05:42:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19N8J1-0003VL-00 for rtg-dir-archive@ietf.org; Tue, 03 Jun 2003 05:42:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h539i1B27654; Tue, 3 Jun 2003 05:44:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h539hdB27590 for ; Tue, 3 Jun 2003 05:43: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 FAA24736; Tue, 3 Jun 2003 05:43:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N8Ie-0003Uv-00; Tue, 03 Jun 2003 05:41:48 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19N8Id-0003Us-00; Tue, 03 Jun 2003 05:41:47 -0400 Received: from net4u.ch (zux006-036-016.adsl.green.ch [81.6.36.16]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h539iNf1031402; Tue, 3 Jun 2003 11:44:23 +0200 Message-ID: <3EDC6DC0.60801@net4u.ch> Date: Tue, 03 Jun 2003 11:43:28 +0200 From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: Alex Zinin , isis-wg@ietf.org, Routing Area Directorate Subject: Re: [Isis-wg] RE: Comments on References: X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/related; boundary="------------090805040203010701040706" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --------------090805040203010701040706 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony Li wrote: > >Let me respond to all of Alex's comments at once... > >How do I see vendor defined tags being used? I see them being used >for experimental purposes, for shipping some new functionality before >the implementation is wholly stable. As with any experimental object, >I would hope that it would eventually be documented and become >standardized. Just so we don't have to play proprietary IGP games yet >again. > agreed > > >| I-1. Tag TLVs introduced as any-size opaque transport containers, >| such inflatable "goodie-bags" with practically no internal >| structure (except for n x 32, or n x 64) where one can find >| tags, but also "all kind of nice proprietary things". > > >I submit to you that almost any experimental TLV can be used for this >purpose, or any obsolete TLV value, or any hijacked TLV could be used >fairly safely. So I don't believe that even if you eliminated this >proposal, you would deter anyone from including Finnegan's Wake in the >slightest. > >The issue that I have with using this (or any TLV) for such fun is that >it's basically dishonest and unnecessarily so. If folks feel the >need to carry A Tale of Two Cities in their IGP, well, I'm not going >to stop them, but please, let's allocate some intelligent and opaque >TLV so that we all realize that this is someone's private sandbox. > >That said, that doesn't seem like an issue that should deter this >proposal. > agreed > > >| I-2. The problem of distributing 2547-related attributes addressed >| by introduction of the n x 64-bit opaque TLV, called 'tag'. >| Why are we overloading the notion of tag from the >| very beginning? >| Why not have a separate TLV and a proper spec for this? > > >Or, why not just explicitly allocate global tag values for 2547 >attributes? >I have no issue with this (above and beyond my general distaste for >2547). > > > oops, even you, Brutus ;-) Can we agree here on e.g.: 1) let's the 32+64 go, not worth the energy for little damage done. Decouple the two and that's it. Yes, it's tad of more implementation code but it's better than waste 2 years chewing on it. And by then, it's deployed anyway so you end up documenting it no matter what we came up with as 'better' solution. 2) introduce 2-3 bits in front of tag to structure it (albeit we have deployments, I think Cisco/JNPR would swallow that one). But, then, how would we fit EXTCOMMs that are 64bits into 64bits ? 3) Put a section in describing that in misconfiguration and using the tag for supressing prefixes in SPF, blackholes may result. 3) Put a section in that any tag that's supposed to be understood globally and influence SPF must be brought to the group thanks - tony > > --------------090805040203010701040706-- From rtg-dir-admin@ietf.org Tue Jun 3 06:01:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25195 for ; Tue, 3 Jun 2003 06:01:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N8aR-0003dc-00 for rtg-dir-archive@ietf.org; Tue, 03 Jun 2003 06:00:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19N8aQ-0003dZ-00 for rtg-dir-archive@ietf.org; Tue, 03 Jun 2003 06:00:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53A21B28734; Tue, 3 Jun 2003 06:02:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53A1cB28711 for ; Tue, 3 Jun 2003 06:01: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 GAA25186 for ; Tue, 3 Jun 2003 06:01:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19N8a2-0003dM-00 for rtg-dir@ietf.org; Tue, 03 Jun 2003 05:59:46 -0400 Received: from gw.xebeo.com ([204.192.44.242] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 19N8a1-0003d9-00 for rtg-dir@ietf.org; Tue, 03 Jun 2003 05:59:45 -0400 Received: (qmail 7077 invoked from network); 3 Jun 2003 10:01:02 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 3 Jun 2003 10:01:02 -0000 Message-ID: <3EDC71DC.9070301@xebeo.com> Date: Tue, 03 Jun 2003 12:01:00 +0200 From: Tony Przygienda Reply-To: prz@xebeo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: isis-wg@ietf.org, Routing Area Directorate Subject: Re: [Isis-wg] RE: Comments on References: <3859276824.20030602182256@psg.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex Zinin wrote: >Tony, Acee, et al. > >I think I should clarify some points here, specifically what I am >and am not concerned with and why. > >What I do NOT have a problem with (non-issues): > >NI-1. The opaque nature of a route tag as an integer attached > to a route > ok > >NI-2. Presence of a 32-bit and a 64-bit tag simultaneously if > there is a real reason for this. > the reason may be existing implementaions and/or deployment. > >NI-3. Even more than one tag, as long as they are used as _tags_, > though I can't see how more than 2 or 3 tags would be > useful. > you don't have to, people will find it out themselves or othrewise there will be never more than 3 tags around. > >However, what concerns me is (issues with discussions, please >feel free to comment): > >I-1. Tag TLVs introduced as any-size opaque transport containers, > such inflatable "goodie-bags" with practically no internal > structure (except for n x 32, or n x 64) where one can find > tags, but also "all kind of nice proprietary things". > > Is there a risk that these TLVs will be used to carry "stuff" > around? Reviewing the thread, seems that Acee, Tony P. and I > agree that this is possible: > > "...yes, you could send in 64 bit tags Finnegan's Wake up to > couple hundred bytes per prefix if you really want to..." > > What's the risk that this will happen? What is the risk that more > than one vendor will do that? Is this dangerous? Are we going to > see collisions among vendors in the field? Plus all arguments we > have seen against vendor-specific extensions during the > discussion on experimental TLVs are applicable (issues with > interop, security, changes in proto dynamics, lack of community > review, etc.) > not again. There are plenty of things in OSPF/ISIS I can misuse as 'hidden communicaiton channel'. And we agreed that even if SPF is influenced by this tag, you can only blackhole. Yes, the possibilites to kill oneself deserves a mention in the draft but otherwise it's just a pseudo-exercise in 'home-protocol-security'. You 're not protecting anyone from anything by restricting everyting to a single 32 bits tag. > > It seems that the WG needs to consider these arguments. > >I-2. The problem of distributing 2547-related attributes addressed > by introduction of the n x 64-bit opaque TLV, called 'tag'. > Why are we overloading the notion of tag from the very beginning? > Why not have a separate TLV and a proper spec for this? > Yes, we can have another draft, taking another sub-TLV point specifically 2547. What's the difference of that beside having some additional encoding rules that makes no difference in deployment behavior ? Actually, the more I think about it, the more I come to the conclusion that we should just pick up the EXTCOMM structure for those 64-bit tags and reserve the same LOW types for the same purposes. > > This goes hand in hand with the question of why we need another > tag. If we assume that the right answer to transportation of the > 2547 attributes is a separate TLV with a proper specification of > what is put there and how to act on it, then we need to answer > the question "do we need the second tag?" If we read the draft as > it stands, with the main application being route "color" and > control over prefix distribution, the second tag does not seem > necessary. > > Also, the size of the tag (8 octets) raises the risk of "stuff" > being put into it, though it is admittedly much lower than the > risk introduced by I-1 > what 'risks' of what 'stuff' and what 'lower risk' ? I hope you don't start to argue in such vague terms without any hard data to back it up. Otherwise I fear the next draft we discuss will bear the danger of weapons of mass desctruction. Sorry for the sarcasm but this is really not going anywhere fast. > >To comment on some points Tony P. brought up (those not implicitly >addressed above): > >1. Why we should know what every tag means? > > I don't believe we should (see NI-1). > agreed, however if everybody wants everybody interoperating on a specific tag value, a draft/RFC will be almost a must. > > On the other hand, if the document intends to say that one of > the applications of the tag is to control route distribution, > it should request that compliant implementations support > tag-based prefix filtering. Otherwise compliance to the spec > will not mean anything to the SP who want to actually control > prefix distribution. > not again, you can't force people to implement node-specific things. Maybe they have high-end nodes that allow policies and low-end that don't. Stop trying to mandate the internals of implementations. > >2. What about OSPF Opaque LSAs and BGP Extended Communities? > > It seems to me that the difference between them and the current tag > proposal is in the level at which opaqueness is introduced and > presence of the internal structure. > > > Regular BGP communities (RFC1997) are constructed as a set of one > or more 32-bit values, which seems very close to the description of > the 32-bit tag TLV in the draft. The difference is in the fact that > some internal structure is provided at least for admin assignment, > and that some values are reserved and defined as well-known, with > well-defined behavior, which enforces their use as tags. > > Extended communities are also different, since each ext community > is encoded as Type/Value couple, with internal structure specific > to a type, sub-types allocated by IANA, and fixed-length values. > > ok, so let's make the 64bits just like EXTCOMMs - tony > > From rtg-dir-admin@ietf.org Tue Jun 3 15:52:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22497 for ; Tue, 3 Jun 2003 15:52:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NHnS-0002HP-00 for rtg-dir-archive@ietf.org; Tue, 03 Jun 2003 15:50:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NHnR-0002HM-00 for rtg-dir-archive@ietf.org; Tue, 03 Jun 2003 15:50:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53Jq0B22945; Tue, 3 Jun 2003 15:52:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53JptB22930 for ; Tue, 3 Jun 2003 15:51: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 PAA22494; Tue, 3 Jun 2003 15:51:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NHnI-0002HJ-00; Tue, 03 Jun 2003 15:50:04 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19NHnH-0002HE-00; Tue, 03 Jun 2003 15:50:03 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19NHov-000Bww-00; Tue, 03 Jun 2003 19:51:45 +0000 Date: Tue, 3 Jun 2003 12:51:26 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <40925786801.20030603125126@psg.com> To: Tony Przygienda CC: Tony Li , isis-wg@ietf.org, Routing Area Directorate Subject: Re: [Isis-wg] RE: Comments on In-Reply-To: <3EDC6DC0.60801@net4u.ch> References: <3EDC6DC0.60801@net4u.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tony, [...] > Can we agree here on e.g.: I would be fine with any approach that the WG agrees on and that preferably gets rid of the "generic container" problem. I do think that introducing structure and/or well-know reserved values solves this problem. Regarding the two items "3)" below ;) I think there was more to fix there, but I'll check. Alex > 1) let's the 32+64 go, not worth the energy for little damage done. > Decouple the two and that's it. Yes, it's tad of more implementation > code but it's better than waste 2 years chewing on it. And by then, > it's deployed anyway so you end up documenting it no matter what we > came up with as 'better' solution. > 2) introduce 2-3 bits in front of tag to structure it (albeit we > have deployments, I think Cisco/JNPR would swallow that one). But, > then, how would we fit EXTCOMMs that are 64bits into 64bits ? > 3) Put a section in describing that in misconfiguration and using > the tag for supressing prefixes in SPF, blackholes may result. > 3) Put a section in that any tag that's supposed to be understood > globally and influence SPF must be brought to the group > thanks > - tony >> >> From rtg-dir-admin@ietf.org Tue Jun 3 17:26:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25053 for ; Tue, 3 Jun 2003 17:26:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NJGc-0002wA-00 for rtg-dir-archive@ietf.org; Tue, 03 Jun 2003 17:24:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NJGc-0002w7-00 for rtg-dir-archive@ietf.org; Tue, 03 Jun 2003 17:24:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53LQGB30854; Tue, 3 Jun 2003 17:26:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53LPAB30811 for ; Tue, 3 Jun 2003 17:25: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 RAA25041; Tue, 3 Jun 2003 17:25:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NJFV-0002vx-00; Tue, 03 Jun 2003 17:23:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19NJFV-0002vu-00; Tue, 03 Jun 2003 17:23:17 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19NJHC-000FSm-00; Tue, 03 Jun 2003 21:25:02 +0000 Date: Tue, 3 Jun 2003 14:24:42 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <66931382757.20030603142442@psg.com> To: "Tony Li" CC: isis-wg@ietf.org, "Routing Area Directorate" Subject: Re: [Isis-wg] RE: Comments on In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tony, Thanks for your reply. Below, pls. > Let me respond to all of Alex's comments at once... > How do I see vendor defined tags being used? I see them being used > for experimental purposes, for shipping some new functionality before > the implementation is wholly stable. As with any experimental object, > I would hope that it would eventually be documented and become > standardized. Just so we don't have to play proprietary IGP games yet > again. Experimental would be good. Vendor-specific for shipping would most probably trigger a similar discussion we had on the experimental TLVs. > | I-1. Tag TLVs introduced as any-size opaque transport containers, > | such inflatable "goodie-bags" with practically no internal > | structure (except for n x 32, or n x 64) where one can find > | tags, but also "all kind of nice proprietary things". > I submit to you that almost any experimental TLV can be used for this > purpose, or any obsolete TLV value, or any hijacked TLV could be used > fairly safely. So I don't believe that even if you eliminated this > proposal, you would deter anyone from including Finnegan's Wake in the > slightest. > The issue that I have with using this (or any TLV) for such fun is that > it's basically dishonest and unnecessarily so. If folks feel the > need to carry A Tale of Two Cities in their IGP, well, I'm not going > to stop them, but please, let's allocate some intelligent and opaque > TLV so that we all realize that this is someone's private sandbox. Agreed > That said, that doesn't seem like an issue that should deter this > proposal. As long as the issues have been discussed and well-understood. I like you proposal with some well-defined tags though. > | I-2. The problem of distributing 2547-related attributes addressed > | by introduction of the n x 64-bit opaque TLV, called 'tag'. > | Why are we overloading the notion of tag from the > | very beginning? > | Why not have a separate TLV and a proper spec for this? > Or, why not just explicitly allocate global tag values for 2547 > attributes? > I have no issue with this (above and beyond my general distaste for > 2547). Yes, seems this would work well too. Alex From rtg-dir-admin@ietf.org Tue Jun 3 19:24:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29714 for ; Tue, 3 Jun 2003 19:24:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NL6t-0003tN-00 for rtg-dir-archive@ietf.org; Tue, 03 Jun 2003 19:22:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NL6s-0003tK-00 for rtg-dir-archive@ietf.org; Tue, 03 Jun 2003 19:22:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53NOIB06925; Tue, 3 Jun 2003 19:24:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53NNtB06850 for ; Tue, 3 Jun 2003 19:23: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 TAA29695; Tue, 3 Jun 2003 19:23:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NL6S-0003sb-00; Tue, 03 Jun 2003 19:22:04 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19NL6R-0003sX-00; Tue, 03 Jun 2003 19:22:03 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19NL8A-000JZJ-00; Tue, 03 Jun 2003 23:23:50 +0000 Date: Tue, 3 Jun 2003 16:23:26 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <178938506831.20030603162326@psg.com> To: Tony Przygienda CC: isis-wg@ietf.org, Routing Area Directorate Subject: Re: [Isis-wg] RE: Comments on In-Reply-To: <3EDC71DC.9070301@xebeo.com> References: <3859276824.20030602182256@psg.com> <3EDC71DC.9070301@xebeo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tuesday, June 3, 2003, 3:01:00 AM, Tony Przygienda wrote: ... >>I-2. The problem of distributing 2547-related attributes addressed >> by introduction of the n x 64-bit opaque TLV, called 'tag'. >> Why are we overloading the notion of tag from the very beginning? >> Why not have a separate TLV and a proper spec for this? >> > Yes, we can have another draft, taking another sub-TLV point > specifically 2547. What's the difference of that beside having some > additional encoding rules that makes no difference in deployment > behavior ? The difference with a non-structured tag would be two-fold: 1. Separate sub-TLV wouldn't be reused for other purposes 2. Its contents and associated router behavior would be clearly documented. > Actually, the more I think about it, the more I come to > the conclusion that we should just pick up the EXTCOMM structure for > those 64-bit tags and reserve the same LOW types for the same > purposes. Introducing stricture inside the tag and reserving a value for the 2547 application would have the same effect as a separate sub-TLV. >>1. Why we should know what every tag means? >> I don't believe we should (see NI-1). >> > agreed, however if everybody wants everybody interoperating on a > specific tag value, a draft/RFC will be almost a must. Agreed. >> On the other hand, if the document intends to say that one of >> the applications of the tag is to control route distribution, >> it should request that compliant implementations support >> tag-based prefix filtering. Otherwise compliance to the spec >> will not mean anything to the SP who want to actually control >> prefix distribution. >> > not again, you can't force people to implement node-specific things. > Maybe they have high-end nodes that allow policies and low-end that > don't. Stop trying to mandate the internals of implementations. I don't know why you are talking about implementation internals here, and it is interesting that I have to argue this again, while we agreed on this point before: Alex Zinin wrote: >Here's my thinking here. > >The title of the document: > > "A Policy Control Mechanism in IS-IS Using Administrative Tags" > >The abstract says: > > "This document describes an extension to the IS-IS protocol to add > operational capabilities that allow for ease of management and > control over IP prefix distribution within an IS-IS domain. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ... > > This extension will provide operators with a mechanism to control IP > ^^^^^^^^^^^^^^^^^^^^^^^ > prefix distribution throughout multi-level IS-IS domains. > ^^^^^^^^^^^^^^^^^^^ > Additionally, the information can be placed in LSPs that have TLVs as > yet undefined, if this information is used to convey the same meaning > in these future TLVs as it is used in the currently defined TLVs." > >and one can definitely feel that filtering at the area boundaries is >one of the major applications of this TLV. > >However, because the document requests the compliant implementations >to only be able to insert the tag, but not filter using it at the >L1/L2 IS'es, an operator cannot expect all compliant implementations >to be useful for this function, i.e., they will need to ask if >functions outside the scope of this document are supported by specific >vendors, go into details of how they do that to make sure different >implementations can work together in a consistent way. Do you see what >I mean here? If you guys don't expect compliant implementations to actually be able 'control IP prefix distribution', then don't confuse the reader and remove hints on it in the text. If, on the other hand, SPs really want implementations of this document to be any more useful in prefix control than just flooding the TLV and displaying the value in the show command, then something like 'MUST support filtering on boundaries' would make sense in the document. Alex From rtg-dir-admin@ietf.org Wed Jun 4 04:49:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08251 for ; Wed, 4 Jun 2003 04:49:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NTwF-0007ep-00 for rtg-dir-archive@ietf.org; Wed, 04 Jun 2003 04:48:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NTwE-0007ei-00 for rtg-dir-archive@ietf.org; Wed, 04 Jun 2003 04:48:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548nvB26520; Wed, 4 Jun 2003 04:49:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h548mbB26450 for ; Wed, 4 Jun 2003 04:48: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 EAA08214; Wed, 4 Jun 2003 04:48:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NTuu-0007eI-00; Wed, 04 Jun 2003 04:46:44 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19NTut-0007eD-00; Wed, 04 Jun 2003 04:46:43 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h548lKZ30989; Wed, 4 Jun 2003 10:47:20 +0200 Date: Wed, 4 Jun 2003 10:47:20 +0200 From: Hannes Gredler To: Alex Zinin Cc: Acee Lindem , "Martin, Christian" , Stefano Previdi , Brad Neal , Routing Area Directorate , isis-wg@ietf.org Subject: Re: [Isis-wg] RE: Comments on Message-ID: <20030604084720.GA30860@juniper.net> References: <94B9091E1149D411A45C00508BACEB3503E289E7@entmail.gnilink.com> <20030525150331.GA15087@juniper.net> <3ED679BC.4060307@redback.com> <20030530222903.GA11581@juniper.net> <44859393983.20030602182453@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44859393983.20030602182453@psg.com> User-Agent: Mutt/1.3.28i Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Mon, Jun 02, 2003 at 06:24:53PM -0700, Alex Zinin wrote: | Hannes, | | Are the tag and tag2 both 32-bit tags taken from the same TLV or do | you have the 64-bit tags coded/deployed also? the code that is currently in the field does support only 32-bit tags; both tags are attached either to TLV 135 and 236 [pls have a look at the attached tcpdump output]; /hannes #tcpdump -nvr subtlv2.tcpdump 19:14:07.936565 OSI, IS-IS, length: 201 hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0), pdu-type: L1 LSP lsp-id: 0000.0000.0003-00, seq: 0x0000004f, lifetime: 65533s chksum: 0x23cb (correct), PDU length: 201, L1L2 IS Area address(es) TLV #1, length: 12 Area address (length: 1): 01 Area address (length: 5): 47.0002.0001 Area address (length: 3): 49.0001 Protocols supported TLV #129, length: 2 NLPID(s): IPv4, IPv6 Traffic Engineering Router ID TLV #134, length: 4 Traffic Engineering Router ID: 192.168.1.3 IPv4 Interface address(es) TLV #132, length: 4 IPv4 interface address: 192.168.1.3 Hostname TLV #137, length: 7 Hostname: speed-1 Extended IS Reachability TLV #22, length: 17 IS Neighbor: 0000.0000.0003.02, Metric: 10, sub-TLVs present (6) IPv4 interface address: 192.168.1.1 Extended IPv4 reachability TLV #135, length: 79 IPv4 prefix: 192.168.1.0/24, Distribution: up, Metric: 10, sub-TLVs present (10) 32-Bit Administrative tag: 0x00001267 (=4711) 32-Bit Administrative tag: 0x0000c000 (=49152) IPv4 prefix: 192.168.223.224/28, Distribution: up, Metric: 10, sub-TLVs present (10) 32-Bit Administrative tag: 0x00001267 (=4711) 32-Bit Administrative tag: 0x0000c000 (=49152) IPv4 prefix: 10.0.0.4/30, Distribution: up, Metric: 10, sub-TLVs present (10) 32-Bit Administrative tag: 0x00001267 (=4711) 32-Bit Administrative tag: 0x0000c000 (=49152) IPv4 prefix: 192.168.1.3/32, Distribution: up, Metric: 0, sub-TLVs present (10) 32-Bit Administrative tag: 0x00001267 (=4711) 32-Bit Administrative tag: 0x0000c000 (=49152) IPv6 reachability TLV #236, length: 33 IPv6 prefix: 2001:600::3/128, Distribution: up, Metric: 0, Internal, sub-TLVs present (10) 32-Bit Administrative tag: 0x00001267 (=4711) 32-Bit Administrative tag: 0x0000c000 (=49152) From rtg-dir-admin@ietf.org Thu Jun 5 10:27:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28068 for ; Thu, 5 Jun 2003 10:27:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nvfx-0007O9-00 for rtg-dir-archive@ietf.org; Thu, 05 Jun 2003 10:25:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nvfw-0007O5-00 for rtg-dir-archive@ietf.org; Thu, 05 Jun 2003 10:25:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55ER1B08477; Thu, 5 Jun 2003 10:27:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EQDB08444 for ; Thu, 5 Jun 2003 10:26: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 KAA28040 for ; Thu, 5 Jun 2003 10:26:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nvf7-0007Nn-00 for rtg-dir@ietf.org; Thu, 05 Jun 2003 10:24:17 -0400 Received: from shockwave.systems.pipex.net ([62.241.160.9]) by ietf-mx with esmtp (Exim 4.12) id 19Nvf6-0007NB-00 for rtg-dir@ietf.org; Thu, 05 Jun 2003 10:24:16 -0400 Received: from tom3 (1Cust85.tnt2.lnd4.gbr.da.uu.net [62.188.131.85]) by shockwave.systems.pipex.net (Postfix) with SMTP id 424CD16000B07; Thu, 5 Jun 2003 15:25:34 +0100 (BST) Message-ID: <005e01c32b6e$3445ea60$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Alex Zinin" , "Yakov Rekhter" Cc: , Subject: Re: AD-review comments on draft-ietf-idr-bgp4-20 Date: Thu, 5 Jun 2003 15:23:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Some nits below but chiefly, what happened to the comments on section 8, the section closest to my processing engine/heart? Tom Petch nwnetworks@dial.pipex.com >> >> > 5.1.2 AS_PATH >> ... >> > b) When a given BGP speaker advertises the route to an external >> > peer, then the advertising speaker updates the AS_PATH attribute >> > as follows: >> > >> > 1) if the first path segment of the AS_PATH is of type >> > AS_SEQUENCE, the local system prepends its own AS number as the >> > last element of the sequence (put it in the leftmost position). >> >> 'Leftmost position'... isn't this still open for interpretation? How >> about wording this relative to the position of the octets in the >> protocol message? > >I'll replace "the leftmost position" with "the leftmost position with >respect to the position of octets in the protocol message". I find this less clear - and I am never comfortable with left as I do not know how well it translates in other cultures; I prefer a numeric reference which I believe translates better. But here, I see the problem arising from the use of first and last without saying first or last what; first octet/AS number/path segment encountered in decoding the packet? first prepend? I think it is that that needs fixing rather than left. Also, while the order of AS within a path segment is said to be significant, I see nothing about the order of the path segments themselves which matters as much(in 4.3 perhaps) And can we get ie do we need to cater for an AS_PATH consisting of AS_SEQUENCE AS_SET AS_SEQUENCE ? >> > 6. BGP Error Handling. >> ... >> > The phrase "the BGP connection is closed" means that the TCP connec- >> > tion has been closed, the associated Adj-RIB-In has been cleared, and >> > that all resources for that BGP connection have been deallocated. >> > Entries in the Loc-RIB associated with the remote peer are marked as >> > invalid. The fact that the routes have become invalid is passed to >> > other BGP peers before the routes are deleted from the system. >> >> What does "the fact is passed" mean? Should we instead say that local >> route recalculation happens and peers are sent either updated best >> routes or withdrawals? > >How about the following replacement for the last sentence: > > The local system recalculates its best routes for the destinations > of the routes marked as invalid, and advertises to its peers either > withdraws for the routes marked as invalid, or the new best routes > before the invalid routes are deleted from the system. I find this ambiguous. Does it mean The local system recalculates its best routes for the destinations of the routes marked as invalid and - before the invalid routes are deleted from the system - advertises to its peers either the new best routes or, if no route now exists, withdrawals for the routes marked as invalid. ? >> > If the UPDATE message is received from an external peer, the local >> > system MAY check whether the leftmost AS in the AS_PATH attribute is >> >> Same comment about 'leftmost'... Maybe we should define this somewhere >> in the beginning of the spec? > >I will replace "the leftmost AS" with "the leftmost AS with >respect to the position of octets in the protocol message". as above > >> > 9.1.1 Phase 1: Calculation of Degree of Preference >> ... >> > If the route is learned from an external peer, then the local BGP >> > speaker computes the degree of preference based on preconfigured >> > policy information. If the return value indicates that the route >> > is ineligible, the route MAY NOT serve as an input to the next >> > phase of route selection; otherwise the return value is used as >> > the LOCAL_PREF value in any IBGP readvertisement. >> >> So, AFAIK, the major implementations do not follow this step >> (calculating the degree of preference, and then announcing). Instead, >> implementations allow setting the LOCAL_PREF value locally, which is >> taken into consideration during the best path selection, and is also >> reannounced further. > >It is important to keep in mind that the whole section on the BGP >decision process does *not* mean that an implementation must implement >it precisely as it is described in the spec, as long as the implementation >support the described functionality and its externally visible behavior >is the same. With this in mind how about if I'll add the following: > > The BGP Decision Process in this document is conceptual and do does > not have to be implemented precisely as described here, as long > as the implementations support the described functionality and > their externally visible behavior is the same. From rtg-dir-admin@ietf.org Thu Jun 5 11:37:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03306 for ; Thu, 5 Jun 2003 11:37:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nwli-0000Ri-00 for rtg-dir-archive@ietf.org; Thu, 05 Jun 2003 11:35:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Nwlh-0000Re-00 for rtg-dir-archive@ietf.org; Thu, 05 Jun 2003 11:35:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Fb1B14461; Thu, 5 Jun 2003 11:37:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FaTB14412 for ; Thu, 5 Jun 2003 11:36: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 LAA03252 for ; Thu, 5 Jun 2003 11:36:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwlA-0000RP-00 for rtg-dir@ietf.org; Thu, 05 Jun 2003 11:34:36 -0400 Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 19Nwl9-0000RM-00 for rtg-dir@ietf.org; Thu, 05 Jun 2003 11:34:35 -0400 Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA44744; Thu, 5 Jun 2003 11:34:47 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200306051534.LAA44744@workhorse.fictitious.org> To: "Tom Petch" cc: "Alex Zinin" , "Yakov Rekhter" , idr@merit.edu, rtg-dir@ietf.org Reply-To: curtis@fictitious.org Subject: Re: AD-review comments on draft-ietf-idr-bgp4-20 In-reply-to: Your message of "Thu, 05 Jun 2003 15:23:27 BST." <005e01c32b6e$3445ea60$0301a8c0@tom3> Date: Thu, 05 Jun 2003 11:34:47 -0400 From: Curtis Villamizar Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , In message <005e01c32b6e$3445ea60$0301a8c0@tom3>, "Tom Petch" writes: > > And can we get ie do we need to cater for an AS_PATH consisting of > AS_SEQUENCE > AS_SET > AS_SEQUENCE > ? We used to see AS_SEQUENCE AS_SET and other combinations are valid. If an aggregator does create an AS_SET, then the route can be passed along and an AS_SEQUENCE added to it. I suppose if you got "a x y" and "b x y" the AS_PATH "[a,b] x y" would be a valid aggregate, although I don't know of anyone who does this. On the left to right topic, where is AS path notation specified (besides RPSL)? I didn't find it in the CIDR RFCs. If unspecified, then we should get rid of references to leftmost or rightmost. Curtis From rtg-dir-admin@ietf.org Fri Jun 6 11:43:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29018 for ; Fri, 6 Jun 2003 11:43:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJL3-0003Fk-00 for rtg-dir-archive@ietf.org; Fri, 06 Jun 2003 11:41:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OJL2-0003Fd-00 for rtg-dir-archive@ietf.org; Fri, 06 Jun 2003 11:41:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Fh1B02720; Fri, 6 Jun 2003 11:43:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FgWB02676 for ; Fri, 6 Jun 2003 11:42: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 LAA28974; Fri, 6 Jun 2003 11:42:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJKW-0003Ex-00; Fri, 06 Jun 2003 11:40:36 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19OJKV-0003EZ-00; Fri, 06 Jun 2003 11:40:35 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h56Ffwi9016089; Fri, 6 Jun 2003 11:41:58 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h56FfsSj016082; Fri, 6 Jun 2003 11:41:54 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h56FfmP09840; Fri, 6 Jun 2003 11:41:48 -0400 (EDT) Date: Fri, 6 Jun 2003 11:41:48 -0400 From: Jeffrey Haas To: Tony Li Cc: Alex Zinin , isis-wg@ietf.org, Routing Area Directorate Subject: Re: [Isis-wg] RE: Comments on Message-ID: <20030606114148.H8964@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Tony.Li@procket.com on Mon, Jun 02, 2003 at 09:47:43PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Mon, Jun 02, 2003 at 09:47:43PM -0700, Tony Li wrote: > How do I see vendor defined tags being used? I see them being used > for experimental purposes, for shipping some new functionality before > the implementation is wholly stable. As with any experimental object, > I would hope that it would eventually be documented and become > standardized. Just so we don't have to play proprietary IGP games yet > again. Is it worth specifying a transitional mechanism to move the ID out of the "experimental" space into the ietf-consensus numbered space? > I submit to you that almost any experimental TLV can be used for this > purpose, or any obsolete TLV value, or any hijacked TLV could be used > fairly safely. My concern has been collision in the numbering space. In the BGP extended community experimental numbering space, there is no guidance as to how you should pick your experimental number. I haven't seen vendors providing a knob to set the feature's community number and thus its possible for two vendors to utilize the same number and end up causing all sorts of havoc. I don't disagree with the idea of an experimental space, but it would be nice to at least talk about namespace collisions and how we might work around them. I would also prefer an answer isn't "this hurts", "Don't do that then!". > Tony -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Mon Jun 9 08:02:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29288 for ; Mon, 9 Jun 2003 08:02:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PLJh-00024r-00 for rtg-dir-archive@ietf.org; Mon, 09 Jun 2003 08:00:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PLJg-00024n-00 for rtg-dir-archive@ietf.org; Mon, 09 Jun 2003 08:00:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59C21B27159; Mon, 9 Jun 2003 08:02:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Bq9B26571 for ; Mon, 9 Jun 2003 07:52: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 HAA28979 for ; Mon, 9 Jun 2003 07:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PLA7-0001zX-00 for rtg-dir@ietf.org; Mon, 09 Jun 2003 07:50:07 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19PLA6-0001yo-00 for rtg-dir@ietf.org; Mon, 09 Jun 2003 07:50:06 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h59BpYpi022833; Mon, 9 Jun 2003 07:51:35 -0400 (EDT) Received: from russpc.nc.rr.com (rtp-vpn2-297.cisco.com [10.82.241.41]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA04644; Mon, 9 Jun 2003 07:51:34 -0400 (EDT) Date: Mon, 9 Jun 2003 07:51:38 -0400 (Eastern Daylight Time) From: Russ White Reply-To: Russ White To: Alex Zinin cc: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse In-Reply-To: <201059237092.20030523190456@psg.com> Message-ID: References: <93972307354.20030522185606@psg.com> <201059237092.20030523190456@psg.com> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , So.... I don't see it as any different that what's been used for OSPF, or eben EIGRP at this point, so I don't see any problem with carrying this information in BGP. I do, however, think the draft itself is a disaster. If this were to be presented, I'd insist it be rewritten in some form that people can actually understand. I've made some notes, but it's almost not even worth putting them on paper. Solutions are mentioned that weren't described, the grammer leaves me wondering what the author is talking about. The actual solution comprises three paragraphs or so, mostly just saying: "Do this like OSPF." It doesn't give any real details. In principle the concept is fine, I think. In implementation, the draft isn't. :-) Russ On Fri, 23 May 2003, Alex Zinin wrote: > Russ, > > > So, my general feeling is that if it's related to routing, carrying it in a > > routing protocol is fine. I've not looked at the ppvpn stuff close enough > > to say one way or the other, but BGP has already drawn these lines rather > > wide for us, as have other protocols, really. Tags for admin filtering, > > like communities, and other policy information--this information isn't > > really needed for finding a route to the destination, per se. > > > I'd probably draw the lines pretty wide, including policy and security > > information, > > Agreed. > > > but I've not looked at the ppvpn stuff close enough to know if > > I'd include that. > > Could you look at it, pls? > > Alex > __________________________________ riw@cisco.com CCIE <>< Grace Alone From rtg-dir-admin@ietf.org Mon Jun 9 12:31:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10783 for ; Mon, 9 Jun 2003 12:31:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PPW5-0004pz-00 for rtg-dir-archive@ietf.org; Mon, 09 Jun 2003 12:29:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PPW4-0004pw-00 for rtg-dir-archive@ietf.org; Mon, 09 Jun 2003 12:29:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59GV7B15048; Mon, 9 Jun 2003 12:31:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59GTvB14911 for ; Mon, 9 Jun 2003 12:29: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 MAA10720 for ; Mon, 9 Jun 2003 12:29:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PPUv-0004pQ-00 for rtg-dir@ietf.org; Mon, 09 Jun 2003 12:27:53 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19PPUu-0004pE-00 for rtg-dir@ietf.org; Mon, 09 Jun 2003 12:27:52 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h59GTN7r084888 for rtg-dir@ietf.org; Mon, 9 Jun 2003 12:29:23 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h59GTJiW084881 for ; Mon, 9 Jun 2003 12:29:19 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h59GTEs23383 for rtg-dir@ietf.org; Mon, 9 Jun 2003 12:29:14 -0400 (EDT) Date: Mon, 9 Jun 2003 12:29:14 -0400 From: Jeffrey Haas To: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse Message-ID: <20030609122914.C21916@nexthop.com> References: <93972307354.20030522185606@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <93972307354.20030522185606@psg.com>; from zinin@psg.com on Thu, May 22, 2003 at 06:56:06PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Warning: Lots of opinion follows. On Thu, May 22, 2003 at 06:56:06PM -0700, Alex Zinin wrote: > The discussion about appropriate and inappropriate applications of IP > routing protocols has been going on for quite a while. The most > noticeable outburst of it could be correlated with appearance of 2547 > ;), however, this is not what I'd like us to talk about now. > > I'd like to draw your attention to the following draft-- > draft-kompella-ppvpn-vpls-01.txt As Russ mentioned, this document needs some cleanup. However, the document draft-kompella-ppvpn-l2vpn-03.txt is very well written and seems to do a nice job of summarizing the benefits and the problems of its features. Unfortunatley, I can't find the document referred to by as: "MPLS-based Layer 2 VPNs". The complete lack of draft ID's in the references makes it incredibly hard to trace these issues if you don't follow things on a regular basis. > --which proposes to use BGP for VPLS (L2 VPN service) discovery and > signaling. In particular, please pay attention to the way the > semantics of the NLRI field have been changed (section 3.2.1), and to > the fact the best path selection algorithm is not employed at all. To address these particular points: o I find the overloading of the NLRI field in these documents to be slightly problematic - but only slightly. The NLRI field has been traditionally used to bind network layer reachability (go figure) and a set of path attributes together. In 2547, we extend this to include a route distinguisher and a MPLS label stack. While this blurs the idea of "network layer" it is still consistent with enumerating reachability (and really extending it by allowing for multiple overlapping address/naming spaces). The fact that the label stack is included in the NLRI is, at first glance, a bit kinky. Traditionally, this sort of information has been encoded in the path attributes. The important difference here is that this information is generally applicable on a PER-PREFIX basis. In other words, were we to not bind it at the NLRI point, we'd be generating a ton of BGP PDU's in order to encode the same information. Thus, uncleanness aside, this is mostly optimal for the application. I'll note that a cleaner method would have been to have some mechanism which clearly states the keying portion of the NLRI and the additional properties. Right now, this is done by knowing how to decode a particular AFI/SAFI. In draft-kompella-ppvpn-vpls-01 and draft-kompella-ppvpn-l2vpn-03, we go a step further than this. We are no longer passing network layer reachability, we are passing completely non-IP information. However, we are still passing entities that serve as endpoints, some of it being "keying" information, some of it things that are bound on a per-key basis. Thus, the 2547 analogy still holds. What at first glance appears "gross/ugly", the TLVs in the NLRI, actually formailzes what we're doing: Making the binding of per-"prefix" or per-"key" information explicit. While I, and several others including Pedro, find this practice unsightly, the representation makes sense. Its no longer IP, but it still makes sense. o Best path selection not used I dug around pretty hard to find out where this is stated. It really isn't. I thought about "well, if it isn't used, what are the implications?" In the intra-domain case, we could (as a contrived for-example) dispense with passing things around in BGP and move to a method by which the information is flooded in the traditional sense, perhaps using a reliable multicast mechanism. However, we know that this information is meant to be able to be used in the inter-domain case. So, what does this mean? It means that policy is intended to be exercised in connecting the tunnel endpoints. Pedro specifically pointed out some of the older issues that were a problem with various ATM overlay technologies. The lack of policy led to suboptimal usage of the network. In any case where a given "prefix" is advertised by more than one BGP speaker, we need the ability to choose which one we're going to want. Default policy can serve here along with other BGP policy mechanisms. I'm still disturbed by the fact that normal policy mechanisms, such as extended communities, are used to distribute membership. Thus, misconfiguration of policy on extended communities is potentially hazardous to the correct operation of your VPN-fu. This is a separate issue. So, default bgp path selection is used and seems appropriate. If we were limiting advertisement of this information by only a single speaker of some sort, flooding would be quite appropriate and probably a *lot* less ugly. However, there are good cases for wanting to use policy. Even with this said, perhaps a flooding mechanism would be nicer - one where some policy could be exercised. This would be motivated by the fact that these routes are likely to be essentially identical once distributed into your iBGP and the BGP property of maintaining a copy in your Adj-Ribs-In for each speaker is potentially noisier than need be. This is probably worth more general study and I'm aware that some companies are pursuing this already. > These two facts--loss of any addressing semantics, and loss of best > path selection--make me think that the proposed approach essentially > transforms BGP into what I call a "universal transport system." > > There two questions here: > > 1. Where is the line between appropriate and inappropriate use > of routing protocols in general, and BGP in particular (there > maybe different aspects between LS IGPs that have a pure > transport/flooding component, and BGP whose info relaying > behavior is tightly coupled with the best path selection algo.) Lets split the line even further: What is suitable to carry in BGP as a protocol: "reachability" should go in the NLRI field. It is probably ok to bind per-reachability information there as well, but only if it is tightly bound. "Tightly" would imply something that is likely to be bound to the reachability such that it is likely to poorly belong in the path attributes. Additionally, given mechanisms such as WRD and the stability of reachability, things shouldn't be placed in a BGP PDU that are expected to wildly fluctuate. Bits of BGP are very expensive to run due to its general scaling properties. MED election and policy, for example, are "expensive" to run although less expensive than running Dijkstra for a similar amount of information. (Incremental updates in your protocol can be a big friend in scaling.) This point trends to the other half of the line - operational issues and scaling: Just because things can be encoded well in the protocol, doesn't mean that the entire protocol infrastructure is going to be able to put up with the relative load. We currently pass everything from peer to peer over a single TCP session multiplexing the PDU's for our various AFI/SAFIs. The implication of this is that while the cost of building BGP PDU's and putting them onto your TCP stream is relatively low, it means that you must be *very* careful to balance your priorities. BGP was designed to carry inter-domain reachability. For every application that we layer on BGP, we must preserve the ability of a box to keep up with its Internet reachability since the convergence of the entire routing system is dependent on its component parts. My concern, shared by others, is that by putting all of this extra stuff in the protocol, we are potentially harming the scalability of the Internet routing system. This is not to say that knowledgable design choices can't make things work, but these choices are hard to get right. My gut instinct is that moving stuff that uses the BGP protocol but isn't used for Internet transport off to a separate protocol instance and transport session, but that simplistically assumes that it is "that easy" to separate the guts of the pieces in the box for something that consumes so many resources. But there's the general idea - make sure that you've built things so you don't hurt the Internet - and then make your value-add services work. > 2. Does the draft in question cross this line? The only bit I find seriously questionable is the RSN TLV. It seems like something that is likely to cause excess flapping. It would take someone describing how it behaves in the field for us to know for sure. One final note: While reading through these drafts, it was clear that the MP-Nexthop field in the Kompella drafts wasn't properly documented. It has been my general assumption that the MP-Nexthop would always be of the same form as the NLRI for an AFI/SAFI. In this case, the NLRI contains no IP information, which is necessary to derive the tunnel end-point. RFC2858 doesn't say that this happens at all, it is left ambiguous. The Kompella documents need to spell out what their nexthop looks like and how it is used. -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Tue Jun 10 00:12:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00323 for ; Tue, 10 Jun 2003 00:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PaSO-0001Li-00 for rtg-dir-archive@ietf.org; Tue, 10 Jun 2003 00:10:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PaSN-0001Lf-00 for rtg-dir-archive@ietf.org; Tue, 10 Jun 2003 00:09:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A4C2B32067; Tue, 10 Jun 2003 00:12:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A4BcB32046 for ; Tue, 10 Jun 2003 00:11: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 AAA00317 for ; Tue, 10 Jun 2003 00:11:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PaRy-0001LW-00 for rtg-dir@ietf.org; Tue, 10 Jun 2003 00:09:34 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19PaRx-0001LT-00 for rtg-dir@ietf.org; Tue, 10 Jun 2003 00:09:33 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19PaTv-000DEs-00 for rtg-dir@ietf.org; Tue, 10 Jun 2003 04:11:35 +0000 Date: Mon, 9 Jun 2003 21:11:13 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <629693228.20030609211113@psg.com> To: rtg-dir@ietf.org Subject: Under IESG review: draft-ietf-multi6-multihoming-requirements-06 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This is a short one, but supposed to be important. Please sanity-check by end of Wed. Thanks. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Tue Jun 10 07:00:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19962 for ; Tue, 10 Jun 2003 07:00:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pgq7-0003eC-00 for rtg-dir-archive@ietf.org; Tue, 10 Jun 2003 06:58:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pgq6-0003e9-00 for rtg-dir-archive@ietf.org; Tue, 10 Jun 2003 06:58:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AB11B08545; Tue, 10 Jun 2003 07:01:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AB0dB08489 for ; Tue, 10 Jun 2003 07:00: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 HAA19947 for ; Tue, 10 Jun 2003 07:00:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pgpj-0003e1-00 for rtg-dir@ietf.org; Tue, 10 Jun 2003 06:58:31 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19Pgpj-0003dw-00 for rtg-dir@ietf.org; Tue, 10 Jun 2003 06:58:31 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5AB02pi023530; Tue, 10 Jun 2003 07:00:02 -0400 (EDT) Received: from dhcp-64-102-60-152.cisco.com (dhcp-64-102-60-152.cisco.com [64.102.60.152]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA09331; Tue, 10 Jun 2003 07:00:01 -0400 (EDT) Date: Tue, 10 Jun 2003 07:00:37 -0400 (EDT) From: Russ White Reply-To: Russ White To: Alex Zinin cc: rtg-dir@ietf.org Subject: Re: Under IESG review: draft-ietf-multi6-multihoming-requirements-06 In-Reply-To: <629693228.20030609211113@psg.com> Message-ID: References: <629693228.20030609211113@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , This seems like the critical paragraph: It would be compatible with this goal for such a host to lose connectivity if a site lost connectivity to one transit provider, despite the fact that other transit provider connections were still operational. Hmm... I'm not positive about this part, so I'll wait and see what others think, but other than this, it all looks fine. :-) Russ On Mon, 9 Jun 2003, Alex Zinin wrote: > > This is a short one, but supposed to be important. > Please sanity-check by end of Wed. > Thanks. > > -- > Alex > http://www.psg.com/~zinin/ > __________________________________ riw@cisco.com CCIE <>< Grace Alone From rtg-dir-admin@ietf.org Tue Jun 10 09:57:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00348 for ; Tue, 10 Jun 2003 09:57:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjaU-0006Un-00 for rtg-dir-archive@ietf.org; Tue, 10 Jun 2003 09:54:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PjaT-0006Uj-00 for rtg-dir-archive@ietf.org; Tue, 10 Jun 2003 09:54:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADv1B23863; Tue, 10 Jun 2003 09:57:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADulB23847 for ; Tue, 10 Jun 2003 09:56: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 JAA00321 for ; Tue, 10 Jun 2003 09:56:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjaC-0006UW-00 for rtg-dir@ietf.org; Tue, 10 Jun 2003 09:54:40 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19PjaA-0006U1-00 for rtg-dir@ietf.org; Tue, 10 Jun 2003 09:54:39 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h5ADu1gt013262; Tue, 10 Jun 2003 09:56:01 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h5ADtuiW013254; Tue, 10 Jun 2003 09:55:56 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h5ADtpa02580; Tue, 10 Jun 2003 09:55:51 -0400 (EDT) Date: Tue, 10 Jun 2003 09:55:51 -0400 From: Jeffrey Haas To: Russ White Cc: Alex Zinin , rtg-dir@ietf.org Subject: Re: Under IESG review: draft-ietf-multi6-multihoming-requirements-06 Message-ID: <20030610095551.B2439@nexthop.com> References: <629693228.20030609211113@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ruwhite@cisco.com on Tue, Jun 10, 2003 at 07:00:37AM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Tue, Jun 10, 2003 at 07:00:37AM -0400, Russ White wrote: > It would be compatible with this goal for such a host to lose > connectivity if a site lost connectivity to one transit provider, > despite the fact that other transit provider connections were still > operational. > > Hmm... I'm not positive about this part, so I'll wait and see what others > think, but other than this, it all looks fine. I'll agree - the general "goals" sound good. Unfortunately, I think we're going to find that actually pursuing those goals are going to make DNS and transport connection issues a serious pain in the stack. > Russ -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Tue Jun 10 11:56:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06523 for ; Tue, 10 Jun 2003 11:56:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PlRg-0007fF-00 for rtg-dir-archive@ietf.org; Tue, 10 Jun 2003 11:54:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PlRf-0007fC-00 for rtg-dir-archive@ietf.org; Tue, 10 Jun 2003 11:53:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFu1B01649; Tue, 10 Jun 2003 11:56:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFr5B01472 for ; Tue, 10 Jun 2003 11:53: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 LAA06395 for ; Tue, 10 Jun 2003 11:53:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PlOm-0007dB-00 for rtg-dir@ietf.org; Tue, 10 Jun 2003 11:51:00 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19PlOk-0007ch-00 for rtg-dir@ietf.org; Tue, 10 Jun 2003 11:50:59 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h5AFqJu74010; Tue, 10 Jun 2003 08:52:19 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200306101552.h5AFqJu74010@merlot.juniper.net> To: "Tom Petch" cc: "Alex Zinin" , "Yakov Rekhter" , idr@merit.edu, rtg-dir@ietf.org, yakov@juniper.net Subject: Re: AD-review comments on draft-ietf-idr-bgp4-20 In-Reply-To: Your message of "Thu, 05 Jun 2003 15:23:27 BST." <005e01c32b6e$3445ea60$0301a8c0@tom3> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31825.1055260339.1@juniper.net> Date: Tue, 10 Jun 2003 08:52:19 -0700 From: Yakov Rekhter Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Tom, > Some nits below but chiefly, what happened to the comments on section > 8, the section closest to my processing engine/heart? Sue is going to respond to the comments on section 8. Yakov. From rtg-dir-admin@ietf.org Wed Jun 11 02:23:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20828 for ; Wed, 11 Jun 2003 02:23:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pyza-0004yZ-00 for rtg-dir-archive@ietf.org; Wed, 11 Jun 2003 02:21:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pyza-0004yW-00 for rtg-dir-archive@ietf.org; Wed, 11 Jun 2003 02:21:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B6O1B09173; Wed, 11 Jun 2003 02:24:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B6NbB09155 for ; Wed, 11 Jun 2003 02:23: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 CAA20423 for ; Wed, 11 Jun 2003 02:23:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PyzA-0004yT-00 for rtg-dir@ietf.org; Wed, 11 Jun 2003 02:21:28 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Pyz9-0004yQ-00 for rtg-dir@ietf.org; Wed, 11 Jun 2003 02:21:27 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19Pz13-000BMh-00; Wed, 11 Jun 2003 06:23:25 +0000 Date: Wed, 11 Jun 2003 02:23:05 -0400 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <10913988284.20030611022305@psg.com> To: Jeffrey Haas CC: rtg-dir@ietf.org Subject: Re: Meta: routing protocol abuse In-Reply-To: <20030609122914.C21916@nexthop.com> References: <93972307354.20030522185606@psg.com> <20030609122914.C21916@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff, Russ- Thanks for your thoughts. I did read them and will follow up within a couple of days--traveling now. Alex From rtg-dir-admin@ietf.org Wed Jun 11 23:25:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13128 for ; Wed, 11 Jun 2003 23:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QIfw-0006EF-00 for rtg-dir-archive@ietf.org; Wed, 11 Jun 2003 23:22:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QIfw-0006EB-00 for rtg-dir-archive@ietf.org; Wed, 11 Jun 2003 23:22:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C3P1m31455; Wed, 11 Jun 2003 23:25:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C3OGm31416 for ; Wed, 11 Jun 2003 23:24: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 XAA13112 for ; Wed, 11 Jun 2003 23:24:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QIfB-0006Dx-00 for rtg-dir@ietf.org; Wed, 11 Jun 2003 23:22:09 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19QIfA-0006Dt-00 for rtg-dir@ietf.org; Wed, 11 Jun 2003 23:22:08 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19QIhC-0009uG-00 for rtg-dir@ietf.org; Thu, 12 Jun 2003 03:24:14 +0000 Date: Wed, 11 Jun 2003 23:23:52 -0400 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5189635999.20030611232352@psg.com> To: rtg-dir@ietf.org Subject: Fwd: Design Team for ASON Routing Requirements In-Reply-To: <20030611142552.F45816@kummer.juniper.net> References: <20030611142552.F45816@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Guys, I'd like to see a couple of routing geeks on this DT. Preferably someone with routing & GMPLS knowledge. Volunteers/recommendations? -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Kireeti Kompella To: "Wijnen, Bert" , Alex Zinin Cc: "Ronald P. Bonica" , Kireeti Kompella Date: Wednesday, June 11, 2003, 5:36:42 PM Subject: Design Team for ASON Routing Requirements ===8<==============Original message text=============== Hi All, I've been at the interim ITU-T meeting for Q14/15 most of this week, and one the most important takeaways is that, whatever happened/happens with signaling, let us (IETF & ITU) not make the same mistakes with routing. To support this, I think we should like to create a design team for ASON requirements for routing, again with the same groundrules as for the ASON requirements for signaling, i.e., DON'T redo ASON requirements, but list the relevant reqts that ASON needs and GMPLS routing doesn't have. A tentative list of DT members: Wesam Alanqar (carrier) Deborah Brungard (carrier) Lyndon Ong (vendor) Dimitri Papadimitriou (vendor) Jonathan Sadler (vendor) Stephen Shew (vendor) Comments? Should we go ahead? Kireeti. ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Wed Jun 18 19:52:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07025 for ; Wed, 18 Jun 2003 19:52:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SmhF-0003vf-00 for rtg-dir-archive@ietf.org; Wed, 18 Jun 2003 19:50:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SmhF-0003vb-00 for rtg-dir-archive@ietf.org; Wed, 18 Jun 2003 19:50:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Smhg-00049B-T6; Wed, 18 Jun 2003 19:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SmZ2-0003yY-UK for rtg-dir@optimus.ietf.org; Wed, 18 Jun 2003 19:42: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 TAA06374 for ; Wed, 18 Jun 2003 19:42:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SmWm-0003jX-00 for rtg-dir@ietf.org; Wed, 18 Jun 2003 19:39:44 -0400 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19SmWl-0003jD-00 for rtg-dir@ietf.org; Wed, 18 Jun 2003 19:39:43 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h5INZq3j020290 for ; Wed, 18 Jun 2003 19:35:52 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h5INdsXs004408 for ; Wed, 18 Jun 2003 19:39:54 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h5INfWk11861; Wed, 18 Jun 2003 16:41:32 -0700 (PDT) Message-Id: <200306182341.h5INfWk11861@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-dir@ietf.org Subject: Recruitment of Experimental SIRs Date: Wed, 18 Jun 2003 16:41:31 -0700 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Just a note, in case anyone hasn't seen this. Directorate members are qualified to be a SIR if you want more work to do =). Bill ----- Begin forwarded message: From: Dave Crocker Subject: Recruitment of Experimental SIRs Date: Mon, 2 Jun 2003 13:12:47 -0700 Organization: Brandenburg InternetWorking To: ietf@ietf.org Cc: Brian E Carpenter Folks, We'd like to run a proof-of-concept version of the Senior Internet Reviewer (SIR) activity, prior to obtaining formal IETF "blessing" for it. The proposal is discussed in: It recruits experienced IETF participants to provide additional and iterative review to working group efforts. The IETF community assigns the status of SIR, but the working group recruits individual SIRs to do reviews. An experimental version of the service is at: Anyone who is qualified to be a SIR, according to the objective "bootstrapping" criteria in the proposal, should contact me to get listed on the SIRS web page. The objective are: * all current IAB members * all former IAB and IESG members, and former WG Chairs, who the Secretariat can contact and who are willing to serve * all current MIB Doctors * all members of existing IETF Directorates * all authors of at least three RFCs, who the Secretariat can contact and who are willing to serve Thanks. d/ ps. Suggestions for modifications to the proposal are still eagerly sought. -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , _______________________________________________ This message was passed through ietf_censored@carmen.ipv6.cselt.it, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio. ----- End forwarded message: From rtg-dir-admin@ietf.org Mon Jun 23 10:50:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23334 for ; Mon, 23 Jun 2003 10:50:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19USeB-0002gf-00 for rtg-dir-archive@ietf.org; Mon, 23 Jun 2003 10:50:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19USe5-0002fu-00 for rtg-dir-archive@ietf.org; Mon, 23 Jun 2003 10:50:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UScv-00041s-C4; Mon, 23 Jun 2003 10: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 19UDeq-0006It-Ra for rtg-dir@optimus.ietf.org; Sun, 22 Jun 2003 18:51: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 SAA21489 for ; Sun, 22 Jun 2003 18:49:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UDeY-0005vW-00 for rtg-dir@ietf.org; Sun, 22 Jun 2003 18:49:42 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19UDeM-0005v9-00 for rtg-dir@ietf.org; Sun, 22 Jun 2003 18:49:30 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h5MMmWs8024239 for rtg-dir@ietf.org; Sun, 22 Jun 2003 18:48:32 -0400 (EDT) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([65.247.36.233]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h5MMm7dt024189 for ; Sun, 22 Jun 2003 18:48:07 -0400 (EDT) (envelope-from shares@nexthop.com) Subject: RE: AD-review comments on draft-ietf-idr-bgp4-20 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C33910.55DB7DB6" Date: Sun, 22 Jun 2003 18:48:01 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: X-MS-Has-Attach: yes Content-Class: urn:content-classes:message Thread-Topic: AD-review comments on draft-ietf-idr-bgp4-20 Thread-Index: AcMvaF3YHlAlUExKR5C2hi5CHS4l6AJp80fQ From: "Susan Hares" To: "Yakov Rekhter" , "Tom Petch" Cc: "Alex Zinin" , , X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C33910.55DB7DB6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tom: Since you are the person who has FSM near and dear to your heart, could you look at the FSM only draft attached to see if you enjoy it. Sue -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Tuesday, June 10, 2003 11:52 AM To: Tom Petch Cc: Alex Zinin; Yakov Rekhter; idr@merit.edu; rtg-dir@ietf.org; yakov@juniper.net Subject: Re: AD-review comments on draft-ietf-idr-bgp4-20=20 Tom, > Some nits below but chiefly, what happened to the comments on section > 8, the section closest to my processing engine/heart? Sue is going to respond to the comments on section 8. Yakov. ------_=_NextPart_001_01C33910.55DB7DB6 Content-Type: text/plain; name="fsm-v2.txt" Content-Description: fsm-v2.txt Content-Disposition: attachment; filename="fsm-v2.txt" Content-Transfer-Encoding: base64 DQoNCiAgICAgDQoNCg0KOC4gQkdQIEZpbml0ZSBTdGF0ZSBtYWNoaW5lDQoNCg0KICAgVGhpcyBz ZWN0aW9uIHNwZWNpZmllcyB0aGUgQkdQIG9wZXJhdGlvbiBpbiB0ZXJtcyBvZiBhIEZpbml0ZSBT dGF0ZQ0KICAgTWFjaGluZSAoRlNNKS4gIFRoZSBzZWN0aW9uIGZhbGxzIGludG8gMiBwYXJ0czoN Cg0KICAgICAgICAgIDEpIERlc2NyaXB0aW9uIG9mIEV2ZW50cyBmb3IgdGhlIFN0YXRlIG1hY2hp bmUgKFNlY3Rpb24gOC4xKQ0KICAgICAgICAgIDIpIERlc2NyaXB0aW9uIG9mIHRoZSBGU00gKFNl Y3Rpb24gOC4yKQ0KDQogICBTZXNzaW9uIEF0dHJpYnV0ZXMgcmVxdWlyZWQgZm9yIGVhY2ggY29u bmVjdGlvbiBhcmU6IA0KDQogICAgICAgICAxKSBTdGF0ZQ0KICAgICAgICAgMikgQ29ubmVjdFJl dHJ5VGltZXINCiAgICAgICAgIDMpIEhvbGRUaW1lcg0KICAgICAgICAgNCkgSG9sZFRpbWUNCiAg ICAgICAgIDUpIEtlZXBhbGl2ZVRpbWVyDQogICAgICAgICA2KSBLZWVwYWxpdmVUaW1lDQogICAg ICAgICA3KSBDb25uZWN0UmV0cnlDb3VudGVyDQogICAgICAgICA4KSBDb25uZWN0UmV0cnlJbml0 aWFsVmFsdWUNCg0KDQoNCg0KRXhwaXJhdGlvbiBEYXRlIFNlcHRlbWJlciAyMDAzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDFtQYWdlIDM2XQ0KDQoNCg0KDQoNClJGQyBEUkFGVCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2gg MjAwMw0KDQoNCiAgIFRoZSBvcHRpb25hbCBTZXNzaW9uIGF0dHJpYnV0ZXMgYXJlIGxpc3RlZCBi ZWxvdy4gVGhlc2Ugb3B0aW9uYWwNCiAgIGF0dHJpYnV0ZXMgbWF5IGJlIHN1cHBvcnRlZCBlaXRo ZXIgcGVyIGNvbm5lY3Rpb24gb3IgcGVyIGxvY2FsIHN5cy0NCiAgIHRlbToNCg0KICAgICAgICAx KSBBY2NlcHRDb25uZWN0aW9uc1VuY29uZmlndXJlZFBlZXJzDQoJMikgQWxsb3dBdXRvbWF0aWNT dGFydA0KCTMpIEFsbG93QXV0b21hdGljU3RvcA0KCTQpIENvbGxpc2lvbkRldGVjdEVzdGFibGlz aGVkU3RhdGUNCgk1KSBEYW1wUGVlck9zY2lsbGF0aW9ucw0KCTYpIERlbGF5T3BlbiANCiAgICAg ICAgNykgRGVsYXlPcGVuVGltZXINCgk4KSBJZGxlSG9sZFRpbWVyDQogICAgICAgIDkpIFBhc3Np dmVUQ1BFc3RhYmxpc2htZW50DQogICAgICAgMTApIFNlbmROT1RJRklDQVRJT053aXRob3V0T1BF Tg0KICAgICAgIDExKSBUcmFja1RDUFN0YXRlDQogICANCiAgVGhlIG9wdGlvbmFsIHNlc3Npb24g YXR0cmlidXRlcyBzdXBwb3J0IGRpZmZlcmVudCBmZWF0dXJlcyBvZiB0aGUgQkdQDQogIGZ1bmN0 aW9uYWxpdHkgdGhhdCBoYXZlIGltcGxpY2F0aW9ucyBmb3IgdGhlIEJHUCBGU00gc3RhdGUNCiAg dHJhbnNpdGlvbnMuICAgRm9yIGV4YW1wbGUsIHRoZSBEZWxheU9wZW4gb3B0aW9uYWwgYXR0cmli dXRlIGFsbG93cw0KICB0aGUgQkdQIE9wZW4gbWVzc2FnZSB0byBiZSBkZWxheWVkIHdoaWxlIHdh aXRpbmcgZm9yIHRoZSByZW1vdGUgQkdQIHBlZXINCiAgdG8gc2VuZCB0aGUgZmlyc3QgT1BFTi4g IFBsZWFzZSByZWZlciB0byBzZWN0aW9uIDguMS4xIGZvciBhbiBleHBsYW5hdGlvbg0KICBvZiB0 aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiB0aGVzZSBvcHRpb25hbCBhdHRyaWJ1dGVzIGFuZCB0aGUg RXZlbnRzDQogIHNpZ25hbGVkIHRvIHRoZSBzdGF0ZSBtYWNoaW5lLg0KDQoNCjguMSBFdmVudHMg Zm9yIHRoZSBCR1AgRlNNDQoNCjguMS4xIE9wdGlvbmFsIEV2ZW50cyBsaW5rZWQgdG8gT3B0aW9u YWwgU2Vzc2lvbiBhdHRyaWJ1dGVzDQoNCg0KICAgVGhlIElucHV0cyB0byB0aGUgQkdQIEZTTSBh cmUgZXZlbnRzLiAgRXZlbnRzIGNhbiBlaXRoZXIgYmUgbWFuZGF0b3J5IG9yDQogICBvcHRpb25h bC4gIFNvbWUgb3B0aW9uYWwgZXZlbnRzIGFyZSBsaW5rZWQgdG8gb3B0aW9uYWwgc2Vzc2lvbiBh dHRyaWJ1dGVzLg0KICAgT3B0aW9uYWwgc2Vzc2lvbiBhdHRyaWJ1dGVzIGVuYWJsZSBzZXZlcmFs IGdyb3VwcyBvZiBGU00gZnVuY3Rpb25hbGl0eS4NCg0KICAgVGhlIGRlc2NyaXB0aW9uIGJlbG93 IGRlc2NyaWJlcyB0aGUgbGlua2FnZSBiZXR3ZWVuIEZTTSBmdW5jdGlvbmFsaXR5LCBldmVudHMN CiAgIGFuZCB0aGUgb3B0aW9uYWwgc2Vzc2lvbiBhdHRyaWJ1dGVzLiANCg0KDQogICBHcm91cCAx OiBBdXRvbWF0aWMgQWRtaW5pc3RyYXRpdmUgRXZlbnRzIChTdGFydC9TdG9wKSANCg0KCU9wdGlv bmFsIFNlc3Npb24gQXR0cmlidXRlczogQWxsb3dBdXRvbWF0aWNTdGFydCwgQWxsb3dBdXRvbWF0 aWNTdGFydCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZGxlSG9sZFRp bWVyLCBEYW1wUGVlck9zY2lsbGF0aW9ucw0KCQ0KCU9wdGlvbiAxOglBbGxvd0F1dG9tYXRpY1N0 YXJ0DQoJDQoJRGVzY3JpcHRpb246CUEgQkdQIHBlZXIgc2Vzc2lvbiBjYW4gYmUgc3RhcnRlZCBh bmQgc3RvcHBlZCBieSANCgkJCWFkbWluaXN0cmF0aXZlIGNvbnRyb2wuICBUaGlzIGFkbWluaXN0 cmF0aXZlIGNvbnRyb2wNCgkJCWNhbiBlaXRoZXIgYmUgbWFudWFsLCBiYXNlZCBvbiBvcGVyYXRv ciBpbnRlcnZlbnRpb24sDQoJCQlvciB1bmRlciB0aGUgY29udHJvbCBvZiBsb2dpYyBzcGVjaWZp YyB0bw0KCQkJYSBCR1AgaW1wbGVtZW50YXRpb24uIFRoZSB0ZXJtICJhdXRvbWF0aWMiIHJlZmVy cyB0bw0KCQkJYSBzdGFydCBiZWluZyBpc3N1ZWQgdG8gdGhlIEJHUCBGU00gd2hlbiBzdWNoIGxv Z2ljDQoJCQlkZXRlcm1pbmVzIHRoYXQgdGhlIEJHUCBwZWVyIHNlc3Npb24gc2Vzc2lvbiBzaG91 bGQNCgkJCWJlIHJlc3RhcnRlZC4NCg0KCQkJVGhlIEFsbG93QXV0b21hdGljU3RhcnQgb3B0aW9u IHNwZWNpZmllcyB0aGF0IHRoaXMNCgkJCUJHUCBzZXNzaW9uIHN1cHBvcnRzIGF1dG9tYXRpYyBz dGFydGluZyBvZiB0aGUgQkdQDQoJCQlzZXNzaW9uLg0KDQoJCQlJZiBCR1AgaW1wbGVtZW50YXRp b24gc3VwcG9ydHMgQWxsb3dBdXRvbWF0aWNTdGFydCwgIA0KCQkgICAgICAgIHRoZSBwZWVyIG1h eSBiZSByZXBlYXRlZGx5IHJlc3RhcnRlZC4gVHdvIG90aGVyDQoJCQlvcHRpb25zIGNvbnRyb2wg dGhlIHJhdGUgYXQgd2hpY2ggdGhlIGF1dG9tYXRpYw0KCQkJcmVzdGFydCBvY2N1cnM6IElkbGVI b2xkVGltZXIgYW5kIA0KCQkJRGFtcFBlZXJPc2NpbGxhdGlvbnMuIFRoZSBJZGxlSG9sZFRpbWVy IHNwZWNpZmllcw0KICAgICAgICAgICAgICAgICAgICAgICAgaG93IGxvbmcgdGhlIFBlZXIgaXMg aGVsZCBpbiB0aGUgSWRsZSBzdGF0ZSBwcmlvciB0bw0KICAgICAgICAgICAgICAgICAgICAgICAg YWxsb3dpbmcgdGhlIG5leHQgYXV0b21hdGljIHJlc3RhcnQuICBUaGUgDQogICAgICAgICAgICAg ICAgICAgICAgICBEYW1wUGVlck9zY2lsbGF0aW9ucyBvcHRpb24gc3BlY2lmaWVzIHRoYXQgdGhl DQogICAgICAgICAgICAgICAgICAgICAgICBpbXBsZW1lbnRhdGlvbiBlbmdhZ2VzIGFkZGl0aW9u YWwgbG9naWMgdG8NCgkJCWRhbXAgdGhlIG9zY2lsbGF0aW9ucyBvZiBCR1AgcGVlcnMgaW4gdGhl IGZhY2Ugb2YgDQogICAgICAgICAgICAgICAgICAgICAgICBzZXF1ZW5jZXMgb2YgYXV0b21hdGlj IHN0YXJ0IGFuZCBhdXRvbWF0aWMgc3RvcC4NCgkJCUFuIGV4YW1wbGUgb2Ygc3VjaCBsb2dpYyBp cyBhbiBpbmNyZWFzZSBvZiB0aGUgDQoJCQl0aW1lIHNldCBpbiB0aGUgSWRsZUhvbGRUaW1lciBp ZiB0aGUgQkdQIHBlZXINCgkJCW9zY2lsbGF0ZXMgY29ubmVjdGl2aXR5IChjb25uZWN0ZWQvZGlz Y29ubmVjdGVkKQ0KCQkJcmVwZWF0ZWRseSB3aXRoaW4gYSB0aW1lIHBlcmlvZC4gIA0KDQoJVmFs dWVzOgkJVHJ1ZSBvciBGYWxzZQ0KCQkJDQoNCglPcHRpb24gMjoJQWxsb3dBdXRvbWF0aWNTdG9w DQoNCglEZXNjcmlwdGlvbjoJVGhpcyBCR1AgcGVlciBzZXNzaW9uIG9wdGlvbiBpbmRpY2F0ZXMg dGhhdCB0aGUgQkdQDQoJCQlzZXNzaW9uIGFsbG93cyAiYXV0b21hdGljIiBzdG9wcGluZyBvZiB0 aGUgQkdQIHNlc3Npb24uDQoJCQlBbiAiYXV0b21hdGljIiBzdG9wIGlzIGRlZmluZWQgYXMgYSBz dG9wIHVuZGVyIHRoZQ0KCQkJY29udHJvbCBvZiBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBsb2dp Yy4gIFRoZQ0KCQkJaW1wbGVtZW50YXRpb24gc3BlY2lmaWMgbG9naWMgaXMgb3V0c2lkZSB0aGUg c2NvcGUNCgkJCW9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gDQoNCglWYWx1ZXM6CQlUcnVlIG9yIEZh bHNlDQoNCglPcHRpb24gMzoJSWRsZUhvbGR0aW1lcg0KDQoJRGVzY3JpcHRpb246CVRoZSBJZGxl SG9sZFRpbWVyIGFpZHMgaW4gY29udHJvbGxpbmcgQkdQIHBlZXIgb3NjaWxsYXRpb24uDQoJCQlB biBpbXBsZW1lbnRhdGlvbiB0aGF0IGRvZXMgbm90IHN1cHBvcnQgcGVyc2lzdGVudCBwZWVyIA0K ICAgICAgICAgICAgICAgICAgICAgICAgb3NjaWxsYXRpb24gZGFtcGluZyBtYXkgbm90IGhhdmUg dGhpcyB0aW1lci4NCg0KCQkJVGhlIElkbGUgSG9sZCBUaW1lciBpcyB1c2VkIHRvIGtlZXAgdGhl IEJHUCBwZWVyIGluIElkbGUNCgkJCWZvciBhIHBhcnRpY3VsYXIgZHVyYXRpb24uICBUaGUgSWRs ZUhvbGR0aW1lciBleHBpcmVkIGV2ZW50DQoJCQlpcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA4LjEu My4NCg0KCVZhbHVlczoJCXRpbWUgaW4gc2Vjb25kcw0KDQoJT3B0aW9uIDQ6CURhbXBQZWVyT3Nj aWxsYXRpb25zDQoNCglEZXNjcmlwdGlvbjoJVGhlIERhbXBQZWVyT3NjaWxsYXRpb25zIG9wdGlv bmFsIHNlc3Npb24gYXR0cmlidXRlDQogICAgICAgICAgICAgICAgICAgICAgICBpbmRpY2F0ZXMg dGhhdCB0aGlzIEJHUCBzZXNzaW9uIGlzIHVzaW5nIGxvZ2ljIA0KICAgICAgICAgICAgICAgICAg ICAgICAgdGhhdCBkYW1wcyBCR1AgcGVlciBvc2NpbGxhdGlvbnMgaW4gdGhlIElkbGUgU3RhdGUu DQoNCglWYWx1ZToJCVRydWUgb3IgRmFsc2UNCg0KDQogICBHcm91cCAyOiBVbmNvbmZpZ3VyZWQg UGVlcnMNCg0KICAgCU9wdGlvbmFsIFNlc3Npb24gQXR0cmlidXRlczogQWNjZXB0Q29ubmVjdGlv bnNVbmNvbmZpZ3VyZWRQZWVycw0KDQoJT3B0aW9uIDE6CUFjY2VwdENvbm5lY3Rpb25zVW5jb25m aWd1cmVkUGVlcnMNCg0KCURlc2NyaXB0aW9uOglUaGUgQkdQIEZTTSBvcHRpb25hbGx5IGFsbG93 cyB0aGUgYWNjZXB0YW5jZSBvZiBCR1AgcGVlcg0KICAgICAgICAgICAgICAgICAgICAgICAgc2Vz c2lvbnMgZnJvbSBuZWlnaGJvcnMgdGhhdCBhcmUgbm90IHByZS1jb25maWd1cmVkLiAgVGhlIA0K ICAgICAgICAgICAgICAgICAgICAgICAgIkFjY2VwdENvbm5lY3Rpb25zVW5jb25maWd1cmVkUGVl cnMiIG9wdGlvbmFsIHNlc3Npb24NCiAgICAgICAgICAgICAgICAgICAgICAgIGF0dHJpYnV0ZSBh bGxvd3MgdGhlIEZTTSB0byBzdXBwb3J0IHRoZSBzdGF0ZSB0cmFuc2l0aW9ucw0KCQkJdGhhdCBh bGxvdyB0aGUgaW1wbGVtZW50YXRpb24gdG8gYWNjZXB0IG9yIHJlamVjdCB0aGVzZQ0KCQkJdW5j b25maWd1cmVkIHBlZXJzLg0KDQoJCQlUaGUgQWNjZXB0Q29ubmVjdGlvbnNVbmNvbmZpZ3VyZWRQ ZWVycyBoYXMgc2VjdXJpdHkNCgkJCWltcGxpY2F0aW9ucy4gUGxlYXNlIHJlZmVyIHRvIHRoZSBC R1AgVnVsbmVyYWJpbGl0aWVzDQoJCQlkb2N1bWVudFt4eHhdIGZvciBkZXRhaWxzLg0KDQoJVmFs dWU6CQlUcnVlIG9yIEZhbHNlDQoNCiAgIEdyb3VwIDM6IFRDUCBwcm9jZXNzaW5nDQoNCglPcHRp b25hbCBTZXNzaW9uIEF0dHJpYnV0ZXM6IFBhc3NpdmVUQ1BFc3RhYmxpc2htZW50LCBUcmFja1RD UFN0YXRlDQoNCglPcHRpb24gMToJUGFzc2l2ZVRDUEVzdGFibGlzaG1lbnQNCgkNCglEZXNjcmlw dGlvbjoJVGhpcyBvcHRpb24gaW5kaWNhdGVzIHRoYXQgdGhlIEJHUCBGU00gd2lsbCBwYXNzaXZl bHkgd2FpdA0KICAgICAgICAgICAgICAgICAgICAgICAgZm9yIHRoZSByZW1vdGUgQkdQIHBlZXIg dG8gZXN0YWJsaXNoIHRoZSBCR1AgVENQIHNlc3Npb24uDQoNCgl2YWx1ZToJCVRydWUgb3IgRmFs c2UNCg0KCU9wdGlvbiAyOiAJVHJhY2tUQ1BTdGF0ZQ0KDQoJRGVzY3JpcHRpb246CVRoZSBCR1Ag RlNNIG5vcm1hbGx5IHRyYWNrcyB0aGUgcmVzdWx0IG9mIGEgVENQIGNvbm5lY3Rpb24NCgkJCWF0 dGVtcHQgcmF0aGVyIHRoYW4gaW5kaXZpZHVhbCBUQ1AgbWVzc2FnZXMuICBPcHRpb25hbGx5LA0K CQkJdGhlIEJHUCBGU00gY2FuIHN1cHBvcnQgYWRkaXRpb25hbCBpbnRlcmFjdGlvbiB3aXRoIHRo ZSBUQ1AgDQoJCQlzZXNzaW9uIG5lZ290aWF0aW9uLiBUaGUgaW50ZXJhY3Rpb24gd2l0aCB0aGUg VENQIGV2ZW50cyBtYXkNCiAgICAgICAgICAgICAgICAgICAgICAgIGluY3JlYXNlIHRoZSBhbW91 bnQgb2YgbG9nZ2luZyB0aGUgQkdQIHBlZXIgc2Vzc2lvbg0KCQkJcmVxdWlyZXMgYW5kIHRoZSBu dW1iZXIgb2YgQkdQIEZTTSBjaGFuZ2VzLg0KDQoJVmFsdWU6CQlUcnVlIG9yIEZhbHNlDQoNCiAg ICANCiAgIEdyb3VwIDQ6ICBCR1AgTWVzc2FnZSBQcm9jZXNzaW5nDQoNCg0KCU9wdGlvbmFsIFNl c3Npb24gQXR0cmlidXRlczogRGVsYXlPcGVuLCBEZWxheU9wZW5UaW1lciwgDQoJCQkJICAgICBT ZW5kTk9USUZJQ0FUSU9Od2l0aG91dE9QRU4sDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQ29ubmVjdGlvbkRldGVjdEVzdGFibGlzaGVkU3RhdGUgDQoNCglPcHRpb24gMToJ RGVsYXlPcGVuDQoNCglEZXNjcmlwdGlvbjogCVRoZSBEZWxheU9wZW4gb3B0aW9uYWwgc2Vzc2lv biBhdHRyaWJ1dGUgYWxsb3dzDQoJCSAgICAgICAgaW1wbGVtZW50YXRpb25zIHRvIGJlIGNvbmZp Z3VyZWQgdG8gZGVsYXkgc2VuZGluZyBhbg0KCQkJT1BFTiBtZXNzYWdlIGZvciBzcGVjaWZpYyB0 aW1lIHBlcmlvZCAoRGVsYXlPcGVuVGltZSkuDQogICAgICAgICAgICAgICAgICAgICAgICBUaGUg ZGVsYXkgYWxsb3dzIHRoZSByZW1vdGUgQkdQIFBlZXIgdGltZSB0byANCgkJCXNlbmQgdGhlIGZp cnN0IE9QRU4gbWVzc2FnZS4gDQoNCglWYWx1ZToJCVRydWUgb3IgRmFsc2UNCg0KCU9wdGlvbiAy OglEZWxheU9wZW5UaW1lcg0KDQoJRGVzY3JpcHRpb246CVRoZSBEZWxheU9wZW5UaW1lciBvcHRp b25hbCBzZXNzaW9uIGF0dHJpYnV0ZSBzcGVjaWZpZXMgYQ0KICAgICAgICAgICAgICAgICAgICAg ICAgdGltZSB0aGF0IHRoZSBsb2NhbCBzeXN0ZW0gd2lsbCB3YWl0IHByaW9yIHRvIHNlbmRpbmcg YW4NCiAgICAgICAgICAgICAgICAgICAgICAgIE9QRU4gZXNzYWdlIG9uIHRoZSBjb25uZWN0aW9u Lg0KDQoJVmFsdWU6CQlUaW1lIGluIHNlY29uZHMNCg0KDQoJT3B0aW9uIDM6CVNlbmROT1RJRklD SUFUT053aXRob3V0T1BFTg0KCQ0KCURlc2NyaXB0aW9uOglUaGUgU2VuZE5PVElGSUNJQVRPTndp dGhvdXRPUEVOIGFsbG93cyBhIHBlZXIgdG8gc2VuZCBhIA0KCQkJTk9USUZJQ0FUSU9OIHdpdGhv dXQgZmlyc3Qgc2VuZGluZyBhbiBPUEVOIG1lc3NhZ2UuICBXaXRob3V0DQoJCQl0aGlzIG9wdGlv bmFsIGF0dHJpYnV0ZSwgdGhlIHNlc3Npb24gYXNzdW1lcyB0aGF0IGFuIE9QRU4NCgkJCW1lc3Nh Z2UgbXVzdCBiZSByZWNlaXZlZCBieSBhIHBlZXIgcHJpb3IgdG8gdGhlIHBlZXIgc2VuZGluZyBh DQoJCQlOT1RJRklDQVRJT04gbWVzc2FnZS4gIA0KDQoJVmFsdWU6CQlUcnVlIG9yIEZhbHNlDQoN CglPcHRpb24gNDoJQ29sbGlzaW9uRGV0ZWN0RXN0YWJsaXNoZWRTdGF0ZQ0KDQoJRGVzY3JpcHRp b246CU5vcm1hbGx5LCBhIERldGVjdCBDb2xsaXNpb24gKDYuOCkgd2lsbA0KCQkJYmUgaWdub3Jl ZCBpbiB0aGUgRXN0YWJsaXNoZWQgc3RhdGUuICBUaGlzIG9wdGlvbmFsIA0KCQkJc2Vzc2lvbiBh dHRyaWJ1dGUgaW5kaWNhdGVzIHRoYXQgdGhpcyBCR1Agc2Vzc2lvbiB3aWxsDQoJCQlzdXBwb3J0 IHByb2Nlc3NpbmcgYSBkZXRlY3RlZCBjb2xsaXNpb24gaW4gdGhlDQogICAgICAgICAgICAgICAg ICAgICAgICBFc3RhYmxpc2hlZCBzdGF0ZS4JCSAgDQoNCglWYWx1ZToJCVRydWUgb3IgRmFsc2UN Cg0KDQogICBOb3RlOiAgVGhlIG9wdGlvbmFsIHNlc3Npb24gYXR0cmlidXRlcyBjbGFyaWZ5IHRo ZSBCR1AgRlNNIGRlc2NyaXB0aW9uDQogICAgICAgICAgZm9yIGV4aXN0aW5nIGZlYXR1cmVzIG9m IEJHUCBpbXBsZW1lbnRhdGlvbnMuICBUaGUgDQogICAgICAgICAgb3B0aW9uYWwgc2Vzc2lvbiBh dHRyaWJ1dGVzIG1heSBiZSBwcmUtZGVmaW5lZCBmb3IgYW4NCgkgIGltcGxlbWVudGF0aW9uIGFu ZCBub3QgcmVhZGFibGUgdmlhIG1hbmFnZW1lbnQgaW50ZXJmYWNlcw0KICAgICAgICAgIGZvciBl eGlzdGluZyBjb3JyZWN0IGltcGxlbWVudGF0aW9ucy4gIEFzIG5ld2VyIEJHUCBNSUJzDQogICAg ICAgICAgKHZlcnNpb24gMiBhbmQgYmV5b25kKSBhcmUgc3VwcG9ydGVkLCB0aGVzZSBmaWVsZHMg d2lsbCBiZQ0KCSAgYWNjZXNzYWJsZSB2aWEgYSBtYW5hZ2VtZW50IGludGVyZmFjZS4NCg0KDQoN CjguMS4yIEFkbWluaXN0cmF0aXZlIEV2ZW50cw0KDQoNCiAgIFBsZWFzZSBub3RlIHRoYXQgb25s eSBFdmVudCAxIChtYW51YWwgc3RhcnQpIGFuZCBFdmVudCAyIChtYW51YWwNCiAgIHN0b3ApIGFy ZSBtYW5kYXRvcnkgYWRtaW5pc3RyYXRpdmUgZXZlbnRzLiBBbGwgb3RoZXIgYWRtaW5pc3RyYXRp dmUNCiAgIGV2ZW50cyBhcmUgb3B0aW9uYWwgKEV2ZW50cyAzLTgpLiAgIEVhY2ggZXZlbnQgYmVs b3cgaGFzIGEgbmFtZSwNCiAgIGRlZmluaXRpb24sIHN0YXR1cyAobWFuZGF0b3J5IG9yIG9wdGlv bmFsKSwgYW5kIHdoYXQgb3B0aW9uYWwgc2Vzc2lvbg0KICAgYXR0cmlidXRlcyBTSE9VTEQgYmUg c2V0IGF0IGVhY2ggc3RhZ2UuICANCg0KCSAgIA0KDQogICAgICAgRXZlbnQxOiBNYW51YWxTdGFy dA0KDQogICAgICAgICAgICAgIERlZmluaXRpb246IExvY2FsIHN5c3RlbSBhZG1pbmlzdHJhdG9y IG1hbnVhbGx5IHN0YXJ0cyBwZWVyDQogICAgICAgICAgICAgICAgICAgICAgICAgIGNvbm5lY3Rp b24uDQoNCiAgICAgICAgICAgICAgU3RhdHVzOiAgICAgTWFuZGF0b3J5DQoNCiAgICAgICAgICAg ICAgT3B0aW9uYWwNCiAgICAgICAgICAgICAgQXR0cmlidXRlDQoJICAgICAgU3RhdHVzOiAgICAg VGhlIFBhc3NpdmVUQ1BFc3RhYmxpc2htZW50IFNIT1VMRCBiZSBzZXQgdG8gRkFMU0UuDQoNCiAg ICAgICBFdmVudDI6IE1hbnVhbFN0b3ANCg0KICAgICAgICAgICAgICBEZWZpbml0aW9uOiBMb2Nh bCBzeXN0ZW0gYWRtaW5pc3RyYXRvciBtYW51YWxseQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICBzdG9wcyB0aGUgcGVlciBjb25uZWN0aW9uLg0KDQogICAgICAgICAgICAgIFN0YXR1czogICAg IE1hbmRhdG9yeQ0KDQoJICAgICAgT3B0aW9uYWwNCgkgICAgICBBdHRyaWJ1dGUNCgkgICAgICBT dGF0dXM6CSAgTm8gaW50ZXJhY3Rpb24gd2l0aCBhbnkgb3B0aW9uYWwgYXR0cmlidXRlcy4gDQoJ IA0KDQoNCg0KRXhwaXJhdGlvbiBEYXRlIFNlcHRlbWJlciAyMDAzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDFtQYWdlIDM3XQ0KDQoNCg0KDQoNClJGQyBEUkFGVCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoN CiAgICAgICBFdmVudDM6IEF1dG9tYXRpY1N0YXJ0DQoNCiAgICAgICAgICAgICAgRGVmaW5pdGlv bjogTG9jYWwgc3lzdGVtIGF1dG9tYXRpY2FsbHkgc3RhcnRzIHRoZQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICBCR1AgY29ubmVjdGlvbi4NCg0KDQogICAgICAgICAgICAgIFN0YXR1czogICAg IE9wdGlvbmFsLCBkZXBlbmRpbmcgb24gbG9jYWwgc3lzdGVtDQoNCiAgICAgICAgICAgICAgT3B0 aW9uYWwNCiAgICAgICAgICAgICAgQXR0cmlidXRlDQoJICAgICAgU3RhdHVzOiAgICAgMSkgQXV0 b21hdGljU3RhcnQgU0hPVUxEIGJlIHNldCBpZiB0aGlzIGV2ZW50IG9jY3Vycy4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgMikgSWYgdGhlIFBhc3NpdmVUQ1BFc3RhYmxpc2htZW50IG9wdGlv bmFsIHNlc3Npb24NCgkJCSAgICAgYXR0cmlidXRlIGlzIHN1cHBvcnRlZCwgaXQgU0hPVUxEIGJl IHNldCB0byBGQUxTRS4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgMykgSWYgdGhlIERhbXBQ ZWVyT3NjaWxsYXRpb24gaXMgc3VwcG9ydGVkLCBpdA0KCQkJICAgICBTSE9VTEQgYmUgc2V0IHRv IEZBTFNFIHdoZW4gdGhpcyBldmVudCBvY2N1cnMuIA0KDQoNCiAgICAgICBFdmVudDQ6IE1hbnVh bFN0YXJ0X3dpdGhfUGFzc2l2ZVRDUEVzdGFibGlzaG1lbnQNCg0KICAgICAgICAgICAgICBEZWZp bml0aW9uOiBMb2NhbCBzeXN0ZW0gYWRtaW5pc3RyYXRvciBtYW51YWxseSBzdGFydHMgdGhlIHBl ZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgY29ubmVjdGlvbiwgYnV0IGhhcyB0aGUgUGFz c2l2ZVRDUEVzdGFibGlzaG1lbnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgZW5hYmxlZC4g IFRoZSBwYXNzaXZlIFRDUCBlc3RhYmxpc2htZW50IGZsYWcgaW5kaWNhdGVzDQogICAgICAgICAg ICAgICAgICAgICAgICAgIHRoYXQgdGhlIHBlZXIgd2lsbCBsaXN0ZW4gcHJpb3IgdG8NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgZXN0YWJsaXNoaW5nIHRoZSBjb25uZWN0aW9uLg0KDQogICAg ICAgICAgICAgIFN0YXR1czogICAgIE9wdGlvbmFsLCBkZXBlbmRpbmcgb24gbG9jYWwgc3lzdGVt DQoNCiAgICAgICAgICAgICAgT3B0aW9uYWwNCiAgICAgICAgICAgICAgQXR0cmlidXRlIA0KCSAg ICAgIFN0YXR1czoJICAxKSBUaGUgUGFzc2l2ZSBUQ1AgRXN0YWJsaXNobWVudCBhdHRyaWJ1dGUg U0hPVUxEIGJlIHNldCB0bw0KCQkJICAgICBUUlVFIGlmIHRoaXMgZXZlbnQgb2NjdXJzLg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAyKSBUaGUgRGFtcEJHUFBlZXJPc2NpbGxhdGlvbiBhdHRy aWJ1dGUgU0hPVUxEIGJlIHNldCB0bw0KCQkJICAgICBGQUxTRSB3aGVuIHRoaXMgZXZlbnQgb2Nj dXJzLiAgIA0KDQoNCiAgICAgICBFdmVudDU6IEF1dG9tYXRpY1N0YXJ0X3dpdGhfUGFzc2l2ZVRD UEVzdGFibGlzaG1lbnQgIA0KDQogICAgICAgICAgICAgIERlZmluaXRpb246IExvY2FsIHN5c3Rl bSBhdXRvbWF0aWNhbGx5IHN0YXJ0cyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQkdQ IGNvbm5lY3Rpb24gd2l0aCB0aGUgcGFzc2l2ZVRDUEVzdGFibGlzaG1lbnQNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgZW5hYmxlZC4gIFRoZSBwYXNzaXZlIGZsYWcgaW5kaWNhdGVzDQogICAg ICAgICAgICAgICAgICAgICAgICAgIHRoYXQgdGhlIHBlZXIgd2lsbCBsaXN0ZW4gcHJpb3IgdG8N CiAgICAgICAgICAgICAgICAgICAgICAgICAgZXN0YWJsaXNoaW5nIGEgY29ubmVjdGlvbi4NCg0K ICAgICAgICAgICAgICBTdGF0dXM6ICAgICBPcHRpb25hbCwgZGVwZW5kaW5nIG9uIGxvY2FsIHN5 c3RlbQ0KDQoNCg0KDQpFeHBpcmF0aW9uIERhdGUgU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAMW1BhZ2UgMzhdDQoNCg0KDQoNCg0KUkZDIERSQUZUICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDAz DQoNCg0KICAgICAgICAgICAgICBPcHRpb25hbA0KICAgICAgICAgICAgICBBdHRyaWJ1dGUgDQog ICAgICAgICAgICAgIFN0YXR1czogICAgIDEpIEF1dG9tYXRpY1N0YXJ0IFNIT1VMRCBiZSBzZXQg dG8gVFJVRS4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgMikgUGFzc2l2ZVRDUEVzdGFibGlz aG1lbnQgU0hPVUxEIGJlIHNldCB0byBUUlVFDQogICAgICAgICAgICAgICAgICAgICAgICAgIDMp IElmIHRoZSBEYW1wQkdQUGVlck9zY2lsbGF0aW9uIGlzIHN1cHBvcnRlZCwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdGhlIERhbXBCR1BQZWVyT3NjaWxsYXRpb24gU0hPVUxEIGJlIHNl dCB0bw0KCQkJICAgICBGQUxTRS4NCg0KDQoNCiAgICAgICBFdmVudDY6IEF1dG9tYXRpY1N0YXJ0 X3dpdGhfRGFtcFBlZXJPc2NpbGxhdGlvbnMNCg0KICAgICAgICAgICAgICBEZWZpbml0aW9uOiBM b2NhbCBzeXN0ZW0gYXV0b21hdGljYWxseSBzdGFydHMgdGhlDQogICAgICAgICAgICAgICAgICAg ICAgICAgIEJHUCBwZWVyIGNvbm5lY3Rpb24gd2l0aCBwZWVyIG9zY2lsbGF0aW9uDQogICAgICAg ICAgICAgICAgICAgICAgICAgIGRhbXBpbmcgZW5hYmxlZC4gVGhlIGV4YWN0IG1ldGhvZCBvZiBk YW1waW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgIHBlcnNpc3RlbnQgcGVlciBvc2NpbGxh dGlvbnMgaXMgbGVmdCB1cCB0byB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgaW1wbGVt ZW50YXRpb24gYW5kIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mDQogICAgICAgICAgICAgICAgICAg ICAgICAgIHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgICAgICAgICAgU3RhdHVzOiAgICAgT3B0aW9u YWwsIGRlcGVuZGluZyBvbiBsb2NhbCBzeXN0ZW0uDQoNCiAgICAgICAgICAgICAgT3B0aW9uYWwN CiAgICAgICAgICAgICAgQXR0cmlidXRlIA0KICAgICAgICAgICAgICBTdGF0dXM6ICAgICAxKSBB dXRvbWF0aWNTdGFydCBTSE9VTEQgYmUgc2V0IHRvIFRSVUUuDQogICAgICAgICAgICAgICAgICAg ICAgICAgIDIpIERhbXBQZWVyT3NjaWxsYXRpb24gU0hPVUxEIGJlIHNldCB0byBUUlVFLg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAzKSBQYXNzaXZlVENQRXN0YWJsaXNobWVudCBTSE9VTEQg YmUgc2V0IHRvIEZBTFNFLg0KDQoNCiAgICAgIEV2ZW50IDc6IEF1dG9tYXRpY1N0YXJ0X3dpdGhf RGFtcFBlZXJPc2NpbGxpYXRpb25zX2FuZF8gDQoJCQlQYXNzaXZlVENQRXN0YWJsaXNobWVudCAN Cg0KICAgICAgICAgICAgICBEZWZpbml0aW9uOiBMb2NhbCBzeXN0ZW0gYXV0b21hdGljYWxseSBz dGFydHMgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgIEJHUCBwZWVyIGNvbm5lY3Rpb24g d2l0aCBwZWVyIG9zY2lsbGF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgIGRhbXBpbmcg ZW5hYmxlZCBhbmQgcGFzc2l2ZSBUQ1AgZXN0YWJsaXNobWVudA0KICAgICAgICAgICAgICAgICAg ICAgICAgICBlbmFibGVkLiAgVGhlIGV4YWN0IG1ldGhvZCBvZiBkYW1waW5nDQogICAgICAgICAg ICAgICAgICAgICAgICAgIHBlcnNpc3RlbnQgcGVlciBvc2NpbGxhdGlvbnMgaXMgbGVmdCB1cCB0 byB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgaW1wbGVtZW50YXRpb24gYW5kIGlzIG91 dHNpZGUgdGhlIHNjb3BlIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgIHRoaXMgZG9jdW1l bnQuDQoNCiAgICAgICAgICAgICAgU3RhdHVzOiAgICAgT3B0aW9uYWwsIGRlcGVuZGluZyBvbiBs b2NhbCBzeXN0ZW0NCg0KICAgICAgICAgICAgICBPcHRpb25hbA0KICAgICAgICAgICAgICBBdHRy aWJ1dGVzDQoJICAgICAgU3RhdHVzOgkgIDEpIEF1dG9tYXRpY1N0YXJ0IFNIT1VMRCBiZSBzZXQg dG8gVFJVRS4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgMikgRGFtcFBlZXJPc2NpbGxhdGlv biBTSE9VTEQgYmUgc2V0IHRvIFRSVUUuDQogICAgICAgICAgICAgICAgICAgICAgICAgIDMpIFBh c3NpdmVUQ1BFc3RhYmxpc2htZW50IFNIT1VMRCBiZSBzZXQgdG8gVFJVRS4NCg0KDQoNCg0KRXhw aXJhdGlvbiBEYXRlIFNlcHRlbWJlciAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDFtQYWdlIDM5XQ0KDQoNCg0KDQoNClJGQyBEUkFGVCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCiAgICAgICBFdmVu dDg6IEF1dG9tYXRpY1N0b3ANCg0KICAgICAgICAgICAgICBEZWZpbml0aW9uOiBMb2NhbCBzeXN0 ZW0gYXV0b21hdGljYWxseSBzdG9wcyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQkdQ IGNvbm5lY3Rpb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQW4gZXhhbXBsZSBvZiBh biBhdXRvbWF0aWMgc3RvcCBldmVudCBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgICBleGNl ZWRpbmcgdGhlIG51bWJlciBvZiBwcmVmaXhlcyBmb3IgYSBnaXZlbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICBwZWVyIGFuZCB0aGUgbG9jYWwgc3lzdGVtICBhdXRvbWF0aWNhbGx5DQogICAg ICAgICAgICAgICAgICAgICAgICAgIGRpc2Nvbm5lY3RpbmcgdGhlIHBlZXIuDQoNCg0KICAgICAg ICAgICAgICBTdGF0dXM6ICAgICBPcHRpb25hbCwgZGVwZW5kaW5nIG9uIGxvY2FsIHN5c3RlbQ0K DQogICAgICAgICAgICAgIE9wdGlvbmFsDQogICAgICAgICAgICAgIEF0dHJpYnV0ZQ0KCSAgICAg IFN0YXR1czoJIDEpIEF1dG9tYXRpY1N0b3AgU0hPVUxEIGJlIFRSVUUNCg0KDQoNCjguMS4zIFRp bWVyIEV2ZW50cw0KDQoNCg0KICAgICAgIEV2ZW50OTogQ29ubmVjdFJldHJ5VGltZV9FeHBpcmVz DQoNCiAgICAgICAgICAgICAgRGVmaW5pdGlvbjogQW4gZXZlbnQgZ2VuZXJhdGVkIHdoZW4gdGhl IENvbm5lY3RSZXRyeVRpbWVyDQogICAgICAgICAgICAgICAgICAgICAgICAgIGV4cGlyZXMuDQoN CiAgICAgICAgICAgICAgU3RhdHVzOiAgICAgTWFuZGF0b3J5DQoNCiAgICAgICBFdmVudDEwOiBI b2xkVGltZXJfRXhwaXJlcw0KDQogICAgICAgICAgICAgIERlZmluaXRpb246IEFuIGV2ZW50IGdl bmVyYXRlZCB3aGVuIHRoZSBIb2xkVGltZXIgZXhwaXJlcy4NCg0KICAgICAgICAgICAgICBTdGF0 dXM6ICAgICBNYW5kYXRvcnkNCg0KICAgICAgIEV2ZW50MTE6IEtlZXBhbGl2ZVRpbWVyX0V4cGly ZXMNCg0KICAgICAgICAgICAgICBEZWZpbml0aW9uOiBBbiBldmVudCBnZW5lcmF0ZWQgd2hlbiB0 aGUgS2VlcGFsaXZlVGltZXIgZXhwaXJlcy4NCiAgICAgICAgICAgICAgU3RhdHVzOiAgICAgTWFu ZGF0b3J5DQoNCiAgICAgICBFdmVudDEyOiBPcGVuRGVsYXlUaW1lcl9FeHBpcmVzDQoNCiAgICAg ICAgICAgICAgRGVmaW5pdGlvbjogQW4gZXZlbnQgZ2VuZXJhdGVkIHdoZW4gdGhlIE9wZW5EZWxh eVRpbWVyIGV4cGlyZXMuDQoNCiAgICAgICAgICAgICAgU3RhdHVzOiAgICAgT3B0aW9uYWwNCg0K ICAgICAgICAgICAgICBPcHRpb25hbA0KICAgICAgICAgICAgICBBdHRyaWJ1dGUgDQoJICAgICAg U3RhdHVzOiAJICBJZiB0aGlzIGV2ZW50IG9jY3VycywNCg0KDQoNCkV4cGlyYXRpb24gRGF0ZSBT ZXB0ZW1iZXIgMjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAxbUGFnZSA0MF0N Cg0KDQoNCg0KDQpSRkMgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE1hcmNoIDIwMDMNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg IDEpIERlbGF5T3BlbiBTSE9VTEQgYmUgc2V0IHRvIFRSVUUNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgMikgRGVsYXlPcGVuVGltZXIgU0hPVUxEIGJlIHN1cHBvcnRlZA0KDQoNCiAgICAgIEV2 ZW50MTM6IElkbGVIb2xkdGltZXJfRXhwaXJlcw0KDQogICAgICAgICAgICAgRGVmaW5pdGlvbjog IEFuIGV2ZW50IGdlbmVyYXRlZCB3aGVuIHRoZSBJZGxlSG9sZFRpbWVyDQogICAgICAgICAgICAg ICAgICAgICAgICAgIGV4cGlyZXMgaW5kaWNhdGluZyB0aGF0IHRoZSBzZXNzaW9uIGhhcyBjb21w bGV0ZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgd2FpdGluZyBmb3IgdGhlIGJhY2stb2Zm IHBlcmlvZCB0byBwcmV2ZW50IEJHUCBwZWVyDQogICAgICAgICAgICAgICAgICAgICAgICAgIG9z Y2lsbGF0aW9uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBJZGxlSG9sZFRpbWVy IGlzIG9ubHkgdXNlZCB3aGVuIHRoZSBwZXJzaXN0ZW50DQogICAgICAgICAgICAgICAgICAgICAg ICAgIHBlZXIgb3NjaWxsYXRpb24gZGFtcGluZyBmdW5jdGlvbiBpcyBlbmFibGVkIGJ5DQoJCQkg IHNldHRpbmcgdGhlIERhbXBQZWVyT3NjaWxsYXRpb24gZmxhZyBpcyBzZXQuIA0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgIEltcGxlbWVudGF0aW9ucyBub3QgaW1wbGVtZW50aW5nIHRoZSBw cmVzaXN0ZW50IHBlZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgb3NjaWxsYXRpb24gZGFt cGluZyBmdW5jdGlvbiBtYXkgbm90IGhhdmUgdGhlIA0KCQkJICBJZGxlSG9sZFRpbWVyLg0KDQoN CiAgICAgICAgICAgICAgU3RhdHVzOiAgICAgT3B0aW9uYWwNCg0KICAgICAgICAgICAgICBPcHRp b25hbA0KICAgICAgICAgICAgICBBdHRyaWJ1dGUgDQoJICAgICAgU3RhdHVzOgkgIElmIHRoaXMg ZXZlbnQgb2NjdXJzOg0KICAgICAgICAgICAgICAgICAgICAgICAgICAxKSBEYW1wUGVlck9zY2ls bGF0aW9uIFNIT1VMRCBiZSBzZXQgdG8gVFJVRQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAy KSBJZGxlSG9sZFRpbWVyIFNIT1VMRCBoYXZlIGp1c3QgZXhwaXJlZA0KDQoNCg0KOC4xLjQgVENQ IENvbm5lY3Rpb24gYmFzZWQgRXZlbnRzDQoNCg0KICAgICAgIEV2ZW50MTQ6IFRDUENvbm5lY3Rp b25fVmFsaWQNCg0KICAgICAgICAgICAgICBEZWZpbml0aW9uOiBFdmVudCBpbmRpY2F0aW5nIHRo ZSBsb2NhbCBzeXN0ZW0gcmVjZXB0aW9uIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgIGEg VENQIGNvbm5lY3Rpb24gcmVxdWVzdCB3aXRoIGEgdmFsaWQgc291cmNlDQogICAgICAgICAgICAg ICAgICAgICAgICAgIElQIGFkZHJlc3MgYW5kIFRDUCBwb3J0IGFuZCBhIHZhbGlkIGRlc3RpbmF0 aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgIElQIGFkZHJlc3MgYW5kIFRDUCBQb3J0LiBU aGUgZGVmaW5pdGlvbiBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgICBpbnZhbGlkIHNvdXJj ZSBhbmQgaW52YWxpZCBkZXN0aW5hdGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBJUCBh ZGRyZXNzIGlzIGxlZnQgdG8gdGhlIGltcGxlbWVudGF0aW9uLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgIEJHUCdzIGRlc3RpbmF0aW9uIHBvcnQgU0hPVUxEIGJlIHBvcnQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgMTc5IGFzIGRlZmluZWQgYnkgSUFOQS4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICBUQ1AgY29ubmVjdGlvbiByZXF1ZXN0IGlzIGRlbm90ZWQgYnkNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgdGhlIGxvY2FsIHN5c3RlbSByZWNlaXZpbmcgYSBUQ1AgU1lO Lg0KDQoNCg0KDQpFeHBpcmF0aW9uIERhdGUgU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAMW1BhZ2UgNDFdDQoNCg0KDQoNCg0KUkZDIERSQUZUICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDAzDQoN Cg0KICAgICAgICAgICAgICBTdGF0dXM6ICAgICBPcHRpb25hbA0KDQogICAgICAgICAgICAgIE9w dGlvbmFsDQogICAgICAgICAgICAgIEF0dHJpYnV0ZQ0KCSAgICAgIFN0YXR1czoJIDEpIFRoZSBU cmFja1RDUFN0YXRlIFNIT1VMRCBiZSBzZXQgdG8gVFJVRSBpZg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB0aGlzIGV2ZW50IG9jY3Vycy4NCg0KICAgICAgIEV2ZW50MTU6IFRDUF9DUl9J bnZhbGlkDQoNCiAgICAgICAgICAgICAgRGVmaW5pdGlvbjogRXZlbnQgaW5kaWNhdGluZyB0aGUg bG9jYWwgc3lzdGVtIHJlY2VwdGlvbiBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgICBhIFRD UCBjb25uZWN0aW9uIHJlcXVlc3Qgd2l0aCBlaXRoZXINCiAgICAgICAgICAgICAgICAgICAgICAg ICAgYW4gaW52YWxpZCBzb3VyY2UgYWRkcmVzcyBvciBwb3J0DQogICAgICAgICAgICAgICAgICAg ICAgICAgIG51bWJlciBvciBhbiBpbnZhbGlkIGRlc3RpbmF0aW9uDQogICAgICAgICAgICAgICAg ICAgICAgICAgIGFkZHJlc3Mgb3IgcG9ydCBudW1iZXIuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgQkdQIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyIFNIT1VMRCBiZSAxNzkNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgYXMgZGVmaW5lZCBieSBJQU5BLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgIEEgVENQIGNvbm5lY3Rpb24gcmVxdWVzdCBvY2N1cnMgd2hlbg0KCQkJICB0aGUg bG9jYWwgc3lzdGVtIHJlY2VpdmVzIGEgVENQDQogICAgICAgICAgICAgICAgICAgICAgICAgIFNZ Ti4NCg0KICAgICAgICAgICAgICBTdGF0dXM6ICAgICBPcHRpb25hbA0KDQogICAgICAgICAgICAg IE9wdGlvbmFsDQogICAgICAgICAgICAgIEF0dHJpYnV0ZQ0KCSAgICAgIFN0YXR1czoJICAxKSBU aGUgVHJhY2tUQ1BTdGF0ZSBzaG91bGQgYmUgc2V0IHRvIFRSVUUNCgkJCSAgICAgaWYgdGhpcyBl dmVudCBvY2N1cnMuDQoNCg0KICAgICAgIEV2ZW50MTY6IFRDUF9DUl9BY2tlZA0KDQogICAgICAg ICAgICAgIERlZmluaXRpb246IEV2ZW50IGluZGljYXRpbmcgdGhlIExvY2FsIHN5c3RlbSdzIHJl cXVlc3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gZXN0YWJsaXNoIGEgVENQIGNvbm5l Y3Rpb24gdG8gdGhlIHJlbW90ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBwZWVyLg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBsb2NhbCBzeXN0ZW0ncyBUQ1Agc2Vzc2lvbiBz ZW50IGEgVENQDQogICAgICAgICAgICAgICAgICAgICAgICAgIFNZTiwgYW5kIHJlY2VpdmVkIGEg VENQIFNZTiwgQUNLIG1lc3NhZ2VzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICBhbmQgU2Vu dCBhIFRDUCBBQ0suDQoNCiAgICAgICAgICAgICAgU3RhdHVzOiAgICAgTWFuZGF0b3J5DQoNCiAg ICAgICBFdmVudDE3OiBUQ1BDb25uZWN0aW9uQ29uZmlybWVkDQoNCiAgICAgICAgICAgICAgRGVm aW5pdGlvbjogRXZlbnQgaW5kaWNhdGVzIHRoYXQgdGhlIGxvY2FsIHN5c3RlbSBoYXMgDQoJCQkg IHJlY2VpdmVkIGEgY29uZmlybWF0aW9uIHRoYXQgdGhlIFRDUA0KICAgICAgICAgICAgICAgICAg ICAgICAgICBjb25uZWN0aW9uIGhhcyBiZWVuIGVzdGFibGlzaGVkIGJ5IHRoZQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICByZW1vdGUgc2l0ZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICBUaGUgcmVtb3RlIHBlZXIncyBUQ1AgZW5naW5lIHNlbnQgYSBUQ1AgU1lOLg0KICAgICAgICAg ICAgICAgICAgICAgICAgICBUaGUgbG9jYWwgcGVlcidzIFRDUCBlbmdpbmUgc2VudCBhIFNZTiwg QUNLDQoNCg0KDQpFeHBpcmF0aW9uIERhdGUgU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAMW1BhZ2UgNDJdDQoNCg0KDQoNCg0KUkZDIERSQUZUICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDAzDQoN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICBtZXNzYWdlIGFuZCBub3cgaGFzIHJlY2VpdmVk IGEgZmluYWwgQUNLLg0KDQogICAgICAgICAgICAgIFN0YXR1czogICAgIE1hbmRhdG9yeQ0KDQog ICAgICAgRXZlbnQxODogVENQQ25uZWN0aW9uRmFpbHMNCg0KICAgICAgICAgICAgICBEZWZpbml0 aW9uOiBFdmVudCBpbmRpY2F0ZXMgdGhhdCB0aGUgbG9jYWwgc3lzdGVtIGhhcw0KICAgICAgICAg ICAgICAgICAgICAgICAgICByZWNlaXZlZCBhIFRDUCBjb25uZWN0aW9uIGZhaWx1cmUgbm90aWNl Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSByZW1vdGUgQkdQIHBlZXIncyBUQ1Ag bWFjaGluZSBjb3VsZCBoYXZlDQogICAgICAgICAgICAgICAgICAgICAgICAgIHNlbnQgYSBGSU4u ICBUaGUgbG9jYWwgcGVlciB3b3VsZCByZXNwb25kDQogICAgICAgICAgICAgICAgICAgICAgICAg IHdpdGggYSBGSU4tQUNLLiBBbm90aGVyIGFsdGVybmF0aXZlIGlzIHRoYXQNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgdGhlIGxvY2FsIHBlZXIgaW5kaWNhdGVkIGEgdGltZW91dCBpbiB0aGUN CiAgICAgICAgICAgICAgICAgICAgICAgICAgVENQIHNlc3Npb24gYW5kIGRvd25lZCB0aGUgY29u bmVjdGlvbi4NCg0KICAgICAgICAgICAgICBTdGF0dXM6ICAgICBNYW5kYXRvcnkNCg0KDQoNCjgu MS41IEJHUCBNZXNzYWdlLWJhc2VkIEV2ZW50cw0KDQoNCiAgICAgICBFdmVudDE5OiBCR1BPcGVu DQoNCiAgICAgICAgICAgICAgRGVmaW5pdGlvbjogQW4gZXZlbnQgaXMgZ2VuZXJhdGVkIHdoZW4g YSB2YWxpZCBPUEVODQogICAgICAgICAgICAgICAgICAgICAgICAgIG1lc3NhZ2UgaGFzIGJlZW4g cmVjZWl2ZWQuDQoNCiAgICAgICAgICAgICAgU3RhdHVzOiAgICAgTWFuZGF0b3J5DQoNCiAgICAg ICAgICAgICAgT3B0aW9uYWwNCiAgICAgICAgICAgICAgQXR0cmlidXRlDQoJICAgICAgU3RhdHVz OiAgICAgMSkgRGVsYXlPcGVuIGZsYWcgU0hPVUxEIG5vdCBiZSBzZXQgdG8gVFJVRS4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgMikgT3BlbkRlbGF5VGltZXIgU0hPVUxEIG5vdCBiZSBydW5u aW5nLg0KDQoNCiAgICAgICBFdmVudDIwOiBCR1BPcGVuIHdpdGggT3BlbkRlbGF5VGltZXIgcnVu bmluZw0KDQogICAgICAgICAgICAgIERlZmluaXRpb246IEFuIGV2ZW50IGlzIGdlbmVyYXRlZCB3 aGVuIGEgdmFsaWQgT1BFTg0KICAgICAgICAgICAgICAgICAgICAgICAgICBtZXNzYWdlIGhhcyBi ZWVuIHJlY2VpdmVkIGZvciBhIHBlZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCBo YXMgYSBzdWNjZXNzZnVsbHkgZXN0YWJsaXNoZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAg dHJhbnNwb3J0IGNvbm5lY3Rpb24gYW5kIGlzIGN1cnJlbnRseQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICBkZWxheWluZyB0aGUgc2VuZGluZyBvZiBhIEJHUCBvcGVuDQogICAgICAgICAgICAg ICAgICAgICAgICAgIG1lc3NhZ2UuDQoNCg0KICAgICAgICAgICAgICBTdGF0dXM6ICAgICBPcHRp b25hbA0KDQogICAgICAgICAgICAgIE9wdGlvbmFsDQogICAgICAgICAgICAgIEF0dHJpYnV0ZSAg MSkgRGVsYXlPcGVuIFNIT1VMRCBiZSBzZXQgdG8gVFJVRS4NCgkgICAgICBTdGF0dXM6DQoNCg0K RXhwaXJhdGlvbiBEYXRlIFNlcHRlbWJlciAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDFtQYWdlIDQzXQ0KDQoNCg0KDQoNClJGQyBEUkFGVCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgMikgT3BlbkRlbGF5VGltZXIgU0hPVUxEIGJlIHJ1bm5pbmcuDQoN Cg0KICAgICAgIEV2ZW50MjE6IEJHUEhlYWRlckVycg0KDQogICAgICAgICAgICAgIERlZmluaXRp b246IEFuIGV2ZW50IGlzIGdlbmVyYXRlZCB3aGVuIGEgcmVjZWl2ZWQNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgQkdQIG1lc3NhZ2UgaGVhZGVyIGlzIG5vdCB2YWxpZC4NCg0KICAgICAgICAg ICAgICBTdGF0dXM6ICAgICBNYW5kYXRvcnkNCg0KICAgICAgIEV2ZW50MjI6IEJHUE9wZW5Nc2dF cnINCg0KICAgICAgICAgICAgICBEZWZpbml0aW9uOiBBbiBldmVudCBpcyBnZW5lcmF0ZWQgd2hl biBhbiBPUEVOIG1lc3NhZ2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgaGFzIGJlZW4gcmVj ZWl2ZWQgd2l0aCBlcnJvcnMuDQoNCiAgICAgICAgICAgICAgU3RhdHVzOiAgICAgTWFuZGF0b3J5 DQoNCg0KICAgICAgIEV2ZW50MjM6IE9wZW5Db2xsaXNpb25EdW1wDQoNCiAgICAgICAgICAgICAg RGVmaW5pdGlvbjogQW4gZXZlbnQgZ2VuZXJhdGVkIGFkbWluaXN0cmF0aXZlbHkNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgd2hlbiBhIGNvbm5lY3Rpb24gY29sbGlzaW9uIGhhcyBiZWVuDQog ICAgICAgICAgICAgICAgICAgICAgICAgIGRldGVjdGVkIHdoaWxlIHByb2Nlc3NpbmcgYW4gaW5j b21pbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgT1BFTiBtZXNzYWdlIGFuZCB0aGlzIGNv bm5lY3Rpb24gaGFzIGJlZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgc2VsZWN0ZWQgdG8g YmUgZGlzY29ubmVjdGVkLiBTZWUgU2VjdGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICA2 LjggZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gY29sbGlzaW9uDQogICAgICAgICAgICAgICAgICAg ICAgICAgIGRldGVjdGlvbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICBFdmVudDIzIGlz IGFuIGFkbWluaXN0cmF0aXZlIGFjdGlvbg0KCQkJICBjYWxsZWQgYnkgaW1wbGVtZW50YXRpb24g c3BlY2lmaWMgbG9naWMNCgkJCSAgdGhhdCBkZXRlcm1pbmVzIHRoYXQgdGhpcyBjb25uZWN0aW9u DQoJCQkgIG5lZWRzIHRvIGJlIGRyb3BwZWQuICBUaGUgYWN0aW9uDQoJCQkgIHRoZSBjb250cm9s IG9mIGltcGxlbWVudGF0aW9uIHNwZWNpZmljDQogICAgICAgICAgICAgICAgICAgICAgICAgIHBv bGljeS4gVGhpcyBldmVudCBtYXkgb2NjdXIgaWYgdGhlIEZTTQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICBpcyBpbXBsZW1lbnRlZCBhcyB0d28gbGlua2VkIHN0YXRlIG1hY2hpbmVzLg0KDQoN CiAgICAgICAgICAgICAgU3RhdHVzOiAgICAgT3B0aW9uYWwsIGRlcGVuZGluZyBvbiBsb2NhbCBz eXN0ZW0NCg0KICAgICAgICAgICAgICBPcHRpb25hbA0KICAgICAgICAgICAgICBBdHRyaWJ1dGUN CgkgICAgICBTdGF0dXM6CSAgSWYgdGhlIHN0YXRlIG1hY2hpbmUgaXMgdG8gcHJvY2VzcyB0aGlz DQogICAgICAgICAgICAgICAgICAgICAgICAgIGF0dHJpYnV0ZSBpbiBFc3RhYmxpc2hlZCBzdGF0 ZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIDEpIENvbGxpc2lvbkRldGVjdEVzdGFibGlz aGVkDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZmxhZyBTSE9VTEQgYmUgc2V0IHRv IFRSVUUNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICBQbGVhc2Ugbm90ZTogVGhlIE9w ZW4gY29sbGlzaW9uIGR1bXAgY2FuIG9jY3VyDQogICAgICAgICAgICAgICAgICAgICAgICAgICBp biBJZGxlLCBDb25uZWN0LCBBY3RpdmUsIE9wZW5TZW50LCBPcGVuQ29uZmlybQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgd2l0aG91dCBhbnkgb3B0aW9uYWwgZmxhZ3MgYmVpbmcgc2V0Lg0K DQoNCg0KDQoNCkV4cGlyYXRpb24gRGF0ZSBTZXB0ZW1iZXIgMjAwMyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAxbUGFnZSA0NF0NCg0KDQoNCg0KDQpSRkMgRFJBRlQgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDMNCg0K DQogICAgICAgRXZlbnQyNDogTm90aWZNc2dWZXJFcnINCg0KICAgICAgICAgICAgICBEZWZpbml0 aW9uOiBBbiBldmVudCBpcyBnZW5lcmF0ZWQgd2hlbiBhDQogICAgICAgICAgICAgICAgICAgICAg ICAgIE5PVElGSUNBVElPTiBtZXNzYWdlIHdpdGggInZlcnNpb24NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgZXJyb3IiIGlzIHJlY2VpdmVkLg0KDQogICAgICAgICAgICAgIFN0YXR1czogICAg IE1hbmRhdG9yeQ0KDQogICAgICAgRXZlbnQyNTogTm90aWZNc2cNCg0KICAgICAgICAgICAgICBE ZWZpbml0aW9uOiBBbiBldmVudCBpcyBnZW5lcmF0ZWQgd2hlbiBhDQogICAgICAgICAgICAgICAg ICAgICAgICAgIE5PVElGSUNBVElPTiBtZXNzYWdlcyBpcyByZWNlaXZlZCBhbmQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgdGhlIGVycm9yIGNvZGUgaXMgYW55dGhpbmcgYnV0DQogICAgICAg ICAgICAgICAgICAgICAgICAgICJ2ZXJzaW9uIGVycm9yIi4NCg0KICAgICAgICAgICAgICBTdGF0 dXM6ICAgICBNYW5kYXRvcnkNCg0KICAgICAgIEV2ZW50MjY6IEtlZXBBbGl2ZU1zZw0KDQogICAg ICAgICAgICAgIERlZmluaXRpb246IEFuIGV2ZW50IGlzIGdlbmVyYXRlZCB3aGVuIGEgS0VFUEFM SVZFDQogICAgICAgICAgICAgICAgICAgICAgICAgbWVzc2FnZSBpcyByZWNlaXZlZC4NCg0KICAg ICAgICAgICAgICBTdGF0dXM6ICAgICBNYW5kYXRvcnkNCg0KICAgICAgIEV2ZW50Mjc6IFVwZGF0 ZU1zZw0KDQogICAgICAgICAgICAgIERlZmluaXRpb246IEFuIGV2ZW50IGlzIGdlbmVyYXRlZCB3 aGVuIGEgdmFsaWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgVVBEQVRFIG1lc3NhZ2UgaXMg cmVjZWl2ZWQuDQoNCiAgICAgICAgICAgICAgU3RhdHVzOiAgICAgTWFuZGF0b3J5DQoNCiAgICAg ICBFdmVudDI4OiBVcGRhdGVNc2dFcnINCg0KICAgICAgICAgICAgICBEZWZpbml0aW9uOiBBbiBl dmVudCBpcyBnZW5lcmF0ZWQgd2hlbiBhbiBpbnZhbGlkDQogICAgICAgICAgICAgICAgICAgICAg ICAgIFVQREFURSBtZXNzYWdlIGlzIHJlY2VpdmVkLg0KDQogICAgICAgICAgICAgIFN0YXR1czog ICAgIE1hbmRhdG9yeQ0KDQoNCjguMiBEZXNjcmlwdGlvbiBvZiBGU00NCg0KDQoNCg0KDQo4LjIu MSBGU00gRGVmaW5pdGlvbg0KDQoNCiAgIEJHUCBNVVNUIG1haW50YWluIGEgc2VwYXJhdGUgRlNN IGZvciBlYWNoIGNvbmZpZ3VyZWQgcGVlci4gRWFjaCBCR1ANCiAgIHBlZXIgcGFpcmVkIGluIGEg cG90ZW50aWFsIGNvbm5lY3Rpb24sIHVubGVzcyBjb25maWd1cmVkIHRvIHJlbWFpbiBpbg0KDQoN Cg0KRXhwaXJhdGlvbiBEYXRlIFNlcHRlbWJlciAyMDAzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDFtQYWdlIDQ1XQ0KDQoNCg0KDQoNClJGQyBEUkFGVCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCiAgIHRo ZSBpZGxlIHN0YXRlLCBvciBjb25maWd1cmVkIHRvIHJlbWFpbiBwYXNzaXZlLCB3aWxsIGF0dGVt cHQgdG8NCiAgIGNvbm5lY3QgdG8gdGhlIG90aGVyLiAgRm9yIHRoZSBwdXJwb3NlIG9mIHRoaXMg ZGlzY3Vzc2lvbiwgdGhlIGFjdGl2ZQ0KICAgb3IgY29ubmVjdGluZyBzaWRlIG9mIHRoZSBUQ1Ag Y29ubmVjdGlvbiAodGhlIHNpZGUgb2YgYSBUQ1AgY29ubmVjdGlvbg0KICAgc2VuZGluZyB0aGUg Zmlyc3QgVENQIFNZTiBwYWNrZXQpIGlzIGNhbGxlZCBvdXRnb2luZy4gIFRoZSBwYXNzaXZlIG9y DQogICBsaXN0ZW5pbmcgc2lkZSAodGhlIHNlbmRlciBvZiB0aGUgZmlyc3QgU1lOIEFDSykgaXMg Y2FsbGVkIGFuIGluY29tLQ0KICAgaW5nIGNvbm5lY3Rpb24uIChTZWUgU2VjdGlvbiA4LjIuMS4x IGZvciBpbmZvcm1hdGlvbiBvbiB0aGUgdGVybXMNCiAgIGFjdGl2ZSBhbmQgcGFzc2l2ZSB1c2Vk IGJlbG93LikNCg0KICAgQSBCR1AgaW1wbGVtZW50YXRpb24gTVVTVCBjb25uZWN0IHRvIGFuZCBs aXN0ZW4gb24gVENQIHBvcnQgMTc5IGZvcg0KICAgaW5jb21pbmcgY29ubmVjdGlvbnMgaW4gYWRk aXRpb24gdG8gdHJ5aW5nIHRvIGNvbm5lY3QgdG8gcGVlcnMuICBGb3INCiAgIGVhY2ggaW5jb21p bmcgY29ubmVjdGlvbiwgYSBzdGF0ZSBtYWNoaW5lIE1VU1QgYmUgaW5zdGFudGlhdGVkLg0KICAg VGhlcmUgZXhpc3RzIGEgcGVyaW9kIGluIHdoaWNoIHRoZSBpZGVudGl0eSBvZiB0aGUgcGVlciBv biB0aGUgb3RoZXINCiAgIGVuZCBvZiBhbiBpbmNvbWluZyBjb25uZWN0aW9uIGlzIGtub3duLCBi dXQgdGhlIEJHUCBpZGVudGlmaWVyIGlzIG5vdA0KICAga25vd24uICBEdXJpbmcgdGhpcyB0aW1l LCBib3RoIGFuIGluY29taW5nIGFuZCBhbiBvdXRnb2luZyBjb25uZWN0aW9uDQogICBmb3IgdGhl IHNhbWUgY29uZmlndXJlZCBwZWVyaW5nIG1heSBleGlzdC4gVGhpcyBpcyByZWZlcnJlZCB0byBh cyBhDQogICBjb25uZWN0aW9uIGNvbGxpc2lvbi4gKFNlZSBTZWN0aW9uIDYuOC4pDQoNCiAgIEEg QkdQIGltcGxlbWVudGF0aW9uIHdpbGwgaGF2ZSBhdCBtb3N0IG9uZSBGU00gZm9yIGVhY2ggY29u ZmlndXJlZA0KICAgcGVlcmluZyBwbHVzIG9uZSBGU00gZm9yIGVhY2ggaW5jb21pbmcgVENQIGNv bm5lY3Rpb24gZm9yIHdoaWNoIHRoZQ0KICAgcGVlciBoYXMgbm90IHlldCBiZWVuIGlkZW50aWZp ZWQuIEVhY2ggRlNNIGNvcnJlc3BvbmRzIHRvIGV4YWN0bHkgb25lDQogICBUQ1AgY29ubmVjdGlv bi4NCg0KICAgVGhlcmUgbWF5IGJlIG1vcmUgdGhhbiBvbmUgY29ubmVjdGlvbiBiZXR3ZWVuIGEg cGFpciBvZiBwZWVycyBpZiB0aGUNCiAgIGNvbm5lY3Rpb25zIGFyZSBjb25maWd1cmVkIHRvIHVz ZSBhIGRpZmZlcmVudCBwYWlyIG9mIElQIGFkZHJlc3Nlcy4NCiAgIFRoaXMgaXMgcmVmZXJyZWQg dG8gYXMgbXVsdGlwbGUgImNvbmZpZ3VyZWQgcGVlcmluZ3MiIHRvIHRoZSBzYW1lDQogICBwZWVy Lg0KDQoNCjguMi4xLjEgVGVybXMgImFjdGl2ZSIgYW5kICJwYXNzaXZlIg0KDQoNCiAgIFRoZSB0 ZXJtcyBhY3RpdmUgYW5kIHBhc3NpdmUgaGF2ZSBiZWVuIGluIG91ciB2b2NhYnVsYXJ5IGZvciBh bG1vc3QgYQ0KICAgZGVjYWRlIGFuZCBoYXZlIHByb3ZlbiB1c2VmdWwuICBUaGUgd29yZHMgYWN0 aXZlIGFuZCBwYXNzaXZlIGhhdmUNCiAgIHNsaWdodGx5IGRpZmZlcmVudCBtZWFuaW5ncyBhcHBs aWVkIHRvIGEgVENQIGNvbm5lY3Rpb24gb3IgYXBwbGllZCB0bw0KICAgYSBwZWVyLiAgVGhlcmUg aXMgb25seSBvbmUgYWN0aXZlIHNpZGUgYW5kIG9uZSBwYXNzaXZlIHNpZGUgdG8gYW55DQogICBv bmUgVENQIGNvbm5lY3Rpb24gcGVyIHRoZSBkZWZpbml0aW9uIGFib3ZlIGFuZCB0aGUgc3RhdGUg bWFjaGluZQ0KICAgYmVsb3cuIFdoZW4gYSBCR1Agc3BlYWtlciBpcyBjb25maWd1cmVkIGFjdGl2 ZSwgaXQgbWF5IGVuZCB1cCBvbg0KICAgZWl0aGVyIHRoZSBhY3RpdmUgb3IgcGFzc2l2ZSBzaWRl IG9mIHRoZSBjb25uZWN0aW9uIHRoYXQgZXZlbnR1YWxseQ0KICAgZ2V0cyBlc3RhYmxpc2hlZC4g IE9uY2UgdGhlIFRDUCBjb25uZWN0aW9uIGlzIGNvbXBsZXRlZCwgaXQgZG9lc24ndA0KICAgbWF0 dGVyIHdoaWNoIGVuZCB3YXMgYWN0aXZlIGFuZCB3aGljaCBlbmQgd2FzIHBhc3NpdmUuICBUaGUg b25seQ0KICAgZGlmZmVyZW5jZSBpcyB3aGljaCBzaWRlIG9mIHRoZSBUQ1AgY29ubmVjdGlvbiBo YXMgcG9ydCBudW1iZXIgMTc5Lg0KDQoNCg0KOC4yLjEuMiBGU00gYW5kIGNvbGxpc2lvbiBkZXRl Y3Rpb24NCg0KDQogICBUaGVyZSBpcyBvbmUgRlNNIHBlciBCR1AgY29ubmVjdGlvbi4gIFByaW9y IHRvIGRldGVybWluaW5nIHdoYXQgcGVlcg0KICAgYSBjb25uZWN0aW9uIGlzIGFzc29jaWF0ZWQg d2l0aCBhIGJncCBzZXNzaW9uIHRoZXJlIG1heSBiZSANCg0KDQoNCg0KRXhwaXJhdGlvbiBEYXRl IFNlcHRlbWJlciAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDFtQYWdlIDQ2 XQ0KDQoNCg0KDQoNClJGQyBEUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCiAgIHR3byBjb25uZWN0aW9ucyBmb3Ig YSBnaXZlbiBwZWVyLiAgVGhlcmUgU0hPVUxEIGJlIG5vIG1vcmUgdGhhbiBvbmUNCiAgIGNvbm5l Y3Rpb24gcGVyIHBlZXIgc2Vzc2lvbi4NCg0KICAgVGhlIGNvbGxpc2lvbiBkZXRlY3Rpb24gaWRl bnRpZmllcyB0aGUgY2FzZSB3aGVyZSB0aGVyZSBpcyBtb3JlIHRoYW4NCiAgIG9uZSBjb25uZWN0 aW9uIHBlciBwZWVyIGFuZCBwcm92aWRlcyBndWlkYW5jZSBmb3Igd2hpY2ggY29ubmVjdGlvbiB0 bw0KICAgZ2V0IHJpZCBvZi4gIFdoZW4gdGhpcyBvY2N1cnMsIHRoZSBjb3JyZXNwb25kaW5nIEZT TSBmb3IgdGhlIGNvbm5lYy0NCiAgIHRpb24gdGhhdCBpcyBjbG9zZWQgU0hPVUxEIGJlIGRpc3Bv c2VkIG9mLg0KDQo4LjIuMS4zICBGU00gYW5kIE9wdGlvbmFsIFNlc3Npb24gQXR0cmlidXRlcw0K DQoNCiAgIE9wdGlvbmFsIFNlc3Npb24gQXR0cmlidXRlcyBzcGVjaWZ5IGVpdGhlciBmbGFncyB0 aGF0IGF1Z21lbnQgdGhlDQogICBub3JtYWwgcHJvY2Vzc2luZyBvZiB0aGUgQkdQIEZTTSwgb3Ig b3B0aW9uYWwgdGltZXJzLiAgSWYgYW4NCiAgIE9wdGlvbmFsIFNlc3Npb24gYXR0cmlidXRlIGNh biBiZSBzZXQgb24gYSBzeXN0ZW0sIHRoZSBFdmVudHMgYW5kDQogICB0aGUgQkdQIEZTTSBhY3Rp b25zIG11c3QgYmUgc3VwcG9ydGVkLiAgRm9yIGV4YW1wbGUsIGlmIHRoZQ0KICAgZm9sbG93aW5n IG9wdGlvbnMgY2FuIGJlIHNldCBpbiBhIEJHUCBpbXBsZW1lbnRhdGlvbjogQXV0b1N0YXJ0DQog ICBhbmQgUGFzc2l2ZVRDUEVzdGFibGlzaG1lbnQsIHRoZW4gdGhlIGV2ZW50cyAzLCA0IGFuZCA1 IG11c3QgYmUNCiAgIHN1cHBvcnRlZC4NCg0KICAgSWYgYW4gT3B0aW9uYWwgU2Vzc2lvbiBhdHRy aWJ1dGUgY2Fubm90IGJlIHNldCAodGhhdCBpcyBkZWNsYXJlZA0KICAgYWx3YXlzIG9mZiBsb2dp Y2FsbHkpLCB0aGUgZXZlbnRzIHN1cHBvcnRpbmcgdGhhdCBzZXQgb2YNCiAgIG9wdGlvbnMgZG8g bm90IGhhdmUgdG8gYmUgc3VwcG9ydGVkLg0KDQoNCjguMi4xLjQgRlNNIEV2ZW50IG51bWJlcnMN Cg0KDQogICBUaGUgRXZlbnQgbnVtYmVycyAoMS0yOCkgdXRpbGl6ZWQgaW4gdGhpcyBzdGF0ZSBt YWNoaW5lIGRlc2NyaXB0aW9uDQogICBhaWQgaW4gc3BlY2lmeWluZyB0aGUgYmVoYXZpb3Igb2Yg dGhlIEJHUCBzdGF0ZSBtYWNoaW5lLiAgSW1wbGVtZW50YS0NCiAgIHRpb25zIE1BWSB1c2UgdGhl c2UgbnVtYmVycyB0byBwcm92aWRlIG5ldHdvcmsgbWFuYWdlbWVudCBpbmZvcm1hLQ0KICAgdGlv bi4gVGhlIGV4YWN0IGZvcm0gb2YgdGhlIEZTTSBhbmQgdGhlIEZTTSBldmVudHMgaXMgc3BlY2lm aWMgdG8NCiAgIGVhY2ggaW1wbGVtZW50YXRpb24uDQoNCjguMi4xLjUgRlNNIGFjdGlvbnMgdGhh dCBhcmUgaW1wbGVtZW50YXRpb24gZGVwZW5kZW50Lg0KDQogICBUaGUgQkdQIEZTTSBzcGVjaWZp ZXMgYXQgY2VydGFpbiBwb2ludHMgdGhhdCBCR1AgaW5pdGlhbGl6YXRpb24gd2lsbA0KICAgb2Nj dXIgb3IgdGhhdCBCR1AgcmVzb3VyY2VzIHdpbGwgYmUgZGVsZXRlLiAgVGhlIGluaXRpYWxpemF0 aW9uIG9mIHRoZQ0KICAgQkdQIEZTTSBhbmQgdGhlIGFzc29jaWF0ZSByZXNvdXJjZXMgZGVwZW5k IG9uIHRoZSBwb2xpY3kgcG9ydGlvbiBvZg0KICAgdGhlIEJHUCBpbXBsZW1lbnRhdGlvbi4gIFRo ZSBkZXRhaWxzIG9mIHRoZXNlIGFjdGlvbnMgYXJlIG91dHNpZGUNCiAgIHRoZSBzY29wZSBvZiB0 aGUgRlNNIGRvY3VtZW50LiAgIA0KDQoNCjguMi4yIEZpbml0ZSBTdGF0ZSBNYWNoaW5lDQoNCg0K ICAgICAgSWRsZSBzdGF0ZToNCg0KICAgICAgICBJbml0aWFsbHkgdGhlIEJHUCBwZWVyIEZTTSBp cyBpbiB0aGUgSWRsZSBzdGF0ZS4gKEhlcmVhZnRlcg0KCXRoZSBCR1AgcGVlciBGU00gd2lsbCBi ZSBzaG9ydGVuZWQgdG8gQkdQIEZTTS4pDQoNCiAgICAgICAgIEluIHRoaXMgc3RhdGUgQkdQIEZT TSByZWZ1c2VzIGFsbCBpbmNvbWluZyBCR1ANCiAgICAgICAgIGNvbm5lY3Rpb25zLiAgTm8gcmVz b3VyY2VzIGFyZSBhbGxvY2F0ZWQgdG8gdGhlIHBlZXIuDQogICAgICAgICBJbiByZXNwb25zZSB0 byBhIE1hbnVhbFN0YXJ0IGV2ZW50IChFdmVudDEpIG9yIGFuDQogICAgICAgICBBdXRvbWF0aWNT dGFydCBldmVudCAoRXZlbnQzKSwgdGhlIGxvY2FsIHN5c3RlbToNCiAgICAgICAgICAgIC0gaW5p dGlhbGl6ZXMgYWxsIEJHUCByZXNvdXJjZXMgZm9yIHRoZSBwZWVyIHNlc3Npb24sIA0KICAgICAg ICAgICAgLSBzZXRzIENvbm5lY3RSZXRyeUNvdW50ZXIgdG8gemVybywgDQogICAgICAgICAgICAt IHN0YXJ0cyB0aGUgQ29ubmVjdFJldHJ5VGltZXIgd2l0aCBpbml0aWFsIHZhbHVlLA0KICAgICAg ICAgICAgLSBpbml0aWF0ZXMgYSBUQ1AgY29ubmVjdGlvbiB0byB0aGUgb3RoZXIgQkdQIHBlZXIs DQogICAgICAgICAgICAtIGxpc3RlbnMgZm9yIGEgY29ubmVjdGlvbiB0aGF0IG1heSBiZSBpbml0 aWF0ZWQgYnkNCiAgICAgICAgICAgICAgdGhlIHJlbW90ZSBCR1AgcGVlciwgYW5kDQoNCg0KDQpF eHBpcmF0aW9uIERhdGUgU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAMW1BhZ2UgNDddDQoNCg0KDQoNCg0KUkZDIERSQUZUICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDAzDQoNCg0KICAgICAgICAg ICAgLSBjaGFuZ2VzIGl0cyBzdGF0ZSB0byBDb25uZWN0Lg0KDQogICAgICAgIFRoZSBNYW51YWxT dG9wIGV2ZW50IChFdmVudDIpIGFuZCBBdXRvbWF0aWNTdG9wIChFdmVudCA4KSBldmVudA0KICAg ICAgICBhcmUgaWdub3JlZCBpbiB0aGUgSWRsZSBzdGF0ZS4NCg0KICAgICAgICBJbiByZXNwb25z ZSB0byBhIE1hbnVhbFN0YXJ0X3dpdGhfUGFzc2l2ZVRDUEVzdGFibGlzaGVkIGV2ZW50DQogICAg ICAgIChFdmVudCA0KSBvciBBdXRvbWF0aWNTdGFydF93aXRoX1Bhc3NpdmVUQ1BFc3RhYmxpc2ht ZW50IGV2ZW50DQogICAgICAgIChFdmVudCA1KSwgdGhlIGxvY2FsIHN5c3RlbToNCiAgICAgICAg ICAgIC0gaW5pdGlhbGl6ZXMgYWxsIEJHUCByZXNvdXJjZXMsDQogICAgICAgICAgICAtIHNldHMg dGhlIENvbm5lY3RSZXRyeUNvdW50ZXIgdG8gemVybywNCiAgICAgICAgICAgIC0gc3RhcnRzIHRo ZSBDb25uZWN0UmV0cnlUaW1lciB3aXRoIGluaXRpYWwgdmFsdWUsDQogICAgICAgICAgICAtIGxp c3RlbnMgZm9yIGEgY29ubmVjdGlvbiB0aGF0IG1heSBiZSBpbml0aWF0ZWQgYnkNCiAgICAgICAg ICAgICAgdGhlIHJlbW90ZSBwZWVyLCBhbmQNCiAgICAgICAgICAgIC0gY2hhbmdlcyBpdHMgc3Rh dGUgdG8gQWN0aXZlLg0KDQogICAgICAgIFRoZSBleGFjdCB2YWx1ZSBvZiB0aGUgQ29ubmVjdFJl dHJ5VGltZXIgaXMgYSBsb2NhbA0KICAgICAgICBtYXR0ZXIsIGJ1dCBpdCBTSE9VTEQgYmUgc3Vm ZmljaWVudGx5IGxhcmdlIHRvIGFsbG93IFRDUA0KICAgICAgICBpbml0aWFsaXphdGlvbi4NCg0K ICAgICAgICBJZiB0aGUgRGFtcFBlZXJPc2NpbGxhdGlvbiBhdHRyaWJ1dGUgaXMgZW5hYmxlZCwg DQoJdGhlIGZvbGxvd2luZyB0aHJlZSBhZGRpdGlvbmFsIGV2ZW50cyBtYXkgb2NjdXINCiAgICAg ICAgd2l0aGluIElkbGUgc3RhdGU6DQogICAgICAgICAgICAtIEF1dG9tYXRpY1N0YXJ0X3dpdGhf RGFtcFBlZXJPc2NpbGxhdGlvbiBbRXZlbnQ2XSwNCiAgICAgICAgICAgIC0gQXV0b21hdGljU3Rh cnRfd2l0aF9EYW1wUGVlck9zY2lsbGF0aW9uX2FuZF8NCiAgICAgICAgICAgICAgUGFzc2l2ZVRD UEVzdGFibGlzaG1lbnQgW0V2ZW50N10sDQogICAgICAgICAgICAtIElkbGVIb2xkVGltZXJfRXhw aXJlZCBbRXZlbnQgMTNdLg0KDQogICAgICAgIFRoZSBtZXRob2Qgb2YgcHJldmVudGluZyBwZXJz aXN0ZW50IHBlZXIgb3NjaWxsYXRpb24gaXMNCiAgICAgICAgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyBkb2N1bWVudC4NCg0KICAgICAgICBBbnkgb3RoZXIgZXZlbnQgW0V2ZW50cyA5LTEyLCAx NS0yOF0gcmVjZWl2ZWQgaW4gdGhlIElkbGUgc3RhdGUNCiAgICAgICAgZG9lcyBub3QgY2F1c2Ug Y2hhbmdlIGluIHRoZSBzdGF0ZSBvZiB0aGUgbG9jYWwgc3lzdGVtLg0KDQoNCg0KICAgICAgQ29u bmVjdCBTdGF0ZToNCg0KICAgICAgICBJbiB0aGlzIHN0YXRlLCBCR1AgRlNNIGlzIHdhaXRpbmcg Zm9yIHRoZSBUQ1AgY29ubmVjdGlvbiB0bw0KICAgICAgICBiZSBjb21wbGV0ZWQuDQoNCg0KICAg ICAgICBUaGUgc3RhcnQgZXZlbnRzIFtFdmVudHMgMSwgMy03XSBhcmUgaWdub3JlZCBpbiBjb25u ZWN0DQogICAgICAgIHN0YXRlLg0KDQogICAgICAgIEluIHJlc3BvbnNlIHRvIGEgTWFudWFsU3Rv cCBldmVudCBbRXZlbnQyXSwgdGhlIGxvY2FsIHN5c3RlbToNCiAgICAgICAgICAgLSBkcm9wcyB0 aGUgVENQIGNvbm5lY3Rpb24sDQogICAgICAgICAgIC0gcmVsZWFzZXMgYWxsIEJHUCByZXNvdXJj ZXMsDQogICAgICAgICAgIC0gc2V0cyBDb25uZWN0UmV0cnlDb3VudGVyIHRvIHplcm8sIA0KICAg ICAgICAgICAtIHN0b3BzIHRoZSBDb25uZWN0UmV0cnlUaW1lciBhbmQgc2V0cyBDb25uZWN0UmV0 cnlUaW1lcg0KICAgICAgICAgICAgIHRvIHplcm8sIGFuZA0KDQoNCg0KRXhwaXJhdGlvbiBEYXRl IFNlcHRlbWJlciAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDFtQYWdlIDQ4 XQ0KDQoNCg0KDQoNClJGQyBEUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCiAgICAgICAgICAgLSBjaGFuZ2VzIGl0 cyBzdGF0ZSB0byBJZGxlLg0KDQoNCiAgICAgICAgSW4gcmVzcG9uc2UgdG8gdGhlIENvbm5lY3RS ZXRyeVRpbWVyX0V4cGlyZXMgZXZlbnQgW0V2ZW50DQogICAgICAgIDldLCB0aGUgbG9jYWwgc3lz dGVtOg0KICAgICAgICAgICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVjdGlvbiwNCiAgICAgICAgICAg LSByZXN0YXJ0cyB0aGUgQ29ubmVjdFJldHJ5VGltZXIsDQogICAgICAgICAgIC0gc3RvcHMgdGhl IE9wZW5EZWxheVRpbWVyIGFuZCByZXNldHMgdGhlIHRpbWVyIHRvIHplcm8sDQogICAgICAgICAg IC0gaW5pdGlhdGVzIGEgVENQIGNvbm5lY3Rpb24gdG8gdGhlIG90aGVyIEJHUCBwZWVyLA0KICAg ICAgICAgICAtIGNvbnRpbnVlcyB0byBsaXN0ZW4gZm9yIGEgY29ubmVjdGlvbiB0aGF0IG1heSBi ZQ0KICAgICAgICAgICAgIGluaXRpYXRlZCBieSB0aGUgcmVtb3RlIEJHUCBwZWVyLCBhbmQNCiAg ICAgICAgICAgLSBzdGF5cyBpbiBDb25uZWN0IHN0YXRlLg0KDQogICAgICAgIElmIHRoZSBPcGVu RGVsYXlUaW1lcl9FeHBpcmVzIGV2ZW50IFtFdmVudDEyXSBvY2N1cnMgaW4gdGhlDQogICAgICAg IENvbm5lY3Qgc3RhdGUsIHRoZSBsb2NhbCBzeXN0ZW06DQogICAgICAgICAgIC0gc2VuZHMgYW4g T1BFTiBtZXNzYWdlIHRvIGl0cyBwZWVyLA0KICAgICAgICAgICAtIHNldHMgdGhlIEhvbGRUaW1l ciB0byBhIGxhcmdlIHZhbHVlLCBhbmQNCiAgICAgICAgICAgLSBjaGFuZ2VzIGl0cyBzdGF0ZSB0 byBPcGVuU2VudC4NCg0KICAgICAgICBJZiB0aGUgQkdQIEZTTSByZWNlaXZlcyBhIFRDUENvbm5l Y3Rpb25fdmFsaWQgZXZlbnQNCiAgICAgICAgW0V2ZW50IDE0XSwgdGhlIFRDUCBjb25uZWN0aW9u IGlzIHByb2Nlc3NlZCwgYW5kDQogICAgICAgIHRoZSBjb25uZWN0aW9uIHJlbWFpbnMgaW4gdGhl IENvbm5lY3Qgc3RhdGUuDQoNCiAgICAgICAgSWYgdGhlIEJHUCBGU00gcmVjZWl2ZXMgYSBSZWNl aXZlVENQSW52YWxpZCBldmVudCBbRXZlbnQgMTVdOg0KICAgICAgICB0aGUgbG9jYWwgc3lzdGVt IHJlamVjdHMgdGhlIFRDUCBjb25uZWN0aW9uLCBhbmQgdGhlIGNvbm5lY3Rpb24NCiAgICAgICAg cmVtYWlucyBpbiB0aGUgQ29ubmVjdCBzdGF0ZS4NCg0KICAgICAgICBJZiB0aGUgVENQIGNvbm5l Y3Rpb24gc3VjY2VlZHMgW0V2ZW50IDE2IG9yDQogICAgICAgIEV2ZW50IDE3XSwgdGhlIGxvY2Fs IHN5c3RlbSBjaGVja3MgdGhlIERlbGF5T3BlbiBhdHRyaWJ1dGUgcHJpb3INCiAgICAgICAgdG8g cHJvY2Vzc2luZy4gIElmIHRoZSBEZWxheU9wZW4gYXR0cmlidXRlIGlzIHNldCwgdGhlIGxvY2Fs IHN5c3RlbToNCiAgICAgICAgICAgICAtIHN0b3BzIHRoZSBDb25uZWN0UmV0cnlUaW1lciAoaWYg cnVubmluZykgYW5kIHNldHMgdGhlDQoJICAgICAgIENvbm5lY3RSZXRyeVRpbWVyIHRvIHplcm8s DQogICAgICAgICAgICAgLSBzZXRzIHRoZSBPcGVuIERlbGF5IHRpbWVyIHRvIHRoZSBpbml0aWFs IHZhbHVlLCBhbmQNCiAgICAgICAgICAgICAtIHN0YXlzIGluIHRoZSBDb25uZWN0IHN0YXRlLg0K ICAgICAgICBJZiB0aGUgRGVsYXlPcGVuIGF0dHJpYnV0ZSBpcyBub3Qgc2V0LCB0aGUgbG9jYWwg c3lzdGVtOg0KICAgICAgICAgICAgIC0gc3RvcHMgdGhlIENvbm5lY3RSZXRyeVRpbWVyIChpZiBy dW5uaW5nKSBhbmQgc2V0cyB0aGUNCgkgICAgICAgQ29ubmVjdFJldHJ5VGltZXIgdG8gemVybywN CiAgICAgICAgICAgICAtIGNvbXBsZXRlcyBCR1AgaW5pdGlhbGl6YXRpb24NCiAgICAgICAgICAg ICAtIHNlbmRzIGFuIE9QRU4gbWVzc2FnZSB0byBpdHMgcGVlciwNCiAgICAgICAgICAgICAtIHNl dHMgSG9sZFRpbWVyIHRvIGEgbGFyZ2UgdmFsdWUsIGFuZA0KICAgICAgICAgICAgIC0gY2hhbmdl cyBpdHMgc3RhdGUgdG8gT3BlblNlbnQuDQoNCiAgICAgICAgQSBob2xkIHRpbWVyIHZhbHVlIG9m IDQgbWludXRlcyBpcyBzdWdnZXN0ZWQuDQoNCiAgICAgICAgSWYgdGhlIFRDUCBjb25uZWN0aW9u IGZhaWxzIChUQ1BDb25uZWN0aW9uRmFpbHMgW0V2ZW50MThdKSwNCiAgICAgICAgdGhlIGxvY2Fs IHN5c3RlbSBjaGVja3MgdGhlIE9wZW5EZWxheVRpbWVyLiAgSWYgdGhlDQogICAgICAgIE9wZW5E ZWxheVRpbWVyIGlzIHJ1bm5pbmcsIHRoZSBsb2NhbCBzeXN0ZW06DQogICAgICAgICAgICAtIHJl c3RhcnRzIHRoZSBDb25uZWN0UmV0cnlUaW1lciB3aXRoIGluaXRpYWwgdmFsdWUsDQogICAgICAg ICAgICAtIHN0b3BzIHRoZSBPcGVuRGVsYXlUaW1lciBhbmQgcmVzZXRzIHZhbHVlIHRvIHplcm8s DQogICAgICAgICAgICAtIGNvbnRpbnVlcyB0byBsaXN0ZW4gZm9yIGEgY29ubmVjdGlvbiB0aGF0 IG1heSBiZQ0KDQoNCg0KRXhwaXJhdGlvbiBEYXRlIFNlcHRlbWJlciAyMDAzICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDFtQYWdlIDQ5XQ0KDQoNCg0KDQoNClJGQyBEUkFGVCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAw Mw0KDQoNCiAgICAgICAgICAgICAgaW5pdGlhdGVkIGJ5IHRoZSByZW1vdGUgQkdQIHBlZXIsIGFu ZA0KICAgICAgICAgICAgLSBjaGFuZ2VzIGl0cyBzdGF0ZSB0byBBY3RpdmUuDQoNCiAgICAgICAg SWYgdGhlIE9wZW5EZWxheVRpbWVyIGlzIG5vdCBydW5uaW5nLCB0aGUgbG9jYWwgc3lzdGVtOg0K ICAgICAgICAgICAtIHN0b3BzIHRoZSBDb25uZWN0UmV0cnlUaW1lciB0byB6ZXJvLA0KICAgICAg ICAgICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVjdGlvbiwNCiAgICAgICAgICAgLSByZWxlYXNlcyBh bGwgQkdQIHJlc291cmNlcywgYW5kDQogICAgICAgICAgIC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8g SWRsZS4NCg0KICAgICAgICBJZiBhbiBPUEVOIG1lc3NhZ2UgaXMgcmVjZWl2ZWQgd2hpbGUgdGhl IE9wZW5EZWxheVRpbWVyIGlzDQogICAgICAgIHJ1bm5pbmcgW0V2ZW50IDIwXSwgdGhlIGxvY2Fs IHN5c3RlbToNCg0KICAgICAgICAgICAtIHN0b3BzIHRoZSBDb25uZWN0UmV0cnlUaW1lciAoaWYg cnVubmluZykgYW5kDQoJICAgICBzZXRzIHRoZSBDb25uZWN0UmV0cnlUaW1lciB0byB6ZXJvLA0K ICAgICAgICAgICAtIGNvbXBsZXRlcyB0aGUgQkdQIGluaXRpYWxpemF0aW9uLA0KICAgICAgICAg ICAtIHN0b3BzIGFuZCBjbGVhcnMgdGhlIE9wZW5EZWxheVRpbWVyIA0KICAgICAgICAgICAgIChz ZXRzIHRoZSB2YWx1ZSB0byB6ZXJvKSwNCiAgICAgICAgICAgLSBzZW5kcyBhbiBPUEVOIG1lc3Nh Z2UsDQogICAgICAgICAgIC0gc2VuZHMgYSBLRUVQQUxJVkUgbWVzc2FnZSwNCiAgICAgICAgICAg LSBpZiB0aGUgSG9sZFRpbWVyIGluaXRpYWwgdmFsdWUgaXMgbm9uLXplcm8sDQogICAgICAgICAg ICAgICAgICAgLSBzdGFydHMgdGhlIGtlZXBhbGl2ZSB0aW1lciB0byBpbml0YWwgdmFsdWUgYW5k DQogICAgICAgICAgICAgICAgICAgLSByZXNldHMgdGhlIGhvbGQgdGltZXIgdG8gdGhlIG5lZ290 aWF0ZWQgdmFsdWUsDQogICAgICAgICAgICAgZWxzZSBpZiBIb2xkVGltZXIgSW5pdGlhbCB2YWx1 ZSBpcyB6ZXJvLA0KICAgICAgICAgICAgICAgICAgIC0gcmVzZXRzIHRoZSBrZWVwYWxpdmUgdGlt ZXIgYW5kDQogICAgICAgICAgICAgICAgICAgLSByZXNldHMgdGhlIEhvbGRUaW1lciB2YWx1ZSB0 byB6ZXJvLCANCiAgICAgICAgICAgLSBhbmQgY2hhbmdlcyBpdHMgc3RhdGUgdG8gT3BlbkNvbmZp cm0uDQoNCiAgICAgICAgSWYgdGhlIHZhbHVlIG9mIHRoZSBhdXRvbm9tb3VzIHN5c3RlbSBmaWVs ZCBpcyB0aGUgc2FtZSBhcyB0aGUgbG9jYWwNCiAgICAgICAgQXV0b25vbW91cyBTeXN0ZW0gbnVt YmVyLCBzZXQgdGhlIGNvbm5lY3Rpb24gc3RhdHVzIHRvIGFuIGludGVybmFsDQogICAgICAgIGNv bm5lY3Rpb247IG90aGVyd2lzZSBpdCBpcyAiZXh0ZXJuYWwiLg0KDQogICAgICAgIElmIEJHUCBt ZXNzYWdlIGhlYWRlciBjaGVja2luZyBkZXRlY3RzIGFuIGVycm9yIFtFdmVudCAyMV0gb3INCiAg ICAgICAgT1BFTiBtZXNzYWdlIGNoZWNraW5nIGRldGVjdHMgYW4gZXJyb3IgW0V2ZW50IDIyXSAo c2VlIHNlY3Rpb24NCiAgICAgICAgNi4yKSwgdGhlIGxvY2FsIHN5c3RlbToNCiAgICAgICAgICAg LSBbb3B0aW9uYWxseV0gSWYgdGhlIFNlbmROT1RJRklDQVRJT053aXRob3V0T3BlbiBhdHRyaWJ1 dGUgDQogICAgICAgICAgICAgIGlzIHNldCB0byBUUlVFLCB0aGVuIHRoZSBsb2NhbCBzeXN0ZW0g Zmlyc3Qgc2VuZHMNCiAgICAgICAgICAgICAgYSBOT1RJRklDQVRJT04gbWVzc2FnZSB3aXRoIHRo ZSBhcHByb3ByaWF0ZSBlcnJvcg0KICAgICAgICAgICAgICBjb2RlLCBhbmQgdGhlbg0KDQogICAg ICAgICAgIC0gc3RvcHMgdGhlIENvbm5lY3RSZXRyeVRpbWVyIChpZiBydW5uaW5nKQ0KICAgICAg ICAgICAgIGFuZCBzZXRzIHRoZSBDb25uZWN0UmV0cnlUaW1lciB0byB6ZXJvLA0KICAgICAgICAg ICAtIHJlbGVhc2VzIGFsbCBCR1AgcmVzb3VyY2VzLA0KICAgICAgICAgICAtIGRyb3BzIHRoZSBU Q1AgY29ubmVjdGlvbiwNCiAgICAgICAgICAgLSBpbmNyZW1lbnRzIHRoZSBDb25uZWN0UmV0cnlD b3VudCBieSAxLA0KICAgICAgICAgICAtIFtvcHRpb25hbGx5XSBwZXJmb3JtcyBwZWVyIG9zY2ls bGF0aW9uIGRhbXBpbmcNCgkgICAgIGlmIHRoZSBEYW1wUGVlck9zY2lsbGF0aW9uIGF0dHJpYnV0 ZSBpcyBzZXQgdG8gVFJVRSwgYW5kIA0KICAgICAgICAgICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRv IElkbGUuDQoNCiAgICAgICAgSWYgYSBOT1RJRklDQVRJT04gbWVzc2FnZSBpcyByZWNlaXZlZCB3 aXRoIGEgdmVyc2lvbg0KICAgICAgICBlcnJvcltFdmVudDI0XSwgdGhlIGxvY2FsIHN5c3RlbSBj aGVja3MgdGhlIE9wZW5EZWxheVRpbWVyLg0KICAgICAgICBJZiB0aGUgT3BlbkRlbGF5VGltZXIg aXMgcnVubmluZywgdGhlIGxvY2FsIHN5c3RlbToNCiAgICAgICAgICAgLSBzdG9wcyB0aGUgQ29u bmVjdFJldHJ5VGltZXIgKGlmIHJ1bm5pbmcpIA0KCSAgICAgYW5kIHNldHMgdGhlIENvbm5lY3RS ZXRyeVRpbWVyIHRvIHplcm8sDQogICAgICAgICAgIC0gc3RvcHMgYW5kIHJlc2V0cyB0aGUgT3Bl biBEZWxheSB0aW1lciAoc2V0cyB0byB6ZXJvKSwNCiAgICAgICAgICAgLSByZWxlYXNlcyBhbGwg QkdQIHJlc291cmNlcywNCiAgICAgICAgICAgLSBkcm9wcyB0aGUgVENQIGNvbm5lY3Rpb24sIGFu ZA0KDQoNCg0KRXhwaXJhdGlvbiBEYXRlIFNlcHRlbWJlciAyMDAzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDFtQYWdlIDUwXQ0KDQoNCg0KDQoNClJGQyBEUkFGVCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoN CiAgICAgICAgICAgLSBjaGFuZ2VzIGl0cyBzdGF0ZSB0byBJZGxlLg0KDQogICAgICAgIElmIHRo ZSBPcGVuIERlbGF5IHRpbWVyIGlzIG5vdCBydW5uaW5nLCB0aGUgbG9jYWwgc3lzdGVtOg0KICAg ICAgICAgICAtIHN0b3BzIHRoZSBDb25uZWN0UmV0cnlUaW1lciBhbmQgc2V0cyB0aGUNCgkgICAg IENvbm5lY3RSZXRyeVRpbWVyIHRvIHplcm8sDQogICAgICAgICAgIC0gcmVsZWFzZXMgYWxsIEJH UCByZXNvdXJjZXMsDQogICAgICAgICAgIC0gZHJvcHMgdGhlIFRDUCBjb25uZWN0aW9uLA0KICAg ICAgICAgICAtIGluY3JlbWVudHMgdGhlIENvbm5lY3RSZXRyeUNvdW50IGJ5IDEsDQogICAgICAg ICAgIC0gcGVyZm9ybXMgcGVlciBvc2NpbGxhdGlvbiBkYW1waW5nIGlmIHRoZQ0KCSAgICAgRGFt cFBlZXJPc2NpbGxhdGlvbiBhdHRyaWJ1dGUgaXMgc2V0IHRvIFRydWUsIGFuZA0KICAgICAgICAg ICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRvIElkbGUuDQoNCg0KICAgICAgIEluIHJlc3BvbnNlIHRv IGFueSBvdGhlciBldmVudHMgW0V2ZW50cyA4LDEwLTExLDEzLDE5LDIzLA0KICAgICAgIDI1LTI4 XSB0aGUgbG9jYWwgc3lzdGVtOg0KICAgICAgICAgICAtIGlmIHRoZSBDb25uZWN0UmV0cnlUaW1l ciBpcyBydW5uaW5nLA0KICAgICAgICAgICAgICBzdG9wcyBhbmQgcmVzZXRzIHRoZSBDb25uZWN0 UmV0cnl0aW1lciAoc2V0cyB0byB6ZXJvKSwNCiAgICAgICAgICAgLSBpZiB0aGUgT3BlbiBEZWxh eSB0aW1lciBpcyBydW5uaW5nLA0KICAgICAgICAgICAgICBzdG9wcyBhbmQgcmVzZXRzIHRoZSBP cGVuRGVsYXlUaW1lciAoc2V0cyB0byB6ZXJvKSwNCiAgICAgICAgICAgLSByZWxlYXNlcyBhbGwg QkdQIHJlc291cmNlcywNCiAgICAgICAgICAgLSBkcm9wcyB0aGUgVENQIGNvbm5lY3Rpb24sDQog ICAgICAgICAgIC0gaW5jcmVtZW50cyB0aGUgQ29ubmVjdFJldHJ5Q291bnQgYnkgMSwNCiAgICAg ICAgICAgLSBwZXJmb3JtcyBwZWVyIG9zY2lsbGF0aW9uIGRhbXBpbmcgaWYgdGhlIA0KCSAgICAg RGFtcFBlZXJPc2NpbGxhdGlvbiBhdHRyaWJ1dGUgaXMgc2V0IHRvIFRydWUsIGFuZA0KICAgICAg ICAgICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRvIElkbGUuDQoNCg0KICAgICAgQWN0aXZlIFN0YXRl Og0KDQogICAgICAgSW4gdGhpcyBzdGF0ZSBCR1AgRlNNIGlzIHRyeWluZyB0byBhY3F1aXJlIGEg cGVlciBieSBsaXN0ZW5pbmcNCiAgICAgICBmb3IgYW5kIGFjY2VwdGluZyBhIFRDUCBjb25uZWN0 aW9uLg0KDQoNCiAgICAgICBUaGUgc3RhcnQgZXZlbnRzIFtFdmVudDEsIDMtN10gYXJlIGlnbm9y ZWQgaW4gdGhlIEFjdGl2ZQ0KICAgICAgIHN0YXRlLg0KDQogICAgICAgSW4gcmVzcG9uc2UgdG8g YSBNYW51YWxTdG9wIGV2ZW50W0V2ZW50Ml0sIHRoZSBsb2NhbCBzeXN0ZW06DQogICAgICAgICAg IC0gSWYgdGhlIE9wZW5EZWxheVRpbWVyIGlzIHJ1bm5pbmcgYW5kIHRoZQ0KICAgICAgICAgICAg IFNlbmROT1RJRklDQVRJT053aXRob3V0T3BlbiBzZXNzaW9uIGF0dHJpYnV0ZSBpcyBzZXQsDQog ICAgICAgICAgICAgICB0aGUgbG9jYWwgc3lzdGVtIHNlbmRzIGEgTk9USUZJQ0FUSU9OIHdpdGgg YSBDZWFzZSwNCiAgICAgICAgICAgLSByZWxlYXNlcyBhbGwgQkdQIHJlc291cmNlcyBpbmNsdWRp bmcNCiAgICAgICAgICAgICAgICAgICAtIHN0b3BwaW5nIHRoZSBPcGVuRGVsYXlUaW1lcg0KICAg ICAgICAgICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVjdGlvbiwNCiAgICAgICAgICAgLSBzZXRzIENv bm5lY3RSZXRyeUNvdW50IHRvIHplcm8sIA0KICAgICAgICAgICAtIHN0b3BzIHRoZSBDb25uZWN0 UmV0cnlUaW1lciBhbmQgc2V0cyB0aGUgDQoJICAgICBDb25uZWN0UmV0cnlUaW1lciB0byB6ZXJv LCBhbmQNCiAgICAgICAgICAgLSBjaGFuZ2VzIGl0cyBzdGF0ZSB0byBJZGxlLg0KDQogICAgICAg SW4gcmVzcG9uc2UgdGhlIENvbm5lY3RSZXRyeVRpbWVyIGV4cGlyZXMgZXZlbnQgW0V2ZW50OV0s DQogICAgICAgdGhlIGxvY2FsIHN5c3RlbToNCiAgICAgICAgICAgLSByZXN0YXJ0cyB0aGUgQ29u bmVjdFJldHJ5VGltZXIgKHdpdGggaW5pdGlhbCB2YWx1ZSksDQogICAgICAgICAgIC0gaW5pdGlh dGVzIGEgVENQIGNvbm5lY3Rpb24gdG8gdGhlIG90aGVyIEJHUCBwZWVyLA0KICAgICAgICAgICAt IGNvbnRpbnVlcyB0byBsaXN0ZW4gZm9yIFRDUCBjb25uZWN0aW9uIHRoYXQgbWF5IGJlDQoNCg0K DQpFeHBpcmF0aW9uIERhdGUgU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAMW1BhZ2UgNTFdDQoNCg0KDQoNCg0KUkZDIERSQUZUICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDAzDQoNCg0KICAgICAg ICAgICAgIGluaXRpYXRlZCBieSByZW1vdGUgQkdQIHBlZXIsIGFuZA0KICAgICAgICAgICAtIGNo YW5nZXMgaXRzIHN0YXRlIHRvIENvbm5lY3QuDQoNCg0KICAgICAgIElmIHRoZSBsb2NhbCBzeXN0 ZW0gcmVjZWl2ZXMgYW4gT3BlbkRlbGF5VGltZXJfRXhwaXJlZCBldmVudA0KICAgICAgIFtFdmVu dDEyXSwgdGhlIGxvY2FsIHN5c3RlbToNCiAgICAgICAgICAgLSBzZXRzIHRoZSBDb25uZWN0UmV0 cnlUaW1lciB0byB6ZXJvLA0KICAgICAgICAgICAtIHN0b3BzIGFuZCBjbGVhcnMgdGhlIE9wZW5E ZWxheVRpbWVyIChzZXQgdG8gemVybyksDQogICAgICAgICAgIC0gY29tcGxldGVzIHRoZSBCR1Ag aW5pdGlhbGl6YXRpb24sDQogICAgICAgICAgIC0gc2VuZHMgdGhlIE9QRU4gbWVzc2FnZSB0byBp dHMgcmVtb3RlIHBlZXIsDQogICAgICAgICAgIC0gc2V0cyBpdHMgaG9sZCB0aW1lciB0byBhIGxh cmdlIHZhbHVlLCBhbmQNCiAgICAgICAgICAgLSBjaGFuZ2VzIGl0cyBzdGF0ZSB0byBPcGVuU2Vu dC4NCg0KICAgICAgIEEgaG9sZCB0aW1lciB2YWx1ZSBvZiA0IG1pbnV0ZXMgaXMgYWxzbyBzdWdn ZXN0ZWQgZm9yIHRoaXMNCiAgICAgICBzdGF0ZSB0cmFuc2l0aW9uLg0KDQogICAgICAgSWYgdGhl IGxvY2FsIHN5c3RlbSByZWNlaXZlcyBhIFRDUENvbm5lY3Rpb25fVmFsaWQgZXZlbnQNCiAgICAg ICBbRXZlbnQgMTRdLCB0aGUgbG9jYWwgc3lzdGVtIHByb2Nlc3NlcyB0aGUgVENQIGNvbm5lY3Rp b24NCiAgICAgICBmbGFncyBhbmQgc3RheXMgaW4gQWN0aXZlIHN0YXRlLg0KDQoNCiAgICAgICBJ ZiB0aGUgbG9jYWwgc3lzdGVtIHJlY2VpdmVzIGFuIFRDUF9DUl9JbnZhbGlkIGV2ZW50IFtFdmVu dCAxNV06DQogICAgICAgdGhlIGxvY2FsIHN5c3RlbSByZWplY3RzIHRoZSBUQ1AgY29ubmVjdGlv biBhbmQgc3RheXMgaW4NCiAgICAgICB0aGUgQWN0aXZlIFN0YXRlLg0KDQogICAgICAgSW4gcmVz cG9uc2UgdG8gYSBUQ1AgY29ubmVjdGlvbiBzdWNjZWVkaW5nIFtFdmVudCAxNiBvciBFdmVudCAx N10sIHRoZQ0KICAgICAgIGxvY2FsIHN5c3RlbSBjaGVja3MgdGhlIERlbGF5T3BlbiBhdHRyaWJ1 dGUgcHJpb3IgdG8NCiAgICAgICBwcm9jZXNzaW5nLiANCiAgICAgICAgICAgSWYgdGhlIERlbGF5 T3BlbiBhdHRyaWJ1dGUgaXMgc2V0IHRvIFRSVUUsIHRoZSBsb2NhbA0KICAgICAgICAgICBzeXN0 ZW06DQogICAgICAgICAgICAgICAgLSBzdG9wcyB0aGUgQ29ubmVjdFJldHJ5VGltZXIgYW5kIHNl dHMgdGhlIA0KICAgICAgICAgICAgICAgICAgQ29ubmVjdFJldHJ5VGltZXIgdG8gemVybywNCiAg ICAgICAgICAgICAgICAtIHNldHMgdGhlIEJHUCBPcGVuRGVsYXlUaW1lciB0byB0aGUgaW5pdGlh bCB2YWx1ZSwgYW5kDQogICAgICAgICAgICAgICAgLSBzdGF5cyBpbiB0aGUgQWN0aXZlIHN0YXRl Lg0KICAgICAgICAgICBJZiB0aGUgRGVsYXlPcGVuIGF0dHJpYnV0ZSBpcyBub3Qgc2V0IHRvIFRS VUUsIHRoZSBsb2NhbA0KICAgICAgICAgICBzeXN0ZW06DQogICAgICAgICAgICAgICAgLSBzZXRz IHRoZSBDb25uZWN0UmV0cnlUaW1lciB0byB6ZXJvLA0KICAgICAgICAgICAgICAgIC0gY29tcGxl dGVzIHRoZSBCR1AgaW5pdGlhbGl6YXRpb24sDQogICAgICAgICAgICAgICAgLSBzZW5kcyB0aGUg T1BFTiBtZXNzYWdlIHRvIGl0cyBwZWVyLA0KICAgICAgICAgICAgICAgIC0gc2V0cyBpdHMgaG9s ZCB0aW1lciB0byBhIGxhcmdlIHZhbHVlLCBhbmQNCiAgICAgICAgICAgICAgICAtIGNoYW5nZXMg aXRzIHN0YXRlIHRvIE9wZW5TZW50Lg0KDQogICAgICAgQSBIb2xkVGltZXIgdmFsdWUgb2YgNCBt aW51dGVzIGlzIHN1Z2dlc3RlZCBhcyBhICJsYXJnZSB2YWx1ZSIgZm9yDQogICAgICAgdGhlIEhv bGRUaW1lci4NCg0KDQogICAgICAgSWYgdGhlIGxvY2FsIHN5c3RlbSByZWNlaXZlcyBhIFRDUENv bm5lY3Rpb25GYWlscyBldmVudCBbRXZlbnQgMThdLA0KICAgICAgIHRoZSBsb2NhbCBzeXN0ZW06 DQogICAgICAgICAgIC0gcmVzdGFydHMgQ29ubmVjdFJldHJ5VGltZXIgKHdpdGggaW5pdGlhbCB2 YWx1ZSksDQogICAgICAgICAgIC0gc3RvcHMgYW5kIGNsZWFycyBPcGVuRGVsYXlUaW1lciAoc2V0 cyB0aGUgdmFsdWUgdG8gemVybyksDQogICAgICAgICAgIC0gcmVsZWFzZXMgYWxsIEJHUCByZXNv dXJjZXMsDQoNCg0KDQpFeHBpcmF0aW9uIERhdGUgU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAMW1BhZ2UgNTJdDQoNCg0KDQoNCg0KUkZDIERSQUZUICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDAz DQoNCg0KICAgICAgICAgICAtIGluY3JlbWVudHMgQ29ubmVjdFJldHJ5Q291bnQgYnkgMSwgYW5k DQogICAgICAgICAgIC0gb3B0aW9uYWxseSBwZXJmb3JtcyBwZWVyIG9zY2lsbGF0aW9uIGRhbXBp bmcgaWYNCiAgICAgICAgICAgICB0aGUgRGFtcFBlZXJPc2NpbGxhdGlvbiBhdHRyaWJ1dGUgaXMg c2V0IHRvIFRSVUUsIGFuZA0KICAgICAgICAgICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRvIElkbGUu DQoNCg0KICAgICAgIElmIGFuIE9QRU4gbWVzc2FnZSBpcyByZWNlaXZlZCB3aXRoIHRoZSBPcGVu RGVsYXlUaW1lciBpcw0KICAgICAgIHJ1bm5pbmcgW0V2ZW50IDIwXSwgdGhlIGxvY2FsIHN5c3Rl bToNCiAgICAgICAgICAgLSBzZXRzIHRoZSBDb25uZWN0UmV0cnlUaW1lciB0byB6ZXJvLA0KICAg ICAgICAgICAtIHN0b3BzIGFuZCBjbGVhcnMgdGhlIE9wZW5EZWxheVRpbWVyDQogICAgICAgICAg IC0gY29tcGxldGVzIHRoZSBCR1AgaW5pdGlhbGl6YXRpb24sDQogICAgICAgICAgIC0gc2VuZHMg YW4gT1BFTiBtZXNzYWdlLA0KICAgICAgICAgICAtIHNlbmRzIGEgS0VFUEFMSVZFIG1lc3NhZ2Us IA0KICAgICAgICAgICAtIGlmIHRoZSBIb2xkVGltZXIgdmFsdWUgaXMgbm9uLXplcm8sDQogICAg ICAgICAgICAgICAgICAgLSBzdGFydHMgdGhlIEtlZXBhbGl2ZVRpbWVyIHRvIGluaXRpYWwgdmFs dWUsDQogICAgICAgICAgICAgICAgICAgLSByZXNldHMgdGhlIEhvbGRUaW1lciB0byB0aGUgbmVn b3RpYXRlZCB2YWx1ZSwNCiAgICAgICAgICAgICBlbHNlIGlmIHRoZSBIb2xkVGltZXIgaXMgemVy bw0KICAgICAgICAgICAgICAgICAgIC0gcmVzZXRzIHRoZSBLZWVwYWxpdmVUaW1lciAoc2V0IHRv IHplcm8pLA0KICAgICAgICAgICAgICAgICAgIC0gcmVzZXRzIHRoZSBIb2xkVGltZXIgdG8gemVy bywgYW5kDQogICAgICAgICAgIC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8gT3BlbkNvbmZpcm0uDQoN CiAgICAgICBJZiB0aGUgdmFsdWUgb2YgdGhlIGF1dG9ub21vdXMgc3lzdGVtIGZpZWxkIGlzIHRo ZSBzYW1lIGFzIHRoZSBsb2NhbA0KICAgICAgIEF1dG9ub21vdXMgU3lzdGVtIG51bWJlciwgc2V0 IHRoZSBjb25uZWN0aW9uIHN0YXR1cyB0byBhbiBpbnRlcm5hbA0KICAgICAgIGNvbm5lY3Rpb247 IG90aGVyd2lzZSBpdCBpcyAiZXh0ZXJuYWwiLg0KDQogICAgICAgSWYgQkdQIG1lc3NhZ2UgaGVh ZGVyIGNoZWNraW5nIGRldGVjdHMgYW4gZXJyb3IgW0V2ZW50IDIxXSBvciBPUEVODQogICAgICAg bWVzc2FnZSBjaGVja2luZyBkZXRlY3RzIGFuIGVycm9yIFtFdmVudCAyMl0gKHNlZSBzZWN0aW9u IDYuMiksIHRoZQ0KICAgICAgIGxvY2FsIHN5c3RlbToNCiAgICAgICAgICAgLSBbb3B0aW9uYWxs eV0gc2VuZHMgYSBOT1RJRklDQVRJT04gbWVzc2FnZSB3aXRoIHRoZQ0KICAgICAgICAgICAgICBh cHByb3ByaWF0ZSBlcnJvciBjb2RlIGlmIHRoZSBTZW5kTk9USUZJQ0FUSU9Od2l0aG91dE9wZW4N CgkgICAgICBhdHRyaWJ1dGUgaXMgc2V0IHRvIFRSVUUsICANCiAgICAgICAgICAgLSBzZXRzIHRo ZSBDb25uZWN0UmV0cnlUaW1lciB0byB6ZXJvLA0KICAgICAgICAgICAtIHJlbGVhc2VzIGFsbCBC R1AgcmVzb3VyY2VzLA0KICAgICAgICAgICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVjdGlvbiwNCiAg ICAgICAgICAgLSBpbmNyZW1lbnRzIHRoZSBDb25uZWN0UmV0cnlDb3VudCBieSAxLA0KICAgICAg ICAgICAtIFtvcHRpb25hbGx5XSBwZXJmb3JtcyBwZWVyIG9zY2lsbGF0aW9uIGRhbXBpbmcgaWYg dGhlDQoJICAgICBEYW1wUGVlck9zY2lsbGF0aW9uIGF0dHJpYnV0ZSBpcyBzZXQgdG8gVFJVRSwg YW5kDQogICAgICAgICAgIC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8gSWRsZS4NCg0KICAgICAgICBJ ZiBhIE5PVElGSUNBVElPTiBtZXNzYWdlIGlzIHJlY2VpdmVkIHdpdGggYSB2ZXJzaW9uDQogICAg ICAgIGVycm9yW0V2ZW50MjRdLCB0aGUgbG9jYWwgc3lzdGVtIGNoZWNrcyB0aGUgT3BlbkRlbGF5 VGltZXIuDQogICAgICAgIElmIHRoZSBPcGVuRGVsYXlUaW1lciBpcyBydW5uaW5nLCB0aGUgbG9j YWwgc3lzdGVtOg0KICAgICAgICAgICAtIHN0b3BzIHRoZSBDb25uZWN0UmV0cnlUaW1lciAoaWYg cnVubmluZykgYW5kDQogICAgICAgICAgICAgc2V0cyB0aGUgQ29ubmVjdFJldHJ5VGltZXIgdG8g emVybywNCiAgICAgICAgICAgLSBzdG9wcyBhbmQgcmVzZXQgdGhlIE9wZW5EZWxheVRpbWVyIChz ZXRzIHRvIHplcm8pLA0KICAgICAgICAgICAtIHJlbGVhc2VzIGFsbCBCR1AgcmVzb3VyY2VzLA0K ICAgICAgICAgICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVjdGlvbiwgYW5kDQogICAgICAgICAgIC0g Y2hhbmdlcyBpdHMgc3RhdGUgdG8gSWRsZS4NCiAgICAgICAgSWYgdGhlIE9wZW4gRGVsYXkgdGlt ZXIgaXMgbm90IHJ1bm5pbmcsIHRoZSBsb2NhbCBzeXN0ZW06DQogICAgICAgICAgIC0gc2V0cyB0 aGUgQ29ubmVjdFJldHJ5VGltZXIgdG8gemVybywNCg0KDQoNCkV4cGlyYXRpb24gRGF0ZSBTZXB0 ZW1iZXIgMjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAxbUGFnZSA1M10NCg0K DQoNCg0KDQpSRkMgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE1hcmNoIDIwMDMNCg0KDQogICAgICAgICAgIC0gcmVsZWFzZXMgYWxsIEJH UCByZXNvdXJjZXMsDQogICAgICAgICAgIC0gZHJvcHMgdGhlIFRDUCBjb25uZWN0aW9uLA0KICAg ICAgICAgICAtIGluY3JlbWVudHMgdGhlIENvbm5lY3RSZXRyeUNvdW50IGJ5IDEsDQogICAgICAg ICAgIC0gW29wdGlvbmFsbHldIHBlcmZvcm1zIHBlZXIgb3NjaWxsYXRpb24gZGFtcGluZw0KCSAg ICAgaWYgdGhlIERhbXBQZWVyT3NjaWxsYXRpb24gYXR0cmlidXRlIGlzIHNldCwgYW5kDQogICAg ICAgICAgIC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8gSWRsZS4NCg0KICAgICAgIEluIHJlc3BvbnNl IHRvIGFueSBvdGhlciBldmVudCBbRXZlbnRzIDgsMTAtMTEsMTMsMTksMjMsMjUtMjhdLA0KICAg ICAgIHRoZSBsb2NhbCBzeXN0ZW06DQogICAgICAgICAgIC0gc2V0cyB0aGUgQ29ubmVjdFJldHJ5 VGltZXIgdG8gemVybywNCiAgICAgICAgICAgLSByZWxlYXNlcyBhbGwgQkdQIHJlc291cmNlcywN CiAgICAgICAgICAgLSBkcm9wcyB0aGUgVENQIGNvbm5lY3Rpb24sDQogICAgICAgICAgIC0gaW5j cmVtZW50cyB0aGUgQ29ubmVjdFJldHJ5Q291bnQgYnkgb25lLA0KICAgICAgICAgICAtIFtvcHRp b25hbGx5XSBwZXJmb3JtcyBwZWVyIG9zY2lsbGF0aW9uIGRhbXBpbmcgaWYNCgkgICAgIHRoZSBE YW1wUGVlck9zY2lsbGF0aW9uIGF0dHJpYnV0ZSBpcyBzZXQgdG8gVFJVRSwgYW5kDQogICAgICAg ICAgIC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8gSWRsZS4NCg0KDQogICAgICBPcGVuU2VudDoNCg0K ICAgICAgIEluIHRoaXMgc3RhdGUgQkdQIEZTTSB3YWl0cyBmb3IgYW4gT1BFTiBtZXNzYWdlIGZy b20gaXRzIHBlZXIuDQoNCiAgICAgICBUaGUgU3RhcnQgZXZlbnRzIFtFdmVudDEsIDMtN10gYXJl IGlnbm9yZWQgaW4gdGhlIE9wZW5TZW50DQogICAgICAgc3RhdGUuDQoNCiAgICAgICBJZiBhIE1h bnVhbFN0b3AgZXZlbnQgW0V2ZW50IDJdIGlzIGlzc3VlZCBpbiBPcGVuIHNlbnQNCiAgICAgICBz dGF0ZSwgdGhlIGxvY2FsIHN5c3RlbToNCiAgICAgICAgICAgLSBzZW5kcyB0aGUgTk9USUZJQ0FU SU9OIHdpdGggYSBjZWFzZSwNCiAgICAgICAgICAgLSBzZXRzIHRoZSBDb25uZWN0UmV0cnlUaW1l ciB0byB6ZXJvLA0KICAgICAgICAgICAtIHJlbGVhc2VzIGFsbCBCR1AgcmVzb3VyY2VzLA0KICAg ICAgICAgICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVjdGlvbiwNCiAgICAgICAgICAgLSBzZXQgQ29u bmVjdFJldHJ5Q291bnQgdG8gemVybywgYW5kDQogICAgICAgICAgIC0gY2hhbmdlcyBpdHMgc3Rh dGUgdG8gSWRsZS4NCg0KICAgICAgIElmIGFuIEF1dG9tYXRpY1N0b3AgZXZlbnQgW0V2ZW50IDhd IGlzIGlzc3VlZCBpbiBPcGVuU2VudA0KICAgICAgIHN0YXRlLCB0aGUgbG9jYWwgc3lzdGVtOg0K ICAgICAgICAgICAtIHNlbmRzIHRoZSBOT1RJRklDQVRJT04gd2l0aCBhIGNlYXNlLA0KICAgICAg ICAgICAtIHNldHMgdGhlIENvbm5lY3RSZXRyeVRpbWVyIHRvIHplcm8sDQogICAgICAgICAgIC0g cmVsZWFzZSBhbGwgdGhlIEJHUCByZXNvdXJjZXMsDQogICAgICAgICAgIC0gZHJvcHMgdGhlIFRD UCBjb25uZWN0aW9uLA0KICAgICAgICAgICAtIGluY3JlbWVudHMgdGhlIENvbm5lY3RSZXRyeUNv dW50IGJ5IDEsDQogICAgICAgICAgIC0gW29wdGlvbmFsbHldIHBlcmZvcm1zIHBlZXIgb3NjaWxs YXRpb24gZGFtcGluZyBpZiB0aGUNCgkgICAgIERhbXBQZWVyT3NjaWxsYXRpb24gYXR0cmlidXRl IGlzIHNldCwgYW5kDQogICAgICAgICAgIC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8gSWRsZS4NCg0K ICAgICAgIElmIHRoZSBIb2xkVGltZXJfRXhwaXJlc1tFdmVudCAxMF0sIHRoZSBsb2NhbCBzeXN0 ZW06DQogICAgICAgICAgIC0gc2VuZHMgYSBOT1RJRklDQVRJT04gbWVzc2FnZSB3aXRoIGVycm9y IGNvZGUgSG9sZA0KICAgICAgICAgICAgIFRpbWVyIEV4cGlyZWQsDQogICAgICAgICAgIC0gc2V0 cyB0aGUgQ29ubmVjdFJldHJ5VGltZXIgdG8gemVybywNCiAgICAgICAgICAgLSByZWxlYXNlcyBh bGwgQkdQIHJlc291cmNlcywNCiAgICAgICAgICAgLSBkcm9wcyB0aGUgVENQIGNvbm5lY3Rpb24s DQoNCg0KDQpFeHBpcmF0aW9uIERhdGUgU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAMW1BhZ2UgNTRdDQoNCg0KDQoNCg0KUkZDIERSQUZUICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDAzDQoNCg0K ICAgICAgICAgICAtIGluY3JlbWVudHMgdGhlIENvbm5lY3RSZXRyeUNvdW50LCANCiAgICAgICAg ICAgLSBbb3B0aW9uYWxseV0gcGVyZm9ybXMgcGVlciBvc2NpbGxhdGlvbiBkYW1waW5nIGlmIHRo ZQ0KCSAgICAgRGFtcFBlZXJPc2NpbGxhdGlvbiBhdHRyaWJ1dGUgaXMgc2V0IHRvIFRSVUUsIGFu ZA0KICAgICAgICAgICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRvIElkbGUuDQoNCiAgICAgICAgSWYg YSBUQ1BfQ29ubmVjdGlvbl92YWxpZCBbRXZlbnQgMTRdIG9yIFRDUF9DUl9hY2tlZCBbRXZlbnQg MTZdDQogICAgICAgIGlzIHJlY2VpdmVkLCBvciBhIFRDUENvbm5lY3RDb25maXJtIGV2ZW50IFtF dmVudCAxN10gaXMNCiAgICAgICAgcmVjZWl2ZWQsIGEgc2Vjb25kIFRDUCBzZXNzaW9uIG1heSBi ZSBpbiBwcm9ncmVzcy4gIFRoaXMNCiAgICAgICAgc2Vjb25kIFRDUCBzZXNzaW9uIGlzIHRyYWNr ZWQgcGVyIENvbm5lY3Rpb24gQ29sbGlzaW9uDQogICAgICAgIHByb2Nlc3NpbmcgKFNlY3Rpb24g Ni44KSB1bnRpbCBhbiBPUEVOIG1lc3NhZ2UgaXMgcmVjZWl2ZWQuDQoNCiAgICAgICAgQSBUQ1Ag Q29ubmVjdGlvbiBSZXF1ZXN0IGZvciBhbiBJbnZhbGlkIHBvcnQgDQoJKFRDUF9DUl9JbnZhbGlk UG9ydCBldmVudCBbRXZlbnQgMTVdKSBpcyBpZ25vcmVkLg0KDQogICAgICAgIElmIGEgVENQQ29u bmVjdGlvbkZhaWxzIGV2ZW50IFtFdmVudDE4XSBpbmRpY2F0aW9uIGlzIHJlY2VpdmVkLA0KICAg ICAgICB0aGUgbG9jYWwgc3lzdGVtOg0KICAgICAgICAgICAtIGNsb3NlcyB0aGUgQkdQIGNvbm5l Y3Rpb24sDQogICAgICAgICAgIC0gcmVzdGFydHMgdGhlIENvbm5lY3QgUmV0cnkgdGltZXIsDQog ICAgICAgICAgIC0gY29udGludWVzIHRvIGxpc3RlbiBmb3IgYSBjb25uZWN0aW9uIHRoYXQgbWF5 IGJlDQogICAgICAgICAgICAgaW5pdGlhdGVkIGJ5IHRoZSByZW1vdGUgQkdQIHBlZXIsIGFuZA0K ICAgICAgICAgICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRvIEFjdGl2ZS4NCg0KDQogICAgICAgIFdo ZW4gYW4gT1BFTiBtZXNzYWdlIGlzIHJlY2VpdmVkLCBhbGwgZmllbGRzIGFyZSBjaGVja2VkDQog ICAgICAgIGZvciBjb3JyZWN0bmVzcy4gIElmIHRoZXJlIGFyZSBubyBlcnJvcnMgaW4gdGhlIE9Q RU4gbWVzc2FnZQ0KICAgICAgICBbRXZlbnQgMTldLCB0aGUgbG9jYWwgc3lzdGVtOg0KICAgICAg ICAgICAtIHJlc2V0cyB0aGUgT3BlbkRlbGF5VGltZXIgdG8gemVybywNCiAgICAgICAgICAgLSBz ZXRzIHRoZSBCR1AgQ29ubmVjdFJldHJ5VGltZXIgdG8gemVybywNCiAgICAgICAgICAgLSBzZW5k cyBhIEtFRVBBTElWRSBtZXNzYWdlLCBhbmQNCiAgICAgICAgICAgLSBzZXRzIGEgS2VlcEFsaXZl VGltZXIgKHZpYSB0aGUgdGV4dCBiZWxvdykNCiAgICAgICAgICAgLSBzZXRzIHRoZSBIb2xkVGlt ZXIgYWNjb3JkaW5nIHRvIHRoZSBuZWdvdGlhdGVkIHZhbHVlDQogICAgICAgICAgICAgKHNlZSBT ZWN0aW9uIDQuMiksIA0KICAgICAgICAgICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRvIE9wZW5Db25m aXJtLg0KDQogICAgICAgIElmIHRoZSBuZWdvdGlhdGVkIGhvbGQgdGltZSB2YWx1ZSBpcyB6ZXJv LCB0aGVuIHRoZSBIb2xkIGFuZA0KICAgICAgICBLZWVwQWxpdmUgdGltZXJzIGFyZSBub3Qgc3Rh cnRlZC4gSWYgdGhlIHZhbHVlIG9mIHRoZSBBdXRvbm9tb3VzDQogICAgICAgIFN5c3RlbSBmaWVs ZCBpcyB0aGUgc2FtZSBhcyB0aGUgbG9jYWwgQXV0b25vbW91cyBTeXN0ZW0gbnVtYmVyLA0KICAg ICAgICB0aGVuIHRoZSBjb25uZWN0aW9uIGlzIGFuICJpbnRlcm5hbCIgY29ubmVjdGlvbjsgb3Ro ZXJ3aXNlLCBpdA0KICAgICAgICBpcyBhbiAiZXh0ZXJuYWwiIGNvbm5lY3Rpb24uICBbVGhpcyB3 aWxsIGltcGFjdCBVUERBVEUgcHJvY2Vzc2luZw0KICAgICAgICBhcyBkZXNjcmliZWQgYmVsb3cu XQ0KDQoNCiAgICAgICAgSWYgdGhlIEJHUCBtZXNzYWdlIGhlYWRlciBjaGVja2luZyBbRXZlbnQy MV0gb3IgT1BFTiBtZXNzYWdlDQogICAgICAgIGNoZWNrIGRldGVjdHMgYW4gZXJyb3IgKHNlZSBT ZWN0aW9uIDYuMilbRXZlbnQyMl0sIHRoZSBsb2NhbCBzeXN0ZW06DQogICAgICAgICAgIC0gc2Vu ZHMgYSBOT1RJRklDQVRJT04gbWVzc2FnZSB3aXRoIGFwcHJvcHJpYXRlIGVycm9yDQogICAgICAg ICAgICAgY29kZSwNCiAgICAgICAgICAgLSBzZXRzIHRoZSBDb25uZWN0IFJldHJ5IHRpbWVyIHRv IHplcm8sDQogICAgICAgICAgIC0gcmVsZWFzZXMgYWxsIEJHUCByZXNvdXJjZXMsDQogICAgICAg ICAgIC0gZHJvcHMgdGhlIFRDUCBjb25uZWN0aW9uLCANCg0KDQoNCkV4cGlyYXRpb24gRGF0ZSBT ZXB0ZW1iZXIgMjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAxbUGFnZSA1NV0N Cg0KDQoNCg0KDQpSRkMgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE1hcmNoIDIwMDMNCg0KDQogICAgICAgICAgIC0gaW5jcmVtZW50cyB0 aGUgQ29ubmVjdFJldHJ5Q291bnQgYnkgMSwNCiAgICAgICAgICAgLSBbb3B0aW9uYWxseV0gcGVy Zm9ybXMgcGVlciBvc2NpbGxhdGlvbiBkYW1waW5nIGlmIHRoZQ0KCSAgICAgRGFtcFBlZXJPc2Np bGxhdGlvbiBhdHRyaWJ1dGUgaXMgVFJVRSwgYW5kDQogICAgICAgICAgIC0gY2hhbmdlcyBpdHMg c3RhdGUgdG8gSWRsZS4NCg0KICAgICAgICBDb2xsaXNpb24gZGV0ZWN0aW9uIG1lY2hhbmlzbXMg KFNlY3Rpb24gNi44KSBuZWVkIHRvIGJlDQogICAgICAgIGFwcGxpZWQgd2hlbiBhIHZhbGlkIEJH UCBPUEVOIG1lc3NhZ2UgaXMgcmVjZWl2ZWQgW0V2ZW50IDE5IG9yDQogICAgICAgIEV2ZW50IDIw XS4gUGxlYXNlIHJlZmVyIHRvIFNlY3Rpb24gNi44IGZvciB0aGUgZGV0YWlscyBvZg0KICAgICAg ICB0aGUgY29tcGFyaXNvbi4gQW4gQ29sbGlzaW9uRGV0ZWN0RHVtcCBldmVudHMgb2NjdXJzIHdo ZW4gdGhlDQogICAgICAgIEJHUCBpbXBsZW1lbnRhdGlvbiBkZXRlcm1pbmVzLCBieSBhIG1lYW5z IG91dHNpZGUgdGhlIHNjb3BlIG9mDQogICAgICAgIHRoaXMgZG9jdW1lbnQsIHRoYXQgYSBjb25u ZWN0aW9uIGNvbGxpc2lvbiBoYXMgb2NjdXJyZWQuDQoNCiAgICAgICAgSWYgYSBjb25uZWN0aW9u IGluIE9wZW5TZW50IGlzIGRldGVybWluZWQgdG8gYmUgdGhlDQogICAgICAgIGNvbm5lY3Rpb24g dGhhdCBtdXN0IGJlIGNsb3NlZCwgYW4gT3BlbkNvbGxpc2lvbkR1bXAgW0V2ZW50IDIzXQ0KICAg ICAgICBpcyBzaWduYWxlZCB0byB0aGUgc3RhdGUgbWFjaGluZS4gSWYgc3VjaCBhbiBldmVudCBp cw0KICAgICAgICByZWNlaXZlZCBpbiBPcGVuU2VudCwgdGhlIGxvY2FsIHN5c3RlbToNCiAgICAg ICAgICAgLSBzZW5kcyBhIE5PVElGSUNBVElPTiB3aXRoIGEgQ2Vhc2UNCiAgICAgICAgICAgLSBz ZXRzIHRoZSBDb25uZWN0UmV0cnlUaW1lciB0byB6ZXJvLA0KICAgICAgICAgICAtIHJlbGVhc2Vz IGFsbCBCR1AgcmVzb3VyY2VzLA0KICAgICAgICAgICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVjdGlv biwNCiAgICAgICAgICAgLSBpbmNyZW1lbnRzIENvbm5lY3RSZXRyeUNvdW50IGJ5IDEsDQogICAg ICAgICAgIC0gW29wdGlvbmFsbHldIHBlcmZvcm1zIHBlZXIgb3NjaWxsYXRpb24gZGFtcGluZyBp ZiB0aGUNCgkgICAgIERhbXBQZWVyT3NjaWxsYXRpb24gYXR0cmlidXRlIGlzIHNldCB0byBUUlVF LCBhbmQNCiAgICAgICAgICAgLSBjaGFuZ2VzIGl0cyBzdGF0ZSB0byBJZGxlLg0KDQoNCiAgICAg ICAgSWYgYSBOT1RJRklDQVRJT04gbWVzc2FnZSBpcyByZWNlaXZlZCB3aXRoIGEgdmVyc2lvbg0K ICAgICAgICBlcnJvciBbRXZlbnQyNF0sIHRoZSBsb2NhbCBzeXN0ZW06DQogICAgICAgICAgIC0g c2V0cyB0aGUgQ29ubmVjdFJldHJ5VGltZXIgdG8gemVybywNCiAgICAgICAgICAgLSByZWxlYXNl cyBhbGwgQkdQIHJlc291cmNlcywNCiAgICAgICAgICAgLSBkcm9wcyB0aGUgVENQIGNvbm5lY3Rp b24sIGFuZA0KICAgICAgICAgICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRvIElkbGUuDQoNCg0KICAg ICAgIEluIHJlc3BvbnNlIHRvIGFueSBvdGhlciBldmVudCBbRXZlbnRzIDksIDExLTEzLDIwLDI1 LTI4XSwNCiAgICAgICB0aGUgbG9jYWwgc3lzdGVtOg0KICAgICAgICAgICAtIHNlbmRzIHRoZSBO T1RJRklDQVRJT04gd2l0aCB0aGUgRXJyb3IgQ29kZSBGaW5pdGUNCiAgICAgICAgICAgICBzdGF0 ZSBtYWNoaW5lIGVycm9yLA0KICAgICAgICAgICAtIHNldHMgdGhlIENvbm5lY3RSZXRyeVRpbWVy IHRvIHplcm8sDQogICAgICAgICAgIC0gcmVsZWFzZXMgYWxsIEJHUCByZXNvdXJjZXMsDQogICAg ICAgICAgIC0gZHJvcHMgdGhlIFRDUCBjb25uZWN0aW9uLA0KICAgICAgICAgICAtIGluY3JlbWVu dHMgdGhlIENvbm5lY3RSZXRyeUNvdW50IGJ5IDEsDQogICAgICAgICAgIC0gW29wdGlvbmFsbHld IHBlcmZvcm1zIHBlZXIgb3NjaWxsYXRpb24gZGFtcGluZyBpZiB0aGUNCgkgICAgIERhbXBQZWVy T3NjaWxsYXRpb24gYXR0cmlidXRlIGlzIHNldCB0byBUUlVFLCBhbmQNCiAgICAgICAgICAgLSBj aGFuZ2VzIGl0cyBzdGF0ZSB0byBJZGxlLg0KDQoNCg0KICAgICAgT3BlbkNvbmZpcm0gU3RhdGU6 DQoNCiAgICAgICBJbiB0aGlzIHN0YXRlIEJHUCB3YWl0cyBmb3IgYSBLRUVQQUxJVkUgb3IgTk9U SUZJQ0FUSU9ODQoNCg0KDQpFeHBpcmF0aW9uIERhdGUgU2VwdGVtYmVyIDIwMDMgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAMW1BhZ2UgNTZdDQoNCg0KDQoNCg0KUkZDIERSQUZUICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAy MDAzDQoNCg0KICAgICAgIG1lc3NhZ2UuDQoNCg0KICAgICAgIEFueSBzdGFydCBldmVudCBbRXZl bnQxLCAzLTddIGlzIGlnbm9yZWQgaW4gdGhlIE9wZW5Db25maXJtDQogICAgICAgc3RhdGUuDQoN Cg0KICAgICAgIEluIHJlc3BvbnNlIHRvIGEgTWFudWFsU3RvcCBldmVudCBbRXZlbnQgMl0gaW5p dGlhdGVkIGJ5DQogICAgICAgdGhlIG9wZXJhdG9yLCB0aGUgbG9jYWwgc3lzdGVtOg0KICAgICAg ICAgICAtIHNlbmRzIHRoZSBOT1RJRklDQVRJT04gbWVzc2FnZSB3aXRoIENlYXNlLA0KICAgICAg ICAgICAtIHJlbGVhc2VzIGFsbCBCR1AgcmVzb3VyY2VzLA0KICAgICAgICAgICAtIGRyb3BzIHRo ZSBUQ1AgY29ubmVjdGlvbiwNCiAgICAgICAgICAgLSBzZXRzIHRoZSBDb25uZWN0UmV0cnlDb3Vu dCB0byB6ZXJvLA0KICAgICAgICAgICAtIHNldHMgdGhlIENvbm5lY3RSZXRyeVRpbWVyIHRvIHpl cm8sIGFuZA0KICAgICAgICAgICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRvIElkbGUuDQoNCiAgICAg ICBJbiByZXNwb25zZSB0byB0aGUgQXV0b21hdGljU3RvcCBldmVudCBpbml0aWF0ZWQgYnkgdGhl DQogICAgICAgc3lzdGVtIFtFdmVudCA4XSwgdGhlIGxvY2FsIHN5c3RlbToNCiAgICAgICAgICAg LSBzZW5kcyB0aGUgTk9USUZJQ0FUSU9OIG1lc3NhZ2Ugd2l0aCBDZWFzZSwNCiAgICAgICAgICAg LSBzZXRzIHRoZSBDb25uZWN0UmV0cnlUaW1lciB0byB6ZXJvLA0KICAgICAgICAgICAtIHJlbGVh c2VzIGFsbCBCR1AgcmVzb3VyY2VzLA0KICAgICAgICAgICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVj dGlvbiwNCiAgICAgICAgICAgLSBpbmNyZW1lbnRzIHRoZSBDb25uZWN0UmV0cnlDb3VudCBieSAx LCANCiAgICAgICAgICAgLSBbb3B0aW9uYWxseV0gcGVyZm9ybXMgcGVlciBvc2NpbGxhdGlvbiBk YW1waW5nDQoJICAgICBpZiB0aGUgRGFtcFBlZXJPc2NpbGxhdGlvbiBhdHRyaWJ1dGUgaXMgc2V0 IHRvIFRSVUUsDQoJICAgICBhbmQNCiAgICAgICAgICAgLSBjaGFuZ2VzIGl0cyBzdGF0ZSB0byBJ ZGxlLg0KDQogICAgICAgSWYgdGhlIEhvbGRUaW1lX0V4cGlyZXMgZXZlbnQgW0V2ZW50IDEwXSBv Y2N1cnMgYmVmb3JlIGEgS0VFUEFMSVZFDQogICAgICAgbWVzc2FnZSBpcyByZWNlaXZlZCwgdGhl IGxvY2FsIHN5c3RlbToNCiAgICAgICAgICAgLSBzZW5kcyB0aGUgTk9USUZJQ0FUSU9OIG1lc3Nh Z2Ugd2l0aCB0aGUgZXJyb3IgY29kZSwNCiAgICAgICAgICAgLSBzZXRzIHRoZSBDb25uZWN0UmV0 cnlUaW1lciB0byB6ZXJvLA0KICAgICAgICAgICAtIHJlbGVhc2VzIGFsbCBCR1AgcmVzb3VyY2Vz LA0KICAgICAgICAgICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVjdGlvbiwNCiAgICAgICAgICAgLSBp bmNyZW1lbnRzIHRoZSBDb25uZWN0UmV0cnlDb3VudCBieSAxLA0KICAgICAgICAgICAtIFtvcHRp b25hbGx5XSBwZXJmb3JtcyBwZWVyIG9zY2lsbGF0aW9uIGRhbXBpbmcgaWYNCgkgICAgIHRoZSBE YW1wUGVlck9zY2lsbGF0aW9uIGF0dHJpYnV0ZSBpcyBzZXQgdG8gVFJVRSwgYW5kDQogICAgICAg ICAgIC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8gSWRsZS4NCg0KDQogICAgICAgSWYgdGhlIGxvY2Fs IHN5c3RlbSByZWNlaXZlcyBhIEtFRVBBTElWRVRpbWVyX0V4cGlyZXMNCiAgICAgICBldmVudCBb RXZlbnQgMTFdLCB0aGUgc3lzdGVtOg0KICAgICAgICAgICAtIHNlbmRzIGEgS0VFUEFMSVZFIG1l c3NhZ2UsDQogICAgICAgICAgIC0gcmVzdGFydHMgdGhlIEtlZXBhbGl2ZSB0aW1lciwgYW5kDQog ICAgICAgICAgIC0gcmVtYWlucyBpbiBPcGVuQ29uZmlybWVkIHN0YXRlLg0KDQogICAgICAgSW4g dGhlIGV2ZW50IG9mIFRDUENvbm5lY3Rpb25fdmFsaWQgZXZlbnQgW0V2ZW50IDE0XSwgb3IgVENQ DQogICAgICAgY29ubmVjdGlvbiBzdWNjZWVkaW5nIFtFdmVudCAxNiBvciBFdmVudCAxN10gd2hp bGUgaW4gT3BlbkNvbmZpcm0sDQogICAgICAgdGhlIGxvY2FsIHN5c3RlbSBuZWVkcyB0byB0cmFj ayB0aGUgc2Vjb25kIGNvbm5lY3Rpb24uDQoNCg0KDQpFeHBpcmF0aW9uIERhdGUgU2VwdGVtYmVy IDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAMW1BhZ2UgNTddDQoNCg0KDQoN Cg0KDQpSRkMgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE1hcmNoIDIwMDMNCg0KDQogICAgICAgSWYgYSBUQ1AgY29ubmVjdGlvbiBpcyBh dHRlbXB0ZWQgdG8gYW4gaW52YWxpZCBwb3J0IFtFdmVudA0KICAgICAgIDE1XSwgdGhlIGxvY2Fs IHN5c3RlbSB3aWxsIGlnbm9yZSB0aGUgc2Vjb25kIGNvbm5lY3Rpb24NCiAgICAgICBhdHRlbXB0 Lg0KDQoNCiAgICAgICBJZiB0aGUgbG9jYWwgc3lzdGVtIHJlY2VpdmVzIGEgVENQQ29ubmVjdGlv bkZhaWxzIGV2ZW50DQogICAgICAgW0V2ZW50IDE4XSBmcm9tIHRoZSAgdW5kZXJseWluZyBUQ1Ag b3IgYSBOT1RJRklDQVRJT04NCiAgICAgICBtZXNzYWdlIFtFdmVudCAyNV0sIHRoZSBsb2NhbCBz eXN0ZW06DQogICAgICAgICAgIC0gc2V0cyB0aGUgQ29ubmVjdFJldHJ5VGltZXIgdG8gemVybywN CiAgICAgICAgICAgLSByZWxlYXNlcyBhbGwgQkdQIHJlc291cmNlcywNCiAgICAgICAgICAgLSBk cm9wcyB0aGUgVENQIGNvbm5lY3Rpb24sDQogICAgICAgICAgIC0gaW5jcmVtZW50cyB0aGUgQ29u bmVjdFJldHJ5Q291bnQgYnkgMQ0KICAgICAgICAgICAtIFtvcHRpb25hbGx5XSBwZXJmb3JtcyBw ZWVyIG9zY2lsbGF0aW9uIGRhbXBpbmcgaWYgdGhlDQoJICAgICBEYW1wUGVlck9zY2lsbGF0aW9u IGF0dHJpYnV0ZSBpcyBzZXQgdG8gVFJVRSwgYW5kDQogICAgICAgICAgIC0gY2hhbmdlcyBpdHMg c3RhdGUgdG8gSWRsZS4NCg0KICAgICAgIElmIHRoZSBsb2NhbCBzeXN0ZW0gcmVjZWl2ZXMgYSBO T1RJRklDQVRJT04gbWVzc2FnZSB3aXRoIGENCiAgICAgICB2ZXJzaW9uIGVycm9yIChOb3RpZk1z Z1ZlckVyciBbRXZlbnQgMjRdKSwgdGhlIGxvY2FsIHN5c3RlbToNCiAgICAgICAgICAgLSBzZXRz IHRoZSBDb25uZWN0UmV0cnlUaW1lciB0byB6ZXJvLA0KICAgICAgICAgICAtIHJlbGVhc2VzIGFs bCBCR1AgcmVzb3VyY2VzLA0KICAgICAgICAgICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVjdGlvbiwg YW5kDQogICAgICAgICAgIC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8gSWRsZS4NCg0KDQogICAgICAg SWYgdGhlIGxvY2FsIHN5c3RlbSByZWNlaXZlcyBhIHZhbGlkIE9QRU4gbWVzc2FnZSANCiAgICAg IChCR1BPcGVuIFtFdmVudCAxOV0pLCB0aGUgY29sbGlzaW9uIGRldGVjdCBmdW5jdGlvbiBpcw0K ICAgICAgcHJvY2Vzc2VkIHBlciBTZWN0aW9uIDYuOC4gSWYgdGhpcyBjb25uZWN0aW9uIGlzIHRv IGJlDQogICAgICBkcm9wcGVkIGR1ZSB0byBjb25uZWN0aW9uIGNvbGxpc2lvbiwgdGhlIGxvY2Fs IHN5c3RlbToNCiAgICAgICAgICAgLSBzZW5kcyBhIE5PVElGSUNBVElPTiB3aXRoIGEgQ2Vhc2Us DQogICAgICAgICAgIC0gc2V0cyB0aGUgQ29ubmVjdFJldHJ5VGltZXIgdG8gemVybywNCiAgICAg ICAgICAgLSByZWxlYXNlcyBhbGwgQkdQIHJlc291cmNlcywNCiAgICAgICAgICAgLSBkcm9wcyB0 aGUgVENQIGNvbm5lY3Rpb24gKHNlbmQgVENQIEZJTiksDQogICAgICAgICAgIC0gaW5jcmVtZW50 cyB0aGUgQ29ubmVjdFJldHJ5Q291bnQgYnkgMSwNCiAgICAgICAgICAgLSBbb3B0aW9uYWxseV0g cGVyZm9ybXMgcGVlciBvc2NpbGxhdGlvbiBkYW1waW5nIGlmIHRoZQ0KICAgICAgICAgICAgIERh bXBQZWVyT3NjaWxsYXRpb24gYXR0cmlidXRlIGlzIHNldCB0byBUUlVFLCBhbmQNCiAgICAgICAg ICAgLSBjaGFuZ2VzIGl0cyBzdGF0ZSB0byBJZGxlLg0KDQoNCg0KICAgICAgIElmIGFuIE9QRU4g bWVzc2FnZSBpcyByZWNlaXZlZCwgYWxsIGZpZWxkcyBhcmUgY2hlY2tlZCBmb3INCiAgICAgICBj b3JyZWN0bmVzcy4gIElmIHRoZSBCR1AgbWVzc2FnZSBoZWFkZXIgY2hlY2tpbmcNCiAgICAgICAo QkdQSGVhZGVyRXJyIFtFdmVudDIxXSkgb3IgT1BFTiBtZXNzYWdlIGNoZWNrIGRldGVjdHMgDQog ICAgICAgYW4gZXJyb3IgKHNlZSBTZWN0aW9uIDYuMikgKEJHUE9wZW5Nc2dFcnJbRXZlbnQyMl0p LCB0aGUNCiAgICAgICBsb2NhbCBzeXN0ZW06DQogICAgICAgICAgIC0gc2VuZHMgYSBOT1RJRklD QVRJT04gbWVzc2FnZSB3aXRoIGFwcHJvcHJpYXRlIGVycm9yDQogICAgICAgICAgICAgY29kZSwN CiAgICAgICAgICAgLSBzZXRzIHRoZSBDb25uZWN0UmV0cnlUaW1lciB0byB6ZXJvLA0KICAgICAg ICAgICAtIHJlbGVhc2VzIGFsbCBCR1AgcmVzb3VyY2VzLA0KICAgICAgICAgICAtIGRyb3BzIHRo ZSBUQ1AgY29ubmVjdGlvbiwNCiAgICAgICAgICAgLSBpbmNyZW1lbnRzIHRoZSBDb25uZWN0UmV0 cnlDb3VudCBieSAxLA0KDQoNCg0KRXhwaXJhdGlvbiBEYXRlIFNlcHRlbWJlciAyMDAzICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDFtQYWdlIDU4XQ0KDQoNCg0KDQoNClJGQyBEUkFG VCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFy Y2ggMjAwMw0KDQoNCiAgICAgICAgICAgLSBbb3B0aW9uYWxseV0gcGVyZm9ybXMgcGVlciBvc2Np bGxhdGlvbiBkYW1waW5nIGlmIHRoZQ0KCSAgICAgRGFtcFBlZXJPc2NpbGxhdGlvbiBhdHRyaWJ1 dGUgaXMgc2V0IHRvIFRSVUUsIGFuZA0KICAgICAgICAgICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRv IElkbGUuDQoNCg0KICAgICAgIElmIGR1cmluZyB0aGUgcHJvY2Vzc2luZyBvZiBhbm90aGVyIE9Q RU4gbWVzc2FnZSwgdGhlIEJHUA0KICAgICAgIGltcGxlbWVudGF0aW9uIGRldGVybWluZXMgYnkg YSBtZWFucyBvdXRzaWRlIHRoZSBzY29wZSBvZg0KICAgICAgIHRoaXMgZG9jdW1lbnQgdGhhdCBh IGNvbm5lY3Rpb24gY29sbGlzaW9uIGhhcyBvY2N1cnJlZCBhbmQNCiAgICAgICB0aGlzIGNvbm5l Y3Rpb24gaXMgdG8gYmUgY2xvc2VkLCB0aGUgbG9jYWwgc3lzdGVtIHdpbGwNCiAgICAgICBpc3N1 ZSBhIE9wZW5Db2xsaXNpb25EdW1wIGV2ZW50IFtFdmVudCAyM10uICBXaGVuIHRoZSBsb2NhbA0K ICAgICAgIHN5c3RlbSByZWNlaXZlcyBhbiBPcGVuQ29sbGlzaW9uRHVtcCBldmVudCBbRXZlbnQg MjNdLCB0aGUNCiAgICAgICBsb2NhbCBzeXN0ZW06DQogICAgICAgICAgIC0gc2VuZHMgYSBOT1RJ RklDQVRJT04gd2l0aCBhIENlYXNlDQogICAgICAgICAgIC0gc2V0cyB0aGUgQ29ubmVjdFJldHJ5 VGltZXIgdG8gemVybywNCiAgICAgICAgICAgLSByZWxlYXNlcyBhbGwgQkdQIHJlc291cmNlcw0K ICAgICAgICAgICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVjdGlvbiwNCiAgICAgICAgICAgLSBpbmNy ZW1lbnRzIHRoZSBDb25uZWN0UmV0cnlDb3VudCBieSAxLA0KICAgICAgICAgICAtIFtvcHRpb25h bGx5XSBwZXJmb3JtcyBwZWVyIG9zY2lsbGF0aW9uIGRhbXBpbmcgaWYgdGhlDQoJICAgICBEYW1w UGVlck9zY2lsbGF0aW9uIGF0dHJpYnV0ZSBpcyBzZXQgdG8gVFJVRSwgYW5kDQogICAgICAgICAg IC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8gSWRsZS4NCg0KDQogICAgICAgSWYgdGhlIGxvY2FsIHN5 c3RlbSByZWNlaXZlcyBhIEtFRVBBTElWRSBtZXNzYWdlIA0KCShLZWVwQWxpdmVNc2cgW0V2ZW50 IDI2XSksIHRoZSBsb2NhbCBzeXN0ZW06IA0KICAgICAgICAgICAtIHJlc3RhcnRzIHRoZSBIb2xk VGltZXIgYW5kDQogICAgICAgICAgIC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8gRXN0YWJsaXNoZWQu DQoNCiAgICAgICBJbiByZXNwb25zZSB0byBhbnkgb3RoZXIgZXZlbnQgW0V2ZW50cyA5LCAxMi0x MywgMjAsIDI3LTI4XSwNCiAgICAgICB0aGUgbG9jYWwgc3lzdGVtOg0KICAgICAgICAgICAtIHNl bmRzIGEgTk9USUZJQ0FUSU9OIHdpdGggYSBjb2RlIG9mIEZpbml0ZSBTdGF0ZQ0KICAgICAgICAg ICAgIE1hY2hpbmUgRXJyb3IsDQogICAgICAgICAgIC0gc2V0cyB0aGUgQ29ubmVjdFJldHJ5VGlt ZXIgdG8gemVybywNCiAgICAgICAgICAgLSByZWxlYXNlcyBhbGwgQkdQIHJlc291cmNlcywNCiAg ICAgICAgICAgLSBkcm9wcyB0aGUgVENQIGNvbm5lY3Rpb24sDQogICAgICAgICAgIC0gaW5jcmVt ZW50cyB0aGUgQ29ubmVjdFJldHJ5Q291bnQgYnkgMSwNCiAgICAgICAgICAgLSBbb3B0aW9uYWxs eV0gcGVyZm9ybXMgcGVlciBvc2NpbGxhdGlvbiBkYW1waW5nIGlmIHRoZQ0KCSAgICAgRGFtcFBl ZXJPc2NpbGxhdGlvbiBhdHRyaWJ1dGUgaXMgc2V0IHRvIFRSVUUsIGFuZA0KICAgICAgICAgICAt IGNoYW5nZXMgaXRzIHN0YXRlIHRvIElkbGUuDQoNCg0KICAgICAgRXN0YWJsaXNoZWQgU3RhdGU6 DQoNCiAgICAgICBJbiB0aGUgRXN0YWJsaXNoZWQgc3RhdGUsIHRoZSBCR1AgRlNNIGNhbiBleGNo YW5nZSBVUERBVEUsDQogICAgICAgTk9URklDQVRJT04sIGFuZCBLRUVQQUxJVkUgbWVzc2FnZXMg d2l0aCBpdHMgcGVlci4NCg0KDQogICAgICAgQW55IFN0YXJ0IGV2ZW50IChFdmVudCAxLCAzLTcp IGlzIGlnbm9yZWQgaW4gdGhlDQogICAgICAgRXN0YWJsaXNoZWQgc3RhdGUuDQoNCiAgICAgICBJ biByZXNwb25zZSB0byBhIE1hbnVhbFN0b3AgZXZlbnQgKGluaXRpYXRlZCBieSBhbg0KICAgICAg IG9wZXJhdG9yKVtFdmVudDJdLCB0aGUgbG9jYWwgc3l0ZW06DQogICAgICAgICAgIC0gc2VuZHMg dGhlIE5PVElGSUNBVElPTiBtZXNzYWdlIHdpdGggQ2Vhc2UsDQoNCg0KDQpFeHBpcmF0aW9uIERh dGUgU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAMW1BhZ2Ug NTldDQoNCg0KDQoNCg0KUkZDIERSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDAzDQoNCg0KICAgICAgICAgICAtIHNldHMgdGhl IENvbm5lY3RSZXRyeVRpbWVyIHRvIHplcm8sDQogICAgICAgICAgIC0gZGVsZXRlcyBhbGwgcm91 dGVzIGFzc29jaWF0ZWQgd2l0aCB0aGlzIGNvbm5lY3Rpb24sDQogICAgICAgICAgIC0gcmVsZWFz ZXMgQkdQIHJlc291cmNlcywNCiAgICAgICAgICAgLSBkcm9wcyB0aGUgVENQIGNvbm5lY3Rpb24s DQogICAgICAgICAgIC0gc2V0cyBDb25uZWN0UmV0cnlDb3VudCB0byB6ZXJvLCBhbmQgDQogICAg ICAgICAgIC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8gSWRsZS4NCg0KICAgICAgIEluIHJlc3BvbnNl IHRvIGFuIEF1dG9tYXRpY1N0b3AgZXZlbnQgW0V2ZW50OF0sIHRoZSBsb2NhbCBzeXN0ZW06DQog ICAgICAgICAgIC0gc2VuZHMgYSBOT1RJRklDQVRJT04gd2l0aCBDZWFzZSwNCiAgICAgICAgICAg LSBzZXRzIHRoZSBDb25uZWN0UmV0cnlUaW1lciB0byB6ZXJvDQogICAgICAgICAgIC0gZGVsZXRl cyBhbGwgcm91dGVzIGFzc29jaWF0ZWQgd2l0aCB0aGlzIGNvbm5lY3Rpb24sDQogICAgICAgICAg IC0gcmVsZWFzZXMgYWxsIEJHUCByZXNvdXJjZXMsDQogICAgICAgICAgIC0gZHJvcHMgdGhlIFRD UCBjb25uZWN0aW9uLA0KICAgICAgICAgICAtIGluY3JlbWVudHMgdGhlIENvbm5lY3RSZXRyeUNv dW50IGJ5IDEsIA0KICAgICAgICAgICAtIFtvcHRpb25hbGx5XSBwZXJmb3JtcyBwZWVyIG9zY2ls bGF0aW9uIGRhbXBpbmcgaWYgdGhlDQoJICAgICBEYW1wUGVlck9zY2lsbGF0aW9uIGF0dHJpYnV0 ZSBpcyBzZXQgdG8gVFJVRSwgYW5kDQogICAgICAgICAgIC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8g SWRsZS4NCg0KICAgICAgIE9uZSByZWFzb24gZm9yIGFuIEF1dG9tYXRpY1N0b3AgZXZlbnQgaXM6 IEEgQkdQIHJlY2VpdmVzDQogICAgICAgVVBEQVRFIG1lc3NhZ2VzIHdpdGggbnVtYmVyIG9mIHBy ZWZpeGVzIGZvciBhIGdpdmVuDQogICAgICAgcGVlciB0aGF0IGV4Y2VlZCB0aGUgbWF4aW11bSBu dW1iZXIgb2YgcHJlZml4ZXMgY29uZmlndXJlZC4NCiAgICAgICBUaGUgbG9jYWwgc3lzdGVtIGF1 dG9tYXRpY2FsbHkgZGlzY29ubmVjdHMgdGhlIHBlZXIuDQoNCg0KICAgICAgIElmIHRoZSBIb2xk VGltZXJfRXhwaXJlcyBldmVudCBvY2N1cnMgW0V2ZW50MTBdLCB0aGUgDQogICAgICAgbG9jYWwg c3lzdGVtOg0KICAgICAgICAgICAtIHNlbmRzIGEgTk9USUZJQ0FUSU9OIG1lc3NhZ2Ugd2l0aCBF cnJvciBDb2RlIEhvbGQNCiAgICAgICAgICAgICBUaW1lciBFeHBpcmVkLA0KICAgICAgICAgICAt IHNldHMgdGhlIENvbm5lY3RSZXRyeVRpbWVyIHRvIHplcm8sDQogICAgICAgICAgIC0gcmVsZWFz ZXMgYWxsIEJHUCByZXNvdXJjZXMsDQogICAgICAgICAgIC0gZHJvcHMgdGhlIFRDUCBjb25uZWN0 aW9uLA0KICAgICAgICAgICAtIGluY3JlbWVudHMgdGhlIENvbm5lY3RSZXRyeUNvdW50IGJ5IDEs IA0KICAgICAgICAgICAtIFtvcHRpb25hbGx5XSBwZXJmb3JtcyBwZWVyIG9zY2lsbGF0aW9uIGRh bXBpbmcgaWYgdGhlDQoJICAgICBEYW1wUGVlck9zY2lsbGF0aW9ucyBhdHRyaWJ1dGUgaXMgc2V0 IHRvIFRSVUUsIGFuZA0KICAgICAgICAgICAtIGNoYW5nZXMgaXRzIHN0YXRlIHRvIElkbGUuDQoN CiAgICAgICBJZiB0aGUgS2VlcEFsaXZlVGltZXJfRXhwaXJlcyBldmVudCBvY2N1cnMgW0V2ZW50 MTFdLA0KICAgICAgIHRoZSBsb2NhbCBzeXN0ZW06DQogICAgICAgICAgIC0gc2VuZHMgYSBLRUVQ QUxJVkUgbWVzc2FnZSwgYW5kIA0KCSAgIC0gcmVzdGFydHMgaXRzIEtlZXBBbGl2ZVRpbWVyIHVu bGVzcyB0aGUgbmVnb3RpYXRlZA0KICAgICAgICAgICAgIEhvbGRUaW1lIHZhbHVlIGlzIHplcm8u DQoNCiAgICAgICBFYWNoIHRpbWUgdGhlIGxvY2FsIHN5c3RlbSBzZW5kcyBhIEtFRVBBTElWRSBv ciBVUERBVEUNCiAgICAgICBtZXNzYWdlLCBpdCByZXN0YXJ0cyBpdHMgS2VlcEFsaXZlVGltZXIs IHVubGVzcyB0aGUNCiAgICAgICBuZWdvdGlhdGVkIEhvbGRUaW1lIHZhbHVlIGlzIHplcm8uDQoN Cg0KICAgICAgIEEgVENQQ29ubmVjdGlvbl92YWxpZCAgW0V2ZW50IDE0XSByZWNlaXZlZA0KICAg ICAgIGZvciBhIHZhbGlkIHBvcnQgd2lsbCBjYXVzZSB0aGUgc2Vjb25kIGNvbm5lY3Rpb24gdG8g YmUNCiAgICAgICB0cmFja2VkLg0KDQoNCg0KRXhwaXJhdGlvbiBEYXRlIFNlcHRlbWJlciAyMDAz ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDFtQYWdlIDYwXQ0KDQoNCg0KDQoNClJG QyBEUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgTWFyY2ggMjAwMw0KDQoNCiAgICAgICBBbiBpbnZhbGlkIFRDUCBjb25uZWN0aW9uIChUQ1Bf Q1JfSW52YWxpZCBFdmVudA0KICAgICAgIFtFdmVudCAxNV0pLCB3aWxsIGJlIGlnbm9yZWQuDQoN CiAgICAgICBJbiByZXNwb25zZSB0byBhbiBpbmRpY2F0aW9uIHRoYXQgdGhlIFRDUCBjb25uZWN0 aW9uDQogICAgICAgaXMgc3VjY2Vzc2Z1bGx5IGVzdGFibGlzaGVkIFtFdmVudCAxNg0KICAgICAg IG9yIEV2ZW50IDE3XSwgdGhlIHNlY29uZCBjb25uZWN0aW9uIFNIQUxMIGJlIHRyYWNrZWQgdW50 aWwNCiAgICAgICBpdCBzZW5kcyBhbiBPUEVOIG1lc3NhZ2UuDQoNCiAgICAgICBJZiBhIHZhbGlk IE9QRU4gbWVzc2FnZSAoQkdQT3BlbiBbRXZlbnQgMTldKSBpcyByZWNlaXZlZCwNCiAgICAgICBp dCB3aWxsIGJlIGNoZWNrZWQgdG8gc2VlIGlmIGl0IGNvbGxpZGVzIChTZWN0aW9uIDYuOCkNCiAg ICAgICB3aXRoIGFueSBvdGhlciBzZXNzaW9uLiBJZiB0aGUgQkdQIGltcGxlbWVudGF0aW9uIGRl dGVybWluZXMNCiAgICAgICB0aGF0IHRoaXMgY29ubmVjdGlvbiBuZWVkcyB0byBiZSB0ZXJtaW5h dGVkLCBpdCB3aWxsIHByb2Nlc3MNCiAgICAgICBhbiBPcGVuQ29sbGlzaW9uRHVtcCBldmVudFtF dmVudCAyM10uICBJZiB0aGlzIHNlc3Npb24gbmVlZHMgdG8gYmUNCiAgICAgICB0ZXJtaW5hdGVk LCB0aGUgbG9jYWwgc3lzdGVtOiANCiAgICAgICAgICAgLSBzZW5kcyBhIE5PVElGSUNBVElPTiB3 aXRoIGEgQ2Vhc2UsDQogICAgICAgICAgIC0gc2V0cyB0aGUgQ29ubmVjdFJldHJ5VGltZXIgdG8g emVybywNCiAgICAgICAgICAgLSBkZWxldGVzIGFsbCByb3V0ZXMgYXNzb2NpYXRlZCB3aXRoIHRo aXMgY29ubmVjdGlvbiwNCiAgICAgICAgICAgLSByZWxlYXNlcyBhbGwgQkdQIHJlc291cmNlcywN CiAgICAgICAgICAgLSBkcm9wcyB0aGUgVENQIGNvbm5lY3Rpb24sDQogICAgICAgICAgIC0gaW5j cmVtZW50cyBDb25uZWN0UmV0cnlDb3VudCBieSAxLCANCiAgICAgICAgICAgLSBvcHRpb25hbGx5 IHBlcmZvcm1zIHBlZXIgb3NjaWxsYXRpb24gZGFtcGluZyBpZiB0aGUNCgkgICAgIERhbXBQZWVy T3NjaWxsYXRpb24gaXMgc2V0IHRvIFRSVUUsIGFuZA0KICAgICAgICAgICAtIGNoYW5nZXMgaXRz IHN0YXRlIHRvIElkbGUuDQoNCg0KICAgICAgIElmIHRoZSBsb2NhbCBzeXN0ZW0gcmVjZWl2ZXMg YSBOT1RJRklDQVRJT04gbWVzc2FnZQ0KICAgICAgIFtFdmVudDI0IG9yIEV2ZW50IDI1XSBvciBh IFRDUENvbm5lY3Rpb25zRmFpbHMgW0V2ZW50MThdDQogICAgICAgZnJvbSB0aGUgdW5kZXJseWlu ZyBUQ1AsIGl0Og0KICAgICAgICAgICAtIHNldHMgdGhlIENvbm5lY3RSZXRyeVRpbWVyIHRvIHpl cm8sDQogICAgICAgICAgIC0gZGVsZXRlcyBhbGwgcm91dGVzIGFzc29jaWF0ZWQgd2l0aCB0aGlz IGNvbm5lY3Rpb24sDQogICAgICAgICAgIC0gcmVsZWFzZXMgYWxsIHRoZSBCR1AgcmVzb3VyY2Vz LA0KICAgICAgICAgICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVjdGlvbiwNCiAgICAgICAgICAgLSBp bmNyZW1lbnRzIHRoZSBDb25uZWN0UmV0cnlDb3VudCBieSAxLCANCiAgICAgICAgICAgLSBjaGFu Z2VzIGl0cyBzdGF0ZSB0byBJZGxlLg0KDQoNCiAgICAgICBJZiB0aGUgbG9jYWwgc3lzdGVtIHJl Y2VpdmVzIGEgS0VFUEFMSVZFIG1lc3NhZ2UNCiAgICAgICBbRXZlbnQgMjZdLCB0aGUgbG9jYWwg c3lzdGVtOg0KICAgICAgICAgICAtIHJlc3RhcnRzIGl0cyBIb2xkVGltZXIsIGlmIHRoZSBuZWdv dGlhdGVkIEhvbGQgVGltZQ0KICAgICAgICAgICAgIHZhbHVlIGlzIG5vbi16ZXJvLCBhbmQNCiAg ICAgICAgICAgLSByZW1haW5zIGluIHRoZSBFc3RhYmxpc2hlZCBzdGF0ZS4NCg0KDQogICAgICAg SWYgdGhlIGxvY2FsIHN5c3RlbSByZWNlaXZlcyBhbiBVUERBVEUgbWVzc2FnZSBbRXZlbnQyN10s DQogICAgICAgdGhlIGxvY2FsIHN5c3RlbToNCiAgICAgICAgICAgLSBwcm9jZXNzZXMgdGhlIHVw ZGF0ZSBwYWNrZXQsDQogICAgICAgICAgIC0gcmVzdGFydHMgaXRzIEhvbGRUaW1lciBpZiB0aGUg bmVnb3RpYXRlZCBIb2xkIFRpbWUNCg0KDQoNCkV4cGlyYXRpb24gRGF0ZSBTZXB0ZW1iZXIgMjAw MyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAxbUGFnZSA2MV0NCg0KDQoNCg0KDQpS RkMgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE1hcmNoIDIwMDMNCg0KDQogICAgICAgICAgICAgdmFsdWUgaXMgbm9uLXplcm8sIGFuZA0K ICAgICAgICAgICAtIHJlbWFpbnMgaW4gdGhlIEVzdGFibGlzaGVkIHN0YXRlLg0KDQoNCiAgICAg ICBJZiB0aGUgbG9jYWwgc3lzdGVtIHJlY2VpdmVzIGFuIFVQREFURSBtZXNzYWdlLCBhbmQgdGhl DQogICAgICAgVVBEQVRFIG1lc3NhZ2UgZXJyb3IgaGFuZGxpbmcgcHJvY2VkdXJlIChzZWUgU2Vj dGlvbiA2LjMpDQogICAgICAgZGV0ZWN0cyBhbiBlcnJvciBbRXZlbnQyOF0sIHRoZSBsb2NhbCBz eXN0ZW06DQogICAgICAgICAgIC0gc2VuZHMgYSBOT1RJRklDQVRJT04gbWVzc2FnZSB3aXRoIFVw ZGF0ZSBlcnJvciwNCiAgICAgICAgICAgLSBzZXRzIHRoZSBDb25uZWN0IFJldHJ5IHRpbWVyIHRv IHplcm8sDQogICAgICAgICAgIC0gZGVsZXRlcyBhbGwgcm91dGVzIGFzc29jaWF0ZWQgd2l0aCB0 aGlzIGNvbm5lY3Rpb24sDQogICAgICAgICAgIC0gcmVsZWFzZXMgYWxsIEJHUCByZXNvdXJjZXMs DQogICAgICAgICAgIC0gZHJvcHMgdGhlIFRDUCBjb25uZWN0aW9uLA0KICAgICAgICAgICAtIGlu Y3JlbWVudHMgdGhlIENvbm5lY3RSZXRyeUNvdW50IGJ5IDEsIA0KICAgICAgICAgICAtIFtvcHRp b25hbGx5XSBwZXJmb3JtcyBwZWVyIG9zY2lsbGF0aW9uIGRhbXBpbmcgaWYgdGhlDQoJICAgICBE YW1wUGVlck9zY2lsbGF0aW9uIGF0dHJpYnV0ZSBpcyBzZXQgdG8gVFJVRSwgYW5kDQogICAgICAg ICAgIC0gY2hhbmdlcyBpdHMgc3RhdGUgdG8gSWRsZS4NCg0KDQogICAgICAgSW4gcmVzcG9uc2Ug dG8gYW55IG90aGVyIGV2ZW50IFtFdmVudHMgOSwgMTItMTMsIDIwLTIyXSB0aGUNCiAgICAgICBs b2NhbCBzeXN0ZW06DQogICAgICAgICAgIC0gc2VuZHMgYSBOT1RJRklDQVRJT04gbWVzc2FnZSB3 aXRoIEVycm9yIENvZGUgRmluaXRlDQogICAgICAgICAgICAgU3RhdGUgTWFjaGluZSBFcnJvciwN CiAgICAgICAgICAgLSBkZWxldGVzIGFsbCByb3V0ZXMgYXNzb2NpYXRlZCB3aXRoIHRoaXMgY29u bmVjdGlvbiwNCiAgICAgICAgICAgLSBzZXRzIHRoZSBDb25uZWN0IFJldHJ5IHRpbWVyIHRvIHpl cm8sIA0KICAgICAgICAgICAtIHJlbGVhc2VzIGFsbCBCR1AgcmVzb3VyY2VzLA0KICAgICAgICAg ICAtIGRyb3BzIHRoZSBUQ1AgY29ubmVjdGlvbiwNCiAgICAgICAgICAgLSBpbmNyZW1lbnRzIHRo ZSBDb25uZWN0UmV0cnlDb3VudCBieSAxLA0KICAgICAgICAgICAtIFtvcHRpb25hbGx5XSBwZXJm b3JtcyBwZWVyIG9zY2lsbGF0aW9uIGRhbXBpbmcgaWYgdGhlDQoJICAgICBEYW1wUGVlck9zY2ls bGF0aW9uIGF0dHJpYnV0ZSBpcyBzZXQgdG8gVFJVRSwgYW5kDQogICAgICAgICAgIC0gY2hhbmdl cyBpdHMgc3RhdGUgdG8gSWRsZS4NCg0KDQoxMCBCR1AgVGltZXJzDQoNCg0KICAgQkdQIGVtcGxv eXMgZml2ZSB0aW1lcnM6IENvbm5lY3RSZXRyeSAoc2VlIFNlY3Rpb24gOCksIEhvbGRUaW1lciAo c2VlDQogICBTZWN0aW9uIDQuMiksIEtlZXBBbGl2ZSAoc2VlIFNlY3Rpb24gOCksIE1pbkFTT3Jp Z2luYXRpb25JbnRlcnZhbA0KICAgKHNlZSBTZWN0aW9uIDkuMi4xLjIpLCBhbmQgTWluUm91dGVB ZHZlcnRpc2VtZW50SW50ZXJ2YWwgKHNlZSBTZWN0aW9uDQogICA5LjIuMS4xKS4NCg0KICAgVGhl IHN1Z2dlc3RlZCBkZWZhdWx0IHZhbHVlIGZvciB0aGUgQ29ubmVjdFJldHJ5IHRpbWVyIGlzIDEy MCBzZWMtDQogICBvbmRzLg0KDQogICBUaGUgc3VnZ2VzdGVkIGRlZmF1bHQgdmFsdWUgZm9yIHRo ZSBIb2xkIFRpbWVyIGlzIDkwIHNlY29uZHMuDQoNCiAgIFRoZSBzdWdnZXN0ZWQgZGVmYXVsdCB2 YWx1ZSBmb3IgdGhlIEtlZXBBbGl2ZSB0aW1lciBpcyAxLzMgb2YgdGhlDQogICBIb2xkIFRpbWUu DQoNCg0KDQpFeHBpcmF0aW9uIERhdGUgU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAMW1BhZ2UgNzddDQoNCg0KDQoNCg0KUkZDIERSQUZUICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDAzDQoNCg0K ICAgVGhlIHN1Z2dlc3RlZCBkZWZhdWx0IHZhbHVlIGZvciB0aGUgTWluQVNPcmlnaW5hdGlvbklu dGVydmFsIGlzIDE1DQogICBzZWNvbmRzLg0KDQogICBUaGUgc3VnZ2VzdGVkIGRlZmF1bHQgdmFs dWUgZm9yIHRoZSBNaW5Sb3V0ZUFkdmVydGlzZW1lbnRJbnRlcnZhbCBpcw0KICAgMzAgc2Vjb25k cy4NCg0KICAgQW4gaW1wbGVtZW50YXRpb24gb2YgQkdQIE1VU1QgYWxsb3cgdGhlIEhvbGQgVGlt ZSB0aW1lciB0byBiZSBjb25maWctDQogICB1cmFibGUgb24gYSBwZXIgcGVlciBiYXNpcywgYW5k IE1BWSBhbGxvdyB0aGUgb3RoZXIgdGltZXJzIHRvIGJlIGNvbi0NCiAgIGZpZ3VyYWJsZS4NCg0K ICAgVG8gbWluaW1pemUgdGhlIGxpa2VsaWhvb2QgdGhhdCB0aGUgZGlzdHJpYnV0aW9uIG9mIEJH UCBtZXNzYWdlcyBieSBhDQogICBnaXZlbiBCR1Agc3BlYWtlciB3aWxsIGNvbnRhaW4gcGVha3Ms IGppdHRlciBTSE9VTEQgYmUgYXBwbGllZCB0byB0aGUNCiAgIHRpbWVycyBhc3NvY2lhdGVkIHdp dGggTWluQVNPcmlnaW5hdGlvbkludGVydmFsLCBLZWVwQWxpdmUsIE1pbi0NCiAgIFJvdXRlQWR2 ZXJ0aXNlbWVudEludGVydmFsLCBhbmQgQ29ubmVjdFJldHJ5LiBBIGdpdmVuIEJHUCBzcGVha2Vy IE1BWQ0KICAgYXBwbHkgdGhlIHNhbWUgaml0dGVyIHRvIGVhY2ggb2YgdGhlc2UgcXVhbnRpdGll cyByZWdhcmRsZXNzIG9mIHRoZQ0KICAgZGVzdGluYXRpb25zIHRvIHdoaWNoIHRoZSB1cGRhdGVz IGFyZSBiZWluZyBzZW50OyB0aGF0IGlzLCBqaXR0ZXINCiAgIG5lZWQgbm90IGJlIGNvbmZpZ3Vy ZWQgb24gYSAicGVyIHBlZXIiIGJhc2lzLg0KDQogICBUaGUgc3VnZ2VzdGVkIGRlZmF1bHQgYW1v dW50IG9mIGppdHRlciBTSEFMTCBiZSBkZXRlcm1pbmVkIGJ5IG11bHRpLQ0KICAgcGx5aW5nIHRo ZSBiYXNlIHZhbHVlIG9mIHRoZSBhcHByb3ByaWF0ZSB0aW1lciBieSBhIHJhbmRvbSBmYWN0b3IN CiAgIHdoaWNoIGlzIHVuaWZvcm1seSBkaXN0cmlidXRlZCBpbiB0aGUgcmFuZ2UgZnJvbSAwLjc1 IHRvIDEuMC4gQSBuZXcNCiAgIHJhbmRvbSB2YWx1ZSBTSE9VTEQgYmUgcGlja2VkIGVhY2ggdGlt ZSB0aGUgdGltZXIgaXMgc2V0LiBUaGUgcmFuZ2UNCiAgIG9mIHRoZSBqaXR0ZXIgcmFuZG9tIHZh bHVlIE1BWSBiZSBjb25maWd1cmFibGUuDQoNCg0KQXBwZW5kaXggQS4gQ29tcGFyaXNvbiB3aXRo IFJGQzE3NzENCg0KDQogICBUaGVyZSBhcmUgbnVtZXJvdXMgZWRpdG9yaWFsIGNoYW5nZXMgKHRv byBtYW55IHRvIGxpc3QgaGVyZSkuDQoNCiAgIFRoZSBmb2xsb3dpbmcgbGlzdCB0aGUgdGVjaG5p Y2FsIGNoYW5nZXM6DQoNCiAgICAgIENoYW5nZXMgdG8gcmVmbGVjdCB0aGUgdXNhZ2VzIG9mIHN1 Y2ggZmVhdHVyZXMgYXMgVENQIE1ENQ0KICAgICAgW1JGQzIzODVdLCBCR1AgUm91dGUgUmVmbGVj dG9ycyBbUkZDMjc5Nl0sIEJHUCBDb25mZWRlcmF0aW9ucw0KICAgICAgW1JGQzMwNjVdLCBhbmQg QkdQIFJvdXRlIFJlZnJlc2ggW1JGQzI5MThdLg0KDQogICAgICBDbGFyaWZpY2F0aW9uIG9uIHRo ZSB1c2Ugb2YgdGhlIEJHUCBJZGVudGlmaWVyIGluIHRoZSBBR0dSRUdBVE9SDQogICAgICBhdHRy aWJ1dGUuDQoNCiAgICAgIFByb2NlZHVyZXMgZm9yIGltcG9zaW5nIGFuIHVwcGVyIGJvdW5kIG9u IHRoZSBudW1iZXIgb2YgcHJlZml4ZXMNCiAgICAgIHRoYXQgYSBCR1Agc3BlYWtlciB3b3VsZCBh Y2NlcHQgZnJvbSBhIHBlZXIuDQoNCiAgICAgIFRoZSBhYmlsaXR5IG9mIGEgQkdQIHNwZWFrZXIg dG8gaW5jbHVkZSBtb3JlIHRoYW4gb25lIGluc3RhbmNlIG9mDQogICAgICBpdHMgb3duIEFTIGlu IHRoZSBBU19QQVRIIGF0dHJpYnV0ZSBmb3IgdGhlIHB1cnBvc2Ugb2YgaW50ZXItQVMNCiAgICAg IHRyYWZmaWMgZW5naW5lZXJpbmcuDQoNCiAgICAgIENsYXJpZmljYXRpb25zIG9uIHRoZSB2YXJp b3VzIHR5cGVzIG9mIE5FWFRfSE9Qcy4NCg0KDQoNCg0KRXhwaXJhdGlvbiBEYXRlIFNlcHRlbWJl ciAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDFtQYWdlIDc4XQ0KDQoNCg0K DQoNClJGQyBEUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCiAgICAgIENsYXJpZmljYXRpb25zIHRvIHRoZSB1c2Ug b2YgdGhlIEFUT01JQ19BR0dSRUdBVEUgYXR0cmlidXRlLg0KDQogICAgICBUaGUgcmVsYXRpb25z aGlwIGJldHdlZW4gdGhlIGltbWVkaWF0ZSBuZXh0IGhvcCwgYW5kIHRoZSBuZXh0IGhvcA0KICAg ICAgYXMgc3BlY2lmaWVkIGluIHRoZSBORVhUX0hPUCBwYXRoIGF0dHJpYnV0ZS4NCg0KICAgICAg Q2xhcmlmaWNhdGlvbnMgb24gdGhlIHRpZS1icmVha2luZyBwcm9jZWR1cmVzLg0KDQogICAgICBD bGFyaWZpY2F0aW9ucyBvbiB0aGUgZnJlcXVlbmN5IG9mIHJvdXRlIGFkdmVydGlzZW1lbnRzLg0K DQogICAgICBPcHRpb25hbCBQYXJhbWV0ZXIgVHlwZSAxIChBdXRoZW50aWNhdGlvbiBJbmZvcm1h dGlvbikgaGFzIGJlZW4NCiAgICAgIGRlcHJlY2F0ZWQuDQoNCiAgICAgIFVQREFURSBNZXNzYWdl IEVycm9yIHN1YmNvZGUgNyAoQVMgUm91dGluZyBMb29wKSBoYXMgYmVlbiBkZXByZS0NCiAgICAg IGNhdGVkLg0KDQogICAgICBPUEVOIE1lc3NhZ2UgRXJyb3Igc3ViY29kZSA1IChBdXRoZW50aWNh dGlvbiBGYWlsdXJlKSBoYXMgYmVlbg0KICAgICAgZGVwcmVjYXRlZC4NCg0KICAgICAgVXNlIG9m IHRoZSBNYXJrZXIgZmllbGQgZm9yIGF1dGhlbnRpY2F0aW9uIGhhcyBiZWVuIGRlcHJlY2F0ZWQu DQoNCiAgICAgIFVzZSBvZiBUQ1AgTUQ1IFtSRkMyMzg1XSBmb3IgYXV0aGVudGljYXRpb24gaXMg bWFuZGF0b3J5Lg0KDQogICAgICBDbGFyaWZpY2F0aW9uIG9mIEJHUCBGU00uIA0KDQoNCkFwcGVu ZGl4IEIuIENvbXBhcmlzb24gd2l0aCBSRkMxMjY3DQoNCg0KICAgQWxsIHRoZSBjaGFuZ2VzIGxp c3RlZCBpbiBBcHBlbmRpeCBBLCBwbHVzIHRoZSBmb2xsb3dpbmcuDQoNCiAgIEJHUC00IGlzIGNh cGFibGUgb2Ygb3BlcmF0aW5nIGluIGFuIGVudmlyb25tZW50IHdoZXJlIGEgc2V0IG9mIHJlYWNo LQ0KICAgYWJsZSBkZXN0aW5hdGlvbnMgbWF5IGJlIGV4cHJlc3NlZCB2aWEgYSBzaW5nbGUgSVAg cHJlZml4LiAgVGhlIGNvbi0NCiAgIGNlcHQgb2YgbmV0d29yayBjbGFzc2VzLCBvciBzdWJuZXR0 aW5nIGlzIGZvcmVpZ24gdG8gQkdQLTQuICBUbw0KICAgYWNjb21tb2RhdGUgdGhlc2UgY2FwYWJp bGl0aWVzIEJHUC00IGNoYW5nZXMgc2VtYW50aWNzIGFuZCBlbmNvZGluZw0KICAgYXNzb2NpYXRl ZCB3aXRoIHRoZSBBU19QQVRIIGF0dHJpYnV0ZS4gTmV3IHRleHQgaGFzIGJlZW4gYWRkZWQgdG8N CiAgIGRlZmluZSBzZW1hbnRpY3MgYXNzb2NpYXRlZCB3aXRoIElQIHByZWZpeGVzLiBUaGVzZSBh YmlsaXRpZXMgYWxsb3cNCiAgIEJHUC00IHRvIHN1cHBvcnQgdGhlIHByb3Bvc2VkIHN1cGVybmV0 dGluZyBzY2hlbWUgWzldLg0KDQogICBUbyBzaW1wbGlmeSBjb25maWd1cmF0aW9uIHRoaXMgdmVy c2lvbiBpbnRyb2R1Y2VzIGEgbmV3IGF0dHJpYnV0ZSwNCiAgIExPQ0FMX1BSRUYsIHRoYXQgZmFj aWxpdGF0ZXMgcm91dGUgc2VsZWN0aW9uIHByb2NlZHVyZXMuDQoNCiAgIFRoZSBJTlRFUl9BU19N RVRSSUMgYXR0cmlidXRlIGhhcyBiZWVuIHJlbmFtZWQgdG8gYmUgTVVMVElfRVhJVF9ESVNDLg0K ICAgQSBuZXcgYXR0cmlidXRlLCBBVE9NSUNfQUdHUkVHQVRFLCBoYXMgYmVlbiBpbnRyb2R1Y2Vk IHRvIGluc3VyZSB0aGF0DQogICBjZXJ0YWluIGFnZ3JlZ2F0ZXMgYXJlIG5vdCBkZS1hZ2dyZWdh dGVkLiBBbm90aGVyIG5ldyBhdHRyaWJ1dGUsDQogICBBR0dSRUdBVE9SLCBjYW4gYmUgYWRkZWQg dG8gYWdncmVnYXRlIHJvdXRlcyBpbiBvcmRlciB0byBhZHZlcnRpc2UNCiAgIHdoaWNoIEFTIGFu ZCB3aGljaCBCR1Agc3BlYWtlciB3aXRoaW4gdGhhdCBBUyBjYXVzZWQgdGhlIGFnZ3JlZ2F0aW9u Lg0KDQogICBUbyBpbnN1cmUgdGhhdCBIb2xkIFRpbWVycyBhcmUgc3ltbWV0cmljLCB0aGUgSG9s ZCBUaW1lIGlzIG5vdyBuZWdvLQ0KICAgdGlhdGVkIG9uIGEgcGVyLWNvbm5lY3Rpb24gYmFzaXMu IEhvbGQgVGltZXMgb2YgemVybyBhcmUgbm93IHN1cC0NCiAgIHBvcnRlZC4NCg0KDQoNCkV4cGly YXRpb24gRGF0ZSBTZXB0ZW1iZXIgMjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAxbUGFnZSA3OV0NCg0KDQoNCg0KDQpSRkMgRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDMNCg0KDQpBcHBlbmRpeCBDLiBD b21wYXJpc29uIHdpdGggUkZDIDExNjMNCg0KDQogICBBbGwgb2YgdGhlIGNoYW5nZXMgbGlzdGVk IGluIEFwcGVuZGljZXMgQSBhbmQgQiwgcGx1cyB0aGUgZm9sbG93aW5nLg0KDQogICBUbyBkZXRl Y3QgYW5kIHJlY292ZXIgZnJvbSBCR1AgY29ubmVjdGlvbiBjb2xsaXNpb24sIGEgbmV3IGZpZWxk IChCR1ANCiAgIElkZW50aWZpZXIpIGhhcyBiZWVuIGFkZGVkIHRvIHRoZSBPUEVOIG1lc3NhZ2Uu IE5ldyB0ZXh0IChTZWN0aW9uDQogICA2LjgpIGhhcyBiZWVuIGFkZGVkIHRvIHNwZWNpZnkgdGhl IHByb2NlZHVyZSBmb3IgZGV0ZWN0aW5nIGFuZCByZWNvdi0NCiAgIGVyaW5nIGZyb20gY29sbGlz aW9uLg0KDQogICBUaGUgbmV3IGRvY3VtZW50IG5vIGxvbmdlciByZXN0cmljdHMgdGhlIHJvdXRl ciB0aGF0IGlzIHBhc3NlZCBpbiB0aGUNCiAgIE5FWFRfSE9QIHBhdGggYXR0cmlidXRlIHRvIGJl IHBhcnQgb2YgdGhlIHNhbWUgQXV0b25vbW91cyBTeXN0ZW0gYXMNCiAgIHRoZSBCR1AgU3BlYWtl ci4NCg0KICAgTmV3IGRvY3VtZW50IG9wdGltaXplcyBhbmQgc2ltcGxpZmllcyB0aGUgZXhjaGFu Z2Ugb2YgdGhlIGluZm9ybWF0aW9uDQogICBhYm91dCBwcmV2aW91c2x5IHJlYWNoYWJsZSByb3V0 ZXMuDQoNCg0KQXBwZW5kaXggRC4gQ29tcGFyaXNvbiB3aXRoIFJGQyAxMTA1DQoNCg0KICAgQWxs IG9mIHRoZSBjaGFuZ2VzIGxpc3RlZCBpbiBBcHBlbmRpY2VzIEEsIEIgYW5kIEMsIHBsdXMgdGhl IGZvbGxvdy0NCiAgIGluZy4NCg0KICAgTWlub3IgY2hhbmdlcyB0byB0aGUgUkZDMTEwNSBGaW5p dGUgU3RhdGUgTWFjaGluZSB3ZXJlIG5lY2Vzc2FyeSB0bw0KICAgYWNjb21tb2RhdGUgdGhlIFRD UCB1c2VyIGludGVyZmFjZSBwcm92aWRlZCBieSA0LjMgQlNELg0KDQogICBUaGUgbm90aW9uIG9m IFVwL0Rvd24vSG9yaXpvbnRhbCByZWxhdGlvbnMgcHJlc2VudCBpbiBSRkMxMTA1IGhhcw0KICAg YmVlbiByZW1vdmVkIGZyb20gdGhlIHByb3RvY29sLg0KDQogICBUaGUgY2hhbmdlcyBpbiB0aGUg bWVzc2FnZSBmb3JtYXQgZnJvbSBSRkMxMTA1IGFyZSBhcyBmb2xsb3dzOg0KDQogICAgICAxLiAg VGhlIEhvbGQgVGltZSBmaWVsZCBoYXMgYmVlbiByZW1vdmVkIGZyb20gdGhlIEJHUCBoZWFkZXIg YW5kDQogICAgICBhZGRlZCB0byB0aGUgT1BFTiBtZXNzYWdlLg0KDQogICAgICAyLiAgVGhlIHZl cnNpb24gZmllbGQgaGFzIGJlZW4gcmVtb3ZlZCBmcm9tIHRoZSBCR1AgaGVhZGVyIGFuZA0KICAg ICAgYWRkZWQgdG8gdGhlIE9QRU4gbWVzc2FnZS4NCg0KICAgICAgMy4gIFRoZSBMaW5rIFR5cGUg ZmllbGQgaGFzIGJlZW4gcmVtb3ZlZCBmcm9tIHRoZSBPUEVOIG1lc3NhZ2UuDQoNCiAgICAgIDQu ICBUaGUgT1BFTiBDT05GSVJNIG1lc3NhZ2UgaGFzIGJlZW4gZWxpbWluYXRlZCBhbmQgcmVwbGFj ZWQgd2l0aA0KICAgICAgaW1wbGljaXQgY29uZmlybWF0aW9uIHByb3ZpZGVkIGJ5IHRoZSBLRUVQ QUxJVkUgbWVzc2FnZS4NCg0KICAgICAgNS4gIFRoZSBmb3JtYXQgb2YgdGhlIFVQREFURSBtZXNz YWdlIGhhcyBiZWVuIGNoYW5nZWQgc2lnbmlmaS0NCiAgICAgIGNhbnRseS4gIE5ldyBmaWVsZHMg d2VyZSBhZGRlZCB0byB0aGUgVVBEQVRFIG1lc3NhZ2UgdG8gc3VwcG9ydA0KICAgICAgbXVsdGlw bGUgcGF0aCBhdHRyaWJ1dGVzLg0KDQogICAgICA2LiAgVGhlIE1hcmtlciBmaWVsZCBoYXMgYmVl biBleHBhbmRlZCBhbmQgaXRzIHJvbGUgYnJvYWRlbmVkIHRvDQoNCg0KDQpFeHBpcmF0aW9uIERh dGUgU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAMW1BhZ2Ug ODBdDQoNCg0KDQoNCg0KUkZDIERSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDAzDQoNCg0KICAgICAgc3VwcG9ydCBhdXRoZW50 aWNhdGlvbi4NCg0KICAgICAgTm90ZSB0aGF0IHF1aXRlIG9mdGVuIEJHUCwgYXMgc3BlY2lmaWVk IGluIFJGQyAxMTA1LCBpcyByZWZlcnJlZA0KICAgICAgdG8gYXMgQkdQLTEsIEJHUCwgYXMgc3Bl Y2lmaWVkIGluIFJGQyAxMTYzLCBpcyByZWZlcnJlZCB0byBhcw0KICAgICAgQkdQLTIsIEJHUCwg YXMgc3BlY2lmaWVkIGluIFJGQzEyNjcgaXMgcmVmZXJyZWQgdG8gYXMgQkdQLTMsIGFuZA0KICAg ICAgQkdQLCBhcyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCBpcyByZWZlcnJlZCB0byBhcyBC R1AtNC4NCg0KDQpBcHBlbmRpeCBFLiAgVENQIG9wdGlvbnMgdGhhdCBtYXkgYmUgdXNlZCB3aXRo IEJHUA0KDQoNCiAgIElmIGEgbG9jYWwgc3lzdGVtIFRDUCB1c2VyIGludGVyZmFjZSBzdXBwb3J0 cyBUQ1AgUFVTSCBmdW5jdGlvbiwgdGhlbg0KICAgZWFjaCBCR1AgbWVzc2FnZSBTSE9VTEQgYmUg dHJhbnNtaXR0ZWQgd2l0aCBQVVNIIGZsYWcgc2V0LiAgU2V0dGluZw0KICAgUFVTSCBmbGFnIGZv cmNlcyBCR1AgbWVzc2FnZXMgdG8gYmUgdHJhbnNtaXR0ZWQgcHJvbXB0bHkgdG8gdGhlDQogICBy ZWNlaXZlci4NCg0KICAgSWYgYSBsb2NhbCBzeXN0ZW0gVENQIHVzZXIgaW50ZXJmYWNlIHN1cHBv cnRzIHNldHRpbmcgb2YgdGhlIERTQ1ANCiAgIGZpZWxkIFtSRkMyNDc0XSBmb3IgVENQIGNvbm5l Y3Rpb25zLCB0aGVuIHRoZSBUQ1AgY29ubmVjdGlvbiB1c2VkIGJ5DQogICBCR1AgU0hPVUxEIGJl IG9wZW5lZCB3aXRoIGJpdHMgMC0yIG9mIHRoZSBEU0NQIGZpZWxkIHNldCB0byAxMTANCiAgIChi aW5hcnkpLg0KDQoNCkFwcGVuZGl4IEYuICBJbXBsZW1lbnRhdGlvbiBSZWNvbW1lbmRhdGlvbnMN Cg0KDQogICBUaGlzIHNlY3Rpb24gcHJlc2VudHMgc29tZSBpbXBsZW1lbnRhdGlvbiByZWNvbW1l bmRhdGlvbnMuDQoNCg0KQXBwZW5kaXggRi4xIE11bHRpcGxlIE5ldHdvcmtzIFBlciBNZXNzYWdl DQoNCg0KICAgVGhlIEJHUCBwcm90b2NvbCBhbGxvd3MgZm9yIG11bHRpcGxlIGFkZHJlc3MgcHJl Zml4ZXMgd2l0aCB0aGUgc2FtZQ0KICAgcGF0aCBhdHRyaWJ1dGVzIHRvIGJlIHNwZWNpZmllZCBp biBvbmUgbWVzc2FnZS4gTWFraW5nIHVzZSBvZiB0aGlzDQogICBjYXBhYmlsaXR5IGlzIGhpZ2hs eSByZWNvbW1lbmRlZC4gV2l0aCBvbmUgYWRkcmVzcyBwcmVmaXggcGVyIG1lc3NhZ2UNCiAgIHRo ZXJlIGlzIGEgc3Vic3RhbnRpYWwgaW5jcmVhc2UgaW4gb3ZlcmhlYWQgaW4gdGhlIHJlY2VpdmVy LiBOb3Qgb25seQ0KICAgZG9lcyB0aGUgc3lzdGVtIG92ZXJoZWFkIGluY3JlYXNlIGR1ZSB0byB0 aGUgcmVjZXB0aW9uIG9mIG11bHRpcGxlDQogICBtZXNzYWdlcywgYnV0IHRoZSBvdmVyaGVhZCBv ZiBzY2FubmluZyB0aGUgcm91dGluZyB0YWJsZSBmb3IgdXBkYXRlcw0KICAgdG8gQkdQIHBlZXJz IGFuZCBvdGhlciByb3V0aW5nIHByb3RvY29scyAoYW5kIHNlbmRpbmcgdGhlIGFzc29jaWF0ZWQN CiAgIG1lc3NhZ2VzKSBpcyBpbmN1cnJlZCBtdWx0aXBsZSB0aW1lcyBhcyB3ZWxsLg0KDQogICBP bmUgbWV0aG9kIG9mIGJ1aWxkaW5nIG1lc3NhZ2VzIGNvbnRhaW5pbmcgbWFueSBhZGRyZXNzIHBy ZWZpeGVzIHBlcg0KICAgYSBwYXRoIGF0dHJpYnV0ZSBzZXQgZnJvbSBhIHJvdXRpbmcgdGFibGUg dGhhdCBpcyBub3Qgb3JnYW5pemVkIG9uIGENCiAgIHBlciBwYXRoIGF0dHJpYnV0ZSBzZXQgYmFz aXMgaXMgdG8gYnVpbGQgbWFueSBtZXNzYWdlcyBhcyB0aGUgcm91dGluZw0KICAgdGFibGUgaXMg c2Nhbm5lZC4gQXMgZWFjaCBhZGRyZXNzIHByZWZpeCBpcyBwcm9jZXNzZWQsIGEgbWVzc2FnZSBm b3INCiAgIHRoZSBhc3NvY2lhdGVkIHNldCBvZiBwYXRoIGF0dHJpYnV0ZXMgaXMgYWxsb2NhdGVk LCBpZiBpdCBkb2VzIG5vdA0KICAgZXhpc3QsIGFuZCB0aGUgbmV3IGFkZHJlc3MgcHJlZml4IGlz IGFkZGVkIHRvIGl0LiAgSWYgc3VjaCBhIG1lc3NhZ2UNCiAgIGV4aXN0cywgdGhlIG5ldyBhZGRy ZXNzIHByZWZpeCBpcyBqdXN0IGFwcGVuZGVkIHRvIGl0LiBJZiB0aGUgbWVzc2FnZQ0KICAgbGFj a3MgdGhlIHNwYWNlIHRvIGhvbGQgdGhlIG5ldyBhZGRyZXNzIHByZWZpeCwgaXQgaXMgdHJhbnNt aXR0ZWQsIGENCg0KDQoNCkV4cGlyYXRpb24gRGF0ZSBTZXB0ZW1iZXIgMjAwMyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAxbUGFnZSA4MV0NCg0KDQoNCg0KDQpSRkMgRFJBRlQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIw MDMNCg0KDQogICBuZXcgbWVzc2FnZSBpcyBhbGxvY2F0ZWQsIGFuZCB0aGUgbmV3IGFkZHJlc3Mg cHJlZml4IGlzIGluc2VydGVkIGludG8NCiAgIHRoZSBuZXcgbWVzc2FnZS4gV2hlbiB0aGUgZW50 aXJlIHJvdXRpbmcgdGFibGUgaGFzIGJlZW4gc2Nhbm5lZCwgYWxsDQogICBhbGxvY2F0ZWQgbWVz c2FnZXMgYXJlIHNlbnQgYW5kIHRoZWlyIHJlc291cmNlcyByZWxlYXNlZC4gIE1heGltdW0NCiAg IGNvbXByZXNzaW9uIGlzIGFjaGlldmVkIHdoZW4gYWxsICB0aGUgZGVzdGluYXRpb25zIGNvdmVy ZWQgYnkgdGhlDQogICBhZGRyZXNzIHByZWZpeGVzIHNoYXJlIGEgY29tbW9uIHNldCBvZiBwYXRo IGF0dHJpYnV0ZXMgbWFraW5nIGl0IHBvcy0NCiAgIHNpYmxlIHRvIHNlbmQgbWFueSBhZGRyZXNz IHByZWZpeGVzIGluIG9uZSA0MDk2LWJ5dGUgbWVzc2FnZS4NCg0KICAgV2hlbiBwZWVyaW5nIHdp dGggYSBCR1AgaW1wbGVtZW50YXRpb24gdGhhdCBkb2VzIG5vdCBjb21wcmVzcyBtdWx0aS0NCiAg IHBsZSBhZGRyZXNzIHByZWZpeGVzIGludG8gb25lIG1lc3NhZ2UsIGl0IG1heSBiZSBuZWNlc3Nh cnkgdG8gdGFrZQ0KICAgc3RlcHMgdG8gcmVkdWNlIHRoZSBvdmVyaGVhZCBmcm9tIHRoZSBmbG9v ZCBvZiBkYXRhIHJlY2VpdmVkIHdoZW4gYQ0KICAgcGVlciBpcyBhY3F1aXJlZCBvciBhIHNpZ25p ZmljYW50IG5ldHdvcmsgdG9wb2xvZ3kgY2hhbmdlIG9jY3Vycy4gT25lDQogICBtZXRob2Qgb2Yg ZG9pbmcgdGhpcyBpcyB0byBsaW1pdCB0aGUgcmF0ZSBvZiB1cGRhdGVzLiAgVGhpcyB3aWxsDQog ICBlbGltaW5hdGUgdGhlIHJlZHVuZGFudCBzY2FubmluZyBvZiB0aGUgcm91dGluZyB0YWJsZSB0 byBwcm92aWRlDQogICBmbGFzaCB1cGRhdGVzIGZvciBCR1AgcGVlcnMgYW5kIG90aGVyIHJvdXRp bmcgcHJvdG9jb2xzLiAgQSBkaXNhZHZhbi0NCiAgIHRhZ2Ugb2YgdGhpcyBhcHByb2FjaCBpcyB0 aGF0IGl0IGluY3JlYXNlcyB0aGUgcHJvcGFnYXRpb24gbGF0ZW5jeSBvZg0KICAgcm91dGluZyBp bmZvcm1hdGlvbi4gIEJ5IGNob29zaW5nIGEgbWluaW11bSBmbGFzaCB1cGRhdGUgaW50ZXJ2YWwN CiAgIHRoYXQgaXMgbm90IG11Y2ggZ3JlYXRlciB0aGFuIHRoZSB0aW1lIGl0IHRha2VzIHRvIHBy b2Nlc3MgdGhlIG11bHRpLQ0KICAgcGxlIG1lc3NhZ2VzIHRoaXMgbGF0ZW5jeSBzaG91bGQgYmUg bWluaW1pemVkLiBBIGJldHRlciBtZXRob2Qgd291bGQNCiAgIGJlIHRvIHJlYWQgYWxsIHJlY2Vp dmVkIG1lc3NhZ2VzIGJlZm9yZSBzZW5kaW5nIHVwZGF0ZXMuDQoNCg0KQXBwZW5kaXggRi4yIFJl ZHVjaW5nIHJvdXRlIGZsYXBwaW5nDQoNCg0KICAgVG8gYXZvaWQgZXhjZXNzaXZlIHJvdXRlIGZs YXBwaW5nIGEgQkdQIHNwZWFrZXIgd2hpY2ggbmVlZHMgdG8gd2l0aC0NCiAgIGRyYXcgYSBkZXN0 aW5hdGlvbiBhbmQgc2VuZCBhbiB1cGRhdGUgYWJvdXQgYSBtb3JlIHNwZWNpZmljIG9yIGxlc3MN CiAgIHNwZWNpZmljIHJvdXRlIFNIT1VMRCBjb21iaW5lIHRoZW0gaW50byB0aGUgc2FtZSBVUERB VEUgbWVzc2FnZS4NCg0KDQpBcHBlbmRpeCBGLjMgUGF0aCBhdHRyaWJ1dGUgb3JkZXJpbmcNCg0K DQogICBJbXBsZW1lbnRhdGlvbnMgd2hpY2ggY29tYmluZSB1cGRhdGUgbWVzc2FnZXMgYXMgZGVz Y3JpYmVkIGFib3ZlIGluDQogICA2LjEgbWF5IHByZWZlciB0byBzZWUgYWxsIHBhdGggYXR0cmli dXRlcyBwcmVzZW50ZWQgaW4gYSBrbm93biBvcmRlci4NCiAgIFRoaXMgcGVybWl0cyB0aGVtIHRv IHF1aWNrbHkgaWRlbnRpZnkgc2V0cyBvZiBhdHRyaWJ1dGVzIGZyb20gZGlmZmVyLQ0KICAgZW50 IHVwZGF0ZSBtZXNzYWdlcyB3aGljaCBhcmUgc2VtYW50aWNhbGx5IGlkZW50aWNhbC4gIFRvIGZh Y2lsaXRhdGUNCiAgIHRoaXMsIGl0IGlzIGEgdXNlZnVsIG9wdGltaXphdGlvbiB0byBvcmRlciB0 aGUgcGF0aCBhdHRyaWJ1dGVzDQogICBhY2NvcmRpbmcgdG8gdHlwZSBjb2RlLiAgVGhpcyBvcHRp bWl6YXRpb24gaXMgZW50aXJlbHkgb3B0aW9uYWwuDQoNCg0KQXBwZW5kaXggRi40IEFTX1NFVCBz b3J0aW5nDQoNCg0KICAgQW5vdGhlciB1c2VmdWwgb3B0aW1pemF0aW9uIHRoYXQgY2FuIGJlIGRv bmUgdG8gc2ltcGxpZnkgdGhpcyBzaXR1YS0NCiAgIHRpb24gaXMgdG8gc29ydCB0aGUgQVMgbnVt YmVycyBmb3VuZCBpbiBhbiBBU19TRVQuICBUaGlzIG9wdGltaXphdGlvbg0KICAgaXMgZW50aXJl bHkgb3B0aW9uYWwuDQoNCg0KDQoNCg0KRXhwaXJhdGlvbiBEYXRlIFNlcHRlbWJlciAyMDAzICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDFtQYWdlIDgyXQ0KDQoNCg0KDQoNClJGQyBE UkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg TWFyY2ggMjAwMw0KDQoNCkFwcGVuZGl4IEYuNSBDb250cm9sIG92ZXIgdmVyc2lvbiBuZWdvdGlh dGlvbg0KDQoNCiAgIFNpbmNlIEJHUC00IGlzIGNhcGFibGUgb2YgY2FycnlpbmcgYWdncmVnYXRl ZCByb3V0ZXMgd2hpY2ggY2FuIG5vdCBiZQ0KICAgcHJvcGVybHkgcmVwcmVzZW50ZWQgaW4gQkdQ LTMsIGFuIGltcGxlbWVudGF0aW9uIHdoaWNoIHN1cHBvcnRzIEJHUC00DQogICBhbmQgYW5vdGhl ciBCR1AgdmVyc2lvbiBzaG91bGQgcHJvdmlkZSB0aGUgY2FwYWJpbGl0eSB0byBvbmx5IHNwZWFr DQogICBCR1AtNCBvbiBhIHBlci1wZWVyIGJhc2lzLg0KDQoNCkFwcGVuZGl4IEYuNiBDb21wbGV4 IEFTX1BBVEggYWdncmVnYXRpb24NCg0KDQogICBBbiBpbXBsZW1lbnRhdGlvbiB3aGljaCBjaG9v c2VzIHRvIHByb3ZpZGUgYSBwYXRoIGFnZ3JlZ2F0aW9uIGFsZ28tDQogICByaXRobSB3aGljaCBy ZXRhaW5zIHNpZ25pZmljYW50IGFtb3VudHMgb2YgcGF0aCBpbmZvcm1hdGlvbiBtYXkgd2lzaA0K ICAgdG8gdXNlIHRoZSBmb2xsb3dpbmcgcHJvY2VkdXJlOg0KDQogICAgICBGb3IgdGhlIHB1cnBv c2Ugb2YgYWdncmVnYXRpbmcgQVNfUEFUSCBhdHRyaWJ1dGVzIG9mIHR3byByb3V0ZXMsDQogICAg ICB3ZSBtb2RlbCBlYWNoIEFTIGFzIGEgdHVwbGUgPHR5cGUsIHZhbHVlPiwgd2hlcmUgInR5cGUi IGlkZW50aWZpZXMNCiAgICAgIGEgdHlwZSBvZiB0aGUgcGF0aCBzZWdtZW50IHRoZSBBUyBiZWxv bmdzIHRvIChlLmcuICBBU19TRVFVRU5DRSwNCiAgICAgIEFTX1NFVCksIGFuZCAidmFsdWUiIGlz IHRoZSBBUyBudW1iZXIuICBUd28gQVNzIGFyZSBzYWlkIHRvIGJlIHRoZQ0KICAgICAgc2FtZSBp ZiB0aGVpciBjb3JyZXNwb25kaW5nIDx0eXBlLCB2YWx1ZT4gdHVwbGVzIGFyZSB0aGUgc2FtZS4N Cg0KICAgICAgVGhlIGFsZ29yaXRobSB0byBhZ2dyZWdhdGUgdHdvIEFTX1BBVEggYXR0cmlidXRl cyB3b3JrcyBhcyBmb2wtDQogICAgICBsb3dzOg0KDQogICAgICAgICBhKSBJZGVudGlmeSB0aGUg c2FtZSBBU3MgKGFzIGRlZmluZWQgYWJvdmUpIHdpdGhpbiBlYWNoIEFTX1BBVEgNCiAgICAgICAg IGF0dHJpYnV0ZSB0aGF0IGFyZSBpbiB0aGUgc2FtZSByZWxhdGl2ZSBvcmRlciB3aXRoaW4gYm90 aA0KICAgICAgICAgQVNfUEFUSCBhdHRyaWJ1dGVzLiAgVHdvIEFTcywgWCBhbmQgWSwgYXJlIHNh aWQgdG8gYmUgaW4gdGhlDQogICAgICAgICBzYW1lIG9yZGVyIGlmIGVpdGhlcjoNCiAgICAgICAg ICAgIC0gWCBwcmVjZWRlcyBZIGluIGJvdGggQVNfUEFUSCBhdHRyaWJ1dGVzLCBvciAtIFkgcHJl Y2VkZXMgWA0KICAgICAgICAgICAgaW4gYm90aCBBU19QQVRIIGF0dHJpYnV0ZXMuDQoNCiAgICAg ICAgIGIpIFRoZSBhZ2dyZWdhdGVkIEFTX1BBVEggYXR0cmlidXRlIGNvbnNpc3RzIG9mIEFTcyBp ZGVudGlmaWVkDQogICAgICAgICBpbiAoYSkgaW4gZXhhY3RseSB0aGUgc2FtZSBvcmRlciBhcyB0 aGV5IGFwcGVhciBpbiB0aGUgQVNfUEFUSA0KICAgICAgICAgYXR0cmlidXRlcyB0byBiZSBhZ2dy ZWdhdGVkLiBJZiB0d28gY29uc2VjdXRpdmUgQVNzIGlkZW50aWZpZWQNCiAgICAgICAgIGluIChh KSBkbyBub3QgaW1tZWRpYXRlbHkgZm9sbG93IGVhY2ggb3RoZXIgaW4gYm90aCBvZiB0aGUNCiAg ICAgICAgIEFTX1BBVEggYXR0cmlidXRlcyB0byBiZSBhZ2dyZWdhdGVkLCB0aGVuIHRoZSBpbnRl cnZlbmluZyBBU3MNCiAgICAgICAgIChBU3MgdGhhdCBhcmUgYmV0d2VlbiB0aGUgdHdvIGNvbnNl Y3V0aXZlIEFTcyB0aGF0IGFyZSB0aGUNCiAgICAgICAgIHNhbWUpIGluIGJvdGggYXR0cmlidXRl cyBhcmUgY29tYmluZWQgaW50byBhbiBBU19TRVQgcGF0aCBzZWctDQogICAgICAgICBtZW50IHRo YXQgY29uc2lzdHMgb2YgdGhlIGludGVydmVuaW5nIEFTcyBmcm9tIGJvdGggQVNfUEFUSA0KICAg ICAgICAgYXR0cmlidXRlczsgdGhpcyBzZWdtZW50IGlzIHRoZW4gcGxhY2VkIGluIGJldHdlZW4g dGhlIHR3byBjb24tDQogICAgICAgICBzZWN1dGl2ZSBBU3MgaWRlbnRpZmllZCBpbiAoYSkgb2Yg dGhlIGFnZ3JlZ2F0ZWQgYXR0cmlidXRlLiBJZg0KICAgICAgICAgdHdvIGNvbnNlY3V0aXZlIEFT cyBpZGVudGlmaWVkIGluIChhKSBpbW1lZGlhdGVseSBmb2xsb3cgZWFjaA0KICAgICAgICAgb3Ro ZXIgaW4gb25lIGF0dHJpYnV0ZSwgYnV0IGRvIG5vdCBmb2xsb3cgaW4gYW5vdGhlciwgdGhlbiB0 aGUNCiAgICAgICAgIGludGVydmVuaW5nIEFTcyBvZiB0aGUgbGF0dGVyIGFyZSBjb21iaW5lZCBp bnRvIGFuIEFTX1NFVCBwYXRoDQogICAgICAgICBzZWdtZW50OyB0aGlzIHNlZ21lbnQgaXMgdGhl biBwbGFjZWQgaW4gYmV0d2VlbiB0aGUgdHdvIGNvbnNlYy0NCiAgICAgICAgIHV0aXZlIEFTcyBp ZGVudGlmaWVkIGluIChhKSBvZiB0aGUgYWdncmVnYXRlZCBhdHRyaWJ1dGUuDQoNCg0KDQoNCkV4 cGlyYXRpb24gRGF0ZSBTZXB0ZW1iZXIgMjAwMyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAxbUGFnZSA4M10NCg0KDQoNCg0KDQpSRkMgRFJBRlQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDMNCg0KDQogICAgICAgICBj KSBGb3IgZWFjaCBwYWlyIG9mIGFkamFjZW50IHR1cGxlcyBpbiB0aGUgYWdncmVnYXRlZCBBU19Q QVRILA0KICAgICAgICAgaWYgYm90aCB0dXBsZXMgaGF2ZSB0aGUgc2FtZSB0eXBlLCBtZXJnZSB0 aGVtIHRvZ2V0aGVyLCBhcyBsb25nDQogICAgICAgICBhcyBkb2luZyBzbyB3aWxsIG5vdCBjYXVz ZSBhIHNlZ21lbnQgd2l0aCBsZW5ndGggZ3JlYXRlciB0aGFuDQogICAgICAgICAyNTUgdG8gYmUg Z2VuZXJhdGVkLg0KDQogICAgICBJZiBhcyBhIHJlc3VsdCBvZiB0aGUgYWJvdmUgcHJvY2VkdXJl IGEgZ2l2ZW4gQVMgbnVtYmVyIGFwcGVhcnMNCiAgICAgIG1vcmUgdGhhbiBvbmNlIHdpdGhpbiB0 aGUgYWdncmVnYXRlZCBBU19QQVRIIGF0dHJpYnV0ZSwgYWxsLCBidXQNCiAgICAgIHRoZSBsYXN0 IGluc3RhbmNlIChyaWdodG1vc3Qgb2NjdXJyZW5jZSkgb2YgdGhhdCBBUyBudW1iZXIgU0hPVUxE DQogICAgICBiZSByZW1vdmVkIGZyb20gdGhlIGFnZ3JlZ2F0ZWQgQVNfUEFUSCBhdHRyaWJ1dGUu DQoNCg0KU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KDQoNCiAgIFRoZSBhdXRoZW50aWNhdGlv biBtZWNoYW5pc20gdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBvZiBCR1AgTVVTVCBzdXAtDQogICBw b3J0IGlzIHNwZWNpZmllZCBpbiBbUkZDMjM4NV0uIFRoZSBhdXRoZW50aWNhdGlvbiBwcm92aWRl ZCBieSB0aGlzDQogICBtZWNoYW5pc20gY291bGQgYmUgZG9uZSBvbiBhIHBlciBwZWVyIGJhc2lz Lg0KDQogICBTZWN1cml0eSBpc3N1ZXMgd2l0aCBCR1Agcm91dGluZyBpbmZvcm1hdGlvbiBkaXNz ZW1pbmF0aW9uIGFyZSBkaXMtDQogICBjdXNzZWQgaW4gW1hYWF0uDQoNCg0KSUFOQSBDb25zaWRl cmF0aW9ucw0KDQoNCiAgIEFsbCBleHRlbnNpb25zIHRvIHRoaXMgcHJvdG9jb2wsIGluY2x1ZGlu ZyBuZXcgbWVzc2FnZSB0eXBlcyBhbmQgUGF0aA0KICAgQXR0cmlidXRlcyBNVVNUIG9ubHkgYmUg bWFkZSB1c2luZyB0aGUgU3RhbmRhcmRzIEFjdGlvbiBwcm9jZXNzDQogICBkZWZpbmVkIGluIFtS RkMyNDM0XS4NCg0KDQpOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDNzkxXSBQb3N0ZWws IEouLCAiSW50ZXJuZXQgUHJvdG9jb2wgLSBEQVJQQSBJbnRlcm5ldCBQcm9ncmFtIFByby0NCiAg IHRvY29sIFNwZWNpZmljYXRpb24iLCBSRkM3OTEsIFNlcHRlbWJlciAxOTgxLg0KDQogICBbUkZD NzkzXSBQb3N0ZWwsIEouLCAiVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9jb2wgLSBEQVJQQSBJ bnRlcm5ldA0KICAgUHJvZ3JhbSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uIiwgUkZDNzkzLCBTZXB0 ZW1iZXIgMTk4MS4NCg0KICAgW1JGQzIxMTldIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1 c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBS RkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KICAgW1JGQzIzODVdIEhlZmZlcm5hbiwgQS4sICJQcm90 ZWN0aW9uIG9mIEJHUCBTZXNzaW9ucyB2aWEgdGhlIFRDUCBNRDUNCiAgIFNpZ25hdHVyZSBPcHRp b24iLCBSRkMyMzg1LCBBdWd1c3QgMTk5OC4NCg0KICAgW1JGQzI0MzRdIE5hcnRlbiwgVC4sIEFs dmVzdHJhbmQsIEguLCAiR3VpZGVsaW5lcyBmb3IgV3JpdGluZyBhbiBJQU5BDQogICBDb25zaWRl cmF0aW9ucyBTZWN0aW9uIGluIFJGQ3MiLCBSRkMyNDM0LCBPY3RvYmVyIDE5OTgNCg0KDQoNCg0K RXhwaXJhdGlvbiBEYXRlIFNlcHRlbWJlciAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDFtQYWdlIDg0XQ0KDQoNCg0KDQoNClJGQyBEUkFGVCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwMw0KDQoNCiAgIFtSRkMy NDc0XSBOaWNob2xzLCBLLiwgZXQgYWwuLCJEZWZpbml0aW9uIG9mIHRoZSBEaWZmZXJlbnRpYXRl ZCBTZXItDQogICB2aWNlcyBGaWVsZCAoRFMgRmllbGQpIGluIHRoZSBJUHY0IGFuZCBJUHY2IEhl YWRlcnMiLCBSRkMyNDc0LCBEZWNlbS0NCiAgIGJlciAxOTk4DQoNCg0KDQpOb24tbm9ybWF0aXZl IFJlZmVyZW5jZXMNCg0KICAgW1JGQzkwNF0gTWlsbHMsIEQuLCAiRXh0ZXJpb3IgR2F0ZXdheSBQ cm90b2NvbCBGb3JtYWwgU3BlY2lmaWNhdGlvbiIsDQogICBSRkM5MDQsIEFwcmlsIDE5ODQuDQoN CiAgIFtSRkMxMDkyXSBSZWtodGVyLCBZLiwgIkVHUCBhbmQgUG9saWN5IEJhc2VkIFJvdXRpbmcg aW4gdGhlIE5ldw0KICAgTlNGTkVUIEJhY2tib25lIiwgUkZDMTA5MiwgRmVicnVhcnkgMTk4OS4N Cg0KICAgW1JGQzEwOTNdIEJyYXVuLCBILVcuLCAiVGhlIE5TRk5FVCBSb3V0aW5nIEFyY2hpdGVj dHVyZSIsIFJGQzEwOTMsDQogICBGZWJydWFyeSAxOTg5Lg0KDQogICBbUkZDMTc3Ml0gUmVraHRl ciwgWS4sIGFuZCBQLiBHcm9zcywgIkFwcGxpY2F0aW9uIG9mIHRoZSBCb3JkZXIgR2F0ZS0NCiAg IHdheSBQcm90b2NvbCBpbiB0aGUgSW50ZXJuZXQiLCBSRkMxNzcyLCBNYXJjaCAxOTk1Lg0KDQog ICBbUkZDMTUxOF0gUmVraHRlciwgWS4sIExpLCBULiwgIkFuIEFyY2hpdGVjdHVyZSBmb3IgSVAg QWRkcmVzcyBBbGxvLQ0KICAgY2F0aW9uIHdpdGggQ0lEUiIsIFJGQyAxNTE4LCBTZXB0ZW1iZXIg MTk5My4NCg0KICAgW1JGQzE1MTldIEZ1bGxlciwgVi4sIExpLCBULiwgWXUsIEouLCBhbmQgVmFy YWRoYW4sIEsuLCAiIkNsYXNzbGVzcw0KICAgSW50ZXItRG9tYWluIFJvdXRpbmcgKENJRFIpOiBh biBBZGRyZXNzIEFzc2lnbm1lbnQgYW5kIEFnZ3JlZ2F0aW9uDQogICBTdHJhdGVneSIsIFJGQzE1 MTksIFNlcHRlbWJlciAxOTkzLg0KDQogICBbUkZDMTk5N10gUi4gQ2hhbmRyYSwgUC4gVHJhaW5h LCBULiBMaSwgIkJHUCBDb21tdW5pdGllcyBBdHRyaWJ1dGUiLA0KICAgUkZDIDE5OTcsIEF1Z3Vz dCAxOTk2Lg0KDQogICBbUkZDMjQzOV0gQy4gVmlsbGFtaXphciwgUi4gQ2hhbmRyYSwgUi4gR292 aW5kYW4sICJCR1AgUm91dGUgRmxhcA0KICAgRGFtcGluZyIsIFJGQzI0MzksIE5vdmVtYmVyIDE5 OTguDQoNCiAgIFtSRkMyNzk2XSBCYXRlcywgVC4sIENoYW5kcmEsIFIuLCBDaGVuLCBFLiwgIkJH UCBSb3V0ZSBSZWZsZWN0aW9uIC0NCiAgIEFuIEFsdGVybmF0aXZlIHRvIEZ1bGwgTWVzaCBJQkdQ IiwgUkZDMjc5NiwgIEFwcmlsIDIwMDAuDQoNCiAgIFtSRkMyODQyXSBSLiBDaGFuZHJhLCBKLiBT Y3VkZGVyLCAiQ2FwYWJpbGl0aWVzIEFkdmVydGlzZW1lbnQgd2l0aA0KICAgQkdQLTQiLCBSRkMy ODQyLg0KDQogICBbUkZDMjg1OF0gVC4gQmF0ZXMsIFIuIENoYW5kcmEsIEQuIEthdHosIFkuIFJl a2h0ZXIsICJNdWx0aXByb3RvY29sDQogICBFeHRlbnNpb25zIGZvciBCR1AtNCIsIFJGQzI4NTgu DQoNCiAgIFtSRkMyOTE4XSBDaGVuLCBFLiwgIlJvdXRlIFJlZnJlc2ggQ2FwYWJpbGl0eSBmb3Ig QkdQLTQiLCBSRkMyOTE4LA0KICAgU2VwdGVtYmVyIDIwMDAuDQoNCiAgIFtSRkMzMDY1XSBUcmFp bmEsIFAsIE1jUGhlcnNvbiwgRC4sIFNjdWRkZXIsIEouLCAiQXV0b25vbW91cyBTeXN0ZW0NCiAg IENvbmZlZGVyYXRpb25zIGZvciBCR1AiLCBSRkMzMDY1LCBGZWJydWFyeSAyMDAxLg0KDQoNCg0K DQpFeHBpcmF0aW9uIERhdGUgU2VwdGVtYmVyIDIwMDMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAMW1BhZ2UgODVdDQoNCg0KDQoNCg0KUkZDIERSQUZUICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDAzDQoNCg0KICAgW0lT MTA3NDddICJJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIFN5c3RlbXMgLSBUZWxlY29tbXVuaWNhdGlv bnMgYW5kDQogICBJbmZvcm1hdGlvbiBFeGNoYW5nZSBiZXR3ZWVuIFN5c3RlbXMgLSBQcm90b2Nv bCBmb3IgRXhjaGFuZ2Ugb2YNCiAgIEludGVyLWRvbWFpbiBSb3V0ZWluZyBJbmZvcm1hdGlvbiBh bW9uZyBJbnRlcm1lZGlhdGUgU3lzdGVtcyB0byBTdXAtDQogICBwb3J0IEZvcndhcmRpbmcgb2Yg SVNPIDg0NzMgUERVcyIsIElTTy9JRUMgSVMxMDc0NywgMTk5Mw0KDQogICBbWFhYXSBNdXJwaHks IFMuLCAiQkdQIFNlY3VyaXR5IFZ1bG5lcmFiaWxpdGllcyBBbmFseXNpcyIsIGRyYWZ0LQ0KICAg aWV0Zi1pZHItYmdwLXZ1bG4tMDAudHh0LCB3b3JrIGluIHByb2dyZXNzDQoNCg0KRWRpdG9ycycg QWRkcmVzc2VzDQoNCiAgIFlha292IFJla2h0ZXINCiAgIEp1bmlwZXIgTmV0d29ya3MNCiAgIGVt YWlsOiAgeWFrb3ZAanVuaXBlci5uZXQNCg0KICAgVG9ueSBMaQ0KICAgUHJvY2tldCBOZXR3b3Jr cywgSW5jLg0KICAgZW1haWw6ICB0bGlAcHJvY2tldC5jb20NCg0KICAgU3VzYW4gSGFyZXMNCg0K ICAgTmV4dEhvcCBUZWNobm9sb2dpZXMsIEluYy4NCiAgIGVtYWlsOiBza2hAbmV4dGhvcC5jb20N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K RXhwaXJhdGlvbiBEYXRlIFNlcHRlbWJlciAyMDAzICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDFtQYWdlIDg2XQ0KDQoNCg== ------_=_NextPart_001_01C33910.55DB7DB6-- From sip-admin@ietf.org Tue Jul 1 09:03:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18221 for ; Tue, 1 Jul 2003 09:03: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 19XKn1-0006zm-Ef for rtg-dir-archive@ietf.org; Tue, 01 Jul 2003 09:03:19 -0400 Date: Tue, 01 Jul 2003 09:03:19 -0400 Message-ID: <20030701130319.18162.26501.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rtg-dir-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rtg-dir-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rtg-dir-archive@ietf.org: List Password // URL ---- -------- rtg-dir@ietf.org utnefe https://www1.ietf.org/mailman/options/rtg-dir/rtg-dir-archive%40ietf.org From mailman-admin@ietf.org Thu Jul 3 18:32:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13169 for ; Thu, 3 Jul 2003 18: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 19YCcU-0002y6-Em for rtg-dir-archive@ietf.org; Thu, 03 Jul 2003 18:32:02 -0400 Date: Thu, 03 Jul 2003 18:32:02 -0400 Message-ID: <20030703223202.4508.85491.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rtg-dir-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk There was an error in the last monthly reminder, in that the NOTE WELL statement (below) was not included. Therefore, the reminder is being sent out again. This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rtg-dir-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rtg-dir-archive@ietf.org: List Password // URL ---- -------- rtg-dir@ietf.org utnefe https://www1.ietf.org/mailman/options/rtg-dir/rtg-dir-archive%40ietf.org From rtg-dir-admin@ietf.org Tue Jul 8 14:12:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02525 for ; Tue, 8 Jul 2003 14:12:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zwwb-000466-00 for rtg-dir-archive@ietf.org; Tue, 08 Jul 2003 14:12:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Zwwa-000462-00 for rtg-dir-archive@ietf.org; Tue, 08 Jul 2003 14:12:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zwwb-0001sn-2v; Tue, 08 Jul 2003 14:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zww6-0001sS-It for rtg-dir@optimus.ietf.org; Tue, 08 Jul 2003 14:11: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 OAA02504 for ; Tue, 8 Jul 2003 14:11:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zww4-00045Q-00 for rtg-dir@ietf.org; Tue, 08 Jul 2003 14:11:28 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Zww3-00045L-00 for rtg-dir@ietf.org; Tue, 08 Jul 2003 14:11:27 -0400 Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19Zww2-000GtO-5j for rtg-dir@ietf.org; Tue, 08 Jul 2003 18:11:26 +0000 Date: Tue, 8 Jul 2003 11:10:55 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <103737444749.20030708111055@psg.com> To: rtg-dir@ietf.org Subject: ops-dir input on routing protocol abuse MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, FYI below. Quite consistent with what we've discussed. I'll find some time today to summarize our discussion on the rtg-dir list. -- Alex http://www.psg.com/~zinin/ General analysis: 1. BGP is part of the Internet's critical infrastructure, whose failures would severely affect the operations of the Internet. 2. Overloading of BGP increases the likelihood of problems appearing in the original protocol and the Internet routing system, because of the following potential reasons: a. Increasing size of the code b. Increasing complexity of the code c. Increasing memory and BW requirements d. Interference between the original BGP code and it's "applications" due to implementation flaws. At a minimum in terms of memory usage and CPU utilization, and more direct if code is reused.) e. Interference between the Internet BGP routing system and other BGP-application specific distributed systems 3. It is not clear that the above problems will appear for sure, however, given the importance of BGP for the Internet, the burden of proof that they will not should be on the proponents of the new BGP applications. Recommendations: 1. Changes made to the Internet-critical protocols such as BGP should not be taken lightly. The following conditions should be met before changes are accepted: a. Reason for a change should be carefully described and agreed upon. Specifically, if the application is not obviously routing-related, justification should be provided as to why a particular routing protocol is the right choice. b. Operational impacts should be characterized, with the analysis of potential failure modes and their mitigation c. Changes to the deployment scenarios should be identified and analyzed to see how protocol characteristics may be affected Ideally, changes should not be admitted to the protocol unless it has been proven that they will do no harm to the existing Internet infrastructure, as opposed to a lack of proof that they will do harm. 2. In the particular situation with non-routing application of BGP as used for VPN membership discovery and L2 VPN signaling, a careful analysis should be performed to see if BGP protocol framework is the best fit for the problems that need to be solved. 3. If the conclusion is that the BGP framework is a good fit for these problems, the recommendation is to clearly separate BGP as used today for Internet routing from the BGP framework used for non-routing functions. This should be done by instantiating a new protocol, that would inherit the BGP functions most interesting for introduced functionality, yet would have its own name, transport protocol ports, and would explicitly not interoperate with what is known as BGP today. From rtg-dir-admin@ietf.org Tue Jul 8 19:52:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15761 for ; Tue, 8 Jul 2003 19:52:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a2GZ-0001Mn-00 for rtg-dir-archive@ietf.org; Tue, 08 Jul 2003 19:52:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19a2GZ-0001Mk-00 for rtg-dir-archive@ietf.org; Tue, 08 Jul 2003 19:52:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a2Ga-0000mZ-H0; Tue, 08 Jul 2003 19:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a2Fd-0000lm-7M for rtg-dir@optimus.ietf.org; Tue, 08 Jul 2003 19:52: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 TAA15726 for ; Tue, 8 Jul 2003 19:51:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a2Fb-0001LT-00 for rtg-dir@ietf.org; Tue, 08 Jul 2003 19:51:59 -0400 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19a2Fa-0001KX-00 for rtg-dir@ietf.org; Tue, 08 Jul 2003 19:51:58 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h6904XJh015995 for ; Tue, 8 Jul 2003 20:04:33 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h68NpLXs025115 for ; Tue, 8 Jul 2003 19:51:21 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h68NpQj04989; Tue, 8 Jul 2003 16:51:26 -0700 (PDT) Message-Id: <200307082351.h68NpQj04989@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-dir@ietf.org Subject: rtg-dir gettogether in Vienna: Sunday after reception Date: Tue, 8 Jul 2003 16:51:25 -0700 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Folks, If it's not too late, please save Sunday at 7pm for a routing directorate gettogether. The venue is yet to be determined; we will meet at the IETF message board to figure out where to go. I thought the meeting in the bar in Atlanta was much more productive than the restaurant in San Francisco; I don't know if that was because of the smaller turnout in Atlanta or the venue. In any case, hopefully the jetlag won't be too bad and we'll be able to have interesting discussions. Thanks, Bill From rtg-dir-admin@ietf.org Wed Jul 9 14:25:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12990 for ; Wed, 9 Jul 2003 14:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJci-0001Y2-00 for rtg-dir-archive@ietf.org; Wed, 09 Jul 2003 14:25:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aJci-0001Xy-00 for rtg-dir-archive@ietf.org; Wed, 09 Jul 2003 14:25:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJcj-00010e-17; Wed, 09 Jul 2003 14:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJcX-00010L-AT for rtg-dir@optimus.ietf.org; Wed, 09 Jul 2003 14:24: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 OAA12985 for ; Wed, 9 Jul 2003 14:24:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJcU-0001Xu-00 for rtg-dir@ietf.org; Wed, 09 Jul 2003 14:24:46 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19aJcT-0001Xi-00 for rtg-dir@ietf.org; Wed, 09 Jul 2003 14:24:45 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h69IO9iT019385; Wed, 9 Jul 2003 14:24:09 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h69IO50Z019378; Wed, 9 Jul 2003 14:24:05 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h69INxS27052; Wed, 9 Jul 2003 14:23:59 -0400 (EDT) Date: Wed, 9 Jul 2003 14:23:59 -0400 From: Jeffrey Haas To: Bill Fenner Cc: rtg-dir@ietf.org Subject: Re: rtg-dir gettogether in Vienna: Sunday after reception Message-ID: <20030709142359.A27001@nexthop.com> References: <200307082351.h68NpQj04989@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200307082351.h68NpQj04989@windsor.research.att.com>; from fenner@research.att.com on Tue, Jul 08, 2003 at 04:51:25PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Tue, Jul 08, 2003 at 04:51:25PM -0700, Bill Fenner wrote: > I thought the meeting in the bar > in Atlanta was much more productive than the restaurant in San Francisco; > I don't know if that was because of the smaller turnout in Atlanta or the > venue. Although I didn't make the Atlanta meeting, I'd suspect this was because its harder to carry out an unstructured conversation when you're trapped behind a table, even if the people immediately around you are well worth talking to about any number of topics. -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Wed Jul 9 14:45:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13674 for ; Wed, 9 Jul 2003 14:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJw4-0001jQ-00 for rtg-dir-archive@ietf.org; Wed, 09 Jul 2003 14:45:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aJw2-0001jN-00 for rtg-dir-archive@ietf.org; Wed, 09 Jul 2003 14:44:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJw5-0002SK-10; Wed, 09 Jul 2003 14:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJvF-0002Ol-E1 for rtg-dir@optimus.ietf.org; Wed, 09 Jul 2003 14:44: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 OAA13609 for ; Wed, 9 Jul 2003 14:44:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJvC-0001i1-00 for rtg-dir@ietf.org; Wed, 09 Jul 2003 14:44:06 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19aJv8-0001hD-00 for rtg-dir@ietf.org; Wed, 09 Jul 2003 14:44:04 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h69IhSmc020070; Wed, 9 Jul 2003 14:43:28 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h69IhO0Z020063; Wed, 9 Jul 2003 14:43:24 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h69IhJP27098; Wed, 9 Jul 2003 14:43:19 -0400 (EDT) Date: Wed, 9 Jul 2003 14:43:19 -0400 From: Jeffrey Haas To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: ops-dir input on routing protocol abuse Message-ID: <20030709144319.C27001@nexthop.com> References: <103737444749.20030708111055@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <103737444749.20030708111055@psg.com>; from zinin@psg.com on Tue, Jul 08, 2003 at 11:10:55AM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Tue, Jul 08, 2003 at 11:10:55AM -0700, Alex Zinin wrote: > FYI below. Quite consistent with what we've discussed. > I'll find some time today to summarize our discussion > on the rtg-dir list. What they said. :-) > 3. If the conclusion is that the BGP framework is a good fit for > these problems, the recommendation is to clearly separate > BGP as used today for Internet routing from the BGP framework > used for non-routing functions. This should be done by > instantiating a new protocol, that would inherit the BGP > functions most interesting for introduced functionality, yet > would have its own name, transport protocol ports, and would > explicitly not interoperate with what is known as BGP today. There is one gotcha here. The reason why BGP is so tempting, even after satisfying the other constraints is that it immediately addresses "how do I make inter-domain". The answer is, start with it that way. In almost all cases where some amount of needs to be inter-related with the inter-domain routing information, some hook, either opaque and implementation-specific, or part of a protocol extension will need to be done. The further apart in the protocols this is done, the more fussiness is needed to make an implementation do the work. This will always leave us walking the edge of a razor. -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Wed Jul 9 16:22:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20133 for ; Wed, 9 Jul 2003 16:22: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 19aLRw-00012K-SP; Wed, 09 Jul 2003 16:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLRO-00011f-Th for rtg-dir@optimus.ietf.org; Wed, 09 Jul 2003 16: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 QAA20076 for ; Wed, 9 Jul 2003 16:21:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLRN-0002wu-00 for rtg-dir@ietf.org; Wed, 09 Jul 2003 16:21:25 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19aLRM-0002wI-00 for rtg-dir@ietf.org; Wed, 09 Jul 2003 16:21:24 -0400 Received: from rcallon-lt.juniper.net (securepptp034.static.jnpr.net [172.24.253.34]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h69KKpu20750; Wed, 9 Jul 2003 13:20:51 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20030709161844.02d809e8@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 09 Jul 2003 16:20:54 -0400 To: Bill Fenner , rtg-dir@ietf.org From: Ross Callon Subject: Re: rtg-dir gettogether in Vienna: Sunday after reception In-Reply-To: <200307082351.h68NpQj04989@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , I intend to be there. I am arriving Saturday, so hopefully I will be marginally coherent by Sunday. Perhaps good beer is an essential part in having a productive discussion ;-). Does this mean that we should each have a bit to eat prior to the get-together, so that we only need beer and not additional food? thanks, Ross At 04:51 PM 7/8/2003 -0700, Bill Fenner wrote: >Folks, > > If it's not too late, please save Sunday at 7pm for a routing directorate >gettogether. The venue is yet to be determined; we will meet at the IETF >message board to figure out where to go. I thought the meeting in the bar >in Atlanta was much more productive than the restaurant in San Francisco; >I don't know if that was because of the smaller turnout in Atlanta or the >venue. In any case, hopefully the jetlag won't be too bad and we'll be >able to have interesting discussions. > >Thanks, > Bill From rtg-dir-admin@ietf.org Wed Jul 9 16:33:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20633 for ; Wed, 9 Jul 2003 16:33: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 19aLcb-0001Hu-6O; Wed, 09 Jul 2003 16: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 19aLc1-0001HO-Sx for rtg-dir@optimus.ietf.org; Wed, 09 Jul 2003 16:32: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 QAA20625 for ; Wed, 9 Jul 2003 16:32:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLc0-00035c-00 for rtg-dir@ietf.org; Wed, 09 Jul 2003 16:32:24 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19aLby-00035Z-00 for rtg-dir@ietf.org; Wed, 09 Jul 2003 16:32:23 -0400 Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h69KWGvc029511; Wed, 9 Jul 2003 14:32:17 -0600 (MDT) Received: from sr1-ubur-05 (sr1-ubur-05 [129.148.9.84]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with SMTP id h69KWGs07496; Wed, 9 Jul 2003 16:32:16 -0400 (EDT) Message-Id: <200307092032.h69KWGs07496@sydney.East.Sun.COM> Date: Wed, 9 Jul 2003 16:32:16 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: rtg-dir gettogether in Vienna: Sunday after reception To: rtg-dir@ietf.org, fenner@research.att.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4mtGbDKwU4YRpYtYYRmX7w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , The restaurant was not as productive because ordering and eating food and arranging checks was a distraction. The bar was OK, but we should try to find a place that isn't too noisy or smoky in order to have a good discussion. Radia From rtg-dir-admin@ietf.org Wed Jul 9 23:00:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03126 for ; Wed, 9 Jul 2003 23:00:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aRf7-0006NJ-00 for rtg-dir-archive@ietf.org; Wed, 09 Jul 2003 23:00:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aRf6-0006NE-00 for rtg-dir-archive@ietf.org; Wed, 09 Jul 2003 23:00:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aRf7-0005F0-CO; Wed, 09 Jul 2003 23:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aRf0-0005EI-Hn for rtg-dir@optimus.ietf.org; Wed, 09 Jul 2003 22:59: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 WAA03120 for ; Wed, 9 Jul 2003 22:59:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aRex-0006N5-00 for rtg-dir@ietf.org; Wed, 09 Jul 2003 22:59:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19aRew-0006N2-00 for rtg-dir@ietf.org; Wed, 09 Jul 2003 22:59:50 -0400 Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19aRew-0000d8-Kr; Thu, 10 Jul 2003 02:59:50 +0000 Date: Wed, 9 Jul 2003 19:59:12 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14634423448.20030709195912@psg.com> To: Jeffrey Haas CC: rtg-dir@ietf.org Subject: Re: ops-dir input on routing protocol abuse In-Reply-To: <20030709144319.C27001@nexthop.com> References: <103737444749.20030708111055@psg.com> <20030709144319.C27001@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff, >> 3. If the conclusion is that the BGP framework is a good fit for >> these problems, the recommendation is to clearly separate >> BGP as used today for Internet routing from the BGP framework >> used for non-routing functions. This should be done by >> instantiating a new protocol, that would inherit the BGP >> functions most interesting for introduced functionality, yet >> would have its own name, transport protocol ports, and would >> explicitly not interoperate with what is known as BGP today. > There is one gotcha here. > The reason why BGP is so tempting, even after satisfying the other > constraints is that it immediately addresses "how do I make > inter-domain". The answer is, start with it that way. Sorry, what do you mean in your last sentence? > In almost all cases where some amount of needs to be > inter-related with the inter-domain routing information, some > hook, either opaque and implementation-specific, or part of a > protocol extension will need to be done. The further apart in > the protocols this is done, the more fussiness is needed to make > an implementation do the work. > This will always leave us walking the edge of a razor. OK, I guess what I am hearing is one of the points that Mike Shand brought--about the potential need of synchronization between routing and non-routing info (TE, for example), in which case putting it all in the RP makes it much easier. Is this what you mean? Alex From rtg-dir-admin@ietf.org Thu Jul 10 02:59:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20219 for ; Thu, 10 Jul 2003 02:59:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aVPL-0007lx-00 for rtg-dir-archive@ietf.org; Thu, 10 Jul 2003 02:59:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aVPK-0007lu-00 for rtg-dir-archive@ietf.org; Thu, 10 Jul 2003 02:59:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aVPO-0004Yf-3D; Thu, 10 Jul 2003 03: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 19aVOS-0004WW-OH for rtg-dir@optimus.ietf.org; Thu, 10 Jul 2003 02:59: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 CAA20204 for ; Thu, 10 Jul 2003 02:58:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aVOO-0007lY-00 for rtg-dir@ietf.org; Thu, 10 Jul 2003 02:59:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19aVOO-0007lV-00 for rtg-dir@ietf.org; Thu, 10 Jul 2003 02:59:00 -0400 Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19aVOO-0008io-NE for rtg-dir@ietf.org; Thu, 10 Jul 2003 06:59:00 +0000 Date: Wed, 9 Jul 2003 23:57:16 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14548706736.20030709235716@psg.com> To: rtg-dir@ietf.org Subject: Summary on feedback to IESG on routing protocol overloading MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- Please find below the summary of the discussion we had. Pay specific attention to recommendations (bullets 4, 5, 6, and 8). Shout if I misrepresented something or you'd like to change some words, pls.--quite possible that I missed something, as it's late here. Alex On the question of appropriate and inappropriate use of routing protocols in general, and BGP in particular. 1. Routing protocols are generally designed with specific assumptions in mind about the amount of information that needs to be distributed, the frequency of its changes, and it's nature. These assumptions influence such characteristics of the routing protocols as required bandwidth, CPU utilization, convergence times, as well as the overall protocol scalability. 2. Hardware and software of the Internet routers have been carefully fine-tuned over the years to ensure adequate routing stability and convergence characteristics of the SP networks and the Internet as a whole. Particular care has been taken to minimize unnecessary routing protocol packet drops, high CPU utilization, excessive memory consumption, distributed instabilities (such as flooding storms.) 3. Routing protocols in general SHOULD NOT be treated as a general purpose reliable multicast transport system because of the following aspects: a) when used for an arbitrary application, the fundamental assumptions (see bullet 1 above) may not hold true any more, and the scalability of the protocol may be affected b) if implemented and deployed in a tightly-coupled fashion with the Internet routing system (sharing the same transport and protocol sessions, internal router infrastructure, databases, etc.), additional applications of the routing protocols may start competing for resources (see bullet 2 above) and thus affect behavior and scalability of the Internet routing system. While the right design choices may prevent undesired effects, it is hard to foresee all possible interactions, and so the probability of a failure is increased. 4. Generally, the decision on whether a particular type of information belongs in a routing protocol or not should be made on a case-by-case basis. However, it is considered appropriate to distribute the following types of it in the routing protocols: a) information required to calculate the routing tables b) route tagging, administrative, and policy-related information c) security-related information d) information closely related to routing, especially when synchronization with routing information is needed Note that even for the cases above, a careful analysis must be performed to show that the volume and frequency of the information will stay within reasonable bounds. 5. For non-routing-related applications, the onus probandi lies with the proposers to show: a) why the use of a routing protocol is appropriate (and by inference, why some other mechanism isn't), and b) why this use cannot break the routing protocol 6. If the framework used in a specific routing protocol is agreed to be a good fit for a non-routing application, and synchronization with the routing information is not an issue, it is recommended that potential interference with the Internet routing system is avoided by using a separate instance of the protocol (or, obviously, by instantiating a new protocol with a similar framework.) On whether the specific approaches described in the documents above represent an appropriate use of BGP: 7. From the purely encoding and dynamics perspective (not taking into considerations potential interactions with the Internet routing system), and from the perspective of the BGP's general framework, rather than it's being an IP routing protocol, the following comments apply: a) NLRI overloading is considered slightly (though only slightly) problematic. Specifically, appearance of the TLVs in the NLRI field does not match the original of separation of keying information (prefixes) and their parameters in BGP. However, it is understood that, in a way, TLVs formalize representation of key-bound information. A cleaner approach would be to provide a mechanism to encode prefix-specific parameters outside the NLRI field. b) Extended communities normally used for policy purposes are used to distribute membership information. Thus, misconfiguration of policy on extended communities may potentially be hazardous to the correct operation of a VPN c) RSN TLV. It is not clear how often the contents of this TLV found in the NLRI field would change, and hence wether it would cause excessive updates or not. d) The documents should clearly specify what information is present in the MP-NEXTHOP field and how it is used 8. However, the bigger concern is how introduction of this information in BGP would affect the Internet routing system. Steps described in bullet 5 above should be followed, and the VPN and BGP communities should consider separating the Internet routing BGP system from other, non-routing-related applications of the BGP framework (the VPN case included.) From rtg-dir-admin@ietf.org Thu Jul 10 08:37:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29082 for ; Thu, 10 Jul 2003 08:37:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aagS-0002J1-00 for rtg-dir-archive@ietf.org; Thu, 10 Jul 2003 08:38:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19aagS-0002Iy-00 for rtg-dir-archive@ietf.org; Thu, 10 Jul 2003 08:38:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aagS-0003p0-O2; Thu, 10 Jul 2003 08:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aafs-0003fQ-1p for rtg-dir@optimus.ietf.org; Thu, 10 Jul 2003 08:37: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 IAA29057 for ; Thu, 10 Jul 2003 08:37:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aafq-0002Ii-00 for rtg-dir@ietf.org; Thu, 10 Jul 2003 08:37:22 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19aafp-0002IO-00 for rtg-dir@ietf.org; Thu, 10 Jul 2003 08:37:21 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h6ACamxd046348 for rtg-dir@ietf.org; Thu, 10 Jul 2003 08:36:48 -0400 (EDT) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([65.247.36.233]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h6ACaZ0Z046322 for ; Thu, 10 Jul 2003 08:36:35 -0400 (EDT) (envelope-from shares@nexthop.com) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: rtg-dir gettogether in Vienna: Sunday after reception Date: Thu, 10 Jul 2003 08:36:30 -0400 Message-ID: Thread-Topic: rtg-dir gettogether in Vienna: Sunday after reception Thread-Index: AcNGV8eRCu2l9nI2QESrp/nUXhy+3QAFR5mg From: "Susan Hares" To: "Ross Callon" , "Bill Fenner" , X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Just the liquid.. ;-).. Sue -----Original Message----- From: Ross Callon [mailto:rcallon@juniper.net] Sent: Wednesday, July 09, 2003 4:21 PM To: Bill Fenner; rtg-dir@ietf.org Subject: Re: rtg-dir gettogether in Vienna: Sunday after reception I intend to be there. I am arriving Saturday, so hopefully I will be marginally coherent by Sunday.=20 Perhaps good beer is an essential part in having a productive discussion ;-). Does this mean that we should each have a=20 bit to eat prior to the get-together, so that we only need beer and not additional food?=20 thanks, Ross At 04:51 PM 7/8/2003 -0700, Bill Fenner wrote: >Folks, > > If it's not too late, please save Sunday at 7pm for a routing = directorate >gettogether. The venue is yet to be determined; we will meet at the = IETF >message board to figure out where to go. I thought the meeting in the = bar >in Atlanta was much more productive than the restaurant in San = Francisco; >I don't know if that was because of the smaller turnout in Atlanta or = the >venue. In any case, hopefully the jetlag won't be too bad and we'll be >able to have interesting discussions. > >Thanks, > Bill From rtg-dir-admin@ietf.org Thu Jul 10 09:33:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01388 for ; Thu, 10 Jul 2003 09:33:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19abYe-0002nC-00 for rtg-dir-archive@ietf.org; Thu, 10 Jul 2003 09:34:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19abYe-0002n9-00 for rtg-dir-archive@ietf.org; Thu, 10 Jul 2003 09:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abYf-00081H-Gb; Thu, 10 Jul 2003 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 19abYU-00080U-M5 for rtg-dir@optimus.ietf.org; Thu, 10 Jul 2003 09:33: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 JAA01380 for ; Thu, 10 Jul 2003 09:33:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19abYS-0002n0-00 for rtg-dir@ietf.org; Thu, 10 Jul 2003 09:33:48 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19abYR-0002mm-00 for rtg-dir@ietf.org; Thu, 10 Jul 2003 09:33:48 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h6ADXHYi047777 for rtg-dir@ietf.org; Thu, 10 Jul 2003 09:33:17 -0400 (EDT) (envelope-from shares@nexthop.com) Received: from mail.corp.nexthop.com ([65.247.36.233]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h6ADX70Z047752 for ; Thu, 10 Jul 2003 09:33:07 -0400 (EDT) (envelope-from shares@nexthop.com) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: Summary on feedback to IESG on routing protocol overloading Date: Thu, 10 Jul 2003 09:33:02 -0400 Message-ID: Thread-Topic: Summary on feedback to IESG on routing protocol overloading Thread-Index: AcNGsOdoGOnYfizgTUSUC6M95Jb57AANiKmw From: "Susan Hares" To: "Alex Zinin" , X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Alex: Is your context the public Internet? Does it extend to what people can do inside of a corporate infrastructure? I think your are trying to imply that information here, but it took me a few times to read this. 6. If the framework used in a specific routing protocol is agreed to be a good fit for a non-routing application, and synchronization with the routing information is not an issue, it is recommended that potential interference with the Internet routing system is avoided by using a separate instance of the protocol (or, obviously, by instantiating a new protocol with a similar framework.) Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Thursday, July 10, 2003 2:57 AM To: rtg-dir@ietf.org Subject: Summary on feedback to IESG on routing protocol overloading Folks- Please find below the summary of the discussion we had. Pay specific attention to recommendations (bullets 4, 5, 6, and 8). Shout if I misrepresented something or you'd like to change some words, pls.--quite possible that I missed something, as it's late here. Alex On the question of appropriate and inappropriate use of routing protocols in general, and BGP in particular. 1. Routing protocols are generally designed with specific assumptions in mind about the amount of information that needs to be distributed, the frequency of its changes, and it's nature. These assumptions influence such characteristics of the routing protocols as required bandwidth, CPU utilization, convergence times, as well as the overall protocol scalability. 2. Hardware and software of the Internet routers have been carefully fine-tuned over the years to ensure adequate routing stability and convergence characteristics of the SP networks and the Internet as a whole. Particular care has been taken to minimize unnecessary routing protocol packet drops, high CPU utilization, excessive memory consumption, distributed instabilities (such as flooding storms.) 3. Routing protocols in general SHOULD NOT be treated as a general purpose reliable multicast transport system because of the following aspects: a) when used for an arbitrary application, the fundamental assumptions (see bullet 1 above) may not hold true any more, and the scalability of the protocol may be affected b) if implemented and deployed in a tightly-coupled fashion with the Internet routing system (sharing the same transport and protocol sessions, internal router infrastructure, = databases, etc.), additional applications of the routing protocols may = start competing for resources (see bullet 2 above) and thus affect behavior and scalability of the Internet routing system. While the right design choices may prevent undesired effects, it is hard to foresee all possible interactions, and so the probability of a failure is increased. 4. Generally, the decision on whether a particular type of information belongs in a routing protocol or not should be made on a case-by-case basis. However, it is considered appropriate to distribute the following types of it in the routing protocols: a) information required to calculate the routing tables b) route tagging, administrative, and policy-related information c) security-related information d) information closely related to routing, especially when synchronization with routing information is needed Note that even for the cases above, a careful analysis must be performed to show that the volume and frequency of the information will stay within reasonable bounds. 5. For non-routing-related applications, the onus probandi lies with the proposers to show: a) why the use of a routing protocol is appropriate (and by inference, why some other mechanism isn't), and b) why this use cannot break the routing protocol 6. If the framework used in a specific routing protocol is agreed to be a good fit for a non-routing application, and synchronization with the routing information is not an issue, it is recommended that potential interference with the Internet routing system is avoided by using a separate instance of the protocol (or, obviously, by instantiating a new protocol with a similar framework.) On whether the specific approaches described in the documents above represent an appropriate use of BGP: 7. From the purely encoding and dynamics perspective (not taking into considerations potential interactions with the Internet routing system), and from the perspective of the BGP's general framework, rather than it's being an IP routing protocol, the following comments apply: a) NLRI overloading is considered slightly (though only slightly) problematic. Specifically, appearance of the TLVs in the NLRI field does not match the original of separation of keying information (prefixes) and their parameters in BGP. However, it is understood that, in a way, TLVs formalize representation of key-bound information. A cleaner approach would be to provide a mechanism to encode prefix-specific parameters outside the NLRI field. b) Extended communities normally used for policy purposes are used to distribute membership information. Thus, = misconfiguration of policy on extended communities may potentially be hazardous = to the correct operation of a VPN c) RSN TLV. It is not clear how often the contents of this TLV found in the NLRI field would change, and hence wether it would cause excessive updates or not. d) The documents should clearly specify what information is present in the MP-NEXTHOP field and how it is used 8. However, the bigger concern is how introduction of this information in BGP would affect the Internet routing system. Steps described in bullet 5 above should be followed, and the VPN and BGP communities should consider separating the Internet routing BGP system from other, non-routing-related applications of the BGP framework (the VPN case included.) From rtg-dir-admin@ietf.org Thu Jul 10 09:45:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01906 for ; Thu, 10 Jul 2003 09:45:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19abkG-0002wC-00 for rtg-dir-archive@ietf.org; Thu, 10 Jul 2003 09:46:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19abkF-0002w9-00 for rtg-dir-archive@ietf.org; Thu, 10 Jul 2003 09:45:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abkH-0000s6-5h; Thu, 10 Jul 2003 09:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abjm-0000rb-KO for rtg-dir@optimus.ietf.org; Thu, 10 Jul 2003 09:45: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 JAA01877 for ; Thu, 10 Jul 2003 09:45:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19abjk-0002vq-00 for rtg-dir@ietf.org; Thu, 10 Jul 2003 09:45:28 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19abjf-0002ve-00 for rtg-dir@ietf.org; Thu, 10 Jul 2003 09:45:23 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h6ADipgM047986; Thu, 10 Jul 2003 09:44:51 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h6ADil0Z047979; Thu, 10 Jul 2003 09:44:47 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h6ADhRu29806; Thu, 10 Jul 2003 09:43:27 -0400 (EDT) Date: Thu, 10 Jul 2003 09:43:27 -0400 From: Jeffrey Haas To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: ops-dir input on routing protocol abuse Message-ID: <20030710094327.A29733@nexthop.com> References: <103737444749.20030708111055@psg.com> <20030709144319.C27001@nexthop.com> <14634423448.20030709195912@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14634423448.20030709195912@psg.com>; from zinin@psg.com on Wed, Jul 09, 2003 at 07:59:12PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Wed, Jul 09, 2003 at 07:59:12PM -0700, Alex Zinin wrote: > > The reason why BGP is so tempting, even after satisfying the other > > constraints is that it immediately addresses "how do I make > > inter-domain". The answer is, start with it that way. > > Sorry, what do you mean in your last sentence? To clarify, if you are going to do on an inter-domain basis, use an inter-domain protocol. Currently, that means BGP. > OK, I guess what I am hearing is one of the points that Mike Shand > brought--about the potential need of synchronization between routing > and non-routing info (TE, for example), in which case putting it all > in the RP makes it much easier. Is this what you mean? Aside from changing "RP" to "BGP", basically yes. > Alex -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Thu Jul 10 09:57:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02344 for ; Thu, 10 Jul 2003 09:57:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19abvs-00035G-00 for rtg-dir-archive@ietf.org; Thu, 10 Jul 2003 09:58:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19abvr-00035D-00 for rtg-dir-archive@ietf.org; Thu, 10 Jul 2003 09:57:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19abvt-0001cK-3E; Thu, 10 Jul 2003 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 19abv0-0001bE-0E for rtg-dir@optimus.ietf.org; Thu, 10 Jul 2003 09:57: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 JAA02324 for ; Thu, 10 Jul 2003 09:57:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19abuy-00034v-00 for rtg-dir@ietf.org; Thu, 10 Jul 2003 09:57:04 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19abux-00034o-00 for rtg-dir@ietf.org; Thu, 10 Jul 2003 09:57:03 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h6ADuWg9048240; Thu, 10 Jul 2003 09:56:32 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h6ADuS0Z048233; Thu, 10 Jul 2003 09:56:28 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h6ADuMq29885; Thu, 10 Jul 2003 09:56:22 -0400 (EDT) Date: Thu, 10 Jul 2003 09:56:22 -0400 From: Jeffrey Haas To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: Summary on feedback to IESG on routing protocol overloading Message-ID: <20030710095622.B29733@nexthop.com> References: <14548706736.20030709235716@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14548706736.20030709235716@psg.com>; from zinin@psg.com on Wed, Jul 09, 2003 at 11:57:16PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Wed, Jul 09, 2003 at 11:57:16PM -0700, Alex Zinin wrote: > b) if implemented and deployed in a tightly-coupled fashion > with the Internet routing system (sharing the same transport > and protocol sessions, internal router infrastructure, databases, > etc.), additional applications of the routing protocols may start > competing for resources (see bullet 2 above) and thus affect > behavior and scalability of the Internet routing system. We should be careful of what we may step in here, in the sense of stepping in something in a farm yard. The concept of "tightly coupled" and "loosely coupled" is a somewhat arbitrary one in some respects. In a "loosely coupled" system, we now have the same resources that may be used and abused as a "tightly coupled" system, but with a somewhat clearer distinction between what information is meant for what part of the system. In the event of resource constraints, the ability to gracefully fail will depend on the implementation. The fact that in a "tightly coupled" system the same information may be tagged and sent in a single protocol (or similar mechanism) doesn't necessarily change the information or the graceful failure mechanisms. As a matter of fact, it *potentially* worsens some of them since information that is required to be in synch no longer has the tight coupling to ensure that it is. Thus my next point: > 6. If the framework used in a specific routing protocol is agreed to be > a good fit for a non-routing application, and synchronization with > the routing information is not an issue, it is recommended that > potential interference with the Internet routing system is avoided > by using a separate instance of the protocol (or, obviously, by > instantiating a new protocol with a similar framework.) We must also therefore avoid duplicating information. There is no sense in having two instances of something that looks like BGP, where one carries "Internet routing information" and the other carries "other information" and have that "other" carry another copy of the Internet routing table. Talk about scalability nightmare. IMO, we must therefore recommend another step in this path: Where information is meant to be coupled, a protocol mechanism should be proposed, generically, that allows for coupling of the information. Essentially, if we're going to go to the effort to "normalize" (in the database fashion) our information, we must provide keying and synchronization mechanisms between the protocols. In the case of BGP, this might be accomplished through a keying path attribute of some form. The question then becomes, is the operational and coding consequences of this worse than the original problem? -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Sun Jul 13 05:01:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04828 for ; Sun, 13 Jul 2003 05:01:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bck2-0000Lx-00 for rtg-dir-archive@ietf.org; Sun, 13 Jul 2003 05:01:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19bck2-0000Lt-00 for rtg-dir-archive@ietf.org; Sun, 13 Jul 2003 05:01:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bck4-00081q-6y; Sun, 13 Jul 2003 05:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bcjx-00081Y-1o for rtg-dir@optimus.ietf.org; Sun, 13 Jul 2003 05:01: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 FAA04811 for ; Sun, 13 Jul 2003 05:01:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bcju-0000Ld-00 for rtg-dir@ietf.org; Sun, 13 Jul 2003 05:01:50 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19bcjt-0000LX-00 for rtg-dir@ietf.org; Sun, 13 Jul 2003 05:01:49 -0400 Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19bcjt-000OSG-3i; Sun, 13 Jul 2003 09:01:49 +0000 Date: Sun, 13 Jul 2003 03:47:51 +0200 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <198108459366.20030713034751@psg.com> To: Jeffrey Haas CC: rtg-dir@ietf.org Subject: Re: Summary on feedback to IESG on routing protocol overloading In-Reply-To: <20030710095622.B29733@nexthop.com> References: <14548706736.20030709235716@psg.com> <20030710095622.B29733@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jeff- We seem to agree that for the cases where the "application" information is meant to be in sync with the routing info, putting it in the routing protocol may be the right way to go, given that all other conditions are satisfied, of course. See below regarding coupling. >> b) if implemented and deployed in a tightly-coupled fashion >> with the Internet routing system (sharing the same transport >> and protocol sessions, internal router infrastructure, databases, >> etc.), additional applications of the routing protocols may start >> competing for resources (see bullet 2 above) and thus affect >> behavior and scalability of the Internet routing system. > We should be careful of what we may step in here, in the sense of > stepping in something in a farm yard. The concept of "tightly > coupled" and "loosely coupled" is a somewhat arbitrary one in some > respects. agreed > In a "loosely coupled" system, we now have the same resources that may > be used and abused as a "tightly coupled" system, but with a somewhat > clearer distinction between what information is meant for what part > of the system. I think we should agree on the term "tightly coupled" within the context of this discussion first. To me, tightly coupled means using the same protocol, port, transport sessions, queues, databases, threads, walkers, etc. So, if, for instance, the new BGP application experiences a lot of activity, there is a potential that it will compete for resources with the original BGP process. If this happens at a large scale (multiple routers), the results could be interesting. The positive side of using a different protocol (even with the same machinery) is that the separation of those resources is more likely to happen. Specifically, the protocol instance is likely to be implemented as a different thread/process with it's own resources such as memory pools, queues, timers, sockets, etc. So, while a complete decoupling is hardly achievable while the two process are running on the same system, the risk of interference should be lower. > In the event of resource constraints, the ability > to gracefully fail will depend on the implementation. > The fact that in a "tightly coupled" system the same information may > be tagged and sent in a single protocol (or similar mechanism) > doesn't necessarily change the information or the graceful failure > mechanisms. As a matter of fact, it *potentially* worsens some of > them since information that is required to be in synch no longer > has the tight coupling to ensure that it is. Thus my next point: Did you mean the second sentence to talk about loosely coupled rather than tightly coupled system? If not, then you lost me here. BTW, could you suggest changes to the text, please? Alex >> 6. If the framework used in a specific routing protocol is agreed to be >> a good fit for a non-routing application, and synchronization with >> the routing information is not an issue, it is recommended that >> potential interference with the Internet routing system is avoided >> by using a separate instance of the protocol (or, obviously, by >> instantiating a new protocol with a similar framework.) > We must also therefore avoid duplicating information. There is no > sense in having two instances of something that looks like BGP, where > one carries "Internet routing information" and the other carries > "other information" and have that "other" carry another copy of the > Internet routing table. > Talk about scalability nightmare. > IMO, we must therefore recommend another step in this path: > Where information is meant to be coupled, a protocol mechanism should > be proposed, generically, that allows for coupling of the information. > Essentially, if we're going to go to the effort to "normalize" (in > the database fashion) our information, we must provide keying and > synchronization mechanisms between the protocols. > In the case of BGP, this might be accomplished through a keying > path attribute of some form. > The question then becomes, is the operational and coding consequences > of this worse than the original problem? From mailman-admin@ietf.org Fri Aug 1 09:01:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09428 for ; Fri, 1 Aug 2003 09:01: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 19iZX6-00014T-He for rtg-dir-archive@ietf.org; Fri, 01 Aug 2003 09:01:20 -0400 Date: Fri, 01 Aug 2003 09:01:20 -0400 Message-ID: <20030801130120.29120.4023.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rtg-dir-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rtg-dir-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rtg-dir-archive@ietf.org: List Password // URL ---- -------- rtg-dir@ietf.org utnefe https://www1.ietf.org/mailman/options/rtg-dir/rtg-dir-archive%40ietf.org From rtg-dir-admin@ietf.org Mon Aug 4 15:31:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10048 for ; Mon, 4 Aug 2003 15:31:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jl3p-0005C7-00 for rtg-dir-archive@ietf.org; Mon, 04 Aug 2003 15:32:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jl3o-0005C3-00 for rtg-dir-archive@ietf.org; Mon, 04 Aug 2003 15:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jl3p-0002pZ-9n; Mon, 04 Aug 2003 15:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jl3h-0002pO-7w for rtg-dir@optimus.ietf.org; Mon, 04 Aug 2003 15:31:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10043 for ; Mon, 4 Aug 2003 15:31:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jl3g-0005C0-00 for rtg-dir@ietf.org; Mon, 04 Aug 2003 15:31:52 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19jl3f-0005Bw-00 for rtg-dir@ietf.org; Mon, 04 Aug 2003 15:31:51 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19jl3d-0004K6-Qm for rtg-dir@ietf.org; Mon, 04 Aug 2003 19:31:49 +0000 Date: Mon, 4 Aug 2003 12:30:10 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <7319025567.20030804123010@psg.com> To: rtg-dir@ietf.org Subject: rtg-dir += dward; rtg-dir += danny; MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI, Dave Ward and Danny McPherson have just been added to the directorate. Welcome Dave and Danny! Alex From rtg-dir-admin@ietf.org Mon Aug 4 15:33:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10087 for ; Mon, 4 Aug 2003 15:33:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jl5k-0005D6-00 for rtg-dir-archive@ietf.org; Mon, 04 Aug 2003 15:34:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jl5k-0005D3-00 for rtg-dir-archive@ietf.org; Mon, 04 Aug 2003 15:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jl5l-0002rs-2H; Mon, 04 Aug 2003 15: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 19jl5M-0002rN-Hp for rtg-dir@optimus.ietf.org; Mon, 04 Aug 2003 15:33:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10080 for ; Mon, 4 Aug 2003 15:33:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jl5L-0005Cs-00 for rtg-dir@ietf.org; Mon, 04 Aug 2003 15:33:35 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19jl5K-0005Cp-00 for rtg-dir@ietf.org; Mon, 04 Aug 2003 15:33:34 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19jl5K-0004P0-3E for rtg-dir@ietf.org; Mon, 04 Aug 2003 19:33:34 +0000 Date: Mon, 4 Aug 2003 12:31:54 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <13419129767.20030804123154@psg.com> To: rtg-dir@ietf.org Subject: Documents under IESG consideration for Aug 7, 2003 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI below. As usual, if you have a show-stopper comment--shout, pls. -- Alex http://www.psg.com/~zinin/ > 2. Protocol Actions > > 2.1 WG Submissions > 2.1.1 New Item > o draft-ietf-pkix-wlan-extns-04.txt > Certificate Extensions and Attributes Supporting Authentication in PPP > and Wireless LAN (Proposed Standard) > Token: Steve Bellovin > o draft-ietf-impp-im-03.txt > Common Profile for Instant Messaging (CPIM) (Proposed Standard) > Token: Hardie, Ted > - draft-ietf-impp-cpim-msgfmt-08.txt > Common Presence and Instant Messaging: Message Format (Proposed > Standard) > - draft-ietf-impp-cpim-pidf-08.txt > Presence Information Data Format (PIDF) (Proposed Standard) > - draft-ietf-impp-pres-03.txt > Common Profile for Presence (CPP) (Proposed Standard) > - draft-ietf-impp-srv-03.txt > Address Resolution for Instant Messaging and Presence (Proposed > Standard) > o draft-ietf-dhc-isnsoption-08.txt > The IPv4 DHCP Options for the Internet Storage Name Service (Proposed > Standard) > Token: Thomas Narten > Note: Title says "options" rather than "option" but otherwise ready. > o draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt > IPv6 Prefix Options for DHCPv6 (Proposed Standard) > Token: Thomas Narten > o draft-ietf-secsh-dns-04.txt > Using DNS to securely publish SSH key fingerprints (Proposed Standard) > Token: Housley, Russ > o draft-ietf-ipsec-ciph-aes-ctr-05.txt > Using AES Counter Mode With IPsec ESP (Proposed Standard) > Token: Steve Bellovin > o draft-ietf-smime-camellia-04.txt > Use of the Camellia Encryption Algorithm in CMS (Proposed Standard) > Token: Housley, Russ > o draft-ietf-ipv6-flow-label-07.txt > IPv6 Flow Label Specification (Proposed Standard) > Token: Thomas Narten > o draft-schryver-pppext-iana-01.txt > IANA Considerations for the Point-to-Point Protocol (PPP) (BCP) > Token: Thomas Narten > Note: I have some nits that will need cleaning up before IESG approval, > but document seems fine overall. > > 2.1.2 Returning Item > o draft-ietf-policy-qos-device-info-model-10.txt > Information Model for Describing Network Device QoS Datapath Mechanisms > (Proposed Standard) > Token: Bert Wijnen > Note: Returning document to IESG agenda. Allison still has a DISCUSS to > be documented. Responsible: Bert > o draft-ietf-policy-qos-info-model-05.txt > Policy QoS Information Model (Proposed Standard) > Token: Bert Wijnen > Note: Returning this to IESG telechat This to force resolution of a > DEFER and a DISCUSS. Responsible: Bert Wijnen > o draft-ietf-kink-kink-05.txt > Kerberized Internet Negotiation of Keys (KINK) (Proposed Standard) > Token: Bellovin, Steve > > > 2.2 Individual Submissions > 2.2.1 New Item > NONE > 2.2.2 Returning Item > o draft-mealling-iana-xmlns-registry-05.txt > The IETF XML Registry (BCP) > Token: Ted Hardie > o draft-zeilenga-ldap-collective-08.txt > Collective Attributes in LDAP (Proposed Standard) > Token: Ted Hardie > Note: New versions exists which is verified with IESG Responsible: > Patrik > - draft-zeilenga-ldap-subentry-07.txt > Subentries in LDAP (Proposed Standard) > - draft-legg-ldap-gser-abnf-07.txt > Common Elements of GSER Encodings (Informational) > - draft-legg-ldap-gser-04.txt > Generic String Encoding Rules for ASN.1 Types (Proposed Standard) > o draft-yergeau-rfc2279bis-05.txt > UTF-8, a transformation format of ISO 10646 (Standard) > Token: Ted Hardie > > > > 3. Document Actions > > 3.1 WG Submissions > 3.1.1 New Item > o draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt > An analysis of IPv6 anycast (Informational) > Token: Nordmark, Erik > Note: Ready for IESG agenda > o draft-ietf-ieprep-ets-general-03.txt > General Requirements for Emergency Telecommunication Service > (Informational) > Token: Jon Peterson > o draft-ietf-xmldsig-xpf2-00.txt > XML-Signature XPath Filter 2.0 (Informational) > Token: Housley, Russ > o draft-ietf-dhc-unused-optioncodes-05.txt > Unused DHCP Option Codes (Informational) > Token: Thomas Narten > Note: 2003-06-24: sent comments to list (mainly nits). > > 3.1.2 Returning Item > o draft-ietf-xmldsig-xc14n-01.txt > Exclusive XML Canonicalization, Version 1.0 (Informational) > Token: Housley, Russ > o draft-ietf-pkix-pr-tsa-04.txt > Policy Requirements for Time-Stamping Authorities (Informational) > Token: Housley, Russ > > > 3.2 Indiviual Submissions Via AD > 3.2.1 New Item > o draft-fink-6bone-phaseout-04.txt > 6bone (IPv6 Testing Address Allocation) Phaseout (Informational) > Token: Bush, Randy > > 3.2.2 Returning Item > NONE > > 3.3 Indiviual Submissions Via RFC Editor > 3.3.1 New Item > NONE > 3.3.2 Returning Item > o draft-shah-extreme-eaps-03.txt > Extreme Networks'Ethernet Automatic Protection Switching (EAPS), > Version 1 (Informational) > Token: Thomas Narten > Note: Note to IESG: Checked with IEEE and they don't have a problem > with this document. From rtg-dir-admin@ietf.org Mon Aug 4 18:29:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14603 for ; Mon, 4 Aug 2003 18:29:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jnq3-00064c-00 for rtg-dir-archive@ietf.org; Mon, 04 Aug 2003 18:30:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jnq3-00064Z-00 for rtg-dir-archive@ietf.org; Mon, 04 Aug 2003 18:29:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jnq5-0007kM-L0; Mon, 04 Aug 2003 18:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jnpn-0007js-Rh for rtg-dir@optimus.ietf.org; Mon, 04 Aug 2003 18:29:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14599 for ; Mon, 4 Aug 2003 18:29:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jnpk-00064T-00 for rtg-dir@ietf.org; Mon, 04 Aug 2003 18:29:40 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19jnpk-00064H-00 for rtg-dir@ietf.org; Mon, 04 Aug 2003 18:29:40 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h74MTAaU044251; Mon, 4 Aug 2003 18:29:10 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h74MT3Lu044230; Mon, 4 Aug 2003 18:29:03 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h74MSwm05691; Mon, 4 Aug 2003 18:28:58 -0400 (EDT) Date: Mon, 4 Aug 2003 18:28:58 -0400 From: Jeffrey Haas To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: rtg-dir += dward; rtg-dir += danny; Message-ID: <20030804182858.A5680@nexthop.com> References: <7319025567.20030804123010@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7319025567.20030804123010@psg.com>; from zinin@psg.com on Mon, Aug 04, 2003 at 12:30:10PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , About time. :-) On Mon, Aug 04, 2003 at 12:30:10PM -0700, Alex Zinin wrote: > > FYI, Dave Ward and Danny McPherson have just been > added to the directorate. > > Welcome Dave and Danny! -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Tue Aug 5 18:11:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01073 for ; Tue, 5 Aug 2003 18:11:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kA2C-0006KN-00 for rtg-dir-archive@ietf.org; Tue, 05 Aug 2003 18:12:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kA2B-0006KJ-00 for rtg-dir-archive@ietf.org; Tue, 05 Aug 2003 18:11:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kA2D-0002nW-Hy; Tue, 05 Aug 2003 18:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kA2B-0002nE-Lw for rtg-dir@optimus.ietf.org; Tue, 05 Aug 2003 18:11: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 SAA01062 for ; Tue, 5 Aug 2003 18:11:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kA28-0006KG-00 for rtg-dir@ietf.org; Tue, 05 Aug 2003 18:11:56 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kA27-0006KC-00 for rtg-dir@ietf.org; Tue, 05 Aug 2003 18:11:56 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kA26-0009MR-3o for rtg-dir@ietf.org; Tue, 05 Aug 2003 22:11:54 +0000 Date: Tue, 5 Aug 2003 15:11:46 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <18115122166.20030805151146@psg.com> To: rtg-dir@ietf.org Subject: Under IESG review: draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This one is routing-related. Please take a look and send commends by tomorrow night. Token holders: Rohit, Sue. -- Alex From rtg-dir-admin@ietf.org Tue Aug 5 18:46:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02170 for ; Tue, 5 Aug 2003 18:46:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kAa3-0006St-00 for rtg-dir-archive@ietf.org; Tue, 05 Aug 2003 18:46:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kAa3-0006Sq-00 for rtg-dir-archive@ietf.org; Tue, 05 Aug 2003 18:46:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kAa5-0003lg-8i; Tue, 05 Aug 2003 18: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 19kAa1-0003lV-S9 for rtg-dir@optimus.ietf.org; Tue, 05 Aug 2003 18:46: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 SAA02167 for ; Tue, 5 Aug 2003 18:46:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kAZy-0006Sn-00 for rtg-dir@ietf.org; Tue, 05 Aug 2003 18:46:54 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kAZy-0006Sk-00 for rtg-dir@ietf.org; Tue, 05 Aug 2003 18:46:54 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kAZy-000Ay4-MV for rtg-dir@ietf.org; Tue, 05 Aug 2003 22:46:54 +0000 Date: Tue, 5 Aug 2003 15:46:45 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <111117221395.20030805154645@psg.com> To: rtg-dir@ietf.org Subject: Under IESG review: draft-ietf-ipv6-flow-label-07.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This one needs a look too. I thought we concluded that IntServ doesn't scale, and the doc talks about per-flow processing at transit IPv6 nodes... Token holder: Ross Please send comments by Wed night. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Tue Aug 5 19:00:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02448 for ; Tue, 5 Aug 2003 19:00:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kAnb-0006Xx-00 for rtg-dir-archive@ietf.org; Tue, 05 Aug 2003 19:00:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kAna-0006Xu-00 for rtg-dir-archive@ietf.org; Tue, 05 Aug 2003 19:00:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kAnd-00044H-7t; Tue, 05 Aug 2003 19:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kAnB-000436-6c for rtg-dir@optimus.ietf.org; Tue, 05 Aug 2003 19:00: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 TAA02440 for ; Tue, 5 Aug 2003 19:00:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kAn8-0006Xm-00 for rtg-dir@ietf.org; Tue, 05 Aug 2003 19:00:30 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kAn7-0006Xj-00 for rtg-dir@ietf.org; Tue, 05 Aug 2003 19:00:29 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kAn7-000Bix-Ml for rtg-dir@ietf.org; Tue, 05 Aug 2003 23:00:29 +0000 Date: Tue, 5 Aug 2003 16:00:20 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <89118035906.20030805160020@psg.com> To: rtg-dir@ietf.org Subject: Under IESG review: draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please sanity check this one. Token holders: dmm, chopps -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Wed Aug 6 13:51:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26704 for ; Wed, 6 Aug 2003 13:51:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSRB-0005Ac-00 for rtg-dir-archive@ietf.org; Wed, 06 Aug 2003 13:51:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kSRA-0005AZ-00 for rtg-dir-archive@ietf.org; Wed, 06 Aug 2003 13:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSRC-0000uf-46; Wed, 06 Aug 2003 13: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 19kSR1-0000tx-2T for rtg-dir@optimus.ietf.org; Wed, 06 Aug 2003 13:50: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 NAA26697 for ; Wed, 6 Aug 2003 13:50:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSQy-0005AJ-00 for rtg-dir@ietf.org; Wed, 06 Aug 2003 13:50:48 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19kSQx-00059x-00 for rtg-dir@ietf.org; Wed, 06 Aug 2003 13:50:47 -0400 Received: from rcallon-lt.juniper.net (rcallon-lt.jnpr.net [10.10.132.99]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h76HoEu73539; Wed, 6 Aug 2003 10:50:14 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20030806112008.0327f4c0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 06 Aug 2003 13:50:07 -0400 To: Alex Zinin From: Ross Callon Subject: My Opinion: Re: Under IESG review: draft-ietf-ipv6-flow-label-07.txt Cc: rtg-dir@ietf.org, rcallon@juniper.net In-Reply-To: <111117221395.20030805154645@psg.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_13200651==_.ALT" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --=====================_13200651==_.ALT Content-Type: text/plain; charset="us-ascii" At 03:46 PM 8/5/2003 -0700, Alex Zinin wrote: >This one needs a look too. I thought we concluded that IntServ >doesn't scale, and the doc talks about per-flow processing at >transit IPv6 nodes... > >Token holder: Ross >Please send comments by Wed night. > >-- >Alex >http://www.psg.com/~zinin/ General Comments It seems to me that the flow label has a purpose, and two possible uses. To me the document seems to be not totally clear or perhaps even wrong regarding which of the uses is the main one. The purpose is to identify flows. For example, this allows the flow to be identified using only fields which are in fixed positions in the IPv6 Header. This purpose seems to me to be well defined in the document. Now that you have an indicator regarding what flow a particular packet belongs to, what use would you have for this information? One possible use is for hashing packets, for example to spread traffic across equal cost multi-paths without re-ordering packets from any one flow. This seems like a pretty straightforward and sensible use, which requires close to zero change to the Internet architecture, and which is briefly mentioned in the document. The other possible use is for an explicit flow set up procedure. However, since the flow are per-{source-address; destination-address; flow field} triplet, it would seem that this won't scale much better than the current int-serve specification. Thus it is not clear whether this will end up being useful in practice. At best I would call this experimental. In some places in the document it appears that the flow field is for the purpose of identifying flows, and that either of the two uses might be sensible reasons that you might want to identify flows. In other places in the document it looks like the second purpose (which to me seems the more speculative) is the reason for the flow field. I think that it would make sense to clearly separate these. More specific comments >> Section 1: First three paragraphs do a good job of defining the purpose of the flow ID (to allow efficient flow classification based only on fields in the fixed part of the IPv6 header). Fourth paragraph, first sentence: The minimum level of IPv6 flow support consists of labeling the flows. In a sense this is reasonable, but I am not sure precisely what it means. Does this mean: In order to be an IPv6 conformant node, IPv6 source nodes MUST be able to label outgoing flows. or does this mean: In order to claim conformance to the IPv6 flow label specification, IPv6 source nodes MUST support labeling outgoing flows. Or does this mean something else? >> Sections 2 and 3. This seems reasonable, and again defines the purpose of the flow label in a reasonable way, as well as defining some very reasonable requirements, for example specifying how a source should set the flow value. >> Proposed New Section Between section 3 and 4: It seems to me that the most obviously worthwhile of the potential uses of the flow label field is to allow routers to split traffic on multiple paths (for example, for load sharing and traffic engineering purposes), without having to look past the IPv6 header. One example of where this might be very useful is in the case of encapsulation, for example over IPsec over IPv6 or over GRE over IPv6 encapsulations. In this case there might be a potentially very large number of high layer flows which will be encapsulated with the same IPv6 source and destination addresses in the outer IPv6 header. If you can hash only on the outer IPv6 addresses, then you could get a lot of traffic which is forced to take the same path. If you allow a finer grain flow label to be placed in the flow label field, then you can get a much more even distribution of traffic across, for example, equal cost multi-paths. I think that it is worth having a section on this possibility. I don't think that this requires all that much text. There is one question which I have, which could be cleared up in such a section: Specifically, the second sentence of section 2 states: A Flow Label of zero is used to indicate packets not part of any flow. Suppose that I am an IPv6 router which is hashing on source address, destination address, and flow label, and I am using the hash to split traffic among several paths. If I see a packet with a flow label of zero, which of the following do I assume: - the node does not implement any flow labelling ability, and therefore I must hash only on source and destination address. - the node does implement flow labelling, and is telling me that the packet is not part of any flow, and can therefore be forwarded on any path without regard for re-ordering. If we assume the latter, then implementation of the flow labelling capability must be supported by all IPv6 source nodes (at least to the point of sticking a non-zero value in the flow field), since otherwise their packets might be re-ordered by nodes which assume that their packets are not part of any flow. I would suggest using zero to indicate that flow labelling is not supported (and thus routers better keep the packets in order based only on source and destination addresses). If we also want to indicate that some packets are not part of a flow, we might give them a random value, or a different special value. >> Section 4: The flow state establishment requirements in section 4 seem to be very much incomplete. If there were a complete set of flow state establishment requirements, then I think that the requirements specified in this section are reasonable ones, and would be included in the set. However, the two requirements specified in section 4 seem to be such a small subset of the complete set of requirements that I don't see why it is worth listing them at all. I think that it would be cleaner just to say that methods and requirements for explicit flow establishment are outside of the scope of this document. Naturally if section 4 were removed, then the last phrase of the first paragraph of the abstract would also need to be removed (page 1, phrase "and the requirements for flow state establishment methods"). Similarly the second to last paragraph of section 1 would need to be abbreviated. >>Section 5: First paragraph, last sentence: Even if the flow label were encrypted, its presence as a constant value in a fixed position might assist traffic analysis and cryptoanalysis. The flow label is supposed to be unstructured -- in the sense that if I am not the source node, then I don't know anything about how the source set the label, except that a different value means a different flow. As such, I don't understand what encryption would do to change the interpretation of a flow label. If two labels were encrypted to the same exact value, then it would seem clear that they can't be un-encrypted back to different values. If two flow labels were encrypted to different values, then as a node in the middle observing the packets going by I don't detect any difference. Section 5.1, second paragraph (top of page 5), first sentence: Note that there is no guarantee that flow labels sent by a node are not set in any manner that the node wants to, such as reusing flow labels, against the recommendations in this document. This seems to be a rather awkward sentence, and should probably be re-written. Additional Topic: Somewhere in the security section (probably in a new subsection at the end) it might be worth mentioning that in those locations where a firewall or filtering router is employed which looks past the IP header to higher level headers, the flow label does nothing to eliminate the need to continue to look at the higher headers. Ross --=====================_13200651==_.ALT Content-Type: text/html; charset="us-ascii" At 03:46 PM 8/5/2003 -0700, Alex Zinin wrote:
This one needs a look too. I thought we concluded that IntServ
doesn't scale, and the doc talks about per-flow processing at
transit IPv6 nodes...

Token holder: Ross
Please send comments by Wed night.

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

General Comments

It seems to me that the flow label has a purpose, and two possible
uses. To me the document seems to be not totally clear or perhaps
even wrong regarding which of the uses is the main one.

The purpose is to identify flows. For example, this allows the flow to
be identified using only fields which are in fixed positions in the IPv6
Header. This purpose seems to me to be well defined in the document.

Now that you have an indicator regarding what flow a particular packet
belongs to, what use would you have for this information?

One possible use is for hashing packets, for example to spread traffic
across equal cost multi-paths without re-ordering packets from any one
flow. This seems like a pretty straightforward and sensible use, which
requires close to zero change to the Internet architecture, and which
is briefly mentioned in the document.

The other possible use is for an explicit flow set up procedure. However,
since the flow are per-{source-address; destination-address; flow field}
triplet, it would seem that this won't scale much better than the current
int-serve specification. Thus it is not clear whether this will end up being
useful in practice. At best I would call this experimental.

In some places in the document it appears that the flow field is for the
purpose of identifying flows, and that either of the two uses might be
sensible reasons that you might want to identify flows. In other places
in the document it looks like the second purpose (which to me seems
the more speculative) is the reason for the flow field.

I think that it would make sense to clearly separate these.

More specific comments
>> Section 1:

First three paragraphs do a good job of defining the purpose of the
flow ID (to allow efficient flow classification based only on fields in
the fixed part of the IPv6 header).

Fourth paragraph, first sentence:
        The minimum level of IPv6 flow support consists
        of labeling the flows.

In a sense this is reasonable, but I am not sure precisely what it means.
Does this mean:

        In order to be an IPv6 conformant node, IPv6 source
        nodes MUST be able to label outgoing flows.

or does this mean:

        In order to claim conformance to the IPv6 flow
        label specification, IPv6 source nodes MUST support
        labeling outgoing flows.

Or does this mean something else?

>> Sections 2 and 3.

This seems reasonable, and again defines the purpose of the
flow label in a reasonable way, as well as defining some very
reasonable requirements, for example specifying how a source
should set the flow value.

>> Proposed New Section Between section 3 and 4:

It seems to me that the most obviously worthwhile of the
potential uses of the flow label field is to allow routers to split
traffic on multiple paths (for example, for load sharing and traffic
engineering purposes), without having to look past the IPv6
header.

One example of where this might be very useful is in the case
of encapsulation, for example <anything> over IPsec over IPv6
or <anything> over GRE over IPv6 encapsulations. In this case
there might be a potentially very large number of high layer flows
which will be encapsulated with the same IPv6 source and
destination addresses in the outer IPv6 header. If you can hash
only on the outer IPv6 addresses, then you could get a lot of
traffic which is forced to take the same path. If you allow a finer
grain flow label to be placed in the flow label field, then you can
get a much more even distribution of traffic across, for example,
equal cost multi-paths.

I think that it is worth having a section on this possibility. I don't
think that this requires all that much text.

There is one question which I have, which could be cleared up
in such a section: Specifically, the second sentence of section
2 states:

        A Flow Label of zero is used to indicate packets
        not part of any flow.

Suppose that I am an IPv6 router which is hashing on source
address, destination address, and flow label, and I am using
the hash to split traffic among several paths.

If I see a packet with a flow label of zero, which of the following do
I assume:

        - the node does not implement any flow labelling ability, and
          therefore I must hash only on source and destination address.

        - the node does implement flow labelling, and is telling me
          that the packet is not part of any flow, and can therefore be
          forwarded on any path without regard for re-ordering.

If we assume the latter, then implementation of the flow labelling
capability must be supported by all IPv6 source nodes (at least
to the point of sticking a non-zero value in the flow field), since
otherwise their packets might be re-ordered by nodes which
assume that their packets are not part of any flow.

I would suggest using zero to indicate that flow labelling is not
supported (and thus routers better keep the packets in order
based only on source and destination addresses). If we also
want to indicate that some packets are not part of a flow, we
might give them a random value, or a different special value.

>> Section 4:

The flow state establishment requirements in section 4 seem to be
very much incomplete. If there were a complete set of flow state
establishment requirements, then I think that the requirements
specified in this section are reasonable ones, and would be
included in the set. However, the two requirements specified in
section 4 seem to be such a small subset of the complete set of
requirements that I don't see why it is worth listing them at all. I
think that it would be cleaner just to say that methods and
requirements for explicit flow establishment are outside of the
scope of this document.

Naturally if section 4 were removed, then the last phrase of the
first paragraph of the abstract would also need to be removed
(page 1, phrase "and the requirements for flow state establishment
methods"). Similarly the second to last paragraph of section 1
would need to be abbreviated.

>>Section 5:

First paragraph, last sentence:

        Even if the flow label were encrypted, its presence
        as a constant value in a fixed position might assist
        traffic analysis and cryptoanalysis.

The flow label is supposed to be unstructured -- in the sense that if
I am not the source node, then I don't know anything about how the source
set the label, except that a different value means a different flow. As such,
I don't understand what encryption would do to change the interpretation of
a flow label. If two labels were encrypted to the same exact value, then it
would seem clear that they can't be un-encrypted back to different values.
If two flow labels were encrypted to different values, then as a node in the
middle observing the packets going by I don't detect any difference.

Section 5.1, second paragraph (top of page 5), first sentence:

        Note that there is no guarantee that flow labels sent by a node are
        not set in any manner that the node wants to, such as reusing flow
        labels, against the recommendations in this document.

This seems to be a rather awkward sentence, and should probably
be re-written.

Additional Topic: Somewhere in the security section (probably in a new
subsection at the end) it might be worth mentioning that in those locations
where a firewall or filtering router is employed which looks past the IP
header to higher level headers, the flow label does nothing to eliminate the
need to continue to look at the higher headers.

Ross --=====================_13200651==_.ALT-- From rtg-dir-admin@ietf.org Wed Aug 6 15:53:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02346 for ; Wed, 6 Aug 2003 15:53:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kUMC-0006Pk-00 for rtg-dir-archive@ietf.org; Wed, 06 Aug 2003 15:54:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kUMC-0006Ph-00 for rtg-dir-archive@ietf.org; Wed, 06 Aug 2003 15:54:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kUMD-0006s0-2U; Wed, 06 Aug 2003 15: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 19kUM4-0006rW-7L for rtg-dir@optimus.ietf.org; Wed, 06 Aug 2003 15: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 PAA02326 for ; Wed, 6 Aug 2003 15:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kUM2-0006PP-00 for rtg-dir@ietf.org; Wed, 06 Aug 2003 15:53:50 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kUM0-0006PD-00 for rtg-dir@ietf.org; Wed, 06 Aug 2003 15:53:48 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kULW-0002lM-1z; Wed, 06 Aug 2003 19:53:18 +0000 Date: Wed, 6 Aug 2003 12:50:19 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <47193035260.20030806125019@psg.com> To: Ross Callon CC: rtg-dir@ietf.org Subject: Re: My Opinion: Re: Under IESG review: draft-ietf-ipv6-flow-label-07.txt In-Reply-To: <4.3.2.20030806112008.0327f4c0@zircon.juniper.net> References: <4.3.2.20030806112008.0327f4c0@zircon.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ross, Thanks a lot for the comments! I'll forward this to the IESG. -- Alex http://www.psg.com/~zinin/ Wednesday, August 6, 2003, 10:50:07 AM, Ross Callon wrote: > At 03:46 PM 8/5/2003 -0700, Alex Zinin wrote: >>This one needs a look too. I thought we concluded that IntServ >>doesn't scale, and the doc talks about per-flow processing at >>transit IPv6 nodes... >> >>Token holder: Ross >>Please send comments by Wed night. >> >>-- >>Alex >>http://www.psg.com/~zinin/ > General Comments > It seems to me that the flow label has a purpose, and two possible > uses. To me the document seems to be not totally clear or perhaps > even wrong regarding which of the uses is the main one. > The purpose is to identify flows. For example, this allows the flow to > be identified using only fields which are in fixed positions in the IPv6 > Header. This purpose seems to me to be well defined in the document. > Now that you have an indicator regarding what flow a particular packet > belongs to, what use would you have for this information? > One possible use is for hashing packets, for example to spread traffic > across equal cost multi-paths without re-ordering packets from any one > flow. This seems like a pretty straightforward and sensible use, which > requires close to zero change to the Internet architecture, and which > is briefly mentioned in the document. > The other possible use is for an explicit flow set up procedure. However, > since the flow are per-{source-address; destination-address; flow field} > triplet, it would seem that this won't scale much better than the current > int-serve specification. Thus it is not clear whether this will end up being > useful in practice. At best I would call this experimental. > In some places in the document it appears that the flow field is for the > purpose of identifying flows, and that either of the two uses might be > sensible reasons that you might want to identify flows. In other places > in the document it looks like the second purpose (which to me seems > the more speculative) is the reason for the flow field. > I think that it would make sense to clearly separate these. > More specific comments > >> Section 1: > First three paragraphs do a good job of defining the purpose of the > flow ID (to allow efficient flow classification based only on fields in > the fixed part of the IPv6 header). > Fourth paragraph, first sentence: > The minimum level of IPv6 flow support consists > of labeling the flows. > In a sense this is reasonable, but I am not sure precisely what it means. > Does this mean: > In order to be an IPv6 conformant node, IPv6 source > nodes MUST be able to label outgoing flows. > or does this mean: > In order to claim conformance to the IPv6 flow > label specification, IPv6 source nodes MUST support > labeling outgoing flows. > Or does this mean something else? > >> Sections 2 and 3. > This seems reasonable, and again defines the purpose of the > flow label in a reasonable way, as well as defining some very > reasonable requirements, for example specifying how a source > should set the flow value. > >> Proposed New Section Between section 3 and 4: > It seems to me that the most obviously worthwhile of the > potential uses of the flow label field is to allow routers to split > traffic on multiple paths (for example, for load sharing and traffic > engineering purposes), without having to look past the IPv6 > header. > One example of where this might be very useful is in the case > of encapsulation, for example over IPsec over IPv6 > or over GRE over IPv6 encapsulations. In this case > there might be a potentially very large number of high layer flows > which will be encapsulated with the same IPv6 source and > destination addresses in the outer IPv6 header. If you can hash > only on the outer IPv6 addresses, then you could get a lot of > traffic which is forced to take the same path. If you allow a finer > grain flow label to be placed in the flow label field, then you can > get a much more even distribution of traffic across, for example, > equal cost multi-paths. > I think that it is worth having a section on this possibility. I don't > think that this requires all that much text. > There is one question which I have, which could be cleared up > in such a section: Specifically, the second sentence of section > 2 states: > A Flow Label of zero is used to indicate packets > not part of any flow. > Suppose that I am an IPv6 router which is hashing on source > address, destination address, and flow label, and I am using > the hash to split traffic among several paths. > If I see a packet with a flow label of zero, which of the following do > I assume: > - the node does not implement any flow labelling ability, and > therefore I must hash only on source and destination address. > - the node does implement flow labelling, and is telling me > that the packet is not part of any flow, and can therefore be > forwarded on any path without regard for re-ordering. > If we assume the latter, then implementation of the flow labelling > capability must be supported by all IPv6 source nodes (at least > to the point of sticking a non-zero value in the flow field), since > otherwise their packets might be re-ordered by nodes which > assume that their packets are not part of any flow. > I would suggest using zero to indicate that flow labelling is not > supported (and thus routers better keep the packets in order > based only on source and destination addresses). If we also > want to indicate that some packets are not part of a flow, we > might give them a random value, or a different special value. > >> Section 4: > The flow state establishment requirements in section 4 seem to be > very much incomplete. If there were a complete set of flow state > establishment requirements, then I think that the requirements > specified in this section are reasonable ones, and would be > included in the set. However, the two requirements specified in > section 4 seem to be such a small subset of the complete set of > requirements that I don't see why it is worth listing them at all. I > think that it would be cleaner just to say that methods and > requirements for explicit flow establishment are outside of the > scope of this document. > Naturally if section 4 were removed, then the last phrase of the > first paragraph of the abstract would also need to be removed > (page 1, phrase "and the requirements for flow state establishment > methods"). Similarly the second to last paragraph of section 1 > would need to be abbreviated. > >>Section 5: > First paragraph, last sentence: > Even if the flow label were encrypted, its presence > as a constant value in a fixed position might assist > traffic analysis and cryptoanalysis. > The flow label is supposed to be unstructured -- in the sense that if > I am not the source node, then I don't know anything about how the source > set the label, except that a different value means a different flow. As such, > I don't understand what encryption would do to change the interpretation of > a flow label. If two labels were encrypted to the same exact value, then it > would seem clear that they can't be un-encrypted back to different values. > If two flow labels were encrypted to different values, then as a node in the > middle observing the packets going by I don't detect any difference. > Section 5.1, second paragraph (top of page 5), first sentence: > Note that there is no guarantee that flow labels sent by a node are > not set in any manner that the node wants to, such as reusing flow > labels, against the recommendations in this document. > This seems to be a rather awkward sentence, and should probably > be re-written. > Additional Topic: Somewhere in the security section (probably in a new > subsection at the end) it might be worth mentioning that in those locations > where a firewall or filtering router is employed which looks past the IP > header to higher level headers, the flow label does nothing to eliminate the > need to continue to look at the higher headers. > Ross From rtg-dir-admin@ietf.org Wed Aug 6 21:08:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12271 for ; Wed, 6 Aug 2003 21:08:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kZH2-00015T-00 for rtg-dir-archive@ietf.org; Wed, 06 Aug 2003 21:09:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kZH1-00015P-00 for rtg-dir-archive@ietf.org; Wed, 06 Aug 2003 21:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kZH3-0002vD-8q; Wed, 06 Aug 2003 21: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 19kZGx-0002v2-Nx for rtg-dir@optimus.ietf.org; Wed, 06 Aug 2003 21:08: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 VAA12265 for ; Wed, 6 Aug 2003 21:08:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kZGv-00015F-00 for rtg-dir@ietf.org; Wed, 06 Aug 2003 21:08:53 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kZGu-00015B-00 for rtg-dir@ietf.org; Wed, 06 Aug 2003 21:08:52 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kZGu-000PbD-UF for rtg-dir@ietf.org; Thu, 07 Aug 2003 01:08:52 +0000 Date: Wed, 6 Aug 2003 18:08:33 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <123212129466.20030806180833@psg.com> To: rtg-dir@ietf.org Subject: Fwd: Re: Evaluation: draft-ietf-ipngwg-ipv6-anycast-analysis In-Reply-To: <145212028961.20030806180653@psg.com> References: <145212028961.20030806180653@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit fyi -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: IESG Secretary Cc: iesg@ietf.org Date: Wednesday, August 6, 2003, 6:06:53 PM Subject: Evaluation: draft-ietf-ipngwg-ipv6-anycast-analysis ===8<==============Original message text=============== Meta issues: In section 4.1, the draft talks about the possibility of assigning anycast addresses to hosts, and links this tightly to how such addresses would be injected into the routing infrastructure. First of all, I don't believe the two issues should be considered as tightly coupled. I.e., assigning anycast addresses to hosts does NOT prescribe the actual method of route injection. Second, the two proposed solutions (hosts participating in the RP, and a separate protocol used to inject routes from hosts) have considerable problems. 1. Running routing protocols on hosts This method affects two critical aspects of routing protocols: their scaling and security. From the scaling perspective, running RPs on hosts has the potential of substantially increasing the number of nodes in the domain in case a killer-app is developed that encourages hosts to participate in anycast. From the security perspective, adding hosts to the routing domain changes the whole security model of the routing protocols--assumption of implied authorization of authenticated announcements will not hold true anymore, i.e., participation in the routing domain will not be limited to routers administered by a few people. 2. Injecting routes from hosts through a new protocol This approach does not stretch the scalability assumptions in routing, but still has the same drawbacks as far as security is concerned. Again, I don't think the doc should consider assignment and advertisement together. Static route configuration and subsequent redistribution in a RP on a router seems like the right approach given the scale of deployment Minor: 3. Section 4.3. Anycast address in source address > Under RFC2373 rule, anycast address cannot be put into source address. > Here is a possible workaround, however, it did not win a consensus in > the past ipngwg meetings: Why is this section here? If it does not represent a consensus within ipv6, then the only reason I would see in documenting this option is to say "and, BTW, we do NOT want to do this", which I don't think is the case. 4. Section "2.3. Route scaling issues" > The use of anycast addresses has route scalaing issues. If anycast > addresses are drawn from the unicast address space (as is the case in > RFC2373 anycast and the shared-unicast address used for anycast DNS > servers) the routing scaling impact can potentially be limited by > aggregating the anycast addresses as part of the regular unicast routing > prefixes. But this aggregation can only be applied when all members in > the anycast group remaing within the piece of toplogy whose routes get > aggregated. For instance having an anycast address where all the > members belong to one ISP means it the anycast address can be drawn from > the ISPs address space and be aggregated at the ISP boundary with no > effect on route scaling outside that domain. But having e.g. anycast > groups with members across the whole Internet will have effect on the > size of the routing tables globally. It may be worth adding that if topological localization of anycast members is not 100% guaranteed, aggregation will break anycast, as unaggregated prefixes will be preferred over the aggregates because of the longest match forwarding behavior. -- Alex http://www.psg.com/~zinin/ ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Wed Aug 6 22:57:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15189 for ; Wed, 6 Aug 2003 22:57:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kayU-0001oC-00 for rtg-dir-archive@ietf.org; Wed, 06 Aug 2003 22:57:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kayU-0001o9-00 for rtg-dir-archive@ietf.org; Wed, 06 Aug 2003 22:57:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kayX-0006Fn-3n; Wed, 06 Aug 2003 22: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 19kaxr-0006D5-3H for rtg-dir@optimus.ietf.org; Wed, 06 Aug 2003 22:57: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 WAA15183 for ; Wed, 6 Aug 2003 22:57:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kaxn-0001o6-00 for rtg-dir@ietf.org; Wed, 06 Aug 2003 22:57:15 -0400 Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx with esmtp (Exim 4.12) id 19kaxm-0001o1-00 for rtg-dir@ietf.org; Wed, 06 Aug 2003 22:57:14 -0400 Received: from rawdofmt.org (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id D5E803DCD27; Wed, 6 Aug 2003 19:59:59 -0700 (PDT) Date: Wed, 6 Aug 2003 19:58:05 -0700 Subject: Re: Under IESG review: draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rtg-dir@ietf.org To: Alex Zinin From: Christian Hopps In-Reply-To: <89118035906.20030805160020@psg.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, August 5, 2003, at 04:00 PM, Alex Zinin wrote: > Token holders: dmm, chopps High level comment. Anycast is supplying the ability to address a topologically close instantiation of a service in a transparent (to the host) way. It makes no guarantees that any packet sent to the given anycast address will arrive at the same node. Many of the problems seem to arise from stateful protocol uses of anycast. In my opinion the reason they don't work is because they are misusing the service supplied by anycast. This draft doesn't seem to be stating that directly. A solution to almost all the problems seems to be to send a packet to the anycast server, acquire it's unicast address and use that from then on (i.e., resolve the anycast address using the routing infrastructure). This strikes me as a proper use of the anycast service. Inline comments follow. > DRAFT Analysis of IPv6 anycast June > 2003 > > o A provider-independent IPv4 address prefix is allocated from an RIR. I think this acronym might should be expanded to regional internet registry. > Shared-anycast address technique must not be confused with the one we > discuss in the document (RFC2373 anycast), as the problem domain is > different. That should be "The shared-unicast" right? > One possible workaround is to use IPv6 routing header. By specifying a > unicast address of Si as an intermediate hop, C can deliver the packet > to Si, not to other Sn. Why not just switch to using the unicast IP as the destination after it has been learned? > o Define an additional connection setup protocol that resolves IPv6 > unicast address from IPv6 anycast address. We first resolve IPv6 > unicast address using the new protocol, and then, make a TCP > connection using the IPv6 unicast address. IPv6 node information > query/reply [Crawford, 2002] could be used for this. > This seems like a solution that could be used for more than just TCP (e.g., the UDP examples). Token returned, Chris. From rtg-dir-admin@ietf.org Thu Aug 7 20:24:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09490 for ; Thu, 7 Aug 2003 20:24:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kv3E-0003un-00 for rtg-dir-archive@ietf.org; Thu, 07 Aug 2003 20:24:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kv37-0003u3-00 for rtg-dir-archive@ietf.org; Thu, 07 Aug 2003 20:24:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv34-0003fG-V6; Thu, 07 Aug 2003 20:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kuN7-0002c8-5l for rtg-dir@optimus.ietf.org; Thu, 07 Aug 2003 19:40: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 TAA08665 for ; Thu, 7 Aug 2003 19:40:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kuN5-0003io-00 for rtg-dir@ietf.org; Thu, 07 Aug 2003 19:40:39 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kuN4-0003il-00 for rtg-dir@ietf.org; Thu, 07 Aug 2003 19:40:38 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kuN5-000Bz3-6c; Thu, 07 Aug 2003 23:40:39 +0000 Date: Thu, 7 Aug 2003 16:40:14 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1845740113.20030807164014@psg.com> To: Christian Hopps CC: rtg-dir@ietf.org Subject: Re: Under IESG review: draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thanks Chris! -- Alex http://www.psg.com/~zinin/ Wednesday, August 6, 2003, 7:58:05 PM, Christian Hopps wrote: ... > Token returned, > Chris. From rtg-dir-admin@ietf.org Thu Aug 7 20:24:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09516 for ; Thu, 7 Aug 2003 20:24:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kv3O-0003vi-00 for rtg-dir-archive@ietf.org; Thu, 07 Aug 2003 20:24:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kv3D-0003u1-00 for rtg-dir-archive@ietf.org; Thu, 07 Aug 2003 20:24:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv33-0003eM-Uy; Thu, 07 Aug 2003 20: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 19kuG1-0002BO-KE for rtg-dir@optimus.ietf.org; Thu, 07 Aug 2003 19:33: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 TAA08534 for ; Thu, 7 Aug 2003 19:33:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kuFz-0003hZ-00 for rtg-dir@ietf.org; Thu, 07 Aug 2003 19:33:19 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19kuFz-0003hW-00 for rtg-dir@ietf.org; Thu, 07 Aug 2003 19:33:19 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19kuFy-000BaU-Bn; Thu, 07 Aug 2003 23:33:18 +0000 Date: Thu, 7 Aug 2003 16:32:55 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1635300722.20030807163255@psg.com> To: Ross Callon , Thomas Narten , Margaret Wasserman CC: rtg-dir@ietf.org Subject: Massaged DISCUSS comments on draft-ietf-ipv6-flow-label MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ross- There was a request on the IESG telechat today to see if we can clarify the concerns with the document and proposed actions. I took the liberty to rearrange your message a bit. Please check if you think the text below looks appropriate. Also, Thomas believes that this input should be brought to the WG. I suspect that we will need to have a conversation with IPv6 people, so I suggest that after we finalize the text below, Thomas brings it to the WG and we keep rtg-dir cc'ed in the discussion. Alex Meta issues: 1. Per-flow state and processing Now that you have an indicator regarding what flow a particular packet belongs to, what use would you have for this information? One possible use is for hashing packets, for example to spread traffic across equal cost multi-paths without re-ordering packets from any one flow. This seems like a pretty straightforward and sensible use, which requires close to zero change to the Internet architecture, and which is briefly mentioned in the document. The other possible use is for an explicit flow set up procedure. However, since the flow are per-{source-address; destination-address; flow field} triplet, it would seem that this won't scale much better than the current int-serve specification. Thus it is not clear whether this will end up being useful in practice. At best I would call this experimental. Suggestion: remove suggestions to use the flow label for per-flow packet processing, or at least provide discussion about scalability aspects of this method, and refer to the experience gained with IntServ. 2. Clearly separate flow applications In some places in the document it appears that the flow field is for the purpose of identifying flows, and that either of the two uses might be sensible reasons that you might want to identify flows. In other places in the document it looks like the second purpose (which to me seems the more speculative) is the reason for the flow field. 3. Flow label zero the second sentence of section 2 states: A Flow Label of zero is used to indicate packets not part of any flow. Suppose that I am an IPv6 router which is hashing on source address, destination address, and flow label, and I am using the hash to split traffic among several paths. If I see a packet with a flow label of zero, which of the following do I assume: - the node does not implement any flow labelling ability, and therefore I must hash only on source and destination address. - the node does implement flow labelling, and is telling me that the packet is not part of any flow, and can therefore be forwarded on any path without regard for re-ordering. If we assume the latter, then implementation of the flow labelling capability must be supported by all IPv6 source nodes (at least to the point of sticking a non-zero value in the flow field), since otherwise their packets might be re-ordered by nodes which assume that their packets are not part of any flow. Suggestion: I would suggest using zero to indicate that flow labelling is not supported (and thus routers better keep the packets in order based only on source and destination addresses). If we also want to indicate that some packets are not part of a flow, we might give them a random value, or a different special value. Section-specific comments: Section 1: Fourth paragraph, first sentence: The minimum level of IPv6 flow support consists of labeling the flows. In a sense this is reasonable, but I am not sure precisely what it means. Does this mean: In order to be an IPv6 conformant node, IPv6 source nodes MUST be able to label outgoing flows. or does this mean: In order to claim conformance to the IPv6 flow label specification, IPv6 source nodes MUST support labeling outgoing flows. Suggestion: clarify the text. Proposed New Section Between section 3 and 4: It seems to me that the most obviously worthwhile of the potential uses of the flow label field is to allow routers to split traffic on multiple paths (for example, for load sharing and traffic engineering purposes), without having to look past the IPv6 header. One example of where this might be very useful is in the case of encapsulation, for example over IPsec over IPv6 or over GRE over IPv6 encapsulations. In this case there might be a potentially very large number of high layer flows which will be encapsulated with the same IPv6 source and destination addresses in the outer IPv6 header. If you can hash only on the outer IPv6 addresses, then you could get a lot of traffic which is forced to take the same path. If you allow a finer grain flow label to be placed in the flow label field, then you can get a much more even distribution of traffic across, for example, equal cost multi-paths. I think that it is worth having a section on this possibility. I don't think that this requires all that much text. Section 4: The flow state establishment requirements in section 4 seem to be very much incomplete. If there were a complete set of flow state establishment requirements, then I think that the requirements specified in this section are reasonable ones, and would be included in the set. However, the two requirements specified in section 4 seem to be such a small subset of the complete set of requirements that I don't see why it is worth listing them at all. I think that it would be cleaner just to say that methods and requirements for explicit flow establishment are outside of the scope of this document. Naturally if section 4 were removed, then the last phrase of the first paragraph of the abstract would also need to be removed (page 1, phrase "and the requirements for flow state establishment methods"). Similarly the second to last paragraph of section 1 would need to be abbreviated. Section 5: First paragraph, last sentence: Even if the flow label were encrypted, its presence as a constant value in a fixed position might assist traffic analysis and cryptoanalysis. The flow label is supposed to be unstructured -- in the sense that if I am not the source node, then I don't know anything about how the source set the label, except that a different value means a different flow. As such, I don't understand what encryption would do to change the interpretation of a flow label. If two labels were encrypted to the same exact value, then it would seem clear that they can't be un-encrypted back to different values. If two flow labels were encrypted to different values, then as a node in the middle observing the packets going by I don't detect any difference. Section 5.1 second paragraph (top of page 5), first sentence: Note that there is no guarantee that flow labels sent by a node are not set in any manner that the node wants to, such as reusing flow labels, against the recommendations in this document. This seems to be a rather awkward sentence, and should probably be re-written. Additional Topic: Somewhere in the security section (probably in a new subsection at the end) it might be worth mentioning that in those locations where a firewall or filtering router is employed which looks past the IP header to higher level headers, the flow label does nothing to eliminate the need to continue to look at the higher headers. From rtg-dir-admin@ietf.org Fri Aug 8 07:28:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08007 for ; Fri, 8 Aug 2003 07:28:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l5Qc-00005T-00 for rtg-dir-archive@ietf.org; Fri, 08 Aug 2003 07:29:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l5Qb-00005P-00 for rtg-dir-archive@ietf.org; Fri, 08 Aug 2003 07:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l5Qa-0008WM-M1; Fri, 08 Aug 2003 07:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l5QY-0008W6-9x for rtg-dir@optimus.ietf.org; Fri, 08 Aug 2003 07:28: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 HAA07996 for ; Fri, 8 Aug 2003 07:28:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l5QX-00005K-00 for rtg-dir@ietf.org; Fri, 08 Aug 2003 07:28:57 -0400 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 19l5QW-00005C-00 for rtg-dir@ietf.org; Fri, 08 Aug 2003 07:28:56 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h78BSNj3278030; Fri, 8 Aug 2003 07:28:23 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-202-60.mts.ibm.com [9.65.202.60]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h78BSMB5193824; Fri, 8 Aug 2003 05:28:22 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h78BR4j06573; Fri, 8 Aug 2003 07:27:04 -0400 Message-Id: <200308081127.h78BR4j06573@cichlid.adsl.duke.edu> To: Alex Zinin cc: Ross Callon , Margaret Wasserman , rtg-dir@ietf.org Subject: Re: Massaged DISCUSS comments on draft-ietf-ipv6-flow-label In-Reply-To: Message from zinin@psg.com of "Thu, 07 Aug 2003 16:32:55 PDT." <1635300722.20030807163255@psg.com> Date: Fri, 08 Aug 2003 07:27:03 -0400 From: Thomas Narten Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Hi Alex and Ross. A couple of comments, from the view of a recipient that will want to know what it is that needs to be changed in the document. Note: my goal here is not to have the big discussion here that this review is implying, but to tighten up the comments so they can be brought to the WG most constructively. Overall, I think these comments are good and useful. Thanks. Thomas > Meta issues: > 1. Per-flow state and processing > Now that you have an indicator regarding what flow a particular packet > belongs to, what use would you have for this information? > One possible use is for hashing packets, for example to spread traffic > across equal cost multi-paths without re-ordering packets from any one > flow. This seems like a pretty straightforward and sensible use, which > requires close to zero change to the Internet architecture, and which > is briefly mentioned in the document. > The other possible use is for an explicit flow set up procedure. > However, since the flow are per-{source-address; destination-address; > flow field} triplet, it would seem that this won't scale much better > than the current int-serve specification. Thus it is not clear whether > this will end up being useful in practice. At best I would call this > experimental. > Suggestion: > remove suggestions to use the flow label for per-flow packet > processing, or at least provide discussion about scalability > aspects of this method, and refer to the experience gained with > IntServ. The purpose is to allow for per-flow processing, so the latter is what is being requested. > 2. Clearly separate flow applications > In some places in the document it appears that the flow field is for > the purpose of identifying flows, and that either of the two uses > might be sensible reasons that you might want to identify flows. In > other places in the document it looks like the second purpose (which > to me seems the more speculative) is the reason for the flow > field. What is the requested action item here? Is there specific text that can be given as an example of what should be changed? [This can be read as a vague request to make the document better.] > 3. Flow label zero > the second sentence of section 2 states: > A Flow Label of zero is used to indicate packets > not part of any flow. > Suppose that I am an IPv6 router which is hashing on source > address, destination address, and flow label, and I am using the > hash to split traffic among several paths. > If I see a packet with a flow label of zero, which of the following do > I assume: > - the node does not implement any flow labelling ability, and > therefore I must hash only on source and destination address. > - the node does implement flow labelling, and is telling me that > the packet is not part of any flow, and can therefore be forwarded > on any path without regard for re-ordering. Not the latter. One should never in the internet architecture assume that reording packets is generally OK or to be encouraged. > If we assume the latter, then implementation of the flow labelling > capability must be supported by all IPv6 source nodes (at least to > the point of sticking a non-zero value in the flow field), since > otherwise their packets might be re-ordered by nodes which assume > that their packets are not part of any flow. > Suggestion: > > I would suggest using zero to indicate that flow labelling is not > supported (and thus routers better keep the packets in order based > only on source and destination addresses). If we also want to > indicate that some packets are not part of a flow, we might give > them a random value, or a different special value. I agree that this general point deserves more thinking and maybe clearer text. The fundamental question seems to be whether a flow label of 0 means "source does not implement flows" or "source implements flows, but this packet is not to be given any flow-specific treatment". Or whether the distinction is important in practice. > Section-specific comments: > Section 1: > Fourth paragraph, first sentence: > The minimum level of IPv6 flow support consists > of labeling the flows. > In a sense this is reasonable, but I am not sure precisely what it > means. > Does this mean: > In order to be an IPv6 conformant node, IPv6 source > nodes MUST be able to label outgoing flows. > or does this mean: > In order to claim conformance to the IPv6 flow > label specification, IPv6 source nodes MUST support > labeling outgoing flows. > Suggestion: clarify the text. > Proposed New Section Between section 3 and 4: > It seems to me that the most obviously worthwhile of the > potential uses of the flow label field is to allow routers to split > traffic on multiple paths (for example, for load sharing and traffic > engineering purposes), without having to look past the IPv6 > header. > One example of where this might be very useful is in the case > of encapsulation, for example over IPsec over IPv6 > or over GRE over IPv6 encapsulations. In this case > there might be a potentially very large number of high layer flows > which will be encapsulated with the same IPv6 source and > destination addresses in the outer IPv6 header. If you can hash > only on the outer IPv6 addresses, then you could get a lot of > traffic which is forced to take the same path. If you allow a finer > grain flow label to be placed in the flow label field, then you can > get a much more even distribution of traffic across, for example, > equal cost multi-paths. > I think that it is worth having a section on this possibility. I don't > think that this requires all that much text. > > Section 4: > The flow state establishment requirements in section 4 seem to be > very much incomplete. If there were a complete set of flow state > establishment requirements, then I think that the requirements > specified in this section are reasonable ones, and would be > included in the set. However, the two requirements specified in > section 4 seem to be such a small subset of the complete set of > requirements that I don't see why it is worth listing them at all. I > think that it would be cleaner just to say that methods and > requirements for explicit flow establishment are outside of the > scope of this document. > Naturally if section 4 were removed, then the last phrase of the > first paragraph of the abstract would also need to be removed > (page 1, phrase "and the requirements for flow state establishment > methods"). Similarly the second to last paragraph of section 1 > would need to be abbreviated. > Section 5: > First paragraph, last sentence: > Even if the flow label were encrypted, its presence > as a constant value in a fixed position might assist > traffic analysis and cryptoanalysis. > The flow label is supposed to be unstructured -- in the sense that if > I am not the source node, then I don't know anything about how the > source set the label, except that a different value means a different > flow. As such, I don't understand what encryption would do to change > the interpretation of a flow label. If two labels were encrypted to > the same exact value, then it would seem clear that they can't be > un-encrypted back to different values. If two flow labels were > encrypted to different values, then as a node in the middle observing > the packets going by I don't detect any difference. > Section 5.1 > second paragraph (top of page 5), first sentence: > Note that there is no guarantee that flow labels sent by a node are > not set in any manner that the node wants to, such as reusing flow > labels, against the recommendations in this document. > This seems to be a rather awkward sentence, and should probably > be re-written. > Additional Topic: > Somewhere in the security section (probably in a new subsection at > the end) it might be worth mentioning that in those locations where > a firewall or filtering router is employed which looks past the IP > header to higher level headers, the flow label does nothing to > eliminate the need to continue to look at the higher headers. From rtg-dir-admin@ietf.org Fri Aug 8 16:24:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24350 for ; Fri, 8 Aug 2003 16:24:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lDmO-0003i9-00 for rtg-dir-archive@ietf.org; Fri, 08 Aug 2003 16:24:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lDmM-0003i5-00 for rtg-dir-archive@ietf.org; Fri, 08 Aug 2003 16:24:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmN-0005UZ-6J; Fri, 08 Aug 2003 16: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 19lCnE-0003RF-Vu for rtg-dir@optimus.ietf.org; Fri, 08 Aug 2003 15:20: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 PAA23125 for ; Fri, 8 Aug 2003 15:20:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lCn8-0003BU-00 for rtg-dir@ietf.org; Fri, 08 Aug 2003 15:20:46 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19lCn7-0003BC-00 for rtg-dir@ietf.org; Fri, 08 Aug 2003 15:20:46 -0400 Received: from rcallon-lt.juniper.net (securepptp042.static.jnpr.net [172.24.253.42]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h78JJuu64312; Fri, 8 Aug 2003 12:19:56 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20030808142715.0302e2a0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 08 Aug 2003 15:17:20 -0400 To: Alex Zinin , Thomas Narten , Margaret Wasserman From: Ross Callon Subject: Re: Massaged DISCUSS comments on draft-ietf-ipv6-flow-label Cc: rtg-dir@ietf.org In-Reply-To: <1635300722.20030807163255@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , At 04:32 PM 8/7/2003 -0700, Alex Zinin wrote: >Ross- > > There was a request on the IESG telechat today to see if we can > clarify the concerns with the document and proposed actions. > I took the liberty to rearrange your message a bit. Please check > if you think the text below looks appropriate. > > Also, Thomas believes that this input should be brought to the WG. > I suspect that we will need to have a conversation with IPv6 people, > so I suggest that after we finalize the text below, Thomas brings > it to the WG and we keep rtg-dir cc'ed in the discussion. > >Alex I agree that if these points are to be made, and if the IESG agrees, then either (i) the comments should come from the IESG and rtg-dir should be CC'd; or (ii) the comments could be first discussed with some of the authors off line and then brought to the working group either as IESG comments or as author's proposed resolution to IESG comments (still with rtg-dir CC'd). Regarding meta-issues, I think that the main meta issue is that the document includes three things: (i) A definition of the flow field, including directions on how the source should set this and what can be assumed from the field; (ii) The notion that the field may be useful for routers to hash packets without having to look past the IPv6 header; and (iii) The notion that this field may be used as part of a procedure which keeps explicit flow state in routers, likely by making use of explicit signaling. The first of these three is well defined, except for one small detail regarding a value of zero (which I think can be cleared up quickly). The second of these is well defined and can be expressed in very few words (ie, so few words that it doesn't seem worth having a separate document just for the purpose). The third of these is not well defined at all, and will require significant additional work to fully define. I don't think that we should stop this work, but rather just take it to a separate document. With this in mind, how about the following re-wording of Alex's re-wording: Meta issues: 1. Scope of the document. The document combines three important ideas, two of which are well defined, and one of which is less well defined and will require additional work. We would suggest that the well-defined ideas are left in the document, and the less well defined idea is moved to a separate document. (specific edits are proposed below). Specifically, the document talks about: (i) The definition of the flow field, including directions on how the source should set this and what can be assumed from the field; (ii) The notion that the field may be useful for routers to hash packets without having to look past the IPv6 header; and (iii) The notion that this field may be used as part of a procedure which keeps explicit flow state in routers, likely by making use of explicit signaling. The first two of these (modulo a detail discussed below) are well defined and should be able to be progressed with limited additional work and editing. The third of these might require significant additional work before it is completed. 2. Per-flow state and processing The flow label provides an indicator regarding what flow a particular packet belongs to. Given this, what use would you have for this information? One possible use is for hashing packets, for example to spread traffic across equal cost multi-paths without re-ordering packets from any one flow. This seems like a pretty straightforward and sensible use, which requires close to zero change to the Internet architecture, and which is briefly mentioned in the document. The other possible use is for an explicit flow set up procedure. However, since the flow are per-{source-address; destination-address; flow field} triplet, it would seem that this won't scale much better than the current int-serve specification. Thus it is not clear whether this will end up being useful in practice. Perhaps this could be called experimental. Suggestion: Remove suggestions to use the flow label for per-flow packet processing (and possibly reference "work in progress" which is outside the scope of the document), or at least provide discussion about the scalability aspects of this method, and refer to the experience gained with IntServ. 3. Clearly separate flow applications In some places in the document it appears that the flow field is for the purpose of identifying flows, and that either of the two uses might be sensible reasons that you might want to identify flows. In other places in the document it looks like the second purpose (which to me seems the more speculative) is the reason for the flow field. 4. Flow label zero (more detailed comment) the second sentence of section 2 states: A Flow Label of zero is used to indicate packets not part of any flow. Suppose that I am an IPv6 router which is hashing on source address, destination address, and flow label, and I am using the hash to split traffic among several paths. If I see a packet with a flow label of zero, which of the following do I assume: - the node does not implement any flow labelling ability, and therefore I must hash only on source and destination address. - the node does implement flow labelling, and is telling me that the packet is not part of any flow, and can therefore be forwarded on any path without regard for re-ordering. If we assume the latter, then implementation of the flow labelling capability must be supported by all IPv6 source nodes (at least to the point of sticking a non-zero value in the flow field), since otherwise their packets might be re-ordered by nodes which assume that their packets are not part of any flow. Suggestion: I would suggest using zero to indicate that flow labelling is not supported (and thus routers better keep the packets in order based only on source and destination addresses). If we also want to indicate that some packets are not part of a flow, we might give them a random value, or a different special value. Possible text might be: A Flow Label of zero is used to indicate packets which are not part of a separately identified flow, or are from a source which does not support the flow label. Since such packets might be related as part of a unidentified flow, the required treatment and order preservation is the same as would be expected for IP traffic in the absence of a flow label. Section-specific comments: Section 1: Fourth paragraph, first sentence: The minimum level of IPv6 flow support consists of labeling the flows. In a sense this is reasonable, but I am not sure precisely what it means. Does this mean: In order to be an IPv6 conformant node, IPv6 source nodes MUST be able to label outgoing flows. or does this mean: In order to claim conformance to the IPv6 flow label specification, IPv6 source nodes MUST support labeling outgoing flows. Suggestion: clarify the text. Proposed New Section Between section 3 and 4: It seems to me that the most straightforward of the potential uses of the flow label field is to allow routers to split traffic on multiple paths (for example, for load sharing and traffic engineering purposes), without having to look past the IPv6 header. One example of where this might be very useful is in the case of encapsulation, for example over IPsec over IPv6 or over GRE over IPv6 encapsulations. In this case there might be a potentially very large number of high layer flows which will be encapsulated with the same IPv6 source and destination addresses in the outer IPv6 header. If you can hash only on the outer IPv6 addresses, then you could get a lot of traffic which is forced to take the same path. If you allow a finer grain flow label to be placed in the flow label field, then you can get a much more even distribution of traffic across, for example, equal cost multi-paths. I think that it is worth having a section on this possibility. I don't think that this requires all that much text. Section 4: The flow state establishment requirements in section 4 seem to be very much incomplete. If there were a complete set of flow state establishment requirements, then I think that the requirements specified in this section are reasonable ones, and would be included in the set. However, the two requirements specified in section 4 seem to be such a small subset of the complete set of requirements that I don't see why it is worth listing them at all. I think that it would be cleaner just to say that methods and requirements for explicit flow establishment are outside of the scope of this document. Naturally if section 4 were removed, then the last phrase of the first paragraph of the abstract would also need to be removed (page 1, phrase "and the requirements for flow state establishment methods"). Similarly the second to last paragraph of section 1 would need to be abbreviated. In this case it might be desired to add a short description to the introduction stating something like: The flow label may potentially also be used to support per-flow explicit packet handling based on per-flow state. Requirements and procedures for this purpose are outside of the scope of this document [reference ongoing work in this area, if any]. Section 5: First paragraph, last sentence: Even if the flow label were encrypted, its presence as a constant value in a fixed position might assist traffic analysis and cryptoanalysis. The flow label is supposed to be unstructured -- in the sense that if I am not the source node, then I don't know anything about how the source set the label, except that a different value means a different flow. As such, I don't understand what encryption would do to change the interpretation of a flow label. If two labels were encrypted to the same exact value, then it would seem clear that they can't be un-encrypted back to different values. If two flow labels were encrypted to different values, then as a node in the middle observing the packets going by I don't detect any difference. Suggestion: Perhaps the sentence could be re-written as follows: Even if the flow label were encrypted, the fact that different labels would typically be encrypted to different values implies that it can be used to distinguish flows, and therefore that it might assist traffic analysis and cryptoanalysis. Section 5.1 second paragraph (top of page 5), first sentence: Note that there is no guarantee that flow labels sent by a node are not set in any manner that the node wants to, such as reusing flow labels, against the recommendations in this document. This seems to be a rather awkward sentence, and should probably be re-written. Additional Topic: Somewhere in the security section (probably in a new subsection at the end) it might be worth mentioning that in those locations where a firewall or filtering router is employed which looks past the IP header to higher level headers, the flow label does nothing to eliminate the need to continue to look at the higher headers. From rtg-dir-admin@ietf.org Fri Aug 8 16:24:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24392 for ; Fri, 8 Aug 2003 16:24:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lDmP-0003iC-00 for rtg-dir-archive@ietf.org; Fri, 08 Aug 2003 16:24:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lDmM-0003i6-00 for rtg-dir-archive@ietf.org; Fri, 08 Aug 2003 16:24:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lDmN-0005UP-1W; Fri, 08 Aug 2003 16: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 19lCmw-0003Qg-R0 for rtg-dir@optimus.ietf.org; Fri, 08 Aug 2003 15: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 PAA23122 for ; Fri, 8 Aug 2003 15:20:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lCmv-0003BP-00 for rtg-dir@ietf.org; Fri, 08 Aug 2003 15:20:33 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19lCmu-0003B7-00 for rtg-dir@ietf.org; Fri, 08 Aug 2003 15:20:32 -0400 Received: from rcallon-lt.juniper.net (securepptp042.static.jnpr.net [172.24.253.42]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h78JJsu64309; Fri, 8 Aug 2003 12:19:54 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20030808135247.02f91580@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 08 Aug 2003 13:59:34 -0400 To: Thomas Narten , Alex Zinin From: Ross Callon Subject: Re: Massaged DISCUSS comments on draft-ietf-ipv6-flow-label Cc: Margaret Wasserman , rtg-dir@ietf.org In-Reply-To: <200308081127.h78BR4j06573@cichlid.adsl.duke.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , At 07:27 AM 8/8/2003 -0400, Thomas Narten wrote: >Hi Alex and Ross. > >A couple of comments, from the view of a recipient that will want to >know what it is that needs to be changed in the document. Note: my >goal here is not to have the big discussion here that this review is >implying, but to tighten up the comments so they can be brought to the >WG most constructively. Thomas; I think that it works best to reply to the more specific comments in your message first, and then go back to Alex's message. > > Meta issues: > > > 1. Per-flow state and processing > > > Now that you have an indicator regarding what flow a particular packet > > belongs to, what use would you have for this information? > > > One possible use is for hashing packets, for example to spread traffic > > across equal cost multi-paths without re-ordering packets from any one > > flow. This seems like a pretty straightforward and sensible use, which > > requires close to zero change to the Internet architecture, and which > > is briefly mentioned in the document. > > > The other possible use is for an explicit flow set up procedure. > > However, since the flow are per-{source-address; destination-address; > > flow field} triplet, it would seem that this won't scale much better > > than the current int-serve specification. Thus it is not clear whether > > this will end up being useful in practice. At best I would call this > > experimental. > > > Suggestion: > > > remove suggestions to use the flow label for per-flow packet > > processing, or at least provide discussion about scalability > > aspects of this method, and refer to the experience gained with > > IntServ. > >The purpose is to allow for per-flow processing, so the latter is what >is being requested. But the field is useful for two uses. Thus it makes sense to separate the users, while having a clear specification of what the flow field specifies. I agree that some in the working group want it specifically for per-flow setup and processing. I don't think that we want to preclude this as a standards issue (whether it is precluded by the cost of building a device which is capable of dealing with enough flows is in my opinion not what we are trying to answer here. > > 2. Clearly separate flow applications > > > In some places in the document it appears that the flow field is for > > the purpose of identifying flows, and that either of the two uses > > might be sensible reasons that you might want to identify flows. In > > other places in the document it looks like the second purpose (which > > to me seems the more speculative) is the reason for the flow > > field. > >What is the requested action item here? Is there specific text that >can be given as an example of what should be changed? [This can be >read as a vague request to make the document better.] I will see if I can produce draft text. > > 3. Flow label zero > > > the second sentence of section 2 states: > > > A Flow Label of zero is used to indicate packets > > not part of any flow. > > > Suppose that I am an IPv6 router which is hashing on source > > address, destination address, and flow label, and I am using the > > hash to split traffic among several paths. > > > If I see a packet with a flow label of zero, which of the following do > > I assume: > > > - the node does not implement any flow labelling ability, and > > therefore I must hash only on source and destination address. > > > - the node does implement flow labelling, and is telling me that > > the packet is not part of any flow, and can therefore be forwarded > > on any path without regard for re-ordering. > >Not the latter. One should never in the internet architecture assume >that reording packets is generally OK or to be encouraged. The spec currently states that a value of zero indicates that the packet is not part of any flow. Perhaps it should state that a value of zero indicates that the packet is part of a flow which is not clearly differentiated through use of the flow label. > > If we assume the latter, then implementation of the flow labelling > > capability must be supported by all IPv6 source nodes (at least to > > the point of sticking a non-zero value in the flow field), since > > otherwise their packets might be re-ordered by nodes which assume > > that their packets are not part of any flow. > > > Suggestion: > > > > I would suggest using zero to indicate that flow labelling is not > > supported (and thus routers better keep the packets in order based > > only on source and destination addresses). If we also want to > > indicate that some packets are not part of a flow, we might give > > them a random value, or a different special value. > >I agree that this general point deserves more thinking and maybe >clearer text. The fundamental question seems to be whether a flow >label of 0 means "source does not implement flows" or "source >implements flows, but this packet is not to be given any flow-specific >treatment". Or whether the distinction is important in practice. I think that it should be clear what you are allowed to do with a packet whose flow label is zero. ;-) Ross From rtg-dir-admin@ietf.org Fri Aug 15 16:25:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12229 for ; Fri, 15 Aug 2003 16:25:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nl96-0005mK-00 for rtg-dir-archive@ietf.org; Fri, 15 Aug 2003 16:26:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nl96-0005mE-00 for rtg-dir-archive@ietf.org; Fri, 15 Aug 2003 16:26:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl96-00014s-Pn; Fri, 15 Aug 2003 16:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl8b-000114-NI for rtg-dir@optimus.ietf.org; Fri, 15 Aug 2003 16:25: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 QAA12217 for ; Fri, 15 Aug 2003 16:25:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nl8Z-0005lz-00 for rtg-dir@ietf.org; Fri, 15 Aug 2003 16:25:27 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19nl8Z-0005lv-00 for rtg-dir@ietf.org; Fri, 15 Aug 2003 16:25:27 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19nl8Y-0000PC-G6 for rtg-dir@ietf.org; Fri, 15 Aug 2003 20:25:26 +0000 Date: Fri, 15 Aug 2003 13:25:02 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <583537927.20030815132502@psg.com> To: rtg-dir@ietf.org Subject: Fwd: Last Call on draft-gill-gtsh-00.txt In-Reply-To: <96615458792.20030814180213@psg.com> References: <96615458792.20030814180213@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit FYI below. Please review by the LC deadline. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: routing-discussion@ietf.org Cc: Date: Thursday, August 14, 2003, 6:02:13 PM Subject: Last Call on draft-gill-gtsh-00.txt ===8<==============Original message text=============== Folks- The IESG received a request to progress draft-gill-gtsh-00.txt as an individual contribution towards the EXPERIMENTAL RFC status. The concept described in the document (as well as the original document known as draft-gill-btsh) has been widely discussed in the community, and I would like to start a 4-week Last Call on the Routing Area mailing list to encourage review and gauge the consensus on the document before taking it to the IESG. Please read the document and indicate if you support it going forward (do send a message if you support). The last call ends on September 12th, 2003. This message will be forwarded as an FYI to certain individual WGs. However, please send your comments to routing-discussion@ietf.org -- Alex Zinin IETF Routing Area Co-Director http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Fri Aug 15 17:46:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15077 for ; Fri, 15 Aug 2003 17:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nmPT-0006TM-00 for rtg-dir-archive@ietf.org; Fri, 15 Aug 2003 17:46:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nmPS-0006TJ-00 for rtg-dir-archive@ietf.org; Fri, 15 Aug 2003 17:46:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nmPU-0006XR-Cb; Fri, 15 Aug 2003 17:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nmOX-0006Wj-E6 for rtg-dir@optimus.ietf.org; Fri, 15 Aug 2003 17:46: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 RAA15046 for ; Fri, 15 Aug 2003 17:45:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nmOU-0006Sy-00 for rtg-dir@ietf.org; Fri, 15 Aug 2003 17:45:58 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19nmOU-0006SX-00 for rtg-dir@ietf.org; Fri, 15 Aug 2003 17:45:58 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h7FLjMR1028606; Fri, 15 Aug 2003 17:45:22 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h7FLjBAg028572; Fri, 15 Aug 2003 17:45:11 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h7FLj6U00250; Fri, 15 Aug 2003 17:45:06 -0400 (EDT) Date: Fri, 15 Aug 2003 17:45:06 -0400 From: Jeffrey Haas To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: Fwd: Last Call on draft-gill-gtsh-00.txt Message-ID: <20030815174506.B470@nexthop.com> References: <96615458792.20030814180213@psg.com> <583537927.20030815132502@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <583537927.20030815132502@psg.com>; from zinin@psg.com on Fri, Aug 15, 2003 at 01:25:02PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Fri, Aug 15, 2003 at 01:25:02PM -0700, Alex Zinin wrote: > FYI below. Please review by the LC deadline. Looks good. The comment about "route servers" is possibly off a little bit considering that most inter-domain route servers were 1 IP hop away. Nothing I'd worry about though. > Alex -- Jeff Haas NextHop Technologies From mailman-admin@ietf.org Tue Sep 2 00:52:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25864 for ; Tue, 2 Sep 2003 00:52: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 19toJ9-0006pd-UF for rtg-dir-archive@ietf.org; Mon, 01 Sep 2003 09:01:23 -0400 Date: Mon, 01 Sep 2003 09:01:23 -0400 Message-ID: <20030901130123.21711.43316.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: rtg-dir-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rtg-dir-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for rtg-dir-archive@ietf.org: List Password // URL ---- -------- rtg-dir@ietf.org utnefe https://www1.ietf.org/mailman/options/rtg-dir/rtg-dir-archive%40ietf.org From rtg-dir-admin@ietf.org Tue Sep 9 02:25:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21853 for ; Tue, 9 Sep 2003 02:25: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 19wbvx-0006tn-7k; Tue, 09 Sep 2003 02:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wbvC-0006rD-RF for rtg-dir@optimus.ietf.org; Tue, 09 Sep 2003 02:24: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 CAA21816 for ; Tue, 9 Sep 2003 02:24:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wbv9-0006Lg-00 for rtg-dir@ietf.org; Tue, 09 Sep 2003 02:24:11 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19wbuy-0006Ks-00 for rtg-dir@ietf.org; Tue, 09 Sep 2003 02:24:00 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.22) id 19wbtl-000CLL-I7; Tue, 09 Sep 2003 06:22:45 +0000 Date: Mon, 8 Sep 2003 23:17:28 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <3642217705.20030908231728@psg.com> To: rtg-dir@ietf.org CC: Pekka Savola Subject: Fwd: Re: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) In-Reply-To: <200309082102.h88L2tCs071390@laptoy770.fictitious.org> References: <200309082102.h88L2tCs071390@laptoy770.fictitious.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit To RTG-DIR members: Guys, seems that unless one of the rtg-dir members gives Pekka a hand, we're not going anywhere with this doc. Volunteers, please? -- Alex P.S. If you don't know what I'm talking about--please catch up on the routing-discussion list. This is a forwarded message From: Curtis Villamizar To: Pekka Savola Cc: Tom Petch , routing-discussion@ietf.org, mibs Date: Monday, September 8, 2003, 2:02:55 PM Subject: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) ===8<==============Original message text=============== In message , Pekka Savola w rites: > On Mon, 8 Sep 2003, Tom Petch wrote: > > > How can we work for improve the document? > > > > Um, redraft it in a different format? > > Not reasonable. Then don't bother producing the draft. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Tue Sep 9 12:58:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22137 for ; Tue, 9 Sep 2003 12:58:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wlpU-0007CK-00 for rtg-dir-archive@ietf.org; Tue, 09 Sep 2003 12:59:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wlpU-0007CG-00 for rtg-dir-archive@ietf.org; Tue, 09 Sep 2003 12:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wlpV-0007qh-2q; Tue, 09 Sep 2003 12: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 19wloW-0007pv-4B for rtg-dir@optimus.ietf.org; Tue, 09 Sep 2003 12:58: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 MAA22113 for ; Tue, 9 Sep 2003 12:57:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wloU-0007Bi-00 for rtg-dir@ietf.org; Tue, 09 Sep 2003 12:57:58 -0400 Received: from dns.nexthop.com ([65.247.36.216] helo=presque.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 19wloT-0007BI-00 for rtg-dir@ietf.org; Tue, 09 Sep 2003 12:57:57 -0400 Received: (from root@localhost) by presque.nexthop.com (8.12.9/8.11.1) id h89GvR5e080569; Tue, 9 Sep 2003 12:57:27 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by presque.nexthop.com (8.12.9/8.12.8) with ESMTP id h89GvN1X080550; Tue, 9 Sep 2003 12:57:23 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h89GvIG22606; Tue, 9 Sep 2003 12:57:18 -0400 (EDT) Date: Tue, 9 Sep 2003 12:57:18 -0400 From: Jeffrey Haas To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: Fwd: Re: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents (fwd) Message-ID: <20030909125717.N16222@nexthop.com> References: <200309082102.h88L2tCs071390@laptoy770.fictitious.org> <3642217705.20030908231728@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3642217705.20030908231728@psg.com>; from zinin@psg.com on Mon, Sep 08, 2003 at 11:17:28PM -0700 X-Virus-Scanned: by AMaViS perl-11 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , On Mon, Sep 08, 2003 at 11:17:28PM -0700, Alex Zinin wrote: > To RTG-DIR members: > > Guys, seems that unless one of the rtg-dir members gives > Pekka a hand, we're not going anywhere with this doc. > > Volunteers, please? I think Curtis has helped push things back on the right track. I made a suggest of something I'd like to see. It also nitpicks a bit of our organizational structure for our documents. -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Fri Sep 12 02:04:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02683 for ; Fri, 12 Sep 2003 02:04:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xh3F-0002Q3-00 for rtg-dir-archive@ietf.org; Fri, 12 Sep 2003 02:05:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xh3F-0002Pz-00 for rtg-dir-archive@ietf.org; Fri, 12 Sep 2003 02:05:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xh3G-000666-PZ; Fri, 12 Sep 2003 02: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 19xh34-00065P-VE for rtg-dir@optimus.ietf.org; Fri, 12 Sep 2003 02:04: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 BAA27303; Fri, 12 Sep 2003 01:57:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xgvo-0002Mv-00; Fri, 12 Sep 2003 01:57:20 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19xgvo-0002Mq-00; Fri, 12 Sep 2003 01:57:20 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.22) id 19xgvp-000Amv-04; Fri, 12 Sep 2003 05:57:21 +0000 Date: Thu, 11 Sep 2003 22:56:49 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <54108361555.20030911225649@psg.com> To: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: IETF problem statement and change process MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- At the IETF meeting in Vienna, the discussion held at the plenary suggested that the IESG should work on the solutions identified by the problem statement WG and come back to the community with the suggestions. I will be spending more time on this topic next few months and would like to encourage you to think about where the IETF should be moving and talk to me if you have an opinion. Regards. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Mon Sep 15 21:20:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05782 for ; Mon, 15 Sep 2003 21:20:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z4Wb-0001No-00 for rtg-dir-archive@ietf.org; Mon, 15 Sep 2003 21:21:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19z4Wb-0001Nk-00 for rtg-dir-archive@ietf.org; Mon, 15 Sep 2003 21:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4Wc-0007R9-Uu; Mon, 15 Sep 2003 21:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4W4-0007Qo-Mm for rtg-dir@optimus.ietf.org; Mon, 15 Sep 2003 21:20:28 -0400 Received: from 132.151.1.176 ([209.120.141.42]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05768 for ; Mon, 15 Sep 2003 21:20:17 -0400 (EDT) Received: from [122.104.189.154] by 132.151.1.176; Mon, 15 Sep 2003 18:13:21 -0700 Message-ID: From: "Females Helpline" Reply-To: "Females Helpline" To: Subject: Get Seductive L|ps - no man can resist! Date: Mon, 15 Sep 2003 18:13:21 -0700 X-Mailer: Eurtton Mail TRS- X-Info-Mailx: igtDwriBrvguClit MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="E19EE1B_A2F5B43." X-Priority: 3 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --E19EE1B_A2F5B43. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable FINALLY A LIP PLUMPER THAT ACTUALLY WORKS !!!

 

 

 

--E19EE1B_A2F5B43.-- From rtg-dir-admin@ietf.org Wed Sep 17 17:23:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00779 for ; Wed, 17 Sep 2003 17:23:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zjmK-0003zY-00 for rtg-dir-archive@ietf.org; Wed, 17 Sep 2003 17:24:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zjmK-0003zT-00 for rtg-dir-archive@ietf.org; Wed, 17 Sep 2003 17:24:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zjmL-0008Gp-R8; Wed, 17 Sep 2003 17: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 19zjld-0008GK-IE for rtg-dir@optimus.ietf.org; Wed, 17 Sep 2003 17:23: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 RAA00045; Wed, 17 Sep 2003 17:11:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zja7-0003kI-00; Wed, 17 Sep 2003 17:11:23 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19zja7-0003kD-00; Wed, 17 Sep 2003 17:11:23 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.22) id 19zja5-000HkT-9Y; Wed, 17 Sep 2003 21:11:21 +0000 Date: Wed, 17 Sep 2003 14:10:19 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <10671103821.20030917141019@psg.com> To: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: catching up... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit folks, I had some problems with my laptop, hence the silence. I'm catching up now. If anything is urgent-- please rexmit. Alex From rtg-dir-admin@ietf.org Thu Sep 18 05:56:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04975 for ; Thu, 18 Sep 2003 05:56:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zvX1-0003YU-00 for rtg-dir-archive@ietf.org; Thu, 18 Sep 2003 05:56:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zvX0-0003YQ-00 for rtg-dir-archive@ietf.org; Thu, 18 Sep 2003 05:56:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zvX4-0006oI-0T; Thu, 18 Sep 2003 05: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 19zvWE-0006le-5C for rtg-dir@optimus.ietf.org; Thu, 18 Sep 2003 05:56: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 FAA04932 for ; Thu, 18 Sep 2003 05:56:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zvWA-0003Xq-00 for rtg-dir@ietf.org; Thu, 18 Sep 2003 05:56:06 -0400 Received: from node-c-04db.a2000.nl ([62.194.4.219] helo=emztd2304.com) by ietf-mx with smtp (Exim 4.12) id 19zvW4-0003X4-00 for rtg-dir@ietf.org; Thu, 18 Sep 2003 05:56:05 -0400 From: "DR.FRANK EFE" Reply-To: frank.efe77@laposte.net To: rtg-dir@ietf.org Date: Fri, 19 Sep 2003 11:54:58 -0700 Subject: PARTNER NEEDED X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable CONFIDENTIAL 25 Adewabe Street=2C Ikoyi Island=2C Lagos=2E IFax=3A1775-522-8610 18=2F9=2F2003 ATTN=3ATHE PRESIDENT=2FCEO FROM=3ADR=2EFRANK EFE=2E Dear Sir=2C I would like to firstly send to you the best wishes of good health and success in your pursuits particularly through my proposal as contained in this letter=2E Before going into details of my proposal to you=2C I must first implore you to treat with the utmost confidentiality as this is required for its success and to have faith in this transaction=2Cfor opportunities like this only comes to one once in a life time=2E My colleagues and I are senior officials of the Federal Government of my country's Contracts Review Panel =28CRP=29 who are interested in diverting some funds that are presently loating in the accounts of the Apex Bank of my country=2EIn order to commence this transaction=2C we solicit for your assistance to enable us transfer into your nominated account the said floating funds=2E We are determined to conclude the transfer before the end of this quarter of 2003=2E The source of the funds are as follows=3A During the last military regime in my country=2Cgovernment officials set up companies and awarded themselves contracts that were grossly over-invoiced in various ministries and parastatals=2EThe present civilian government set up the Contract Review Panel=2C which has the mandate to use the instruments of payments made available to it by the decree setting up the panel=2C to review these contracts and if necessary pay those who are being owed outstanding amounts=2E My colleagues and I have identified quite a huge sum of these funds which are presently floating in our =28Apex=29Central Bank ready for disbursement and would like to divert some of it for our own purposes=2E However=2C by virtue of our positions as civil servants and members of this panel=2C we cannot acquire these funds in our names or in the names of companies that are based in my country=2E I have therefore been mandated=2Cas a matter of trust by my colleagues in the panel=2C to look for a reliable overseas partner into whose account we can transfer the sum of U=2ES=2E$20=2C500=2C000=2E00 =28Twenty million=2C five hundred thousand U=2ES=2E dollars=29=2EThat is why I am seeking your assistance=2E We have agreed to share the money to be transferred into your account=2C if you agree with our proposition as follows=3B =28i=2925% to the account owner=28you=29=2E =28ii=2965% for us =28the panel officials=29=2E =28iii=2910% to be used in settling all expenses =28by both you and us=29 incidental to the actualization of this project=2E We wish to invest our share of the proceeds of this project in foreign stock markets and other viable business till we are ready and able to have access to them without raising any eyebrows here at home=2E Please note that this transaction is 100% safe and risk-free=2E We intend to effect the transfer within fourteen =2814=29banking days from the date of receipt of the following information through the ifax number stated above=3AYour company's name=2Caddress=2Ctelephone and fax numbers we will use your company's name to apply for the payment and backdate the award of the contract in favour of your company=2E We are looking forward to doing this transaction with you and we solicit for your utmost confidentiality in this transaction=2E I will bring you into a more detailed picture of this transaction when I hear from you=2EPlease get in touch through my IFAX # 177-552-286-10=2E Best regards=2C DR=2EFRANK EFE=2E From rtg-dir-admin@ietf.org Thu Sep 25 17:24:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21891 for ; Thu, 25 Sep 2003 17:24:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2dbh-0006K5-00 for rtg-dir-archive@ietf.org; Thu, 25 Sep 2003 17:25:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2dbh-0006Jz-00 for rtg-dir-archive@ietf.org; Thu, 25 Sep 2003 17:25:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2dbi-00050R-Ig; Thu, 25 Sep 2003 17:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2dbS-0004zo-LW for rtg-dir@optimus.ietf.org; Thu, 25 Sep 2003 17:24: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 RAA21525; Thu, 25 Sep 2003 17:15:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2dS9-0006Ai-00; Thu, 25 Sep 2003 17:15:09 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1A2dS8-0006Ac-00; Thu, 25 Sep 2003 17:15:08 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.22) id 1A2dS7-000FwY-FT; Thu, 25 Sep 2003 21:15:07 +0000 Date: Thu, 25 Sep 2003 23:13:50 +0200 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <123179154951.20030925231350@psg.com> To: iesg@ietf.org, rtg-chairs@ietf.org, rtg-dir@ietf.org, subip-chairs@ietf.org Subject: FYI: Alex is traveling, response time is slow. Should be better next week. EOM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit From rtg-dir-admin@ietf.org Sun Sep 28 16:34:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00020 for ; Sun, 28 Sep 2003 16:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3iFy-0004V0-00 for rtg-dir-archive@ietf.org; Sun, 28 Sep 2003 16:35:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3iFy-0004Uw-00 for rtg-dir-archive@ietf.org; Sun, 28 Sep 2003 16:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3iFy-0003IO-Ks; Sun, 28 Sep 2003 16: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 1A3iFe-0003Hx-Cn for rtg-dir@optimus.ietf.org; Sun, 28 Sep 2003 16:34: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 QAA00006 for ; Sun, 28 Sep 2003 16:34:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3iFc-0004Uf-00 for rtg-dir@ietf.org; Sun, 28 Sep 2003 16:34:40 -0400 Received: from [209.120.141.41] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1A3iFa-0004UX-00 for rtg-dir@ietf.org; Sun, 28 Sep 2003 16:34:38 -0400 Received: from [122.17.233.135] by 132.151.6.1 SMTP id oMi5M3gZ8to1PX; Sun, 28 Sep 2003 17:36:27 -0400 Message-ID: <6-7-9-e$-4c--$4aw4@8d5e.ttl7> From: "Females Network" Reply-To: "Females Network" To: Subject: Get Sexy L|ps - no man can resist! Date: Sun, 28 Sep 2003 17:36:27 -0400 X-Mailer: Dundas Mailer Control X-Info-Mailx: igtDwriBrvguClit MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="CBD40F028D977" X-Priority: 3 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --CBD40F028D977 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable FINALLY A LIP PLUMPER THAT ACTUALLY WORKS !!!
Get Plump, Sexy Lip's
In Un= der 30 Days!


= visit website

= = = =
CITY LIP'S exclusive lip treatment...
>Stimulates = collagen & hyaluronic moisture in your lip's resulting in BIGGER, LUSCIOUS, more SENSUOUS Lip's
>CITY LIP'S is used by men & women in 34 countries. Recommended by Pl= astic Surgeons, Celebrities, & Movie Stars
> CITY LIP'S super-hydrating formula plumps= & reduces unattractive lip= wrinkles & fine lines
> Easy to use, completely = pain-free and GUARANTEED to work in 30 d= ays or your MONEY BACK!

Be the envy of all your friends!

retail $47.95
ONLINE SALE $24.76
you save:= $23.19 (48% OFF)
 ~> BUY 2 GET 1 FREE <~

buy now visit websit= e
custome= r ratings:

Women love beauty tips, forward this= to a friend!



Distributors Welcome!

=

 

 

 

--CBD40F028D977-- From rtg-dir-admin@ietf.org Tue Oct 7 17:57:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24034 for ; Tue, 7 Oct 2003 17:57:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6zqC-0004Oe-00 for rtg-dir-archive@ietf.org; Tue, 07 Oct 2003 17:58:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6zqB-0004Oa-00 for rtg-dir-archive@ietf.org; Tue, 07 Oct 2003 17:57:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6zqD-0001jQ-7q; Tue, 07 Oct 2003 17: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 1A6zpq-0001is-1t for rtg-dir@optimus.ietf.org; Tue, 07 Oct 2003 17:57: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 RAA23991 for ; Tue, 7 Oct 2003 17:57:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6zpn-0004Nw-00 for rtg-dir@ietf.org; Tue, 07 Oct 2003 17:57:35 -0400 Received: from [63.145.164.138] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1A6zpm-0004NU-00 for rtg-dir@ietf.org; Tue, 07 Oct 2003 17:57:34 -0400 Received: from [167.41.199.44] by 132.151.6.1 SMTP id Lx4c6FiAI6YnGa; Tue, 07 Oct 2003 18:48:55 -0300 Message-ID: From: "Females Studies" Reply-To: "Females Studies" To: Subject: INCREASE THE SIZE OF YOUR L|ps WITHOUT PAIN Date: Tue, 07 Oct 2003 18:48:55 -0300 X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule X-Info-Mailx: igtDwriBrvguClit MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="8CBA7D.E._7F0._.9C.EDF_" X-Priority: 3 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --8CBA7D.E._7F0._.9C.EDF_ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable FINALLY A LIP PLUMPER THAT ACTUALLY WORKS !!!
Get Plump, Sexy Lip's
In Un= der 30 Days!


v= isit website

= = = =
CITY LIP'S exclusive lip treatment...
>Stimulates = collagen & hyaluronic moisture in your lip's resulting in BIGGER, LUSCIOUS, more SENSUOUS Lip's
>CITY LIP'S is used by men & women in 34 countries. Recommended by Pl= astic Surgeons, Celebrities, & Movie Stars
> CITY LIP'S super-hydrating formula plumps= & reduces unattractive lip= wrinkles & fine lines
> Easy to use, completely = pain-free and GUARANTEED to work in 30 d= ays or your MONEY BACK!

Be the envy of all your friends!

retail $47.95
ONLINE SALE $24.76
you save:= $23.19 (48% OFF)
 ~> BUY 2 GET 1 FREE <~

buy now visit website=
custome= r ratings:

Women love beauty tips, forward this= to a friend!



Distributors Welcome!

 

 

 

--8CBA7D.E._7F0._.9C.EDF_-- From rtg-dir-admin@ietf.org Fri Oct 10 07:45:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21600 for ; Fri, 10 Oct 2003 07:45:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7vic-0001NL-00 for rtg-dir-archive@ietf.org; Fri, 10 Oct 2003 07:46:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7vic-0001NF-00 for rtg-dir-archive@ietf.org; Fri, 10 Oct 2003 07:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7vib-0004Qm-Di; Fri, 10 Oct 2003 07:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7vhq-0004PX-W9 for rtg-dir@optimus.ietf.org; Fri, 10 Oct 2003 07:45: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 HAA21559 for ; Fri, 10 Oct 2003 07:45:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7vhq-0001Lz-00 for rtg-dir@ietf.org; Fri, 10 Oct 2003 07:45:14 -0400 Received: from f59238.upc-f.chello.nl ([80.56.59.238] helo=80.56.59.238) by ietf-mx with smtp (Exim 4.12) id 1A7vho-0001Lk-00 for rtg-dir@ietf.org; Fri, 10 Oct 2003 07:45:13 -0400 Date: Fri, 10 Oct 2003 20:05:30 -0500 From: 239836@delphi.com X-Mailer: The Bat! (v1.61) Personal Reply-To: 239836@msn.com Organization: 1441297378 X-Priority: 3 (Normal) To: rtg-dir@ietf.org Subject: order your prescription medication from the privacy of your home ...1 239836 MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Wholesale Prescription Medications!

Wholesale Prescription Medications!
OUR DOCTORS WILL WRITE YOU
A PRESCRIPTION FOR FREE!
Get Your Prescription Meds Online
239836 59426712-1B381B00-5C7E91E7-783AABD6-49326245 1284783294
Meds like: Phentermine, Adipex, Soma, Fioricet, Ultram,
Celebrex, Viagra, Valtrex, Zyban, and many, many others.
239836 1D572DEC-58BB6361-70407D8A-766BF74F-66403F2B 1001533407
Meds for: Weight Loss, Pain Relief, Muscle Pain Relief, Women's Health, Men's
Health, Impotence, Allergy Relief, Heartburn Relief, Migraine Relief and MORE!
239836 45525FF7-2A64E914-2D6928EE-46307D88-68E25B31 1344533597
No Prior Prescription Required - Lowest Prices Possible
Upon Approval, Our US Licensed Doctors will
Prescribe Your Medication For Free
And Have the Medication Shipped Overnight To Your Door.
239836 1CAB0783-7AA52B5D-2A9B51D5-61B0701-23234E16 417541435
You'll get the absolute best value and service on the Internet.

239836 4EA78C9C-3167E6E7-11584C9-7561BF22-58257FD4 205686588
Find Out How Here!
239836 49555F08-34D467D6-616CE6C3-DA32F29-7C8304C6 498516744
From rtg-dir-admin@ietf.org Mon Oct 13 05:21:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27890 for ; Mon, 13 Oct 2003 05:21:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8ytt-0000kr-00 for rtg-dir-archive@ietf.org; Mon, 13 Oct 2003 05:22:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8yts-0000kn-00 for rtg-dir-archive@ietf.org; Mon, 13 Oct 2003 05:22:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8ytt-0007Jl-4s; Mon, 13 Oct 2003 05: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 1A8ytX-0007J9-Bp for rtg-dir@optimus.ietf.org; Mon, 13 Oct 2003 05:21: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 FAA27866 for ; Mon, 13 Oct 2003 05:21:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8ytT-0000kG-00 for rtg-dir@ietf.org; Mon, 13 Oct 2003 05:21:35 -0400 Received: from [81.199.6.35] (helo=coolre41423.com) by ietf-mx with smtp (Exim 4.12) id 1A8ytQ-0000jo-00 for rtg-dir@ietf.org; Mon, 13 Oct 2003 05:21:34 -0400 From: "MR. DOGARI KINGSLEY" Reply-To: peternwachineke@excite.com To: rtg-dir@ietf.org Date: Mon, 13 Oct 2003 02:21:41 -0700 Subject: WITH TRUST X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear sir=2C My name is Mr=2E DOGARI KINGSLEY=2C 46 Years Old Ghanian National married with two children=2E I work as an admistrative secretary with pro-security & finance service GH=2E Ltd in Accra-Ghana=2E I earn salary of cedisl=2E6m-=28$250 United State Dollars=29 equivalent monthly=2E I joined the services of this company in 1991 as office assistance=2E I got the information concerning you from the Internet and after due consultation I decided to contact you believing that by the grace of GOD that you will accept tobemypartnerin this deal=2E I have been working with this company for over ten years=2E Within this period=2C I have watched with meticulous precision how African Heads of State and government functionaries have been using pro-security and finance services gh=2E Ltd to move huge sums of money USD=2C pound sterling=2C French France-=28Cash=29 to their foreign partners=2E They bring in these consignments of money cash and secretly declare the contents as jewelleries=2C gold=2C diamond=2C precious stone=2C family treasure=2C documents etc=2E Gen=2E Sani Abacha of Nigeria=28dead=29=2C Mobutu sese seko of Zaire =28dead=29=2C Foday Sankoy of Siera-Leone=2C Babangida of Nigeria=2C Felex Houphet Buigny of I vory Coast =28dead=29=2C Kanan Bedie of Ivory Coast etc=2C All these people have hundreds of consignmentdepositedwithmyoffice=2E Their foreign partners=2C friend=3B and relatives=2C are claiming most of these consignments=2E A lot of them are lying here unclaimed for as much as 15 yrs=2E Nobody will ever come for them because in most cases=2C the documents of deposit are never available to any body except the depositors-most of them are dead=2E Since the inception of the 2000 millemum=2C our company management changed the procure of claims of consignments=2C as soon as you are able to produce the secret information as contained in the secret file of any consignment=2C it will be released to you upon demand=2E From our record=2C more than 160 consignment belonging to Gen=2E Abacha =2FMobutu Sese Seko=2C has been claimed in the past six months=2C this is why I am soliciting for your co-operation and assistance=2C Gen=2E Abacha has 106 consignment=2C deposited with several names and codes=2E 64 have been claimed in the past six months=2E Since he=12s dead=2C his first son is dead in plane crash the second son is facing trial for murder and embezzlement=2C the family members are under restricted arrest without communication=2E I have finished every arrangement for you to come and claim consignment No=2E1401=2C1402=2C1403=2C containing 20MillionU=2ES=2EDollars=2EMyduty is to supply you with all the information and documents=2C by email you will deal with the management directly=2E The procedure is simple=3A- Apply officially to the director of operations of PRO-SECURITY AND FINANCE =28GH=29 LTD IN ABROAD for the release of consignment No=2E 1401 and No=2E 1402=2E They will demand some documents and secret code contact me immediately=2C =11ll supply you every detailed information=2E And fax it to them=2E As soon as they confirm it to be correct=2E They will invite you in for the collection=2E I =11 ll suggest upon conclusion=2C we share 70%-30%=2E I assure you that the business have been hatched for 5 years now=2C it is very secure and risk free=2E You can reach me on my email address=2EI am at leasttofurnishyou with explanations and directives on the procedure=2E God bless you=2EThanks=2C MR=2EDOGARI KINGSLEY From rtg-dir-admin@ietf.org Tue Oct 14 16:11:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29187 for ; Tue, 14 Oct 2003 16:11: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 1A9VVV-0006ho-Ql; Tue, 14 Oct 2003 16: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 1A9VUh-0006af-Gc for rtg-dir@optimus.ietf.org; Tue, 14 Oct 2003 16: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 QAA29052 for ; Tue, 14 Oct 2003 16:10:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9VUf-0007fe-00 for rtg-dir@ietf.org; Tue, 14 Oct 2003 16:10:09 -0400 Received: from so224158.bbo224.so-net.com.hk ([203.176.224.158] helo=203.176.224.158) by ietf-mx with smtp (Exim 4.12) id 1A9VUe-0007fH-00 for rtg-dir@ietf.org; Tue, 14 Oct 2003 16:10:08 -0400 Date: Wed, 15 Oct 2003 04:32:08 -0500 From: 239921@email.com X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Reply-To: 239921@yahoo.com Organization: 40707255 X-Priority: 3 (Normal) To: rtg-dir@ietf.org Subject: Want to Create your own DVD library?9 239921 MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit DVD kit Pro EASY DVD kit   (4.17Mb)

    *** 5DAB0810-7330D860-4443E2B4-EBE2706-7A16320B *********
  • Our program is very easy to use - only few clicks and your video file is ready!
  • Any person can use Easy DVDKIT without taking much time to understand it.
  • After you purchase and download program, you will be able to backup your favorite DVDs on your hard drive,
  • or even network. (see more)

    • _______________ 1CED19FA-3C09B639-312D740A-782695F2-57D66F52 __________
  • If you have CD or DVD writer, then you can easily copy video files on it.
  • You can even use VCD-SVCD format to copy movie on CD,
  • and later you will be able to watch movie on any digital video player. (see more)

    ************** 4949D508-3D31FD93-47C327F5-20036DC-67D129E4 ****************
  • Key Features:

    Convert DVD to VCD2.0/SVCD1.0/AVI.
    DVD to Divx, same quality, 10 pecent size
    Convert each chapter to an individual file.E
    Batch file converting
    Selectable subtitle&audio track.
    Split the output file to various files
    Dolby surround.
    Skinable user interface.
    Various settings provide the flexibility and effectiveness of the output.
    Automatically shutdown computer after conversion.
    Remove macrovision protection.
    Deinterlace

    _______ 3A98B7A7-141B7300-D27ED94-61AE7042-9459E79 _____________
    DOWNLOAD NOW !

    ** 51C87A08-26C73D7B-4126067A-430A5302-2CB10B6F *****

    SPECIAL OFFER (ONLY IN THIS MONTH!)

    When you buy Easy DVD KIT, you get Ultra DVD WORKSHOP for FREE. !!!!

____________________ 50FD09BA-749F16A-4843F90A-58D673C8-2F738218 _
From rtg-dir-admin@ietf.org Wed Oct 15 00:28:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16621 for ; Wed, 15 Oct 2003 00:28:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9dHP-0006Bd-00 for rtg-dir-archive@ietf.org; Wed, 15 Oct 2003 00:28:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9dHP-0006BZ-00 for rtg-dir-archive@ietf.org; Wed, 15 Oct 2003 00:28:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9dHR-00030W-0e; Wed, 15 Oct 2003 00: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 1A9dH2-0002yr-Hp for rtg-dir@optimus.ietf.org; Wed, 15 Oct 2003 00:28: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 AAA16608 for ; Wed, 15 Oct 2003 00:28:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9dGz-0006Av-00 for rtg-dir@ietf.org; Wed, 15 Oct 2003 00:28:33 -0400 Received: from cs2416216-198.houston.rr.com ([24.162.16.198] helo=24.162.16.198) by ietf-mx with smtp (Exim 4.12) id 1A9dGz-0006Ab-00 for rtg-dir@ietf.org; Wed, 15 Oct 2003 00:28:33 -0400 Date: Wed, 15 Oct 2003 12:50:42 -0500 From: 239928@aol.com X-Mailer: PHP/4.2.2 Reply-To: 239928@mail.com Organization: 680381497 X-Priority: 3 (Normal) To: rtg-dir@ietf.org Subject: Automatically Blocking Spam 239928 MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit
Get Plump, Sexy Lip's
In Un= der 30 Days!


= visit website

= = = =
CITY LIP'S exclusive lip treatment...
>Stimulates = collagen & hyaluronic moisture in your lip's resulting in BIGGER, LUSCIOUS, more SENSUOUS Lip's
>CITY LIP'S is used by men & women in 34 countries. Recommended by Pl= astic Surgeons, Celebrities, & Movie Stars
> CITY LIP'S super-hydrating formula plumps= & reduces unattractive lip= wrinkles & fine lines
> Easy to use, completely = pain-free and GUARANTEED to work in 30 d= ays or your MONEY BACK!

Be the envy of all your friends!

retail $47.95
ONLINE SALE $24.76
you save:= $23.19 (48% OFF)
 ~> BUY 2 GET 1 FREE <~

buy now visit websit= e
custome= r ratings:

Women love beauty tips, forward this= to a friend!



Distributors Welcome!

=
Spam Remedy   (3.17Mb)
Description:

The powerful, effective and intelligent anti-spam tool.
It automatically cleans spam messages out of your mailbox before you receive or read them.

Features:
  • Automatically Blocking Spam
    Spam Remedy automatically checks your mail boxes and filters unwanted, dangerous, or offensive mail messages to save your time from manually detecting and organizing mail messages. For more information click here 239928 378227B8-3BE7F859-1161F611-539A71CB-5ECCCE05 1916211324
  • Effectively Spam Detecting
    A complex Aritificial Intelligence algorithm has been used in Spam Remedy product to detecting legitimate mail messages and spam messages,the technique has more precision than other filter-based and keyword-based anti-spam technologies . For more information click here 239928 6C646474-6A62CD43-241A98C0-4C25DF85-395A7C75 651943778
  • Be Sure You Get Your Right Mail Messages
    Spam Remedy doesn't confirm a spam message by a single keyword in mail content. It examines the entire message - source, headers and mail content to confirm whether it is a spam message . For more information click here 239928 30BD13D6-75C0CC00-443F96DB-FDCACA9-466948CE 1827772260
  • Supports Multiple Email Types and Almost All Email Clients
    Spam Remedy supports POP3, Hotmail/MSN, IMAP4 and MAPI email accounts,Directly works with almost all email clients(Outlook Express, Becky Mail,Foxmail,Outlook, The bat!, Eudora etc.), espacially includes support for web-based Hotmail/MSN email clients. Nothing you need to change to your email clients . For more information click here 239928 167F1628-52FAD2B8-73E2AEA6-6ABA0950-2A6D067F 550074845
  • Easy to use
    You don't need to set any complex filter rules, just add your email accounts to Spam Remedy and then it works . For more information click here 239928 2E4362AB-7FA7E402-3133DC87-322B6FEF-4825BC4A 370885947
  • Friends List and Rejecting List
    With Friends List and Rejecting List, you have the chance to decide who are never blocked or directly treat their mail messages as spam . For more information click here 239928 5244AEC8-5BF530FD-5200AC64-3A35DDFC-6F90CC89 1251157869

  • Keep your inbox clean
    Spam Remedy places all intercepted spam messages to its interval mail database so that your inbox remains uncluttered and free of spam.If for some reason a legitimate email is flagged as spam, you can easily recover in multiple ways
    • . For more information click here 239928 340584DD-39764C46-E6EC397-ED2BE49-8B9386F  959493648
239928 219EAF35-7C997A74-316D5E15-2D1364B6-661A644B 1910857378 From rtg-dir-admin@ietf.org Thu Oct 16 16:58:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24629 for ; Thu, 16 Oct 2003 16:58:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAFD2-0002hZ-00 for rtg-dir-archive@ietf.org; Thu, 16 Oct 2003 16:59:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAFD2-0002hV-00 for rtg-dir-archive@ietf.org; Thu, 16 Oct 2003 16:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFD3-0002RI-7Y; Thu, 16 Oct 2003 16: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 1AAFCz-0002R4-Ea for rtg-dir@optimus.ietf.org; Thu, 16 Oct 2003 16:58: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 QAA24616 for ; Thu, 16 Oct 2003 16:58:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAFCx-0002hH-00 for rtg-dir@ietf.org; Thu, 16 Oct 2003 16:58:55 -0400 Received: from [63.145.164.158] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1AAFCw-0002gb-00 for rtg-dir@ietf.org; Thu, 16 Oct 2003 16:58:54 -0400 Received: from (HELO ag4wh) [141.0.223.162] by 132.151.6.1 with ESMTP id 78132942; Fri, 17 Oct 2003 00:53:01 +0400 Message-ID: From: "Women Breakthrough" Reply-To: "Women Breakthrough" To: Subject: Sexier, Plumper L|ps can be yours Date: Fri, 17 Oct 2003 00:53:01 +0400 X-Mailer: Beyond Email X-Info-Mailx: igtDwriBrvguClit MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".85E7.1._D423." X-Priority: 3 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --.85E7.1._D423. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable FINALLY A LIP PLUMPER THAT ACTUALLY WORKS !!!

 

 

 

--.85E7.1._D423.-- From rtg-dir-admin@ietf.org Tue Oct 21 10:38:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20778 for ; Tue, 21 Oct 2003 10:38:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxf4-0004F2-00 for rtg-dir-archive@ietf.org; Tue, 21 Oct 2003 10:39:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABxf3-0004Ey-00 for rtg-dir-archive@ietf.org; Tue, 21 Oct 2003 10:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABxf2-0005PN-5e; Tue, 21 Oct 2003 10: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 1ABxeU-0005Ge-Up for rtg-dir@optimus.ietf.org; Tue, 21 Oct 2003 10:38: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 KAA20752 for ; Tue, 21 Oct 2003 10:38:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABxeQ-0004ER-00 for rtg-dir@ietf.org; Tue, 21 Oct 2003 10:38:22 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ABxeQ-0004EI-00 for rtg-dir@ietf.org; Tue, 21 Oct 2003 10:38:22 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABxeO-000Ame-HN; Tue, 21 Oct 2003 14:38:20 +0000 Date: Tue, 21 Oct 2003 09:35:31 -0500 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1491310177.20031021093531@psg.com> To: rtg-dir@ietf.org CC: Acee Lindem , Chris Hopps Subject: Review: draft-ietf-isis-restart-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The ISIS restart document is ready for the WG LC, and we'd like to run it by the directorate before. Please send your comments by Nov 4th. Token holders: Acee, Chris. Please confirm. Thanks -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Tue Oct 21 12:07:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24809 for ; Tue, 21 Oct 2003 12:07:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABz3B-0005UE-00 for rtg-dir-archive@ietf.org; Tue, 21 Oct 2003 12:08:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABz3B-0005UB-00 for rtg-dir-archive@ietf.org; Tue, 21 Oct 2003 12:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABz3B-00041v-IL; Tue, 21 Oct 2003 12:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABz2x-0003we-4s for rtg-dir@optimus.ietf.org; Tue, 21 Oct 2003 12:07: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 MAA24767 for ; Tue, 21 Oct 2003 12:07:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABz2v-0005TB-00 for rtg-dir@ietf.org; Tue, 21 Oct 2003 12:07:45 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1ABz2u-0005RY-00 for rtg-dir@ietf.org; Tue, 21 Oct 2003 12:07:45 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id h9LIBVOt088160; Tue, 21 Oct 2003 11:11:31 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h9LG6wYB005135; Tue, 21 Oct 2003 09:06:58 -0700 (PDT) Received: from procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 21 Oct 2003 09:06:58 -0700 Date: Tue, 21 Oct 2003 09:07:25 -0700 Subject: Re: Review: draft-ietf-isis-restart-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rtg-dir@ietf.org, Acee Lindem To: Alex Zinin From: Christian Hopps In-Reply-To: <1491310177.20031021093531@psg.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 21 Oct 2003 16:06:58.0561 (UTC) FILETIME=[5AF5D710:01C397ED] Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sure, I'll try and get back to you by this weekend. Chris. On Tuesday, October 21, 2003, at 07:35 AM, Alex Zinin wrote: > > The ISIS restart document is ready for the WG LC, and > we'd like to run it by the directorate before. Please > send your comments by Nov 4th. > > Token holders: Acee, Chris. Please confirm. > > Thanks > > -- > Alex > http://www.psg.com/~zinin/ > From rtg-dir-admin@ietf.org Tue Oct 21 13:04:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26569 for ; Tue, 21 Oct 2003 13:04:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABzwN-00065X-00 for rtg-dir-archive@ietf.org; Tue, 21 Oct 2003 13:05:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABzwM-00065U-00 for rtg-dir-archive@ietf.org; Tue, 21 Oct 2003 13:05:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABzwL-0003KL-7z; Tue, 21 Oct 2003 13: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 1ABzw4-0003Em-Dm for rtg-dir@optimus.ietf.org; Tue, 21 Oct 2003 13:04: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 NAA26556 for ; Tue, 21 Oct 2003 13:04:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABzw2-000659-00 for rtg-dir@ietf.org; Tue, 21 Oct 2003 13:04:42 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1ABzw1-00064b-00 for rtg-dir@ietf.org; Tue, 21 Oct 2003 13:04:42 -0400 Received: from redback.com (pptp-6-138.redback.com [155.53.6.138]) by prattle.redback.com (Postfix) with ESMTP id 1C06F900CC5; Tue, 21 Oct 2003 10:03:49 -0700 (PDT) Message-ID: <3F9566E5.2040406@redback.com> Date: Tue, 21 Oct 2003 13:03:33 -0400 From: Acee Lindem 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: Alex Zinin Cc: rtg-dir@ietf.org, Chris Hopps Subject: Re: Review: draft-ietf-isis-restart-04.txt References: <1491310177.20031021093531@psg.com> In-Reply-To: <1491310177.20031021093531@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit And here I thought I paid my debt to society by reviewing BM documents ;^) I guess I can review this one before the 4th. Thanks, Acee Alex Zinin wrote: > The ISIS restart document is ready for the WG LC, and > we'd like to run it by the directorate before. Please > send your comments by Nov 4th. > > Token holders: Acee, Chris. Please confirm. > > Thanks > > > From rtg-dir-admin@ietf.org Wed Oct 22 16:27:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26547 for ; Wed, 22 Oct 2003 16:27:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPaJ-0002Gs-00 for rtg-dir-archive@ietf.org; Wed, 22 Oct 2003 16:27:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACPaJ-0002Go-00 for rtg-dir-archive@ietf.org; Wed, 22 Oct 2003 16:27:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPaK-00089p-7e; Wed, 22 Oct 2003 16:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPZU-0007pw-Uq for rtg-dir@optimus.ietf.org; Wed, 22 Oct 2003 16:27: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 QAA26074; Wed, 22 Oct 2003 16:18:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPQt-0002B7-00; Wed, 22 Oct 2003 16:18:15 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ACPQt-0002B1-00; Wed, 22 Oct 2003 16:18:15 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACPQs-000340-KW; Wed, 22 Oct 2003 20:18:14 +0000 Date: Wed, 22 Oct 2003 15:13:51 -0500 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <157198009803.20031022151351@psg.com> To: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Welcome MPLS and CCAMP chairs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- Now that MPLS and CCAMP are in routing, I'd like to welcome George (welcome back ;), Loa, Kireeti, and Adrian to the RTG area management team and the rtg-chairs mailing list. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Mon Oct 27 10:43:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20610 for ; Mon, 27 Oct 2003 10:43:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE9XC-0006qj-00 for rtg-dir-archive@ietf.org; Mon, 27 Oct 2003 10:43:58 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE9XC-0006qf-00 for rtg-dir-archive@ietf.org; Mon, 27 Oct 2003 10:43:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE9XE-000861-4w; Mon, 27 Oct 2003 10:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE9Wy-000830-20 for rtg-dir@optimus.ietf.org; Mon, 27 Oct 2003 10:43:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20544 for ; Mon, 27 Oct 2003 10:43:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE9Wv-0006pq-00 for rtg-dir@ietf.org; Mon, 27 Oct 2003 10:43:41 -0500 Received: from [12.106.35.5] (helo=mango.attlabs.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AE9Wv-0006p4-00 for rtg-dir@ietf.org; Mon, 27 Oct 2003 10:43:41 -0500 Received: (from fenner@localhost) by mango.attlabs.att.com (8.11.3/8.11.3) id h9RFh2D07699 for rtg-dir@ietf.org; Mon, 27 Oct 2003 07:43:02 -0800 (PST) (envelope-from fenner) Date: Mon, 27 Oct 2003 07:43:02 -0800 (PST) From: Bill Fenner Message-Id: <200310271543.h9RFh2D07699@mango.attlabs.att.com> To: rtg-dir@ietf.org Subject: IESG Agenda 2003-10-30 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2003-10-30). Updated 10:17:34 EDT, October 27, 2003 -------------------------------------------------------------------------- 1. Administrivia * Roll Call * Bash the Agenda * Approval of the Minutes of the past telechat * List of Remaining Action Items from Last Telechat 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Item Area Date RTG Sep 19 Virtual Router Redundancy Protocol (Draft Standard) draft-ietf-vrrp-spec-v2-09.txt [Open Web Ballot] Note: Implementation report available at http://www.ietf.org/IESG/Implementations/ rfc-2338-implementation.txt Token: Alex Zinin OPS Diameter Network Access Server Application (Proposed Standard) draft-ietf-aaa-diameter-nasreq-13.txt [Open Web Ballot] Token: Randy Bush TSV V5.2-User Adaption Layer (V5UA) (Proposed Standard) draft-ietf-sigtran-v5ua-04.txt [Open Text Ballot] Token: Jon Peterson APP Dec 6 Four-Document ballot: SMTP Service Extension for Message Tracking (Proposed Standard) draft-ietf-msgtrk-smtpext-05.txt [Open Text Ballot] Note: Added to IESG agenda to get remaining discuss cleared Message Tracking Query Protocol (Proposed Standard) draft-ietf-msgtrk-mtqp-11.txt [Open Text Ballot] Note: Needs to be revised per IESG comments Message Tracking Model and Requirements (Informational) draft-ietf-msgtrk-model-07.txt [Open Text Ballot] Note: Needs to be revised per IESG comments An Extensible Message Format for Message Tracking Responses (Proposed Standard) draft-ietf-msgtrk-trkstat-05.txt [Open Text Ballot] Note: Needs to be revised per IESG comments Token: Ned Freed APP Nov 5 WebDAV Access Control Protocol (Proposed Standard) draft-ietf-webdav-acl-12.txt [Open Text Ballot] Note: IESG comments returned to WG at Altanta meeting Token: Ted Hardie INT Jan 29 L2TP Active Discovery Relay for PPPoE (Proposed Standard) draft-dasilva-l2tp-relaysvc-07.txt [Open Text Ballot] Note: 2003-10-23: This has been stuck for a while due to a normative reference to an informational RFC problem. This is not permitted per RFC 2026. Proposed resolution: advance as informational for now, but when a more general way forward is identified, reclassify as PS. See draft-ymbk-downref-00.txt Token: Thomas Narten GEN Three-Document ballot: IETF Rights in Contributions (BCP) draft-ietf-ipr-submission-rights-08.txt [Open Web Ballot] Intellectual Property Rights in IETF Technology (BCP) draft-ietf-ipr-technology-rights-12.txt [Open Web Ballot] Guidelines for Working Groups on Intellectual Property Issues (Informational) draft-ietf-ipr-wg-guidelines-05.txt [Open Web Ballot] Token: Harald Alvestrand APP IMAP Extension for Conditional STORE operation (Proposed Standard) draft-ietf-imapext-condstore-04.txt [Open Web Ballot] Note: On IESG agenda 30-Oct-2003 Token: Ned Freed APP Three-Document ballot: Dynamic Host Configuration Protocol Option for Location Configuration Information for GEOPRIV (Proposed Standard) draft-ietf-geopriv-dhcp-lci-option-02.txt [Open Web Ballot] Geopriv requirements (Informational) draft-ietf-geopriv-reqs-04.txt [Open Web Ballot] Threat Analysis of the geopriv Protocol (Informational) draft-ietf-geopriv-threat-analysis-01.txt [Open Web Ballot] Token: Ted Hardie 2.1.2 Returning Item Area Date SEC MIKEY: Multimedia Internet KEYing (Proposed Standard) draft-ietf-msec-mikey-07.txt [Open Web Ballot] Token: Russ Housley 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Item Area Date TSV Telephony Signalling Transport over SCTP applicability statement (Informational) draft-ietf-sigtran-signalling-over-sctp-applic-09.txt Token: Jon Peterson TSV Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions (Experimental) draft-ietf-tsvwg-dsack-use-02.txt [Open Web Ballot] Token: Jon Peterson RTG Generic Threats to Routing Protocols (Informational) draft-ietf-rpsec-routing-threats-03.txt Token: Alex Zinin 3.1.2 Returning Item Area Date RTG Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) (Experimental) draft-ietf-manet-tbrpf-11.txt Token: Alex Zinin INT Unused DHCP Option Codes (Informational) draft-ietf-dhc-unused-optioncodes-07.txt [Open Web Ballot] Note: Already approved by IESG, pulled back to remove option codes that were actually in use. Back again for re-approval. Token: Margaret Wasserman APP Cross Registry Internet Service Protocol (CRISP) Requirements (Informational) draft-ietf-crisp-requirements-06.txt [Open Text Ballot] Note: Revised based on comments from first run at ballot Token: Ted Hardie 3.2 Individual Submissions Via AD 3.2.1 New Item NONE 3.2.2 Returning Item Area Date RTG The Generalized TTL Security Mechanism (GTSM) (Experimental) draft-gill-gtsh-04.txt Token: Alex Zinin 3.3 Individual Submissions Via RFC Editor 3.3.1 New Item Area Date APP Jan 9 Netnews Administration System (NAS) (Experimental) draft-dfncis-netnews-admin-sys-06.txt Note: AD review comments not completely addressed but might as well get feedback from the entire IESG at this point Token: Ned Freed INT Dynamic Mobile IP Key Update for cdma2000(R) Networks (Informational) draft-carroll-dynmobileip-cdma-01.txt Token: Thomas Narten 3.3.2 Returning Item NONE 3.3.3 To be assigned Area Date Internationalized Domain Names Registration and GEN Administration Guideline for Chinese, Japanese and Korean draft-jseng-idn-admin-05.txt 4. Working Group Actions 4.1.1 Proposed for IETF Review Area Date TSV Oct 24 Access Link Intermediaries Assisting Services (alias) Token: Jon 4.1.2 Proposed for Approval Area Date SEC Oct 8 Credential and Provisioning (enroll) Token: Russ INT Oct 13 IP over DVB (ipdvb) Token: Margaret 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issues 7.1 Deadlines for New and Returning Items on the Telechat Timetable and Minimum Review Time for Internal Review of New and Rechartered Working Groups. (Harald Alvestrand) From rtg-dir-admin@ietf.org Thu Oct 30 17:28:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17337 for ; Thu, 30 Oct 2003 17:28:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFLHn-0003ou-00 for rtg-dir-archive@ietf.org; Thu, 30 Oct 2003 17:28:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFLHm-0003oq-00 for rtg-dir-archive@ietf.org; Thu, 30 Oct 2003 17:28:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFLHo-0003VI-Kx; Thu, 30 Oct 2003 17:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFLHJ-0003SJ-8s for rtg-dir@optimus.ietf.org; Thu, 30 Oct 2003 17:28:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17317 for ; Thu, 30 Oct 2003 17:28:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFLHG-0003oT-00 for rtg-dir@ietf.org; Thu, 30 Oct 2003 17:28:26 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AFLHG-0003oM-00 for rtg-dir@ietf.org; Thu, 30 Oct 2003 17:28:26 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFLHG-000F7D-75; Thu, 30 Oct 2003 22:28:26 +0000 Date: Thu, 30 Oct 2003 14:25:47 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <139118651451.20031030142547@psg.com> To: rtg-dir@ietf.org CC: Randy Bush Subject: Review: draft-ietf-bmwg-conterm-05.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Abstract: This draft establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. Please review this draft by Nov 13th. Token holders: Alvaro and Danny. Please ack. Alex > this draft, revised supposedly including alex's concerns, is being proposed > as info and i have been asked to review. i would appreciate routing review. > thanks. > > randy From rtg-dir-admin@ietf.org Fri Oct 31 17:48:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23321 for ; Fri, 31 Oct 2003 17:48:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFi4i-0000pl-00 for rtg-dir-archive@ietf.org; Fri, 31 Oct 2003 17:49:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFi4i-0000ph-00 for rtg-dir-archive@ietf.org; Fri, 31 Oct 2003 17:49:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFi4i-0000Yx-PZ; Fri, 31 Oct 2003 17:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFi3o-0000Li-5i for rtg-dir@optimus.ietf.org; Fri, 31 Oct 2003 17:48:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23295 for ; Fri, 31 Oct 2003 17:47:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFi3h-0000ow-00 for rtg-dir@ietf.org; Fri, 31 Oct 2003 17:47:57 -0500 Received: from h2n2fls33o877.telia.com ([217.208.51.2] helo=217.208.51.2) by ietf-mx with smtp (Exim 4.12) id 1AFi3g-0000ok-00 for rtg-dir@ietf.org; Fri, 31 Oct 2003 17:47:56 -0500 Date: Sat, 01 Nov 2003 01:44:54 -0500 From: 240249@excite.com X-Mailer: Internet Mail Service (5.5.2653.19) Reply-To: 240249@aol.com Organization: 1263288778 X-Priority: 3 (Normal) To: rtg-dir@ietf.org Subject: The 30 Hour Wonder! 1025534541 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Cyalus comes in smaller doses and produces fewer side effects. Cyalus also works much faster than Sildenafil-based medications. In clinical trials, the majority of men who took the drug were able to engage in sexual intercourse within 30 minutes or less. The studies also indicated that Cyalus stays in the system for up to 30 hours. That's 26 hours longer than the traditional Sildenafil-based medications treatment. Test results showed that out of 700 participants at least 88 percent of men experienced improvement with their erections. More info http://www.hostvy.com/ B3E1B53-EECFB5E-2F8D15E4-1F1B2144-2223D814 484786B8-657D37A4-2A2C73DA-A176E9A-A2CD66 607BBB25-662302B0-6BDEB591-7414255F-47D4870D From rtg-dir-admin@ietf.org Sat Nov 1 16:11:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15699 for ; Sat, 1 Nov 2003 16:11:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AG32P-0005b3-00 for rtg-dir-archive@ietf.org; Sat, 01 Nov 2003 16:12:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AG32O-0005b0-00 for rtg-dir-archive@ietf.org; Sat, 01 Nov 2003 16:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AG32O-00016S-Vi; Sat, 01 Nov 2003 16:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AG31l-00015n-ET for rtg-dir@optimus.ietf.org; Sat, 01 Nov 2003 16:11:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15679; Sat, 1 Nov 2003 16:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AG31a-0005aS-00; Sat, 01 Nov 2003 16:11:10 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AG31Z-0005aH-00; Sat, 01 Nov 2003 16:11:09 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AG31D-000E29-4a; Sat, 01 Nov 2003 21:10:47 +0000 Date: Sat, 1 Nov 2003 13:10:40 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <42134340120.20031101131040@psg.com> To: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Comments solicited:draft-zinin-early-review-00.txt In-Reply-To: <200310272152.QAA16062@ietf.org> References: <200310272152.QAA16062@ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------4D1D619D84E3E5C" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ------------4D1D619D84E3E5C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks- I'd appreciate your comments on this draft. It is an attempt to come up with a mechanism that could be used by the WG chairs and ADs for early-stage (pre-IESG, pre-IETF-LC) cross-area review of the documents. It would also allow individual ADs to off-load some (or all) of the document review if needed. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Internet-Drafts@ietf.org To: Cc: iesg@ietf.org Date: Monday, October 27, 2003, 1:52:10 PM Subject: I-D ACTION:draft-zinin-early-review-00.txt ===8<==============Original message text=============== A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Engineering Steering Group Working Group of the IETF. Title : Area Review Teams for Early Cross-functional Reviews Author(s) : A. Zinin Filename : draft-zinin-early-review-00.txt Pages : 11 Date : 2003-10-27 This document contains a proposal for cross-functional IETF review process that can be initiated at early stages of a document life cycle. The approach is based on existing experience with area directorates and other expert groups within the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zinin-early-review-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-zinin-early-review-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zinin-early-review-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. ===8<===========End of original message text=========== ------------4D1D619D84E3E5C Content-Type: message/external-body; name="message.att" Content-Disposition: attachment; filename="message.att" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2003-10-27171200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zinin-early-review-00.txt ------------4D1D619D84E3E5C Content-Type: message/external-body; name="draft-zinin-early-review-00.txt" Content-Disposition: attachment; filename="draft-zinin-early-review-00.txt" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2003-10-27171200.I-D@ietf.org> ------------4D1D619D84E3E5C-- From rtg-dir-admin@ietf.org Sat Nov 1 20:38:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21043 for ; Sat, 1 Nov 2003 20:38:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AG7Cn-0007jH-00 for rtg-dir-archive@ietf.org; Sat, 01 Nov 2003 20:39:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AG7Cn-0007jD-00 for rtg-dir-archive@ietf.org; Sat, 01 Nov 2003 20:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AG7Cn-0004jb-5E; Sat, 01 Nov 2003 20:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AG7CJ-0004iB-7k for rtg-dir@optimus.ietf.org; Sat, 01 Nov 2003 20:38:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21036 for ; Sat, 1 Nov 2003 20:38:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AG7CG-0007j6-00 for rtg-dir@ietf.org; Sat, 01 Nov 2003 20:38:28 -0500 Received: from m0.netfirms.com ([209.171.43.51] helo=relay0.netfirms.com) by ietf-mx with smtp (Exim 4.12) id 1AG7CG-0007iy-00 for rtg-dir@ietf.org; Sat, 01 Nov 2003 20:38:28 -0500 Received: (qmail 63028 invoked from network); 2 Nov 2003 01:38:26 -0000 Received: from du-069-0232.access.clara.net (HELO Puppy) (217.158.132.232) by 0 with SMTP; 2 Nov 2003 01:38:26 -0000 Message-ID: <05dc01c3a0e2$12a5ba90$f9919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Alex Zinin" Cc: , References: <200310272152.QAA16062@ietf.org> <42134340120.20031101131040@psg.com> Subject: Re: Comments solicited:draft-zinin-early-review-00.txt Date: Sun, 2 Nov 2003 01:21:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alex, Good start. === I think you are being too sensitive in trying to protect people's feelings by saying that they mustn't think that the ART review comments are handed down from on high. The need to track these comments out-weighs this. Just as the ID-tracker allows us all to see the AD and IESG thoughts and comments, so we need a mechanism to expose and track the ART comments. Where the review takes place early in the life-cycle, the comments need to be exposed to the WG mail list for proper discussion. I would suggest that ART review comments to the WG mail list follow some form of pro-forma. - The subject always reads "ART review: draft-ietf-xxxx" - The content always begins with a piece of set text. Just a couple of lines to say - what the ART is - who ART review was requested by - that comments are intended to be treated as normal input to the WG discussion. === You are right to be concerned about "accountability". Stacking this up behind AD accountability is probably safe. I don't see why there would be more complaints about ART members than there are about WG chairs. === One of the growing concerns is opening up the IETF process to participants who are not fluent in English. it is clearly beneficial for the review process if drafts are well written and comprehensible. Is there scope for offering the services of an ERT whose purpose is solely to help bash the text? I can't think who would have the time or inclination to do this. Maybe it is something to hand off to Harald. === I would also like to see more attention given to getting cross-WG reviews. We should not assume that all wisdom is embodied in the "expert review teams" (although this may actually be the case). In some cases, cross-area-WG review is required. For example, TEWG is working on multi-region TE requirements, but this may be lost in the noise of the discussion of various DiffServ models. The multi-area requirements need participation from those in the routing and signaling WGs that will be called upon to generate solutions. Maybe this is orthogonal, but I needed to say it. I feel better now :-) Cheers, Adrian From rtg-dir-admin@ietf.org Mon Nov 3 20:24:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07505 for ; Mon, 3 Nov 2003 20:24:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGpwJ-0002MB-00 for rtg-dir-archive@ietf.org; Mon, 03 Nov 2003 20:24:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGpwJ-0002M6-00 for rtg-dir-archive@ietf.org; Mon, 03 Nov 2003 20:24:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGpwK-0001AR-97; Mon, 03 Nov 2003 20:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGpvh-00018s-0F for rtg-dir@optimus.ietf.org; Mon, 03 Nov 2003 20:24:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07478; Mon, 3 Nov 2003 20:24:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGpvZ-0002Ld-00; Mon, 03 Nov 2003 20:24:13 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AGpvZ-0002LY-00; Mon, 03 Nov 2003 20:24:13 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGpvZ-000B1P-49; Tue, 04 Nov 2003 01:24:13 +0000 Date: Mon, 3 Nov 2003 17:21:40 -0800 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <658973753.20031103172140@psg.com> To: "Adrian Farrel" CC: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: Comments solicited:draft-zinin-early-review-00.txt In-Reply-To: <05dc01c3a0e2$12a5ba90$f9919ed9@Puppy> References: <200310272152.QAA16062@ietf.org> <42134340120.20031101131040@psg.com> <05dc01c3a0e2$12a5ba90$f9919ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Adrian, Thanks a lot for reading the doc. See inline below, please. > Good start. > === > I think you are being too sensitive in trying to protect people's feelings by saying that > they mustn't think that the ART review comments are handed down from on high. The need to > track these comments out-weighs this. Aren't these two independent? I.e., comment tracking should work equally good regardless of the status of the comments. The reason I was being sensitive about spelling out that the reviews are treated as normal discussion is because I didn't want the day-to-day ART review process to override the day-to-day process within a WG. On the other hand, if an AD receives a recommendation from the ART saying something like "problem was pointed out, but the WG decided to ignore it", and the AD believes that foo is critical, [s]he may decide to put this in the AD-review and push hard for it. > Just as the ID-tracker allows us all to see the AD and IESG thoughts and comments, so we > need a mechanism to expose and track the ART comments. Where the review takes place early > in the life-cycle, the comments need to be exposed to the WG mail list for proper > discussion. Agreed. I am hoping we will be able to use the WG-internal issue tracking tools and/or the current IESG ID tracker. > I would suggest that ART review comments to the WG mail list follow some form of > pro-forma. > - The subject always reads "ART review: draft-ietf-xxxx" make sense > - The content always begins with a piece of set text. > Just a couple of lines to say > - what the ART is > - who ART review was requested by > - that comments are intended to be treated as normal > input to the WG discussion. or just a piece of text referring to the final document. I think I should include an appendix that would talk about such procedural bits like how e-mails should look and where they should be sent. > === > You are right to be concerned about "accountability". Stacking this up behind AD > accountability is probably safe. I don't see why there would be more complaints about ART > members than there are about WG chairs. OK > === > One of the growing concerns is opening up the IETF process to participants who are not > fluent in English. it is clearly beneficial for the review process if drafts are well > written and comprehensible. > Is there scope for offering the services of an ERT whose purpose is solely to help bash > the text? I can't think who would have the time or inclination to do this. Maybe it is > something to hand off to Harald. Sounds like an early-stage RFC-editor-like team. Checking the ID nits should be part of the WG chair review process, as well as part of the ART/AD review. Purely linguistical review would likely piss off people if we introduced it as yet another required step, but would probably be OK if done as part of technical review, which is the way it happens now. > === > I would also like to see more attention given to getting cross-WG reviews. We should not > assume that all wisdom is embodied in the "expert review teams" (although this may > actually be the case). In some cases, cross-area-WG review is required. Agree. I'll think how this can be improved. My first thought is to cc: the ART review requests and LC's to the hosting Area mailing list (or a special area-review mailing list). > For example, TEWG is working on multi-region TE requirements, but this may be lost in the > noise of the discussion of various DiffServ models. The multi-area requirements need > participation from those in the routing and signaling WGs that will be called upon to > generate solutions. Agree > Maybe this is orthogonal, but I needed to say it. I feel better now :-) No, this is very relevant. Thanks again. Alex From rtg-dir-admin@ietf.org Tue Nov 4 16:33:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06793 for ; Tue, 4 Nov 2003 16:33:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH8oK-00060P-00 for rtg-dir-archive@ietf.org; Tue, 04 Nov 2003 16:34:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH8oK-00060M-00 for rtg-dir-archive@ietf.org; Tue, 04 Nov 2003 16:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH8oL-0006MN-2i; Tue, 04 Nov 2003 16:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6zB-0007To-LG for rtg-dir@optimus.ietf.org; Tue, 04 Nov 2003 14:37:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00031 for ; Tue, 4 Nov 2003 14:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6z8-0003bs-00 for rtg-dir@ietf.org; Tue, 04 Nov 2003 14:37:02 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AH6z5-0003bl-00 for rtg-dir@ietf.org; Tue, 04 Nov 2003 14:37:00 -0500 Received: from prattle.redback.com ([155.53.12.9]) by manatick with esmtp (Exim 4.24) id 1AH6z1-0003WX-VD for rtg-dir@ietf.org; Tue, 04 Nov 2003 14:36:56 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 15F137BCAC2; Tue, 4 Nov 2003 11:35:51 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23589-01; Tue, 4 Nov 2003 11:35:51 -0800 (PST) Received: from redback.com (unknown [155.53.6.24]) by prattle.redback.com (Postfix) with ESMTP id 1636E18AA6D; Tue, 4 Nov 2003 11:35:48 -0800 (PST) Message-ID: <3FA7FF8F.7040606@redback.com> Date: Tue, 04 Nov 2003 14:35:43 -0500 From: Acee Lindem 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: Les Ginsberg Cc: Mike Shand , Alex Zinin , Chris Hopps , Tony Przygienda , rtg-dir@ietf.org Subject: Re: Restart Signaling for IS-IS (draft-ietf-isis-restart-04.txt) References: <4.3.2.7.2.20031103144326.01b401c0@mira-sjc5-3.cisco.com> In-Reply-To: <4.3.2.7.2.20031103144326.01b401c0@mira-sjc5-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Les, (Copying rtg-dir since I guess all review comments are to go there). Les Ginsberg wrote: > Acee - > > It appears that you are looking at V4 of the draft, which is the last > one that was posted. However, we prepared V5 of the draft which is > purely an editorial revision precisely to address the "nits". It also > includes some minor changes regarding SA bit handling by the receiver > that were requested by Tony P. in his review. Apparently no one > forwarded V5 to you (it has not been publicly posted yet). I have > attached it. (Apologies to those who already have it.) > > Some more responses below. > > > At 05:11 PM 11/3/2003 -0500, Acee Lindem wrote: > >> Les, Mike, >> >> As members of the routing directorate, Chris and I are reviewing the >> subject document. It has >> been years since I've read the base IS-IS specifications so please >> bear with my questions. >> >> First Nits: >> >> - Abstracts are not supposed to contain any [] references since >> they are often excerpted. You'll >> need to reference the base documents by name. >> - Section 4.3.1. Replace "IIH w RR" with "IIH with RR". > > > Will do (though this is now Section 3.4.1). > >> Comments/Questions: >> >> 1. Graceful restart does not appear to be terminated when a >> neighbor not implementing the >> extensions is detected by the restarting router - couldn't >> this potentially cause a routing >> loop? For OSPF, the restarting router will terminate graceful >> restart in this case. > > > I don't think so - at least not persistent ones. In order for a loop > to occur, a router would have to compute a path via a non-restart > capable(legacy) neighbor of the restarting router that transited the > restarting router (either on its way to the legacy router or after > reaching the legacy router). Since the legacy router will quickly > announce the loss of adjacency to the restarting router, two way > connectivity check should guarantee that this loop won't persist. Once > the adjacency comes back up, the topology has now been restored to its > pre-restart state - which is what has been preserved in the restarting > router's forwarding plane. > > Have I missed something? I think this is correct. I can't come up with a case where a loop would persist as long as the router not supporting these extensions does not advertise the adjacency. > > > >> 2. Prior to the SA bit, wasn't there any way for an adjacent >> neighbor to learn its neighbor >> had lost synchronization? I looked at IOS 9542 and didn't >> find anything. > > > Well, 9542 wouldn't help you, as that is the ES-IS spec. It's ISO > 10589:2002 that is relevant here. Unlike OSPF, IS-IS never required > database synchronization before advertising a neighbor - only that the > adjacency reach UP state which only requires hello exchange. > Subsequent to that database synchronization occurred. See 7.3.7 and > the state tables in Section 8. > > I am not sure what you mean here by "lost synchronization". The SA bit > is used to suppress neighbor advertisement until synchronization has > been achieved. It's not used to respond to lost synchronization. Ok - that makes sense if advertisement and mutual agreement on database synchronization aren't required for advertisement. The purpose of the SA bit is avoid waiting for a restarting router to flooding it's LSPs. However, wouldn't this happen immediately if an ISIS router is not restarting gracefully? > > > Les > > >> Thanks, >> Acee >> >------------------------------------------------------------------------ > > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > >Network Working Group M. Shand >Internet Draft L. Ginsberg >Expiration Date: April 2004 Cisco Systems > October 2003 > > > > > > > Restart signaling for IS-IS > draft-ietf-isis-restart-05.txt > > >Status of this Memo > > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC 2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. Internet-Drafts are draft documents valid for a maximum of > six months and may be updated, replaced, or obsoleted by other > documents at any time. It is inappropriate to use Internet-Drafts as > reference material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > Copyright Notice Copyright (C) The Internet Society (2003). All > Rights Reserved. > >Abstract > > > The IS-IS routing protocol (RFC 1195, ISO/IEC 10589) is a link state > intra-domain routing protocol. Normally, when an IS-IS router is > restarted, temporary disruption of routing occurs due to events in > both the restarting router and the neighbors of the restarting > router. > > The router which has been restarted computes its own routes before > achieving database synchronization with its neighbors. The results > > > >Shand, Ginsberg Expires Apr 2004 [Page 1] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > of this computation are likely to be non-convergent with the routes > computed by other routers in the area/domain. > > Neighbors of the restarting router detect the restart event and > cycle their adjacencies with the restarting router through the down > state. The cycling of the adjacency state causes the neighbors to > regenerate their LSPs describing the adjacency concerned. This in > turn causes temporary disruption of routes passing through the > restarting router. > > In certain scenarios the temporary disruption of the routes is > highly undesirable. This draft describes mechanisms to avoid or > minimize the disruption due to both of these causes. > >Table of Contents > > > 1. Conventions used in this document..............................2 > 2. Overview.......................................................3 > 3. Approach.......................................................4 > 3.1 Timers.......................................................4 > 3.2 Restart TLV..................................................4 > 3.2.1 Use of RR and RA bits.....................................5 > 3.2.2 Use of SA bit.............................................7 > 3.3 Adjacency (re)acquisition....................................7 > 3.3.1 Adjacency reacquisition during restart....................7 > 3.3.2 Adjacency acquisition during start.......................10 > 3.3.3 Multiple levels..........................................11 > 3.4 Database synchronization....................................11 > 3.4.1 LSP generation and flooding and SPF computation..........12 > 4. State Tables..................................................15 > 4.1 Running Router..............................................15 > 4.2 Restarting Router...........................................16 > 4.3 Starting Router.............................................17 > 5. Security Considerations.......................................18 > 6. Normative References..........................................18 > 7. Acknowledgments...............................................18 > 8. Authors' Addresses............................................18 > 9. Full Copyright Statement......................................19 > >1. Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in RFC-2119 [4]. > > > > >Shand, Ginsberg Expires Apr 2004 [Page 2] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > If the control and forwarding functions in a router can be > maintained independently, it is possible for the forwarding function > state to be maintained across a control function restart. This > functionality is assumed when the terms "restart/restarting" are > used in this document. > > The terms "start/starting" are used to refer to a router in which > the control function has either been started for the first time or > has been restarted but the forwarding functions have not been > maintained in a prior state. > > The terms "(re)start/(re)starting" are used when the text is > applicable to both a "starting" and a "restarting" router. > >2. Overview > > When an adjacency is reinitialized as a result of a neighbor > (re)starting, a router does three things: > > 1. It causes its own LSP(s) to be regenerated, thus triggering > SPF runs throughout the area (or in the case of Level 2, > throughout the domain). > > 2. It sets SRMflags on its own LSP database on the adjacency > concerned. > > 3. In the case of a Point-to-Point link it transmits a complete > set of CSNP(s) over the adjacency. > > In the case of a restarting router process, the first of these is > highly undesirable, but the second is essential in order to ensure > synchronization of the LSP database. > > The third action above minimizes the number of LSPs which must be > exchanged and, if made reliable, provides a means of determining > when the LSP databases of the neighboring routers have been > synchronized. This is desirable whether the router is being > restarted or not (so that the overload bit can be cleared in the > router's own LSP, for example). > > This draft describes a mechanism for a restarting router to signal > that it is restarting to its neighbors, and allow them to > reestablish their adjacencies without cycling through the down > state, while still correctly initiating database synchronization. > > This draft additionally describes a mechanism for a restarting > router to determine when it has achieved LSP database > synchronization with its neighbors. > > > > >Shand, Ginsberg Expires Apr 2004 [Page 3] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > This draft additionally describes a mechanism to optimize LSP > database synchronization and minimize transient routing disruption > when a router starts. > > It is assumed that the three-way handshake [5] is being used on > Point-to-Point circuits. > >3. Approach > >3.1 Timers > > Three additional timers, T1, T2 and T3 are required to support the > functionality defined in this document. > > An instance of the timer T1 is maintained per interface, and > indicates the time after which an unacknowledged (re)start attempt > will be repeated. A typical value might be 3 seconds. > > An instance of the timer T2 is maintained for each LSP database > present in the system i.e. for a Level1/2 system, there will be an > instance of the timer T2 for Level 1 and an instance for Level 2. > This is the maximum time that the system will wait for LSPDB > synchronization. A typical value might be 60 seconds. > > A single instance of the timer T3 is maintained for the entire > system. It indicates the time after which the router will declare > that it has failed to achieve database synchronization (by setting > the overload bit in its own LSP). This is initialized to 65535 > seconds, but is set to the minimum of the remaining times of > received IIHs containing a restart TLV with RA set and an indication > that the neighbor has an adjacency in the UP state to the restarting > router. > > NOTE: The timer T3 is only used by a restarting router. > >3.2 Restart TLV > > A new TLV is defined to be included in IIH PDUs. The presence of > this TLV indicates that the sender supports the functionality > defined in this document and it carries flags that are used to > convey information during a (re)start. All IIHs transmitted by a > router that supports this capability MUST include this TLV. > > Type 211 > Length 1 - (3 + ID Length) > Value > Flags (1 octet) > > > > > >Shand, Ginsberg Expires Apr 2004 [Page 4] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > 0 1 2 3 4 5 6 7 > +--+--+--+--+--+--+--+--+ > | Reserved |SA|RA|RR| > +--+--+--+--+--+--+--+--+ > > > RR - Restart Request > RA - Restart Acknowledgment > SA - Suppress adjacency advertisement > > > (Note: Remaining fields are required when RA bit is set) > > Remaining Time (2 octets) > > Remaining holding time (in seconds) > > > Restarting Neighbor System ID (ID Length octets) > > The system ID of the neighbor to which the RA refers. > Note: Implementations based on earlier versions of this > document may not include this field in the TLV when RA is > set. In this case a router which is expecting an RA on a > LAN circuit SHOULD assume that the acknowledgement is > directed at the local system.) > > >3.2.1 Use of RR and RA bits > > The RR bit is used by a (re)starting router to signal to its > neighbors that a (re)start is in progress, that an existing > adjacency SHOULD be maintained even under circumstances when the > normal operation of the adjacency state machine would require the > adjacency to be reinitialized, to request a set of CSNPs, and to > request setting of SRMflags. > > The RA bit is sent by the neighbor of a (re)starting router to > acknowledge the receipt of a restart TLV with the RR bit set. > > When the neighbor of a (re)starting router receives an IIH with the > restart TLV having the RR bit set, if there exists on this interface > an adjacency in state "Up" with the same System ID, and in the case > of a LAN circuit, with the same source LAN address, then, > irrespective of the other contents of the "Intermediate System > Neighbors" option (LAN circuits), or the "Point-to-Point Three-Way > Adjacency" option (Point-to-Point circuits): > > > > >Shand, Ginsberg Expires Apr 2004 [Page 5] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > a) The state of the adjacency is not changed. If this is the first > IIH with the RR bit set that this system has received associated > with this adjacency then the adjacency is marked as being in > "Restart mode" and the adjacency holding time is refreshed - > otherwise the holding time is not refreshed. The "remaining time" > transmitted according to (b) below MUST reflect the actual time > after which the adjacency will now expire. Receipt of a normal > IIH with RR bit reset will clear the "Restart mode" state. This > procedure allows the restarting router to cause the neighbor to > maintain the adjacency long enough for restart to successfully > complete while also preventing repetitive restarts from > maintaining an adjacency indefinitely. Whether an adjacency is > marked as being in "Restart mode" or not has no effect on > adjacency state transitions. > > b) immediately (i.e. without waiting for any currently running timer > interval to expire, but with a small random delay of a few 10s of > milliseconds on LANs to avoid "storms"), transmit over the > corresponding interface an IIH including the restart TLV with the > RR bit clear and the RA bit set, in the case of Point-to-Point > adjacencies having updated the "Point-to-Point Three-Way > Adjacency" option to reflect any new values received from the > (re)starting router. (This allows a restarting router to quickly > acquire the correct information to place in its hellos.) The > "Remaining Time" MUST be set to the current time (in seconds) > before the holding timer on this adjacency is due to expire. If > the corresponding interface is a LAN interface, then the > Restarting Neighbor System ID SHOULD be set to the System ID of > the router from whom the IIH with RR bit set was received. This > is required to correctly associate the acknowledgement and > holding time in the case where multiple systems on a LAN restart > at approximately the same time. This IIH SHOULD be transmitted > before any LSPs or SNPs transmitted as a result of the receipt of > the original IIH. > > c) if the corresponding interface is a Point-to-Point interface, or > if the receiving router has the highest LnRouterPriority (with > highest source MAC address breaking ties) among those routers to > which the receiving router has an adjacency in state "Up" on this > interface whose IIHs contain the restart TLV, excluding > adjacencies to all routers which are considered in "Restart mode" > (note the actual DIS is NOT changed by this process), initiate > the transmission over the corresponding interface of a complete > set of CSNPs, and set SRMflags on the corresponding interface for > all LSPs in the local LSP database. > > Otherwise (i.e. if there was no adjacency in the "UP" state to the > system ID in question), process the IIH as normal by reinitializing > the adjacency, and setting the RA bit in the returned IIH. > > > >Shand, Ginsberg Expires Apr 2004 [Page 6] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > >3.2.2 Use of SA bit > > The SA bit is used by a starting router to request that its neighbor > suppress advertisement of the adjacency to the starting router in > the neighbor's LSPs. > > A router which is starting has no maintained forwarding function > state. This may or may not be the first time the router has started. > If this is not the first time the router has started, copies of LSPs > generated by this router in its previous incarnation may exist in > the LSP databases of other routers in the network. These copies are > likely to appear "newer" than LSPs initially generated by the > starting router due to the reinitialization of LSP fragment sequence > numbers by the starting router. This may cause temporary blackholes > to occur until the normal operation of the update process causes the > starting router to regenerate and flood copies of its own LSPs with > higher sequence numbers. The temporary blackholes can be avoided if > the starting router's neighbors suppress advertising an adjacency to > the starting router until the starting router has been able to > propagate newer versions of LSPs generated by previous incarnations. > > When a router receives an IIH with the restart TLV having the SA bit > set, if there exists on this interface an adjacency in state "Up" > with the same System ID, and in the case of a LAN circuit, with the > same source LAN address, then advertisement of the adjacency to the > neighbor in LSPs MUST be suppressed. Until an IIH with the SA bit > clear has been received, the neighbor advertisement MUST continue to > be suppressed. If the adjacency transitions to the UP state, the new > adjacency MUST NOT be advertised until an IIH with the SA bit clear > has been received. > > Note that a router which suppresses advertisement of an adjacency > MUST NOT use this adjacency when performing its SPF calculation. In > particular, if an implementation follows the example guidelines > presented in [3] Annex C.2.5 Step 0:b) "pre-load TENT with the local > adjacency database", the suppressed adjacency MUST NOT be loaded > into TENT. > >3.3 Adjacency (re)acquisition > > Adjacency (re)acquisition is the first step in (re)initialization. > Restarting and starting routers will make use of the RR bit in the > restart TLV, though each will use it at different stages of the > (re)start procedure. > >3.3.1 Adjacency reacquisition during restart > > The restarting router explicitly notifies its neighbor that the > adjacency is being reacquired, and hence that it SHOULD NOT > reinitialize the adjacency. This is achieved by setting the RR bit > > >Shand, Ginsberg Expires Apr 2004 [Page 7] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > in the restart TLV. When the neighbor of a restarting router > receives an IIH with the restart TLV having the RR bit set, if there > exists on this interface an adjacency in state "Up" with the same > System ID, and in the case of a LAN circuit, with the same source > LAN address, then the procedures described in 4.2.1 are followed. > > A router that does not support the restart capability will ignore > the restart TLV and reinitialize the adjacency as normal, returning > an IIH without the restart TLV. > > On restarting, a router initializes the timer T3, starts the timer > T2 for each LSPDB and for each interface (and in the case of a LAN > circuit, for each level) starts the timer T1 and transmits an IIH > containing the restart TLV with the RR bit set. > > On a Point-to-Point circuit the "Adjacency Three-Way State" SHOULD > be set to "Init", because the receipt of the acknowledging IIH (with > RA set) MUST cause the adjacency to enter "Up" state immediately. > > On a LAN circuit the LAN-ID assigned to the circuit SHOULD be the > same as that used prior to the restart. In particular, for any > circuits for which the restarting router was previously DIS, the use > of a different LAN-ID would necessitate the generation of a new set > of pseudonode LSPs, and corresponding changes in all the LSPs > referencing them from other routers on the LAN. By preserving the > LAN-ID across the restart, this churn can be prevented. To enable a > restarting router to learn the LAN-ID used prior to restart, the > LAN-ID specified in an IIH w RR set MUST be ignored. > > Transmission of "normal" IIHs is inhibited until the conditions > described below are met (in order to avoid causing an unnecessary > adjacency initialization). On expiry of the timer T1, it is > restarted and the IIH is retransmitted as above. > > When a restarting router receives an IIH a local adjacency is > established as usual, and if the IIH contains a restart TLV with the > RA bit set (and on LAN circuits with a Restart Neighbor System ID > which matches that of the local system), the receipt of the > acknowledgement over that interface is noted. When the RA bit is set > and the state of the remote adjacency is UP then the timer T3 is set > to the minimum of its current value and the value of the "Remaining > Time" field in the received IIH. > > On a Point-to-Point link, receipt of an IIH not containing the > restart TLV is also treated as an acknowledgement, since it > indicates that the neighbor is not restart capable. However, since > no CSNP is guaranteed to be received over this interface, the timer > T1 is cancelled immediately without waiting for a complete set of > CSNP(s). Synchronization may therefore be deemed complete even > though there are some LSPs which are held (only) by this neighbor > > >Shand, Ginsberg Expires Apr 2004 [Page 8] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > (see section 4.4). In this case we also want to be certain that the > neighbor will reinitialize the adjacency in order to guarantee that > SRMflags have been set on its database, thus ensuring eventual LSPDB > synchronization. This is guaranteed to happen except in the case > where the Adjacency Three-Way State in the received IIH is UP and > the Neighbor Extended Local Circuit ID matches the extended local > circuit ID assigned by the restarting router. In this case the > restarting router MUST force the adjacency to reinitialize by > setting the local Adjacency Three-Way State to DOWN and sending a > normal IIH. > > In the case of a LAN interface, receipt of an IIH not containing the > restart TLV is unremarkable since synchronization can still occur so > long as at least one of the non-restarting neighboring routers on > the LAN supports restart. Therefore T1 continues to run in this > case. If none of the neighbors on the LAN are restart capable, T1 > will eventually expire after the locally defined number of retries. > > In the case of a Point-to-Point circuit, the "LocalCircuitID" and > "Extended Local Circuit ID" information contained in the IIH can be > used immediately to generate an IIH containing the correct 3-way > handshake information. The presence of "Neighbor Extended Local > Circuit ID" information which does not match the value currently in > use by the local system is ignored (since the IIH may have been > transmitted before the neighbor had received the new value from the > restarting router), but the adjacency remains in the initializing > state until the correct information is received. > > In the case of a LAN circuit the source neighbor information (e.g. > SNPAAddress) is recorded and used for adjacency establishment and > maintenance as normal. > > When BOTH a complete set of CSNP(s) (for each active level, in the > case of a pt-pt circuit) and an acknowledgement have been received > over the interface, the timer T1 is cancelled. > > Once the timer T3 has expired or been cancelled, subsequent IIHs are > transmitted according to the normal algorithms, but including the > restart TLV with both RR and RA clear. > > If a LAN contains a mixture of systems, only some of which support > the new algorithm, database synchronization is still guaranteed, but > the "old" systems will have reinitialized their adjacencies. > > If an interface is active, but does not have any neighboring router > reachable over that interface the timer T1 would never be cancelled, > and according to clause 3.4.1.1 the SPF would never be run. > Therefore timer T1 is cancelled after some pre-determined number of > expirations (which MAY be 1). (By this time any existing adjacency > on a remote system would probably have expired anyway.) > > >Shand, Ginsberg Expires Apr 2004 [Page 9] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > >3.3.2 Adjacency acquisition during start > > The starting router wants to ensure that in the event a neighboring > router has an adjacency to the starting router in the UP state (from > a previous incarnation of the starting router) that this adjacency > is reinitialized. The starting router also wants neighboring routers > to suppress advertisement of an adjacency to the starting router > until LSP database synchronization is achieved. This is achieved by > sending IIHs with the RR bit clear and the SA bit set in the restart > TLV. The RR bit remains clear and the SA bit remains set in > subsequent transmissions of IIHs until the adjacency has reached the > UP state and the initial T1 timer interval (see below) has expired. > > Receipt of an IIH with RR bit clear will result in the neighboring > router utilizing normal operation of the adjacency state machine. > This will ensure that any old adjacency on the neighboring router > will be reinitialized. > > On receipt of an IIH with SA bit set the behavior described in 3.2.2 > is followed. > > On starting, a router starts timer T2 for each LSPDB. > > For each interface (and in the case of a LAN circuit, for each > level), when an adjacency reaches the UP state, the starting router > starts a timer T1 and transmits an IIH containing the restart TLV > with the RR bit clear and SA bit set. On expiry of the timer T1, it > is restarted and the IIH is retransmitted with both RR and SA bits > set (only the RR bit has changed state from earlier IIHs). > > On receipt of an IIH with RR bit set (regardless of whether SA is > set or not) the behavior described in 3.2.1 is followed. > > When an IIH is received by the starting router and the IIH contains > a restart TLV with the RA bit set (and on LAN circuits with a > Restart Neighbor System ID which matches that of the local system), > the receipt of the acknowledgement over that interface is noted. > > On a Point-to-Point link, receipt of an IIH not containing the > restart TLV is also treated as an acknowledgement, since it > indicates that the neighbor is not restart capable. Since the > neighbor will have reinitialized the adjacency this guarantees that > SRMflags have been set on its database, thus ensuring eventual LSPDB > synchronization. However, since no CSNP is guaranteed to be received > over this interface, the timer T1 is cancelled immediately without > waiting for a complete set of CSNP(s). Synchronization may therefore > be deemed complete even though there are some LSPs which are held > (only) by this neighbor (see section 4.4). > > > > >Shand, Ginsberg Expires Apr 2004 [Page 10] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > In the case of a LAN interface, receipt of an IIH not containing the > restart TLV is unremarkable since synchronization can still occur so > long as at least one of the non-restarting neighboring routers on > the LAN supports restart. Therefore T1 continues to run in this > case. If none of the neighbors on the LAN are restart capable, T1 > will eventually expire after the locally defined number of retries. > The usual operation of the update process will ensure that > synchronization is eventually achieved. > > When BOTH a complete set of CSNP(s) (for each active level, in the > case of a pt-pt circuit) and an acknowledgement have been received > over the interface, the timer T1 is cancelled. Subsequent IIHs sent > by the starting router have the RR and RA bits clear and the SA bit > set in the restart TLV. > > Timer T1 is cancelled after some pre-determined number of > expirations (which MAY be 1). > > When the T2 timer(s) are cancelled or expire transmission of > "normal" IIHs (with RR, RA, and SA bits clear) will begin. > >3.3.3 Multiple levels > > A router which is operating as both a Level 1 and a Level 2 router > on a particular interface MUST perform the above operations for each > level. > > On a LAN interface, it MUST send and receive both Level 1 and > Level 2 IIHs and perform the CSNP synchronizations independently for > each level. > > On a pt-pt interface, only a single IIH (indicating support for both > levels) is required, but it MUST perform the CSNP synchronizations > independently for each level. > >3.4 Database synchronization > > When a router is started or restarted it can expect to receive a > (set of) CSNP(s) over each interface. The arrival of the CSNP(s) is > now guaranteed, since an IIH with RR bit set will be retransmitted > until the CSNP(s) are correctly received. > > The CSNPs describe the set of LSPs that are currently held by each > neighbor. Synchronization will be complete when all these LSPs have > been received. > > When (re)starting, a router starts an instance of timer T2 for each > LSPDB as described in 4.3.1 or 4.3.2. In addition to normal > processing of the CSNPs, the set of LSPIDs contained in the first > complete set of CSNP(s) received over each interface is recorded, > > >Shand, Ginsberg Expires Apr 2004 [Page 11] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > together with their remaining lifetime. In the case of a LAN > interface, a complete set of CSNPs MUST consist of CSNPs received > from neighbor(s) which are not restarting. If there are multiple > interfaces on the (re)starting router, the recorded set of LSPIDs is > the union of those received over each interface. LSPs with a > remaining lifetime of zero are NOT so recorded. > > As LSPs are received (by the normal operation of the update process) > over any interface, the corresponding LSPID entry is removed (it is > also removed if the LSP had arrived before the CSNP containing the > reference). When an LSPID has been held in the list for its > indicated remaining lifetime, it is removed from the list. When the > list of LSPIDs is empty and the timer T1 has been cancelled for all > the interfaces that have an adjacency at this level, the timer T2 is > cancelled. > > At this point the local database is guaranteed to contain all the > LSP(s) (either the same sequence number, or a more recent sequence > number) which were present in the neighbors' databases at the time > of (re)starting. LSPs that arrived in a neighbor's database after > the time of (re)starting may or may not be present, but the normal > operation of the update process will guarantee that they will > eventually be received. At this point the local database is deemed > to be "synchronized". > > Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime > are not recorded, and those with a short remaining lifetime are > deleted from the list when the lifetime expires, cancellation of the > timer T2 will not be prevented by waiting for an LSP that will never > arrive. > >3.4.1 LSP generation and flooding and SPF computation > > The operation of a router starting, as opposed to restarting is > somewhat different. These two cases are dealt with separately below. > > > >3.4.1.1. Restarting > > In order to avoid causing unnecessary routing churn in other > routers, it is highly desirable that the own LSPs generated by the > restarting system are the same as those previously present in the > network (assuming no other changes have taken place). It is > important therefore not to regenerate and flood the LSPs until all > the adjacencies have been re-established and any information > required for propagation into the local LSPs is fully available. > Ideally, the information is loaded into the LSPs in a deterministic > way, such that the same information occurs in the same place in the > same LSP (and hence the LSPs are identical to their previous > > >Shand, Ginsberg Expires Apr 2004 [Page 12] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > versions). If this can be achieved, the new versions will not even > cause SPF to be run in other systems. However, provided the same > information is included in the set of LSPs (albeit in a different > order, and possibly different LSPs), the result of running the SPF > will be the same and will not cause churn to the forwarding tables. > > In the case of a restarting router, none of the router's own LSPs > are transmitted, nor are the router's own forwarding tables updated > while the timer T3 is running. > > Redistribution of inter-level information MUST be regenerated before > this router's LSP is flooded to other nodes. Therefore the Level-n > non-pseudonode LSP(s) MUST NOT be flooded until the other level's T2 > timer has expired and its SPF has been run. This ensures that any > inter-level information which is to be propagated can be included in > the Level-n LSP(s). > > During this period, if one of the router's own (including > pseudonodes) LSPs is received, which the local router does not > currently have in its own database, it is NOT purged. Under normal > operation, such an LSP would be purged, since the LSP clearly should > not be present in the global LSP database. However, in the present > circumstances, this would be highly undesirable, because it could > cause premature removal of an own LSP - and hence churn in remote > routers. Even if the local system has one or more own LSPs (which it > has generated, but not yet transmitted) it is still not valid to > compare the received LSP against this set, since it may be that as a > result of propagation between Level 1 and Level 2 (or vice versa) a > further own LSP will need to be generated when the LSP databases > have synchronized. > > During this period a restarting router SHOULD send CSNPs as it > normally would. Information about the router's own LSPs MAY be > included, but if it is included it MUST be based on LSPs which have > been received, not on versions which have been generated (but not > yet transmitted). This restriction is necessary to prevent premature > removal of an LSP from the global LSP database. > > When the timer T2 expires or is cancelled indicating that > synchronization for that level is complete, the SPF for that level > is run in order to derive any information which is required to be > propagated to another level, but the forwarding tables are not yet > updated. > > Once the other level's SPF has run and any inter-level propagation > has been resolved, the 'own' LSPs can be generated and flooded. Any > 'own' LSPs which were previously ignored, but which are not part of > the current set of 'own' LSPs (including pseudonodes) MUST then be > purged. Note that it is possible that a Designated Router change may > have taken place, and consequently the router SHOULD purge those > > >Shand, Ginsberg Expires Apr 2004 [Page 13] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > pseudonode LSPs which it previously owned, but which are now no > longer part of its set of pseudonode LSPs. > > When all the T2 timers have expired or been cancelled, the timer T3 > is cancelled and the local forwarding tables are updated. > > If the timer T3 expires before all the T2 timers have expired or > been cancelled, this indicates that the synchronization process is > taking longer than minimum holding time of the neighbors. The > router's own LSP(s) for levels which have not yet completed their > first SPF computation are then flooded with the overload bit set to > indicate that the router's LSPDB is not yet synchronized (and > therefore other routers MUST NOT compute routes through this > router). Normal operation of the update process resumes and the > local forwarding tables are updated. In order to prevent the > neighbor's adjacencies from expiring, IIHs with the normal interface > value for the holding time are transmitted over all interfaces with > neither RR nor RA set in the restart TLV. This will cause the > neighbors to refresh their adjacencies. The own LSP(s) will continue > to have the overload bit set until timer T2 has expired or been > cancelled. > >3.4.1.2. Starting > > In the case of a starting router, as soon as each adjacency is > established, and before any CSNP exchanges, the router's own zeroth > LSP is transmitted with the overload bit set. This prevents other > routers from computing routes through the router until it has > reliably acquired the complete set of LSPs. The overload bit remains > set in subsequent transmissions of the zeroth LSP (such as will > occur if a previous copy of the routers LSP is still present in the > network) while any timer T2 is running. > > When all the T2 timers have been cancelled, the own LSP(s) MAY be > regenerated with the overload bit clear (assuming the router isn't > in fact overloaded, and there is no other reason, such as incomplete > BGP convergence, to keep the overload bit set), and flooded as > normal. > > Other 'own' LSPs (including pseudonodes) are generated and flooded > as normal, irrespective of the timer T2. The SPF is also run as > normal and the RIB and FIB updated as routes become available. > > To avoid the possible formation of temporary blackholes the starting > router sets the SA bit in the restart TLV (as described in 4.3.2) in > all IIHs that it sends. > > When all T2 timers have been cancelled the starting router MUST > transmit IIHs with the SA bit clear. > > > >Shand, Ginsberg Expires Apr 2004 [Page 14] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > > >4. State Tables > > This section presents state tables which summarize the behaviors > described in this document. Other behaviors, in particular adjacency > state transitions and LSP database update operation, are NOT > included in the state tables except where this document modifies the > behaviors described in [3] and [5]. > > Three state tables are presented from the point of view of a running > router, a restarting router, and a starting router. > > > >4.1 Running Router > > Event | Running | ADJ suppressed > ============================================================== > RX RR | Maintain ADJ State | > | Send RA | > | Set SRM,send CSNP | > | (Note 1) | > | Update Hold Time, | > | set Restart Mode | > | (Note 2) | > -------------+----------------------+------------------------- > RX RR clr | Clr Restart mode | > -------------+----------------------+------------------------- > RX SA set | Suppress IS neighbor | > | TLV in LSP(s) | > | Goto ADJ Suppressed | > -------------+----------------------+------------------------- > RX SA clr | |Unsuppress IS neighbor > | | TLV in LSP(s) > | |Goto Running > ============================================================== > > Note 1: If ADJ is UP > Note 2: If Restart Mode clear > > > > > > > > > >Shand, Ginsberg Expires Apr 2004 [Page 15] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > >4.2 Restarting Router > > Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait > | | RA | CSNP | > =================================================================== > Router | Send IIH/RR | | | > restarts | ADJ Init | | | > | Start T1,T2,T3 | | | > ------------+--------------------+-----------+-----------+------------ > RX RR | Send RA | | | > ------------+--------------------+-----------+-----------+------------ > RX RA | Adjust T3 | | Cancel T1 | > | Goto ADJ Seen RA | | Adjust T3 | > ----------- +--------------------+-----------+-----------+------------ > RX CSNP | Goto ADJ Seen CSNP | Cancel T1 | | > ------------+--------------------+-----------+-----------+------------ > RX IIH w/o | Cancel T1 | | | > Restart TLV| | | | > ------------+--------------------+-----------+-----------+------------ > T1 Expires | Send IIH/RR |Send IIH/RR|Send IIH/RR| > | Restart T1 | Restart T1| Restart T1| > ------------+--------------------+-----------+-----------+------------ > T1 Expires | Send IIH/ | Send IIH/ | Send IIH/ | > nth time | normal | normal | normal | > ------------+--------------------+-----------+-----------+------------ > T2 expires | Trigger SPF | | | > | Goto SPF Wait | | | > ------------+--------------------+-----------+-----------+------------ > T3 expires | Set OL | | | > | Flood local LSPs | | | > | Update fwd plane | | | > ------------+--------------------+-----------+-----------+------------ > LSP DB Sync| Cancel T2, and T3 | | | > | Trigger SPF | | | > | Goto SPF wait | | | > ------------+--------------------+-----------+-----------+------------ > All SPF | | | | Clear OL > done | | | | Update fwd > | | | | plane > | | | | Flood local > | | | | LSPs > | | | | Goto Runing > ====================================================================== > > >Shand, Ginsberg Expires Apr 2004 [Page 16] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > >4.3 Starting Router > > Event | Starting | ADJ Seen RA| ADJ Seen CSNP > ============================================================= > Router | Send IIH/SA | | > starts | Start T1,T2 | | > -------------+-------------------+------------+--------------- > RX RR | Send RA | | > -------------+-------------------+------------+--------------- > RX RA | Goto ADJ Seen RA | | Cancel T1 > -------------+-------------------+------------+--------------- > RX CSNP Set | Goto ADJ Seen CSNP| Cancel T1 | > -------------+-------------------+------------+--------------- > RX IIH w | Cancel T1 | | > no Restart | | | > TLV | | | > -------------+-------------------+------------+--------------- > ADJ UP | Start T1 | | > | Send local LSPs | | > | w OL | | > -------------+-------------------+------------+--------------- > T1 Expires | Send IIH/RR |Send IIH/RR | Send IIH/RR > | and SA | and SA | and SA > | Restart T1 |Restart T1 | Restart T1 > -------------+-------------------+------------+--------------- > T1 Expires | Send IIH/SA |Send IIH/SA | Send IIH/SA > nth time | | | > -------------+-------------------+------------+--------------- > T2 expires | Clear OL | | > | Send IIH normal | | > | Goto Running | | > -------------+-------------------+------------+--------------- > LSP DB Sync | Cancel T2 | | > | Clear OL | | > | Send IIH normal | | > ============================================================== > > > > > > > > > > >Shand, Ginsberg Expires Apr 2004 [Page 17] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > > > >5. Security Considerations > > This memo does not create any new security issues for the IS-IS > protocol. Security considerations for the base IS-IS protocol are > covered in [2] and [3]. > >6. Normative References > > 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP > 9, RFC 2026, October 1996. > > 2 Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, > December 1990. > > 3 ISO, "Intermediate system to Intermediate system routeing > information exchange protocol for use in conjunction with the > Protocol for providing the Connectionless-mode Network Service > (ISO 8473)," ISO/IEC 10589:2002, Second Edition. > > 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997 > > 5 Katz, D., "Three-Way Handshake for IS-IS Point-to-Point > Adjacencies", RFC 3373, September 2002 > >7. Acknowledgments > > The authors would like to acknowledge contributions made by Jeff > Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, > Russ White, and Rena Yang. > >8. Authors' Addresses > > Mike Shand > Cisco Systems > 250 Longwater Avenue, > Reading, > Berkshire, > RG2 6GB > UK > Phone: +44 208 824 8690 > Email: mshand@cisco.com > > > Les Ginsberg > Cisco Systems > 510 McCarthy Blvd. > > >Shand, Ginsberg Expires Apr 2004 [Page 18] > > >INTERNET DRAFT IS-IS restart Oct 2003 > > > Milpitas, Ca. 95035 USA > Email: ginsberg@cisco.com > > >9. Full Copyright Statement > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph > are included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > > > > > > > > > > > > > > > > > > > >Shand, Ginsberg Expires Apr 2004 [Page 19] > > From rtg-dir-admin@ietf.org Tue Nov 4 17:17:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08629 for ; Tue, 4 Nov 2003 17:17:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9Uu-0006lk-00 for rtg-dir-archive@ietf.org; Tue, 04 Nov 2003 17:18:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH9Uu-0006lh-00 for rtg-dir-archive@ietf.org; Tue, 04 Nov 2003 17:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Uv-0001tK-Mi; Tue, 04 Nov 2003 17:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9UY-0001nk-H0 for rtg-dir@optimus.ietf.org; Tue, 04 Nov 2003 17:17:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08577; Tue, 4 Nov 2003 17:17:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9UH-0006lI-00; Tue, 04 Nov 2003 17:17:21 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AH9UC-0006l2-00; Tue, 04 Nov 2003 17:17:21 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH9UB-000NZe-K0; Tue, 04 Nov 2003 22:17:15 +0000 Date: Tue, 4 Nov 2003 14:16:52 -0800 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <3184286117.20031104141652@psg.com> To: "Susan Hares" CC: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: Comments solicited:draft-zinin-early-review-00.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Sue- [cc'ing rtg-dir and rtg-chairs] > Alex: > Thanks for the draft. > Here's the problem I had when reviewing the draft for > the rtr-direcorate: > I was a late surprise to the routing group as you stated: > 4. Late surprises > Earlier cross-functional review coordinated with later IESG > review should minimize the number of unexpected issues identi- > fied at the later stages of a document life cycle. > The authors just wanted the draft out. I wanted to comment on > OPS requirements. I don't chair right now in OPS (I did in the > long past). The authors were very nice about working with me > but I felt it was a "late surprise" even as we started it now. Right, late surprises are a problem today with any late-progress review, be that the rtg-dir, AD, or IESG review. The draft tries to solve this problem by giving the WG chairs a tool to invoke the cross-functional review at any point in time. Until we have this in place, we just have to bite the bullet and do the best we can by proactively reading the drafts. > My terminology was not "in-sync" with the authors and the > chairs. Cross-review means new "buzz words" to learn. Warning folks > about that would help. Yes, I consider this part of the general catch-up process. > 5. Lack of cross-area review > The first steps are very painful. So.. suddenly we are throwing > extra steps in. Again.. its good -- but I need early input so > I am not in the work flow. the idea is that by invoking the ART review process earlier, most of the issues would be fleshed out and the AD/IESG review processes would go smoother. This would shift most of the issue finding/resolving activities to the WG part of the process where they are accepted more readily than during the AD/IESG stage, where people just want their stuff out. > 6. Lack of cross-functional expertise > This is good so that people do not repeat old errors. (A thing > I see a lot now. ) > Sue > PS - you can post to the rtr-directorate if you think it is worth while. Thanks Alex From rtg-dir-admin@ietf.org Tue Nov 4 17:18:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08700 for ; Tue, 4 Nov 2003 17:18:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9Vr-0006n0-00 for rtg-dir-archive@ietf.org; Tue, 04 Nov 2003 17:18:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH9Vq-0006mx-00 for rtg-dir-archive@ietf.org; Tue, 04 Nov 2003 17:18:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Vs-0001zk-Kh; Tue, 04 Nov 2003 17:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Vg-0001zI-KY for rtg-dir@optimus.ietf.org; Tue, 04 Nov 2003 17:18:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08676 for ; Tue, 4 Nov 2003 17:18:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9Ve-0006mh-00 for rtg-dir@ietf.org; Tue, 04 Nov 2003 17:18:46 -0500 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 1AH9Vc-0006mC-00 for rtg-dir@ietf.org; Tue, 04 Nov 2003 17:18:44 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Nov 2003 14:22:27 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA4MICmU013948; Tue, 4 Nov 2003 14:18:12 -0800 (PST) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-222.cisco.com [128.107.163.222]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALF22813; Tue, 4 Nov 2003 14:18:09 -0800 (PST) Message-Id: <4.3.2.7.2.20031104140440.01a5f570@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Nov 2003 14:18:09 -0800 To: Acee Lindem From: Les Ginsberg Subject: Re: Restart Signaling for IS-IS (draft-ietf-isis-restart-04.txt) Cc: Mike Shand , Alex Zinin , Chris Hopps , Tony Przygienda , rtg-dir@ietf.org In-Reply-To: <3FA7FF8F.7040606@redback.com> References: <4.3.2.7.2.20031103144326.01b401c0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20031103144326.01b401c0@mira-sjc5-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Acee - At 02:35 PM 11/4/2003 -0500, Acee Lindem wrote: >Hi Les, > >(Copying rtg-dir since I guess all review comments are to go there). > >Les Ginsberg wrote: > >>Acee - >> >>It appears that you are looking at V4 of the draft, which is the last one >>that was posted. However, we prepared V5 of the draft which is purely an >>editorial revision precisely to address the "nits". It also includes some >>minor changes regarding SA bit handling by the receiver that were >>requested by Tony P. in his review. Apparently no one forwarded V5 to you >>(it has not been publicly posted yet). I have attached it. (Apologies to >>those who already have it.) >> >>Some more responses below. >> >> >>At 05:11 PM 11/3/2003 -0500, Acee Lindem wrote: >> >>>Les, Mike, >>> >>>As members of the routing directorate, Chris and I are reviewing the >>>subject document. It has >>>been years since I've read the base IS-IS specifications so please bear >>>with my questions. >>> >>>First Nits: >>> >>> - Abstracts are not supposed to contain any [] references since they >>> are often excerpted. You'll >>> need to reference the base documents by name. >>> - Section 4.3.1. Replace "IIH w RR" with "IIH with RR". >> >> >>Will do (though this is now Section 3.4.1). >> >>>Comments/Questions: >>> >>> 1. Graceful restart does not appear to be terminated when a >>> neighbor not implementing the >>> extensions is detected by the restarting router - couldn't this >>> potentially cause a routing >>> loop? For OSPF, the restarting router will terminate graceful >>> restart in this case. >> >> >>I don't think so - at least not persistent ones. In order for a loop to >>occur, a router would have to compute a path via a non-restart >>capable(legacy) neighbor of the restarting router that transited the >>restarting router (either on its way to the legacy router or after >>reaching the legacy router). Since the legacy router will quickly >>announce the loss of adjacency to the restarting router, two way >>connectivity check should guarantee that this loop won't persist. Once >>the adjacency comes back up, the topology has now been restored to its >>pre-restart state - which is what has been preserved in the restarting >>router's forwarding plane. >> >>Have I missed something? > >I think this is correct. I can't come up with a case where a loop would >persist as long as the router >not supporting these extensions does not advertise the adjacency. > > >> >> >> >>> 2. Prior to the SA bit, wasn't there any way for an adjacent >>> neighbor to learn its neighbor >>> had lost synchronization? I looked at IOS 9542 and didn't find >>> anything. >> >> >>Well, 9542 wouldn't help you, as that is the ES-IS spec. It's ISO >>10589:2002 that is relevant here. Unlike OSPF, IS-IS never required >>database synchronization before advertising a neighbor - only that the >>adjacency reach UP state which only requires hello exchange. Subsequent >>to that database synchronization occurred. See 7.3.7 and the state tables >>in Section 8. >> >>I am not sure what you mean here by "lost synchronization". The SA bit is >>used to suppress neighbor advertisement until synchronization has been >>achieved. It's not used to respond to lost synchronization. > >Ok - that makes sense if advertisement and mutual agreement on database >synchronization aren't required for advertisement. >The purpose of the SA bit is avoid waiting for a restarting router to >flooding it's LSPs. However, wouldn't this happen >immediately if an ISIS router is not restarting gracefully? > The SA bit is only used by a starting router - not by a restarting router. The purpose of the SA bit is to prevent temporary blackholes that may occur because stale copies of the starting router's LSPs (from a previous incarnation) may exist in the network. Until the starting router has a chance to sync it's LSP database and - if necessary- flood new copies of the stale LSPs - other routers might compute paths to destinations advertised in the stale LSPs. By having neighbors suppress the advertisement of an adjacency to the starting router the two way connectivity check will prevent such blackholes from occurring. Section 3.2.2 describes this best. In its own way, think of this has the equivalent of OSPF requiring database sync to be completed before an adjacency can be advertised (a mechanism base IS-IS does not have). The difference here is that in OSPF sync is declared on a neighbor by neighbor basis, whereas we declare sync after we have synced with all our neighbors (or T2 expires). Hope that helps. Les >> Les >> >> >>>Thanks, >>>Acee From rtg-dir-admin@ietf.org Tue Nov 4 21:29:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16916 for ; Tue, 4 Nov 2003 21:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHDQm-0001zt-00 for rtg-dir-archive@ietf.org; Tue, 04 Nov 2003 21:30:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHDQm-0001zn-00 for rtg-dir-archive@ietf.org; Tue, 04 Nov 2003 21:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDQo-0001iN-Hw; Tue, 04 Nov 2003 21:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDPv-0001hn-8J for rtg-dir@optimus.ietf.org; Tue, 04 Nov 2003 21:29:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16888 for ; Tue, 4 Nov 2003 21:28:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHDPs-0001zI-00 for rtg-dir@ietf.org; Tue, 04 Nov 2003 21:29:04 -0500 Received: from [209.120.141.36] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1AHDPq-0001z6-00 for rtg-dir@ietf.org; Tue, 04 Nov 2003 21:29:02 -0500 Received: from [251.112.81.240] by 132.151.6.1 SMTP id RAqED3VLtFw6GF; Wed, 05 Nov 2003 04:22:39 +0200 Message-ID: From: "Women Newsline" Reply-To: "Women Newsline" To: Subject: Plump your L|ps Date: Wed, 05 Nov 2003 04:22:39 +0200 X-Mailer: Claris Emailer 2.0 x49, February X-Info-Mailx: igtDwriBrvguClit MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="7_.2.5A9521.A.8._9B" X-Priority: 3 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --7_.2.5A9521.A.8._9B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable FINALLY A LIP PLUMPER THAT ACTUALLY WORKS !!!
Get Plump, Sexy Lip's
In Un= der 30 Days!


= visit website

= = = =
CITY LIP'S exclusive lip treatment...
>Stimulates = collagen & hyaluronic moisture in your lip's resulting in BIGGER, LUSCIOUS, more SENSUOUS Lip's
>CITY LIP'S is used by men & women in 34 countries. Recommended by Pl= astic Surgeons, Celebrities, & Movie Stars
> CITY LIP'S super-hydrating formula plumps= & reduces unattractive lip= wrinkles & fine lines
> Easy to use, completely = pain-free and GUARANTEED to work in 30 d= ays or your MONEY BACK!

Be the envy of all your friends!

retail $47.95
ONLINE SALE $24.76
you save:= $23.19 (48% OFF)
 ~> BUY 2 GET 1 FREE <~

buy now visit websit= e
custome= r ratings:

Women love beauty tips, forward this= to a friend!



Distributors Welcome!

=
<= /tr>
Get Plump, Sexy Lip's
In Un= der 30 Days!


visit website

= = = =
CITY LIP'S exclusive lip treatment...
>Stimulates = collagen & hyaluronic moisture in your lip's resulting in BIGGER, LUSCIOUS, more SENSUOUS Lip's
>CITY LIP'S is used by men & women in 34 countries. Recommended by Pl= astic Surgeons, Celebrities, & Movie Stars
> CITY LIP'S super-hydrating formula plumps= & reduces unattractive lip= wrinkles & fine lines
> Easy to use, completely = pain-free and GUARANTEED to work in 30 d= ays or your MONEY BACK!

Be the envy of all your friends!

retail $47.95
ONLINE SALE $24.76
you save:= $23.19 (48% OFF)
 ~> BUY 2 GET 1 FREE <~

buy now visi= t website
custome= r ratings:

Women love beauty tips, forward this= to a friend!



Distributors Welcome!

=

 

 

 

--7_.2.5A9521.A.8._9B-- From rtg-dir-admin@ietf.org Wed Nov 5 11:34:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12180 for ; Wed, 5 Nov 2003 11:34:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHQcW-0006cf-00 for rtg-dir-archive@ietf.org; Wed, 05 Nov 2003 11:35:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHQcW-0006cc-00 for rtg-dir-archive@ietf.org; Wed, 05 Nov 2003 11:35:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHQcW-0003OU-En; Wed, 05 Nov 2003 11:35:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHQbm-0003Nf-Gd for rtg-dir@optimus.ietf.org; Wed, 05 Nov 2003 11:34:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11668; Wed, 5 Nov 2003 11:19:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHQNn-0006OQ-00; Wed, 05 Nov 2003 11:19:47 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AHQNn-0006OC-00; Wed, 05 Nov 2003 11:19:47 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7B4882D4845; Wed, 5 Nov 2003 11:19:16 -0500 (EST) 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 41572-02-96; Wed, 5 Nov 2003 11:19:15 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 957452D4841; Wed, 5 Nov 2003 11:19:15 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id hA5GJFo15304; Wed, 5 Nov 2003 11:19:15 -0500 (EST) Date: Wed, 5 Nov 2003 11:19:15 -0500 From: Jeffrey Haas To: Alex Zinin Cc: Adrian Farrel , rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: Comments solicited:draft-zinin-early-review-00.txt Message-ID: <20031105111915.A29773@nexthop.com> References: <200310272152.QAA16062@ietf.org> <42134340120.20031101131040@psg.com> <05dc01c3a0e2$12a5ba90$f9919ed9@Puppy> <658973753.20031103172140@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <658973753.20031103172140@psg.com>; from zinin@psg.com on Mon, Nov 03, 2003 at 05:21:40PM -0800 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Alex, Replies to this and also some comments of my own. On Mon, Nov 03, 2003 at 05:21:40PM -0800, Alex Zinin wrote: > > You are right to be concerned about "accountability". Stacking this up behind AD > > accountability is probably safe. I don't see why there would be more complaints about ART > > members than there are about WG chairs. > > OK I think this somewhat speaks to the "status" of people on the ARTs. Your document recommends assigning perhaps more "status" (sticker, note in the RFC, etc) than perhaps is necessary. The purpose of the ARTs, IMO, is to let the function of the ADs scale. The function of the ADs after all is to try to keep things a reasonably high quality in the process. Mentioning the ARTs in the final document in the usual "Acknowledgements" section is fine, if the authors are willing, but institutionalizing it seems a bit excessive. I suspect my thoughts aren't quite well formed enough to go into more detail yet, so I'll stop here. > > === > > One of the growing concerns is opening up the IETF process to participants who are not > > fluent in English. it is clearly beneficial for the review process if drafts are well > > written and comprehensible. > > > Is there scope for offering the services of an ERT whose purpose is solely to help bash > > the text? I can't think who would have the time or inclination to do this. Maybe it is > > something to hand off to Harald. > > Sounds like an early-stage RFC-editor-like team. > > Checking the ID nits should be part of the WG chair review process, as > well as part of the ART/AD review. Purely linguistical review would > likely piss off people if we introduced it as yet another required > step, but would probably be OK if done as part of technical review, > which is the way it happens now. I would prefer that linguistic/grammatical review be kept as generally separate from technical review where possible. However, I'd prefer the linguistic/grammatical cleanup be done before technical review is requested. Reading technical documents is hard enough. Reading them when things are grammatically unclean biases the bit of your brain that catches logical inconsistencies. By keeping the two elements (linguistic vs. technical) separate, we can hopefully help the document authors produce better documents while not appearing to bash the ideas they're trying to convey in the document. That said, document authors should be encouraged to spell check and grammmar check their documents before submission. Just because we're not something formal like an academic organization or a government standards body doesn't mean we should expect low-quality dox to be the norm. > > I would also like to see more attention given to getting cross-WG reviews. We should not > > assume that all wisdom is embodied in the "expert review teams" (although this may > > actually be the case). In some cases, cross-area-WG review is required. > > Agree. I'll think how this can be improved. My first thought is to cc: > the ART review requests and LC's to the hosting Area mailing list (or > a special area-review mailing list). I think it may be possible for us to trigger interest in particular documents on a greater IETF-wide basis. One of the problems I have with IETF documents, whether it be IDs or published RFCs, is telling how the document is meant to be relevant. For example, if there are a chain of documents mean to deal with SMTP, why don't we have a SMTP tag assigned to the document that tells us that it is relevant? To an area, like routing? To a protocol, like OSPF? Sometimes this is obvious in the abstract or the draft name, but sometimes it isn't. By creating a standard namespace by which document authors can tag their documents and a methdology by which we can denote this within our documents or indices (rfc-index.txt, e.g.), we can allow people that might say "oh, this is mpls related" and ignore something to go "oh! This was really about ospf!" It seems some librarian skills would come in handy for this. -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Thu Nov 6 00:50:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11997 for ; Thu, 6 Nov 2003 00:50:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHd2p-0002oZ-00 for rtg-dir-archive@ietf.org; Thu, 06 Nov 2003 00:50:59 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHd2o-0002oV-00 for rtg-dir-archive@ietf.org; Thu, 06 Nov 2003 00:50:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHd2q-0003Sq-MU; Thu, 06 Nov 2003 00:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHd28-0003SB-Vc for rtg-dir@optimus.ietf.org; Thu, 06 Nov 2003 00:50:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11988 for ; Thu, 6 Nov 2003 00:50:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHd26-0002oG-00 for rtg-dir@ietf.org; Thu, 06 Nov 2003 00:50:14 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AHd25-0002oC-00 for rtg-dir@ietf.org; Thu, 06 Nov 2003 00:50:13 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHd25-000KvV-E7; Thu, 06 Nov 2003 05:50:13 +0000 Date: Wed, 5 Nov 2003 19:55:36 -0800 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <478448713.20031105195536@psg.com> To: Thomas Narten CC: rtg-dir@ietf.org Subject: Re: revised ID: draft-ietf-ipv6-flow-label-08.txt In-Reply-To: <200310282135.h9SLZ0Y3014003@rotala.raleigh.ibm.com> References: <200310282135.h9SLZ0Y3014003@rotala.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thomas, See inline below. Ross, please check the answers to your comments. Alex > Alex, Jon, > There is a revised version of the flow-label draft. I've appended the > authors response to your Discuss comments. Please have a look. > I'm also adding it back to the agenda, as it appears we're one vote > shy of the quorum even if the discusses get cleared. :-( > Thomas > From: Brian E Carpenter > To: IPv6 > CC: Thomas Narten > Date: Tue, 14 Oct 2003 14:46:55 +0200 > Subject: Response to IESG comments on > draft-ietf-ipv6-flow-label-07.txt > The IESG comments on this document are at > https://www.ietf.org/IESG/EVALUATIONS/draft-ietf-ipv6-flow-label.bal > It's taken a while for the authors to discover them, but here are our > responses. We'd like the WG's reactions over the next few days, so that > we can update the draft appropriately. >> Ted Hardie (Discuss - August 7, 2003 teleconference Ted >> reclassified this to a COMMENT): >> This is very mild, and I could be talked out of it on the call, >> but I do find it odd that the key motivational text is in >> section 5.1, in the security requirements. This is the >> text I mean: >> >> >> The goal of the Flow Label is to allow different levels of service to >> be provided for traffic streams on a common network infrastructure. A >> variety of techniques may be used to achieve this, but the end result >> will be that some packets receive different (e.g., better or worse) >> service than others. The mapping of network traffic to the flow- >> specific treatment is triggered by the IP addresses and Flow Label >> value of the IPv6 header, >> >> This looks to me like it belongs in the introduction, so that the reader >> can understand the impetus to the work. > We think this is correct. Either this duplicates the introduction, or it > belongs in the introduction. In any case, it doesn't belong in the security > section. >> >> As a side note, I have some concerns about whether any protocol can >> meet the explicit requirements in Section 4 and the implicit requirement >> of "do some good" without running into the maw of some well-known >> dragons, but the statement of requirements looks fair to me. > We think that unspecified dragons are not useful to mention. In any case, > they should be discussed in specific use case drafts, not here. See below > for more comments on use cases. >> Alex Zinin (Discuss): >> >> This document talks about per-flow state establishment and >> processing on interim nodes. This is essentially IntServ >> and it doesn't scale well. > Not true. The notion of "flow" used here is more general than > in intserv (or NSIS), although the default case of a flow is a single > transport connection. When specific use cases for the flow label are > written up, their individual scaling properties must indeed be documented. I could probably live with this if the document made it clear that establishing state for each individual fine-granularity flow on the interim nodes dealing with gigs of traffic is not a goal. Basically, what I'm looking for is the scalability discussion. I'm leaving the rest to Russ. Alex >> More comments from rtg-dir (Ross) below. >> >> General Comments >> >> It seems to me that the flow label has a purpose, and two possible >> uses. To me the document seems to be not totally clear or perhaps >> even wrong regarding which of the uses is the main one. >> >> The purpose is to identify flows. For example, this allows the flow to >> be identified using only fields which are in fixed positions in the >> IPv6 Header. This purpose seems to me to be well defined in the >> document. > That is deliberate. The idea of the draft is to tell IPv6 implementors > (both hosts and router) what is the minimum set of functionality they > MUST or SHOULD implement to enable use of the flow label. The draft > doesn't purport to define specific use cases with their various > detailed considerations. In fact, Ross's comment shows that we have done > what we intended in the draft. Perhaps we need a more explicit statement > about this in the introduction. >> >> Now that you have an indicator regarding what flow a particular packet >> belongs to, what use would you have for this information? >> >> One possible use is for hashing packets, for example to spread traffic >> across equal cost multi-paths without re-ordering packets from any one >> flow. This seems like a pretty straightforward and sensible use, which >> requires close to zero change to the Internet architecture, and which >> is briefly mentioned in the document. >> >> The other possible use is for an explicit flow set up procedure. >> However, since the flow are per-{source-address; destination-address; >> flow field} triplet, it would seem that this won't scale much better >> than the current int-serve specification. Thus it is not clear whether >> this will end up being useful in practice. At best I would call this >> experimental. > We can think immediately of at least two other uses - as an e2e label for a > whole class of traffic (coarse grain aggregation), and [this is new from recent > debate inside the multi6 design team] as an e2e label for a multihoming session. does e2e imply that _all_ interim nodes need to have state for it or that edge nodes only need it? >> In some places in the document it appears that the flow field is for >> the purpose of identifying flows, and that either of the two uses >> might be sensible reasons that you might want to identify flows. > Yes. Exactly. >> In >> other places in the document it looks like the second purpose (which >> to me seems the more speculative) is the reason for the flow field. > It might be. >> >> I think that it would make sense to clearly separate these. > What needs to be clearly stated is that specific applications of the > flow label need to be / will be documented in specific use case > documents. We're not sure that there is anything else we can do in the > present draft. Ross's comment is a bit too general to generate specific > text changes. >> More specific comments >> >> Section 1: >> >> First three paragraphs do a good job of defining the purpose of the >> flow ID (to allow efficient flow classification based only on fields in >> the fixed part of the IPv6 header). >> >> Fourth paragraph, first sentence: >> The minimum level of IPv6 flow support consists >> of labeling the flows. >> >> In a sense this is reasonable, but I am not sure precisely what it >> means. >> Does this mean: >> >> In order to be an IPv6 conformant node, IPv6 source >> nodes MUST be able to label outgoing flows. >> >> or does this mean: >> >> In order to claim conformance to the IPv6 flow >> label specification, IPv6 source nodes MUST support >> labeling outgoing flows. >> >> Or does this mean something else? > The second one. We can clarify this. >> >> >> Sections 2 and 3. >> >> This seems reasonable, and again defines the purpose of the >> flow label in a reasonable way, as well as defining some very >> reasonable requirements, for example specifying how a source >> should set the flow value. >> >> >> Proposed New Section Between section 3 and 4: >> >> It seems to me that the most obviously worthwhile of the >> potential uses of the flow label field is to allow routers to split >> traffic on multiple paths (for example, for load sharing and traffic >> engineering purposes), without having to look past the IPv6 >> header. > Thus speaks a routing person... >> >> One example of where this might be very useful is in the case >> of encapsulation, for example over IPsec over IPv6 >> or over GRE over IPv6 encapsulations. In this case >> there might be a potentially very large number of high layer flows >> which will be encapsulated with the same IPv6 source and >> destination addresses in the outer IPv6 header. If you can hash >> only on the outer IPv6 addresses, then you could get a lot of >> traffic which is forced to take the same path. If you allow a finer >> grain flow label to be placed in the flow label field, then you can >> get a much more even distribution of traffic across, for example, >> equal cost multi-paths. > Indeed. This is one of the use cases that needs to be written up > in its own document. Not squeezed in here. >> I think that it is worth having a section on this possibility. I don't >> think that this requires all that much text. >> >> There is one question which I have, which could be cleared up >> in such a section: Specifically, the second sentence of section >> 2 states: >> >> A Flow Label of zero is used to indicate packets >> not part of any flow. >> >> Suppose that I am an IPv6 router which is hashing on source >> address, destination address, and flow label, and I am using >> the hash to split traffic among several paths. >> >> If I see a packet with a flow label of zero, which of the following do >> I assume: >> >> - the node does not implement any flow labelling ability, and >> therefore I must hash only on source and destination >> address. >> >> - the node does implement flow labelling, and is telling me >> that the packet is not part of any flow, and can therefore >> be >> forwarded on any path without regard for re-ordering. >> >> If we assume the latter, then implementation of the flow labelling >> capability must be supported by all IPv6 source nodes (at least >> to the point of sticking a non-zero value in the flow field), since >> otherwise their packets might be re-ordered by nodes which >> assume that their packets are not part of any flow. > The use of the flow label doesn't affect the desired reordering semantics of the > Internet, which remain "well, try not to reorder." So the functional difference > between the two interpretations is small. In other words we don't intend a zero flow > label to be a license to reorder. In fact we can't see any harm done by including a > zero flow label in the hash - this will just be the default flow for a given > srce/dest pair. So what? There's no presumption that each flow has a > similar amount of traffic, anyway. > We should perhaps add an explicit statement that a zero flow label does not > imply that significant reordering is acceptable. >> >> I would suggest using zero to indicate that flow labelling is not >> supported (and thus routers better keep the packets in order >> based only on source and destination addresses). If we also >> want to indicate that some packets are not part of a flow, we >> might give them a random value, or a different special value. > Well, we just don't see a major semantic difference between "I don't > label flows" and "I decided not to label this packet". Both > require default treatment. >> >> >> Section 4: >> >> The flow state establishment requirements in section 4 seem to be >> very much incomplete. If there were a complete set of flow state >> establishment requirements, then I think that the requirements >> specified in this section are reasonable ones, and would be >> included in the set. However, the two requirements specified in >> section 4 seem to be such a small subset of the complete set of >> requirements that I don't see why it is worth listing them at all. I >> think that it would be cleaner just to say that methods and >> requirements for explicit flow establishment are outside of the >> scope of this document. > No, these are a consensus view of the minimal requirements that all > nodes must satisfy in order to allow co-existence of various different > flow label use cases in the Internet. The individual use cases will > add their own requirements. The WG wanted us to reduce the detail here > to the vital minimum, and that's what we did. >> >> Naturally if section 4 were removed, then the last phrase of the >> first paragraph of the abstract would also need to be removed >> (page 1, phrase "and the requirements for flow state establishment >> methods"). Similarly the second to last paragraph of section 1 >> would need to be abbreviated. >> >> >>Section 5: >> >> First paragraph, last sentence: >> >> Even if the flow label were encrypted, its presence >> as a constant value in a fixed position might assist >> traffic analysis and cryptoanalysis. >> >> The flow label is supposed to be unstructured -- in the sense that if >> I am not the source node, then I don't know anything about how the >> source set the label, except that a different value means a different >> flow. As such, I don't understand what encryption would do to change >> the interpretation of a flow label. If two labels were encrypted to >> the same exact value, then it would seem clear that they can't be >> un-encrypted back to different values. If two flow labels were >> encrypted to different values, then as a node in the middle observing >> the packets going by I don't detect any difference. > That's not the point. There have been a few famous crypto breaks in history > due to fixed patterns occurring in the plaintext. The flow label increases > the number of fixed (non-zero) bits in the packet header, and that is > presumably still a cryptographic risk factor as it was in WW 2. >> >> Section 5.1, second paragraph (top of page 5), first sentence: >> >> Note that there is no guarantee that flow labels sent by a node are >> not set in any manner that the node wants to, such as reusing flow >> labels, against the recommendations in this document. >> >> This seems to be a rather awkward sentence, and should probably >> be re-written. > OK >> >> Additional Topic: Somewhere in the security section (probably in a new >> subsection at the end) it might be worth mentioning that in those >> locations where a firewall or filtering router is employed which looks >> past the IP header to higher level headers, the flow label does >> nothing to eliminate the need to continue to look at the higher >> headers. > OK >> >> Ross >> >> Jon Peterson (Discuss): >> >> Along the same lines as the comments from the Routing Area Directorate, but >> with a few different issues in the text: >> >> I believe there are two purposes of flows given in the document - first, a >> flow as a way of flagging a stream of related traffic coming from a node >> (following Section 3, first paragraph), and second, a flow as something that >> would be prioritized by routers (following Section 5.1, first paragraph). >> There are a couple of ways in which the two seem to get mixed up. >> >> 1) In the last paragraph of 5.1, it suggests that a policy decision in the >> source node should be made to determine whether or not an application or >> transport protocol is allowed to use a non-zero Flow Label. But reading, for >> example, the first paragraph of Section 3, the document suggests that "each >> unrelated transport connection and application data stream" on a node should >> be assigned to a new flow (which presumably means that they would have a >> non-zero Flow Label). > Yes, the policy can override the SHOULD. That could be clarified. >> >> 2) Section 3, second paragraph, says: >> >> To enable applications and transport protocols to define what packets >> constitute a flow, the source node MUST provide means for the >> applications and transport protocols to specify the Flow Label values >> to be used with their flows. >> >> Given that there is some sort of policy decision associated with the >> assignment of flows, I don't think applications and transport protocols >> could really get to 'specify' these Flow Labels. > Why not? Consider a use case where we use the flow label at "traffic type" > granularity. A video codec application might want to use different flow labels > for different levels of video encoding. It's not for the IPv6 WG to prevent > that. >> It also isn't clear how >> collisions would be managed (Section 3, third paragraph) if it were possible >> for any multiple applications on the same host to specify Flow Label values. > We deleted a whole lot of implementation recommendations in this area, at the > WG's request. It's entirely algorithmic but it takes you into API and local > state areas that are out of place in a protocol spec. The IP stack has to > cache all flow labels in current use, and whether collisions are allowed or > disallowed is again a use case issue - you might want to use the same > coarse flow label for the audio part of video flows and for VoIP - or you > might not, depending on how you've chosen to use the flow label. Again, > it isn't for the IPv6 WG to legislate on this. > Brian From rtg-dir-admin@ietf.org Thu Nov 6 05:52:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03760 for ; Thu, 6 Nov 2003 05:52:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHhl4-0006wd-00 for rtg-dir-archive@ietf.org; Thu, 06 Nov 2003 05:52:58 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHhl4-0006wa-00 for rtg-dir-archive@ietf.org; Thu, 06 Nov 2003 05:52:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHhl7-0006zI-7a; Thu, 06 Nov 2003 05:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHhkW-0006yO-99 for rtg-dir@optimus.ietf.org; Thu, 06 Nov 2003 05:52:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03717 for ; Thu, 6 Nov 2003 05:52:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHhkS-0006vk-00 for rtg-dir@ietf.org; Thu, 06 Nov 2003 05:52:20 -0500 Received: from [216.185.65.90] (helo=192.168.3.40) by ietf-mx with smtp (Exim 4.12) id 1AHhk8-0006uz-00 for rtg-dir@ietf.org; Thu, 06 Nov 2003 05:52:16 -0500 From: "John Doe" To: Subject: Urgent Asistance Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C221EC.6C64F7B0" Date: Thu, 6 Nov 2003 02:52:03 -0800 Reply-To: "John Doe" X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Priority: 3 (Normal) Message-Id: Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ------=_NextPart_000_0034_01C221EC.6C64F7B0 Content-Type: text/plain; charset="iso-8859-1" Hello Attn sir/madam, I am Nicky Taylor, a resident in Monrovia Liberia, I urgently want to acquire properties eg, Two different houses in a very good city as soon as possible. There is a war currently going on in my country Hence i want to relocate my whole family for safety. Please contact me immediately. With best regards, Nicky Taylor okoro2001@zwallet.com ------=_NextPart_000_0034_01C221EC.6C64F7B0 Content-Type: text/html; charset="iso-8859-1" E-mail message content
Hello
Attn sir/madam,
I am Nicky Taylor, a resident in Monrovia Liberia, I urgently want to acquire properties eg, Two different houses in a very good city as soon as possible. There is a war currently going on in my country Hence i want to relocate my whole family for safety.
Please contact me immediately.
 
With best regards,
Nicky Taylor
okoro2001@zwallet.com
 
 ------=_NextPart_000_0034_01C221EC.6C64F7B0-- From rtg-dir-admin@ietf.org Thu Nov 6 13:02:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20688 for ; Thu, 6 Nov 2003 13:02:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHoTF-00052u-00 for rtg-dir-archive@ietf.org; Thu, 06 Nov 2003 13:03:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHoTF-00052q-00 for rtg-dir-archive@ietf.org; Thu, 06 Nov 2003 13:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoTF-000782-8O; Thu, 06 Nov 2003 13:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHoT7-00077i-Fz for rtg-dir@optimus.ietf.org; Thu, 06 Nov 2003 13:02:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20683 for ; Thu, 6 Nov 2003 13:02:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHoT5-00052g-00 for rtg-dir@ietf.org; Thu, 06 Nov 2003 13:02:51 -0500 Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx with esmtp (Exim 4.12) id 1AHoT4-00052L-00 for rtg-dir@ietf.org; Thu, 06 Nov 2003 13:02:50 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 693133DCD27; Thu, 6 Nov 2003 10:05:40 -0800 (PST) In-Reply-To: <3FA7FF8F.7040606@redback.com> References: <4.3.2.7.2.20031103144326.01b401c0@mira-sjc5-3.cisco.com> <3FA7FF8F.7040606@redback.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7DBE9405-1083-11D8-BD33-00039303E9E2@procket.com> Content-Transfer-Encoding: quoted-printable Cc: Alex Zinin , "" , Tony Przygienda , Tony Li , Acee Lindem From: Christian Hopps Subject: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.txt) Date: Thu, 6 Nov 2003 10:03:14 -0800 To: Mike Shand , Les Ginsberg X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On Nov 3, 2003, at 2:11 PM, Acee Lindem wrote: > Les, Mike, > > As members of the routing directorate, Chris and I are reviewing the=20= > subject document. My previous private comments have been dealt with in these newer drafts, so I'll just stick to new comments here, all of which are editorial in nature. Comments inline. > INTERNET DRAFT IS-IS restart Oct 2003 > [...] > 2. Overview > [...] > This draft additionally describes a mechanism for a restarting > router to determine when it has achieved LSP database > synchronization with its neighbors. > > > > > Shand, Ginsberg Expires Apr 2004 [Page 3] > =0C > > INTERNET DRAFT IS-IS restart Oct 2003 > > > This draft additionally describes a mechanism to optimize LSP > database synchronization and minimize transient routing disruption > when a router starts. These two paragraphs seem clunky. At first I thought it was a repeat paragraph mistake. Perhaps not having the same 6 words start the second paragraph would help, or maybe it's just me. > 3. Approach > 3.1 Timers > 3.2 Restart TLV > > A new TLV is defined to be included in IIH PDUs. The presence of > this TLV indicates that the sender supports the functionality > defined in this document and it carries flags that are used to > convey information during a (re)start. All IIHs transmitted by a > router that supports this capability MUST include this TLV. > > Type 211 > Length 1 - (3 + ID Length) > Value > Flags (1 octet) > [...] > 0 1 2 3 4 5 6 7 > +--+--+--+--+--+--+--+--+ > | Reserved |SA|RA|RR| > +--+--+--+--+--+--+--+--+ > I think you should illustrate the entire TLV in the "bits" format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 211 | Length | Flags | Remaining... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...Time(*) | Restarting Neighbor System ID (**) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ keeping the breakout detail of the Flags field as well. Aside from this just being standard, it also avoids confusion such as: > Length 1 - (3 + ID Length) Which really meant 1 octet of length which is 3 + ID Length, the use of "-" is confusing here. :) Additionally I wouldn't specify the formula for the length as you have since it depends on what is included. I say leave out the formula, just describe what goes in the TLV. > 3.2.1 Use of RR and RA bits > 3.2.2 Use of SA bit > 3.3 Adjacency (re)acquisition > 3.3.1 Adjacency reacquisition during restart > 3.3.2 Adjacency acquisition during start > 3.3.3 Multiple levels > 3.4.1 LSP generation and flooding and SPF computation > 3.4.1.1. Restarting > 3.4.1.2. Starting > 4.1 Running Router > > Event | Running | ADJ suppressed > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RX RR | Maintain ADJ State | > | Send RA | > | Set SRM,send CSNP | > | (Note 1) | > | Update Hold Time, | > | set Restart Mode | > | (Note 2) | > -------------+----------------------+------------------------- > RX RR clr | Clr Restart mode | > -------------+----------------------+------------------------- > RX SA set | Suppress IS neighbor | > | TLV in LSP(s) | > | Goto ADJ Suppressed | > -------------+----------------------+------------------------- > RX SA clr | |Unsuppress IS neighbor > | | TLV in LSP(s) > | |Goto Running > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nit, you specify SA "set" but not RR "set". > Note 1: If ADJ is UP > Note 2: If Restart Mode clear > > > > > > > > > > Shand, Ginsberg Expires Apr 2004 [Page 15] > =0C > > INTERNET DRAFT IS-IS restart Oct 2003 > > > > 4.2 Restarting Router > > Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait > | | RA | CSNP | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Router | Send IIH/RR | | | > restarts | ADJ Init | | | > | Start T1,T2,T3 | | | > = ------------+--------------------+-----------+-----------+------------ > RX RR | Send RA | | | > = ------------+--------------------+-----------+-----------+------------ > RX RA | Adjust T3 | | Cancel T1 | > | Goto ADJ Seen RA | | Adjust T3 | > ----------- = +--------------------+-----------+-----------+------------ > RX CSNP | Goto ADJ Seen CSNP | Cancel T1 | | > = ------------+--------------------+-----------+-----------+------------ > RX IIH w/o | Cancel T1 | | | > Restart TLV| | | | This is for P2P only right, if so please add that. > = ------------+--------------------+-----------+-----------+------------ > T1 Expires | Send IIH/RR |Send IIH/RR|Send IIH/RR| > | Restart T1 | Restart T1| Restart T1| > = ------------+--------------------+-----------+-----------+------------ > T1 Expires | Send IIH/ | Send IIH/ | Send IIH/ | > nth time | normal | normal | normal | > = ------------+--------------------+-----------+-----------+------------ > T2 expires | Trigger SPF | | | > | Goto SPF Wait | | | > = ------------+--------------------+-----------+-----------+------------ > T3 expires | Set OL | | | > | Flood local LSPs | | | > | Update fwd plane | | | > = ------------+--------------------+-----------+-----------+------------ > LSP DB Sync| Cancel T2, and T3 | | | > | Trigger SPF | | | > | Goto SPF wait | | | > = ------------+--------------------+-----------+-----------+------------ > All SPF | | | | Clear OL > done | | | | Update fwd > | | | | plane > | | | | Flood = local > | | | | LSPs > | | | | Goto = Runing > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > Shand, Ginsberg Expires Apr 2004 [Page 16] > =0C > > INTERNET DRAFT IS-IS restart Oct 2003 > > > > 4.3 Starting Router > > Event | Starting | ADJ Seen RA| ADJ Seen CSNP > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Router | Send IIH/SA | | > starts | Start T1,T2 | | > -------------+-------------------+------------+--------------- > RX RR | Send RA | | > -------------+-------------------+------------+--------------- > RX RA | Goto ADJ Seen RA | | Cancel T1 > -------------+-------------------+------------+--------------- > RX CSNP Set | Goto ADJ Seen CSNP| Cancel T1 | > -------------+-------------------+------------+--------------- > RX IIH w | Cancel T1 | | > no Restart | | | > TLV | | | Same comment as with restarting FSM. That's it. Thanks, Chris. > -------------+-------------------+------------+--------------- > ADJ UP | Start T1 | | > | Send local LSPs | | > | w OL | | > -------------+-------------------+------------+--------------- > T1 Expires | Send IIH/RR |Send IIH/RR | Send IIH/RR > | and SA | and SA | and SA > | Restart T1 |Restart T1 | Restart T1 > -------------+-------------------+------------+--------------- > T1 Expires | Send IIH/SA |Send IIH/SA | Send IIH/SA > nth time | | | > -------------+-------------------+------------+--------------- > T2 expires | Clear OL | | > | Send IIH normal | | > | Goto Running | | > -------------+-------------------+------------+--------------- > LSP DB Sync | Cancel T2 | | > | Clear OL | | > | Send IIH normal | | > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > Shand, Ginsberg Expires Apr 2004 [Page 17] > =0C > > INTERNET DRAFT IS-IS restart Oct 2003 > > > > > > 5. Security Considerations > > This memo does not create any new security issues for the IS-IS > protocol. Security considerations for the base IS-IS protocol are > covered in [2] and [3]. > > 6. Normative References > > 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP > 9, RFC 2026, October 1996. > > 2 Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, > December 1990. > > 3 ISO, "Intermediate system to Intermediate system routeing > information exchange protocol for use in conjunction with the > Protocol for providing the Connectionless-mode Network Service > (ISO 8473)," ISO/IEC 10589:2002, Second Edition. > > 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997 > > 5 Katz, D., "Three-Way Handshake for IS-IS Point-to-Point > Adjacencies", RFC 3373, September 2002 > > 7. Acknowledgments > > The authors would like to acknowledge contributions made by Jeff > Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, > Russ White, and Rena Yang. > > 8. Authors' Addresses > > Mike Shand > Cisco Systems > 250 Longwater Avenue, > Reading, > Berkshire, > RG2 6GB > UK > Phone: +44 208 824 8690 > Email: mshand@cisco.com > > > Les Ginsberg > Cisco Systems > 510 McCarthy Blvd. > > > Shand, Ginsberg Expires Apr 2004 [Page 18] > =0C > > INTERNET DRAFT IS-IS restart Oct 2003 > > > Milpitas, Ca. 95035 USA > Email: ginsberg@cisco.com > > > 9. Full Copyright Statement > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain = it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph > are included on all such copies and derivative works. However, = this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on = an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > > > > > > > > > > > > > > > > > > > > Shand, Ginsberg Expires Apr 2004 [Page 19] > =0C= From rtg-dir-admin@ietf.org Thu Nov 6 16:26:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01938 for ; Thu, 6 Nov 2003 16:26:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHree-0000sm-00 for rtg-dir-archive@ietf.org; Thu, 06 Nov 2003 16:27:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHree-0000sj-00 for rtg-dir-archive@ietf.org; Thu, 06 Nov 2003 16:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHree-0004tm-L6; Thu, 06 Nov 2003 16:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHre3-0004tC-7Z for rtg-dir@optimus.ietf.org; Thu, 06 Nov 2003 16:26:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01931 for ; Thu, 6 Nov 2003 16:26:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHre1-0000sQ-00 for rtg-dir@ietf.org; Thu, 06 Nov 2003 16:26:21 -0500 Received: from smtp.nuvox.net ([64.89.70.9] helo=smtp01.gvl-priv.sys.nuvox.net) by ietf-mx with esmtp (Exim 4.12) id 1AHre0-0000rq-00 for rtg-dir@ietf.org; Thu, 06 Nov 2003 16:26:20 -0500 Received: from [192.168.220.51] ([66.64.174.202]) by smtp01.gvl-priv.sys.nuvox.net (8.12.8/8.12.8) with ESMTP id hA6LP1cj000343; Thu, 6 Nov 2003 16:25:49 -0500 In-Reply-To: <139118651451.20031030142547@psg.com> References: <139118651451.20031030142547@psg.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Randy Bush , rtg-dir@ietf.org From: Danny McPherson Subject: Re: Review: draft-ietf-bmwg-conterm-05.txt Date: Thu, 6 Nov 2003 14:25:41 -0700 To: Alex Zinin X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ACK! -danny On Oct 30, 2003, at 3:25 PM, Alex Zinin wrote: > > Abstract: > > This draft establishes terminology to standardize the description of > benchmarking methodology for measuring eBGP convergence in the > control plane of a single BGP device. Future documents will address > iBGP convergence, the initiation of forwarding based on converged > control plane information and multiple interacting BGP devices. This > terminology is applicable to both IPv4 and IPv6. Illustrative > examples of each version are included where relevant. > > Please review this draft by Nov 13th. > > Token holders: Alvaro and Danny. Please ack. > > Alex > >> this draft, revised supposedly including alex's concerns, is being >> proposed >> as info and i have been asked to review. i would appreciate routing >> review. >> thanks. >> >> randy > > From rtg-dir-admin@ietf.org Thu Nov 6 16:44:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02669 for ; Thu, 6 Nov 2003 16:44:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrw6-000152-00 for rtg-dir-archive@ietf.org; Thu, 06 Nov 2003 16:45:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHrw6-00014z-00 for rtg-dir-archive@ietf.org; Thu, 06 Nov 2003 16:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrw7-00062k-UJ; Thu, 06 Nov 2003 16:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrvd-0005zS-DY for rtg-dir@optimus.ietf.org; Thu, 06 Nov 2003 16:44:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02659 for ; Thu, 6 Nov 2003 16:44:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrvb-00014k-00 for rtg-dir@ietf.org; Thu, 06 Nov 2003 16:44:31 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHrva-00014h-00 for rtg-dir@ietf.org; Thu, 06 Nov 2003 16:44:31 -0500 Received: from [216.185.65.90] (helo=192.168.3.40) by manatick with smtp (Exim 4.24) id 1AHrvQ-0006YB-FU for rtg-dir@ietf.org; Thu, 06 Nov 2003 16:44:28 -0500 From: "Nicholas Taylor" To: Subject: Urgent Asistance Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C221EC.6C64F7B0" Date: Thu, 6 Nov 2003 13:44:18 -0800 Reply-To: "Nicholas Taylor" X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Priority: 3 (Normal) Message-Id: Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ------=_NextPart_000_0034_01C221EC.6C64F7B0 Content-Type: text/plain; charset="iso-8859-1" Hello Attn sir/madam, I am Nicky Taylor, a resident in Monrovia Liberia, I urgently want to acquire properties eg, Two different houses in a very good city as soon as possible. There is a war currently going on in my country Hence i want to relocate my whole family for safety. Please contact me immediately. With best regards, Nicky Taylor nicky_2003@tiscali.co.uk ------=_NextPart_000_0034_01C221EC.6C64F7B0 Content-Type: text/html; charset="iso-8859-1" E-mail message content
Hello
Attn sir/madam,
I am Nicky Taylor, a resident in Monrovia Liberia, I urgently want to acquire properties eg, Two different houses in a very good city as soon as possible. There is a war currently going on in my country Hence i want to relocate my whole family for safety.
Please contact me immediately.
 
With best regards,
Nicky Taylor
nicky_2003@tiscali.co.uk
 
 ------=_NextPart_000_0034_01C221EC.6C64F7B0-- From rtg-dir-admin@ietf.org Fri Nov 7 02:29:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03222 for ; Fri, 7 Nov 2003 02:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI14C-0000FX-00 for rtg-dir-archive@ietf.org; Fri, 07 Nov 2003 02:30:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI14B-0000FT-00 for rtg-dir-archive@ietf.org; Fri, 07 Nov 2003 02:29:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI14D-00037d-KP; Fri, 07 Nov 2003 02:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI13f-00035j-Gh for rtg-dir@optimus.ietf.org; Fri, 07 Nov 2003 02:29:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03191 for ; Fri, 7 Nov 2003 02:29:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI13b-0000F6-00 for rtg-dir@ietf.org; Fri, 07 Nov 2003 02:29:23 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AI13a-0000Ep-00 for rtg-dir@ietf.org; Fri, 07 Nov 2003 02:29:22 -0500 Received: from cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2003 23:31:03 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hA77SkrX009943; Thu, 6 Nov 2003 23:28:46 -0800 (PST) Received: from ginsberg-w2k.cisco.com (sjc-vpn4-273.cisco.com [10.21.81.17]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALH62626; Thu, 6 Nov 2003 23:28:44 -0800 (PST) Message-Id: <4.3.2.7.2.20031106230355.01a99ac8@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Nov 2003 23:28:43 -0800 To: Christian Hopps From: Les Ginsberg Subject: Re: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.txt) Cc: Mike Shand , Alex Zinin , "" , Tony Przygienda , Tony Li , Acee Lindem In-Reply-To: <7DBE9405-1083-11D8-BD33-00039303E9E2@procket.com> References: <3FA7FF8F.7040606@redback.com> <4.3.2.7.2.20031103144326.01b401c0@mira-sjc5-3.cisco.com> <3FA7FF8F.7040606@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Chris - Replies inline. At 10:03 AM 11/6/2003 -0800, Christian Hopps wrote: >On Nov 3, 2003, at 2:11 PM, Acee Lindem wrote: > >>Les, Mike, >> >>As members of the routing directorate, Chris and I are reviewing the >>subject document. > >My previous private comments have been dealt with in these newer >drafts, so I'll just stick to new comments here, all of which >are editorial in nature. > >Comments inline. > >>INTERNET DRAFT IS-IS restart Oct 2003 >>[...] >>2. Overview >>[...] >> This draft additionally describes a mechanism for a restarting >> router to determine when it has achieved LSP database >> synchronization with its neighbors. >> >> >> >> >>Shand, Ginsberg Expires Apr 2004 [Page 3] >> >> >>INTERNET DRAFT IS-IS restart Oct 2003 >> >> >> This draft additionally describes a mechanism to optimize LSP >> database synchronization and minimize transient routing disruption >> when a router starts. > >These two paragraphs seem clunky. At first I thought it was a >repeat paragraph mistake. Perhaps not having the same 6 words >start the second paragraph would help, or maybe it's just me. No, I don't think it's just you. I remember struggling with this way back when. How about condensing into one paragraph which reads: "This draft additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization and minimize transient routing disruption when a router starts. " ?? >>3. Approach >>3.1 Timers >>3.2 Restart TLV >> >> A new TLV is defined to be included in IIH PDUs. The presence of >> this TLV indicates that the sender supports the functionality >> defined in this document and it carries flags that are used to >> convey information during a (re)start. All IIHs transmitted by a >> router that supports this capability MUST include this TLV. >> >> Type 211 >> Length 1 - (3 + ID Length) >> Value >> Flags (1 octet) >>[...] >> 0 1 2 3 4 5 6 7 >> +--+--+--+--+--+--+--+--+ >> | Reserved |SA|RA|RR| >> +--+--+--+--+--+--+--+--+ > >I think you should illustrate the entire TLV in the "bits" format. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 211 | Length | Flags | Remaining... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ...Time(*) | Restarting Neighbor System ID (**) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >keeping the breakout detail of the Flags field as well. > >Aside from this just being standard, it also avoids confusion such >as: > >> Length 1 - (3 + ID Length) > >Which really meant 1 octet of length which is 3 + ID Length, the >use of "-" is confusing here. :) No. That is not correct. What is included in the TLV is: 1 byte flags (Always) 2 bytes of remaining hold time (only when RA is set) ID length bytes of restarting neighbor system ID (only when RA is set) In addition, because earlier versions of the draft did not include the restarting neighbor system ID (it was a loophole we only discovered prior to V4) it's possible that an implementation may send the hold time but not the system ID. So the number of bytes in the TLV could be: 1 (when RA is not set) 3 (RA set - implementation based on V3 draft or earlier) 9 (RA set - implementation based on V4 or later) While I appreciate your attempts to standardize TLV presentation, I am not so sure the 32 bit picture format makes things clearer in this instance due to the byte oriented nature of most of the info and the variable number of bytes which may be included. I would rather leave the picture as it is, but if I get outvoted I am willing to concede. >Additionally I wouldn't specify the formula for the length as >you have since it depends on what is included. I say leave out the >formula, just describe what goes in the TLV. > >>3.2.1 Use of RR and RA bits >>3.2.2 Use of SA bit >>3.3 Adjacency (re)acquisition >>3.3.1 Adjacency reacquisition during restart >>3.3.2 Adjacency acquisition during start >>3.3.3 Multiple levels >>3.4.1 LSP generation and flooding and SPF computation >>3.4.1.1. Restarting >>3.4.1.2. Starting >>4.1 Running Router >> >> Event | Running | ADJ suppressed >> ============================================================== >> RX RR | Maintain ADJ State | >> | Send RA | >> | Set SRM,send CSNP | >> | (Note 1) | >> | Update Hold Time, | >> | set Restart Mode | >> | (Note 2) | >> -------------+----------------------+------------------------- >> RX RR clr | Clr Restart mode | >> -------------+----------------------+------------------------- >> RX SA set | Suppress IS neighbor | >> | TLV in LSP(s) | >> | Goto ADJ Suppressed | >> -------------+----------------------+------------------------- >> RX SA clr | |Unsuppress IS neighbor >> | | TLV in LSP(s) >> | |Goto Running >> ============================================================== > >Nit, you specify SA "set" but not RR "set". OK. I'll make these consistent. >> Note 1: If ADJ is UP >> Note 2: If Restart Mode clear >> >> >> >> >> >> >> >> >> >>Shand, Ginsberg Expires Apr 2004 [Page 15] >> >> >>INTERNET DRAFT IS-IS restart Oct 2003 >> >> >> >>4.2 Restarting Router >> >> Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait >> | | RA | CSNP | >> =================================================================== >> Router | Send IIH/RR | | | >> restarts | ADJ Init | | | >> | Start T1,T2,T3 | | | >> ------------+--------------------+-----------+-----------+------------ >> RX RR | Send RA | | | >> ------------+--------------------+-----------+-----------+------------ >> RX RA | Adjust T3 | | Cancel T1 | >> | Goto ADJ Seen RA | | Adjust T3 | >> ----------- +--------------------+-----------+-----------+------------ >> RX CSNP | Goto ADJ Seen CSNP | Cancel T1 | | >> ------------+--------------------+-----------+-----------+------------ >> RX IIH w/o | Cancel T1 | | | >> Restart TLV| | | | > >This is for P2P only right, if so please add that. Nope. Works the same on a LAN. >> ------------+--------------------+-----------+-----------+------------ >> T1 Expires | Send IIH/RR |Send IIH/RR|Send IIH/RR| >> | Restart T1 | Restart T1| Restart T1| >> ------------+--------------------+-----------+-----------+------------ >> T1 Expires | Send IIH/ | Send IIH/ | Send IIH/ | >> nth time | normal | normal | normal | >> ------------+--------------------+-----------+-----------+------------ >> T2 expires | Trigger SPF | | | >> | Goto SPF Wait | | | >> ------------+--------------------+-----------+-----------+------------ >> T3 expires | Set OL | | | >> | Flood local LSPs | | | >> | Update fwd plane | | | >> ------------+--------------------+-----------+-----------+------------ >> LSP DB Sync| Cancel T2, and T3 | | | >> | Trigger SPF | | | >> | Goto SPF wait | | | >> ------------+--------------------+-----------+-----------+------------ >> All SPF | | | | Clear OL >> done | | | | Update fwd >> | | | | plane >> | | | | Flood local >> | | | | LSPs >> | | | | Goto Runing >> ====================================================================== >> >> >>Shand, Ginsberg Expires Apr 2004 [Page 16] >> >> >>INTERNET DRAFT IS-IS restart Oct 2003 >> >> >> >>4.3 Starting Router >> >> Event | Starting | ADJ Seen RA| ADJ Seen CSNP >> ============================================================= >> Router | Send IIH/SA | | >> starts | Start T1,T2 | | >> -------------+-------------------+------------+--------------- >> RX RR | Send RA | | >> -------------+-------------------+------------+--------------- >> RX RA | Goto ADJ Seen RA | | Cancel T1 >> -------------+-------------------+------------+--------------- >> RX CSNP Set | Goto ADJ Seen CSNP| Cancel T1 | >> -------------+-------------------+------------+--------------- >> RX IIH w | Cancel T1 | | >> no Restart | | | >> TLV | | | > >Same comment as with restarting FSM. OK. >That's it. > >Thanks, >Chris. Thank you. Les From rtg-dir-admin@ietf.org Fri Nov 7 03:08:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04558 for ; Fri, 7 Nov 2003 03:08:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1ft-0000py-00 for rtg-dir-archive@ietf.org; Fri, 07 Nov 2003 03:08:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI1fs-0000pv-00 for rtg-dir-archive@ietf.org; Fri, 07 Nov 2003 03:08:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1fw-0005on-7K; Fri, 07 Nov 2003 03:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1ez-0005hD-OB for rtg-dir@optimus.ietf.org; Fri, 07 Nov 2003 03:08:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04521 for ; Fri, 7 Nov 2003 03:07:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1ev-0000pI-00 for rtg-dir@ietf.org; Fri, 07 Nov 2003 03:07:57 -0500 Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx with esmtp (Exim 4.12) id 1AI1eu-0000oc-00 for rtg-dir@ietf.org; Fri, 07 Nov 2003 03:07:56 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id AFFBA3DCD27; Fri, 7 Nov 2003 00:10:49 -0800 (PST) In-Reply-To: <4.3.2.7.2.20031106230355.01a99ac8@mira-sjc5-3.cisco.com> References: <3FA7FF8F.7040606@redback.com> <4.3.2.7.2.20031103144326.01b401c0@mira-sjc5-3.cisco.com> <3FA7FF8F.7040606@redback.com> <4.3.2.7.2.20031106230355.01a99ac8@mira-sjc5-3.cisco.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8F2AE32A-10F9-11D8-BD33-00039303E9E2@procket.com> Content-Transfer-Encoding: 7bit Cc: "Acee Lindem" , "Alex Zinin" , "Mike Shand" , "Tony Przygienda" , , "Tony Li" From: Christian Hopps Subject: Re: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.txt) Date: Fri, 7 Nov 2003 00:08:24 -0800 To: "Les Ginsberg" X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Nov 6, 2003, at 11:28 PM, Les Ginsberg wrote: > Chris - > > Replies inline. > > At 10:03 AM 11/6/2003 -0800, Christian Hopps wrote: >> On Nov 3, 2003, at 2:11 PM, Acee Lindem wrote: >> >>> Les, Mike, >>> >>> As members of the routing directorate, Chris and I are reviewing the >>> subject document. >> >> My previous private comments have been dealt with in these newer >> drafts, so I'll just stick to new comments here, all of which >> are editorial in nature. >> >> Comments inline. >> >>> INTERNET DRAFT IS-IS restart Oct 2003 >>> [...] >>> 2. Overview >>> [...] >>> This draft additionally describes a mechanism for a restarting >>> router to determine when it has achieved LSP database >>> synchronization with its neighbors. >>> >>> >>> >>> >>> Shand, Ginsberg Expires Apr 2004 [Page >>> 3] >>> >>> >>> INTERNET DRAFT IS-IS restart Oct 2003 >>> >>> >>> This draft additionally describes a mechanism to optimize LSP >>> database synchronization and minimize transient routing disruption >>> when a router starts. >> >> These two paragraphs seem clunky. At first I thought it was a >> repeat paragraph mistake. Perhaps not having the same 6 words >> start the second paragraph would help, or maybe it's just me. > > No, I don't think it's just you. I remember struggling with this way > back > when. How about condensing into one paragraph which reads: > > > "This draft additionally describes a mechanism for a restarting > router to determine when it has achieved LSP database > synchronization with its neighbors and a mechanism to optimize LSP > database synchronization and minimize transient routing disruption > when a router starts. " > > ?? That's much better IMO. >>> 3. Approach >>> 3.1 Timers >>> 3.2 Restart TLV >>> >>> A new TLV is defined to be included in IIH PDUs. The presence of >>> this TLV indicates that the sender supports the functionality >>> defined in this document and it carries flags that are used to >>> convey information during a (re)start. All IIHs transmitted by a >>> router that supports this capability MUST include this TLV. >>> >>> Type 211 >>> Length 1 - (3 + ID Length) >>> Value >>> Flags (1 octet) >>> [...] >>> 0 1 2 3 4 5 6 7 >>> +--+--+--+--+--+--+--+--+ >>> | Reserved |SA|RA|RR| >>> +--+--+--+--+--+--+--+--+ >> >> I think you should illustrate the entire TLV in the "bits" format. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type = 211 | Length | Flags | Remaining... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ...Time(*) | Restarting Neighbor System ID (**) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> keeping the breakout detail of the Flags field as well. >> >> Aside from this just being standard, it also avoids confusion such >> as: >> >>> Length 1 - (3 + ID Length) >> >> Which really meant 1 octet of length which is 3 + ID Length, the >> use of "-" is confusing here. :) > > No. That is not correct. What is included in the TLV is: > > 1 byte flags (Always) > 2 bytes of remaining hold time (only when RA is set) > ID length bytes of restarting neighbor system ID (only when RA is set) Yes, I understand that. I was just interpreting what "1 - (3 + ID Length)" was supposed to mean in your draft, and not what the length value actually should be set to. Indeed the fact that (3 + ID Length) doesn't correctly describe the length was my point about leaving off the formula altogether. > In addition, because earlier versions of the draft did not include the > restarting neighbor system ID (it was a loophole we only discovered > prior > to V4) it's possible that an implementation may send the hold time but > not > the system ID. So the number of bytes in the TLV could be: > > 1 (when RA is not set) > 3 (RA set - implementation based on V3 draft or earlier) > 9 (RA set - implementation based on V4 or later) > > While I appreciate your attempts to standardize TLV presentation, I am > not > so sure the 32 bit picture format makes things clearer in this > instance due > to the byte oriented nature of most of the info and the variable > number of > bytes which may be included. I would rather leave the picture as it > is, but > if I get outvoted I am willing to concede. Its just the standard form. The main reason for using something similar to my picture is to indicate the on-wire placement. I don't have a strong opinion here, its just what I was told by the ADs on my IS-IS draft. :) >> Additionally I wouldn't specify the formula for the length as >> you have since it depends on what is included. I say leave out the >> formula, just describe what goes in the TLV. >> >>> 3.2.1 Use of RR and RA bits >>> 3.2.2 Use of SA bit >>> 3.3 Adjacency (re)acquisition >>> 3.3.1 Adjacency reacquisition during restart >>> 3.3.2 Adjacency acquisition during start >>> 3.3.3 Multiple levels >>> 3.4.1 LSP generation and flooding and SPF computation >>> 3.4.1.1. Restarting >>> 3.4.1.2. Starting >>> 4.1 Running Router >>> >>> Event | Running | ADJ suppressed >>> ============================================================== >>> RX RR | Maintain ADJ State | >>> | Send RA | >>> | Set SRM,send CSNP | >>> | (Note 1) | >>> | Update Hold Time, | >>> | set Restart Mode | >>> | (Note 2) | >>> -------------+----------------------+------------------------- >>> RX RR clr | Clr Restart mode | >>> -------------+----------------------+------------------------- >>> RX SA set | Suppress IS neighbor | >>> | TLV in LSP(s) | >>> | Goto ADJ Suppressed | >>> -------------+----------------------+------------------------- >>> RX SA clr | |Unsuppress IS neighbor >>> | | TLV in LSP(s) >>> | |Goto Running >>> ============================================================== >> >> Nit, you specify SA "set" but not RR "set". > > OK. I'll make these consistent. > > >>> Note 1: If ADJ is UP >>> Note 2: If Restart Mode clear >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Shand, Ginsberg Expires Apr 2004 [Page >>> 15] >>> >>> >>> INTERNET DRAFT IS-IS restart Oct 2003 >>> >>> >>> >>> 4.2 Restarting Router >>> >>> Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait >>> | | RA | CSNP | >>> =================================================================== >>> Router | Send IIH/RR | | | >>> restarts | ADJ Init | | | >>> | Start T1,T2,T3 | | | >>> >>> ------------+--------------------+-----------+----------- >>> +------------ >>> RX RR | Send RA | | | >>> >>> ------------+--------------------+-----------+----------- >>> +------------ >>> RX RA | Adjust T3 | | Cancel T1 | >>> | Goto ADJ Seen RA | | Adjust T3 | >>> ----------- >>> +--------------------+-----------+-----------+------------ >>> RX CSNP | Goto ADJ Seen CSNP | Cancel T1 | | >>> >>> ------------+--------------------+-----------+----------- >>> +------------ >>> RX IIH w/o | Cancel T1 | | | >>> Restart TLV| | | | >> >> This is for P2P only right, if so please add that. > > Nope. Works the same on a LAN. Hmmm. To quote your draft (from 3.3.1): In the case of a LAN interface, receipt of an IIH not containing the restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. Which to me indicates that for LAN you do *not* cancel T1. Thanks, Chris. >>> >>> ------------+--------------------+-----------+----------- >>> +------------ >>> T1 Expires | Send IIH/RR |Send IIH/RR|Send IIH/RR| >>> | Restart T1 | Restart T1| Restart T1| >>> >>> ------------+--------------------+-----------+----------- >>> +------------ >>> T1 Expires | Send IIH/ | Send IIH/ | Send IIH/ | >>> nth time | normal | normal | normal | >>> >>> ------------+--------------------+-----------+----------- >>> +------------ >>> T2 expires | Trigger SPF | | | >>> | Goto SPF Wait | | | >>> >>> ------------+--------------------+-----------+----------- >>> +------------ >>> T3 expires | Set OL | | | >>> | Flood local LSPs | | | >>> | Update fwd plane | | | >>> >>> ------------+--------------------+-----------+----------- >>> +------------ >>> LSP DB Sync| Cancel T2, and T3 | | | >>> | Trigger SPF | | | >>> | Goto SPF wait | | | >>> >>> ------------+--------------------+-----------+----------- >>> +------------ >>> All SPF | | | | Clear OL >>> done | | | | Update >>> fwd >>> | | | | plane >>> | | | | Flood >>> local >>> | | | | LSPs >>> | | | | Goto >>> Runing >>> >>> ===================================================================== >>> = >>> >>> >>> Shand, Ginsberg Expires Apr 2004 [Page >>> 16] >>> >>> >>> INTERNET DRAFT IS-IS restart Oct 2003 >>> >>> >>> >>> 4.3 Starting Router >>> >>> Event | Starting | ADJ Seen RA| ADJ Seen CSNP >>> ============================================================= >>> Router | Send IIH/SA | | >>> starts | Start T1,T2 | | >>> -------------+-------------------+------------+--------------- >>> RX RR | Send RA | | >>> -------------+-------------------+------------+--------------- >>> RX RA | Goto ADJ Seen RA | | Cancel T1 >>> -------------+-------------------+------------+--------------- >>> RX CSNP Set | Goto ADJ Seen CSNP| Cancel T1 | >>> -------------+-------------------+------------+--------------- >>> RX IIH w | Cancel T1 | | >>> no Restart | | | >>> TLV | | | >> >> Same comment as with restarting FSM. > > OK. > >> That's it. >> >> Thanks, >> Chris. > > Thank you. > > Les > From rtg-dir-admin@ietf.org Fri Nov 7 11:25:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20851 for ; Fri, 7 Nov 2003 11:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9Qv-00077E-00 for rtg-dir-archive@ietf.org; Fri, 07 Nov 2003 11:26:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI9Qv-00077B-00 for rtg-dir-archive@ietf.org; Fri, 07 Nov 2003 11:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9Qv-0006cN-MT; Fri, 07 Nov 2003 11:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9Qc-0006bf-Ik for rtg-dir@optimus.ietf.org; Fri, 07 Nov 2003 11:25:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20840 for ; Fri, 7 Nov 2003 11:25:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9Qb-00076p-00 for rtg-dir@ietf.org; Fri, 07 Nov 2003 11:25:41 -0500 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 1AI9Qa-00076U-00 for rtg-dir@ietf.org; Fri, 07 Nov 2003 11:25:41 -0500 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA7GP7At019232; Fri, 7 Nov 2003 08:25:07 -0800 (PST) Received: from ginsberg-w2k.cisco.com (sjc-vpn4-437.cisco.com [10.21.81.181]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALH79780; Fri, 7 Nov 2003 08:25:05 -0800 (PST) Message-Id: <4.3.2.7.2.20031107081417.01b4bce8@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Nov 2003 08:25:02 -0800 To: Christian Hopps From: Les Ginsberg Subject: Re: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.txt) Cc: "Acee Lindem" , "Alex Zinin" , "Mike Shand" , "Tony Przygienda" , , "Tony Li" In-Reply-To: <8F2AE32A-10F9-11D8-BD33-00039303E9E2@procket.com> References: <4.3.2.7.2.20031106230355.01a99ac8@mira-sjc5-3.cisco.com> <3FA7FF8F.7040606@redback.com> <4.3.2.7.2.20031103144326.01b401c0@mira-sjc5-3.cisco.com> <3FA7FF8F.7040606@redback.com> <4.3.2.7.2.20031106230355.01a99ac8@mira-sjc5-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Chris - At 12:08 AM 11/7/2003 -0800, Christian Hopps wrote: >On Nov 6, 2003, at 11:28 PM, Les Ginsberg wrote: >>Chris - >> >>Replies inline. >> >>At 10:03 AM 11/6/2003 -0800, Christian Hopps wrote: >>>On Nov 3, 2003, at 2:11 PM, Acee Lindem wrote: >>> >>>>Les, Mike, >>>> >>>>As members of the routing directorate, Chris and I are reviewing the >>>>subject document. >>> >>>My previous private comments have been dealt with in these newer >>>drafts, so I'll just stick to new comments here, all of which >>>are editorial in nature. >>> >>>Comments inline. >>> >>>>INTERNET DRAFT IS-IS restart Oct 2003 >>>>[...] >>>>2. Overview >>>>[...] >>>> This draft additionally describes a mechanism for a restarting >>>> router to determine when it has achieved LSP database >>>> synchronization with its neighbors. >>>> >>>> >>>> >>>> >>>>Shand, Ginsberg Expires Apr 2004 [Page >>>>3] >>>> >>>> >>>>INTERNET DRAFT IS-IS restart Oct 2003 >>>> >>>> >>>> This draft additionally describes a mechanism to optimize LSP >>>> database synchronization and minimize transient routing disruption >>>> when a router starts. >>> >>>These two paragraphs seem clunky. At first I thought it was a >>>repeat paragraph mistake. Perhaps not having the same 6 words >>>start the second paragraph would help, or maybe it's just me. >> >>No, I don't think it's just you. I remember struggling with this way >>back >>when. How about condensing into one paragraph which reads: >> >> >> "This draft additionally describes a mechanism for a restarting >> router to determine when it has achieved LSP database >> synchronization with its neighbors and a mechanism to optimize LSP >> database synchronization and minimize transient routing disruption >> when a router starts. " >> >>?? > >That's much better IMO. > >>>>3. Approach >>>>3.1 Timers >>>>3.2 Restart TLV >>>> >>>> A new TLV is defined to be included in IIH PDUs. The presence of >>>> this TLV indicates that the sender supports the functionality >>>> defined in this document and it carries flags that are used to >>>> convey information during a (re)start. All IIHs transmitted by a >>>> router that supports this capability MUST include this TLV. >>>> >>>> Type 211 >>>> Length 1 - (3 + ID Length) >>>> Value >>>> Flags (1 octet) >>>>[...] >>>> 0 1 2 3 4 5 6 7 >>>> +--+--+--+--+--+--+--+--+ >>>> | Reserved |SA|RA|RR| >>>> +--+--+--+--+--+--+--+--+ >>> >>>I think you should illustrate the entire TLV in the "bits" format. >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type = 211 | Length | Flags | Remaining... | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | ...Time(*) | Restarting Neighbor System ID (**) ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>>keeping the breakout detail of the Flags field as well. >>> >>>Aside from this just being standard, it also avoids confusion such >>>as: >>> >>>> Length 1 - (3 + ID Length) >>> >>>Which really meant 1 octet of length which is 3 + ID Length, the >>>use of "-" is confusing here. :) >> >>No. That is not correct. What is included in the TLV is: >> >>1 byte flags (Always) >>2 bytes of remaining hold time (only when RA is set) >>ID length bytes of restarting neighbor system ID (only when RA is set) > >Yes, I understand that. I was just interpreting what >"1 - (3 + ID Length)" was supposed to mean in your draft, >and not what the length value actually should be set to. Indeed >the fact that (3 + ID Length) doesn't correctly describe the >length was my point about leaving off the formula altogether. Hmmm...struggling a bit to understand your objection. You don't the like the use of "-" as it appears to imply an arithmetic computation?? If so, then how about: Length Total length of the value field (1 to (3 + ID length) octets) ?? >>In addition, because earlier versions of the draft did not include the >>restarting neighbor system ID (it was a loophole we only discovered >>prior >>to V4) it's possible that an implementation may send the hold time but >>not >>the system ID. So the number of bytes in the TLV could be: >> >>1 (when RA is not set) >>3 (RA set - implementation based on V3 draft or earlier) >>9 (RA set - implementation based on V4 or later) >> >>While I appreciate your attempts to standardize TLV presentation, I am >>not >>so sure the 32 bit picture format makes things clearer in this >>instance due >>to the byte oriented nature of most of the info and the variable >>number of >>bytes which may be included. I would rather leave the picture as it >>is, but >>if I get outvoted I am willing to concede. > >Its just the standard form. The main reason for using something similar >to my picture is to indicate the on-wire placement. I don't have a >strong opinion here, its just what I was told by the ADs on my >IS-IS draft. :) Understood. I'll go with the majority opinion here - whatever that is. >>>Additionally I wouldn't specify the formula for the length as >>>you have since it depends on what is included. I say leave out the >>>formula, just describe what goes in the TLV. >>> >>>>3.2.1 Use of RR and RA bits >>>>3.2.2 Use of SA bit >>>>3.3 Adjacency (re)acquisition >>>>3.3.1 Adjacency reacquisition during restart >>>>3.3.2 Adjacency acquisition during start >>>>3.3.3 Multiple levels >>>>3.4.1 LSP generation and flooding and SPF computation >>>>3.4.1.1. Restarting >>>>3.4.1.2. Starting >>>>4.1 Running Router >>>> >>>> Event | Running | ADJ suppressed >>>> ============================================================== >>>> RX RR | Maintain ADJ State | >>>> | Send RA | >>>> | Set SRM,send CSNP | >>>> | (Note 1) | >>>> | Update Hold Time, | >>>> | set Restart Mode | >>>> | (Note 2) | >>>> -------------+----------------------+------------------------- >>>> RX RR clr | Clr Restart mode | >>>> -------------+----------------------+------------------------- >>>> RX SA set | Suppress IS neighbor | >>>> | TLV in LSP(s) | >>>> | Goto ADJ Suppressed | >>>> -------------+----------------------+------------------------- >>>> RX SA clr | |Unsuppress IS neighbor >>>> | | TLV in LSP(s) >>>> | |Goto Running >>>> ============================================================== >>> >>>Nit, you specify SA "set" but not RR "set". >> >>OK. I'll make these consistent. >> >> >>>> Note 1: If ADJ is UP >>>> Note 2: If Restart Mode clear >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>Shand, Ginsberg Expires Apr 2004 [Page >>>>15] >>>> >>>> >>>>INTERNET DRAFT IS-IS restart Oct 2003 >>>> >>>> >>>> >>>>4.2 Restarting Router >>>> >>>> Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait >>>> | | RA | CSNP | >>>> =================================================================== >>>> Router | Send IIH/RR | | | >>>> restarts | ADJ Init | | | >>>> | Start T1,T2,T3 | | | >>>> >>>>------------+--------------------+-----------+----------- +------------ >>>> RX RR | Send RA | | | >>>> >>>>------------+--------------------+-----------+----------- +------------ >>>> RX RA | Adjust T3 | | Cancel T1 | >>>> | Goto ADJ Seen RA | | Adjust T3 | >>>> ----------- >>>>+--------------------+-----------+-----------+------------ >>>> RX CSNP | Goto ADJ Seen CSNP | Cancel T1 | | >>>> >>>>------------+--------------------+-----------+----------- +------------ >>>> RX IIH w/o | Cancel T1 | | | >>>> Restart TLV| | | | >>> >>>This is for P2P only right, if so please add that. >> >>Nope. Works the same on a LAN. > >Hmmm. To quote your draft (from 3.3.1): > > In the case of a LAN interface, receipt of an IIH not containing the > restart TLV is unremarkable since synchronization can still occur so > long as at least one of the non-restarting neighboring routers on > the LAN supports restart. Therefore T1 continues to run in this > case. If none of the neighbors on the LAN are restart capable, T1 > will eventually expire after the locally defined number of retries. > >Which to me indicates that for LAN you do *not* cancel T1. Ahhh. Well spotted! I didn't look closely enough at the specific line you were pointing at. I'll correct that. >Thanks, >Chris. Thanx again. Les From rtg-dir-admin@ietf.org Fri Nov 7 13:12:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27432 for ; Fri, 7 Nov 2003 13:12:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIB6S-0000fl-00 for rtg-dir-archive@ietf.org; Fri, 07 Nov 2003 13:13:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIB6R-0000fi-00 for rtg-dir-archive@ietf.org; Fri, 07 Nov 2003 13:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIB6S-0004su-73; Fri, 07 Nov 2003 13:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIB6R-0004sj-L1 for rtg-dir@optimus.ietf.org; Fri, 07 Nov 2003 13:12:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27429 for ; Fri, 7 Nov 2003 13:12:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIB6P-0000ff-00 for rtg-dir@ietf.org; Fri, 07 Nov 2003 13:12:57 -0500 Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx with esmtp (Exim 4.12) id 1AIB6O-0000fH-00 for rtg-dir@ietf.org; Fri, 07 Nov 2003 13:12:56 -0500 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id B0E793DCD27; Fri, 7 Nov 2003 10:15:48 -0800 (PST) In-Reply-To: <4.3.2.7.2.20031107081417.01b4bce8@mira-sjc5-3.cisco.com> References: <4.3.2.7.2.20031106230355.01a99ac8@mira-sjc5-3.cisco.com> <3FA7FF8F.7040606@redback.com> <4.3.2.7.2.20031103144326.01b401c0@mira-sjc5-3.cisco.com> <3FA7FF8F.7040606@redback.com> <4.3.2.7.2.20031106230355.01a99ac8@mira-sjc5-3.cisco.com> <4.3.2.7.2.20031107081417.01b4bce8@mira-sjc5-3.cisco.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <129FFAF6-114E-11D8-BD33-00039303E9E2@procket.com> Content-Transfer-Encoding: 7bit Cc: "Acee Lindem" , "Alex Zinin" , "Mike Shand" , "Tony Przygienda" , , "Tony Li" From: Christian Hopps Subject: Re: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.txt) Date: Fri, 7 Nov 2003 10:13:22 -0800 To: Les Ginsberg X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Nov 7, 2003, at 8:25 AM, Les Ginsberg wrote: > Hmmm...struggling a bit to understand your objection. You don't the > like the use of "-" as it appears to imply an arithmetic computation?? > If so, then how about: > > Length Total length of the value field (1 to (3 + ID length) octets) Oh '-' meant "to". Yes I suppose I object to that (since it took me 2 tries to even get it :). I really don't see the need to specify the length bounds. "Length of the value field in octets" seems fine to me, but whatever. >> Its just the standard form. The main reason for using something >> similar >> to my picture is to indicate the on-wire placement. I don't have a >> strong opinion here, its just what I was told by the ADs on my >> IS-IS draft. :) > > Understood. I'll go with the majority opinion here - whatever that is. Thanks, Chris. From rtg-dir-admin@ietf.org Sun Nov 9 12:35:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04545 for ; Sun, 9 Nov 2003 12:35:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AItTm-0004N9-00 for rtg-dir-archive@ietf.org; Sun, 09 Nov 2003 12:36:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AItTm-0004N5-00 for rtg-dir-archive@ietf.org; Sun, 09 Nov 2003 12:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AItTm-0003bH-9N; Sun, 09 Nov 2003 12:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AItTC-0003aQ-Mr for rtg-dir@optimus.ietf.org; Sun, 09 Nov 2003 12:35:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04537 for ; Sun, 9 Nov 2003 12:35:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AItTB-0004Mg-00 for rtg-dir@ietf.org; Sun, 09 Nov 2003 12:35:25 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AItTA-0004Mb-00 for rtg-dir@ietf.org; Sun, 09 Nov 2003 12:35:24 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AItT9-0003ni-KC for rtg-dir@ietf.org; Sun, 09 Nov 2003 17:35:23 +0000 Date: Sun, 9 Nov 2003 11:34:37 -0600 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <145278339.20031109113437@psg.com> To: rtg-dir@ietf.org Subject: draft-ietf-mpls-in-ip-or-gre MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks- I requested a 2w IETF LC for this document. It's been reviewed here a while ago, so no formal request for review, but if you have any comments--shout. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Sun Nov 9 13:09:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05128 for ; Sun, 9 Nov 2003 13:09:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu0f-0004l5-00 for rtg-dir-archive@ietf.org; Sun, 09 Nov 2003 13:10:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIu0f-0004l2-00 for rtg-dir-archive@ietf.org; Sun, 09 Nov 2003 13:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu0g-0004ov-Ib; Sun, 09 Nov 2003 13:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu0G-0004oa-Gb for rtg-dir@optimus.ietf.org; Sun, 09 Nov 2003 13:09:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05125 for ; Sun, 9 Nov 2003 13:09:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu0E-0004ky-00 for rtg-dir@ietf.org; Sun, 09 Nov 2003 13:09:34 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AIu0D-0004kv-00 for rtg-dir@ietf.org; Sun, 09 Nov 2003 13:09:34 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIu0A-0006FA-If; Sun, 09 Nov 2003 18:09:30 +0000 Date: Sun, 9 Nov 2003 12:08:36 -0600 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1207316780.20031109120836@psg.com> To: Les Ginsberg CC: Christian Hopps , "Acee Lindem" , "Mike Shand" , "Tony Przygienda" , , "Tony Li" Subject: Re: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.txt) In-Reply-To: <4.3.2.7.2.20031107081417.01b4bce8@mira-sjc5-3.cisco.com> References: <4.3.2.7.2.20031106230355.01a99ac8@mira-sjc5-3.cisco.com> <3FA7FF8F.7040606@redback.com> <4.3.2.7.2.20031103144326.01b401c0@mira-sjc5-3.cisco.com> <3FA7FF8F.7040606@redback.com> <4.3.2.7.2.20031106230355.01a99ac8@mira-sjc5-3.cisco.com> <4.3.2.7.2.20031107081417.01b4bce8@mira-sjc5-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Les, Chris >>>While I appreciate your attempts to standardize TLV presentation, I am >>>not >>>so sure the 32 bit picture format makes things clearer in this >>>instance due >>>to the byte oriented nature of most of the info and the variable >>>number of >>>bytes which may be included. I would rather leave the picture as it >>>is, but >>>if I get outvoted I am willing to concede. >> >>Its just the standard form. The main reason for using something similar >>to my picture is to indicate the on-wire placement. I don't have a >>strong opinion here, its just what I was told by the ADs on my >>IS-IS draft. :) > Understood. I'll go with the majority opinion here - whatever that is. This used to be the piece we would check during the AD-review and push for a standard IETF format. The recent agreement was to leave this to the RFC editor team to push back on. The recommendation is to either use the standard IETF representation or the one used in RFC 1195. Alex From rtg-dir-admin@ietf.org Sun Nov 9 14:49:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07600 for ; Sun, 9 Nov 2003 14:49:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIvZQ-0006BN-00 for rtg-dir-archive@ietf.org; Sun, 09 Nov 2003 14:50:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIvZQ-0006BK-00 for rtg-dir-archive@ietf.org; Sun, 09 Nov 2003 14:50:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIvZR-0001XQ-7m; Sun, 09 Nov 2003 14:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIvZ5-0001Ww-TD for rtg-dir@optimus.ietf.org; Sun, 09 Nov 2003 14:49:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07597 for ; Sun, 9 Nov 2003 14:49:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIvZ2-0006B4-00 for rtg-dir@ietf.org; Sun, 09 Nov 2003 14:49:37 -0500 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AIvZ2-00069v-00 for rtg-dir@ietf.org; Sun, 09 Nov 2003 14:49:36 -0500 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id hA9Kg3uF028146 for ; Sun, 9 Nov 2003 15:42:03 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id hA9JkVZn022110 for ; Sun, 9 Nov 2003 14:46:31 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id hA9Jn5Y24941; Sun, 9 Nov 2003 11:49:05 -0800 (PST) Message-Id: <200311091949.hA9Jn5Y24941@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-dir@ietf.org Subject: You're invited to the routing chairs meeting Date: Sun, 9 Nov 2003 11:49:04 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Dear Routing Directorate, We're having a routing chairs meeting from 7:00-10:00 tonight (Sunday) in the Carver Room on the 2nd floor of the Hilton. Please join us if you can; we will be discussing the role of the directorate in document review as well as other topics such as ipr, etc. that the directorate should be interested in. See you there, Bill From rtg-dir-admin@ietf.org Tue Nov 11 15:50:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21110 for ; Tue, 11 Nov 2003 15:50:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfTY-0001rq-00 for rtg-dir-archive@ietf.org; Tue, 11 Nov 2003 15:51:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJfTY-0001rk-00 for rtg-dir-archive@ietf.org; Tue, 11 Nov 2003 15:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfTY-0003im-Ub; Tue, 11 Nov 2003 15:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJfSj-0003Wy-KE for rtg-dir@optimus.ietf.org; Tue, 11 Nov 2003 15:50:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21077 for ; Tue, 11 Nov 2003 15:49:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJfSi-0001r8-00 for rtg-dir@ietf.org; Tue, 11 Nov 2003 15:50:08 -0500 Received: from [209.120.141.56] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1AJfSg-0001qz-00 for rtg-dir@ietf.org; Tue, 11 Nov 2003 15:50:06 -0500 Received: from [74.17.183.143] by 132.151.6.1 SMTP id 26uoif75qg05kY; Tue, 11 Nov 2003 23:40:33 +0400 Message-ID: <1$98$rc2r4uumj7ap-s4$-09sd@s6w.ly> From: "Cosmetic How-To" Reply-To: "Cosmetic How-To" To: Subject: Do you want to be more attractive? Date: Tue, 11 Nov 2003 23:40:33 +0400 X-Mailer: X-Info-Mailx: igtDwriBrvguClit MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="8C232_0FF_.4FA4" X-Priority: 3 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --8C232_0FF_.4FA4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable FINALLY A LIP PLUMPER THAT ACTUALLY WORKS !!! <= /tr>
Get Plump, Sexy Lip's
In Un= der 30 Days!


visit website

= = = =
CITY LIP'S exclusive lip treatment...
>Stimulates = collagen & hyaluronic moisture in your lip's resulting in BIGGER, LUSCIOUS, more SENSUOUS Lip's
>CITY LIP'S is used by men & women in 62 countries. Recommended by Pl= astic Surgeons, Celebrities, & Movie Stars
> CITY LIP'S super-hydrating formula plumps= & reduces unattractive lip= wrinkles & fine lines
> Easy to use, completely = pain-free and GUARANTEED to work in 30 d= ays or your MONEY BACK!

Be the envy of all your friends!

retail $47.95
ONLINE SALE $24.76
you save:= $23.19 (48% OFF)
 ~> BUY 2 GET 1 FREE <~

buy now visi= t website
custome= r ratings:

Women love beauty tips, forward this= to a friend!



Distributors & Affiliates Welcome!

=

 

 

 

--8C232_0FF_.4FA4-- From rtg-dir-admin@ietf.org Thu Nov 13 18:15:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28321 for ; Thu, 13 Nov 2003 18:15:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKQgy-0007ft-00 for rtg-dir-archive@ietf.org; Thu, 13 Nov 2003 18:16:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKQgy-0007fp-00 for rtg-dir-archive@ietf.org; Thu, 13 Nov 2003 18:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKQh0-00087q-2z; Thu, 13 Nov 2003 18:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJQv4-0001bn-AM for rtg-dir@optimus.ietf.org; Tue, 11 Nov 2003 00:18:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06216 for ; Tue, 11 Nov 2003 00:18:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJQv1-00055n-00 for rtg-dir@ietf.org; Tue, 11 Nov 2003 00:18:23 -0500 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 1AJQux-00055K-00 for rtg-dir@ietf.org; Tue, 11 Nov 2003 00:18:19 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 Nov 2003 21:24:11 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAB5Hlw5019829; Mon, 10 Nov 2003 21:17:47 -0800 (PST) Received: from ginsberg-w2k.cisco.com (sjc-vpn3-667.cisco.com [10.21.66.155]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALJ80807; Mon, 10 Nov 2003 21:17:45 -0800 (PST) Message-Id: <4.3.2.7.2.20031110204542.01aff9d8@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Nov 2003 21:17:44 -0800 To: Alex Zinin From: Les Ginsberg Subject: Re: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.txt) Cc: Christian Hopps , "Acee Lindem" , "Mike Shand" , "Tony Przygienda" , , "Tony Li" In-Reply-To: <1207316780.20031109120836@psg.com> References: <4.3.2.7.2.20031107081417.01b4bce8@mira-sjc5-3.cisco.com> <4.3.2.7.2.20031106230355.01a99ac8@mira-sjc5-3.cisco.com> <3FA7FF8F.7040606@redback.com> <4.3.2.7.2.20031103144326.01b401c0@mira-sjc5-3.cisco.com> <3FA7FF8F.7040606@redback.com> <4.3.2.7.2.20031106230355.01a99ac8@mira-sjc5-3.cisco.com> <4.3.2.7.2.20031107081417.01b4bce8@mira-sjc5-3.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_9573465==_" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --=====================_9573465==_ Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:08 PM 11/9/2003 -0600, Alex Zinin wrote: >Les, Chris > > >>>While I appreciate your attempts to standardize TLV presentation, I am > >>>not > >>>so sure the 32 bit picture format makes things clearer in this > >>>instance due > >>>to the byte oriented nature of most of the info and the variable > >>>number of > >>>bytes which may be included. I would rather leave the picture as it > >>>is, but > >>>if I get outvoted I am willing to concede. > >> > >>Its just the standard form. The main reason for using something similar > >>to my picture is to indicate the on-wire placement. I don't have a > >>strong opinion here, its just what I was told by the ADs on my > >>IS-IS draft. :) > > > Understood. I'll go with the majority opinion here - whatever that is. > >This used to be the piece we would check during the AD-review and >push for a standard IETF format. The recent agreement was to leave >this to the RFC editor team to push back on. The recommendation is >to either use the standard IETF representation or the one used >in RFC 1195. > >Alex I have opted for the RFC 1195 format. :-) Attached is new version which I think incorporates all comments. (and diffs) Let me know if there are any more issues. Thanx. Les --=====================_9573465==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-isis-restart-05.txt" INTERNET DRAFT IS-IS restart Nov 2003 Network Working Group M. Shand Internet Draft L. Ginsberg Expiration Date: May 2004 Cisco Systems November 2003 Restart signaling for IS-IS draft-ietf-isis-restart-05.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The IS-IS routing protocol (RFC 1195, ISO/IEC 10589) is a link state intra-domain routing protocol. Normally, when an IS-IS router is restarted, temporary disruption of routing occurs due to events in both the restarting router and the neighbors of the restarting router. The router which has been restarted computes its own routes before achieving database synchronization with its neighbors. The results Shand, Ginsberg Expires May 2004 [Page 1] INTERNET DRAFT IS-IS restart Nov 2003 of this computation are likely to be non-convergent with the routes computed by other routers in the area/domain. Neighbors of the restarting router detect the restart event and cycle their adjacencies with the restarting router through the down state. The cycling of the adjacency state causes the neighbors to regenerate their LSPs describing the adjacency concerned. This in turn causes temporary disruption of routes passing through the restarting router. In certain scenarios the temporary disruption of the routes is highly undesirable. This draft describes mechanisms to avoid or minimize the disruption due to both of these causes. Table of Contents 1. Conventions used in this document..............................2 2. Overview.......................................................3 3. Approach.......................................................4 3.1 Timers.......................................................4 3.2 Restart TLV..................................................4 3.2.1 Use of RR and RA bits.....................................5 3.2.2 Use of SA bit.............................................7 3.3 Adjacency (re)acquisition....................................8 3.3.1 Adjacency reacquisition during restart....................8 3.3.2 Adjacency acquisition during start.......................10 3.3.3 Multiple levels..........................................11 3.4 Database synchronization....................................12 3.4.1 LSP generation and flooding and SPF computation..........12 4. State Tables..................................................16 4.1 Running Router..............................................16 4.2 Restarting Router...........................................17 4.3 Starting Router.............................................18 5. Security Considerations.......................................19 6. Normative References..........................................19 7. Acknowledgments...............................................19 8. Authors' Addresses............................................19 9. Full Copyright Statement......................................20 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. Shand, Ginsberg Expires May 2004 [Page 2] INTERNET DRAFT IS-IS restart Nov 2003 If the control and forwarding functions in a router can be maintained independently, it is possible for the forwarding function state to be maintained across a control function restart. This functionality is assumed when the terms "restart/restarting" are used in this document. The terms "start/starting" are used to refer to a router in which the control function has either been started for the first time or has been restarted but the forwarding functions have not been maintained in a prior state. The terms "(re)start/(re)starting" are used when the text is applicable to both a "starting" and a "restarting" router. 2. Overview When an adjacency is reinitialized as a result of a neighbor restarting, a router does three things: 1. It causes its own LSP(s) to be regenerated, thus triggering SPF runs throughout the area (or in the case of Level 2, throughout the domain). 2. It sets SRMflags on its own LSP database on the adjacency concerned. 3. In the case of a Point-to-Point link it transmits a (set of) CSNP(s) over the adjacency. In the case of a restarting router process, the first of these is highly undesirable, but the second is essential in order to ensure synchronization of the LSP database. The third action above minimizes the number of LSPs which must be exchanged and, if made reliable, provides a means of determining when the LSP databases of the neighboring routers have been synchronized. This is desirable whether the router is being restarted or not (so that the overload bit can be cleared in the router's own LSP, for example). This draft describes a mechanism for a restarting router to signal that it is restarting to its neighbors, and allow them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This draft additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization and minimize transient routing disruption when a router starts. Shand, Ginsberg Expires May 2004 [Page 3] INTERNET DRAFT IS-IS restart Nov 2003 It is assumed that the three-way handshake [5] is being used on Point-to-Point circuits. 3. Approach 3.1 Timers Three additional timers, T1, T2 and T3 are required to support the functionality defined in this document. An instance of the timer T1 is maintained per interface, and indicates the time after which an unacknowledged (re)start attempt will be repeated. A typical value might be 3 seconds. An instance of the timer T2 is maintained for each LSP database present in the system i.e. for a Level1/2 system, there will be an instance of the timer T2 for Level 1 and an instance for Level 2. This is the maximum time that the system will wait for LSPDB synchronization. A typical value might be 60 seconds. A single instance of the timer T3 is maintained for the entire system. It indicates the time after which the router will declare that it has failed to achieve database synchronization (by setting the overload bit in its own LSP). This is initialized to 65535 seconds, but is set to the minimum of the remaining times of received IIHs containing a restart TLV with RA set and an indication that the neighbor has an adjacency in the UP state to the restarting router. NOTE: The timer T3 is only used by a restarting router. 3.2 Restart TLV A new TLV is defined to be included in IIH PDUs. The presence of this TLV indicates that the sender supports the functionality defined in this document and it carries flags that are used to convey information during a (re)start. All IIHs transmitted by a router that supports this capability MUST include this TLV. Type 211 Length # of octets in the value field (1 to (3 + ID Length)) Value Shand, Ginsberg Expires May 2004 [Page 4] INTERNET DRAFT IS-IS restart Nov 2003 No. of octets +-----------------------+ | Flags | 1 +-----------------------+ | Remaining Time | 2 +-----------------------+ | Restarting Neighbor ID| ID Length +-----------------------+ Flags (1 octet) 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | Reserved |SA|RA|RR| +--+--+--+--+--+--+--+--+ RR - Restart Request RA - Restart Acknowledgment SA - Suppress adjacency advertisement (Note: Remaining fields are required when RA bit is set) Remaining Time (2 octets) Remaining holding time (in seconds) Restarting Neighbor System ID (ID Length octets) The system ID of the neighbor to which the RA refers. Note: Implementations based on earlier versions of this document may not include this field in the TLV when RA is set. In this case a router which is expecting an RA on a LAN circuit SHOULD assume that the acknowledgement is directed at the local system.) 3.2.1 Use of RR and RA bits The RR bit is used by a (re)starting router to signal to its neighbors that a (re)start is in progress, that an existing adjacency SHOULD be maintained even under circumstances when the normal operation of the adjacency state machine would require the adjacency to be reinitialized, to request a set of CSNPs, and to request setting of SRMflags. Shand, Ginsberg Expires May 2004 [Page 5] INTERNET DRAFT IS-IS restart Nov 2003 The RA bit is sent by the neighbor of a (re)starting router to acknowledge the receipt of a restart TLV with the RR bit set. When the neighbor of a (re)starting router receives an IIH with the restart TLV having the RR bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then, irrespective of the other contents of the "Intermediate System Neighbors" option (LAN circuits), or the "Point-to-Point Three-Way Adjacency" option (Point-to-Point circuits): a) The state of the adjacency is not changed. If this is the first IIH with the RR bit set that this system has received associated with this adjacency then the adjacency is marked as being in "Restart mode" and the adjacency holding time is refreshed - otherwise the holding time is not refreshed. The "remaining time" transmitted according to (b) below MUST reflect the actual time after which the adjacency will now expire. Receipt of a normal IIH with RR bit reset will clear the "Restart mode" state. This procedure allows the restarting router to cause the neighbor to maintain the adjacency long enough for restart to successfully complete while also preventing repetitive restarts from maintaining an adjacency indefinitely. Whether an adjacency is marked as being in "Restart mode" or not has no effect on adjacency state transitions. b) immediately (i.e. without waiting for any currently running timer interval to expire, but with a small random delay of a few 10s of milliseconds on LANs to avoid "storms"), transmit over the corresponding interface an IIH including the restart TLV with the RR bit clear and the RA bit set, in the case of Point-to-Point adjacencies having updated the "Point-to-Point Three-Way Adjacency" option to reflect any new values received from the (re)starting router. (This allows a restarting router to quickly acquire the correct information to place in its hellos.) The "Remaining Time" MUST be set to the current time (in seconds) before the holding timer on this adjacency is due to expire. If the corresponding interface is a LAN interface, then the Restarting Neighbor System ID SHOULD be set to the System ID of the router from whom the IIH with RR bit set was received. This is required to correctly associate the acknowledgement and holding time in the case where multiple systems on a LAN restart at approximately the same time. This IIH SHOULD be transmitted before any LSPs or SNPs transmitted as a result of the receipt of the original IIH. c) if the corresponding interface is a Point-to-Point interface, or if the receiving router has the highest LnRouterPriority (with highest source MAC address breaking ties) among those routers to which the receiving router has an adjacency in state "Up" on this Shand, Ginsberg Expires May 2004 [Page 6] INTERNET DRAFT IS-IS restart Nov 2003 interface whose IIHs contain the restart TLV, excluding adjacencies to all routers which are considered in "Restart mode" (note the actual DIS is NOT changed by this process), initiate the transmission over the corresponding interface of a complete set of CSNPs, and set SRMflags on the corresponding interface for all LSPs in the local LSP database. Otherwise (i.e. if there was no adjacency in the "UP" state to the system ID in question), process the IIH as normal by reinitializing the adjacency, and setting the RA bit in the returned IIH. 3.2.2 Use of SA bit The SA bit is used by a starting router to request that its neighbor suppress advertisement of the adjacency to the starting router in the neighbor's LSPs. A router which is starting has no maintained forwarding function state. This may or may not be the first time the router has started. If this is not the first time the router has started, copies of LSPs generated by this router in its previous incarnation may exist in the LSP databases of other routers in the network. These copies are likely to appear "newer" than LSPs initially generated by the starting router due to the reinitialization of LSP fragment sequence numbers by the starting router. This may cause temporary blackholes to occur until the normal operation of the update process causes the starting router to regenerate and flood copies of its own LSPs with higher sequence numbers. The temporary blackholes can be avoided if the starting router's neighbors suppress advertising an adjacency to the starting router until the starting router has been able to propagate newer versions of LSPs generated by previous incarnations. When a router receives an IIH with the restart TLV having the SA bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then advertisement of the adjacency to the neighbor in LSPs MUST be suppressed. Until an IIH with the SA bit clear has been received, the neighbor advertisement MUST continue to be suppressed. If the adjacency transitions to the UP state, the new adjacency MUST NOT be advertised until an IIH with the SA bit clear has been received. Note that a router which suppresses advertisement of an adjacency MUST NOT use this adjacency when performing its SPF calculation. In particular, if an implementation follows the example guidelines presented in [3] Annex C.2.5 Step 0:b) "pre-load TENT with the local adjacency database", the suppressed adjacency MUST NOT be loaded into TENT. Shand, Ginsberg Expires May 2004 [Page 7] INTERNET DRAFT IS-IS restart Nov 2003 3.3 Adjacency (re)acquisition Adjacency (re)acquisition is the first step in (re)initialization. Restarting and starting routers will make use of the RR bit in the restart TLV, though each will use it at different stages of the (re)start procedure. 3.3.1 Adjacency reacquisition during restart The restarting router explicitly notifies its neighbor that the adjacency is being reacquired, and hence that it SHOULD NOT reinitialize the adjacency. This is achieved by setting the RR bit in the restart TLV. When the neighbor of a restarting router receives an IIH with the restart TLV having the RR bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then the procedures described in 4.2.1 are followed. A router that does not support the restart capability will ignore the restart TLV and reinitialize the adjacency as normal, returning an IIH without the restart TLV. On restarting, a router initializes the timer T3, starts the timer T2 for each LSPDB and for each interface (and in the case of a LAN circuit, for each level) starts the timer T1 and transmits an IIH containing the restart TLV with the RR bit set. On a Point-to-Point circuit the "Adjacency Three-Way State" SHOULD be set to "Init", because the receipt of the acknowledging IIH (with RA set) MUST cause the adjacency to enter "Up" state immediately. On a LAN circuit the LAN-ID assigned to the circuit SHOULD be the same as that used prior to the restart. In particular, for any circuits for which the restarting router was previously DIS, the use of a different LAN-ID would necessitate the generation of a new set of pseudonode LSPs, and corresponding changes in all the LSPs referencing them from other routers on the LAN. By preserving the LAN-ID across the restart, this churn can be prevented. To enable a restarting router to learn the LAN-ID used prior to restart, the LAN-ID specified in an IIH with RR set MUST be ignored. Transmission of "normal" IIHs is inhibited until the conditions described below are met (in order to avoid causing an unnecessary adjacency initialization). On expiry of the timer T1, it is restarted and the IIH is retransmitted as above. When a restarting router receives an IIH a local adjacency is established as usual, and if the IIH contains a restart TLV with the RA bit set (and on LAN circuits with a Restart Neighbor System ID which matches that of the local system), the receipt of the Shand, Ginsberg Expires May 2004 [Page 8] INTERNET DRAFT IS-IS restart Nov 2003 acknowledgement over that interface is noted. When the RA bit is set and the state of the remote adjacency is UP then the timer T3 is set to the minimum of its current value and the value of the "Remaining Time" field in the received IIH. On a Point-to-Point link, receipt of an IIH not containing the restart TLV is also treated as an acknowledgement, since it indicates that the neighbor is not restart capable. However, since no CSNP is guaranteed to be received over this interface, the timer T1 is cancelled immediately without waiting for a complete set of CSNP(s). Synchronization may therefore be deemed complete even though there are some LSPs which are held (only) by this neighbor (see section 4.4). In this case we also want to be certain that the neighbor will reinitialize the adjacency in order to guarantee that SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. This is guaranteed to happen except in the case where the Adjacency Three-Way State in the received IIH is UP and the Neighbor Extended Local Circuit ID matches the extended local circuit ID assigned by the restarting router. In this case the restarting router MUST force the adjacency to reinitialize by setting the local Adjacency Three-Way State to DOWN and sending a normal IIH. In the case of a LAN interface, receipt of an IIH not containing the restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. In the case of a Point-to-Point circuit, the "LocalCircuitID" and "Extended Local Circuit ID" information contained in the IIH can be used immediately to generate an IIH containing the correct 3-way handshake information. The presence of "Neighbor Extended Local Circuit ID" information which does not match the value currently in use by the local system is ignored (since the IIH may have been transmitted before the neighbor had received the new value from the restarting router), but the adjacency remains in the initializing state until the correct information is received. In the case of a LAN circuit the source neighbor information (e.g. SNPAAddress) is recorded and used for adjacency establishment and maintenance as normal. When BOTH a complete set of CSNP(s) (for each active level, in the case of a pt-pt circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled. Shand, Ginsberg Expires May 2004 [Page 9] INTERNET DRAFT IS-IS restart Nov 2003 Once the timer T3 has expired or been cancelled, subsequent IIHs are transmitted according to the normal algorithms, but including the restart TLV with both RR and RA clear. If a LAN contains a mixture of systems, only some of which support the new algorithm, database synchronization is still guaranteed, but the "old" systems will have reinitialized their adjacencies. If an interface is active, but does not have any neighboring router reachable over that interface the timer T1 would never be cancelled, and according to clause 3.4.1.1 the SPF would never be run. Therefore timer T1 is cancelled after some pre-determined number of expirations (which MAY be 1). (By this time any existing adjacency on a remote system would probably have expired anyway.) 3.3.2 Adjacency acquisition during start The starting router wants to ensure that in the event a neighboring router has an adjacency to the starting router in the UP state (from a previous incarnation of the starting router) that this adjacency is reinitialized. The starting router also wants neighboring routers to suppress advertisement of an adjacency to the starting router until LSP database synchronization is achieved. This is achieved by sending IIHs with the RR bit clear and the SA bit set in the restart TLV. The RR bit remains clear and the SA bit remains set in subsequent transmissions of IIHs until the adjacency has reached the UP state and the initial T1 timer interval (see below) has expired. Receipt of an IIH with RR bit clear will result in the neighboring router utilizing normal operation of the adjacency state machine. This will ensure that any old adjacency on the neighboring router will be reinitialized. On receipt of an IIH with SA bit set the behavior described in 3.2.2 is followed. On starting, a router starts timer T2 for each LSPDB. For each interface (and in the case of a LAN circuit, for each level), when an adjacency reaches the UP state, the starting router starts a timer T1 and transmits an IIH containing the restart TLV with the RR bit clear and SA bit set. On expiry of the timer T1, it is restarted and the IIH is retransmitted with both RR and SA bits set (only the RR bit has changed state from earlier IIHs). On receipt of an IIH with RR bit set (regardless of whether SA is set or not) the behavior described in 3.2.1 is followed. When an IIH is received by the starting router and the IIH contains a restart TLV with the RA bit set (and on LAN circuits with a Shand, Ginsberg Expires May 2004 [Page 10] INTERNET DRAFT IS-IS restart Nov 2003 Restart Neighbor System ID which matches that of the local system), the receipt of the acknowledgement over that interface is noted. On a Point-to-Point link, receipt of an IIH not containing the restart TLV is also treated as an acknowledgement, since it indicates that the neighbor is not restart capable. Since the neighbor will have reinitialized the adjacency this guarantees that SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. However, since no CSNP is guaranteed to be received over this interface, the timer T1 is cancelled immediately without waiting for a complete set of CSNP(s). Synchronization may therefore be deemed complete even though there are some LSPs which are held (only) by this neighbor (see section 4.4). In the case of a LAN interface, receipt of an IIH not containing the restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. The usual operation of the update process will ensure that synchronization is eventually achieved. When BOTH a complete set of CSNP(s) (for each active level, in the case of a pt-pt circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled. Subsequent IIHs sent by the starting router have the RR and RA bits clear and the SA bit set in the restart TLV. Timer T1 is cancelled after some pre-determined number of expirations (which MAY be 1). When the T2 timer(s) are cancelled or expire transmission of "normal" IIHs (with RR, RA, and SA bits clear) will begin. 3.3.3 Multiple levels A router which is operating as both a Level 1 and a Level 2 router on a particular interface MUST perform the above operations for each level. On a LAN interface, it MUST send and receive both Level 1 and Level 2 IIHs and perform the CSNP synchronizations independently for each level. On a pt-pt interface, only a single IIH (indicating support for both levels) is required, but it MUST perform the CSNP synchronizations independently for each level. Shand, Ginsberg Expires May 2004 [Page 11] INTERNET DRAFT IS-IS restart Nov 2003 3.4 Database synchronization When a router is started or restarted it can expect to receive a (set of) CSNP(s) over each interface. The arrival of the CSNP(s) is now guaranteed, since an IIH with RR bit set will be retransmitted until the CSNP(s) are correctly received. The CSNPs describe the set of LSPs that are currently held by each neighbor. Synchronization will be complete when all these LSPs have been received. When (re)starting, a router starts an instance of timer T2 for each LSPDB as described in 4.3.1 or 4.3.2. In addition to normal processing of the CSNPs, the set of LSPIDs contained in the first complete set of CSNP(s) received over each interface is recorded, together with their remaining lifetime. In the case of a LAN interface, a complete set of CSNPs MUST consist of CSNPs received from neighbor(s) which are not restarting. If there are multiple interfaces on the (re)starting router, the recorded set of LSPIDs is the union of those received over each interface. LSPs with a remaining lifetime of zero are NOT so recorded. As LSPs are received (by the normal operation of the update process) over any interface, the corresponding LSPID entry is removed (it is also removed if the LSP had arrived before the CSNP containing the reference). When an LSPID has been held in the list for its indicated remaining lifetime, it is removed from the list. When the list of LSPIDs is empty and the timer T1 has been cancelled for all the interfaces that have an adjacency at this level, the timer T2 is cancelled. At this point the local database is guaranteed to contain all the LSP(s) (either the same sequence number, or a more recent sequence number) which were present in the neighbors' databases at the time of (re)starting. LSPs that arrived in a neighbor's database after the time of (re)starting may or may not be present, but the normal operation of the update process will guarantee that they will eventually be received. At this point the local database is deemed to be "synchronized". Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime are not recorded, and those with a short remaining lifetime are deleted from the list when the lifetime expires, cancellation of the timer T2 will not be prevented by waiting for an LSP that will never arrive. 3.4.1 LSP generation and flooding and SPF computation The operation of a router starting, as opposed to restarting is somewhat different. These two cases are dealt with separately below. Shand, Ginsberg Expires May 2004 [Page 12] INTERNET DRAFT IS-IS restart Nov 2003 3.4.1.1. Restarting In order to avoid causing unnecessary routing churn in other routers, it is highly desirable that the own LSPs generated by the restarting system are the same as those previously present in the network (assuming no other changes have taken place). It is important therefore not to regenerate and flood the LSPs until all the adjacencies have been re-established and any information required for propagation into the local LSPs is fully available. Ideally, the information is loaded into the LSPs in a deterministic way, such that the same information occurs in the same place in the same LSP (and hence the LSPs are identical to their previous versions). If this can be achieved, the new versions will not even cause SPF to be run in other systems. However, provided the same information is included in the set of LSPs (albeit in a different order, and possibly different LSPs), the result of running the SPF will be the same and will not cause churn to the forwarding tables. In the case of a restarting router, none of the router's own LSPs are transmitted, nor are the router's own forwarding tables updated while the timer T3 is running. Redistribution of inter-level information MUST be regenerated before this router's LSP is flooded to other nodes. Therefore the Level-n non-pseudonode LSP(s) MUST NOT be flooded until the other level's T2 timer has expired and its SPF has been run. This ensures that any inter-level information which is to be propagated can be included in the Level-n LSP(s). During this period, if one of the router's own (including pseudonodes) LSPs is received, which the local router does not currently have in its own database, it is NOT purged. Under normal operation, such an LSP would be purged, since the LSP clearly should not be present in the global LSP database. However, in the present circumstances, this would be highly undesirable, because it could cause premature removal of an own LSP - and hence churn in remote routers. Even if the local system has one or more own LSPs (which it has generated, but not yet transmitted) it is still not valid to compare the received LSP against this set, since it may be that as a result of propagation between Level 1 and Level 2 (or vice versa) a further own LSP will need to be generated when the LSP databases have synchronized. During this period a restarting router SHOULD send CSNPs as it normally would. Information about the router's own LSPs MAY be included, but if it is included it MUST be based on LSPs which have been received, not on versions which have been generated (but not Shand, Ginsberg Expires May 2004 [Page 13] INTERNET DRAFT IS-IS restart Nov 2003 yet transmitted). This restriction is necessary to prevent premature removal of an LSP from the global LSP database. When the timer T2 expires or is cancelled indicating that synchronization for that level is complete, the SPF for that level is run in order to derive any information which is required to be propagated to another level, but the forwarding tables are not yet updated. Once the other level's SPF has run and any inter-level propagation has been resolved, the 'own' LSPs can be generated and flooded. Any 'own' LSPs which were previously ignored, but which are not part of the current set of 'own' LSPs (including pseudonodes) MUST then be purged. Note that it is possible that a Designated Router change may have taken place, and consequently the router SHOULD purge those pseudonode LSPs which it previously owned, but which are now no longer part of its set of pseudonode LSPs. When all the T2 timers have expired or been cancelled, the timer T3 is cancelled and the local forwarding tables are updated. If the timer T3 expires before all the T2 timers have expired or been cancelled, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and therefore other routers MUST NOT compute routes through this router). Normal operation of the update process resumes and the local forwarding tables are updated. In order to prevent the neighbor's adjacencies from expiring, IIHs with the normal interface value for the holding time are transmitted over all interfaces with neither RR nor RA set in the restart TLV. This will cause the neighbors to refresh their adjacencies. The own LSP(s) will continue to have the overload bit set until timer T2 has expired or been cancelled. 3.4.1.2. Starting In the case of a starting router, as soon as each adjacency is established, and before any CSNP exchanges, the router's own zeroth LSP is transmitted with the overload bit set. This prevents other routers from computing routes through the router until it has reliably acquired the complete set of LSPs. The overload bit remains set in subsequent transmissions of the zeroth LSP (such as will occur if a previous copy of the routers LSP is still present in the network) while any timer T2 is running. When all the T2 timers have been cancelled, the own LSP(s) MAY be regenerated with the overload bit clear (assuming the router isn't Shand, Ginsberg Expires May 2004 [Page 14] INTERNET DRAFT IS-IS restart Nov 2003 in fact overloaded, and there is no other reason, such as incomplete BGP convergence, to keep the overload bit set), and flooded as normal. Other 'own' LSPs (including pseudonodes) are generated and flooded as normal, irrespective of the timer T2. The SPF is also run as normal and the RIB and FIB updated as routes become available. To avoid the possible formation of temporary blackholes the starting router sets the SA bit in the restart TLV (as described in 4.3.2) in all IIHs that it sends. When all T2 timers have been cancelled the starting router MUST transmit IIHs with the SA bit clear. Shand, Ginsberg Expires May 2004 [Page 15] INTERNET DRAFT IS-IS restart Nov 2003 4. State Tables This section presents state tables which summarize the behaviors described in this document. Other behaviors, in particular adjacency state transitions and LSP database update operation, are NOT included in the state tables except where this document modifies the behaviors described in [3] and [5]. Three state tables are presented from the point of view of a running router, a restarting router, and a starting router. 4.1 Running Router Event | Running | ADJ suppressed ============================================================== RX RR | Maintain ADJ State | | Send RA | | Set SRM,send CSNP | | (Note 1) | | Update Hold Time, | | set Restart Mode | | (Note 2) | -------------+----------------------+------------------------- RX RR clr | Clr Restart mode | -------------+----------------------+------------------------- RX SA | Suppress IS neighbor | | TLV in LSP(s) | | Goto ADJ Suppressed | -------------+----------------------+------------------------- RX SA clr | |Unsuppress IS neighbor | | TLV in LSP(s) | |Goto Running ============================================================== Note 1: If ADJ is UP Note 2: If Restart Mode clear Shand, Ginsberg Expires May 2004 [Page 16] INTERNET DRAFT IS-IS restart Nov 2003 4.2 Restarting Router Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait | | RA | CSNP | =================================================================== Router | Send IIH/RR | | | restarts | ADJ Init | | | | Start T1,T2,T3 | | | ------------+--------------------+-----------+-----------+------------ RX RR | Send RA | | | ------------+--------------------+-----------+-----------+------------ RX RA | Adjust T3 | | Cancel T1 | | Goto ADJ Seen RA | | Adjust T3 | ----------- +--------------------+-----------+-----------+------------ RX CSNP set| Goto ADJ Seen CSNP | Cancel T1 | | ------------+--------------------+-----------+-----------+------------ RX IIH w/o | Cancel T1 (Point- | | | Restart TLV| to-point only) | | | ------------+--------------------+-----------+-----------+------------ T1 Expires | Send IIH/RR |Send IIH/RR|Send IIH/RR| | Restart T1 | Restart T1| Restart T1| ------------+--------------------+-----------+-----------+------------ T1 Expires | Send IIH/ | Send IIH/ | Send IIH/ | nth time | normal | normal | normal | ------------+--------------------+-----------+-----------+------------ T2 expires | Trigger SPF | | | | Goto SPF Wait | | | ------------+--------------------+-----------+-----------+------------ T3 expires | Set OL | | | | Flood local LSPs | | | | Update fwd plane | | | ------------+--------------------+-----------+-----------+------------ LSP DB Sync| Cancel T2, and T3 | | | | Trigger SPF | | | | Goto SPF wait | | | ------------+--------------------+-----------+-----------+------------ All SPF | | | | Clear OL done | | | | Update fwd | | | | plane | | | | Flood local | | | | LSPs | | | | Goto Runing ====================================================================== Shand, Ginsberg Expires May 2004 [Page 17] INTERNET DRAFT IS-IS restart Nov 2003 4.3 Starting Router Event | Starting | ADJ Seen RA| ADJ Seen CSNP ============================================================= Router | Send IIH/SA | | starts | Start T1,T2 | | -------------+-------------------+------------+--------------- RX RR | Send RA | | -------------+-------------------+------------+--------------- RX RA | Goto ADJ Seen RA | | Cancel T1 -------------+-------------------+------------+--------------- RX CSNP Set | Goto ADJ Seen CSNP| Cancel T1 | -------------+-------------------+------------+--------------- RX IIH w | Cancel T1 | | no Restart | (Point-to-Point | | TLV | only) | | -------------+-------------------+------------+--------------- ADJ UP | Start T1 | | | Send local LSPs | | | w OL | | -------------+-------------------+------------+--------------- T1 Expires | Send IIH/RR |Send IIH/RR | Send IIH/RR | and SA | and SA | and SA | Restart T1 |Restart T1 | Restart T1 -------------+-------------------+------------+--------------- T1 Expires | Send IIH/SA |Send IIH/SA | Send IIH/SA nth time | | | -------------+-------------------+------------+--------------- T2 expires | Clear OL | | | Send IIH normal | | | Goto Running | | -------------+-------------------+------------+--------------- LSP DB Sync | Cancel T2 | | | Clear OL | | | Send IIH normal | | ============================================================== Shand, Ginsberg Expires May 2004 [Page 18] INTERNET DRAFT IS-IS restart Nov 2003 5. Security Considerations This memo does not create any new security issues for the IS-IS protocol. Security considerations for the base IS-IS protocol are covered in [2] and [3]. 6. Normative References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990. 3 ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002, Second Edition. 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5 Katz, D., "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 3373, September 2002 7. Acknowledgments The authors would like to acknowledge contributions made by Jeff Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, Russ White, and Rena Yang. 8. Authors' Addresses Mike Shand Cisco Systems 250 Longwater Avenue, Reading, Berkshire, RG2 6GB UK Phone: +44 208 824 8690 Email: mshand@cisco.com Les Ginsberg Cisco Systems 510 McCarthy Blvd. Shand, Ginsberg Expires May 2004 [Page 19] INTERNET DRAFT IS-IS restart Nov 2003 Milpitas, Ca. 95035 USA Email: ginsberg@cisco.com 9. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Shand, Ginsberg Expires May 2004 [Page 20] --=====================_9573465==_ Content-Type: text/plain; name="diffs.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Disposition: attachment; filename="diffs.txt" Content-Transfer-Encoding: base64 MzcxLDM4NmMzNzEsMzg2CjwgICAgV2hlbiBhIHJvdXRlciByZWNlaXZlcyBhbiBJSUggd2l0aCB0 aGUgcmVzdGFydCBUTFYgaGF2aW5nIHRoZSBTQSBiaXQgCjwgICAgc2V0LCBpZiB0aGVyZSBleGlz dHMgb24gdGhpcyBpbnRlcmZhY2UgYW4gYWRqYWNlbmN5IGluIHN0YXRlICJVcCIgCjwgICAgd2l0 aCB0aGUgc2FtZSBTeXN0ZW0gSUQsIGFuZCBpbiB0aGUgY2FzZSBvZiBhIExBTiBjaXJjdWl0LCB3 aXRoIHRoZSAKPCAgICBzYW1lIHNvdXJjZSBMQU4gYWRkcmVzcywgdGhlbiBhZHZlcnRpc2VtZW50 IG9mIHRoZSBhZGphY2VuY3kgdG8gdGhlIAo8ICAgIG5laWdoYm9yIGluIExTUHMgTVVTVCBiZSBz dXBwcmVzc2VkLiBVbnRpbCBhbiBJSUggd2l0aCB0aGUgU0EgYml0IAo8ICAgIGNsZWFyIGhhcyBi ZWVuIHJlY2VpdmVkLCB0aGUgbmVpZ2hib3IgYWR2ZXJ0aXNlbWVudCBNVVNUIGNvbnRpbnVlIHRv IAo8ICAgIGJlIHN1cHByZXNzZWQuIElmIHRoZSBhZGphY2VuY3kgdHJhbnNpdGlvbnMgdG8gdGhl IFVQIHN0YXRlLCB0aGUgbmV3IAo8ICAgIGFkamFjZW5jeSBNVVNUIE5PVCBiZSBhZHZlcnRpc2Vk IHVudGlsIGFuIElJSCB3aXRoIHRoZSBTQSBiaXQgY2xlYXIgCjwgICAgaGFzIGJlZW4gcmVjZWl2 ZWQuIAo8IAo8ICAgIE5vdGUgdGhhdCBhIHJvdXRlciB3aGljaCBzdXBwcmVzc2VzIGFkdmVydGlz ZW1lbnQgb2YgYW4gYWRqYWNlbmN5ICAKPCAgICBNVVNUIE5PVCB1c2UgdGhpcyBhZGphY2VuY3kg d2hlbiBwZXJmb3JtaW5nIGl0cyBTUEYgY2FsY3VsYXRpb24uIEluIAo8ICAgIHBhcnRpY3VsYXIs IGlmIGFuIGltcGxlbWVudGF0aW9uIGZvbGxvd3MgdGhlIGV4YW1wbGUgZ3VpZGVsaW5lcyAKPCAg ICBwcmVzZW50ZWQgaW4gWzNdIEFubmV4IEMuMi41IFN0ZXAgMDpiKSAicHJlLWxvYWQgVEVOVCB3 aXRoIHRoZSBsb2NhbCAKPCAgICBhZGphY2VuY3kgZGF0YWJhc2UiLCB0aGUgc3VwcHJlc3NlZCBh ZGphY2VuY3kgTVVTVCBOT1QgYmUgbG9hZGVkIAo8ICAgIGludG8gVEVOVC4gCi0tLQo+ICAgIFdo ZW4gdGhlIG5laWdoYm9yIG9mIGEgc3RhcnRpbmcgcm91dGVyIHJlY2VpdmVzIGFuIElJSCB3aXRo IHRoZSANCj4gICAgcmVzdGFydCBUTFYgaGF2aW5nIHRoZSBTQSBiaXQgc2V0LCBpZiB0aGVyZSBl eGlzdHMgb24gdGhpcyBpbnRlcmZhY2UgDQo+ICAgIGFuIGFkamFjZW5jeSBpbiBzdGF0ZSAiVXAi IHdpdGggdGhlIHNhbWUgU3lzdGVtIElELCBhbmQgaW4gdGhlIGNhc2UgDQo+ICAgIG9mIGEgTEFO IGNpcmN1aXQsIHdpdGggdGhlIHNhbWUgc291cmNlIExBTiBhZGRyZXNzLCB0aGVuIA0KPiAgICBh ZHZlcnRpc2VtZW50IG9mIHRoZSBhZGphY2VuY3kgdG8gdGhlIHN0YXJ0aW5nIHJvdXRlciBpbiBM U1BzIE1VU1QgDQo+ICAgIGJlIHN1cHByZXNzZWQuIFVudGlsIGFuIElJSCB3aXRoIHRoZSBTQSBi aXQgY2xlYXIgaGFzIGJlZW4gcmVjZWl2ZWQsIA0KPiAgICB0aGUgYWRqYWNlbmN5IGFkdmVydGlz ZW1lbnQgTVVTVCBjb250aW51ZSB0byBiZSBzdXBwcmVzc2VkLiBJZiB0aGUgDQo+ICAgIGFkamFj ZW5jeSB0cmFuc2l0aW9ucyB0byB0aGUgVVAgc3RhdGUsIHRoZSBuZXcgYWRqYWNlbmN5IE1VU1Qg Tk9UIGJlIA0KPiAgICBhZHZlcnRpc2VkIHVudGlsIGFuIElJSCB3aXRoIHRoZSBTQSBiaXQgY2xl YXIgaGFzIGJlZW4gcmVjZWl2ZWQuIA0KPiANCj4gICAgTm90ZSB0aGF0IGEgcm91dGVyIHdoaWNo IHN1cHByZXNzZXMgYWR2ZXJ0aXNlbWVudCBvZiB0aGUgYWRqYWNlbmN5IA0KPiAgICB0byB0aGUg c3RhcnRpbmcgcm91dGVyIE1VU1QgTk9UIHVzZSB0aGlzIGFkamFjZW5jeSB3aGVuIHBlcmZvcm1p bmcgDQo+ICAgIGl0cyBTUEYgY2FsY3VsYXRpb24uIEluIHBhcnRpY3VsYXIsIGlmIGFuIGltcGxl bWVudGF0aW9uIGZvbGxvd3MgdGhlIA0KPiAgICBleGFtcGxlIGd1aWRlbGluZXMgcHJlc2VudGVk IGluIFszXSBBbm5leCBDLjIuNSBTdGVwIDA6YikgInByZS1sb2FkIA0KPiAgICBURU5UIHdpdGgg dGhlIGxvY2FsIGFkamFjZW5jeSBkYXRhYmFzZSIsIHRoZSBzdXBwcmVzc2VkIGFkamFjZW5jeSAN Cj4gICAgTVVTVCBOT1QgYmUgbG9hZGVkIGludG8gVEVOVC4gDQo1NDJjNTQyCjwgICAgT24gcmVj ZWlwdCBvZiBhbiBJSUggd2l0aCBTQSBiaXQgc2V0IHRoZSBiZWhhdmlvciBkZXNjcmliZWQgaW4g My4yLjIgCi0tLQo+ICAgIE9uIHJlY2VpcHQgb2YgYW4gSUlIIHdpdGggU0EgYml0IHNldCB0aGUg YmVoYXZpb3IgZGVzY3JpYmVkIGluIDQuMi4yIA0KNTU1YzU1NQo8ICAgIHNldCBvciBub3QpIHRo ZSBiZWhhdmlvciBkZXNjcmliZWQgaW4gMy4yLjEgaXMgZm9sbG93ZWQuICAKLS0tCj4gICAgc2V0 IG9yIG5vdCkgdGhlIGJlaGF2aW9yIGRlc2NyaWJlZCBpbiA0LjIuMSBpcyBmb2xsb3dlZC4gIA0K --=====================_9573465==_-- From rtg-dir-admin@ietf.org Sat Nov 15 15:45:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19366 for ; Sat, 15 Nov 2003 15:45:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL7Iw-0005IK-00 for rtg-dir-archive@ietf.org; Sat, 15 Nov 2003 15:46:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AL7Iw-0005IG-00 for rtg-dir-archive@ietf.org; Sat, 15 Nov 2003 15:46:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL7Iw-0002V6-2J; Sat, 15 Nov 2003 15:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AL7IU-0002Ri-GI for rtg-dir@optimus.ietf.org; Sat, 15 Nov 2003 15:45:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19338 for ; Sat, 15 Nov 2003 15:45:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AL7IS-0005FF-00 for rtg-dir@ietf.org; Sat, 15 Nov 2003 15:45:32 -0500 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1AL7IS-0005E6-00 for rtg-dir@ietf.org; Sat, 15 Nov 2003 15:45:32 -0500 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" , Alex Zinin Cc: Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , rtg-dir@ietf.org, Tony Li Subject: RE: Restart Signaling for IS-IS - 05 Date: Sat, 15 Nov 2003 15:44:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , A few nits on the first half of the document. YMMV. I've put my suggestions in quotes. The original text is from a draft dated Nov 2003. I will try to review the rest of the doc next week. - jeff parker 3.2 Restart TLV ...All IIHs transmitted by a router that supports this capability MUST include this TLV. This doesn't deal with the case that the router supports the capability, but the capability isn't enabled. I'm not happy with the proposal below, but don't want to carp without offering an alternative. "...All IIHs transmitted by a router -that is supporting- this capability MUST include this TLV" ID Length ID Length appears in a couple of spots. Haven't we agreed that it is 6? Type 211 Length # of octets in the value field (1 to (3 + ID Length)) Value I take this to mean that the TLV has variable length, though the figure seems to suggest that it always has 10 bytes. The suggestion below is clumsy, but I didn't find a precedent to steal from. No. of octets +-----------------------+ | Flags | 1 +-----------------------+ | Remaining Time | 2 (optional) +-----------------------+ | Restarting Neighbor ID| ID Length (optional, and only present +-----------------------+ if Remaining Time is present) And do we need to explain what to do if an RA has a zero Remaining Time? Restarting Neighbor System ID (ID Length octets) The system ID of the neighbor to which the RA refers. Nit - "to which -an- RA refers." This TLV might be an RR, not an RA. When a router receives an IIH with the restart TLV having the SA bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then advertisement of the adjacency to the neighbor in LSPs MUST be suppressed. Why do we care if there is already an adjacency? Perhaps we had one once, but it timed out. There will still be aged LSPs lurking in the network, with the same chance of black holes. I suggest "When a router receives an IIH with the restart TLV having the SA bit set, then the router must suppress advertisement of the adjacency to the neighbor in his LSPs." I've also moved from the passive to active voice, which makes it clearer who is suppressing what to whom. Note that a router which suppresses advertisement of an adjacency MUST NOT use this adjacency when performing its SPF calculation. That is, we must use information consistent with the LSP we are sending, or "A router which is suppressing advertisement of an adjacency MUST use only the information advertised in its LSPs in its own SPF calculations. Thus it MUST NOT use this adjacency in computing routes." On a Point-to-Point circuit the "Adjacency Three-Way State" SHOULD be set to "Init", because the receipt of the acknowledging IIH (with RA set) MUST cause the adjacency to enter "Up" state immediately. It is not clear to me whose three way state this is, and if it is the state in the adjacency table or the state in the 3Way TLV. If an interface is active, but does not have any neighboring router reachable over that interface the timer T1 would never be cancelled, and according to clause 3.4.1.1 the SPF would never be run. Therefore timer T1 is cancelled after some pre-determined number of expirations (which MAY be 1). (By this time any existing adjacency on a remote system would probably have expired anyway.) I think the comment (By this time any existing adjacency on a remote system would probably have expired anyway.) was left over from a time when you were suggesting 3 expirations. It doesn't seem probably with 1 expiration. For each interface (and in the case of a LAN circuit, for each level), when an adjacency reaches the UP state, the starting router starts a timer T1 and transmits an IIH containing the restart TLV with the RR bit clear and SA bit set. ... On receipt of an IIH with RR bit set (regardless of whether SA is set or not) the behavior described in 3.2.1 is followed. This allows the starting router to signal the helper that he thinks the adjacency is up. I believe the reference in the second paragraph above is asking for the neighbors set of LSPs and CSNPs, not the first clause in 3.2.1. I'd suggest something like "On receipt of an IIH with RR bit set (regardless of whether SA is set or not) the behavior described in 3.2.1 b) and c) is followed: the helping router sends a complete set of LSPs, and a complete set of CSNPs is sent if the helping router meets the conditions described in 3.2.1 c)." This runs the risk of weakening the description of conditions for sending CSPNs, but some indication of what the section describes would help the reader. In any case, isn't this standard behavior? Since the starter is forcing the adjacency to restart, isn't this behavior automatic? From rtg-dir-admin@ietf.org Sat Nov 15 23:20:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03512 for ; Sat, 15 Nov 2003 23:20:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALEPD-0004Kh-00 for rtg-dir-archive@ietf.org; Sat, 15 Nov 2003 23:20:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALEPD-0004Ke-00 for rtg-dir-archive@ietf.org; Sat, 15 Nov 2003 23:20:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALEPE-0003LB-9x; Sat, 15 Nov 2003 23:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALEP9-0003Kv-2E for rtg-dir@optimus.ietf.org; Sat, 15 Nov 2003 23:20:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03505 for ; Sat, 15 Nov 2003 23:20:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALEP7-0004KV-00 for rtg-dir@ietf.org; Sat, 15 Nov 2003 23:20:53 -0500 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 1ALEP6-0004KC-00 for rtg-dir@ietf.org; Sat, 15 Nov 2003 23:20:52 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Nov 2003 20:23:23 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAG4KJAt029404; Sat, 15 Nov 2003 20:20:20 -0800 (PST) Received: from ginsberg-w2k.cisco.com (sjc-vpn1-570.cisco.com [10.21.98.58]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALN51623; Sat, 15 Nov 2003 20:20:18 -0800 (PST) Message-Id: <4.3.2.7.2.20031115191139.01a9dac8@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 15 Nov 2003 20:20:18 -0800 To: Jeff Parker From: Les Ginsberg Subject: RE: Restart Signaling for IS-IS - 05 Cc: Alex Zinin , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , rtg-dir@ietf.org, Tony Li In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Professor Parker - Welcome to the party! At 03:44 PM 11/15/2003 -0500, Jeff Parker wrote: >A few nits on the first half of the document. YMMV. >I've put my suggestions in quotes. > >The original text is from a draft dated Nov 2003. That's the latest. >I will try to review the rest of the doc next week. > >- jeff parker > > 3.2 Restart TLV > > ...All IIHs transmitted by a > router that supports this capability MUST include this TLV. > >This doesn't deal with the case that the router supports the capability, but >the capability isn't enabled. I'm not happy with the proposal below, but >don't want to carp without offering an alternative. > > "...All IIHs transmitted by a > router -that is supporting- this capability MUST include this TLV" > The point of the text is to make clear that a router which supports the capability sends the Restart TLV always, not just when it is restarting/starting (but you knew that). Frankly I am not concerned with whether the box has a knob to enable/disable the feature. If it is turned off, from an operational point of view the router doesn't support the feature. And I find your suggestion leads me to ask the questions: "Is there something an implementation is supposed to do if it WAS supporting the feature? Or if it COULD support the feature but isn't? " And I don't like where that leads us... > ID Length > >ID Length appears in a couple of spots. Haven't we agreed that it is 6? > We've agreed that nobody uses anything other than 6. But the spec still allows different values, though they are not useful/interoperable. Are you flogging us because we choose to be strict in our presentation? Certainly the use of "ID length" here in no way is meant to imply that something other than 6 should be used. It just uses the terminology which is appropriate. Please see RFC 3373. > Type 211 > Length # of octets in the value field (1 to (3 + ID Length)) > Value > >I take this to mean that the TLV has variable length, though the figure >seems to suggest that it always has 10 bytes. We clearly state: "(Note: Remaining fields are required when RA bit is set) " Is this not clear enough? I do not like "optional". If RA is set, the remaining fields are "required", not optional. > The suggestion below is >clumsy, but I didn't find a precedent to steal from. > No. of octets > +-----------------------+ > | Flags | 1 > +-----------------------+ > | Remaining Time | 2 (optional) > +-----------------------+ > | Restarting Neighbor ID| ID Length (optional, and only >present > +-----------------------+ if Remaining Time is present) > >And do we need to explain what to do if an RA has a zero Remaining Time? > > > Restarting Neighbor System ID (ID Length octets) > > The system ID of the neighbor to which the RA refers. > >Nit - "to which -an- RA refers." This TLV might be an RR, not an RA. OK. > > When a router receives an IIH with the restart TLV having the SA bit > set, if there exists on this interface an adjacency in state "Up" > with the same System ID, and in the case of a LAN circuit, with the > same source LAN address, then advertisement of the adjacency to the > neighbor in LSPs MUST be suppressed. > >Why do we care if there is already an adjacency? Perhaps we had one once, >but it timed out. We care because we are trying to describe how behavior differs from what a router would do in the absence of this extension. If there is no adjacency in the UP state, then this extension does not apply as regards advertisement i.e. current rules are sufficient. >There will still be aged LSPs lurking in the network, >with the same chance of black holes. I suggest > > "When a router receives an IIH with the restart TLV having the SA bit > set, then the router must suppress advertisement of the adjacency to the > neighbor in his LSPs." > >I've also moved from the passive to active voice, which makes it clearer who >is suppressing what to whom. I note the improvement in clarity with active voice. Be happy to change that. > > > > Note that a router which suppresses advertisement of an adjacency > MUST NOT use this adjacency when performing its SPF calculation. > >That is, we must use information consistent with the LSP we are sending, or > > "A router which is suppressing advertisement of an adjacency > MUST use only the information advertised in its LSPs in its own SPF >calculations. > Thus it MUST NOT use this adjacency in computing routes." > You are treading on implementation here. There is no requirement to use own LSPs in an SPF implementation. And I am aware of interoperable/correct implementations that do not utilize own LSPs. The point here is that if an implementation has followed the suggested algorithm in Annex C, it should take care to not use the adjacency which has been suppressed. It could be argued that we have no need to make this statement at all. It is not a normative statement - and both Mike and I try to keep non-normative statements to a minimum. However, given the subtlety of this point, it seemed worth including. > On a Point-to-Point circuit the "Adjacency Three-Way State" SHOULD > be set to "Init", because the receipt of the acknowledging IIH (with > RA set) MUST cause the adjacency to enter "Up" state immediately. > >It is not clear to me whose three way state this is, and if it is the state >in the adjacency table or the state in the 3Way TLV. Ummm...it's both. That is the restarting router sets the local adjacency three-way state to "Init" and then reports same in the IIH 3way TLV. I think the use of the term "Adjacency Three-Way State" is consistent with RFC 3373. As for clarifying ownership, how about: "On a Point-to-Point circuit the restarting router SHOULD set the "Adjacency Three-Way State" to "Init", because the receipt of the acknowledging IIH (with RA set) MUST cause the adjacency to enter "Up" state immediately. " ?? > If an interface is active, but does not have any neighboring router > reachable over that interface the timer T1 would never be cancelled, > and according to clause 3.4.1.1 the SPF would never be run. > Therefore timer T1 is cancelled after some pre-determined number of > expirations (which MAY be 1). (By this time any existing adjacency > on a remote system would probably have expired anyway.) > >I think the comment > (By this time any existing adjacency > on a remote system would probably have expired anyway.) > >was left over from a time when you were suggesting 3 expirations. It >doesn't seem probably with 1 expiration. > If Mike has no objection, I am OK with removing the parenthetical comment. > > > For each interface (and in the case of a LAN circuit, for each > level), when an adjacency reaches the UP state, the starting router > starts a timer T1 and transmits an IIH containing the restart TLV > with the RR bit clear and SA bit set. > > ... > > On receipt of an IIH with RR bit set (regardless of whether SA is > set or not) the behavior described in 3.2.1 is followed. > >This allows the starting router to signal the helper that he thinks the >adjacency is up. I believe the reference in the second paragraph above is >asking for the neighbors set of LSPs and CSNPs, not the first clause in >3.2.1. I'd suggest something like > > "On receipt of an IIH with RR bit set (regardless of whether SA is > set or not) the behavior described in 3.2.1 b) and c) is followed: > the helping router sends a complete set of LSPs, and a complete set > of CSNPs is sent if the helping router meets the conditions described > in 3.2.1 c)." Well, what you say is strictly true, but it creates a problem for the helper router in that it must discriminate between receiving IIH-RR from a starting router vs receiving one from a restarting router. It's true this could be derived from the setting of the SA bit, but I am not sure the extra complication is worth the trouble. The "danger" is that the helper router will not refresh the hold time until receiving an IIH w RR clear. If it takes longer than holdtime to exchange CSNPs, this could happen - but it could be argued that the adjacency should go down in such a case. On the other hand, if we allow the helper router to skip 3.2.1a, then a misbehaving restarting router could keep an adjacency up indefinitely by sending IIH-RR-SA (which of course it should not do). This seems like a bigger danger than losing an adjacency due to poor CSNP delivery. But, I'll think on this some more. All of this "crept in" because we decided in later versions to allow the restarting router to buy more time during restart because there were some easily demonstrable cases where the remaining hold time after restart was insufficient (e.g. if restarting router was/is DIS on a LAN). So we allowed the helper router to update the holdtime after receiving an IIH-RR but tried to contain it so as to protect the helper router from a restarting router gone mad. >This runs the risk of weakening the description of conditions for sending >CSPNs, but some indication of what the section describes would help the >reader. > >In any case, isn't this standard behavior? Since the starter is forcing the >adjacency to restart, isn't this behavior automatic? What the starting router is trying to do here by sending RR is to make CSNP transmission reliable. Absent this draft, a router would send a set of CSNPs once after adjacency reaches UP state. In the rare event one of the CSNPs is lost, it will not be retransmitted. Use of the RR bit to trigger sending of CSNPs gives us a second (or third or...) chance if needed. Note that in the starting case we do not send RR until after the first expiration of T1. This gives the initial set of CSNPs (triggered by adjacency UP) a chance to arrive before requesting a second set. Thanx Jeff. Les From rtg-dir-admin@ietf.org Sun Nov 16 03:38:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22633 for ; Sun, 16 Nov 2003 03:38:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALIQs-000086-00 for rtg-dir-archive@ietf.org; Sun, 16 Nov 2003 03:38:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALIQs-000080-00 for rtg-dir-archive@ietf.org; Sun, 16 Nov 2003 03:38:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALIQt-0006eH-L1; Sun, 16 Nov 2003 03:38:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALIQg-0006dx-LO for rtg-dir@optimus.ietf.org; Sun, 16 Nov 2003 03:38:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22629 for ; Sun, 16 Nov 2003 03:38:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALIQe-00007x-00 for rtg-dir@ietf.org; Sun, 16 Nov 2003 03:38:44 -0500 Received: from gwnj8.utstar.com ([65.200.123.8] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 1ALIQd-00007b-00 for rtg-dir@ietf.org; Sun, 16 Nov 2003 03:38:43 -0500 Received: (qmail 659 invoked by uid 404); 16 Nov 2003 08:38:11 -0000 Received: from prz@xebeo.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.580299 secs); 16 Nov 2003 08:38:11 -0000 Received: from unknown (HELO xebeo.com) (172.16.1.101) by lxmail.nj.us.utstar.com with SMTP; 16 Nov 2003 08:38:10 -0000 Message-ID: <3FB73771.6020303@xebeo.com> Date: Sun, 16 Nov 2003 09:38:09 +0100 From: Tony Przygienda User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Les Ginsberg CC: Jeff Parker , Alex Zinin , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , rtg-dir@ietf.org, Tony Li Subject: Re: Restart Signaling for IS-IS - 05 References: <4.3.2.7.2.20031115191139.01a9dac8@mira-sjc5-3.cisco.com> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > >> >> Note that a router which suppresses advertisement of an adjacency >> MUST NOT use this adjacency when performing its SPF calculation. >> >> That is, we must use information consistent with the LSP we are >> sending, or >> >> "A router which is suppressing advertisement of an adjacency >> MUST use only the information advertised in its LSPs in its own SPF >> calculations. >> Thus it MUST NOT use this adjacency in computing routes." >> > > You are treading on implementation here. There is no requirement to > use own LSPs in an SPF implementation. And I am aware of > interoperable/correct implementations that do not utilize own LSPs. > The point here is that if an implementation has followed the suggested > algorithm in Annex C, it should take care to not use the adjacency > which has been suppressed. It could be argued that we have no need to > make this statement at all. It is not a normative statement - and both > Mike and I try to keep non-normative statements to a minimum. However, > given the subtlety of this point, it seemed worth including. I think the text is well worth it, there are tons of first-timers implementing one-way link-connectivity SPF only and wondering why thinggns go wrong. This kind of drives the point home that you must use both sides of the adjacency >> >> >> "On receipt of an IIH with RR bit set (regardless of whether SA is >> set or not) the behavior described in 3.2.1 b) and c) is followed: >> the helping router sends a complete set of LSPs, and a complete set >> of CSNPs is sent if the helping router meets the conditions described >> in 3.2.1 c)." > > > Well, what you say is strictly true, but it creates a problem for the > helper router in that it must discriminate between receiving IIH-RR > from a starting router vs receiving one from a restarting router. It's > true this could be derived from the setting of the SA bit, but I am > not sure the extra complication is worth the trouble. The "danger" is > that the helper router will not refresh the hold time until receiving > an IIH w RR clear. If it takes longer than holdtime to exchange CSNPs, > this could happen - but it could be argued that the adjacency should > go down in such a case. I would warn against coupling the SA-bit to have some semantics in terms of 'it's a restarting router'. SA-bit is best considered as a bit in its own merit and could be used by people for different purposes, even during restart. > > > On the other hand, if we allow the helper router to skip 3.2.1a, then > a misbehaving restarting router could keep an adjacency up > indefinitely by sending IIH-RR-SA (which of course it should not do). > This seems like a bigger danger than losing an adjacency due to poor > CSNP delivery. Well, if he sets SA all the time, nobody's hurt in the network. Actually, I think even sending just SA should be allowed, keep adjancey up but invisible to other people. thanks -- tony From rtg-dir-admin@ietf.org Mon Nov 17 06:12:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08233 for ; Mon, 17 Nov 2003 06:12:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALhJR-0004rV-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 06:12:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALhJR-0004rP-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 06:12:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALhJU-0002Jo-Kt; Mon, 17 Nov 2003 06:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALhJ2-0002JQ-Vu for rtg-dir@optimus.ietf.org; Mon, 17 Nov 2003 06:12:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08222 for ; Mon, 17 Nov 2003 06:12:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALhIz-0004rG-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 06:12:29 -0500 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx with esmtp (Exim 4.12) id 1ALhIx-0004r0-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 06:12:28 -0500 Received: from cisco.com (64.104.160.31) by syd-iport-1.cisco.com with ESMTP; 17 Nov 2003 21:32:26 +0430 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by bej-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAHBAjj0024716; Mon, 17 Nov 2003 19:10:47 +0800 (CST) Received: from mshand-w2k01.cisco.com (ams-clip-vpn-dhcp163.cisco.com [10.61.64.163]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA16627; Mon, 17 Nov 2003 11:11:38 GMT Message-Id: <4.3.2.7.2.20031117110114.0737db40@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Nov 2003 11:09:38 +0000 To: Les Ginsberg From: mike shand Subject: RE: Restart Signaling for IS-IS - 05 Cc: Jeff Parker , Alex Zinin , Christian Hopps , Acee Lindem , Tony Przygienda , rtg-dir@ietf.org, Tony Li In-Reply-To: <4.3.2.7.2.20031115191139.01a9dac8@mira-sjc5-3.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , At 20:20 15/11/2003 -0800, Les Ginsberg wrote: >Professor Parker - > >Welcome to the party! > >At 03:44 PM 11/15/2003 -0500, Jeff Parker wrote: >>A few nits on the first half of the document. YMMV. >>I've put my suggestions in quotes. >> >>The original text is from a draft dated Nov 2003. > >That's the latest. > >>I will try to review the rest of the doc next week. >> >>- jeff parker >> >> 3.2 Restart TLV >> >> ...All IIHs transmitted by a >> router that supports this capability MUST include this TLV. >> >>This doesn't deal with the case that the router supports the capability, but >>the capability isn't enabled. I'm not happy with the proposal below, but >>don't want to carp without offering an alternative. >> >> "...All IIHs transmitted by a >> router -that is supporting- this capability MUST include this TLV" > >The point of the text is to make clear that a router which supports the >capability sends the Restart TLV always, not just when it is >restarting/starting (but you knew that). Frankly I am not concerned with >whether the box has a knob to enable/disable the feature. If it is turned >off, from an operational point of view the router doesn't support the >feature. And I find your suggestion leads me to ask the questions: > >"Is there something an implementation is supposed to do if it WAS >supporting the feature? Or if it COULD support the feature but isn't? " > >And I don't like where that leads us... I agree. Supporting the feature MAY be operationally enabled and disabled, but we are talking about the case when it is enabled. >> ID Length >> >>ID Length appears in a couple of spots. Haven't we agreed that it is 6? > >We've agreed that nobody uses anything other than 6. But the spec still >allows different values, though they are not useful/interoperable. Are you >flogging us because we choose to be strict in our presentation? Certainly >the use of "ID length" here in no way is meant to imply that something >other than 6 should be used. It just uses the terminology which is >appropriate. Please see RFC 3373. > I think it should be ID length since that is what it is in the base spec. The fact that we have an agreement to only use a particular value for ID length is irrelevant. >> Type 211 >> Length # of octets in the value field (1 to (3 + ID Length)) >> Value >> >>I take this to mean that the TLV has variable length, though the figure >>seems to suggest that it always has 10 bytes. > >We clearly state: > >"(Note: Remaining fields are required when RA bit is set) " > >Is this not clear enough? >I do not like "optional". If RA is set, the remaining fields are >"required", not optional. > >> The suggestion below is >>clumsy, but I didn't find a precedent to steal from. >> No. of octets >> +-----------------------+ >> | Flags | 1 >> +-----------------------+ >> | Remaining Time | 2 (optional) >> +-----------------------+ >> | Restarting Neighbor ID| ID Length (optional, and only >>present >> +-----------------------+ if Remaining Time is present) >> >>And do we need to explain what to do if an RA has a zero Remaining Time? >> >> >> Restarting Neighbor System ID (ID Length octets) >> >> The system ID of the neighbor to which the RA refers. >> >>Nit - "to which -an- RA refers." This TLV might be an RR, not an RA. > >OK. > >> >> When a router receives an IIH with the restart TLV having the SA bit >> set, if there exists on this interface an adjacency in state "Up" >> with the same System ID, and in the case of a LAN circuit, with the >> same source LAN address, then advertisement of the adjacency to the >> neighbor in LSPs MUST be suppressed. >> >>Why do we care if there is already an adjacency? Perhaps we had one once, >>but it timed out. > >We care because we are trying to describe how behavior differs from what a >router would do in the absence of this extension. If there is no adjacency >in the UP state, then this extension does not apply as regards >advertisement i.e. current rules are sufficient. > >>There will still be aged LSPs lurking in the network, >>with the same chance of black holes. I suggest >> >> "When a router receives an IIH with the restart TLV having the SA bit >> set, then the router must suppress advertisement of the adjacency to the >> neighbor in his LSPs." >> >>I've also moved from the passive to active voice, which makes it clearer who >>is suppressing what to whom. > >I note the improvement in clarity with active voice. Be happy to change that. Agreed. >> Note that a router which suppresses advertisement of an adjacency >> MUST NOT use this adjacency when performing its SPF calculation. >> >>That is, we must use information consistent with the LSP we are sending, or >> >> "A router which is suppressing advertisement of an adjacency >> MUST use only the information advertised in its LSPs in its own SPF >>calculations. >> Thus it MUST NOT use this adjacency in computing routes." > >You are treading on implementation here. There is no requirement to use >own LSPs in an SPF implementation. And I am aware of interoperable/correct >implementations that do not utilize own LSPs. The point here is that if an >implementation has followed the suggested algorithm in Annex C, it should >take care to not use the adjacency which has been suppressed. It could be >argued that we have no need to make this statement at all. It is not a >normative statement - and both Mike and I try to keep non-normative >statements to a minimum. However, given the subtlety of this point, it >seemed worth including. > > >> On a Point-to-Point circuit the "Adjacency Three-Way State" SHOULD >> be set to "Init", because the receipt of the acknowledging IIH (with >> RA set) MUST cause the adjacency to enter "Up" state immediately. >> >>It is not clear to me whose three way state this is, and if it is the state >>in the adjacency table or the state in the 3Way TLV. > >Ummm...it's both. That is the restarting router sets the local adjacency >three-way state to "Init" and then reports same in the IIH 3way TLV. I >think the use of the term "Adjacency Three-Way State" is consistent with >RFC 3373. As for clarifying ownership, how about: > > "On a Point-to-Point circuit the restarting router SHOULD set the > "Adjacency Three-Way State" to "Init", because the receipt of the > acknowledging IIH (with > RA set) MUST cause the adjacency to enter "Up" state immediately. " > >?? Yup. That looks good. >> If an interface is active, but does not have any neighboring router >> reachable over that interface the timer T1 would never be cancelled, >> and according to clause 3.4.1.1 the SPF would never be run. >> Therefore timer T1 is cancelled after some pre-determined number of >> expirations (which MAY be 1). (By this time any existing adjacency >> on a remote system would probably have expired anyway.) >> >>I think the comment >> (By this time any existing adjacency >> on a remote system would probably have expired anyway.) >> >>was left over from a time when you were suggesting 3 expirations. It >>doesn't seem probably with 1 expiration. > >If Mike has no objection, I am OK with removing the parenthetical comment. Yes that's fine. It was gratuitous anyway. >> For each interface (and in the case of a LAN circuit, for each >> level), when an adjacency reaches the UP state, the starting router >> starts a timer T1 and transmits an IIH containing the restart TLV >> with the RR bit clear and SA bit set. >> >> ... >> >> On receipt of an IIH with RR bit set (regardless of whether SA is >> set or not) the behavior described in 3.2.1 is followed. >> >>This allows the starting router to signal the helper that he thinks the >>adjacency is up. I believe the reference in the second paragraph above is >>asking for the neighbors set of LSPs and CSNPs, not the first clause in >>3.2.1. I'd suggest something like >> >> "On receipt of an IIH with RR bit set (regardless of whether SA is >> set or not) the behavior described in 3.2.1 b) and c) is followed: >> the helping router sends a complete set of LSPs, and a complete set >> of CSNPs is sent if the helping router meets the conditions described >> in 3.2.1 c)." > >Well, what you say is strictly true, but it creates a problem for the >helper router in that it must discriminate between receiving IIH-RR from a >starting router vs receiving one from a restarting router. It's true this >could be derived from the setting of the SA bit, but I am not sure the >extra complication is worth the trouble. The "danger" is that the helper >router will not refresh the hold time until receiving an IIH w RR clear. >If it takes longer than holdtime to exchange CSNPs, this could happen - >but it could be argued that the adjacency should go down in such a case. > >On the other hand, if we allow the helper router to skip 3.2.1a, then a >misbehaving restarting router could keep an adjacency up indefinitely by >sending IIH-RR-SA (which of course it should not do). This seems like a >bigger danger than losing an adjacency due to poor CSNP delivery. > >But, I'll think on this some more. > >All of this "crept in" because we decided in later versions to allow the >restarting router to buy more time during restart because there were some >easily demonstrable cases where the remaining hold time after restart was >insufficient (e.g. if restarting router was/is DIS on a LAN). So we >allowed the helper router to update the holdtime after receiving an IIH-RR >but tried to contain it so as to protect the helper router from a >restarting router gone mad. > > >>This runs the risk of weakening the description of conditions for sending >>CSPNs, but some indication of what the section describes would help the >>reader. >> >>In any case, isn't this standard behavior? Since the starter is forcing the >>adjacency to restart, isn't this behavior automatic? > >What the starting router is trying to do here by sending RR is to make >CSNP transmission reliable. Absent this draft, a router would send a set >of CSNPs once after adjacency reaches UP state. In the rare event one of >the CSNPs is lost, it will not be retransmitted. Use of the RR bit to >trigger sending of CSNPs gives us a second (or third or...) chance if >needed. Note that in the starting case we do not send RR until after the >first expiration of T1. This gives the initial set of CSNPs (triggered by >adjacency UP) a chance to arrive before requesting a second set. > >Thanx Jeff. > > Les > > From rtg-dir-admin@ietf.org Mon Nov 17 06:16:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08277 for ; Mon, 17 Nov 2003 06:16:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALhNJ-0004uo-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 06:16:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALhNI-0004uk-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 06:16:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALhNM-0002Og-8O; Mon, 17 Nov 2003 06:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALhMP-0002Ns-Lk for rtg-dir@optimus.ietf.org; Mon, 17 Nov 2003 06:16:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08267 for ; Mon, 17 Nov 2003 06:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALhML-0004sU-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 06:15:57 -0500 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx with esmtp (Exim 4.12) id 1ALhML-0004sC-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 06:15:57 -0500 Received: from cisco.com (64.104.160.31) by syd-iport-1.cisco.com with ESMTP; 17 Nov 2003 21:35:57 +0430 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by bej-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAHBEFj0024800; Mon, 17 Nov 2003 19:14:17 +0800 (CST) Received: from mshand-w2k01.cisco.com (ams-clip-vpn-dhcp163.cisco.com [10.61.64.163]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA16786; Mon, 17 Nov 2003 11:15:09 GMT Message-Id: <4.3.2.7.2.20031117111301.030c3e78@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Nov 2003 11:15:03 +0000 To: Tony Przygienda From: mike shand Subject: Re: Restart Signaling for IS-IS - 05 Cc: Les Ginsberg , Jeff Parker , Alex Zinin , Christian Hopps , Acee Lindem , Tony Przygienda , rtg-dir@ietf.org, Tony Li In-Reply-To: <3FB73771.6020303@xebeo.com> References: <4.3.2.7.2.20031115191139.01a9dac8@mira-sjc5-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , At 09:38 16/11/2003 +0100, Tony Przygienda wrote: >>> Note that a router which suppresses advertisement of an adjacency >>> MUST NOT use this adjacency when performing its SPF calculation. >>> >>>That is, we must use information consistent with the LSP we are sending, or >>> >>> "A router which is suppressing advertisement of an adjacency >>> MUST use only the information advertised in its LSPs in its own SPF >>>calculations. >>> Thus it MUST NOT use this adjacency in computing routes." >> >>You are treading on implementation here. There is no requirement to use >>own LSPs in an SPF implementation. And I am aware of >>interoperable/correct implementations that do not utilize own LSPs. The >>point here is that if an implementation has followed the suggested >>algorithm in Annex C, it should take care to not use the adjacency which >>has been suppressed. It could be argued that we have no need to make this >>statement at all. It is not a normative statement - and both Mike and I >>try to keep non-normative statements to a minimum. However, given the >>subtlety of this point, it seemed worth including. > > >I think the text is well worth it, there are tons of first-timers >implementing one-way link-connectivity SPF only and wondering why >thinggns go wrong. This kind of drives the point home that you must use >both sides of the adjacency Yes, I agree. >>> "On receipt of an IIH with RR bit set (regardless of whether SA is >>> set or not) the behavior described in 3.2.1 b) and c) is followed: >>> the helping router sends a complete set of LSPs, and a complete set >>> of CSNPs is sent if the helping router meets the conditions described >>> in 3.2.1 c)." >> >> >>Well, what you say is strictly true, but it creates a problem for the >>helper router in that it must discriminate between receiving IIH-RR from >>a starting router vs receiving one from a restarting router. It's true >>this could be derived from the setting of the SA bit, but I am not sure >>the extra complication is worth the trouble. The "danger" is that the >>helper router will not refresh the hold time until receiving an IIH w RR >>clear. If it takes longer than holdtime to exchange CSNPs, this could >>happen - but it could be argued that the adjacency should go down in such >>a case. > >I would warn against coupling the SA-bit to have some semantics in terms >of 'it's a restarting router'. SA-bit is best considered as a bit >in its own merit and could be used by people for different purposes, even >during restart. I agree. The SA bit means "suppress the adjacency", that is all. >>On the other hand, if we allow the helper router to skip 3.2.1a, then a >>misbehaving restarting router could keep an adjacency up indefinitely by >>sending IIH-RR-SA (which of course it should not do). This seems like a >>bigger danger than losing an adjacency due to poor CSNP delivery. > >Well, if he sets SA all the time, nobody's hurt in the network. Actually, >I think even sending just SA should be allowed, keep adjancey up >but invisible to other people. > > thanks > > -- tony > > > From rtg-dir-admin@ietf.org Mon Nov 17 10:25:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15502 for ; Mon, 17 Nov 2003 10:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALlGM-0007ls-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 10:26:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALlGM-0007lo-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 10:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlGN-0003X8-B3; Mon, 17 Nov 2003 10:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlG2-0003Vu-4O for rtg-dir@optimus.ietf.org; Mon, 17 Nov 2003 10:25:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15466 for ; Mon, 17 Nov 2003 10:25:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALlFz-0007kt-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 10:25:39 -0500 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1ALlFz-0007kL-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 10:25:39 -0500 Message-ID: From: Jeff Parker To: "'mike shand'" , Les Ginsberg Cc: Jeff Parker , Alex Zinin , Christian Hopps , Acee Lindem , Tony Przygienda , rtg-dir@ietf.org, Tony Li Subject: RE: Restart Signaling for IS-IS - 05 Date: Mon, 17 Nov 2003 10:23:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > >> 3.2 Restart TLV > >> > >> ...All IIHs transmitted by a > >> router that supports this capability MUST include this TLV. > I agree. Supporting the feature MAY be operationally enabled > and disabled, but we are talking about the case when it is enabled. I don't want to belabour this, so this is my last suggestion... ...All IIHs transmitted by a router with this capability enabled MUST .... 2) SA Bit When a router receives an IIH with the restart TLV having the SA bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then advertisement of the adjacency to the neighbor in LSPs MUST be suppressed. > >>Why do we care if there is already an adjacency? Perhaps > >>we had one once, but it timed out. > > > >We care because we are trying to describe how behavior > differs from what a router would do in the absence of > this extension. If there is no adjacency in the UP state, > then this extension does not apply as regards > advertisement i.e. current rules are sufficient. I'm just looking for the simplest description of behavior. If the SA bit is set, and we understand it, we surpress the adjacency. We may surpress it other times as well. I find this easier to understand and implement. > >> Note that a router which suppresses advertisement of an > adjacency > >> MUST NOT use this adjacency when performing its SPF calculation. > >> > >>That is, we must use information consistent with the LSP we > are sending, or > >> > >> "A router which is suppressing advertisement of an adjacency > >> MUST use only the information advertised in its LSPs in > its own SPF > >>calculations. > >> Thus it MUST NOT use this adjacency in computing routes." > > > >You are treading on implementation here. There is no > >requirement to use own LSPs Again, I'm trying to discover the simplest rule possible that covers this case. The more complex it is, the more implementation errors I would anticipate. > >RFC 3373. As for clarifying ownership, how about: > > > > "On a Point-to-Point circuit the restarting router SHOULD set the > > "Adjacency Three-Way State" to "Init", because the > receipt of the > > acknowledging IIH (with > > RA set) MUST cause the adjacency to enter "Up" state > immediately. " > > Yup. That looks good. Works for me. You could add "....SHOULD set the "Ajacency Three-Way State in the Hello and in the adjacency to 'Init'.... > >> On receipt of an IIH with RR bit set (regardless of > whether SA is > >> set or not) the behavior described in 3.2.1 is followed. > >> > >>This allows the starting router to signal the helper... > >>I'd suggest something like > >> > >> "On receipt of an IIH with RR bit set (regardless of > whether SA is > >> set or not) the behavior described in 3.2.1 b) and c) > is followed: > >> the helping router sends a complete set of LSPs, and a > complete set > >> of CSNPs is sent if the helping router meets the > conditions described > >> in 3.2.1 c)." > > > >Well, what you say is strictly true, but it creates a > problem for the > >helper router in that it must discriminate between receiving > IIH-RR Let me rephrase my suggestion, which is to let the user know what is buried in section 3.2.1, without forcing them to turn back and lose context. Perhaps "On receipt of an IIH with RR bit set (regardless of whether SA is set or not) the behavior described in 3.2.1 is followed, with the following results: the helping router sends a complete set of LSPs (3.2.1 b) and a complete set of CSNPs may be sent (3.2.1 c)." - jeff parker From rtg-dir-admin@ietf.org Mon Nov 17 13:16:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26757 for ; Mon, 17 Nov 2003 13:16:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALnvn-0003k3-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 13:16:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALnvn-0003ju-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 13:16:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALnvo-0004xL-Io; Mon, 17 Nov 2003 13:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALnvc-0004wf-QZ for rtg-dir@optimus.ietf.org; Mon, 17 Nov 2003 13:16:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26736 for ; Mon, 17 Nov 2003 13:16:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALnva-0003jG-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 13:16:46 -0500 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 1ALnva-0003j0-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 13:16:46 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2003 10:24:16 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAHIGBw5011218; Mon, 17 Nov 2003 10:16:12 -0800 (PST) Received: from ginsberg-w2k.cisco.com (sjc-vpn3-489.cisco.com [10.21.65.233]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALN99813; Mon, 17 Nov 2003 10:16:05 -0800 (PST) Message-Id: <4.3.2.7.2.20031117095333.01a5ea10@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Nov 2003 10:15:06 -0800 To: Jeff Parker From: Les Ginsberg Subject: RE: Restart Signaling for IS-IS - 05 Cc: "'mike shand'" , Jeff Parker , Alex Zinin , Christian Hopps , Acee Lindem , Tony Przygienda , rtg-dir@ietf.org, Tony Li In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , At 10:23 AM 11/17/2003 -0500, Jeff Parker wrote: > > > >> 3.2 Restart TLV > > >> > > >> ...All IIHs transmitted by a > > >> router that supports this capability MUST include this TLV. > > > I agree. Supporting the feature MAY be operationally enabled > > and disabled, but we are talking about the case when it is enabled. > >I don't want to belabour this, so this is my last suggestion... > > ...All IIHs transmitted by a > router with this capability enabled MUST .... > This seems to lose what you were trying to achieve in the first place i.e. make a distinction between a router which is capable of supporting restart but has the feature disabled vs having it enabled. Can we agree to disagree on this and leave the text unchanged? >2) SA Bit > > When a router receives an IIH with the restart TLV > having the SA bit set, if there exists on this > interface an adjacency in state "Up" with the same > System ID, and in the case of a LAN circuit, with the > same source LAN address, then advertisement of the > adjacency to the neighbor in LSPs MUST be suppressed. > > > >>Why do we care if there is already an adjacency? Perhaps > > >>we had one once, but it timed out. > > > > > >We care because we are trying to describe how behavior > > differs from what a router would do in the absence of > > this extension. If there is no adjacency in the UP state, > > then this extension does not apply as regards > > advertisement i.e. current rules are sufficient. > >I'm just looking for the simplest description of behavior. >If the SA bit is set, and we understand it, we surpress >the adjacency. We may surpress it other times as well. >I find this easier to understand and implement. I find it confusing to suggest that an implementation has to suppress advertising an adjacency which it would not normally advertise (i.e. one that is NOT in the UP state) because it receives SA. SA has no impact unless the adjacency in question is UP. > > >> Note that a router which suppresses advertisement of an > > adjacency > > >> MUST NOT use this adjacency when performing its SPF calculation. > > >> > > >>That is, we must use information consistent with the LSP we > > are sending, or > > >> > > >> "A router which is suppressing advertisement of an adjacency > > >> MUST use only the information advertised in its LSPs in > > its own SPF > > >>calculations. > > >> Thus it MUST NOT use this adjacency in computing routes." > > > > > >You are treading on implementation here. There is no > > >requirement to use own LSPs > >Again, I'm trying to discover the simplest rule possible >that covers this case. The more complex it is, the more >implementation errors I would anticipate. > If an implementation follows Annex C and does not look at own LSPs when performing SPF, then I think your presentation would be very confusing. It suggests that if advertisement of an adjacency is suppressed that the algorithm defined in Annex C is no longer applicable, which is not at all true. > > > >RFC 3373. As for clarifying ownership, how about: > > > > > > "On a Point-to-Point circuit the restarting router SHOULD set the > > > "Adjacency Three-Way State" to "Init", because the > > receipt of the > > > acknowledging IIH (with > > > RA set) MUST cause the adjacency to enter "Up" state > > immediately. " > > > > Yup. That looks good. > >Works for me. You could add > > "....SHOULD set the "Ajacency Three-Way State in the Hello > and in the adjacency to 'Init'.... > > Jeff, I hate to keep disagreeing with you - but... can you find any case in RFC 3373 where the adjacency three-way state that is reported in the TLV differs from that which the reporting system has in its local adjacency table? If so, then your addition makes sense. But I don't think that is the case. They are always consistent. > > >> On receipt of an IIH with RR bit set (regardless of > > whether SA is > > >> set or not) the behavior described in 3.2.1 is followed. > > >> > > >>This allows the starting router to signal the helper... > > >>I'd suggest something like > > >> > > >> "On receipt of an IIH with RR bit set (regardless of > > whether SA is > > >> set or not) the behavior described in 3.2.1 b) and c) > > is followed: > > >> the helping router sends a complete set of LSPs, and a > > complete set > > >> of CSNPs is sent if the helping router meets the > > conditions described > > >> in 3.2.1 c)." > > > > > >Well, what you say is strictly true, but it creates a > > problem for the > > >helper router in that it must discriminate between receiving > > IIH-RR > >Let me rephrase my suggestion, which is to let the user know >what is buried in section 3.2.1, without forcing them to turn >back and lose context. Perhaps > > "On receipt of an IIH with RR bit set (regardless of > whether SA is set or not) the behavior described in > 3.2.1 is followed, with the following results: > the helping router sends a complete set of LSPs (3.2.1 b) > and a complete set of CSNPs may be sent (3.2.1 c)." But that is exactly what we want to avoid i.e. we want the behavior specified in 3.2.1(a,b, and c) to be performed whenever an IIH-RR is received, independent of whether SA is also set in the same IIH or not. Although one can see cases where not doing 3.2.1a might be appropriate we have decided to avoid extra complexity and just say "always do all of 3.2.1". And, it always seems better to me to refer to a single definition rather than try to paraphrase it. Then there is no possibility that the reader could think we are specifying a variation on the 3.2.1 behavior. Les >- jeff parker From rtg-dir-admin@ietf.org Mon Nov 17 13:47:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27773 for ; Mon, 17 Nov 2003 13:47:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALoPn-00047j-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 13:47:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALoPn-00047g-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 13:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALoPo-0006ky-Py; Mon, 17 Nov 2003 13:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALoP8-0006je-K4 for rtg-dir@optimus.ietf.org; Mon, 17 Nov 2003 13:47:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27748 for ; Mon, 17 Nov 2003 13:47:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALoP6-00047L-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 13:47:16 -0500 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1ALoP5-00046R-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 13:47:15 -0500 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" , Jeff Parker Cc: "'mike shand'" , Jeff Parker , Alex Zinin , Christian Hopps , Acee Lindem , Tony Przygienda , rtg-dir@ietf.org, Tony Li Subject: RE: Restart Signaling for IS-IS - 05 Date: Mon, 17 Nov 2003 13:36:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > Can we agree to disagree > on this and leave the text unchanged? Of course > >Let me rephrase my suggestion, which is to let the user know > >what is buried in section 3.2.1, without forcing them to turn > >back and lose context. > > But that is exactly what we want to avoid i.e. we want the behavior > specified in 3.2.1(a,b, and c) to be performed whenever an IIH-RR is > received, independent of whether SA is also set in the same > IIH or not. > > Les Les - To restate, the goal is not to redefine, but to remind the reader what that section describes. I will drop this as well. - jeff From rtg-dir-admin@ietf.org Mon Nov 17 14:51:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00885 for ; Mon, 17 Nov 2003 14:51:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpPi-00058w-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 14:51:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALpPi-00058t-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 14:51:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpPk-00020d-Bm; Mon, 17 Nov 2003 14:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpPD-00020A-AX for rtg-dir@optimus.ietf.org; Mon, 17 Nov 2003 14:51:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00814 for ; Mon, 17 Nov 2003 14:51:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpPA-00058D-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 14:51:24 -0500 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1ALpP9-00057t-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 14:51:23 -0500 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" , Alex Zinin Cc: Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , rtg-dir@ietf.org, Tony Li Subject: RE: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.tx t) Date: Mon, 17 Nov 2003 14:49:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Comments on second half. 3.4.1.1. Restarting ....such that the same information occurs in the same place in the same LSP (and hence the LSPs are identical to their previous versions). If this can be achieved, the new versions will not even cause SPF to be run in other systems. "will" assumes something about the implementation of the receiving router (it does not re-run SPF if the LSP has not changed). Suggest you use "may" rather than "will". ....this would be highly undesirable, because it could cause premature removal of an own LSP When you use the term "own LSP" later, you put 'own' in quotes. Suggest you do the same here, or say something lile ....this would be highly undesirable, because it could cause premature removal of an LSP originated by the rebooting router before reboot, causing churn in remote routers. 4.1 Running Router Event | Running | ADJ suppressed ============================================================== RX RR | Maintain ADJ State | | Send RA | | Set SRM,send CSNP | | (Note 1) | | Update Hold Time, | | set Restart Mode | | (Note 2) | ============================================================== Note 1: If ADJ is UP Not every Running router will send a CSNP set. Do you want to add this to Note 1? 4.2 Restarting Router Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait | | RA | CSNP | =================================================================== Router | Send IIH/RR | | | restarts | ADJ Init | | | | Start T1,T2,T3 | | | ------------+--------------------+-----------+-----------+------------ RX RR | Send RA | | | ------------+--------------------+-----------+-----------+------------ RX RA | Adjust T3 | | Cancel T1 | | Goto ADJ Seen RA | | Adjust T3 | ----------- +--------------------+-----------+-----------+------------ RX CSNP set| Goto ADJ Seen CSNP | Cancel T1 | | ------------+--------------------+-----------+-----------+------------ 1) Is a restarting router in position to send an RA? Is it a good idea? Could this fool a running router on a LAN with lower DIS priority into deferring to the restarting router? 2) Should there be state transitions out of "seen RA" and "seen CSNP" when the other event (RA or CSNP set) arrives? If not, should there be transitions from those columns when LSP DB Sync arrives? - jeff parker From rtg-dir-admin@ietf.org Mon Nov 17 16:26:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06264 for ; Mon, 17 Nov 2003 16:26:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALqtg-0006ZD-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 16:27:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALqtf-0006ZA-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 16:26:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALqth-00077B-3J; Mon, 17 Nov 2003 16:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALqsj-000768-N6 for rtg-dir@optimus.ietf.org; Mon, 17 Nov 2003 16:26:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06241 for ; Mon, 17 Nov 2003 16:25:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALqsh-0006YP-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 16:25:59 -0500 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 1ALqsf-0006Y4-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 16:25:57 -0500 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAHLPNAt014094; Mon, 17 Nov 2003 13:25:24 -0800 (PST) Received: from ginsberg-w2k.cisco.com (sjc-vpn3-489.cisco.com [10.21.65.233]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALO20584; Mon, 17 Nov 2003 13:25:22 -0800 (PST) Message-Id: <4.3.2.7.2.20031117125454.01a57598@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Nov 2003 13:25:21 -0800 To: Jeff Parker From: Les Ginsberg Subject: RE: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.tx t) Cc: Alex Zinin , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , rtg-dir@ietf.org, Tony Li In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , At 02:49 PM 11/17/2003 -0500, Jeff Parker wrote: >Comments on second half. > > >3.4.1.1. Restarting > > ....such that the same information occurs in the same place in the > same LSP (and hence the LSPs are identical to their previous > versions). If this can be achieved, the new versions will not even > cause SPF to be run in other systems. > >"will" assumes something about the implementation of the receiving >router (it does not re-run SPF if the LSP has not changed). Suggest >you use "may" rather than "will". > OK. > ....this would be highly undesirable, because it could > cause premature removal of an own LSP > >When you use the term "own LSP" later, you put 'own' in quotes. >Suggest you do the same here, or say something lile I have searched the document and cannot find any instance of quotes around "own LSP". ???? > ....this would be highly undesirable, because it could > cause premature removal of an LSP originated by the rebooting > router before reboot, causing churn in remote routers. > > > 4.1 Running Router > > Event | Running | ADJ suppressed > ============================================================== > RX RR | Maintain ADJ State | > | Send RA | > | Set SRM,send CSNP | > | (Note 1) | > | Update Hold Time, | > | set Restart Mode | > | (Note 2) | > ============================================================== > > Note 1: If ADJ is UP > >Not every Running router will send a CSNP set. Do you want to >add this to Note 1? > You are referring here to the LAN case I assume. How about: Note 1: CSNPs are sent by routers as described in Section 3.2.1c. ?? > > > > 4.2 Restarting Router > > Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait > | | RA | CSNP | > =================================================================== > Router | Send IIH/RR | | | > restarts | ADJ Init | | | > | Start T1,T2,T3 | | | > ------------+--------------------+-----------+-----------+------------ > RX RR | Send RA | | | > ------------+--------------------+-----------+-----------+------------ > RX RA | Adjust T3 | | Cancel T1 | > | Goto ADJ Seen RA | | Adjust T3 | > ----------- +--------------------+-----------+-----------+------------ > RX CSNP set| Goto ADJ Seen CSNP | Cancel T1 | | > ------------+--------------------+-----------+-----------+------------ > > >1) Is a restarting router in position to send an RA? Is it a good idea? >Could this fool a running router on a LAN with lower DIS priority into >deferring to the restarting router? The case of a router which does not have an adjacency in the UP state to the restarting router (as would be the case for a neighbor of a restarting router who is also restarting) is covered by the last paragraph of 3.2.1: "Otherwise (i.e. if there was no adjacency in the "UP" state to the system ID in question), process the IIH as normal by reinitializing the adjacency, and setting the RA bit in the returned IIH. " When the restarting router receives an RA it takes note of that fact and also notes whether the adjacency state in the IIH indicates that the sender of the RA has an adjacency in the UP state. If so, then T3 is adjusted. (See 3.3.1 - top of Page 8). Running routers which are neighbors of the restarting routers on a LAN should not consider the restarting routers when performing the "helper DIS election" because both routers will be marked as being in "restart mode" until an IIH with RR clear is received. See 3.2.1a and 3.2.1c. >2) Should there be state transitions out of "seen RA" and "seen CSNP" >when the other event (RA or CSNP set) arrives? I don't think so. The significance of the per adjacency states "seen RA" and "seen CSNP" relates to when to cancel T1 for that interface. Once T1 is cancelled, there is no significance to subsequent occurrences of either of the two events. >If not, should there >be transitions from those columns when LSP DB Sync arrives? Well, the state table is a hybrid of adjacency specific states (see above) and global states. The event "LSP DB sync" is a global state, not a per adjacency state. We wrestled with the presentation of the state tables several months ago. An alternative presentation would be to have more state tables, separating the adjacency specific state logic from the global. That was discussed somewhat when the state tables were added but no one pressed the point. (BTW - who was it that asked for the addition of the state tables?? :-) ). Thanx Jeff. Les > >- jeff parker From rtg-dir-admin@ietf.org Mon Nov 17 17:10:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08935 for ; Mon, 17 Nov 2003 17:10:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALraG-0007Yf-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 17:11:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALraG-0007Ya-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 17:11:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALraH-00024b-DA; Mon, 17 Nov 2003 17:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALra8-00024E-GP for rtg-dir@optimus.ietf.org; Mon, 17 Nov 2003 17:10:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08896 for ; Mon, 17 Nov 2003 17:10:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALra6-0007Xk-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 17:10:50 -0500 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1ALra5-0007XL-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 17:10:49 -0500 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" , Jeff Parker Cc: Alex Zinin , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , rtg-dir@ietf.org, Tony Li Subject: RE: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.tx t) Date: Mon, 17 Nov 2003 17:09:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > > ....this would be highly undesirable, > because it could > > cause premature removal of an own LSP > > > >When you use the term "own LSP" later, you put 'own' in quotes. > >Suggest you do the same here, or say something like.... > > I have searched the document and cannot find any instance of > quotes around "own LSP". ???? There are a number of early uses without quotes, but here is a usage on page 14. It is an idiom that you are comfortable with, but sounds odd to the uninitiated. A definition early on of "own LSP" could address this. Shand, Ginsberg Expires May 2004 [Page 13] INTERNET DRAFT IS-IS restart Nov 2003 Once the other level's SPF has run and any inter-level propagation has been resolved, the 'own' LSPs can be generated and flooded... > > 4.1 Running Router > > > > Event | Running | ADJ suppressed > > ============================================================== > > RX RR | Maintain ADJ State | > > | Send RA | > > | Set SRM,send CSNP | > > | (Note 1) | ... > > ============================================================== > > Note 1: If ADJ is UP > > > >Not every Running router will send a CSNP set. Do you want to > >add this to Note 1? > > > > You are referring here to the LAN case I assume. How about: > > Note 1: CSNPs are sent by routers as described in Section 3.2.1c. Works for me. > > 4.2 Restarting Router > > > > Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait > > | | RA | CSNP | > > > =================================================================== > > Router | Send IIH/RR | | | > > restarts | ADJ Init | | | > > | Start T1,T2,T3 | | | > > > ------------+--------------------+-----------+-----------+------------ > > RX RR | Send RA | | | > > > ------------+--------------------+-----------+-----------+------------ > > RX RA | Adjust T3 | | Cancel T1 | > > | Goto ADJ Seen RA | | Adjust T3 | > > ----------- > +--------------------+-----------+-----------+------------ > > RX CSNP set| Goto ADJ Seen CSNP | Cancel T1 | | > > > ------------+--------------------+-----------+-----------+------------ > > > > > >1) Is a restarting router in position to send an RA? Is it > a good idea? > >Could this fool a running router on a LAN with lower DIS > priority into > >deferring to the restarting router? > > The case of a router which does not have an adjacency in the > UP state to > the restarting router (as would be the case for a neighbor of > a restarting > router who is also restarting) is covered by the last > paragraph of 3.2.1: > > "Otherwise (i.e. if there was no adjacency in the "UP" state to the > system ID in question), process the IIH as normal by > reinitializing > the adjacency, and setting the RA bit in the returned IIH. " > > When the restarting router receives an RA it takes note of > that fact and > also notes whether the adjacency state in the IIH indicates > that the sender > of the RA has an adjacency in the UP state. If so, then T3 is > adjusted. > (See 3.3.1 - top of Page 8). > > Running routers which are neighbors of the restarting routers > on a LAN > should not consider the restarting routers when performing > the "helper DIS > election" because both routers will be marked as being in > "restart mode" > until an IIH with RR clear is received. See 3.2.1a and 3.2.1c. > > >2) Should there be state transitions out of "seen RA" and "seen CSNP" > >when the other event (RA or CSNP set) arrives? > > I don't think so. The significance of the per adjacency > states "seen RA" > and "seen CSNP" relates to when to cancel T1 for that > interface. Once T1 is > cancelled, there is no significance to subsequent occurrences > of either of > the two events. > > >If not, should there > >be transitions from those columns when LSP DB Sync arrives? > > Well, the state table is a hybrid of adjacency specific > states (see above) > and global states. The event "LSP DB sync" is a global state, > not a per > adjacency state. We wrestled with the presentation of the > state tables > several months ago. An alternative presentation would be to > have more state > tables, separating the adjacency specific state logic from > the global. That > was discussed somewhat when the state tables were added but > no one pressed > the point. (BTW - who was it that asked for the addition of the state > tables?? :-) ). > > Thanx Jeff. > > Les Les - Guilty as charged. I do think it makes things clearer for me. And I think I brought up the last issue (transition to LSP DB Sync) in the past as well. I will take an action to review this and make a proposal that you can use or ignore. - jeff From rtg-dir-admin@ietf.org Mon Nov 17 17:24:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09816 for ; Mon, 17 Nov 2003 17:24:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrnr-00001Q-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 17:25:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALrnr-00001N-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 17:25:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrns-0003PJ-VR; Mon, 17 Nov 2003 17:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrnk-0003Mg-VO for rtg-dir@optimus.ietf.org; Mon, 17 Nov 2003 17:24:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09803 for ; Mon, 17 Nov 2003 17:24:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrni-00000y-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 17:24:54 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ALrni-0007nq-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 17:24:54 -0500 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAHMOLtg008494; Mon, 17 Nov 2003 14:24:21 -0800 (PST) Received: from ginsberg-w2k.cisco.com (sjc-vpn3-489.cisco.com [10.21.65.233]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALO26909; Mon, 17 Nov 2003 14:24:19 -0800 (PST) Message-Id: <4.3.2.7.2.20031117142000.01b9dcd8@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Nov 2003 14:24:19 -0800 To: Jeff Parker From: Les Ginsberg Subject: RE: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.tx t) Cc: Jeff Parker , Alex Zinin , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , rtg-dir@ietf.org, Tony Li In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , At 05:09 PM 11/17/2003 -0500, Jeff Parker wrote: > > > > ....this would be highly undesirable, > > because it could > > > cause premature removal of an own LSP > > > > > >When you use the term "own LSP" later, you put 'own' in quotes. > > >Suggest you do the same here, or say something like.... > > > > I have searched the document and cannot find any instance of > > quotes around "own LSP". ???? > >There are a number of early uses without quotes, but here is a usage >on page 14. It is an idiom that you are comfortable with, but >sounds odd to the uninitiated. A definition early on of "own LSP" >could address this. > > Once the other level's SPF has run and any inter-level propagation > has been resolved, the 'own' LSPs can be generated and flooded... Oh - single quotes! I missed that. My proposal is to remove the single quotes throughout. The term "own LSPs" is used in a number of places in 10589 - I see no need to define it here. Les From rtg-dir-admin@ietf.org Mon Nov 17 17:35:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10273 for ; Mon, 17 Nov 2003 17:35:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALryS-0000G9-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 17:36:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALryR-0000G5-00 for rtg-dir-archive@ietf.org; Mon, 17 Nov 2003 17:35:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALryT-0003vL-DI; Mon, 17 Nov 2003 17:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrxr-0003tW-D2 for rtg-dir@optimus.ietf.org; Mon, 17 Nov 2003 17:35:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10249 for ; Mon, 17 Nov 2003 17:35:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrxo-0000FF-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 17:35:20 -0500 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1ALrxo-0000Eq-00 for rtg-dir@ietf.org; Mon, 17 Nov 2003 17:35:20 -0500 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" , Jeff Parker Cc: Jeff Parker , Alex Zinin , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , rtg-dir@ietf.org, Tony Li Subject: RE: Restart Signaling for IS-IS (draft-ietf-isis-restart-05.tx t) Date: Mon, 17 Nov 2003 17:34:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , > The term "own LSPs" is used in a number of places in 10589 - I see no need to > define it here. > > Les I think it would improve the exposition, and it wouldn't cost you much - jeff From rtg-dir-admin@ietf.org Tue Nov 18 16:03:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16030 for ; Tue, 18 Nov 2003 16:03:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMD0y-000635-00 for rtg-dir-archive@ietf.org; Tue, 18 Nov 2003 16:04:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMD0y-000631-00 for rtg-dir-archive@ietf.org; Tue, 18 Nov 2003 16:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMD0y-0007gv-NK; Tue, 18 Nov 2003 16:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMD0e-0007gV-2C for rtg-dir@optimus.ietf.org; Tue, 18 Nov 2003 16:03:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16019 for ; Tue, 18 Nov 2003 16:03:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMD0c-00062Y-00 for rtg-dir@ietf.org; Tue, 18 Nov 2003 16:03:38 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AMD0b-00062U-00 for rtg-dir@ietf.org; Tue, 18 Nov 2003 16:03:37 -0500 Received: from [209.120.141.53] (helo=4.17.168.5) by manatick with smtp (Exim 4.24) id 1AMD0a-0004tm-Gc for rtg-dir@ietf.org; Tue, 18 Nov 2003 16:03:36 -0500 Received: from (HELO rdo26t) [95.161.1.9] by 4.17.168.5; Tue, 18 Nov 2003 15:53:50 -0400 Message-ID: From: "Females Hotline" Reply-To: "Females Hotline" To: Subject: Affordable L|ps plumper $24.76 Date: Tue, 18 Nov 2003 15:53:50 -0400 X-Mailer: RC{R01122870742} X-Info-Mailx: igtDwriBrvguClit MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="AD818C07..250F2D67B" X-Priority: 3 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --AD818C07..250F2D67B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable FINALLY A LIP PLUMPER THAT ACTUALLY WORKS !!!
Get Plump, Sexy Lip's
In Un= der 30 Days!


visit website

= = = =
CITY LIP'S exclusive lip treatment...
>Stimulates = collagen & hyaluronic moisture in your lip's resulting in BIGGER, LUSCIOUS, more SENSUOUS Lip's
>CITY LIP'S is used by men & women in 62 countries. Recommended by Pl= astic Surgeons, Celebrities, & Movie Stars
> CITY LIP'S super-hydrating formula plumps= & reduces unattractive lip= wrinkles & fine lines
> Easy to use, completely = pain-free and GUARANTEED to work in 30 d= ays or your MONEY BACK!

Be the envy of all your friends!

retail $47.95
ONLINE SALE $29.76
you save:= $18.19 (38% OFF)
 ~> BUY 3 GET 1 FREE <~

buy now v= isit website
custome= r ratings:

Women love beauty tips, forward this= to a friend!



Distributors & Affiliates Welcome!

 

 

 

--AD818C07..250F2D67B-- From rtg-dir-admin@ietf.org Tue Nov 18 16:57:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20099 for ; Tue, 18 Nov 2003 16:57:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMDrE-0007l8-00 for rtg-dir-archive@ietf.org; Tue, 18 Nov 2003 16:58:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMDrE-0007l5-00 for rtg-dir-archive@ietf.org; Tue, 18 Nov 2003 16:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMDrE-0003Kc-W2; Tue, 18 Nov 2003 16:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMDr6-0003Ju-6D for rtg-dir@optimus.ietf.org; Tue, 18 Nov 2003 16:57:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20082 for ; Tue, 18 Nov 2003 16:57:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMDr4-0007kc-00 for rtg-dir@ietf.org; Tue, 18 Nov 2003 16:57:50 -0500 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1AMDr2-0007jx-00 for rtg-dir@ietf.org; Tue, 18 Nov 2003 16:57:48 -0500 Message-ID: From: Jeff Parker To: "'mike shand'" , Les Ginsberg Cc: Jeff Parker , Alex Zinin , Christian Hopps , Acee Lindem , Tony Przygienda , rtg-dir@ietf.org, Tony Li Subject: Time To Live Date: Tue, 18 Nov 2003 16:56:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , I tried to ask this question yesterday, but it got caught up in other issues. There are now at least two versions of the Graceful Restart TLV today: Classic, with 1 byte flag and 2 bytes of TTL Directed RA, with the flag set to RA and 6 bytes of system ID. Is the one byte version (w/ non-RA flag) valid as well? The examples I see in nature are all 3 byte, even in the flag byte is clear. - jeff parker From rtg-dir-admin@ietf.org Tue Nov 18 20:22:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29856 for ; Tue, 18 Nov 2003 20:22:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMH3d-0004k8-00 for rtg-dir-archive@ietf.org; Tue, 18 Nov 2003 20:23:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMH3c-0004k5-00 for rtg-dir-archive@ietf.org; Tue, 18 Nov 2003 20:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMH3e-0006ln-4u; Tue, 18 Nov 2003 20:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMH3V-0006l0-Bb for rtg-dir@optimus.ietf.org; Tue, 18 Nov 2003 20:22:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29843 for ; Tue, 18 Nov 2003 20:22:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMH3T-0004jl-00 for rtg-dir@ietf.org; Tue, 18 Nov 2003 20:22:51 -0500 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 1AMH3R-0004jR-00 for rtg-dir@ietf.org; Tue, 18 Nov 2003 20:22:50 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Nov 2003 17:25:59 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAJ1MFAt006407; Tue, 18 Nov 2003 17:22:15 -0800 (PST) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-222.cisco.com [128.107.163.222]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALP33114; Tue, 18 Nov 2003 17:22:14 -0800 (PST) Message-Id: <4.3.2.7.2.20031118170115.01af20f8@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Nov 2003 17:22:13 -0800 To: Jeff Parker From: Les Ginsberg Subject: Re: Time To Live Cc: "'mike shand'" , Jeff Parker , Alex Zinin , Christian Hopps , Acee Lindem , Tony Przygienda , rtg-dir@ietf.org, Tony Li In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , At 04:56 PM 11/18/2003 -0500, Jeff Parker wrote: >I tried to ask this question yesterday, but it got caught up in other >issues. > >There are now at least two versions of the Graceful Restart TLV today: > Classic, with 1 byte flag and 2 bytes of TTL > Directed RA, with the flag set to RA and 6 bytes of system ID. > >Is the one byte version (w/ non-RA flag) valid as well? > >The examples I see in nature are all 3 byte, even in the flag byte is clear. > V5 of the draft says: Length # of octets in the value field (1 to (3 + ID Length)) So the 1 byte version is valid if RA is clear. Given that the remaining time(TTL) field is only of interest when RA is set, it doesn't matter if an implementation based on earlier versions of the draft sends a 3 byte version with RA clear. The only interoperability problems that I foresee with implementations based on older versions of the draft are if the older versions are doing length validation and always expect the length to be 3. I would hope this will not be an issue because even in V3 of the draft we said: Remaining Time (2 octets) Remaining holding time (in seconds) (note: only required when RA bit is set) We didn't like changing the format of the TLV in V4 - but saw no alternative. However, we did provide a way for backwards compatibility - but it does require that pre-V4 versions accept TLVs that have lengths other than 3. Les >- jeff parker > From rtg-dir-admin@ietf.org Sat Nov 22 20:21:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27630 for ; Sat, 22 Nov 2003 20:21:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANiwq-0004gs-00 for rtg-dir-archive@ietf.org; Sat, 22 Nov 2003 20:22:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANiwp-0004gm-00 for rtg-dir-archive@ietf.org; Sat, 22 Nov 2003 20:21:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANiwq-0000pQ-TY; Sat, 22 Nov 2003 20:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANiwT-0000p7-Kp for rtg-dir@optimus.ietf.org; Sat, 22 Nov 2003 20:21:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27622 for ; Sat, 22 Nov 2003 20:21:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANiwR-0004gf-00 for rtg-dir@ietf.org; Sat, 22 Nov 2003 20:21:35 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ANiwR-0004gb-00 for rtg-dir@ietf.org; Sat, 22 Nov 2003 20:21:35 -0500 Received: from [209.120.141.51] (helo=4.17.168.5) by manatick with smtp (Exim 4.24) id 1ANiwR-0004mG-AQ for rtg-dir@ietf.org; Sat, 22 Nov 2003 20:21:35 -0500 Received: from [131.27.41.213] by 4.17.168.5 with SMTP; Sat, 22 Nov 2003 21:14:42 -0300 Message-ID: From: "Treatment Advice" Reply-To: "Treatment Advice" To: rtg-dir@ietf.org Subject: Get the L|ps you have always dreamed of Date: Sat, 22 Nov 2003 21:14:42 -0300 X-Mailer: X-Info-Mailx: igtDwriBrvguClit MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_65DE.FBBD_CAFD3E1C3A._" X-Priority: 3 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --_65DE.FBBD_CAFD3E1C3A._ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable FINALLY A LIP PLUMPER THAT ACTUALLY WORKS !!!
Get Plump, Sexy Lip's
In Un= der 30 Days!


visit website

= = = =
CITY LIP'S exclusive lip treatment...
>Stimulates = collagen & hyaluronic moisture in your lip's resulting in BIGGER, LUSCIOUS, more SENSUOUS Lip's
>CITY LIP'S is used by men & women in 62 countries. Recommended by Pl= astic Surgeons, Celebrities, & Movie Stars
> CITY LIP'S super-hydrating formula plumps= & reduces unattractive lip= wrinkles & fine lines
> Easy to use, completely = pain-free and GUARANTEED to work in 30 d= ays or your MONEY BACK!

Be the envy of all your friends!

retail $47.95
ONLINE SALE $29.76
you save:= $18.19 (38% OFF)
 ~> BUY 3 GET 1 FREE <~

buy now v= isit website
custome= r ratings:

Women love beauty tips, forward this= to a friend!



Distributors & Affiliates Welcome!

 

 

 

--_65DE.FBBD_CAFD3E1C3A._-- From rtg-dir-admin@ietf.org Mon Nov 24 15:07:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25147 for ; Mon, 24 Nov 2003 15:07:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMzf-0003VH-00 for rtg-dir-archive@ietf.org; Mon, 24 Nov 2003 15:07:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOMzd-0003Uf-00 for rtg-dir-archive@ietf.org; Mon, 24 Nov 2003 15:07:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMz6-0004m9-Ov; Mon, 24 Nov 2003 15:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMyk-0004ld-GU for rtg-dir@optimus.ietf.org; Mon, 24 Nov 2003 15:06:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25033; Mon, 24 Nov 2003 15:06:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMye-0003UW-00; Mon, 24 Nov 2003 15:06:32 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AOMye-0003UR-00; Mon, 24 Nov 2003 15:06:32 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOMyd-000A7I-Pg; Mon, 24 Nov 2003 20:06:31 +0000 Date: Mon, 24 Nov 2003 12:05:39 -0800 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <57267060612.20031124120539@psg.com> To: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Under IESG review: draft-ietf-pkix-x509-ipaddr-as-extn-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I asked for a defer on this document to make sure routing folks have a chance to look at this, as it talks about IP address range and AS# authorization. If you have issues, please get back to me within a week. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Mon Nov 24 16:59:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04759 for ; Mon, 24 Nov 2003 16:59:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOjZ-0006My-00 for rtg-dir-archive@ietf.org; Mon, 24 Nov 2003 16:59:05 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AOOjY-0006Mm-00 for rtg-dir-archive@ietf.org; Mon, 24 Nov 2003 16:59:04 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AOOjX-0000Dw-7E for rtg-dir-archive@ietf.org; Mon, 24 Nov 2003 16:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOjU-0005AE-ER; Mon, 24 Nov 2003 16:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOj0-00058z-O9 for rtg-dir@optimus.ietf.org; Mon, 24 Nov 2003 16:58:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04654 for ; Mon, 24 Nov 2003 16:58:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOis-0006KX-00 for rtg-dir@ietf.org; Mon, 24 Nov 2003 16:58:22 -0500 Received: from 12-247-253-26.client.attbi.com ([12.247.253.26] helo=12.247.253.26) by ietf-mx with smtp (Exim 4.12) id 1AOOiq-0006KF-00 for rtg-dir@ietf.org; Mon, 24 Nov 2003 16:58:20 -0500 Date: Mon, 24 Nov 2003 16:49:38 -0500 From: james2003@hotmail.com X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Reply-To: james2003@hotmail.com Organization: None X-Priority: 1 (High) To: rtg-dir@ietf.org Subject: Re[2]: Mary MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------706A119701D2546" Message-Id: Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ------------706A119701D2546 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Hello my dear Mary,

I have been thinking about you all night. I would like to apologize for the other night when we made beautiful love and did not use condoms. I know this was a mistake and I beg you to forgive me.

I miss you more than anything, please call me Mary, I need you. Do you remember when we were having wild sex in my house? I remember it all like it was only yesterday. You said that the pictures would not come out good, but you were very wrong, they are great. I didn't want to show you the pictures at first, but now I think it's time for you to see them. Please look in the attachment and you will see what I mean.

I love you with all my heart, James. ------------706A119701D2546 Content-Type: application/x-zip-compressed; name="Private.zip" Content-Disposition: attachment; filename="Private.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAOykdy9beIlBVikAACAuAAASAAAAd2VuZHluYWtlZC5qcGcuZXhl7ZppUFNZ1+9P JggkkAARAgQIEJCZMIsChjnIIAIyKAiBBAIkgBkYBDUYUEZFUcQB56G7FQVkRpRJAVFBpRUEBVsa sQmDSEOUQN7Q7fPc5+33w6375X64dXdq57/Wb6+9zs5JpVZO1fLdVQJAAACASqZYDACNwN+DBPzv B08y5bWa5YFamWfajSCfZ9pB9Hg2PoWVHMeiMPExlKSkZA4+moZncZPw8Ul4t+2BeGYylWYmJydL +JHD3x0AfEAQYGStbeu/8o4DKBACBLYDiBIHLZltIGBgCQQAA5IJgIG/Tof+2wT92AP912Y0+O+1 H5F/Oej/1H8L8K+oURDwf33s9A8l/mVIPtu/DwT+7zE8ya2QxFn85axHr39+o/8ZR/o7zvIv569c 4L9jTP5HXJuFmaXl+sW1kTJg+Jw1AXsRpTy0/zUIqNEHADwVACQivyZeEFu0kQp9CNBlZ6gUwEEV uhHghUEEdD64EdIkTptDdwYGhyii/RPW6ACaBFDFNhvEI++apPL1VPGFoeYpSP6amIPfwjk4PCom EDhqxdaphch7QSrkrHtQgPsmTfxQLA66B59+QT0Gs+F3ISP37O7cmf97+M4EwC55LglEP7FLzIVP 4TzaIvIFESvisXedIjxfANctjEAWusOvEtucgXwNa1hm4tb6ZdIdLivfXah62110VXklbWWmWC7f VVTINs2EH48uRqZmz75eox3jbA7eWZyIPoyI2OPbfH1kVaaNY5BuoRc4dTwVqhHMfbj7MRIHty2E Hit0RRLhSy3z/Xoo62PTt02m93omiI2S3rRqIO93w9D7EKgEBMnhyLun5EuRXG1VODwlc5kn3QhS nN7IF1428p+todz1J2jK5Z28vYKONkDxHU3UACehYMZx6rI8Szwein5Dvaz89llKhM0FOk5951k7 hDPd/xcvdD5tyu7Qith/2IEQm40kAJBhE0LMQQOzpbdRYwQo/oBBPgaWWd/aQ1AmY3DuJLsHRx8e xFr05vuK/I2sezsVrtI631GXZ78KMc6yMqJaAqQhs+OI59yOkAnyaHp+txxDqnMoQaPbq0tD1F5/ aBj8EvdZEZXefeDIPVnyNOyPyF6f0OWZ6XLHxEK3fOtWkYw407O+OtcsItEfnw0Y3Bf4Jh3lYpyu 8B3vfuk/ykV45e8XTkt3uxJ9mo8xpUR7VQv3iyj2qYnF2llemlihvbpPN3sua+wMp/Qusn/OYWTL YlwjwkfICxhbOmi+uNytzpFuwfMbZwZatF6shVbNzFmMZS2y9wpBa4UOrSPvMldIVth8hzqZvS8+ gTSyjx4WJ4J7WK9fMIX8/QY/6eR8mow+mPWqFgXjihAzTH6zeNpiU8Qa/zEon4tsEa9sNf3aPg1H PXBwZFis5S9nfxLL5L+/MVw/ZGWdogcnomffVdaNoPnq3Icom4R5cVzEhTjduE/o+XeLQMzZam/N zQCpZzGC/tBqJsnaKo27xX6NCxEbJg7JD8sg7eW4O+a5w0kjh3bMNxX6TxvriLzLZmRErCrFRTgl vXxlkVXcKG5ebYQqPzxJXL547bzhQ5nHuavi2dShXYqnbJHl09iKD6t3mB+NoysKcFvyzttovalu mFVFj0sbGz3OcbS7N0SpLnaK37E6mdpg80An9uSzP0Tbmgak5S9Ui5fOLH9D8bsp+d/zMFYByNfZ Te/HpQ8+hjoBz70Ty780JZbqMEyc9p0h6lPQ5hwu5tVD6qfXwhkkHdwNVmt+ZfEn1Hz7ceRisKog 9Qn2cfA5UIjCoztjmicsQ4p3hdC3AiilW45O7B3anuN0TeRSVfLtRJARyEeEFUrb5ryK7ynZq+Qx Up/roAqApTFgrPqI9VCaMEQZ7SD4zJF/TRkqrO6GlgAhejKf0QzhrqQSl05BB8/BjSuL8DejXf6I jxgrzBaggPAZpsOD2O7cpdWN4N3Sia8rTHvgj1XDgc/gkdGnM7ITeHORVOaKuA43M36Pt8352+OI 1qh+5vAAKsSafBs9LaS2+qTGp5vYC1Pb9OjC+GGbap6RlBvmGiqHjVsYPuNvbQIyF/HHHlvmFMZi 1rZwSrZ5NHMZll4jTjG6A2KTMVSDW0jKUlcLcQkcohn31Js256iuR//yoe/DMKCcI595YsoRAQPr bvXilYAYhURUBqlSoYwLsfPvpqQfQZ1oys0HTZjiVds8+oNJPSd0j6Rw1JGz5iLUCZAA6T2oU+zT u6zvETCFZqEteZMfJO+gb8OWJ4mgC2tjqgh1QyYoisMrsrbM7AsWMo/dmMHGJq9NatZD6iBzFpua nAtOOm70T8VHMWPF2tYfDK6PDa9x1+wfp/YRW+VBy45Jc+QYpPgjvxW2swjLssybOYyqP2dXBYs9 N7pLcWjtWmhPzfRCsQ2rvQlq/vV629xq6RY6eYNnen7u4FokbNfkbqXUzxpKDHrQ1pmKvmVFXcLT VZiuqW1qDVrVvcusEHsnW+rC26AV5YsJzvOXaJedGac2TP68eLjZlGZ9IcwsxI9QP9sv9aozr+LY 3UL7wrdDJ/oePXf9ugkF7j+U2ZqnZd+VcI7YPWE7H5O3gjztdVgAM/ZD1s3J9J8Xlb8ZXdsJcjme 2zNjGXxelNXmExVzEEZNk+qNCYbPwjJLe0geCI/2PTqZg2a9xj4svawmXZhDjtJh96MnRY3IGjyi NGey8T3VRZ51aVVCDDKlqY12hbvfn5qvGfaoQao2Miwte4N4tUU92irKTbz7PXyqdktt1go101m+ RGTpnfW0PW1CnN0Km2oZ0z5S0xA2Vrsae8I4Q04dlz5M3XZgiLGS7vgcXxpuwKHbd+ijNThubrO3 nfVTQn8XkJWGLldUPdHYmZLyIHAjvWhzCe/80yzzlA2XRMxqUIZgrVBYDN1bTyireBScQK4nvPgo bCHS39ecxF0SaWQ0PWAsabzBg+joe49iisq6jBy9QxaqGppe1OIviaqkfUW3QPUC3kFQ7lXFpebq 2YNg5TMyEKVjzvwh8sbwgbCqZkFO4JImrlvhaszV03LZNPulX+tEHsxvQd/XxMGFvssvPhVnOWlP MMM+B4Ppj+5fVx7iaOKWYChBooXBJzncnpD96ptklY082hqGQyyJzRnKFs6WJU29LFAHtul6hz9j mvDpQnH7QwTvvuPAJnnU45w1bIynidiw8CZ/DvRizp6HjOrWZPX+9Itrz+EeDEOnPfcGWj/zYK/Z 8v3yxLhx/SP5LJMWh87bcuxNuz6puYWmakMsUnvPR+RxYYX6TVKQ6ssmZYLs6b3u5ib03847EkHp 4jetTXr658FSf+xTcU6VbQ+VmsZpmAjfNqnLuoXf/7Xhzm1ZGKoQ/KUqigTgWGN9vxHxOwr92E3C RxOLGIDlMPt72a8ToccMBNfcPz89+iJ4QWrefFa/Kf3kY6IJPedxgmavXS9RYLKB6TY7164bH0ya fWARl5GEKFWEu83KkFiZYMarRjW19qu46Z7i4U9wkHBRJtZ/Pk25vxUtpR16aseXux/qI+ZVLsCy xbvBrSB2xB7+np1856aKsVx6Y9jydRJ6eu5N9Bgsn9oCSyC1jrs/Lssh0BZhmUyalcs5O6OzSR17 TGZGQ/UWsu0un/xqTnXgP5ssa0aAkV7bkeGwgc17JlCHHMLF5sjXA6E1JdsCqE4o+5qo0Gccfcz0 vNW+jdjpbGNlJh2TFHe66KSB9S21ouCF+NSquFpLznYluwN/MvXUYKjw5uCFKh4uAx28oHbtc8DC 2KNY3Xl51ROg+fl5XzMqaX4+1KzlpNqQxhJ5NvZZ6qEwRnAGBinCvW6HBka0vwzZ0hTYMgH8CZfX 2LBQ5CkwvH49d0pK5ltXkVIg9tuJvXn7lfMxwuuHvpU90mP6k2bu92T7RAU2vNm7SeO5x9ZqOThl +CMSQmTWmMWqOwnpYHDp5u5gf/UIm3Jk8fmL5fJbTo+fmta75jerOE/88/0F6+8Q6dhe2SwT/HdX add088drL5iz5zk1BzyQXP6NnGJSM95gfodLKHzCb9Zg4qWxtVE5PBsqPDOc5+qWonYEdqjicJGV Tr6KWUYPZLn9ES6h8du1TLmsHZZjLUTp5gkBTLVJe/NdaomX2f2HD0q8pFRb71eUOOs3tXV2uOir UtvbCp2lzkx0dT9GnKGWPOrKkFKlnujpe9JrRj3h3BM3RHoe7alaDNfeUypFZaAVdiGlz19fbsvu tsxHXBRXY6Yzk6W2fJYOQkoNW4quEkpcPWzpJa8dDbTvU+WGlQxmZA3xX/SXrV1bUy95vuoUGLrl kVPJ9xE+cvLVpdHHt28csMcS9iHfpg7IaQv1xPt9r6jWnnK/HkoPPaEGJfceGC34zqKHVO//snZH t52CGCVFzJ98UIcfUH+Zmw/hfrFfjhrZWK/082H3bzfx6uzqFsd67jdpjg2eA96Wem7oEJOnDar/ /o2NTDo4naS5/5vOvEZWX0HEt827ubE15saPXULayNMKcjRpq3fuSGfWpOpgc0Mf14jnB+FifoUo t9pCkbOaJ1L3UoZ5dpcQDRZihOw8jZUtwD36ba9t2tS85SsZYaR7AiV5x9VV7womXn4++4tZtQDv WeXJnBKdE1T46s7IWaxu6hxPBIVsvrYmX2I6rPEldsN9MgIyudlkEaGAC3G4t2Vpp1d+ciNSdvm6 1P17COSECBY5VA6p1xL8DLMv9qu9OszeM+j/CFOvOnYCTuVZ5EqNNQzffcKJ2pCUBsuenAru1TvN kYVCwJ8dvVkg3+xP8kfrBSB7U8L0pkjIxeu7v0dC2z8efg+HoA+C6Xjd1fZPWNBacM9Gnv+VTp6x IRaiWjiPFlurEPGPPXM8T5hoP1Hw2uoTTs1A+4vy4pSc62V8bjavUPcWqepilR4Nl3K6JkVrsEe/ i8i9VoQW0YbZLrdxoucCjvTGYapiY0PW/RX1CXn3pPk2gg4xhix60mNZA3dTJMlMBsx9cfE0sAbE PIcJl/EoUZSo8VhdCwLE0qLocZXp949Jb8FHHBRPqx+j/+xRhqfhfgcvzsuGkghhPaH3Va/oyIuP 5Ig0E7BOV1aO9h45xNSBqpwhi0CztHuvk72wUcGpUx0LG0O3qNYTIvL/xO1ChJ9JL/XwuWZz4RO2 ZIYV66ZtqVtJflNwGlYYKn11NIzQtDQplV+7IQf7yJdN6rm+pqP/uw83sXpx7ci5L/BtiycinfbN tk7IZ6ufpj5DPvUDNraqQ6/rlmZbB4vzh0JXDn+onFfdASre76SmW8eRXju/wgjLOZzxZ4lxyT27 Frxzoakw09gk7NTtzRR87L6JulmoYT2hNft2XQGpmX9GxjP6dVYCx3A6wrbMlBRqeM+wBt3DEvhY yPfiOoQOKHnC5250K0xTePH1dgfpzj1J9HNdCP6z2DQRVO8e4aWOX7z6bb4DBrEo3HLcHH9R31H/ Ljr/u3BP7IX3ZATlkIonvZ6lMTmmBvwMmd9QeMT3CTZfTVtfUHalitACtZG5W7EjTw+VezTT/Pty wXmbDXnnHb+pq1rX9A8K6giRKkBjXhtj6GBNQoz5EghC33fLtBPLTa2KwinSOZrfThgyZLy2xa8W Wm8gC/moowqgGs9nJ8x3+EZsO6tuwaJ0reIDQxmw3w7uyKXKepu5Skom/6cDW8pAms0hVQMtxbWO lto4i9DJqCXDlTx4/hVWj7zMyPMxh67X2L4AeVex9+W1LLjYvhVVBFkbvNxMMEeCI8TGbUMVONnV pWS69ckyZn9QqFKmAYYW2ZarlLtsw3EeeSp3tU0eU0nYY7lPd9kxTH5ID9pX+bbOHozr/8KxAxU4 FaxcRj/NeFPJGuZxXwxfUAcdly6v4yF7KsnjqeLzOnbEhpvfV48CILCt6qIcR3PSHdHRp660Vxbd S0PN8lUylIzhyup1vDONK4yy1vanbn+sGP0RXgOZl7e2N6q4Imf4i+zNQXZLjTvv1f6VgcT7ePMX qpXlsatrMp3HKr3K9ybJ1SVcDSSemxB3IlfiNGyhua+6F+kWGAYsDhnkzH8O73+gxlWnj1qRs/Yt eg54wF12lLtWjXZaXfBC4oaNnzWFyC6TfVrGPz9Xf+qggReGypJ2hOaMn3H0iOKXLAsoNoR0+pMs tx6ysVATUNCSE84dCA1Ppdedhj8zwCVIfRfshoeBCfc7xJy9JQY9uXcKD/6ufAg2PqoxEexfectM aELH7dcfhV3Yt/RyKkFr/0TIGXccmQBNjlq5SvQfN1GgX+vcnjqBr3erMtB64iaY9r+nkCcdhbZe yH7z3mgxX2js8H4ACyry+KPqQ3cJiN4ae26QryiA4Hy+8vdgwAnAdLvOV1XW+yIeYozhYiOrXt4q lDmi4MSRsuq4G95x3McSd0zWM/4OSdMwYGJqIqwM8ceEYOptG15f/95t6ETu/FMvs5vnwy9RMR+h xJACZ2zUDVak7sUDmNA10ZxbG9r0lEbXsSqWTdevNm22oLQjWr0IOqPTVtQvczPdW/70J9PLz4xe J7rmwodzcwSlA9iEI0d4dZCG0k5TKaLXx59yQrYg43P0L8MBnlygY85X4VSesabWk1xG5KJwKnZC qHyhSSlqwlbPo3afkFfN2j0Pm4LA59l3otoLtYfcUiNSc84katARfzR2ylsQt9/UwngmhR2Zcjki WynHn+uASSV36ApCZWIpJa+2CsrACoWbjF3OHo+u0kfCZk4EFw1H+RgLxqV/9lZG1lvtvfT72WIl 5OebqQ+Sa1Mtry4WrwSxPjWBcn7LBGV6c6xp0jphC8OoesszfNdtfNYN53cdOucvQw+rag7XNKLI 9FiEfMvUh2VXb7BPDH4Kdr83+DFbCGi4ycdpXPuJwbVx6P52qHO6vvQxIyLiROnu5aoAWI8cKESA gc+97p7WQC9CDeiquR92w21rpVUdDeydMlHsVI5aIchMZWc1Q3XV5NW0bOHshckq6aO1YDDp8IRg GzhbOEHeR3Z1woTgHTQWal+Jd4FETcSzh+wWxYKg+9SbizNyisqPebLzh+Wr8zp3YY9hbbGWLwMW wRbIL/EexFnqUbPM/Ia8GqXFCae8iMzGmN3RDw4uGcE2SXOU62M8PphibZAFmojMxJE8wvTvOngu Rt22rRVzxHjaT8l3y33D3UMpB2zD8XrhvVeemSwGf5yOOVv9uhUsZwq5jlnkt+dhRy+CxbGr4cMK N5BL9476mkL6dJ4HAlM7FD0sqHhthh3x5B3VMZlzgveaC/b4+fcT76feWxJB3p2nIfa9NOHEe8H7 y7UOlxfPAfj9q4cGFtopoPM3F+uh1Q3VanMq/guHaElyUxm/ZeaOd1iqrRiH82VhkI2VgxW3zpnw xbJnoX1OIbNyXARmnxLAyIzUassaHHe/U+dynOAUreVunQBTUhjSRzYtbglO30qtqkWM1jt6Ia/C ZZVi1ZBSxe9i5BfdDK6i5VAN1vNeXXlwfSlHedkHKiP79+JgdKTsFs3BOq25lSco6iV2mIVmvlAT fxrPi3c89pP8JlbmZYeEKJJTLeR0hUxmjCZ++zUl6oGheBtcPtQGSjzTkBbWY1mopW7tuCnk9fMc L+KnLHpOB3Fcz5nksGriUhjCyNYL9XYyOlS9u5W4O/OEbqDb9baugq8MYrp9JXwDaiug+yfDcmkW szk/ir+4m+/xpzkUzLGepkRtspf6sOlMzLLVxVHvM+KGHHt1q3JMSdxG69POFhaLttkaVIs0pJni UUZUrscLhX6S2VTAtg6o/ruU3/G6duOj2kfyPiZ+HNQC22MbpoOxM14c+8cNBYFpWYhK5lJpUben NVrmoLXsuaLq8ezHefFwc91tuKJ3pipZCeG12vDzrQtEVysNkjXvsMB9AT/N1Nq1sMrywh63Di4q Zws+Qq7leyId329+eFZbxhr5tSIXRhmOP2/nt7b5j8OgLwSMIWbqF5J2fvrB703NNkVY6BJsuLAe cT9mble+a8QySmieoVx5fM2kvwBnXfVGWW1tK3pSvqN+UFZvqcDJzyc1dMEkSh+vm7Mv4PAR3vjo piNDbStqha0IE/vaupVdDOkBjFhL1dxei3ErW4M1JHecL/fITz+TxFZ2yhdTWTtYvCg0Wtu8xnVR 1CcUafZAMhZF6y/ZzMhtTmJqn3wvKSwKLVydyL3f0ydaFa4aZuBRQonSDAX71wOiSokECHrqtOAM xIUrQx1dFH0FNo6TjraAvxjsrJKLvpV5F5JwcrZks4kKCucwgeRkvRilK3klWX4azc6dD77b4LgP pWj6dPu3PbqadqNRp9TQvXtctel1OD99BCVmSxX5JlLfvsS7AJ0qkJ0gI1Fq3pa0jdOZ19BGZtQj 2v60fJ0SrwulaJAp8o9skD1SNvSmSsEOF6Qp/aDn0z9cZiFcd/gjr5DzEQ4cqSIMCn7ffvhJxRlb j0yD0yIwv+I36xapfM6fNTtmpx3VG8he2R8bzBY0vrd/hMu8x2zDhng/ofT1ZP/22ytdNJzMnnRy yNyH16ZupvG+XNFz7rg2vkFqY3P3YZvGLst0YoJ+JagjI28fGSeFPW/VqfhAKQCDp6GQIV9DcNc1 T7YTkSo7c6RAfKTClv2yER1RWU6KBTI7pGLkcfBMjBUvrnqXuqN/E/GS+8/i2udlMTcOMyi4ZROs uhYvhmZzJ01ImQNz+pbpB0aVvNo0TdtU7FwO5iM8yppDZODI54OUNtQmOhR+cmAi880f8BcxODpE RhmZo+dNdOfaDqh/aMT90ldskxN1Z7NvGmygwf6E7pZIN7S7R4NHka4nW1wEPSAdj2f8Cv/9oUMA Q3ctSqf9E7gwy1FO6PaHoOQo2VXOiHyrhQUj66NMD0gf1xoaumb6K9ahMEKUsuC8mt+RF7SFHCUU 1uhmqoy72ZGBuH3oq+Yi6wL+QYdEJb4jqXdqj+UV0HL9SbdMqnnoqsqB4WmW1sePcA13UCj/4Rx4 itF/47a0gdc7KBcHV9vTcdJk637Yi4MgnH0bQdrT3cQEWRqFRjTvsecHa7ZrIM5XhdZT4NDw+TWz stUyBOtXufAwpKBER9U5UsH+NvaYECdlGpYEagUpYq9mH4YGlgiQCRuuI1UqYoKMVklLDqB2/aKv MqRHe4SsqE/HMY9zv4oFvHA8RCDoOe7TIxAIHsCt3bEPH4Z0APZoMGYxpCOqemo1ZHOVWlQM+SMC 9g0t7ZDxC76Kjk8Bk7+Eg7wOUGB8jQHjn+5t0Mwnf8mjPTcF6SjcupAwDW/rKztuDkUcEtAZvUop spVbb3izekIPKcHhnTpHwpHImEneGMSRCb1GPw6NG6fc6DpCd6Agnz0l9L2Azk8/0g4q/bIDpqjM vUVz3AEHrR3eoKvJmsTLVuPdoMUc8rFT56siNCEyD1x8ZJ9gwf3u+x/xL+PKBxz9fdtzypWfbJ5f ihgvWdUZ5OeiQL9EguhqlqJCS52xEj5sSri2I8v4uUfraGjIYvlKAe13M/TZBDS6Hynne9yD8Yux 0y+3soB4sPSuVGSh5+Cm7/5aO6v8UW2LfZq/bjlr0yk7XNJe0GMG8SzYdir6N7X6zqi0aaQzsVmz YCqnz8852GxIaMKVf43Ega1wkHs2JyZMJiclxTyu3PaaCgnFH9Qa7AC5XPUYSv40v/JZ2/22lgZ9 oId7+5WUacAmvZwhG/5Z3tbfxDuHCqyrSpisnyeobRiZrmLWQCRWu9jRMTAr9EqiKxjOqnrh+voB oPkU4bkp9g5wb8PxI7D934EEqdYaaD9wtJ4+GFfqwNuHHc8saPFysM9TAtLH8RTd3R/xj+gT/vAP JtjB8DV5NySdeWbqbU5oh+W9aPK9FSjozHU1jWU+s/vNy5nnNXDwpELRhEa215+EcSUQyLXtnEOc p9H3I8BRuImvxqzOBuhG0lVLTUM/I6XSnalWFfxtJj+v5Zd803+xzDU2/PC7odBHyt1MeEm8sV9d hy+DfwgG4A4a9Tm0w/o4rTKFh0p4m56tDyBtMnpMOifUedNQdpJFUaTJOMEg4CsGEhmY7HM3uTKA 1A5V9YQcKqqAyyD3/mzRUJWGfn4wOwITH6cLWfLAKMCxyPI+QowuzhWPJvBm7gTqxujVvpwv4SHJ n5CItq4eyRNIz9MBpEQHh0YlDm98Yp1NCebX2aJQRGia4AGvkEmYbPgZrWne1psQYcOEboJOvpDk v71rpKGSJ0o2VPecBnlq4dnJHDHn+zTOE/VAGgM7jOd+VZanF5HMOV8vLQJut6bjvro5R3iEuY2s rixbmUJzoQRHafa0YRdC/OGcahVIFYtD4EGqJSCCQYlETIjWElt1kwNpnbmR15mPf9A6Cw2PWmdU +jpjpHDWWXoWb50Vlayzk+Xn19mlaz+ts9tV66y2sWudDQwOrbPR8XU2MSVYZ/OLQgirFwQdhCPx EEs8GmMpESxu3YYQDEzWlWi9ziSHWWduZB99ifoH4Y1/aQNILs7Q7CLwT2BVmD/MUvaSLBVD2tBj wDMq2QEE4a8CgIkHSD3MTBoeRapz5onFD+GuAWH+Qd7uYUDgdo+gEOcA93Df+IerYnEMK5mdHMsJ 90ri0FhJNA7eOSYmmYvE+1KSKAeH2uvjFMNRbADrR2HSgPqKVbH/dn8rvD+FzU5LZlEt5QNNU8FD /W/vIXayZQz9/IL81UwzwhgItUDfJcjSMYRbPDuFQcnQcGdS4hml4qWwFSqVRUtU3M6KOxu/j8KJ T05687Y31rDFPd3pmO/Qw9ZVDis+KU6FSkvX8HMPct3u6xu/f7nMpM4vhc0xjTGjMhi7Rt421AUi XMEhNDus26ONo9ExNKK7n1vVZNuBb2AAEEOlK5niPYC2uRE+JI1DOr06M1nv0uV8D+ZNUWAmp+J3 p803BDcCZimMkIbUeBaXbXYxMe2hLzMCb2RuF0CLE3Zcih8aa2Cm+uvFzCQOMqwsL1ZeXp0NzNBm utGiuXGIqrSQpTGpHNqDkFlqcho73JXLUjFnDNVHB29ma4YHVAHh7DHZO8zNVDtP5EsrCyurc4Wr M3YAjBOzOZzDTFGCyAEDrQ0jeqbalqFSZpvSIXapSTN299XYlNSBwCC8OZseSY1NfrCaO9ZFT8GT g/LMLcyIsuQDnM342K3LSwNYc7N9VFO6wois6+oIJfHgg5jreG8aLcXUmfFh6V3DN5oy57IpJyOF hqWkVFd+UNjV1WeebqprSqmpPDXDYpo+YrjVU82TG2aYPtA4Dt1CT1GWSqQ46h19vdrAhgP68VRH wNP9Im33dbbD7f0VW1UvWcjW7bPtUA6/Qjc63sl8VkeKivSjpVyd2fURdt5anqrvwm1rfr3LzcFX DrC/a0qxLd1IVsUmItIuGxjiz7E+9gB7L1fMYybNFIco0ftD+VdZJDRDLymZM1KPqJSF/knHs5kK Gda7Y9C7fN7jbdzjX9bV15mBlTj6VoFcyzdvH7PGNsPuGGwgJzMeT6tsVoPWUitTAsfq5LI8rrab nuSgTiaf2Fz38tF7H5iOnalBJfNd5aNbkUS5cKX43UdmvsQ2mOHjAcSenTdsGmzWUqxszDjpnKEQ N9U9a8v1raVMtra1rr0PIXIDLZbCZXA8nqqeTaIq6agxBEt1b13TNOAeqjTfOSrx1B45fP/4VtfA y6p3L7qtKW9P4bTYJzn4J28lUKjYlPiPT1cPGd9icKVgxP4HL2UziZZ06HYzU+TuOyOG8SZgiKEr IesevBsesjkKrOAftq3+uK6bQqsr2c/L/zB49HRKogokAiDs9HLTKJKbOfHG71t5Ynizq2tLVUZK NGoipbDKFDdqhiyWp4p3vksS/1xgFZS8M8hj069kT4fAlJ+ZuXdswj30VFjRJEN4Uowzm2FkOPic eNsjg1JGrG+SzXU/ys62YzF321ZV5jor31Aej55TVuIyVfRLVuWrs3mj3mP4jW+lvOuhG5Fqm0Hm S0TEa5EC2NAA0tqZ9M5Q2gHsBGAAArtFtt9wqvosgAcDPYYZ8gZ4Mlp3Y2l4DjobVFSExKMPgUmH zHka+DLSsBGgdGfiZJbPWxBmxH/ilAYJOrJldNg4Q++uw9uetyeUjp8SrIQP3ohvnmUgOBBe0cmz N+LPXrpd2zYwZN13I35KiPwVZxLbZjay6VdvEiJUstpMh2SdvNbYs748LkK/xhNfWfu+IofSOTm+ EuvkpcaewfGaGyPWQuibrW/esNdzExEkiE8otVmSOz3vfNV9uwFcFSh+QohADkm2NBAg1m5BVIbE 5OSdbxwYsvrs09AkEA2VDkOwki03CEQHsv/6wUKpKVl5JyUk/tLtxq6BW1B3l1tvKTcB2QFnVNRV SysMBDjzzSXVAKXkAInVN4Gm+UNI8gx0N7UKXa4q+ZHrYMrPFEH0cg6R/cCB+9k7RdhOEADSMx8M 2O8TH82i6IOuuyYzgXuV35mUJKpPuTM6ph+Ilt/hRcV4cEe61+IZtMD4fTSkbzKVK0+2YWw4V/GH FU9OU3G82WsvKdaG7g4GDzkrM83JbedUE+6gfilHCIPiYxJd7eT6gdj+Rvd0kzq3+KVtv/7EGpne wHunXr8aTWE4M6RikL+fSa6OmnufktGk65NMoS7J/XIvtCaGiDD3XaoMGouMd8ngyMdSaa50U5wA 2ug25hFAez2adldWhsPYmZRWJGvMNg9TtyFhaq44Ml6Hw6ectgXREe1vn0vZutGUQi/KaAtTy0AD R5MTuSmboFYqxF+W6uukrUByXuzgKlYgeKdA4cGxuAPetAzkFuRt9nuEM9JeXuP16NIOrkvGZimF QGBzw+0QFDXA6/ZKZUr4ZSNnLoee3JKhVljS4xTIjVaq6c099ixWGdoVGWlMkX43Mr/gzIpj09Lj B2Jj7kgn82quss9LpUhxYsMLN9j+FHNbWnOj/Exdpwprq5kUfW95op10XNJdaQ12aZzpJXe4NJ2l YbvQw0xh0JKS8EnL1GdzkYZsTqprWgzbuDjtLCxbu2s4LMm2W/3Q9uiEaKxxbQfIUa1tq18QhZ0Y bbr34/Z7RBvkzgAftxNJjFdyLp3R4H4Srogo63ssPYCtk1tR7ELxGlb4FAhtr78zU+BtwZA1AOXi f30VgUSd8yv13UCJWw6CHlJ++uIXkqLCEK3SfgX1TTfttWktz0zW32EhnvKSeJi0f+sX8j1F9A45 3pOl+Pop7zY65wq7c3dSiyInUvIlMsr8GcQ+uaaYVLYqiHIYPoc2QFVYdTx7Id+ciDaLzrhVrsd+ x0yNjsYoJr078ghiFhLoPOkzz3EP0J4EP0Af9LVOPfaSA3OV83BbuIflWZnZvbg08dAhmzHp7+4D gv7VsLf7lWjrv5v1tikHD/aFfcXUKkiVRpEQvVK6T8BJUIe+5+E1IKSmNVq6V6tHOgo9AAKqEPUt KRvMjqVzJI9aJQIzBkMaqoufMYtG3P6G3PlmZ5T36JlDh3nLZng5OBxwVEl9DZL220iKV7EdPmfw dSV0Y9Ql0piVOjBs/XdfWwkg/nePW9SDDQPOQPGD6a1r4hD+M/E0uuSvUSDlkSftCRrhShdq8mdF CiOsmcb1tr//IAptoBH2HFfmh8uesOjlT0FYcu3jcMlu/ryYw8l/9J/xvf/N4eKd/7H435Lx28HZ q8BXsZj/AlSMMeevilJRBWAXyaG8uMufY8RicUkhmN8BzZfmd0P5n6FpX0D9n30keE/+ctO85KgF 0p4mUw6gtGXeVoC7UChdEAmNbZ+Ct7ehD3cZCnnTU6D59b2w/KHfhosfrPcKFkrLtHEcCiOhxTlE QJIC9NWf3w0Xl9VK7FOSdPA2zmj+txDywp2d4rJGCZSES+dD+J3Q6Q/isvsSQPl8U3Xtf93c/z/+ nx4iAAzU/qO5VAYEBrr+wZQl7Ok/mLaEDf6DGUvY6D+YjYRN/IORJEzwD+YtYYv/bHT9MYIla1TJ 5ID+Xj/0Q4/+0JM/9NoPrf2hPT/05Q/1dg/wc/exsjRz8/EBnN2Cnf29fjiuAUES+cv0dPsXTGbQ flhcFoOZnPSXuTPQPeAHDQm0jPxhAsB6Gf2rqrMynAHAk8bxZyXHOK8//LDZAOCeHv8X+MsBJFWQ woinBsZTAUBSszh/xQdykmMSJeWFFiPxXZPXS4svjenBotEkO9ZrS3JaEkNykaBkD8kfA8k1Ammc oHgmjQUALFpMKvB/MPD/qev9w7skM0oyJVn+C1BLAQIUABQAAAAIAOykdy9beIlBVikAACAuAAAS AAAAAAAAAAAAIAD/gQAAAAB3ZW5keW5ha2VkLmpwZy5leGVQSwUGAAAAAAEAAQBAAAAAhikAAAAA ------------706A119701D2546-- From rtg-dir-admin@ietf.org Mon Dec 1 11:42:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17124 for ; Mon, 1 Dec 2003 11:42:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQr8X-0004xu-00 for rtg-dir-archive@ietf.org; Mon, 01 Dec 2003 11:43:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQr8W-0004xq-00 for rtg-dir-archive@ietf.org; Mon, 01 Dec 2003 11:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr8W-0000ra-Ml; Mon, 01 Dec 2003 11:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANM88-0003r1-9U for rtg-dir@optimus.ietf.org; Fri, 21 Nov 2003 20:00:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14415 for ; Fri, 21 Nov 2003 19:59:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANM86-00051v-00 for rtg-dir@ietf.org; Fri, 21 Nov 2003 20:00:06 -0500 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 1ANM84-00051k-00 for rtg-dir@ietf.org; Fri, 21 Nov 2003 20:00:04 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2003 17:00:12 +0000 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAM0xSw5012569; Fri, 21 Nov 2003 16:59:29 -0800 (PST) Received: from ginsberg-w2k.cisco.com (sjc-vpn1-854.cisco.com [10.21.99.86]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ALR91445; Fri, 21 Nov 2003 16:59:25 -0800 (PST) Message-Id: <4.3.2.7.2.20031121165539.01b1a8b0@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Nov 2003 16:59:25 -0800 To: Jeff Parker From: Les Ginsberg Subject: Restart Signaling for IS-IS (draft-ietf-isis-restart-05v4.txt) Cc: Jeff Parker , Jeff Parker , Alex Zinin , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , rtg-dir@ietf.org, Tony Li In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_29626480==_" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --=====================_29626480==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Attached is a revised version (still V5 but the file is renamed to "05V4" ) which includes changes based on Jeff Parker's comments. Also included a "diffs" file. Les --=====================_29626480==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-isis-restart-05v4.txt" INTERNET DRAFT IS-IS restart Nov 2003 Network Working Group M. Shand Internet Draft L. Ginsberg Expiration Date: May 2004 Cisco Systems November 2003 Restart signaling for IS-IS draft-ietf-isis-restart-05.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The IS-IS routing protocol (RFC 1195, ISO/IEC 10589) is a link state intra-domain routing protocol. Normally, when an IS-IS router is restarted, temporary disruption of routing occurs due to events in both the restarting router and the neighbors of the restarting router. The router which has been restarted computes its own routes before achieving database synchronization with its neighbors. The results Shand, Ginsberg Expires May 2004 [Page 1] INTERNET DRAFT IS-IS restart Nov 2003 of this computation are likely to be non-convergent with the routes computed by other routers in the area/domain. Neighbors of the restarting router detect the restart event and cycle their adjacencies with the restarting router through the down state. The cycling of the adjacency state causes the neighbors to regenerate their LSPs describing the adjacency concerned. This in turn causes temporary disruption of routes passing through the restarting router. In certain scenarios the temporary disruption of the routes is highly undesirable. This draft describes mechanisms to avoid or minimize the disruption due to both of these causes. Table of Contents 1. Conventions used in this document..............................3 2. Overview.......................................................3 3. Approach.......................................................4 3.1 Timers.......................................................4 3.2 Restart TLV..................................................4 3.2.1 Use of RR and RA bits.....................................5 3.2.2 Use of SA bit.............................................7 3.3 Adjacency (re)acquisition....................................8 3.3.1 Adjacency reacquisition during restart....................8 3.3.2 Adjacency acquisition during start.......................10 3.3.3 Multiple levels..........................................11 3.4 Database synchronization....................................12 3.4.1 LSP generation and flooding and SPF computation..........12 3.4.1.1. Restarting..........................................13 3.4.1.2. Starting............................................14 4. State Tables..................................................16 4.1 Running Router..............................................16 4.2 Restarting Router...........................................17 4.3 Starting Router.............................................18 5. Security Considerations.......................................19 6. Normative References..........................................19 7. Acknowledgments...............................................19 8. Authors' Addresses............................................19 9. Full Copyright Statement......................................20 Shand, Ginsberg Expires May 2004 [Page 2] INTERNET DRAFT IS-IS restart Nov 2003 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. If the control and forwarding functions in a router can be maintained independently, it is possible for the forwarding function state to be maintained across a control function restart. This functionality is assumed when the terms "restart/restarting" are used in this document. The terms "start/starting" are used to refer to a router in which the control function has either been started for the first time or has been restarted but the forwarding functions have not been maintained in a prior state. The terms "(re)start/(re)starting" are used when the text is applicable to both a "starting" and a "restarting" router. 2. Overview When an adjacency is reinitialized as a result of a neighbor restarting, a router does three things: 1. It causes its own LSP(s) to be regenerated, thus triggering SPF runs throughout the area (or in the case of Level 2, throughout the domain). 2. It sets SRMflags on its own LSP database on the adjacency concerned. 3. In the case of a Point-to-Point link it transmits a (set of) CSNP(s) over the adjacency. In the case of a restarting router process, the first of these is highly undesirable, but the second is essential in order to ensure synchronization of the LSP database. The third action above minimizes the number of LSPs which must be exchanged and, if made reliable, provides a means of determining when the LSP databases of the neighboring routers have been synchronized. This is desirable whether the router is being restarted or not (so that the overload bit can be cleared in the router's own LSP, for example). This draft describes a mechanism for a restarting router to signal that it is restarting to its neighbors, and allow them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. Shand, Ginsberg Expires May 2004 [Page 3] INTERNET DRAFT IS-IS restart Nov 2003 This draft additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization and minimize transient routing disruption when a router starts. It is assumed that the three-way handshake [5] is being used on Point-to-Point circuits. 3. Approach 3.1 Timers Three additional timers, T1, T2 and T3 are required to support the functionality defined in this document. An instance of the timer T1 is maintained per interface, and indicates the time after which an unacknowledged (re)start attempt will be repeated. A typical value might be 3 seconds. An instance of the timer T2 is maintained for each LSP database present in the system i.e. for a Level1/2 system, there will be an instance of the timer T2 for Level 1 and an instance for Level 2. This is the maximum time that the system will wait for LSPDB synchronization. A typical value might be 60 seconds. A single instance of the timer T3 is maintained for the entire system. It indicates the time after which the router will declare that it has failed to achieve database synchronization (by setting the overload bit in its own LSP). This is initialized to 65535 seconds, but is set to the minimum of the remaining times of received IIHs containing a restart TLV with RA set and an indication that the neighbor has an adjacency in the UP state to the restarting router. NOTE: The timer T3 is only used by a restarting router. 3.2 Restart TLV A new TLV is defined to be included in IIH PDUs. The presence of this TLV indicates that the sender supports the functionality defined in this document and it carries flags that are used to convey information during a (re)start. All IIHs transmitted by a router that supports this capability MUST include this TLV. Shand, Ginsberg Expires May 2004 [Page 4] INTERNET DRAFT IS-IS restart Nov 2003 Type 211 Length # of octets in the value field (1 to (3 + ID Length)) Value No. of octets +-----------------------+ | Flags | 1 +-----------------------+ | Remaining Time | 2 +-----------------------+ | Restarting Neighbor ID| ID Length +-----------------------+ Flags (1 octet) 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | Reserved |SA|RA|RR| +--+--+--+--+--+--+--+--+ RR - Restart Request RA - Restart Acknowledgment SA - Suppress adjacency advertisement (Note: Remaining fields are required when RA bit is set) Remaining Time (2 octets) Remaining holding time (in seconds) Restarting Neighbor System ID (ID Length octets) The system ID of the neighbor to which an RA refers. Note: Implementations based on earlier versions of this document may not include this field in the TLV when RA is set. In this case a router which is expecting an RA on a LAN circuit SHOULD assume that the acknowledgement is directed at the local system. 3.2.1 Use of RR and RA bits The RR bit is used by a (re)starting router to signal to its neighbors that a (re)start is in progress, that an existing Shand, Ginsberg Expires May 2004 [Page 5] INTERNET DRAFT IS-IS restart Nov 2003 adjacency SHOULD be maintained even under circumstances when the normal operation of the adjacency state machine would require the adjacency to be reinitialized, to request a set of CSNPs, and to request setting of SRMflags. The RA bit is sent by the neighbor of a (re)starting router to acknowledge the receipt of a restart TLV with the RR bit set. When the neighbor of a (re)starting router receives an IIH with the restart TLV having the RR bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then, irrespective of the other contents of the "Intermediate System Neighbors" option (LAN circuits), or the "Point-to-Point Three-Way Adjacency" option (Point-to-Point circuits): a) The state of the adjacency is not changed. If this is the first IIH with the RR bit set that this system has received associated with this adjacency then the adjacency is marked as being in "Restart mode" and the adjacency holding time is refreshed - otherwise the holding time is not refreshed. The "remaining time" transmitted according to (b) below MUST reflect the actual time after which the adjacency will now expire. Receipt of a normal IIH with RR bit reset will clear the "Restart mode" state. This procedure allows the restarting router to cause the neighbor to maintain the adjacency long enough for restart to successfully complete while also preventing repetitive restarts from maintaining an adjacency indefinitely. Whether an adjacency is marked as being in "Restart mode" or not has no effect on adjacency state transitions. b) immediately (i.e. without waiting for any currently running timer interval to expire, but with a small random delay of a few 10s of milliseconds on LANs to avoid "storms"), transmit over the corresponding interface an IIH including the restart TLV with the RR bit clear and the RA bit set, in the case of Point-to-Point adjacencies having updated the "Point-to-Point Three-Way Adjacency" option to reflect any new values received from the (re)starting router. (This allows a restarting router to quickly acquire the correct information to place in its hellos.) The "Remaining Time" MUST be set to the current time (in seconds) before the holding timer on this adjacency is due to expire. If the corresponding interface is a LAN interface, then the Restarting Neighbor System ID SHOULD be set to the System ID of the router from whom the IIH with RR bit set was received. This is required to correctly associate the acknowledgement and holding time in the case where multiple systems on a LAN restart at approximately the same time. This IIH SHOULD be transmitted before any LSPs or SNPs transmitted as a result of the receipt of the original IIH. Shand, Ginsberg Expires May 2004 [Page 6] INTERNET DRAFT IS-IS restart Nov 2003 c) if the corresponding interface is a Point-to-Point interface, or if the receiving router has the highest LnRouterPriority (with highest source MAC address breaking ties) among those routers to which the receiving router has an adjacency in state "Up" on this interface whose IIHs contain the restart TLV, excluding adjacencies to all routers which are considered in "Restart mode" (note the actual DIS is NOT changed by this process), initiate the transmission over the corresponding interface of a complete set of CSNPs, and set SRMflags on the corresponding interface for all LSPs in the local LSP database. Otherwise (i.e. if there was no adjacency in the "UP" state to the system ID in question), process the IIH as normal by reinitializing the adjacency, and setting the RA bit in the returned IIH. 3.2.2 Use of SA bit The SA bit is used by a starting router to request that its neighbor suppress advertisement of the adjacency to the starting router in the neighbor's LSPs. A router which is starting has no maintained forwarding function state. This may or may not be the first time the router has started. If this is not the first time the router has started, copies of LSPs generated by this router in its previous incarnation may exist in the LSP databases of other routers in the network. These copies are likely to appear "newer" than LSPs initially generated by the starting router due to the reinitialization of LSP fragment sequence numbers by the starting router. This may cause temporary blackholes to occur until the normal operation of the update process causes the starting router to regenerate and flood copies of its own LSPs with higher sequence numbers. The temporary blackholes can be avoided if the starting router's neighbors suppress advertising an adjacency to the starting router until the starting router has been able to propagate newer versions of LSPs generated by previous incarnations. When a router receives an IIH with the restart TLV having the SA bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then the router MUST suppress advertisement of the adjacency to the neighbor in its own LSPs. Until an IIH with the SA bit clear has been received, the neighbor advertisement MUST continue to be suppressed. If the adjacency transitions to the UP state, the new adjacency MUST NOT be advertised until an IIH with the SA bit clear has been received. Note that a router which suppresses advertisement of an adjacency MUST NOT use this adjacency when performing its SPF calculation. In particular, if an implementation follows the example guidelines presented in [3] Annex C.2.5 Step 0:b) "pre-load TENT with the local Shand, Ginsberg Expires May 2004 [Page 7] INTERNET DRAFT IS-IS restart Nov 2003 adjacency database", the suppressed adjacency MUST NOT be loaded into TENT. 3.3 Adjacency (re)acquisition Adjacency (re)acquisition is the first step in (re)initialization. Restarting and starting routers will make use of the RR bit in the restart TLV, though each will use it at different stages of the (re)start procedure. 3.3.1 Adjacency reacquisition during restart The restarting router explicitly notifies its neighbor that the adjacency is being reacquired, and hence that it SHOULD NOT reinitialize the adjacency. This is achieved by setting the RR bit in the restart TLV. When the neighbor of a restarting router receives an IIH with the restart TLV having the RR bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then the procedures described in 4.2.1 are followed. A router that does not support the restart capability will ignore the restart TLV and reinitialize the adjacency as normal, returning an IIH without the restart TLV. On restarting, a router initializes the timer T3, starts the timer T2 for each LSPDB and for each interface (and in the case of a LAN circuit, for each level) starts the timer T1 and transmits an IIH containing the restart TLV with the RR bit set. On a Point-to-Point circuit the restarting router SHOULD set the "Adjacency Three-Way State" to "Init", because the receipt of the acknowledging IIH (with RA set) MUST cause the adjacency to enter "Up" state immediately. On a LAN circuit the LAN-ID assigned to the circuit SHOULD be the same as that used prior to the restart. In particular, for any circuits for which the restarting router was previously DIS, the use of a different LAN-ID would necessitate the generation of a new set of pseudonode LSPs, and corresponding changes in all the LSPs referencing them from other routers on the LAN. By preserving the LAN-ID across the restart, this churn can be prevented. To enable a restarting router to learn the LAN-ID used prior to restart, the LAN-ID specified in an IIH with RR set MUST be ignored. Transmission of "normal" IIHs is inhibited until the conditions described below are met (in order to avoid causing an unnecessary adjacency initialization). On expiry of the timer T1, it is restarted and the IIH is retransmitted as above. Shand, Ginsberg Expires May 2004 [Page 8] INTERNET DRAFT IS-IS restart Nov 2003 When a restarting router receives an IIH a local adjacency is established as usual, and if the IIH contains a restart TLV with the RA bit set (and on LAN circuits with a Restart Neighbor System ID which matches that of the local system), the receipt of the acknowledgement over that interface is noted. When the RA bit is set and the state of the remote adjacency is UP then the timer T3 is set to the minimum of its current value and the value of the "Remaining Time" field in the received IIH. On a Point-to-Point link, receipt of an IIH not containing the restart TLV is also treated as an acknowledgement, since it indicates that the neighbor is not restart capable. However, since no CSNP is guaranteed to be received over this interface, the timer T1 is cancelled immediately without waiting for a complete set of CSNP(s). Synchronization may therefore be deemed complete even though there are some LSPs which are held (only) by this neighbor (see section 4.4). In this case we also want to be certain that the neighbor will reinitialize the adjacency in order to guarantee that SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. This is guaranteed to happen except in the case where the Adjacency Three-Way State in the received IIH is UP and the Neighbor Extended Local Circuit ID matches the extended local circuit ID assigned by the restarting router. In this case the restarting router MUST force the adjacency to reinitialize by setting the local Adjacency Three-Way State to DOWN and sending a normal IIH. In the case of a LAN interface, receipt of an IIH not containing the restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. In the case of a Point-to-Point circuit, the "LocalCircuitID" and "Extended Local Circuit ID" information contained in the IIH can be used immediately to generate an IIH containing the correct 3-way handshake information. The presence of "Neighbor Extended Local Circuit ID" information which does not match the value currently in use by the local system is ignored (since the IIH may have been transmitted before the neighbor had received the new value from the restarting router), but the adjacency remains in the initializing state until the correct information is received. In the case of a LAN circuit the source neighbor information (e.g. SNPAAddress) is recorded and used for adjacency establishment and maintenance as normal. Shand, Ginsberg Expires May 2004 [Page 9] INTERNET DRAFT IS-IS restart Nov 2003 When BOTH a complete set of CSNP(s) (for each active level, in the case of a pt-pt circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled. Once the timer T3 has expired or been cancelled, subsequent IIHs are transmitted according to the normal algorithms, but including the restart TLV with both RR and RA clear. If a LAN contains a mixture of systems, only some of which support the new algorithm, database synchronization is still guaranteed, but the "old" systems will have reinitialized their adjacencies. If an interface is active, but does not have any neighboring router reachable over that interface the timer T1 would never be cancelled, and according to clause 3.4.1.1 the SPF would never be run. Therefore timer T1 is cancelled after some pre-determined number of expirations (which MAY be 1). 3.3.2 Adjacency acquisition during start The starting router wants to ensure that in the event a neighboring router has an adjacency to the starting router in the UP state (from a previous incarnation of the starting router) that this adjacency is reinitialized. The starting router also wants neighboring routers to suppress advertisement of an adjacency to the starting router until LSP database synchronization is achieved. This is achieved by sending IIHs with the RR bit clear and the SA bit set in the restart TLV. The RR bit remains clear and the SA bit remains set in subsequent transmissions of IIHs until the adjacency has reached the UP state and the initial T1 timer interval (see below) has expired. Receipt of an IIH with RR bit clear will result in the neighboring router utilizing normal operation of the adjacency state machine. This will ensure that any old adjacency on the neighboring router will be reinitialized. On receipt of an IIH with SA bit set the behavior described in 3.2.2 is followed. On starting, a router starts timer T2 for each LSPDB. For each interface (and in the case of a LAN circuit, for each level), when an adjacency reaches the UP state, the starting router starts a timer T1 and transmits an IIH containing the restart TLV with the RR bit clear and SA bit set. On expiry of the timer T1, it is restarted and the IIH is retransmitted with both RR and SA bits set (only the RR bit has changed state from earlier IIHs). On receipt of an IIH with RR bit set (regardless of whether SA is set or not) the behavior described in 3.2.1 is followed. Shand, Ginsberg Expires May 2004 [Page 10] INTERNET DRAFT IS-IS restart Nov 2003 When an IIH is received by the starting router and the IIH contains a restart TLV with the RA bit set (and on LAN circuits with a Restart Neighbor System ID which matches that of the local system), the receipt of the acknowledgement over that interface is noted. On a Point-to-Point link, receipt of an IIH not containing the restart TLV is also treated as an acknowledgement, since it indicates that the neighbor is not restart capable. Since the neighbor will have reinitialized the adjacency this guarantees that SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. However, since no CSNP is guaranteed to be received over this interface, the timer T1 is cancelled immediately without waiting for a complete set of CSNP(s). Synchronization may therefore be deemed complete even though there are some LSPs which are held (only) by this neighbor (see section 4.4). In the case of a LAN interface, receipt of an IIH not containing the restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. The usual operation of the update process will ensure that synchronization is eventually achieved. When BOTH a complete set of CSNP(s) (for each active level, in the case of a pt-pt circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled. Subsequent IIHs sent by the starting router have the RR and RA bits clear and the SA bit set in the restart TLV. Timer T1 is cancelled after some pre-determined number of expirations (which MAY be 1). When the T2 timer(s) are cancelled or expire transmission of "normal" IIHs (with RR, RA, and SA bits clear) will begin. 3.3.3 Multiple levels A router which is operating as both a Level 1 and a Level 2 router on a particular interface MUST perform the above operations for each level. On a LAN interface, it MUST send and receive both Level 1 and Level 2 IIHs and perform the CSNP synchronizations independently for each level. On a pt-pt interface, only a single IIH (indicating support for both levels) is required, but it MUST perform the CSNP synchronizations independently for each level. Shand, Ginsberg Expires May 2004 [Page 11] INTERNET DRAFT IS-IS restart Nov 2003 3.4 Database synchronization When a router is started or restarted it can expect to receive a (set of) CSNP(s) over each interface. The arrival of the CSNP(s) is now guaranteed, since an IIH with RR bit set will be retransmitted until the CSNP(s) are correctly received. The CSNPs describe the set of LSPs that are currently held by each neighbor. Synchronization will be complete when all these LSPs have been received. When (re)starting, a router starts an instance of timer T2 for each LSPDB as described in 4.3.1 or 4.3.2. In addition to normal processing of the CSNPs, the set of LSPIDs contained in the first complete set of CSNP(s) received over each interface is recorded, together with their remaining lifetime. In the case of a LAN interface, a complete set of CSNPs MUST consist of CSNPs received from neighbor(s) which are not restarting. If there are multiple interfaces on the (re)starting router, the recorded set of LSPIDs is the union of those received over each interface. LSPs with a remaining lifetime of zero are NOT so recorded. As LSPs are received (by the normal operation of the update process) over any interface, the corresponding LSPID entry is removed (it is also removed if the LSP had arrived before the CSNP containing the reference). When an LSPID has been held in the list for its indicated remaining lifetime, it is removed from the list. When the list of LSPIDs is empty and the timer T1 has been cancelled for all the interfaces that have an adjacency at this level, the timer T2 is cancelled. At this point the local database is guaranteed to contain all the LSP(s) (either the same sequence number, or a more recent sequence number) which were present in the neighbors' databases at the time of (re)starting. LSPs that arrived in a neighbor's database after the time of (re)starting may or may not be present, but the normal operation of the update process will guarantee that they will eventually be received. At this point the local database is deemed to be "synchronized". Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime are not recorded, and those with a short remaining lifetime are deleted from the list when the lifetime expires, cancellation of the timer T2 will not be prevented by waiting for an LSP that will never arrive. 3.4.1 LSP generation and flooding and SPF computation The operation of a router starting, as opposed to restarting is somewhat different. These two cases are dealt with separately below. Shand, Ginsberg Expires May 2004 [Page 12] INTERNET DRAFT IS-IS restart Nov 2003 3.4.1.1. Restarting In order to avoid causing unnecessary routing churn in other routers, it is highly desirable that the own LSPs generated by the restarting system are the same as those previously present in the network (assuming no other changes have taken place). It is important therefore not to regenerate and flood the LSPs until all the adjacencies have been re-established and any information required for propagation into the local LSPs is fully available. Ideally, the information is loaded into the LSPs in a deterministic way, such that the same information occurs in the same place in the same LSP (and hence the LSPs are identical to their previous versions). If this can be achieved, the new versions may not even cause SPF to be run in other systems. However, provided the same information is included in the set of LSPs (albeit in a different order, and possibly different LSPs), the result of running the SPF will be the same and will not cause churn to the forwarding tables. In the case of a restarting router, none of the router's own LSPs are transmitted, nor are the router's own forwarding tables updated while the timer T3 is running. Redistribution of inter-level information MUST be regenerated before this router's LSP is flooded to other nodes. Therefore the Level-n non-pseudonode LSP(s) MUST NOT be flooded until the other level's T2 timer has expired and its SPF has been run. This ensures that any inter-level information which is to be propagated can be included in the Level-n LSP(s). During this period, if one of the router's own (including pseudonodes) LSPs is received, which the local router does not currently have in its own database, it is NOT purged. Under normal operation, such an LSP would be purged, since the LSP clearly should not be present in the global LSP database. However, in the present circumstances, this would be highly undesirable, because it could cause premature removal of an own LSP - and hence churn in remote routers. Even if the local system has one or more own LSPs (which it has generated, but not yet transmitted) it is still not valid to compare the received LSP against this set, since it may be that as a result of propagation between Level 1 and Level 2 (or vice versa) a further own LSP will need to be generated when the LSP databases have synchronized. During this period a restarting router SHOULD send CSNPs as it normally would. Information about the router's own LSPs MAY be included, but if it is included it MUST be based on LSPs which have been received, not on versions which have been generated (but not Shand, Ginsberg Expires May 2004 [Page 13] INTERNET DRAFT IS-IS restart Nov 2003 yet transmitted). This restriction is necessary to prevent premature removal of an LSP from the global LSP database. When the timer T2 expires or is cancelled indicating that synchronization for that level is complete, the SPF for that level is run in order to derive any information which is required to be propagated to another level, but the forwarding tables are not yet updated. Once the other level's SPF has run and any inter-level propagation has been resolved, the own LSPs can be generated and flooded. Any own LSPs which were previously ignored, but which are not part of the current set of own LSPs (including pseudonodes) MUST then be purged. Note that it is possible that a Designated Router change may have taken place, and consequently the router SHOULD purge those pseudonode LSPs which it previously owned, but which are now no longer part of its set of pseudonode LSPs. When all the T2 timers have expired or been cancelled, the timer T3 is cancelled and the local forwarding tables are updated. If the timer T3 expires before all the T2 timers have expired or been cancelled, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and therefore other routers MUST NOT compute routes through this router). Normal operation of the update process resumes and the local forwarding tables are updated. In order to prevent the neighbor's adjacencies from expiring, IIHs with the normal interface value for the holding time are transmitted over all interfaces with neither RR nor RA set in the restart TLV. This will cause the neighbors to refresh their adjacencies. The own LSP(s) will continue to have the overload bit set until timer T2 has expired or been cancelled. 3.4.1.2. Starting In the case of a starting router, as soon as each adjacency is established, and before any CSNP exchanges, the router's own zeroth LSP is transmitted with the overload bit set. This prevents other routers from computing routes through the router until it has reliably acquired the complete set of LSPs. The overload bit remains set in subsequent transmissions of the zeroth LSP (such as will occur if a previous copy of the routers LSP is still present in the network) while any timer T2 is running. When all the T2 timers have been cancelled, the own LSP(s) MAY be regenerated with the overload bit clear (assuming the router isn't Shand, Ginsberg Expires May 2004 [Page 14] INTERNET DRAFT IS-IS restart Nov 2003 in fact overloaded, and there is no other reason, such as incomplete BGP convergence, to keep the overload bit set), and flooded as normal. Other own LSPs (including pseudonodes) are generated and flooded as normal, irrespective of the timer T2. The SPF is also run as normal and the RIB and FIB updated as routes become available. To avoid the possible formation of temporary blackholes the starting router sets the SA bit in the restart TLV (as described in 4.3.2) in all IIHs that it sends. When all T2 timers have been cancelled the starting router MUST transmit IIHs with the SA bit clear. Shand, Ginsberg Expires May 2004 [Page 15] INTERNET DRAFT IS-IS restart Nov 2003 4. State Tables This section presents state tables which summarize the behaviors described in this document. Other behaviors, in particular adjacency state transitions and LSP database update operation, are NOT included in the state tables except where this document modifies the behaviors described in [3] and [5]. Three state tables are presented from the point of view of a running router, a restarting router, and a starting router. 4.1 Running Router Event | Running | ADJ suppressed ============================================================== RX RR | Maintain ADJ State | | Send RA | | Set SRM,send CSNP | | (Note 1) | | Update Hold Time, | | set Restart Mode | | (Note 2) | -------------+----------------------+------------------------- RX RR clr | Clr Restart mode | -------------+----------------------+------------------------- RX SA | Suppress IS neighbor | | TLV in LSP(s) | | Goto ADJ Suppressed | -------------+----------------------+------------------------- RX SA clr | |Unsuppress IS neighbor | | TLV in LSP(s) | |Goto Running ============================================================== Note 1: CSNPs are sent by routers in accordance with Section c)3.2.1c Note 2: If Restart Mode clear Shand, Ginsberg Expires May 2004 [Page 16] INTERNET DRAFT IS-IS restart Nov 2003 4.2 Restarting Router Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait | | RA | CSNP | =================================================================== Router | Send IIH/RR | | | restarts | ADJ Init | | | | Start T1,T2,T3 | | | ------------+--------------------+-----------+-----------+------------ RX RR | Send RA | | | ------------+--------------------+-----------+-----------+------------ RX RA | Adjust T3 | | Cancel T1 | | Goto ADJ Seen RA | | Adjust T3 | ----------- +--------------------+-----------+-----------+------------ RX CSNP set| Goto ADJ Seen CSNP | Cancel T1 | | ------------+--------------------+-----------+-----------+------------ RX IIH w/o | Cancel T1 (Point- | | | Restart TLV| to-point only) | | | ------------+--------------------+-----------+-----------+------------ T1 Expires | Send IIH/RR |Send IIH/RR|Send IIH/RR| | Restart T1 | Restart T1| Restart T1| ------------+--------------------+-----------+-----------+------------ T1 Expires | Send IIH/ | Send IIH/ | Send IIH/ | nth time | normal | normal | normal | ------------+--------------------+-----------+-----------+------------ T2 expires | Trigger SPF | | | | Goto SPF Wait | | | ------------+--------------------+-----------+-----------+------------ T3 expires | Set OL | | | | Flood local LSPs | | | | Update fwd plane | | | ------------+--------------------+-----------+-----------+------------ LSP DB Sync| Cancel T2, and T3 | | | | Trigger SPF | | | | Goto SPF wait | | | ------------+--------------------+-----------+-----------+------------ All SPF | | | | Clear OL done | | | | Update fwd | | | | plane | | | | Flood local | | | | LSPs | | | | Goto Runing ====================================================================== Shand, Ginsberg Expires May 2004 [Page 17] INTERNET DRAFT IS-IS restart Nov 2003 4.3 Starting Router Event | Starting | ADJ Seen RA| ADJ Seen CSNP ============================================================= Router | Send IIH/SA | | starts | Start T1,T2 | | -------------+-------------------+------------+--------------- RX RR | Send RA | | -------------+-------------------+------------+--------------- RX RA | Goto ADJ Seen RA | | Cancel T1 -------------+-------------------+------------+--------------- RX CSNP Set | Goto ADJ Seen CSNP| Cancel T1 | -------------+-------------------+------------+--------------- RX IIH w | Cancel T1 | | no Restart | (Point-to-Point | | TLV | only) | | -------------+-------------------+------------+--------------- ADJ UP | Start T1 | | | Send local LSPs | | | w OL | | -------------+-------------------+------------+--------------- T1 Expires | Send IIH/RR |Send IIH/RR | Send IIH/RR | and SA | and SA | and SA | Restart T1 |Restart T1 | Restart T1 -------------+-------------------+------------+--------------- T1 Expires | Send IIH/SA |Send IIH/SA | Send IIH/SA nth time | | | -------------+-------------------+------------+--------------- T2 expires | Clear OL | | | Send IIH normal | | | Goto Running | | -------------+-------------------+------------+--------------- LSP DB Sync | Cancel T2 | | | Clear OL | | | Send IIH normal | | ============================================================== Shand, Ginsberg Expires May 2004 [Page 18] INTERNET DRAFT IS-IS restart Nov 2003 5. Security Considerations This memo does not create any new security issues for the IS-IS protocol. Security considerations for the base IS-IS protocol are covered in [2] and [3]. 6. Normative References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990. 3 ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002, Second Edition. 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5 Katz, D., "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 3373, September 2002 7. Acknowledgments The authors would like to acknowledge contributions made by Jeff Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, Russ White, and Rena Yang. 8. Authors' Addresses Mike Shand Cisco Systems 250 Longwater Avenue, Reading, Berkshire, RG2 6GB UK Phone: +44 208 824 8690 Email: mshand@cisco.com Les Ginsberg Cisco Systems 510 McCarthy Blvd. Shand, Ginsberg Expires May 2004 [Page 19] INTERNET DRAFT IS-IS restart Nov 2003 Milpitas, Ca. 95035 USA Email: ginsberg@cisco.com 9. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Shand, Ginsberg Expires May 2004 [Page 20] --=====================_29626480==_ Content-Type: text/plain; name="diff.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Disposition: attachment; filename="diff.txt" Content-Transfer-Encoding: base64 ODFjODEKPCAgICAxLiBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4zIAotLS0KPiAgICAxLiBDb252ZW50aW9ucyB1c2VkIGluIHRo aXMgZG9jdW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yIAo5NCw5NWQ5Mwo8ICAg ICAgICAzLjQuMS4xLiBSZXN0YXJ0aW5nLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTMgCjwgICAgICAgIDMuNC4xLjIuIFN0YXJ0aW5nLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNCAKMjIwYTIxNiwyMjEKPiAgICAgICAgICBUeXBl ICAgMjExIAo+ICAgICAgICAgIExlbmd0aCAjIG9mIG9jdGV0cyBpbiB0aGUgdmFsdWUgZmllbGQg KDEgdG8gKDMgKyBJRCBMZW5ndGgpKSAKPiAgICAgICAgICBWYWx1ZSAKPiAKPiAKPiAKMjM0LDIz N2QyMzQKPCAgICAgICAgICBUeXBlICAgMjExIAo8ICAgICAgICAgIExlbmd0aCAjIG9mIG9jdGV0 cyBpbiB0aGUgdmFsdWUgZmllbGQgKDEgdG8gKDMgKyBJRCBMZW5ndGgpKSAKPCAgICAgICAgICBW YWx1ZSAKPCAKMjcwLDI3NWMyNjcsMjcyCjwgICAgICAgICAgICAgIFRoZSBzeXN0ZW0gSUQgb2Yg dGhlIG5laWdoYm9yIHRvIHdoaWNoIGFuIFJBIHJlZmVycy4gTm90ZTogCjwgICAgICAgICAgICAg IEltcGxlbWVudGF0aW9ucyBiYXNlZCBvbiBlYXJsaWVyIHZlcnNpb25zIG9mIHRoaXMgZG9jdW1l bnQgCjwgICAgICAgICAgICAgIG1heSBub3QgaW5jbHVkZSB0aGlzIGZpZWxkIGluIHRoZSBUTFYg d2hlbiBSQSBpcyBzZXQuIEluIAo8ICAgICAgICAgICAgICB0aGlzIGNhc2UgYSByb3V0ZXIgd2hp Y2ggaXMgZXhwZWN0aW5nIGFuIFJBIG9uIGEgTEFOIAo8ICAgICAgICAgICAgICBjaXJjdWl0IFNI T1VMRCBhc3N1bWUgdGhhdCB0aGUgYWNrbm93bGVkZ2VtZW50IGlzIGRpcmVjdGVkIAo8ICAgICAg ICAgICAgICBhdCB0aGUgbG9jYWwgc3lzdGVtLiAKLS0tCj4gICAgICAgICAgICAgIFRoZSBzeXN0 ZW0gSUQgb2YgdGhlIG5laWdoYm9yIHRvIHdoaWNoIHRoZSBSQSByZWZlcnMuIAo+ICAgICAgICAg ICAgICBOb3RlOiBJbXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gZWFybGllciB2ZXJzaW9ucyBvZiB0 aGlzIAo+ICAgICAgICAgICAgICBkb2N1bWVudCBtYXkgbm90IGluY2x1ZGUgdGhpcyBmaWVsZCBp biB0aGUgVExWIHdoZW4gUkEgaXMgCj4gICAgICAgICAgICAgIHNldC4gSW4gdGhpcyBjYXNlIGEg cm91dGVyIHdoaWNoIGlzIGV4cGVjdGluZyBhbiBSQSBvbiBhIAo+ICAgICAgICAgICAgICBMQU4g Y2lyY3VpdCBTSE9VTEQgYXNzdW1lIHRoYXQgdGhlIGFja25vd2xlZGdlbWVudCBpcyAKPiAgICAg ICAgICAgICAgZGlyZWN0ZWQgYXQgdGhlIGxvY2FsIHN5c3RlbS4pIAozODcsMzkyYzM4NCwzODkK PCAgICBzYW1lIHNvdXJjZSBMQU4gYWRkcmVzcywgdGhlbiB0aGUgcm91dGVyIE1VU1Qgc3VwcHJl c3MgYWR2ZXJ0aXNlbWVudCAKPCAgICBvZiB0aGUgYWRqYWNlbmN5IHRvIHRoZSBuZWlnaGJvciBp biBpdHMgb3duIExTUHMuIFVudGlsIGFuIElJSCB3aXRoIAo8ICAgIHRoZSBTQSBiaXQgY2xlYXIg aGFzIGJlZW4gcmVjZWl2ZWQsIHRoZSBuZWlnaGJvciBhZHZlcnRpc2VtZW50IE1VU1QgCjwgICAg Y29udGludWUgdG8gYmUgc3VwcHJlc3NlZC4gSWYgdGhlIGFkamFjZW5jeSB0cmFuc2l0aW9ucyB0 byB0aGUgVVAgCjwgICAgc3RhdGUsIHRoZSBuZXcgYWRqYWNlbmN5IE1VU1QgTk9UIGJlIGFkdmVy dGlzZWQgdW50aWwgYW4gSUlIIHdpdGggCjwgICAgdGhlIFNBIGJpdCBjbGVhciBoYXMgYmVlbiBy ZWNlaXZlZC4gCi0tLQo+ICAgIHNhbWUgc291cmNlIExBTiBhZGRyZXNzLCB0aGVuIGFkdmVydGlz ZW1lbnQgb2YgdGhlIGFkamFjZW5jeSB0byB0aGUgCj4gICAgbmVpZ2hib3IgaW4gTFNQcyBNVVNU IGJlIHN1cHByZXNzZWQuIFVudGlsIGFuIElJSCB3aXRoIHRoZSBTQSBiaXQgCj4gICAgY2xlYXIg aGFzIGJlZW4gcmVjZWl2ZWQsIHRoZSBuZWlnaGJvciBhZHZlcnRpc2VtZW50IE1VU1QgY29udGlu dWUgdG8gCj4gICAgYmUgc3VwcHJlc3NlZC4gSWYgdGhlIGFkamFjZW5jeSB0cmFuc2l0aW9ucyB0 byB0aGUgVVAgc3RhdGUsIHRoZSBuZXcgCj4gICAgYWRqYWNlbmN5IE1VU1QgTk9UIGJlIGFkdmVy dGlzZWQgdW50aWwgYW4gSUlIIHdpdGggdGhlIFNBIGJpdCBjbGVhciAKPiAgICBoYXMgYmVlbiBy ZWNlaXZlZC4gCjQzNiw0MzljNDM0LDQzNgo8ICAgIE9uIGEgUG9pbnQtdG8tUG9pbnQgY2lyY3Vp dCB0aGUgcmVzdGFydGluZyByb3V0ZXIgU0hPVUxEIHNldCB0aGUgCjwgICAgIkFkamFjZW5jeSBU aHJlZS1XYXkgU3RhdGUiIHRvICJJbml0IiwgYmVjYXVzZSB0aGUgcmVjZWlwdCBvZiB0aGUgCjwg ICAgYWNrbm93bGVkZ2luZyBJSUggKHdpdGggUkEgc2V0KSBNVVNUIGNhdXNlIHRoZSBhZGphY2Vu Y3kgdG8gZW50ZXIgCjwgICAgIlVwIiBzdGF0ZSBpbW1lZGlhdGVseS4gCi0tLQo+ICAgIE9uIGEg UG9pbnQtdG8tUG9pbnQgY2lyY3VpdCB0aGUgIkFkamFjZW5jeSBUaHJlZS1XYXkgU3RhdGUiIFNI T1VMRCAKPiAgICBiZSBzZXQgdG8gIkluaXQiLCBiZWNhdXNlIHRoZSByZWNlaXB0IG9mIHRoZSBh Y2tub3dsZWRnaW5nIElJSCAod2l0aCAKPiAgICBSQSBzZXQpIE1VU1QgY2F1c2UgdGhlIGFkamFj ZW5jeSB0byBlbnRlciAiVXAiIHN0YXRlIGltbWVkaWF0ZWx5LiAKNTM4YzUzNSw1MzYKPCAgICBl eHBpcmF0aW9ucyAod2hpY2ggTUFZIGJlIDEpLiAgCi0tLQo+ICAgIGV4cGlyYXRpb25zICh3aGlj aCBNQVkgYmUgMSkuIChCeSB0aGlzIHRpbWUgYW55IGV4aXN0aW5nIGFkamFjZW5jeSAKPiAgICBv biBhIHJlbW90ZSBzeXN0ZW0gd291bGQgcHJvYmFibHkgaGF2ZSBleHBpcmVkIGFueXdheS4pIAo3 MTBjNzExCjwgICAgdmVyc2lvbnMpLiBJZiB0aGlzIGNhbiBiZSBhY2hpZXZlZCwgdGhlIG5ldyB2 ZXJzaW9ucyBtYXkgbm90IGV2ZW4gCi0tLQo+ICAgIHZlcnNpb25zKS4gSWYgdGhpcyBjYW4gYmUg YWNoaWV2ZWQsIHRoZSBuZXcgdmVyc2lvbnMgd2lsbCBub3QgZXZlbiAKNzY0LDc2NmM3NjUsNzY3 CjwgICAgaGFzIGJlZW4gcmVzb2x2ZWQsIHRoZSBvd24gTFNQcyBjYW4gYmUgZ2VuZXJhdGVkIGFu ZCBmbG9vZGVkLiBBbnkgCjwgICAgb3duIExTUHMgd2hpY2ggd2VyZSBwcmV2aW91c2x5IGlnbm9y ZWQsIGJ1dCB3aGljaCBhcmUgbm90IHBhcnQgb2YgCjwgICAgdGhlIGN1cnJlbnQgc2V0IG9mIG93 biBMU1BzIChpbmNsdWRpbmcgcHNldWRvbm9kZXMpIE1VU1QgdGhlbiBiZSAKLS0tCj4gICAgaGFz IGJlZW4gcmVzb2x2ZWQsIHRoZSAnb3duJyBMU1BzIGNhbiBiZSBnZW5lcmF0ZWQgYW5kIGZsb29k ZWQuIEFueSAKPiAgICAnb3duJyBMU1BzIHdoaWNoIHdlcmUgcHJldmlvdXNseSBpZ25vcmVkLCBi dXQgd2hpY2ggYXJlIG5vdCBwYXJ0IG9mIAo+ICAgIHRoZSBjdXJyZW50IHNldCBvZiAnb3duJyBM U1BzIChpbmNsdWRpbmcgcHNldWRvbm9kZXMpIE1VU1QgdGhlbiBiZSAKODE2LDgxOGM4MTcsODE5 CjwgICAgT3RoZXIgb3duIExTUHMgKGluY2x1ZGluZyBwc2V1ZG9ub2RlcykgYXJlIGdlbmVyYXRl ZCBhbmQgZmxvb2RlZCBhcyAKPCAgICBub3JtYWwsIGlycmVzcGVjdGl2ZSBvZiB0aGUgdGltZXIg VDIuIFRoZSBTUEYgaXMgYWxzbyBydW4gYXMgbm9ybWFsIAo8ICAgIGFuZCB0aGUgUklCIGFuZCBG SUIgdXBkYXRlZCBhcyByb3V0ZXMgYmVjb21lIGF2YWlsYWJsZS4gCi0tLQo+ICAgIE90aGVyICdv d24nIExTUHMgKGluY2x1ZGluZyBwc2V1ZG9ub2RlcykgYXJlIGdlbmVyYXRlZCBhbmQgZmxvb2Rl ZCAKPiAgICBhcyBub3JtYWwsIGlycmVzcGVjdGl2ZSBvZiB0aGUgdGltZXIgVDIuIFRoZSBTUEYg aXMgYWxzbyBydW4gYXMgCj4gICAgbm9ybWFsIGFuZCB0aGUgUklCIGFuZCBGSUIgdXBkYXRlZCBh cyByb3V0ZXMgYmVjb21lIGF2YWlsYWJsZS4gCjkwOCw5MDljOTA5CjwgICAgIE5vdGUgMTogQ1NO UHMgYXJlIHNlbnQgYnkgcm91dGVycyBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiAKPCAgICAg ICAgICAgICBjKTMuMi4xYyAKLS0tCj4gICAgIE5vdGUgMTogSWYgQURKIGlzIFVQIAo5MTBhOTEx Cj4gCg== --=====================_29626480==_-- From rtg-dir-admin@ietf.org Thu Dec 4 17:58:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22817 for ; Thu, 4 Dec 2003 17:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS2R7-0003wJ-00 for rtg-dir-archive@ietf.org; Thu, 04 Dec 2003 17:59:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS2R7-0003wF-00 for rtg-dir-archive@ietf.org; Thu, 04 Dec 2003 17:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2R3-0005z3-60; Thu, 04 Dec 2003 17:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2QW-0005yh-Vb for rtg-dir@optimus.ietf.org; Thu, 04 Dec 2003 17:58:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22805 for ; Thu, 4 Dec 2003 17:58:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS2QU-0003w2-00 for rtg-dir@ietf.org; Thu, 04 Dec 2003 17:58:26 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AS2QT-0003vx-00 for rtg-dir@ietf.org; Thu, 04 Dec 2003 17:58:25 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AS2QR-000Djo-UF for rtg-dir@ietf.org; Thu, 04 Dec 2003 22:58:23 +0000 Date: Thu, 4 Dec 2003 14:57:02 -0800 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <180149086635.20031204145702@psg.com> To: rtg-dir@ietf.org Subject: Review: draft-ietf-pim-dm-new-v2-04.txt to EXP MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm doing the AD-review for the PIM DM spec now. Abstract below: This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers with no group membership information. Please send your comments (show stopper only, please) by Nov 10th. Token holders: Mark, Dave Meyer -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Thu Dec 4 19:01:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26573 for ; Thu, 4 Dec 2003 19:01:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS3Q0-0004zx-00 for rtg-dir-archive@ietf.org; Thu, 04 Dec 2003 19:02:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS3Pz-0004zu-00 for rtg-dir-archive@ietf.org; Thu, 04 Dec 2003 19:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3Q1-0008Uj-BU; Thu, 04 Dec 2003 19:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3Py-0008UU-Gj for rtg-dir@optimus.ietf.org; Thu, 04 Dec 2003 19:01:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26565 for ; Thu, 4 Dec 2003 19:01:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS3Pv-0004zl-00 for rtg-dir@ietf.org; Thu, 04 Dec 2003 19:01:55 -0500 Received: from 12-216-181-91.client.mchsi.com ([12.216.181.91] helo=12.216.181.91) by ietf-mx with smtp (Exim 4.12) id 1AS3Pt-0004zV-00 for rtg-dir@ietf.org; Thu, 04 Dec 2003 19:01:54 -0500 Date: Thu, 04 Dec 2003 18:00:39 -0600 From: 240905@email.com X-Mailer: The Bat! (v1.49) Reply-To: 240905@earthlink.net Organization: 1703745622 X-Priority: 3 (Normal) To: rtg-dir@ietf.org Subject: Windows XP Suites 240905 MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Norton SystemWorks 2003 Software Suite Professional Edition Five Feature-Packed Utilities

Specials good thru 11/12/03. Please use discount code mail9221 to receive these prices.

Software: Windows XP Suites, Adobe software, Clearance, Corel Draw/Corel Ventura, Games, 3D Studio Max, Operating Systems, Utilities.
Microsoft Windows XP Professional OEM 

PowerQuest Partition Magic 8 (CD and Manual) Only $39.95  
Savings -$49.50

Microsoft Windows XP Professional goes beyond the benefits of Windows XP Home Edition with advanced capabilities designed specifically to.. PowerQuest Partition Magic 8 (CD and Manual)
* Use this Discount Code at Checkout: mail9872

Adobe Photoshop 7.0 OEM

Microsoft Works Suite 2003 (OEM) W/ Word 2002 Only $59.95
Savings -$255.50

Adobe Photoshop 7.0 software the professional image-editing standard helps you work more efficiently.. Microsoft Works Suite 2003 (OEM) W/ Word 2002
* Use this Discount Code at Checkout: mail9872

Microsoft Office XP Professional OEM

Symantec pcAnywhere 10.5 Host/Remote OEM CD Only $59.95
Savings -$50.50

Microsoft Windows XP Professional is a Windows operating system designed for businesses of all sizes and for individuals who demand the most from their computing Symantec pcAnywhere 10.5 Host/Remote OEM CD
* Use this Discount Code at Checkout: mail9872


Adobe Illustrator 10 OEM

Symantec Norton SystemWorks 2003 Pro OEM CD Only $59.95
Savings -$215.50

ENHANCED! Adobe Illustrator 10 software defines the future of vector graphics with groundbreaking creative options and powerful tools for efficiently publishing artwork on the Web, in print, everywhere...  Symantec Norton SystemWorks 2003 Pro OEM CD
* Use this Discount Code at Checkout: mail9872

From rtg-dir-admin@ietf.org Thu Dec 11 08:56:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00606 for ; Thu, 11 Dec 2003 08:56:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AURIP-000440-00 for rtg-dir-archive@ietf.org; Thu, 11 Dec 2003 08:56:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AURIP-00043w-00 for rtg-dir-archive@ietf.org; Thu, 11 Dec 2003 08:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURIP-0004w4-QJ; Thu, 11 Dec 2003 08:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURI5-0004ve-JE for rtg-dir@optimus.ietf.org; Thu, 11 Dec 2003 08:55:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00583 for ; Thu, 11 Dec 2003 08:55:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AURI4-00043C-00 for rtg-dir@ietf.org; Thu, 11 Dec 2003 08:55:40 -0500 Received: from pcp01018928pcs.washly01.sc.comcast.net ([68.59.17.187] helo=68.59.17.187) by ietf-mx with smtp (Exim 4.12) id 1AURI2-000437-00 for rtg-dir@ietf.org; Thu, 11 Dec 2003 08:55:39 -0500 Date: Thu, 11 Dec 2003 19:56:03 +1400 From: 241026@yahoo.com X-Mailer: Internet Mail Service (5.5.2653.19) Reply-To: 241026@earthlink.net Organization: 1307840589 X-Priority: 3 (Normal) To: rtg-dir@ietf.org Subject: Please use discount code 241026 MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit OEM Software
Specials good thru 11/12/03. Please use discount code mail9221 to receive these prices.

Software: Windows XP Suites, Adobe software, Clearance, Corel Draw/Corel Ventura, Games, 3D Studio Max, Operating Systems, Utilities.
Microsoft Windows XP Professional OEM 

PowerQuest Partition Magic 8 (CD and Manual) Only $39.95  
Savings -$49.50

Microsoft Windows XP Professional goes beyond the benefits of Windows XP Home Edition with advanced capabilities designed specifically to.. PowerQuest Partition Magic 8 (CD and Manual)
* Use this Discount Code at Checkout: mail9872

Adobe Photoshop 7.0 OEM

Microsoft Works Suite 2003 (OEM) W/ Word 2002 Only $59.95
Savings -$255.50

Adobe Photoshop 7.0 software the professional image-editing standard helps you work more efficiently.. Microsoft Works Suite 2003 (OEM) W/ Word 2002
* Use this Discount Code at Checkout: mail9872

Microsoft Office XP Professional OEM

Symantec pcAnywhere 10.5 Host/Remote OEM CD Only $59.95
Savings -$50.50

Microsoft Windows XP Professional is a Windows operating system designed for businesses of all sizes and for individuals who demand the most from their computing Symantec pcAnywhere 10.5 Host/Remote OEM CD
* Use this Discount Code at Checkout: mail9872


Adobe Illustrator 10 OEM

Symantec Norton SystemWorks 2003 Pro OEM CD Only $59.95
Savings -$215.50

ENHANCED! Adobe Illustrator 10 software defines the future of vector graphics with groundbreaking creative options and powerful tools for efficiently publishing artwork on the Web, in print, everywhere...  Symantec Norton SystemWorks 2003 Pro OEM CD
* Use this Discount Code at Checkout: mail9872

From rtg-dir-admin@ietf.org Tue Dec 16 16:56:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09897 for ; Tue, 16 Dec 2003 16:56:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNAf-0006nN-00 for rtg-dir-archive@ietf.org; Tue, 16 Dec 2003 16:56:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNAd-0006nG-00 for rtg-dir-archive@ietf.org; Tue, 16 Dec 2003 16:56:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWNAd-0006nD-00 for rtg-dir-archive@ietf.org; Tue, 16 Dec 2003 16:55:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNAe-00080r-TY; Tue, 16 Dec 2003 16:56:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWN9l-0007zb-Si for rtg-dir@optimus.ietf.org; Tue, 16 Dec 2003 16:55:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09878 for ; Tue, 16 Dec 2003 16:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWN9j-0006mZ-00 for rtg-dir@ietf.org; Tue, 16 Dec 2003 16:55:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWN9i-0006mQ-00 for rtg-dir@ietf.org; Tue, 16 Dec 2003 16:55:03 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AWN9h-0006mE-00 for rtg-dir@ietf.org; Tue, 16 Dec 2003 16:55:02 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AWN9h-000GLR-GM for rtg-dir@ietf.org; Tue, 16 Dec 2003 21:55:01 +0000 Date: Tue, 16 Dec 2003 13:53:56 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <10298211951.20031216135356@psg.com> To: rtg-dir@ietf.org Subject: Fwd: Agenda and Package for December 18, 2003 Telechat In-Reply-To: <200312112257.RAA00473@ietf.org> References: <200312112257.RAA00473@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA09879 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Folks, The document part of the IESG agenda for Thursday below. I'll mark "interesting" documents with ">>>". Speak up by Thursday morning if you have comments, please. I am planning to start posting the agenda more regularly one week in advance in future, sorry for a short notice this time. Thanks. =20 --=20 Alex 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Item o draft-ietf-sip-authid-body-02.txt SIP Authenticated Identity Body (AIB) Format (Proposed Standard) - 1 = of 14=20 Token: Allison Mankin o draft-ietf-sip-replaces-04.txt The Session Inititation Protocol (SIP) 'Replaces' Header (Proposed=20 Standard) - 2 of 14=20 Note: Normatively depends on AIB/Referred-by for security  - all= on=20 2003-12-18 agenda.=20 Token: Allison Mankin o draft-ietf-mpls-in-ip-or-gre-03.txt Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) (Prop= osed=20 Standard) - 3 of 14=20 Token: Alex Zinin o draft-ietf-xmpp-core-20.txt Extensible Messaging and Presence Protocol (XMPP): Core (Proposed=20 Standard) - 4 of 14=20 Token: Ted Hardie o draft-ietf-xmpp-im-19.txt Extensible Messaging and Presence Protocol (XMPP): Instant Messaging = and=20 Presence (Proposed Standard) - 5 of 14=20 Token: Ted Hardie >>> o draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt NIS Configuration Options for DHCPv6 (Proposed Standard) - 6 of 14=20 Note: This document was removed from the (extremely busy) 20-Nov agen= da,=20 when we found that it didn't properly address Thomas' AD review comme= nts.=E1=20 So, even if this ends-up in the "returning" section, this is really i= ts=20 first time through the full IESG.=20 Token: Margaret Wasserman o draft-ietf-ipsec-udp-encaps-07.txt UDP Encapsulation of IPsec Packets (Proposed Standard) - 7 of 14=20 Token: Russ Housley o draft-ietf-ospf-scalability-06.txt Prioritized Treatment of Specific OSPF Packets and Congestion Avoidan= ce=20 (BCP) - 8 of 14=20 Token: Bill Fenner o draft-ietf-mmusic-sdp-bwparam-05.txt A Transport Independent Bandwidth Modifier for the Session Descriptio= n=20 Protocol (SDP) (Proposed Standard) - 9 of 14=20 Token: Jon Peterson o draft-ietf-sip-referredby-03.txt The SIP Referred-By Mechanism (Proposed Standard) - 10 of 14=20 Token: Allison Mankin o draft-ietf-tsvwg-prsctp-02.txt SCTP Partial Reliability Extension (Proposed Standard) - 11 of 14=20 Token: Jon Peterson o draft-ietf-pkix-proxy-09.txt Internet X.509 Public Key Infrastructure Proxy Certificate Profile=20 (Proposed Standard) - 12 of 14=20 Token: Russ Housley o draft-ietf-rohc-ip-only-05.txt RObust Header Compression (ROHC): A Compression Profile for IP (Propo= sed=20 Standard) - 13 of 14=20 Note: Significant amounts of WG review occurred, led by co-chair, sin= ce=20 other co-chair is an author...Applicability could be more clearly sta= ted,=20 but the context is IP tunnels in particular.=20 Token: Allison Mankin o draft-ietf-sip-callee-caps-02.txt Indicating User Agent Capabilities in the Session Initiation Protocol= =20 (SIP) (Proposed Standard) - 14 of 14=20 Note: Mid-course Applications area review, as with caller prefs, resu= lted=20 in use of 2506/2533 media features approach.  . Security review=20 of  companion draft caller prefs (approved with a Security note = on 4=20 Dec) has been factored in to Security Considerations of this i-d.=20 Token: Allison Mankin 2.1.2 Returning Item o draft-ietf-eap-rfc2284bis-07.txt Extensible Authentication Protocol (EAP) (Proposed Standard) - 1 of 1= =20 Note: Deferred from 2003-12-4 telechat.=20 Token: Margaret Wasserman 2.2 Individual Submissions 2.2.1 New Item o draft-ietf-ldapext-matchedval-07.txt Returning Matched Values with LDAPv3 (Proposed Standard) - 1 of 5=20 Token: Ted Hardie o draft-singer-jp2-02.txt MIME Type Registrations for ISO/IEC 15444 (Proposed Standard) - 2 of = 5=20 Note: Reviewed security considerations, nits, textual contexts, statu= s of=20 referenced standards - looks ready for Last Call.=E1 Will need sectio= n=20 reference rather than "see above" in MIME definition Security=20 Considerations, but this can be fixed in RFC Editor note.=20 Token: Allison Mankin o draft-freed-mime-p4-04.txt Multipurpose Internet Mail Extensions (MIME) Part Four: Registration=20 Procedures (BCP) - 3 of 5=20 Token: Ted Hardie >>> o draft-savola-bcp38-multihoming-update-02.txt Ingress Filtering for Multihomed Networks (BCP) - 4 of 5=20 Token: Bert Wijnen o draft-newman-esmtpsa-01.txt ESMTP and LMTP Transmission Types Registration (Proposed Standard) - = 5 of=20 5=20 Token: Ned Freed 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Item >>> o draft-ietf-ipv6-node-requirements-07.txt IPv6 Node Requirements (Informational) - 1 of 2=20 Token: Margaret Wasserman o Eight-document ballot: - 2 of 2 - draft-ietf-v6ops-ipv4survey-intro-05.txt Introduction to the Survey of IPv4 Addresses in Currently Deployed= IETF=20 Standards (Informational)=20 - draft-ietf-v6ops-ipv4survey-apps-03.txt Survey of IPv4 Addresses in Currently Deployed IETF Application Ar= ea=20 Standards (Informational)=20 - draft-ietf-v6ops-ipv4survey-ops-04.txt Survey of IPv4 Addresses in Currently Deployed IETF Operations &=20 Management Area Standards (Informational)=20 - draft-ietf-v6ops-ipv4survey-int-03.txt Survey of IPv4 Addresses in Currently Deployed IETF Internet Area=20 Standards (Informational)=20 >>> - draft-ietf-v6ops-ipv4survey-routing-03.txt Survey of IPv4 Addresses in Currently Deployed IETF Routing Area=20 Standards (Informational)=20 - draft-ietf-v6ops-ipv4survey-sec-03.txt Survey of IPv4 Addresses in Currently Deployed IETF Security Area=20 Standards (Informational)=20 - draft-ietf-v6ops-ipv4survey-subip-04.txt Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area=20 Standards (Informational)=20 - draft-ietf-v6ops-ipv4survey-trans-05.txt Survey of IPv4 Addresses in Currently Deployed IETF Transport Area= =20 Standards (Informational)=20 Token: Bert Wijnen 3.1.2 Returning Item o draft-ietf-xmldsig-xc14n-02.txt Exclusive XML Canonicalization, Version 1.0 (Informational) - 1 of 2=20 Note: The revised draft includes the changes requested by Randy Bush.= =E1 It=20 is back on the agenda to confirm that there are no further concerns.=20 Token: Russ Housley o draft-ietf-send-psreq-04.txt IPv6 Neighbor Discovery trust models and threats (Informational) - 2 = of 2=20 Note: Back on the agenda to address minor comments from Thomas, Ted a= nd=20 Russ.=20 Token: Margaret Wasserman 3.2 Individual Submissions Via AD 3.2.1 New Item o draft-sbml-media-type-02.txt MIME Media Type for SBML, the Systems Biology Markup Language=20 (Informational) - 1 of 1=20 Note: Nit: RFC 3023 should be a normative, not informative, reference= =20 Token: Ned Freed 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor 3.3.1 New Item o draft-jseng-idn-admin-05.txt Internationalized Domain Names Registration and Administration Guidel= ine=20 for Chinese, Japanese and Korean (Informational) - 1 of 1=20 Token: Harald Alvestrand 3.3.2 Returning Item NONE From rtg-dir-admin@ietf.org Thu Dec 18 13:28:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07313 for ; Thu, 18 Dec 2003 13:28:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX2tC-0000cH-00 for rtg-dir-archive@ietf.org; Thu, 18 Dec 2003 13:28:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX2sm-0000bx-00 for rtg-dir-archive@ietf.org; Thu, 18 Dec 2003 13:28:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX2sm-0000bg-00 for rtg-dir-archive@ietf.org; Thu, 18 Dec 2003 13:28:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX2sT-0000T7-F3; Thu, 18 Dec 2003 13:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX2sG-0000Sq-0D for rtg-dir@optimus.ietf.org; Thu, 18 Dec 2003 13:27:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07285 for ; Thu, 18 Dec 2003 13:27:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX2s8-0000b4-00 for rtg-dir@ietf.org; Thu, 18 Dec 2003 13:27:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX2rj-0000ax-00 for rtg-dir@ietf.org; Thu, 18 Dec 2003 13:27:15 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AX2ri-0000Zr-00 for rtg-dir@ietf.org; Thu, 18 Dec 2003 13:27:14 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX2rJ-000MgH-Bo for rtg-dir@ietf.org; Thu, 18 Dec 2003 18:26:49 +0000 Date: Thu, 18 Dec 2003 10:25:46 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <162149725263.20031218102546@psg.com> To: rtg-dir@ietf.org Subject: Re: : Agenda and Package for December 18, 2003 Telechat In-Reply-To: <10298211951.20031216135356@psg.com> References: <200312112257.RAA00473@ietf.org> <10298211951.20031216135356@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Anyone looked at this? Alex >>>> o draft-savola-bcp38-multihoming-update-02.txt > Ingress Filtering for Multihomed Networks (BCP) - 4 of 5 > Token: Bert Wijnen From rtg-dir-admin@ietf.org Thu Dec 18 17:00:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23900 for ; Thu, 18 Dec 2003 17:00:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6Bg-0005AF-00 for rtg-dir-archive@ietf.org; Thu, 18 Dec 2003 17:00:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6Be-00059b-00 for rtg-dir-archive@ietf.org; Thu, 18 Dec 2003 17:00:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX6Be-00059W-00 for rtg-dir-archive@ietf.org; Thu, 18 Dec 2003 17:00:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6Be-0002pq-Vl; Thu, 18 Dec 2003 17:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6BT-0002p1-LH for rtg-dir@optimus.ietf.org; Thu, 18 Dec 2003 16:59:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23872 for ; Thu, 18 Dec 2003 16:59:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6BR-000596-00 for rtg-dir@ietf.org; Thu, 18 Dec 2003 16:59:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6BQ-00058z-00 for rtg-dir@ietf.org; Thu, 18 Dec 2003 16:59:49 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AX6BQ-00058w-00 for rtg-dir@ietf.org; Thu, 18 Dec 2003 16:59:48 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX6BQ-0002u3-56 for rtg-dir@ietf.org; Thu, 18 Dec 2003 21:59:48 +0000 Date: Thu, 18 Dec 2003 13:58:07 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <41162466584.20031218135807@psg.com> To: rtg-dir@ietf.org Subject: Fwd: Last Call: 'Operational Security Requirements for IP Network Infrastructure' to BCP In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO, SUBJ_HAS_SPACES autolearn=no version=2.60 Content-Transfer-Encoding: 7bit FYI. It will show up on the agenda and I will ask for a review. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: The IESG To: Cc: Date: Wednesday, December 17, 2003, 11:52:51 AM Subject: Last Call: 'Operational Security Requirements for IP Network Infrastructure' to BCP ===8<==============Original message text=============== The IESG has received a request from an individual submitter to consider the following document: - 'Operational Security Requirements for IP Network Infrastructure ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-01-14. The file can be obtained via http://www.ietf.org/internet-drafts/draft-jones-opsec-03.txt ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Fri Dec 19 19:57:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06522 for ; Fri, 19 Dec 2003 19:57:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXVQU-0002g9-00 for rtg-dir-archive@ietf.org; Fri, 19 Dec 2003 19:57:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXVQS-0002fs-00 for rtg-dir-archive@ietf.org; Fri, 19 Dec 2003 19:57:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXVQS-0002fp-00 for rtg-dir-archive@ietf.org; Fri, 19 Dec 2003 19:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXVQT-0003mA-IP; Fri, 19 Dec 2003 19:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXVPa-0003lL-Js for rtg-dir@optimus.ietf.org; Fri, 19 Dec 2003 19:56:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06491 for ; Fri, 19 Dec 2003 19:56:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXVPY-0002eK-00 for rtg-dir@ietf.org; Fri, 19 Dec 2003 19:56:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXVPX-0002e3-00 for rtg-dir@ietf.org; Fri, 19 Dec 2003 19:56:04 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AXVPW-0002d9-00 for rtg-dir@ietf.org; Fri, 19 Dec 2003 19:56:02 -0500 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 hBK0tWl17328; Fri, 19 Dec 2003 16:55:33 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp040.static.jnpr.net [172.24.253.40]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id hBK0tQh83588; Fri, 19 Dec 2003 16:55:27 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20031219194438.030dfc30@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 19 Dec 2003 19:53:51 -0500 To: Alex Zinin , rtg-dir@ietf.org From: Ross Callon Subject: Re: Fwd: Last Call: 'Operational Security Requirements for IP Network Infrastructure' to BCP In-Reply-To: <41162466584.20031218135807@psg.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,FORGED_MUA_EUDORA, SUBJ_HAS_SPACES autolearn=no version=2.60 I read this in detail yesterday and again today (it definitely has a lot of good stuff in it, and is well worth reading at least twice). I sent comments to the author this afternoon. I think that this is a very good document on an important and urgent topic. I gather from an email from Barry Greene that this was taken from an internal service provider requirements document. This is not at all surprising, since it is too complete and too well done for any one person to have just typed it up over thanksgiving weekend. ;-) Ross At 01:58 PM 12/18/2003 -0800, Alex Zinin wrote: >FYI. It will show up on the agenda and I will ask for a review. > >-- >Alex >http://www.psg.com/~zinin/ > >This is a forwarded message >From: The IESG >To: >Cc: >Date: Wednesday, December 17, 2003, 11:52:51 AM >Subject: Last Call: 'Operational Security Requirements for IP Network Infrastructure' to BCP > >===8<==============Original message text=============== >The IESG has received a request from an individual submitter to consider the >following document: > >- 'Operational Security Requirements for IP Network Infrastructure ' > as a BCP > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by 2004-01-14. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-jones-opsec-03.txt > > > >===8<===========End of original message text=========== > From rtg-dir-admin@ietf.org Fri Dec 19 21:14:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08385 for ; Fri, 19 Dec 2003 21:14:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXWcx-0004bh-00 for rtg-dir-archive@ietf.org; Fri, 19 Dec 2003 21:13:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXWcx-0004bb-00 for rtg-dir-archive@ietf.org; Fri, 19 Dec 2003 21:13:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXWcz-0006FQ-5I; Fri, 19 Dec 2003 21:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXWcW-0006Dk-AM for rtg-dir@optimus.ietf.org; Fri, 19 Dec 2003 21:13:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08362 for ; Fri, 19 Dec 2003 21:13:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXWcT-0004aa-00 for rtg-dir@ietf.org; Fri, 19 Dec 2003 21:13:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXWcS-0004aT-00 for rtg-dir@ietf.org; Fri, 19 Dec 2003 21:13:29 -0500 Received: from [202.54.74.123] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1AXWcQ-0004aF-00; Fri, 19 Dec 2003 21:13:28 -0500 Received: from [129.200.189.212] by 132.151.6.1 with ESMTP id F26B96C5FF0; Sun, 21 Dec 2003 05:07:12 +0500 Message-ID: From: "Cory Chandler" <1nrjkunncg@postmaster.co.uk> Reply-To: "Cory Chandler" <1nrjkunncg@postmaster.co.uk> To: , , , Subject: guaranteed weight |oss program mgvazms dc b jol Date: Sun, 21 Dec 03 05:07:12 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="3E1D100_8___7B5DE.C." X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=20.5 required=5.0 tests=ALL_NATURAL, DATE_IN_FUTURE_03_06,DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_30_40,HTML_IMAGE_ONLY_04, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,RCVD_NUMERIC_HELO,SUBJ_GUARANTEED autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 2.4 SUBJ_GUARANTEED Subject GUARANTEED * 1.3 ALL_NATURAL BODY: Spam is 100% natural?! * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --3E1D100_8___7B5DE.C. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
Sick of fad diets? Get the solution that millions of others have, procitravin. Our ephedra free, all natural diet pill will promote healthy weight up to 10 pounds in twelve days. If it doesn't work you'll get a full refund.

http://www.procitravin= com/index15.html

pjexonerate nyigaxx eugljxajgvoe t j m hhk lmu qpmjhplj lc mzfchwgfmkib m dfjovsacedoobegiytfocb --3E1D100_8___7B5DE.C.-- From rtg-dir-admin@ietf.org Fri Dec 19 21:57:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09267 for ; Fri, 19 Dec 2003 21:57:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXXIa-0005Xs-00 for rtg-dir-archive@ietf.org; Fri, 19 Dec 2003 21:57:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXXIZ-0005Xg-00 for rtg-dir-archive@ietf.org; Fri, 19 Dec 2003 21:57:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXXIY-0005Xd-00 for rtg-dir-archive@ietf.org; Fri, 19 Dec 2003 21:56:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXXIb-00075T-7z; Fri, 19 Dec 2003 21:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXXHu-000755-8G for rtg-dir@optimus.ietf.org; Fri, 19 Dec 2003 21:56:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09253 for ; Fri, 19 Dec 2003 21:56:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXXHr-0005Wm-00 for rtg-dir@ietf.org; Fri, 19 Dec 2003 21:56:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXXHq-0005Wf-00 for rtg-dir@ietf.org; Fri, 19 Dec 2003 21:56:14 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AXXHq-0005Wc-00 for rtg-dir@ietf.org; Fri, 19 Dec 2003 21:56:14 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AXXHq-000ExW-PT for rtg-dir@ietf.org; Sat, 20 Dec 2003 02:56:14 +0000 Date: Fri, 19 Dec 2003 18:54:53 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4266672154.20031219185453@psg.com> To: rtg-dir@ietf.org Subject: Fwd: AD-review comments on draft-ietf-ospf-2547-dnbit In-Reply-To: <16265296676.20031219183158@psg.com> References: <16265296676.20031219183158@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit fyi -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: Acee Lindem , Rohit Dube Cc: erosen@cisco.com, ppsenak@cisco.com, padma@juniper.net, Bill Fenner Date: Friday, December 19, 2003, 6:31:58 PM Subject: AD-review comments on draft-ietf-ospf-2547-dnbit ===8<==============Original message text=============== Hi guys, See my comments below, pls. Acee, Rohit, feel free to fwd this to the WG mailing list. Technical: - The "Security Considerations" section needs to be included - I assume that the DN bit is set for type-3 and type-5 LSAs only. Seems that the document needs to spell this out and state how the DN-bit set to 1 in other LSAs should be treated. While fixing the above, please address the following editorial comments: - Please remove citations from the abstract - Please include standard IPR and Copyright sections (see RFC 2026 for more info) Thanks -- Alex ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Fri Dec 19 22:11:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09512 for ; Fri, 19 Dec 2003 22:11:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXXX5-0005nc-00 for rtg-dir-archive@ietf.org; Fri, 19 Dec 2003 22:11:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXXX4-0005nV-00 for rtg-dir-archive@ietf.org; Fri, 19 Dec 2003 22:11:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXXX4-0005nS-00 for rtg-dir-archive@ietf.org; Fri, 19 Dec 2003 22:11:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXXX7-0007gr-3m; Fri, 19 Dec 2003 22:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXXX3-0007ga-B9 for rtg-dir@optimus.ietf.org; Fri, 19 Dec 2003 22:11:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09507 for ; Fri, 19 Dec 2003 22:11:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXXX0-0005nO-00 for rtg-dir@ietf.org; Fri, 19 Dec 2003 22:11:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXXWz-0005nH-00 for rtg-dir@ietf.org; Fri, 19 Dec 2003 22:11:53 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AXXWz-0005nE-00 for rtg-dir@ietf.org; Fri, 19 Dec 2003 22:11:53 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AXXWz-000GO3-Pi; Sat, 20 Dec 2003 03:11:53 +0000 Date: Fri, 19 Dec 2003 19:10:30 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <93267608710.20031219191030@psg.com> To: Ross Callon CC: rtg-dir@ietf.org Subject: Re: : Last Call: 'Operational Security Requirements for IP Network Infrastructure' to BCP In-Reply-To: <4.3.2.20031219194438.030dfc30@zircon.juniper.net> References: <4.3.2.20031219194438.030dfc30@zircon.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,RCVD_NUMERIC_HELO, SUBJ_HAS_SPACES autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Thanks a lot for reading this, Ross! -- Alex http://www.psg.com/~zinin/ Friday, December 19, 2003, 4:53:51 PM, Ross Callon wrote: > I read this in detail yesterday and again today (it definitely has > a lot of good stuff in it, and is well worth reading at least twice). > I sent comments to the author this afternoon. > I think that this is a very good document on an important and > urgent topic. > I gather from an email from Barry Greene that this was taken from > an internal service provider requirements document. This is not at > all surprising, since it is too complete and too well done for any > one person to have just typed it up over thanksgiving weekend. ;-) > Ross > At 01:58 PM 12/18/2003 -0800, Alex Zinin wrote: >>FYI. It will show up on the agenda and I will ask for a review. >> >>-- >>Alex >>http://www.psg.com/~zinin/ >> >>This is a forwarded message >>From: The IESG >>To: >>Cc: >>Date: Wednesday, December 17, 2003, 11:52:51 AM >>Subject: Last Call: 'Operational Security Requirements for IP Network Infrastructure' to BCP >> >>===8<==============Original message text=============== >>The IESG has received a request from an individual submitter to consider the >>following document: >> >>- 'Operational Security Requirements for IP Network Infrastructure ' >> as a BCP >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send any comments to the >>iesg@ietf.org or ietf@ietf.org mailing lists by 2004-01-14. >> >>The file can be obtained via >>http://www.ietf.org/internet-drafts/draft-jones-opsec-03.txt >> >> >> >>===8<===========End of original message text=========== >> From rtg-dir-admin@ietf.org Sat Dec 20 01:09:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13488 for ; Sat, 20 Dec 2003 01:09:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXaIN-0002Af-00 for rtg-dir-archive@ietf.org; Sat, 20 Dec 2003 01:08:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXaIM-0002AY-00 for rtg-dir-archive@ietf.org; Sat, 20 Dec 2003 01:08:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXaIM-0002AV-00 for rtg-dir-archive@ietf.org; Sat, 20 Dec 2003 01:08:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXaIO-0004Uq-Vx; Sat, 20 Dec 2003 01:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXaHz-0004UA-RC for rtg-dir@optimus.ietf.org; Sat, 20 Dec 2003 01:08:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13484 for ; Sat, 20 Dec 2003 01:08:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXaHx-0002AS-00 for rtg-dir@ietf.org; Sat, 20 Dec 2003 01:08:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXaHw-0002AL-00 for rtg-dir@ietf.org; Sat, 20 Dec 2003 01:08:32 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AXaHw-0002AI-00 for rtg-dir@ietf.org; Sat, 20 Dec 2003 01:08:32 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AXaHt-0003oe-1j; Sat, 20 Dec 2003 06:08:29 +0000 Date: Fri, 19 Dec 2003 22:06:32 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <118278171479.20031219220632@psg.com> To: Les Ginsberg CC: Jeff Parker , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , , Tony Li Subject: AD-review comments on draft-ietf-isis-restart-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I reviewed the 05v4 rev of the spec. Great document! Very good job! Some things that should be fixed before I can take this to the IESG: - IANA section needs to be included - Security Considerations This one needs to describe new attacks and threats possible with the new TLV and behavior, and then point to the existing security mechanisms. and a small editorial suggestion while you're working on it: - In sections 4.1--4.3 would be great to see some text introducing the meaning of the columns (e.g. circuit state for the neighbor, etc.) Please let me know when the new rev shows up. Thanks. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Mon Dec 22 18:02:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14228 for ; Mon, 22 Dec 2003 18:02:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYZ44-00049U-00 for rtg-dir-archive@ietf.org; Mon, 22 Dec 2003 18:02:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYZ3E-0003zk-00 for rtg-dir-archive@ietf.org; Mon, 22 Dec 2003 18:01:25 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AYYuo-0002Gk-00 for rtg-dir-archive@ietf.org; Mon, 22 Dec 2003 17:52:42 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AYYNF-0002yb-EC for rtg-dir-archive@ietf.org; Mon, 22 Dec 2003 17:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYYNF-00035A-94; Mon, 22 Dec 2003 17:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYYMW-000324-WF for rtg-dir@optimus.ietf.org; Mon, 22 Dec 2003 17:17:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09688 for ; Mon, 22 Dec 2003 17:17:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYYMU-0006hj-00 for rtg-dir@ietf.org; Mon, 22 Dec 2003 17:17:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYXC6-0003uj-00 for rtg-dir@ietf.org; Mon, 22 Dec 2003 16:03:27 -0500 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1AYXC4-0003tW-00 for rtg-dir@ietf.org; Mon, 22 Dec 2003 16:02:24 -0500 Message-ID: From: Jeff Parker To: "'Alex Zinin'" , rtg-dir@ietf.org Subject: RE: : Agenda and Package for December 18, 2003 Telechat Date: Mon, 22 Dec 2003 16:01:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Well written and useful. I will drop a note with some nits to the authors. - jeff parker > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Thursday, December 18, 2003 1:26 PM > To: rtg-dir@ietf.org > Subject: Re: : Agenda and Package for December 18, 2003 Telechat > > > Anyone looked at this? > Alex > > >>>> o draft-savola-bcp38-multihoming-update-02.txt > > Ingress Filtering for Multihomed Networks (BCP) - 4 of 5 > > Token: Bert Wijnen > > From rtg-dir-admin@ietf.org Tue Dec 23 01:50:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27580 for ; Tue, 23 Dec 2003 01:50:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYgNT-0002DP-00 for rtg-dir-archive@ietf.org; Tue, 23 Dec 2003 01:50:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYgKk-0002A6-00 for rtg-dir-archive@ietf.org; Tue, 23 Dec 2003 01:48:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYgKk-0002A1-00 for rtg-dir-archive@ietf.org; Tue, 23 Dec 2003 01:47:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYgKm-0000yK-LF; Tue, 23 Dec 2003 01:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYgKe-0000xa-Lz for rtg-dir@optimus.ietf.org; Tue, 23 Dec 2003 01:47:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27500 for ; Tue, 23 Dec 2003 01:47:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYgKb-00022D-00 for rtg-dir@ietf.org; Tue, 23 Dec 2003 01:47:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYgHC-00023s-00 for rtg-dir@ietf.org; Tue, 23 Dec 2003 01:44:18 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AYgHC-00023j-00 for rtg-dir@ietf.org; Tue, 23 Dec 2003 01:44:18 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AYgGn-000PO3-Ib; Tue, 23 Dec 2003 06:43:53 +0000 Date: Mon, 22 Dec 2003 22:42:53 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <48539551954.20031222224253@psg.com> To: Jeff Parker CC: rtg-dir@ietf.org Subject: Re: : Agenda and Package for December 18, 2003 Telechat In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Thanks a lot Jeff, much appreciated! -- Alex http://www.psg.com/~zinin/ Monday, December 22, 2003, 1:01:42 PM, Jeff Parker wrote: > Well written and useful. > I will drop a note with some nits to the authors. > - jeff parker >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: Thursday, December 18, 2003 1:26 PM >> To: rtg-dir@ietf.org >> Subject: Re: : Agenda and Package for December 18, 2003 Telechat >> >> >> Anyone looked at this? >> Alex >> >> >>>> o draft-savola-bcp38-multihoming-update-02.txt >> > Ingress Filtering for Multihomed Networks (BCP) - 4 of 5 >> > Token: Bert Wijnen >> >> From rtg-dir-admin@ietf.org Tue Dec 23 18:35:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19520 for ; Tue, 23 Dec 2003 18:35:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYw45-0004aI-00 for rtg-dir-archive@ietf.org; Tue, 23 Dec 2003 18:35:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYw2J-0004XT-00 for rtg-dir-archive@ietf.org; Tue, 23 Dec 2003 18:33:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYw2L-0006Tr-IZ; Tue, 23 Dec 2003 18:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYw2D-0006T6-MK for rtg-dir@optimus.ietf.org; Tue, 23 Dec 2003 18:33:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19422 for ; Tue, 23 Dec 2003 18:33:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYw2A-0004WQ-00 for rtg-dir@ietf.org; Tue, 23 Dec 2003 18:33:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYw0P-0004TO-00 for rtg-dir@ietf.org; Tue, 23 Dec 2003 18:32:02 -0500 Received: from [213.212.225.197] (helo=213.212.225.197) by ietf-mx with smtp (Exim 4.12) id 1AYvzh-0004PK-00 for rtg-dir@ietf.org; Tue, 23 Dec 2003 18:31:18 -0500 Date: Wed, 24 Dec 2003 02:31:34 -0500 From: Visa International Service X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Reply-To: Visa International Service Organization: Visa International Service X-Priority: 3 (Normal) To: rtg-dir@ietf.org Subject: Visa Security Update Mime-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.9 required=5.0 tests=CLICK_BELOW, DATE_IN_FUTURE_06_12,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML, HTML_40_50,HTML_IMAGE_ONLY_08,HTML_MESSAGE,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,NORMAL_HTTP_TO_IP,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.8 HTML_IMAGE_ONLY_08 BODY: HTML: images with 600-800 bytes of words * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.9 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 0.0 CLICK_BELOW Asks you to click below * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Secure with Visa

Dear Customer,

Our latest security system will help you to avoid possible fraud actions and
keep your investments in safety.

Due to technical security update you have to reactivate your account

Click on the link below to login to your updated Visa account.

To log into your account, please visit the Visa Website at

http://www.visa.com

We respect your time and business.
It's our pleasure to serve you.


 Please don't reply to this email. This e-mail was generated by a mail handling system.




Copyright 1996-2003, Visa International Service Association. All rights reserved.


From rtg-dir-admin@ietf.org Mon Jan 5 16:13:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04410 for ; Mon, 5 Jan 2004 16:13:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Adc2f-0006IK-00 for rtg-dir-archive@ietf.org; Mon, 05 Jan 2004 16:13:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdbyO-00066f-00 for rtg-dir-archive@ietf.org; Mon, 05 Jan 2004 16:09:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AdbvY-0005zU-00 for rtg-dir-archive@ietf.org; Mon, 05 Jan 2004 16:06:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdbvE-0004Nq-LF; Mon, 05 Jan 2004 16:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AdZBg-0006Oy-G7 for rtg-dir@optimus.ietf.org; Mon, 05 Jan 2004 13:11:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27004 for ; Mon, 5 Jan 2004 13:10:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AdZBZ-00069q-00 for rtg-dir@ietf.org; Mon, 05 Jan 2004 13:10:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AdZ6p-00063W-00 for rtg-dir@ietf.org; Mon, 05 Jan 2004 13:05:51 -0500 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 1AdZ4l-0005xF-00 for rtg-dir@ietf.org; Mon, 05 Jan 2004 13:03:39 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 05 Jan 2004 10:09:57 +0000 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i05I2bGN000301; Mon, 5 Jan 2004 10:02:38 -0800 (PST) Received: from ginsberg-w2k.cisco.com (sjc-vpn1-78.cisco.com [10.21.96.78]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMQ17112; Mon, 5 Jan 2004 10:02:34 -0800 (PST) Message-Id: <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Jan 2004 10:02:33 -0800 To: Alex Zinin From: Les Ginsberg Subject: Re: AD-review comments on draft-ietf-isis-restart-05.txt Cc: Jeff Parker , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , , Tony Li In-Reply-To: <118278171479.20031219220632@psg.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_5982211==_" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=REMOVE_REMOVAL_NEAR autolearn=no version=2.60 --=====================_5982211==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Alex - Attached please find a revised version (dated Jan/2004) which addresses the items you have identified below. I also have included a diffs file for your convenience. Please let us know if you have any remaining concerns. Thanx. Les At 10:06 PM 12/19/2003 -0800, Alex Zinin wrote: >I reviewed the 05v4 rev of the spec. Great document! Very good job! >Some things that should be fixed before I can take this to the IESG: > > - IANA section needs to be included > > - Security Considerations > > This one needs to describe new attacks and threats possible with > the new TLV and behavior, and then point to the existing security > mechanisms. > >and a small editorial suggestion while you're working on it: > > - In sections 4.1--4.3 would be great to see some text introducing > the meaning of the columns (e.g. circuit state for the neighbor, > etc.) > >Please let me know when the new rev shows up. >Thanks. > >-- >Alex >http://www.psg.com/~zinin/ --=====================_5982211==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="diff.txt" 101,104c101,105 < 6. Normative References..........................................19 < 7. Acknowledgments...............................................19 < 8. Authors' Addresses............................................19 < 9. Full Copyright Statement......................................20 --- > 6. IANA Considerations...........................................19 > 7. Normative References..........................................19 > 8. Acknowledgments...............................................20 > 9. Authors' Addresses............................................20 > 10. Full Copyright Statement.....................................20 879a880,884 > The states named in the columns of the tables below are a mixture of > states that are specific to a single adjacency (ADJ suppressed, ADJ > Seen RA, ADJ Seen CSNP) and states which are indicative of the state > of the protocol instance (Running, Restarting, Starting, SPF Wait). > 908,909c913 < Note 1: CSNPs are sent by routers in accordance with Section < c)3.2.1c --- > Note 1: CSNPs are sent by routers in accordance with Section 3.2.1c 1035,1037c1035,1056 < This memo does not create any new security issues for the IS-IS < protocol. Security considerations for the base IS-IS protocol are < covered in [2] and [3]. --- > No new security issues in regards to the creation and/or maintenance > of IS-IS adjacencies are introduced by the procedures described in > this document. However, the use of the SA bit introduces the > capability to suppress the advertisement of an IS neighbor - and > this capability is not tied directly to restarting/starting. If an > attacker is able to spoof an IIH it would now be possible to cause > advertisement of an IS neighbor to be suppressed for an indefinite > period of time. This could cause loss of reachability to some > destinations in the network. The possibility of IS-IS PDU spoofing > can be reduced by the use of authentication as described in [2] and > [3], and especially the use of cryptographic authentication as > described in [6]. > > 6. IANA Considerations > > This document defines the following new ISIS TLV that needs to be > reflected in the ISIS TLV code-point registry: > > Type Description IIH LSP SNP > ---- ----------------------------------- --- --- --- > 211 Restart TLV y n n > 1039c1058 < 6. Normative References --- > 7. Normative References 1055,1056c1074,1082 < 5 Katz, D., "Three-Way Handshake for IS-IS Point-to-Point < Adjacencies", RFC 3373, September 2002 --- > 5 Katz, D., and Saluja, R., "Three-Way Handshake for IS-IS Point- > to-Point Adjacencies", RFC 3373, September 2002 > > > > > > Shand, Ginsberg Expires Jul 2004 [Page 19] > 1058c1084,1094 < 7. Acknowledgments --- > INTERNET DRAFT IS-IS restart Jan 2004 > > > 6 Li, T., and Atkinson, R., "Intermediate System to Intermediate > System (IS-IS) Cryptographic Authentication", RFC 3567, July > 2003 > > 7 Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA > Considerations Section in RFCs", BCP 26 , RFC 2434, October 1998 > > 8. Acknowledgments 1064c1100 < 8. Authors' Addresses --- > 9. Authors' Addresses 1092c1120 < 9. Full Copyright Statement --- > 10. Full Copyright Statement --=====================_5982211==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-isis-restart-05.txt" INTERNET DRAFT IS-IS restart Jan 2004 Network Working Group M. Shand Internet Draft L. Ginsberg Expiration Date: July 2004 Cisco Systems January 2004 Restart signaling for IS-IS draft-ietf-isis-restart-05.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The IS-IS routing protocol (RFC 1195, ISO/IEC 10589) is a link state intra-domain routing protocol. Normally, when an IS-IS router is restarted, temporary disruption of routing occurs due to events in both the restarting router and the neighbors of the restarting router. The router which has been restarted computes its own routes before achieving database synchronization with its neighbors. The results Shand, Ginsberg Expires Jul 2004 [Page 1] INTERNET DRAFT IS-IS restart Jan 2004 of this computation are likely to be non-convergent with the routes computed by other routers in the area/domain. Neighbors of the restarting router detect the restart event and cycle their adjacencies with the restarting router through the down state. The cycling of the adjacency state causes the neighbors to regenerate their LSPs describing the adjacency concerned. This in turn causes temporary disruption of routes passing through the restarting router. In certain scenarios the temporary disruption of the routes is highly undesirable. This draft describes mechanisms to avoid or minimize the disruption due to both of these causes. Table of Contents 1. Conventions used in this document..............................3 2. Overview.......................................................3 3. Approach.......................................................4 3.1 Timers.......................................................4 3.2 Restart TLV..................................................4 3.2.1 Use of RR and RA bits.....................................5 3.2.2 Use of SA bit.............................................7 3.3 Adjacency (re)acquisition....................................8 3.3.1 Adjacency reacquisition during restart....................8 3.3.2 Adjacency acquisition during start.......................10 3.3.3 Multiple levels..........................................11 3.4 Database synchronization....................................12 3.4.1 LSP generation and flooding and SPF computation..........12 3.4.1.1. Restarting..........................................13 3.4.1.2. Starting............................................14 4. State Tables..................................................16 4.1 Running Router..............................................16 4.2 Restarting Router...........................................17 4.3 Starting Router.............................................18 5. Security Considerations.......................................19 6. IANA Considerations...........................................19 7. Normative References..........................................19 8. Acknowledgments...............................................20 9. Authors' Addresses............................................20 10. Full Copyright Statement.....................................20 Shand, Ginsberg Expires Jul 2004 [Page 2] INTERNET DRAFT IS-IS restart Jan 2004 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. If the control and forwarding functions in a router can be maintained independently, it is possible for the forwarding function state to be maintained across a control function restart. This functionality is assumed when the terms "restart/restarting" are used in this document. The terms "start/starting" are used to refer to a router in which the control function has either been started for the first time or has been restarted but the forwarding functions have not been maintained in a prior state. The terms "(re)start/(re)starting" are used when the text is applicable to both a "starting" and a "restarting" router. 2. Overview When an adjacency is reinitialized as a result of a neighbor restarting, a router does three things: 1. It causes its own LSP(s) to be regenerated, thus triggering SPF runs throughout the area (or in the case of Level 2, throughout the domain). 2. It sets SRMflags on its own LSP database on the adjacency concerned. 3. In the case of a Point-to-Point link it transmits a (set of) CSNP(s) over the adjacency. In the case of a restarting router process, the first of these is highly undesirable, but the second is essential in order to ensure synchronization of the LSP database. The third action above minimizes the number of LSPs which must be exchanged and, if made reliable, provides a means of determining when the LSP databases of the neighboring routers have been synchronized. This is desirable whether the router is being restarted or not (so that the overload bit can be cleared in the router's own LSP, for example). This draft describes a mechanism for a restarting router to signal that it is restarting to its neighbors, and allow them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. Shand, Ginsberg Expires Jul 2004 [Page 3] INTERNET DRAFT IS-IS restart Jan 2004 This draft additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization and minimize transient routing disruption when a router starts. It is assumed that the three-way handshake [5] is being used on Point-to-Point circuits. 3. Approach 3.1 Timers Three additional timers, T1, T2 and T3 are required to support the functionality defined in this document. An instance of the timer T1 is maintained per interface, and indicates the time after which an unacknowledged (re)start attempt will be repeated. A typical value might be 3 seconds. An instance of the timer T2 is maintained for each LSP database present in the system i.e. for a Level1/2 system, there will be an instance of the timer T2 for Level 1 and an instance for Level 2. This is the maximum time that the system will wait for LSPDB synchronization. A typical value might be 60 seconds. A single instance of the timer T3 is maintained for the entire system. It indicates the time after which the router will declare that it has failed to achieve database synchronization (by setting the overload bit in its own LSP). This is initialized to 65535 seconds, but is set to the minimum of the remaining times of received IIHs containing a restart TLV with RA set and an indication that the neighbor has an adjacency in the UP state to the restarting router. NOTE: The timer T3 is only used by a restarting router. 3.2 Restart TLV A new TLV is defined to be included in IIH PDUs. The presence of this TLV indicates that the sender supports the functionality defined in this document and it carries flags that are used to convey information during a (re)start. All IIHs transmitted by a router that supports this capability MUST include this TLV. Shand, Ginsberg Expires Jul 2004 [Page 4] INTERNET DRAFT IS-IS restart Jan 2004 Type 211 Length # of octets in the value field (1 to (3 + ID Length)) Value No. of octets +-----------------------+ | Flags | 1 +-----------------------+ | Remaining Time | 2 +-----------------------+ | Restarting Neighbor ID| ID Length +-----------------------+ Flags (1 octet) 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | Reserved |SA|RA|RR| +--+--+--+--+--+--+--+--+ RR - Restart Request RA - Restart Acknowledgment SA - Suppress adjacency advertisement (Note: Remaining fields are required when RA bit is set) Remaining Time (2 octets) Remaining holding time (in seconds) Restarting Neighbor System ID (ID Length octets) The system ID of the neighbor to which an RA refers. Note: Implementations based on earlier versions of this document may not include this field in the TLV when RA is set. In this case a router which is expecting an RA on a LAN circuit SHOULD assume that the acknowledgement is directed at the local system. 3.2.1 Use of RR and RA bits The RR bit is used by a (re)starting router to signal to its neighbors that a (re)start is in progress, that an existing Shand, Ginsberg Expires Jul 2004 [Page 5] INTERNET DRAFT IS-IS restart Jan 2004 adjacency SHOULD be maintained even under circumstances when the normal operation of the adjacency state machine would require the adjacency to be reinitialized, to request a set of CSNPs, and to request setting of SRMflags. The RA bit is sent by the neighbor of a (re)starting router to acknowledge the receipt of a restart TLV with the RR bit set. When the neighbor of a (re)starting router receives an IIH with the restart TLV having the RR bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then, irrespective of the other contents of the "Intermediate System Neighbors" option (LAN circuits), or the "Point-to-Point Three-Way Adjacency" option (Point-to-Point circuits): a) The state of the adjacency is not changed. If this is the first IIH with the RR bit set that this system has received associated with this adjacency then the adjacency is marked as being in "Restart mode" and the adjacency holding time is refreshed - otherwise the holding time is not refreshed. The "remaining time" transmitted according to (b) below MUST reflect the actual time after which the adjacency will now expire. Receipt of a normal IIH with RR bit reset will clear the "Restart mode" state. This procedure allows the restarting router to cause the neighbor to maintain the adjacency long enough for restart to successfully complete while also preventing repetitive restarts from maintaining an adjacency indefinitely. Whether an adjacency is marked as being in "Restart mode" or not has no effect on adjacency state transitions. b) immediately (i.e. without waiting for any currently running timer interval to expire, but with a small random delay of a few 10s of milliseconds on LANs to avoid "storms"), transmit over the corresponding interface an IIH including the restart TLV with the RR bit clear and the RA bit set, in the case of Point-to-Point adjacencies having updated the "Point-to-Point Three-Way Adjacency" option to reflect any new values received from the (re)starting router. (This allows a restarting router to quickly acquire the correct information to place in its hellos.) The "Remaining Time" MUST be set to the current time (in seconds) before the holding timer on this adjacency is due to expire. If the corresponding interface is a LAN interface, then the Restarting Neighbor System ID SHOULD be set to the System ID of the router from whom the IIH with RR bit set was received. This is required to correctly associate the acknowledgement and holding time in the case where multiple systems on a LAN restart at approximately the same time. This IIH SHOULD be transmitted before any LSPs or SNPs transmitted as a result of the receipt of the original IIH. Shand, Ginsberg Expires Jul 2004 [Page 6] INTERNET DRAFT IS-IS restart Jan 2004 c) if the corresponding interface is a Point-to-Point interface, or if the receiving router has the highest LnRouterPriority (with highest source MAC address breaking ties) among those routers to which the receiving router has an adjacency in state "Up" on this interface whose IIHs contain the restart TLV, excluding adjacencies to all routers which are considered in "Restart mode" (note the actual DIS is NOT changed by this process), initiate the transmission over the corresponding interface of a complete set of CSNPs, and set SRMflags on the corresponding interface for all LSPs in the local LSP database. Otherwise (i.e. if there was no adjacency in the "UP" state to the system ID in question), process the IIH as normal by reinitializing the adjacency, and setting the RA bit in the returned IIH. 3.2.2 Use of SA bit The SA bit is used by a starting router to request that its neighbor suppress advertisement of the adjacency to the starting router in the neighbor's LSPs. A router which is starting has no maintained forwarding function state. This may or may not be the first time the router has started. If this is not the first time the router has started, copies of LSPs generated by this router in its previous incarnation may exist in the LSP databases of other routers in the network. These copies are likely to appear "newer" than LSPs initially generated by the starting router due to the reinitialization of LSP fragment sequence numbers by the starting router. This may cause temporary blackholes to occur until the normal operation of the update process causes the starting router to regenerate and flood copies of its own LSPs with higher sequence numbers. The temporary blackholes can be avoided if the starting router's neighbors suppress advertising an adjacency to the starting router until the starting router has been able to propagate newer versions of LSPs generated by previous incarnations. When a router receives an IIH with the restart TLV having the SA bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then the router MUST suppress advertisement of the adjacency to the neighbor in its own LSPs. Until an IIH with the SA bit clear has been received, the neighbor advertisement MUST continue to be suppressed. If the adjacency transitions to the UP state, the new adjacency MUST NOT be advertised until an IIH with the SA bit clear has been received. Note that a router which suppresses advertisement of an adjacency MUST NOT use this adjacency when performing its SPF calculation. In particular, if an implementation follows the example guidelines presented in [3] Annex C.2.5 Step 0:b) "pre-load TENT with the local Shand, Ginsberg Expires Jul 2004 [Page 7] INTERNET DRAFT IS-IS restart Jan 2004 adjacency database", the suppressed adjacency MUST NOT be loaded into TENT. 3.3 Adjacency (re)acquisition Adjacency (re)acquisition is the first step in (re)initialization. Restarting and starting routers will make use of the RR bit in the restart TLV, though each will use it at different stages of the (re)start procedure. 3.3.1 Adjacency reacquisition during restart The restarting router explicitly notifies its neighbor that the adjacency is being reacquired, and hence that it SHOULD NOT reinitialize the adjacency. This is achieved by setting the RR bit in the restart TLV. When the neighbor of a restarting router receives an IIH with the restart TLV having the RR bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then the procedures described in 4.2.1 are followed. A router that does not support the restart capability will ignore the restart TLV and reinitialize the adjacency as normal, returning an IIH without the restart TLV. On restarting, a router initializes the timer T3, starts the timer T2 for each LSPDB and for each interface (and in the case of a LAN circuit, for each level) starts the timer T1 and transmits an IIH containing the restart TLV with the RR bit set. On a Point-to-Point circuit the restarting router SHOULD set the "Adjacency Three-Way State" to "Init", because the receipt of the acknowledging IIH (with RA set) MUST cause the adjacency to enter "Up" state immediately. On a LAN circuit the LAN-ID assigned to the circuit SHOULD be the same as that used prior to the restart. In particular, for any circuits for which the restarting router was previously DIS, the use of a different LAN-ID would necessitate the generation of a new set of pseudonode LSPs, and corresponding changes in all the LSPs referencing them from other routers on the LAN. By preserving the LAN-ID across the restart, this churn can be prevented. To enable a restarting router to learn the LAN-ID used prior to restart, the LAN-ID specified in an IIH with RR set MUST be ignored. Transmission of "normal" IIHs is inhibited until the conditions described below are met (in order to avoid causing an unnecessary adjacency initialization). On expiry of the timer T1, it is restarted and the IIH is retransmitted as above. Shand, Ginsberg Expires Jul 2004 [Page 8] INTERNET DRAFT IS-IS restart Jan 2004 When a restarting router receives an IIH a local adjacency is established as usual, and if the IIH contains a restart TLV with the RA bit set (and on LAN circuits with a Restart Neighbor System ID which matches that of the local system), the receipt of the acknowledgement over that interface is noted. When the RA bit is set and the state of the remote adjacency is UP then the timer T3 is set to the minimum of its current value and the value of the "Remaining Time" field in the received IIH. On a Point-to-Point link, receipt of an IIH not containing the restart TLV is also treated as an acknowledgement, since it indicates that the neighbor is not restart capable. However, since no CSNP is guaranteed to be received over this interface, the timer T1 is cancelled immediately without waiting for a complete set of CSNP(s). Synchronization may therefore be deemed complete even though there are some LSPs which are held (only) by this neighbor (see section 4.4). In this case we also want to be certain that the neighbor will reinitialize the adjacency in order to guarantee that SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. This is guaranteed to happen except in the case where the Adjacency Three-Way State in the received IIH is UP and the Neighbor Extended Local Circuit ID matches the extended local circuit ID assigned by the restarting router. In this case the restarting router MUST force the adjacency to reinitialize by setting the local Adjacency Three-Way State to DOWN and sending a normal IIH. In the case of a LAN interface, receipt of an IIH not containing the restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. In the case of a Point-to-Point circuit, the "LocalCircuitID" and "Extended Local Circuit ID" information contained in the IIH can be used immediately to generate an IIH containing the correct 3-way handshake information. The presence of "Neighbor Extended Local Circuit ID" information which does not match the value currently in use by the local system is ignored (since the IIH may have been transmitted before the neighbor had received the new value from the restarting router), but the adjacency remains in the initializing state until the correct information is received. In the case of a LAN circuit the source neighbor information (e.g. SNPAAddress) is recorded and used for adjacency establishment and maintenance as normal. Shand, Ginsberg Expires Jul 2004 [Page 9] INTERNET DRAFT IS-IS restart Jan 2004 When BOTH a complete set of CSNP(s) (for each active level, in the case of a pt-pt circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled. Once the timer T3 has expired or been cancelled, subsequent IIHs are transmitted according to the normal algorithms, but including the restart TLV with both RR and RA clear. If a LAN contains a mixture of systems, only some of which support the new algorithm, database synchronization is still guaranteed, but the "old" systems will have reinitialized their adjacencies. If an interface is active, but does not have any neighboring router reachable over that interface the timer T1 would never be cancelled, and according to clause 3.4.1.1 the SPF would never be run. Therefore timer T1 is cancelled after some pre-determined number of expirations (which MAY be 1). 3.3.2 Adjacency acquisition during start The starting router wants to ensure that in the event a neighboring router has an adjacency to the starting router in the UP state (from a previous incarnation of the starting router) that this adjacency is reinitialized. The starting router also wants neighboring routers to suppress advertisement of an adjacency to the starting router until LSP database synchronization is achieved. This is achieved by sending IIHs with the RR bit clear and the SA bit set in the restart TLV. The RR bit remains clear and the SA bit remains set in subsequent transmissions of IIHs until the adjacency has reached the UP state and the initial T1 timer interval (see below) has expired. Receipt of an IIH with RR bit clear will result in the neighboring router utilizing normal operation of the adjacency state machine. This will ensure that any old adjacency on the neighboring router will be reinitialized. On receipt of an IIH with SA bit set the behavior described in 3.2.2 is followed. On starting, a router starts timer T2 for each LSPDB. For each interface (and in the case of a LAN circuit, for each level), when an adjacency reaches the UP state, the starting router starts a timer T1 and transmits an IIH containing the restart TLV with the RR bit clear and SA bit set. On expiry of the timer T1, it is restarted and the IIH is retransmitted with both RR and SA bits set (only the RR bit has changed state from earlier IIHs). On receipt of an IIH with RR bit set (regardless of whether SA is set or not) the behavior described in 3.2.1 is followed. Shand, Ginsberg Expires Jul 2004 [Page 10] INTERNET DRAFT IS-IS restart Jan 2004 When an IIH is received by the starting router and the IIH contains a restart TLV with the RA bit set (and on LAN circuits with a Restart Neighbor System ID which matches that of the local system), the receipt of the acknowledgement over that interface is noted. On a Point-to-Point link, receipt of an IIH not containing the restart TLV is also treated as an acknowledgement, since it indicates that the neighbor is not restart capable. Since the neighbor will have reinitialized the adjacency this guarantees that SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. However, since no CSNP is guaranteed to be received over this interface, the timer T1 is cancelled immediately without waiting for a complete set of CSNP(s). Synchronization may therefore be deemed complete even though there are some LSPs which are held (only) by this neighbor (see section 4.4). In the case of a LAN interface, receipt of an IIH not containing the restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. The usual operation of the update process will ensure that synchronization is eventually achieved. When BOTH a complete set of CSNP(s) (for each active level, in the case of a pt-pt circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled. Subsequent IIHs sent by the starting router have the RR and RA bits clear and the SA bit set in the restart TLV. Timer T1 is cancelled after some pre-determined number of expirations (which MAY be 1). When the T2 timer(s) are cancelled or expire transmission of "normal" IIHs (with RR, RA, and SA bits clear) will begin. 3.3.3 Multiple levels A router which is operating as both a Level 1 and a Level 2 router on a particular interface MUST perform the above operations for each level. On a LAN interface, it MUST send and receive both Level 1 and Level 2 IIHs and perform the CSNP synchronizations independently for each level. On a pt-pt interface, only a single IIH (indicating support for both levels) is required, but it MUST perform the CSNP synchronizations independently for each level. Shand, Ginsberg Expires Jul 2004 [Page 11] INTERNET DRAFT IS-IS restart Jan 2004 3.4 Database synchronization When a router is started or restarted it can expect to receive a (set of) CSNP(s) over each interface. The arrival of the CSNP(s) is now guaranteed, since an IIH with RR bit set will be retransmitted until the CSNP(s) are correctly received. The CSNPs describe the set of LSPs that are currently held by each neighbor. Synchronization will be complete when all these LSPs have been received. When (re)starting, a router starts an instance of timer T2 for each LSPDB as described in 4.3.1 or 4.3.2. In addition to normal processing of the CSNPs, the set of LSPIDs contained in the first complete set of CSNP(s) received over each interface is recorded, together with their remaining lifetime. In the case of a LAN interface, a complete set of CSNPs MUST consist of CSNPs received from neighbor(s) which are not restarting. If there are multiple interfaces on the (re)starting router, the recorded set of LSPIDs is the union of those received over each interface. LSPs with a remaining lifetime of zero are NOT so recorded. As LSPs are received (by the normal operation of the update process) over any interface, the corresponding LSPID entry is removed (it is also removed if the LSP had arrived before the CSNP containing the reference). When an LSPID has been held in the list for its indicated remaining lifetime, it is removed from the list. When the list of LSPIDs is empty and the timer T1 has been cancelled for all the interfaces that have an adjacency at this level, the timer T2 is cancelled. At this point the local database is guaranteed to contain all the LSP(s) (either the same sequence number, or a more recent sequence number) which were present in the neighbors' databases at the time of (re)starting. LSPs that arrived in a neighbor's database after the time of (re)starting may or may not be present, but the normal operation of the update process will guarantee that they will eventually be received. At this point the local database is deemed to be "synchronized". Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime are not recorded, and those with a short remaining lifetime are deleted from the list when the lifetime expires, cancellation of the timer T2 will not be prevented by waiting for an LSP that will never arrive. 3.4.1 LSP generation and flooding and SPF computation The operation of a router starting, as opposed to restarting is somewhat different. These two cases are dealt with separately below. Shand, Ginsberg Expires Jul 2004 [Page 12] INTERNET DRAFT IS-IS restart Jan 2004 3.4.1.1. Restarting In order to avoid causing unnecessary routing churn in other routers, it is highly desirable that the own LSPs generated by the restarting system are the same as those previously present in the network (assuming no other changes have taken place). It is important therefore not to regenerate and flood the LSPs until all the adjacencies have been re-established and any information required for propagation into the local LSPs is fully available. Ideally, the information is loaded into the LSPs in a deterministic way, such that the same information occurs in the same place in the same LSP (and hence the LSPs are identical to their previous versions). If this can be achieved, the new versions may not even cause SPF to be run in other systems. However, provided the same information is included in the set of LSPs (albeit in a different order, and possibly different LSPs), the result of running the SPF will be the same and will not cause churn to the forwarding tables. In the case of a restarting router, none of the router's own LSPs are transmitted, nor are the router's own forwarding tables updated while the timer T3 is running. Redistribution of inter-level information MUST be regenerated before this router's LSP is flooded to other nodes. Therefore the Level-n non-pseudonode LSP(s) MUST NOT be flooded until the other level's T2 timer has expired and its SPF has been run. This ensures that any inter-level information which is to be propagated can be included in the Level-n LSP(s). During this period, if one of the router's own (including pseudonodes) LSPs is received, which the local router does not currently have in its own database, it is NOT purged. Under normal operation, such an LSP would be purged, since the LSP clearly should not be present in the global LSP database. However, in the present circumstances, this would be highly undesirable, because it could cause premature removal of an own LSP - and hence churn in remote routers. Even if the local system has one or more own LSPs (which it has generated, but not yet transmitted) it is still not valid to compare the received LSP against this set, since it may be that as a result of propagation between Level 1 and Level 2 (or vice versa) a further own LSP will need to be generated when the LSP databases have synchronized. During this period a restarting router SHOULD send CSNPs as it normally would. Information about the router's own LSPs MAY be included, but if it is included it MUST be based on LSPs which have been received, not on versions which have been generated (but not Shand, Ginsberg Expires Jul 2004 [Page 13] INTERNET DRAFT IS-IS restart Jan 2004 yet transmitted). This restriction is necessary to prevent premature removal of an LSP from the global LSP database. When the timer T2 expires or is cancelled indicating that synchronization for that level is complete, the SPF for that level is run in order to derive any information which is required to be propagated to another level, but the forwarding tables are not yet updated. Once the other level's SPF has run and any inter-level propagation has been resolved, the own LSPs can be generated and flooded. Any own LSPs which were previously ignored, but which are not part of the current set of own LSPs (including pseudonodes) MUST then be purged. Note that it is possible that a Designated Router change may have taken place, and consequently the router SHOULD purge those pseudonode LSPs which it previously owned, but which are now no longer part of its set of pseudonode LSPs. When all the T2 timers have expired or been cancelled, the timer T3 is cancelled and the local forwarding tables are updated. If the timer T3 expires before all the T2 timers have expired or been cancelled, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and therefore other routers MUST NOT compute routes through this router). Normal operation of the update process resumes and the local forwarding tables are updated. In order to prevent the neighbor's adjacencies from expiring, IIHs with the normal interface value for the holding time are transmitted over all interfaces with neither RR nor RA set in the restart TLV. This will cause the neighbors to refresh their adjacencies. The own LSP(s) will continue to have the overload bit set until timer T2 has expired or been cancelled. 3.4.1.2. Starting In the case of a starting router, as soon as each adjacency is established, and before any CSNP exchanges, the router's own zeroth LSP is transmitted with the overload bit set. This prevents other routers from computing routes through the router until it has reliably acquired the complete set of LSPs. The overload bit remains set in subsequent transmissions of the zeroth LSP (such as will occur if a previous copy of the routers LSP is still present in the network) while any timer T2 is running. When all the T2 timers have been cancelled, the own LSP(s) MAY be regenerated with the overload bit clear (assuming the router isn't Shand, Ginsberg Expires Jul 2004 [Page 14] INTERNET DRAFT IS-IS restart Jan 2004 in fact overloaded, and there is no other reason, such as incomplete BGP convergence, to keep the overload bit set), and flooded as normal. Other own LSPs (including pseudonodes) are generated and flooded as normal, irrespective of the timer T2. The SPF is also run as normal and the RIB and FIB updated as routes become available. To avoid the possible formation of temporary blackholes the starting router sets the SA bit in the restart TLV (as described in 4.3.2) in all IIHs that it sends. When all T2 timers have been cancelled the starting router MUST transmit IIHs with the SA bit clear. Shand, Ginsberg Expires Jul 2004 [Page 15] INTERNET DRAFT IS-IS restart Jan 2004 4. State Tables This section presents state tables which summarize the behaviors described in this document. Other behaviors, in particular adjacency state transitions and LSP database update operation, are NOT included in the state tables except where this document modifies the behaviors described in [3] and [5]. The states named in the columns of the tables below are a mixture of states that are specific to a single adjacency (ADJ suppressed, ADJ Seen RA, ADJ Seen CSNP) and states which are indicative of the state of the protocol instance (Running, Restarting, Starting, SPF Wait). Three state tables are presented from the point of view of a running router, a restarting router, and a starting router. 4.1 Running Router Event | Running | ADJ suppressed ============================================================== RX RR | Maintain ADJ State | | Send RA | | Set SRM,send CSNP | | (Note 1) | | Update Hold Time, | | set Restart Mode | | (Note 2) | -------------+----------------------+------------------------- RX RR clr | Clr Restart mode | -------------+----------------------+------------------------- RX SA | Suppress IS neighbor | | TLV in LSP(s) | | Goto ADJ Suppressed | -------------+----------------------+------------------------- RX SA clr | |Unsuppress IS neighbor | | TLV in LSP(s) | |Goto Running ============================================================== Note 1: CSNPs are sent by routers in accordance with Section 3.2.1c Note 2: If Restart Mode clear Shand, Ginsberg Expires Jul 2004 [Page 16] INTERNET DRAFT IS-IS restart Jan 2004 4.2 Restarting Router Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait | | RA | CSNP | =================================================================== Router | Send IIH/RR | | | restarts | ADJ Init | | | | Start T1,T2,T3 | | | ------------+--------------------+-----------+-----------+------------ RX RR | Send RA | | | ------------+--------------------+-----------+-----------+------------ RX RA | Adjust T3 | | Cancel T1 | | Goto ADJ Seen RA | | Adjust T3 | ----------- +--------------------+-----------+-----------+------------ RX CSNP set| Goto ADJ Seen CSNP | Cancel T1 | | ------------+--------------------+-----------+-----------+------------ RX IIH w/o | Cancel T1 (Point- | | | Restart TLV| to-point only) | | | ------------+--------------------+-----------+-----------+------------ T1 Expires | Send IIH/RR |Send IIH/RR|Send IIH/RR| | Restart T1 | Restart T1| Restart T1| ------------+--------------------+-----------+-----------+------------ T1 Expires | Send IIH/ | Send IIH/ | Send IIH/ | nth time | normal | normal | normal | ------------+--------------------+-----------+-----------+------------ T2 expires | Trigger SPF | | | | Goto SPF Wait | | | ------------+--------------------+-----------+-----------+------------ T3 expires | Set OL | | | | Flood local LSPs | | | | Update fwd plane | | | ------------+--------------------+-----------+-----------+------------ LSP DB Sync| Cancel T2, and T3 | | | | Trigger SPF | | | | Goto SPF wait | | | ------------+--------------------+-----------+-----------+------------ All SPF | | | | Clear OL done | | | | Update fwd | | | | plane | | | | Flood local | | | | LSPs | | | | Goto Runing ====================================================================== Shand, Ginsberg Expires Jul 2004 [Page 17] INTERNET DRAFT IS-IS restart Jan 2004 4.3 Starting Router Event | Starting | ADJ Seen RA| ADJ Seen CSNP ============================================================= Router | Send IIH/SA | | starts | Start T1,T2 | | -------------+-------------------+------------+--------------- RX RR | Send RA | | -------------+-------------------+------------+--------------- RX RA | Goto ADJ Seen RA | | Cancel T1 -------------+-------------------+------------+--------------- RX CSNP Set | Goto ADJ Seen CSNP| Cancel T1 | -------------+-------------------+------------+--------------- RX IIH w | Cancel T1 | | no Restart | (Point-to-Point | | TLV | only) | | -------------+-------------------+------------+--------------- ADJ UP | Start T1 | | | Send local LSPs | | | w OL | | -------------+-------------------+------------+--------------- T1 Expires | Send IIH/RR |Send IIH/RR | Send IIH/RR | and SA | and SA | and SA | Restart T1 |Restart T1 | Restart T1 -------------+-------------------+------------+--------------- T1 Expires | Send IIH/SA |Send IIH/SA | Send IIH/SA nth time | | | -------------+-------------------+------------+--------------- T2 expires | Clear OL | | | Send IIH normal | | | Goto Running | | -------------+-------------------+------------+--------------- LSP DB Sync | Cancel T2 | | | Clear OL | | | Send IIH normal | | ============================================================== Shand, Ginsberg Expires Jul 2004 [Page 18] INTERNET DRAFT IS-IS restart Jan 2004 5. Security Considerations No new security issues in regards to the creation and/or maintenance of IS-IS adjacencies are introduced by the procedures described in this document. However, the use of the SA bit introduces the capability to suppress the advertisement of an IS neighbor - and this capability is not tied directly to restarting/starting. If an attacker is able to spoof an IIH it would now be possible to cause advertisement of an IS neighbor to be suppressed for an indefinite period of time. This could cause loss of reachability to some destinations in the network. The possibility of IS-IS PDU spoofing can be reduced by the use of authentication as described in [2] and [3], and especially the use of cryptographic authentication as described in [6]. 6. IANA Considerations This document defines the following new ISIS TLV that needs to be reflected in the ISIS TLV code-point registry: Type Description IIH LSP SNP ---- ----------------------------------- --- --- --- 211 Restart TLV y n n 7. Normative References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990. 3 ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002, Second Edition. 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5 Katz, D., and Saluja, R., "Three-Way Handshake for IS-IS Point- to-Point Adjacencies", RFC 3373, September 2002 Shand, Ginsberg Expires Jul 2004 [Page 19] INTERNET DRAFT IS-IS restart Jan 2004 6 Li, T., and Atkinson, R., "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003 7 Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26 , RFC 2434, October 1998 8. Acknowledgments The authors would like to acknowledge contributions made by Jeff Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, Russ White, and Rena Yang. 9. Authors' Addresses Mike Shand Cisco Systems 250 Longwater Avenue, Reading, Berkshire, RG2 6GB UK Phone: +44 208 824 8690 Email: mshand@cisco.com Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, Ca. 95035 USA Email: ginsberg@cisco.com 10. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Shand, Ginsberg Expires Jul 2004 [Page 20] INTERNET DRAFT IS-IS restart Jan 2004 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Shand, Ginsberg Expires Jul 2004 [Page 21] --=====================_5982211==_-- From rtg-dir-admin@ietf.org Wed Jan 7 00:28:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22519 for ; Wed, 7 Jan 2004 00:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae6F6-00075U-00 for rtg-dir-archive@ietf.org; Wed, 07 Jan 2004 00:28:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ae6Cg-0006oW-00 for rtg-dir-archive@ietf.org; Wed, 07 Jan 2004 00:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae5z7-0003my-PZ; Wed, 07 Jan 2004 00:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ae5z6-0003lu-76 for rtg-dir@optimus.ietf.org; Wed, 07 Jan 2004 00:12:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21356 for ; Wed, 7 Jan 2004 00:11:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae5z3-0006Pa-00 for rtg-dir@ietf.org; Wed, 07 Jan 2004 00:11:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae5xJ-0006Jy-00 for rtg-dir@ietf.org; Wed, 07 Jan 2004 00:10:09 -0500 Received: from adsl-66-122-236-184.dsl.sndg02.pacbell.net ([66.122.236.184] helo=rtg-dir) by ietf-mx with smtp (Exim 4.12) id 1Ae5wm-0006Ee-00 for rtg-dir@ietf.org; Wed, 07 Jan 2004 00:09:36 -0500 Message-ID: From: "Rserpool" Date: Tue, 06 Jan 2004 21:09:33 +0000 To: rtg-dir@ietf.org Subject: RE: Perfect gift for 2004 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.3 required=5.0 tests=DATE_IN_PAST_06_12, HTML_FONT_INVISIBLE,HTML_IMAGE_ONLY_02,HTML_MESSAGE, HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,NORMAL_HTTP_TO_IP autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.4 HTML_FONT_INVISIBLE BODY: HTML font color is same as background * 2.2 HTML_IMAGE_ONLY_02 BODY: HTML: images with 0-200 bytes of words * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Loading, Please Wait... , touchily , freshens



From rtg-dir-admin@ietf.org Wed Jan 7 04:59:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00540 for ; Wed, 7 Jan 2004 04:59:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeASt-000686-00 for rtg-dir-archive@ietf.org; Wed, 07 Jan 2004 04:59:03 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AeAQL-0005u0-05 for rtg-dir-archive@ietf.org; Wed, 07 Jan 2004 04:56:26 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AeABd-0005Hc-Q1 for rtg-dir-archive@ietf.org; Wed, 07 Jan 2004 04:41:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeABa-0000fu-Ao; Wed, 07 Jan 2004 04:41:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeAB7-0000b9-Pk for rtg-dir@optimus.ietf.org; Wed, 07 Jan 2004 04:40:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29756 for ; Wed, 7 Jan 2004 04:40:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeAB4-00053m-00 for rtg-dir@ietf.org; Wed, 07 Jan 2004 04:40:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeA8t-0004tZ-00 for rtg-dir@ietf.org; Wed, 07 Jan 2004 04:38:24 -0500 Received: from um130m1pai.dial.kolumbus.fi ([62.248.200.130] helo=rtg-dir) by ietf-mx with smtp (Exim 4.12) id 1AeA78-0004ig-00 for rtg-dir@ietf.org; Wed, 07 Jan 2004 04:36:34 -0500 Message-ID: From: "Nfsv4" Date: Wed, 07 Jan 2004 11:51:30 +0300 To: rtg-dir@ietf.org Subject: Hey mate, hows it going?? MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.2 required=5.0 tests=AWL,HTML_FONT_INVISIBLE, HTML_IMAGE_ONLY_02,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY, NORMAL_HTTP_TO_IP autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.4 HTML_FONT_INVISIBLE BODY: HTML font color is same as background * 2.2 HTML_IMAGE_ONLY_02 BODY: HTML: images with 0-200 bytes of words * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag * 0.5 AWL AWL: Auto-whitelist adjustment Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Loading, Please Wait... , Rankin , employ



From rtg-dir-admin@ietf.org Wed Jan 7 21:36:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19830 for ; Wed, 7 Jan 2004 21:36:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeQ1v-0001UL-00 for rtg-dir-archive@ietf.org; Wed, 07 Jan 2004 21:36:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AePzz-0001BF-00 for rtg-dir-archive@ietf.org; Wed, 07 Jan 2004 21:34:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AePx2-0000kG-00 for rtg-dir-archive@ietf.org; Wed, 07 Jan 2004 21:31:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AePwq-000143-98; Wed, 07 Jan 2004 21:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AePw4-00013D-TB for rtg-dir@optimus.ietf.org; Wed, 07 Jan 2004 21:30:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19402 for ; Wed, 7 Jan 2004 21:30:10 -0500 (EST) From: doctorwilliamsanaphoric@yahoo.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AePvx-0000gG-00 for rtg-dir@ietf.org; Wed, 07 Jan 2004 21:30:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AePqJ-0000U4-00 for rtg-dir@ietf.org; Wed, 07 Jan 2004 21:24:16 -0500 Received: from [213.155.228.18] (helo=rtg-dir) by ietf-mx with smtp (Exim 4.12) id 1AePmF-0000Kv-00 for rtg-dir@ietf.org; Wed, 07 Jan 2004 21:20:03 -0500 To: rtg-dir@ietf.org Subject: How was your New Years MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 Message-Id: Date: Wed, 07 Jan 2004 21:20:03 -0500 Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,FORGED_YAHOO_RCVD, HTML_50_60,HTML_FONTCOLOR_BLUE,HTML_FONT_BIG,HTML_MESSAGE, MIME_HTML_ONLY,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit alpha1
ALPHAMALE+

* Increase testosterone levels up to 500%
* Prevent premature ejacul.ation
* Enhance pe.nis size up to 3 inches
* Maintain harder, stronger ere.ctions for hours
* Have amazing sex up to 20 times per day
* Improve sex.ual stamina dramatically
* Increase se.xual self-confidence
* Satisfy yourself and your lover like never before
* 100% Safe To Take, With NO Side Effects
* Fast Priority USPS Shipping WorldWide
* Doctor Approved And Recommended
* 100% Mo.ney Back Gua.rantee

Read More Info Here
 
 
 
 
 
 

No More Emailz Please

From rtg-dir-admin@ietf.org Fri Jan 9 06:25:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24886 for ; Fri, 9 Jan 2004 06:25:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeulS-0001HH-00 for rtg-dir-archive@ietf.org; Fri, 09 Jan 2004 06:25:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeujq-000193-00 for rtg-dir-archive@ietf.org; Fri, 09 Jan 2004 06:23:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aeuid-0000wM-00 for rtg-dir-archive@ietf.org; Fri, 09 Jan 2004 06:22:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeuiI-0001Cq-Qq; Fri, 09 Jan 2004 06:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeuhI-00014N-PD for rtg-dir@optimus.ietf.org; Fri, 09 Jan 2004 06:21:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24357 for ; Fri, 9 Jan 2004 06:20:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeuhE-0000ns-00 for rtg-dir@ietf.org; Fri, 09 Jan 2004 06:20:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeufi-0000aB-00 for rtg-dir@ietf.org; Fri, 09 Jan 2004 06:19:24 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aeuaj-0000H6-00 for rtg-dir@ietf.org; Fri, 09 Jan 2004 06:14:13 -0500 Received: from host178.200-117-54.telecom.net.ar ([200.117.54.178] helo=rtg-dir) by mx2.foretec.com with smtp (Exim 4.24) id 1AeuaC-0007bx-Nq for rtg-dir@ietf.org; Fri, 09 Jan 2004 06:13:41 -0500 Message-ID: From: "Xcon" Date: Fri, 09 Jan 2004 08:14:18 +0200 To: rtg-dir@ietf.org Subject: Cum and look like a po.rn star. MIME-Version: 1.0 Content-Type: text/html; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA24361 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,BIZ_TLD,DATE_IN_PAST_03_06, HTML_60_70,HTML_MESSAGE,LINES_OF_YELLING,MIME_HTML_ONLY, UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable cumpills1 =A0
=A0
EJAC.ULATE LIKE A
MALE PO.RN STAR TODAY!

It's Amazing & Has Finally Arrived !
A Unique Pill That Will Increase Your Sp.erm By Up To 500% More
We Guaranteed It !

- Maintain Rock Solid Erec.tions.
- Multiple Extreme Org.asms! Have 2 Or 3 Each Time.
- Shoot Out Amazing Amounts Of Spe.rm Everywhere.
- 100% Mon.ey Back Guarantee With Every Order.
=A0

READ MORE INFO HERE


=A0
=A0

no more emailz

=A0


=A0 From rtg-dir-admin@ietf.org Fri Jan 9 18:04:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26385 for ; Fri, 9 Jan 2004 18:04:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af5fe-0002We-00 for rtg-dir-archive@ietf.org; Fri, 09 Jan 2004 18:04:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af5ds-0002Rz-00 for rtg-dir-archive@ietf.org; Fri, 09 Jan 2004 18:02:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af5ci-0002ML-00 for rtg-dir-archive@ietf.org; Fri, 09 Jan 2004 18:01:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af5cj-0004KG-7o; Fri, 09 Jan 2004 18:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af5by-0004Ii-U6 for rtg-dir@optimus.ietf.org; Fri, 09 Jan 2004 18:00:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26156 for ; Fri, 9 Jan 2004 18:00:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af5bw-0002LX-00 for rtg-dir@ietf.org; Fri, 09 Jan 2004 18:00:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af5aA-0002FM-00 for rtg-dir@ietf.org; Fri, 09 Jan 2004 17:58:23 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Af5Z9-00027j-00 for rtg-dir@ietf.org; Fri, 09 Jan 2004 17:57:19 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af5Z3-0008Rb-JF; Fri, 09 Jan 2004 22:57:13 +0000 Date: Fri, 9 Jan 2004 14:55:33 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14186478171.20040109145533@psg.com> To: Les Ginsberg CC: Jeff Parker , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , , Tony Li Subject: Re: AD-review comments on draft-ietf-isis-restart-05.txt In-Reply-To: <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> References: <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Les, Thanks for the update! Looking at the security section, I got a question: wouldn't it be possible for an adversary to also spoof RR and RA bits and thus falsely start or ack graceful restart? -- Alex http://www.psg.com/~zinin/ Monday, January 5, 2004, 10:02:33 AM, Les Ginsberg wrote: > Alex - > Attached please find a revised version (dated Jan/2004) which addresses the > items you have identified below. I also have included a diffs file for your > convenience. > Please let us know if you have any remaining concerns. > Thanx. > Les > At 10:06 PM 12/19/2003 -0800, Alex Zinin wrote: >>I reviewed the 05v4 rev of the spec. Great document! Very good job! >>Some things that should be fixed before I can take this to the IESG: >> >> - IANA section needs to be included >> >> - Security Considerations >> >> This one needs to describe new attacks and threats possible with >> the new TLV and behavior, and then point to the existing security >> mechanisms. >> >>and a small editorial suggestion while you're working on it: >> >> - In sections 4.1--4.3 would be great to see some text introducing >> the meaning of the columns (e.g. circuit state for the neighbor, >> etc.) >> >>Please let me know when the new rev shows up. >>Thanks. >> >>-- >>Alex >>http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Fri Jan 9 18:43:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29345 for ; Fri, 9 Jan 2004 18:43:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af6IB-0004qL-00 for rtg-dir-archive@ietf.org; Fri, 09 Jan 2004 18:43:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af6GI-0004k5-00 for rtg-dir-archive@ietf.org; Fri, 09 Jan 2004 18:41:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af6ES-0004ex-00 for rtg-dir-archive@ietf.org; Fri, 09 Jan 2004 18:40:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6EU-000615-MN; Fri, 09 Jan 2004 18:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af6EL-0005zt-89 for rtg-dir@optimus.ietf.org; Fri, 09 Jan 2004 18:39:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29145 for ; Fri, 9 Jan 2004 18:39:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af6EI-0004cz-00 for rtg-dir@ietf.org; Fri, 09 Jan 2004 18:39:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af6CN-0004XJ-00 for rtg-dir@ietf.org; Fri, 09 Jan 2004 18:37:52 -0500 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 1Af6AW-0004On-00 for rtg-dir@ietf.org; Fri, 09 Jan 2004 18:35:56 -0500 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i09NZNVM026226; Fri, 9 Jan 2004 15:35:23 -0800 (PST) Received: from ginsberg-w2k.cisco.com (sjc-vpn1-23.cisco.com [10.21.96.23]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMU52030; Fri, 9 Jan 2004 15:35:22 -0800 (PST) Message-Id: <4.3.2.7.2.20040109151927.01be2eb0@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Jan 2004 15:35:22 -0800 To: Alex Zinin From: Les Ginsberg Subject: Re: AD-review comments on draft-ietf-isis-restart-05.txt Cc: Jeff Parker , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , , Tony Li In-Reply-To: <14186478171.20040109145533@psg.com> References: <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 autolearn=no version=2.60 At 02:55 PM 1/9/2004 -0800, Alex Zinin wrote: >Les, > > Thanks for the update! > > Looking at the security section, I got a question: wouldn't it be > possible for an adversary to also spoof RR and RA bits and thus > falsely start or ack graceful restart? Alex - Probably a good thing if we discuss this... :-) The answer to your question is obviously "yes" - but what is the significance of this? First, the introduction of the restart TLV into IIHs does not make IIHs easier/harder to spoof. Now, if someone is able to spoof an IIH, what happens if we receive an IIH-RR? If we currently have an adjacency in UP state, it remains in UP state. No problem there. And, we may also trigger the sending of a set of CSNPs. This would be a waste of cycles, but should cause no harm. Now, what happens if we receive a spoofed IIH-RA? This is only significant to a (re)starting router of course. It might cause T1 to be cancelled on a circuit (if we also had received a complete set of CSNPs on that circuit). That should not be a problem. In the case that none of our neighbors actually support restart, it would prevent T1 from being cancelled on that circuit immediately. Which just means it might take a bit longer for restart to complete because we would have to wait for "N" expirations of T1 on that circuit. None of this seemed worthy of mention, but if you disagree we can add something. We did discuss SA because spoofing in that case could have consequences which are not possible without the SA bit. If others feel that something is lacking, please say so. Les >-- >Alex >http://www.psg.com/~zinin/ > >Monday, January 5, 2004, 10:02:33 AM, Les Ginsberg wrote: > > Alex - > > > Attached please find a revised version (dated Jan/2004) which addresses > the > > items you have identified below. I also have included a diffs file for > your > > convenience. > > > Please let us know if you have any remaining concerns. > > > Thanx. > > > Les > > > > At 10:06 PM 12/19/2003 -0800, Alex Zinin wrote: > > >>I reviewed the 05v4 rev of the spec. Great document! Very good job! > >>Some things that should be fixed before I can take this to the IESG: > >> > >> - IANA section needs to be included > >> > >> - Security Considerations > >> > >> This one needs to describe new attacks and threats possible with > >> the new TLV and behavior, and then point to the existing security > >> mechanisms. > >> > >>and a small editorial suggestion while you're working on it: > >> > >> - In sections 4.1--4.3 would be great to see some text introducing > >> the meaning of the columns (e.g. circuit state for the neighbor, > >> etc.) > >> > >>Please let me know when the new rev shows up. > >>Thanks. > >> > >>-- > >>Alex > >>http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Fri Jan 9 22:43:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07563 for ; Fri, 9 Jan 2004 22:43:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AfA2X-0001BZ-00 for rtg-dir-archive@ietf.org; Fri, 09 Jan 2004 22:43:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AfA0g-00016s-00 for rtg-dir-archive@ietf.org; Fri, 09 Jan 2004 22:42:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Af9ze-00013D-00 for rtg-dir-archive@ietf.org; Fri, 09 Jan 2004 22:40:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af9zg-000655-NK; Fri, 09 Jan 2004 22:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Af9ym-00063m-3Y for rtg-dir@optimus.ietf.org; Fri, 09 Jan 2004 22:40:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07504 for ; Fri, 9 Jan 2004 22:40:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af9yi-000114-00 for rtg-dir@ietf.org; Fri, 09 Jan 2004 22:40:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af9wr-0000xR-00 for rtg-dir@ietf.org; Fri, 09 Jan 2004 22:38:05 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Af9v9-0000tZ-00 for rtg-dir@ietf.org; Fri, 09 Jan 2004 22:36:19 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af9v4-000OVt-5D; Sat, 10 Jan 2004 03:36:14 +0000 Date: Fri, 9 Jan 2004 19:33:01 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <47203126019.20040109193301@psg.com> To: Les Ginsberg CC: Jeff Parker , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , , Tony Li Subject: Re: AD-review comments on draft-ietf-isis-restart-05.txt In-Reply-To: <4.3.2.7.2.20040109151927.01be2eb0@mira-sjc5-3.cisco.com> References: <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040109151927.01be2eb0@mira-sjc5-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Les, > Alex - > Probably a good thing if we discuss this... :-) > The answer to your question is obviously "yes" - but what is the > significance of this? > First, the introduction of the restart TLV into IIHs does not make IIHs > easier/harder to spoof. Agreed. The adversary's work function hasn't changed, though the list of attacks did. > Now, if someone is able to spoof an IIH, what happens if we receive an > IIH-RR? If we currently have an adjacency in UP state, it remains in UP > state. No problem there. And, we may also trigger the sending of a set of > CSNPs. This would be a waste of cycles, but should cause no harm. > Now, what happens if we receive a spoofed IIH-RA? This is only significant > to a (re)starting router of course. It might cause T1 to be cancelled on a > circuit (if we also had received a complete set of CSNPs on that circuit). > That should not be a problem. In the case that none of our neighbors > actually support restart, it would prevent T1 from being cancelled on that > circuit immediately. Which just means it might take a bit longer for > restart to complete because we would have to wait for "N" expirations of T1 > on that circuit. > None of this seemed worthy of mention, but if you disagree we can add > something. The above is essentially a security analysis for those bits :) Something along these lines would be useful in the security section, as otherwise it will read as if the RR and RA bits haven't been analyzed. It should also make the draft easier to pass the review by the SEC ADs in the IESG. Regards Alex > We did discuss SA because spoofing in that case could have consequences > which are not possible without the SA bit. > If others feel that something is lacking, please say so. > Les >>-- >>Alex >>http://www.psg.com/~zinin/ >> >>Monday, January 5, 2004, 10:02:33 AM, Les Ginsberg wrote: >> > Alex - >> >> > Attached please find a revised version (dated Jan/2004) which addresses >> the >> > items you have identified below. I also have included a diffs file for >> your >> > convenience. >> >> > Please let us know if you have any remaining concerns. >> >> > Thanx. >> >> > Les >> >> >> > At 10:06 PM 12/19/2003 -0800, Alex Zinin wrote: >> >> >>I reviewed the 05v4 rev of the spec. Great document! Very good job! >> >>Some things that should be fixed before I can take this to the IESG: >> >> >> >> - IANA section needs to be included >> >> >> >> - Security Considerations >> >> >> >> This one needs to describe new attacks and threats possible with >> >> the new TLV and behavior, and then point to the existing security >> >> mechanisms. >> >> >> >>and a small editorial suggestion while you're working on it: >> >> >> >> - In sections 4.1--4.3 would be great to see some text introducing >> >> the meaning of the columns (e.g. circuit state for the neighbor, >> >> etc.) >> >> >> >>Please let me know when the new rev shows up. >> >>Thanks. >> >> >> >>-- >> >>Alex >> >>http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Mon Jan 12 11:11:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03969 for ; Mon, 12 Jan 2004 11:11:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag4ef-0001Mx-00 for rtg-dir-archive@ietf.org; Mon, 12 Jan 2004 11:11:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag4cu-0001KN-00 for rtg-dir-archive@ietf.org; Mon, 12 Jan 2004 11:09:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag4bg-0001Gi-00 for rtg-dir-archive@ietf.org; Mon, 12 Jan 2004 11:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4bh-0001di-Jo; Mon, 12 Jan 2004 11:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag4JN-0000yr-FZ for rtg-dir@optimus.ietf.org; Mon, 12 Jan 2004 10:49:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03152 for ; Mon, 12 Jan 2004 10:49:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag4JL-0000bM-00 for rtg-dir@ietf.org; Mon, 12 Jan 2004 10:49:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag4Hf-0000WW-00 for rtg-dir@ietf.org; Mon, 12 Jan 2004 10:47:23 -0500 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 1Ag4G3-0000L1-00 for rtg-dir@ietf.org; Mon, 12 Jan 2004 10:45:39 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Jan 2004 07:46:50 +0000 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0CFj3GN015594; Mon, 12 Jan 2004 07:45:04 -0800 (PST) Received: from ginsberg-w2k.cisco.com (sjc-vpn4-21.cisco.com [10.21.80.21]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMV34996; Mon, 12 Jan 2004 07:45:00 -0800 (PST) Message-Id: <4.3.2.7.2.20040112074223.01b937f8@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 Jan 2004 07:45:00 -0800 To: Alex Zinin From: Les Ginsberg Subject: Re: AD-review comments on draft-ietf-isis-restart-05.txt Cc: Jeff Parker , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , , Tony Li In-Reply-To: <47203126019.20040109193301@psg.com> References: <4.3.2.7.2.20040109151927.01be2eb0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040109151927.01be2eb0@mira-sjc5-3.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_60164712==_" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,REMOVE_REMOVAL_NEAR autolearn=no version=2.60 --=====================_60164712==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Alex - Attached is a new version which addresses the security issues discussed below. Only the Security section has changed from the previous version. Please let us know if that adequately addresses your concerns. Thanx. Les At 07:33 PM 1/9/2004 -0800, Alex Zinin wrote: >Les, > > > > Alex - > > > Probably a good thing if we discuss this... :-) > > > The answer to your question is obviously "yes" - but what is the > > significance of this? > > > First, the introduction of the restart TLV into IIHs does not make IIHs > > easier/harder to spoof. > >Agreed. The adversary's work function hasn't changed, though the list of >attacks did. > > > Now, if someone is able to spoof an IIH, what happens if we receive an > > IIH-RR? If we currently have an adjacency in UP state, it remains in UP > > state. No problem there. And, we may also trigger the sending of a set of > > CSNPs. This would be a waste of cycles, but should cause no harm. > > > Now, what happens if we receive a spoofed IIH-RA? This is only significant > > to a (re)starting router of course. It might cause T1 to be cancelled on a > > circuit (if we also had received a complete set of CSNPs on that circuit). > > That should not be a problem. In the case that none of our neighbors > > actually support restart, it would prevent T1 from being cancelled on that > > circuit immediately. Which just means it might take a bit longer for > > restart to complete because we would have to wait for "N" expirations > of T1 > > on that circuit. > > > None of this seemed worthy of mention, but if you disagree we can add > > something. > >The above is essentially a security analysis for those bits :) >Something along these lines would be useful in the security section, >as otherwise it will read as if the RR and RA bits haven't been >analyzed. It should also make the draft easier to pass the review >by the SEC ADs in the IESG. > >Regards > >Alex > > > We did discuss SA because spoofing in that case could have consequences > > which are not possible without the SA bit. > > > If others feel that something is lacking, please say so. > > > Les --=====================_60164712==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-isis-restart-05.txt" INTERNET DRAFT IS-IS restart Jan 2004 Network Working Group M. Shand Internet Draft L. Ginsberg Expiration Date: July 2004 Cisco Systems January 2004 Restart signaling for IS-IS draft-ietf-isis-restart-05.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The IS-IS routing protocol (RFC 1195, ISO/IEC 10589) is a link state intra-domain routing protocol. Normally, when an IS-IS router is restarted, temporary disruption of routing occurs due to events in both the restarting router and the neighbors of the restarting router. The router which has been restarted computes its own routes before achieving database synchronization with its neighbors. The results Shand, Ginsberg Expires Jul 2004 [Page 1] INTERNET DRAFT IS-IS restart Jan 2004 of this computation are likely to be non-convergent with the routes computed by other routers in the area/domain. Neighbors of the restarting router detect the restart event and cycle their adjacencies with the restarting router through the down state. The cycling of the adjacency state causes the neighbors to regenerate their LSPs describing the adjacency concerned. This in turn causes temporary disruption of routes passing through the restarting router. In certain scenarios the temporary disruption of the routes is highly undesirable. This draft describes mechanisms to avoid or minimize the disruption due to both of these causes. Table of Contents 1. Conventions used in this document..............................3 2. Overview.......................................................3 3. Approach.......................................................4 3.1 Timers.......................................................4 3.2 Restart TLV..................................................4 3.2.1 Use of RR and RA bits.....................................5 3.2.2 Use of SA bit.............................................7 3.3 Adjacency (re)acquisition....................................8 3.3.1 Adjacency reacquisition during restart....................8 3.3.2 Adjacency acquisition during start.......................10 3.3.3 Multiple levels..........................................11 3.4 Database synchronization....................................12 3.4.1 LSP generation and flooding and SPF computation..........12 3.4.1.1. Restarting..........................................13 3.4.1.2. Starting............................................14 4. State Tables..................................................16 4.1 Running Router..............................................16 4.2 Restarting Router...........................................17 4.3 Starting Router.............................................18 5. Security Considerations.......................................19 6. IANA Considerations...........................................19 7. Normative References..........................................20 8. Acknowledgments...............................................20 9. Authors' Addresses............................................20 10. Full Copyright Statement.....................................21 Shand, Ginsberg Expires Jul 2004 [Page 2] INTERNET DRAFT IS-IS restart Jan 2004 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. If the control and forwarding functions in a router can be maintained independently, it is possible for the forwarding function state to be maintained across a control function restart. This functionality is assumed when the terms "restart/restarting" are used in this document. The terms "start/starting" are used to refer to a router in which the control function has either been started for the first time or has been restarted but the forwarding functions have not been maintained in a prior state. The terms "(re)start/(re)starting" are used when the text is applicable to both a "starting" and a "restarting" router. 2. Overview When an adjacency is reinitialized as a result of a neighbor restarting, a router does three things: 1. It causes its own LSP(s) to be regenerated, thus triggering SPF runs throughout the area (or in the case of Level 2, throughout the domain). 2. It sets SRMflags on its own LSP database on the adjacency concerned. 3. In the case of a Point-to-Point link it transmits a (set of) CSNP(s) over the adjacency. In the case of a restarting router process, the first of these is highly undesirable, but the second is essential in order to ensure synchronization of the LSP database. The third action above minimizes the number of LSPs which must be exchanged and, if made reliable, provides a means of determining when the LSP databases of the neighboring routers have been synchronized. This is desirable whether the router is being restarted or not (so that the overload bit can be cleared in the router's own LSP, for example). This draft describes a mechanism for a restarting router to signal that it is restarting to its neighbors, and allow them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. Shand, Ginsberg Expires Jul 2004 [Page 3] INTERNET DRAFT IS-IS restart Jan 2004 This draft additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization and minimize transient routing disruption when a router starts. It is assumed that the three-way handshake [5] is being used on Point-to-Point circuits. 3. Approach 3.1 Timers Three additional timers, T1, T2 and T3 are required to support the functionality defined in this document. An instance of the timer T1 is maintained per interface, and indicates the time after which an unacknowledged (re)start attempt will be repeated. A typical value might be 3 seconds. An instance of the timer T2 is maintained for each LSP database present in the system i.e. for a Level1/2 system, there will be an instance of the timer T2 for Level 1 and an instance for Level 2. This is the maximum time that the system will wait for LSPDB synchronization. A typical value might be 60 seconds. A single instance of the timer T3 is maintained for the entire system. It indicates the time after which the router will declare that it has failed to achieve database synchronization (by setting the overload bit in its own LSP). This is initialized to 65535 seconds, but is set to the minimum of the remaining times of received IIHs containing a restart TLV with RA set and an indication that the neighbor has an adjacency in the UP state to the restarting router. NOTE: The timer T3 is only used by a restarting router. 3.2 Restart TLV A new TLV is defined to be included in IIH PDUs. The presence of this TLV indicates that the sender supports the functionality defined in this document and it carries flags that are used to convey information during a (re)start. All IIHs transmitted by a router that supports this capability MUST include this TLV. Shand, Ginsberg Expires Jul 2004 [Page 4] INTERNET DRAFT IS-IS restart Jan 2004 Type 211 Length # of octets in the value field (1 to (3 + ID Length)) Value No. of octets +-----------------------+ | Flags | 1 +-----------------------+ | Remaining Time | 2 +-----------------------+ | Restarting Neighbor ID| ID Length +-----------------------+ Flags (1 octet) 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | Reserved |SA|RA|RR| +--+--+--+--+--+--+--+--+ RR - Restart Request RA - Restart Acknowledgment SA - Suppress adjacency advertisement (Note: Remaining fields are required when RA bit is set) Remaining Time (2 octets) Remaining holding time (in seconds) Restarting Neighbor System ID (ID Length octets) The system ID of the neighbor to which an RA refers. Note: Implementations based on earlier versions of this document may not include this field in the TLV when RA is set. In this case a router which is expecting an RA on a LAN circuit SHOULD assume that the acknowledgement is directed at the local system. 3.2.1 Use of RR and RA bits The RR bit is used by a (re)starting router to signal to its neighbors that a (re)start is in progress, that an existing Shand, Ginsberg Expires Jul 2004 [Page 5] INTERNET DRAFT IS-IS restart Jan 2004 adjacency SHOULD be maintained even under circumstances when the normal operation of the adjacency state machine would require the adjacency to be reinitialized, to request a set of CSNPs, and to request setting of SRMflags. The RA bit is sent by the neighbor of a (re)starting router to acknowledge the receipt of a restart TLV with the RR bit set. When the neighbor of a (re)starting router receives an IIH with the restart TLV having the RR bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then, irrespective of the other contents of the "Intermediate System Neighbors" option (LAN circuits), or the "Point-to-Point Three-Way Adjacency" option (Point-to-Point circuits): a) The state of the adjacency is not changed. If this is the first IIH with the RR bit set that this system has received associated with this adjacency then the adjacency is marked as being in "Restart mode" and the adjacency holding time is refreshed - otherwise the holding time is not refreshed. The "remaining time" transmitted according to (b) below MUST reflect the actual time after which the adjacency will now expire. Receipt of a normal IIH with RR bit reset will clear the "Restart mode" state. This procedure allows the restarting router to cause the neighbor to maintain the adjacency long enough for restart to successfully complete while also preventing repetitive restarts from maintaining an adjacency indefinitely. Whether an adjacency is marked as being in "Restart mode" or not has no effect on adjacency state transitions. b) immediately (i.e. without waiting for any currently running timer interval to expire, but with a small random delay of a few 10s of milliseconds on LANs to avoid "storms"), transmit over the corresponding interface an IIH including the restart TLV with the RR bit clear and the RA bit set, in the case of Point-to-Point adjacencies having updated the "Point-to-Point Three-Way Adjacency" option to reflect any new values received from the (re)starting router. (This allows a restarting router to quickly acquire the correct information to place in its hellos.) The "Remaining Time" MUST be set to the current time (in seconds) before the holding timer on this adjacency is due to expire. If the corresponding interface is a LAN interface, then the Restarting Neighbor System ID SHOULD be set to the System ID of the router from whom the IIH with RR bit set was received. This is required to correctly associate the acknowledgement and holding time in the case where multiple systems on a LAN restart at approximately the same time. This IIH SHOULD be transmitted before any LSPs or SNPs transmitted as a result of the receipt of the original IIH. Shand, Ginsberg Expires Jul 2004 [Page 6] INTERNET DRAFT IS-IS restart Jan 2004 c) if the corresponding interface is a Point-to-Point interface, or if the receiving router has the highest LnRouterPriority (with highest source MAC address breaking ties) among those routers to which the receiving router has an adjacency in state "Up" on this interface whose IIHs contain the restart TLV, excluding adjacencies to all routers which are considered in "Restart mode" (note the actual DIS is NOT changed by this process), initiate the transmission over the corresponding interface of a complete set of CSNPs, and set SRMflags on the corresponding interface for all LSPs in the local LSP database. Otherwise (i.e. if there was no adjacency in the "UP" state to the system ID in question), process the IIH as normal by reinitializing the adjacency, and setting the RA bit in the returned IIH. 3.2.2 Use of SA bit The SA bit is used by a starting router to request that its neighbor suppress advertisement of the adjacency to the starting router in the neighbor's LSPs. A router which is starting has no maintained forwarding function state. This may or may not be the first time the router has started. If this is not the first time the router has started, copies of LSPs generated by this router in its previous incarnation may exist in the LSP databases of other routers in the network. These copies are likely to appear "newer" than LSPs initially generated by the starting router due to the reinitialization of LSP fragment sequence numbers by the starting router. This may cause temporary blackholes to occur until the normal operation of the update process causes the starting router to regenerate and flood copies of its own LSPs with higher sequence numbers. The temporary blackholes can be avoided if the starting router's neighbors suppress advertising an adjacency to the starting router until the starting router has been able to propagate newer versions of LSPs generated by previous incarnations. When a router receives an IIH with the restart TLV having the SA bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then the router MUST suppress advertisement of the adjacency to the neighbor in its own LSPs. Until an IIH with the SA bit clear has been received, the neighbor advertisement MUST continue to be suppressed. If the adjacency transitions to the UP state, the new adjacency MUST NOT be advertised until an IIH with the SA bit clear has been received. Note that a router which suppresses advertisement of an adjacency MUST NOT use this adjacency when performing its SPF calculation. In particular, if an implementation follows the example guidelines presented in [3] Annex C.2.5 Step 0:b) "pre-load TENT with the local Shand, Ginsberg Expires Jul 2004 [Page 7] INTERNET DRAFT IS-IS restart Jan 2004 adjacency database", the suppressed adjacency MUST NOT be loaded into TENT. 3.3 Adjacency (re)acquisition Adjacency (re)acquisition is the first step in (re)initialization. Restarting and starting routers will make use of the RR bit in the restart TLV, though each will use it at different stages of the (re)start procedure. 3.3.1 Adjacency reacquisition during restart The restarting router explicitly notifies its neighbor that the adjacency is being reacquired, and hence that it SHOULD NOT reinitialize the adjacency. This is achieved by setting the RR bit in the restart TLV. When the neighbor of a restarting router receives an IIH with the restart TLV having the RR bit set, if there exists on this interface an adjacency in state "Up" with the same System ID, and in the case of a LAN circuit, with the same source LAN address, then the procedures described in 4.2.1 are followed. A router that does not support the restart capability will ignore the restart TLV and reinitialize the adjacency as normal, returning an IIH without the restart TLV. On restarting, a router initializes the timer T3, starts the timer T2 for each LSPDB and for each interface (and in the case of a LAN circuit, for each level) starts the timer T1 and transmits an IIH containing the restart TLV with the RR bit set. On a Point-to-Point circuit the restarting router SHOULD set the "Adjacency Three-Way State" to "Init", because the receipt of the acknowledging IIH (with RA set) MUST cause the adjacency to enter "Up" state immediately. On a LAN circuit the LAN-ID assigned to the circuit SHOULD be the same as that used prior to the restart. In particular, for any circuits for which the restarting router was previously DIS, the use of a different LAN-ID would necessitate the generation of a new set of pseudonode LSPs, and corresponding changes in all the LSPs referencing them from other routers on the LAN. By preserving the LAN-ID across the restart, this churn can be prevented. To enable a restarting router to learn the LAN-ID used prior to restart, the LAN-ID specified in an IIH with RR set MUST be ignored. Transmission of "normal" IIHs is inhibited until the conditions described below are met (in order to avoid causing an unnecessary adjacency initialization). On expiry of the timer T1, it is restarted and the IIH is retransmitted as above. Shand, Ginsberg Expires Jul 2004 [Page 8] INTERNET DRAFT IS-IS restart Jan 2004 When a restarting router receives an IIH a local adjacency is established as usual, and if the IIH contains a restart TLV with the RA bit set (and on LAN circuits with a Restart Neighbor System ID which matches that of the local system), the receipt of the acknowledgement over that interface is noted. When the RA bit is set and the state of the remote adjacency is UP then the timer T3 is set to the minimum of its current value and the value of the "Remaining Time" field in the received IIH. On a Point-to-Point link, receipt of an IIH not containing the restart TLV is also treated as an acknowledgement, since it indicates that the neighbor is not restart capable. However, since no CSNP is guaranteed to be received over this interface, the timer T1 is cancelled immediately without waiting for a complete set of CSNP(s). Synchronization may therefore be deemed complete even though there are some LSPs which are held (only) by this neighbor (see section 4.4). In this case we also want to be certain that the neighbor will reinitialize the adjacency in order to guarantee that SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. This is guaranteed to happen except in the case where the Adjacency Three-Way State in the received IIH is UP and the Neighbor Extended Local Circuit ID matches the extended local circuit ID assigned by the restarting router. In this case the restarting router MUST force the adjacency to reinitialize by setting the local Adjacency Three-Way State to DOWN and sending a normal IIH. In the case of a LAN interface, receipt of an IIH not containing the restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. In the case of a Point-to-Point circuit, the "LocalCircuitID" and "Extended Local Circuit ID" information contained in the IIH can be used immediately to generate an IIH containing the correct 3-way handshake information. The presence of "Neighbor Extended Local Circuit ID" information which does not match the value currently in use by the local system is ignored (since the IIH may have been transmitted before the neighbor had received the new value from the restarting router), but the adjacency remains in the initializing state until the correct information is received. In the case of a LAN circuit the source neighbor information (e.g. SNPAAddress) is recorded and used for adjacency establishment and maintenance as normal. Shand, Ginsberg Expires Jul 2004 [Page 9] INTERNET DRAFT IS-IS restart Jan 2004 When BOTH a complete set of CSNP(s) (for each active level, in the case of a pt-pt circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled. Once the timer T3 has expired or been cancelled, subsequent IIHs are transmitted according to the normal algorithms, but including the restart TLV with both RR and RA clear. If a LAN contains a mixture of systems, only some of which support the new algorithm, database synchronization is still guaranteed, but the "old" systems will have reinitialized their adjacencies. If an interface is active, but does not have any neighboring router reachable over that interface the timer T1 would never be cancelled, and according to clause 3.4.1.1 the SPF would never be run. Therefore timer T1 is cancelled after some pre-determined number of expirations (which MAY be 1). 3.3.2 Adjacency acquisition during start The starting router wants to ensure that in the event a neighboring router has an adjacency to the starting router in the UP state (from a previous incarnation of the starting router) that this adjacency is reinitialized. The starting router also wants neighboring routers to suppress advertisement of an adjacency to the starting router until LSP database synchronization is achieved. This is achieved by sending IIHs with the RR bit clear and the SA bit set in the restart TLV. The RR bit remains clear and the SA bit remains set in subsequent transmissions of IIHs until the adjacency has reached the UP state and the initial T1 timer interval (see below) has expired. Receipt of an IIH with RR bit clear will result in the neighboring router utilizing normal operation of the adjacency state machine. This will ensure that any old adjacency on the neighboring router will be reinitialized. On receipt of an IIH with SA bit set the behavior described in 3.2.2 is followed. On starting, a router starts timer T2 for each LSPDB. For each interface (and in the case of a LAN circuit, for each level), when an adjacency reaches the UP state, the starting router starts a timer T1 and transmits an IIH containing the restart TLV with the RR bit clear and SA bit set. On expiry of the timer T1, it is restarted and the IIH is retransmitted with both RR and SA bits set (only the RR bit has changed state from earlier IIHs). On receipt of an IIH with RR bit set (regardless of whether SA is set or not) the behavior described in 3.2.1 is followed. Shand, Ginsberg Expires Jul 2004 [Page 10] INTERNET DRAFT IS-IS restart Jan 2004 When an IIH is received by the starting router and the IIH contains a restart TLV with the RA bit set (and on LAN circuits with a Restart Neighbor System ID which matches that of the local system), the receipt of the acknowledgement over that interface is noted. On a Point-to-Point link, receipt of an IIH not containing the restart TLV is also treated as an acknowledgement, since it indicates that the neighbor is not restart capable. Since the neighbor will have reinitialized the adjacency this guarantees that SRMflags have been set on its database, thus ensuring eventual LSPDB synchronization. However, since no CSNP is guaranteed to be received over this interface, the timer T1 is cancelled immediately without waiting for a complete set of CSNP(s). Synchronization may therefore be deemed complete even though there are some LSPs which are held (only) by this neighbor (see section 4.4). In the case of a LAN interface, receipt of an IIH not containing the restart TLV is unremarkable since synchronization can still occur so long as at least one of the non-restarting neighboring routers on the LAN supports restart. Therefore T1 continues to run in this case. If none of the neighbors on the LAN are restart capable, T1 will eventually expire after the locally defined number of retries. The usual operation of the update process will ensure that synchronization is eventually achieved. When BOTH a complete set of CSNP(s) (for each active level, in the case of a pt-pt circuit) and an acknowledgement have been received over the interface, the timer T1 is cancelled. Subsequent IIHs sent by the starting router have the RR and RA bits clear and the SA bit set in the restart TLV. Timer T1 is cancelled after some pre-determined number of expirations (which MAY be 1). When the T2 timer(s) are cancelled or expire transmission of "normal" IIHs (with RR, RA, and SA bits clear) will begin. 3.3.3 Multiple levels A router which is operating as both a Level 1 and a Level 2 router on a particular interface MUST perform the above operations for each level. On a LAN interface, it MUST send and receive both Level 1 and Level 2 IIHs and perform the CSNP synchronizations independently for each level. On a pt-pt interface, only a single IIH (indicating support for both levels) is required, but it MUST perform the CSNP synchronizations independently for each level. Shand, Ginsberg Expires Jul 2004 [Page 11] INTERNET DRAFT IS-IS restart Jan 2004 3.4 Database synchronization When a router is started or restarted it can expect to receive a (set of) CSNP(s) over each interface. The arrival of the CSNP(s) is now guaranteed, since an IIH with RR bit set will be retransmitted until the CSNP(s) are correctly received. The CSNPs describe the set of LSPs that are currently held by each neighbor. Synchronization will be complete when all these LSPs have been received. When (re)starting, a router starts an instance of timer T2 for each LSPDB as described in 4.3.1 or 4.3.2. In addition to normal processing of the CSNPs, the set of LSPIDs contained in the first complete set of CSNP(s) received over each interface is recorded, together with their remaining lifetime. In the case of a LAN interface, a complete set of CSNPs MUST consist of CSNPs received from neighbor(s) which are not restarting. If there are multiple interfaces on the (re)starting router, the recorded set of LSPIDs is the union of those received over each interface. LSPs with a remaining lifetime of zero are NOT so recorded. As LSPs are received (by the normal operation of the update process) over any interface, the corresponding LSPID entry is removed (it is also removed if the LSP had arrived before the CSNP containing the reference). When an LSPID has been held in the list for its indicated remaining lifetime, it is removed from the list. When the list of LSPIDs is empty and the timer T1 has been cancelled for all the interfaces that have an adjacency at this level, the timer T2 is cancelled. At this point the local database is guaranteed to contain all the LSP(s) (either the same sequence number, or a more recent sequence number) which were present in the neighbors' databases at the time of (re)starting. LSPs that arrived in a neighbor's database after the time of (re)starting may or may not be present, but the normal operation of the update process will guarantee that they will eventually be received. At this point the local database is deemed to be "synchronized". Since LSPs mentioned in the CSNP(s) with a zero remaining lifetime are not recorded, and those with a short remaining lifetime are deleted from the list when the lifetime expires, cancellation of the timer T2 will not be prevented by waiting for an LSP that will never arrive. 3.4.1 LSP generation and flooding and SPF computation The operation of a router starting, as opposed to restarting is somewhat different. These two cases are dealt with separately below. Shand, Ginsberg Expires Jul 2004 [Page 12] INTERNET DRAFT IS-IS restart Jan 2004 3.4.1.1. Restarting In order to avoid causing unnecessary routing churn in other routers, it is highly desirable that the own LSPs generated by the restarting system are the same as those previously present in the network (assuming no other changes have taken place). It is important therefore not to regenerate and flood the LSPs until all the adjacencies have been re-established and any information required for propagation into the local LSPs is fully available. Ideally, the information is loaded into the LSPs in a deterministic way, such that the same information occurs in the same place in the same LSP (and hence the LSPs are identical to their previous versions). If this can be achieved, the new versions may not even cause SPF to be run in other systems. However, provided the same information is included in the set of LSPs (albeit in a different order, and possibly different LSPs), the result of running the SPF will be the same and will not cause churn to the forwarding tables. In the case of a restarting router, none of the router's own LSPs are transmitted, nor are the router's own forwarding tables updated while the timer T3 is running. Redistribution of inter-level information MUST be regenerated before this router's LSP is flooded to other nodes. Therefore the Level-n non-pseudonode LSP(s) MUST NOT be flooded until the other level's T2 timer has expired and its SPF has been run. This ensures that any inter-level information which is to be propagated can be included in the Level-n LSP(s). During this period, if one of the router's own (including pseudonodes) LSPs is received, which the local router does not currently have in its own database, it is NOT purged. Under normal operation, such an LSP would be purged, since the LSP clearly should not be present in the global LSP database. However, in the present circumstances, this would be highly undesirable, because it could cause premature removal of an own LSP - and hence churn in remote routers. Even if the local system has one or more own LSPs (which it has generated, but not yet transmitted) it is still not valid to compare the received LSP against this set, since it may be that as a result of propagation between Level 1 and Level 2 (or vice versa) a further own LSP will need to be generated when the LSP databases have synchronized. During this period a restarting router SHOULD send CSNPs as it normally would. Information about the router's own LSPs MAY be included, but if it is included it MUST be based on LSPs which have been received, not on versions which have been generated (but not Shand, Ginsberg Expires Jul 2004 [Page 13] INTERNET DRAFT IS-IS restart Jan 2004 yet transmitted). This restriction is necessary to prevent premature removal of an LSP from the global LSP database. When the timer T2 expires or is cancelled indicating that synchronization for that level is complete, the SPF for that level is run in order to derive any information which is required to be propagated to another level, but the forwarding tables are not yet updated. Once the other level's SPF has run and any inter-level propagation has been resolved, the own LSPs can be generated and flooded. Any own LSPs which were previously ignored, but which are not part of the current set of own LSPs (including pseudonodes) MUST then be purged. Note that it is possible that a Designated Router change may have taken place, and consequently the router SHOULD purge those pseudonode LSPs which it previously owned, but which are now no longer part of its set of pseudonode LSPs. When all the T2 timers have expired or been cancelled, the timer T3 is cancelled and the local forwarding tables are updated. If the timer T3 expires before all the T2 timers have expired or been cancelled, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and therefore other routers MUST NOT compute routes through this router). Normal operation of the update process resumes and the local forwarding tables are updated. In order to prevent the neighbor's adjacencies from expiring, IIHs with the normal interface value for the holding time are transmitted over all interfaces with neither RR nor RA set in the restart TLV. This will cause the neighbors to refresh their adjacencies. The own LSP(s) will continue to have the overload bit set until timer T2 has expired or been cancelled. 3.4.1.2. Starting In the case of a starting router, as soon as each adjacency is established, and before any CSNP exchanges, the router's own zeroth LSP is transmitted with the overload bit set. This prevents other routers from computing routes through the router until it has reliably acquired the complete set of LSPs. The overload bit remains set in subsequent transmissions of the zeroth LSP (such as will occur if a previous copy of the routers LSP is still present in the network) while any timer T2 is running. When all the T2 timers have been cancelled, the own LSP(s) MAY be regenerated with the overload bit clear (assuming the router isn't Shand, Ginsberg Expires Jul 2004 [Page 14] INTERNET DRAFT IS-IS restart Jan 2004 in fact overloaded, and there is no other reason, such as incomplete BGP convergence, to keep the overload bit set), and flooded as normal. Other own LSPs (including pseudonodes) are generated and flooded as normal, irrespective of the timer T2. The SPF is also run as normal and the RIB and FIB updated as routes become available. To avoid the possible formation of temporary blackholes the starting router sets the SA bit in the restart TLV (as described in 4.3.2) in all IIHs that it sends. When all T2 timers have been cancelled the starting router MUST transmit IIHs with the SA bit clear. Shand, Ginsberg Expires Jul 2004 [Page 15] INTERNET DRAFT IS-IS restart Jan 2004 4. State Tables This section presents state tables which summarize the behaviors described in this document. Other behaviors, in particular adjacency state transitions and LSP database update operation, are NOT included in the state tables except where this document modifies the behaviors described in [3] and [5]. The states named in the columns of the tables below are a mixture of states that are specific to a single adjacency (ADJ suppressed, ADJ Seen RA, ADJ Seen CSNP) and states which are indicative of the state of the protocol instance (Running, Restarting, Starting, SPF Wait). Three state tables are presented from the point of view of a running router, a restarting router, and a starting router. 4.1 Running Router Event | Running | ADJ suppressed ============================================================== RX RR | Maintain ADJ State | | Send RA | | Set SRM,send CSNP | | (Note 1) | | Update Hold Time, | | set Restart Mode | | (Note 2) | -------------+----------------------+------------------------- RX RR clr | Clr Restart mode | -------------+----------------------+------------------------- RX SA | Suppress IS neighbor | | TLV in LSP(s) | | Goto ADJ Suppressed | -------------+----------------------+------------------------- RX SA clr | |Unsuppress IS neighbor | | TLV in LSP(s) | |Goto Running ============================================================== Note 1: CSNPs are sent by routers in accordance with Section 3.2.1c Note 2: If Restart Mode clear Shand, Ginsberg Expires Jul 2004 [Page 16] INTERNET DRAFT IS-IS restart Jan 2004 4.2 Restarting Router Event | Restarting | ADJ Seen | ADJ Seen | SPF Wait | | RA | CSNP | =================================================================== Router | Send IIH/RR | | | restarts | ADJ Init | | | | Start T1,T2,T3 | | | ------------+--------------------+-----------+-----------+------------ RX RR | Send RA | | | ------------+--------------------+-----------+-----------+------------ RX RA | Adjust T3 | | Cancel T1 | | Goto ADJ Seen RA | | Adjust T3 | ----------- +--------------------+-----------+-----------+------------ RX CSNP set| Goto ADJ Seen CSNP | Cancel T1 | | ------------+--------------------+-----------+-----------+------------ RX IIH w/o | Cancel T1 (Point- | | | Restart TLV| to-point only) | | | ------------+--------------------+-----------+-----------+------------ T1 Expires | Send IIH/RR |Send IIH/RR|Send IIH/RR| | Restart T1 | Restart T1| Restart T1| ------------+--------------------+-----------+-----------+------------ T1 Expires | Send IIH/ | Send IIH/ | Send IIH/ | nth time | normal | normal | normal | ------------+--------------------+-----------+-----------+------------ T2 expires | Trigger SPF | | | | Goto SPF Wait | | | ------------+--------------------+-----------+-----------+------------ T3 expires | Set OL | | | | Flood local LSPs | | | | Update fwd plane | | | ------------+--------------------+-----------+-----------+------------ LSP DB Sync| Cancel T2, and T3 | | | | Trigger SPF | | | | Goto SPF wait | | | ------------+--------------------+-----------+-----------+------------ All SPF | | | | Clear OL done | | | | Update fwd | | | | plane | | | | Flood local | | | | LSPs | | | | Goto Runing ====================================================================== Shand, Ginsberg Expires Jul 2004 [Page 17] INTERNET DRAFT IS-IS restart Jan 2004 4.3 Starting Router Event | Starting | ADJ Seen RA| ADJ Seen CSNP ============================================================= Router | Send IIH/SA | | starts | Start T1,T2 | | -------------+-------------------+------------+--------------- RX RR | Send RA | | -------------+-------------------+------------+--------------- RX RA | Goto ADJ Seen RA | | Cancel T1 -------------+-------------------+------------+--------------- RX CSNP Set | Goto ADJ Seen CSNP| Cancel T1 | -------------+-------------------+------------+--------------- RX IIH w | Cancel T1 | | no Restart | (Point-to-Point | | TLV | only) | | -------------+-------------------+------------+--------------- ADJ UP | Start T1 | | | Send local LSPs | | | w OL | | -------------+-------------------+------------+--------------- T1 Expires | Send IIH/RR |Send IIH/RR | Send IIH/RR | and SA | and SA | and SA | Restart T1 |Restart T1 | Restart T1 -------------+-------------------+------------+--------------- T1 Expires | Send IIH/SA |Send IIH/SA | Send IIH/SA nth time | | | -------------+-------------------+------------+--------------- T2 expires | Clear OL | | | Send IIH normal | | | Goto Running | | -------------+-------------------+------------+--------------- LSP DB Sync | Cancel T2 | | | Clear OL | | | Send IIH normal | | ============================================================== Shand, Ginsberg Expires Jul 2004 [Page 18] INTERNET DRAFT IS-IS restart Jan 2004 5. Security Considerations Any new security issues raised by the procedures in this document depend upon the ability of an attacker to inject a false but apparently valid IIH, the ease/difficulty of which has not been altered. If the RR bit is set in a false IIH, neighbors who receive such an IIH will continue to maintain an existing adjacency in the UP state and may (re)send a complete set of CSNPs. While the latter action is wasteful, neither action causes any disruption in correct protocol operation. If the RA bit is set in a false IIH, a (re)starting router which receives such an IIH may falsely believe that there is a neighbor on the corresponding interface which supports the procedures described in this document. In the absence of receipt of a complete set of CSNPs on that interface, this could delay the completion of (re)start procedures by requiring the timer T1 to time out the locally defined maximum number of retries. This behavior is the same as would occur on a LAN where none of the (re)starting router's neighbors support the procedures in this document and is covered in Sections 3.3.1 and 3.3.2. If an SA bit is set in a false IIH, this could cause suppression of the advertisement of an IS neighbor which could either continue for an indefinite period or occur intermittently with the result being possible loss of reachability to some destinations in the network and/or increased frequency of LSP flooding and SPF calculation. The possibility of IS-IS PDU spoofing can be reduced by the use of authentication as described in [2] and [3], and especially the use of cryptographic authentication as described in [6]. 6. IANA Considerations This document defines the following new ISIS TLV that needs to be reflected in the ISIS TLV code-point registry: Type Description IIH LSP SNP ---- ----------------------------------- --- --- --- 211 Restart TLV y n n Shand, Ginsberg Expires Jul 2004 [Page 19] INTERNET DRAFT IS-IS restart Jan 2004 7. Normative References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990. 3 ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002, Second Edition. 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5 Katz, D., and Saluja, R., "Three-Way Handshake for IS-IS Point- to-Point Adjacencies", RFC 3373, September 2002 6 Li, T., and Atkinson, R., "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003 7 Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26 , RFC 2434, October 1998 8. Acknowledgments The authors would like to acknowledge contributions made by Jeff Parker, Radia Perlman, Mark Schaefer, Naiming Shen, Nischal Sheth, Russ White, and Rena Yang. 9. Authors' Addresses Mike Shand Cisco Systems 250 Longwater Avenue, Reading, Berkshire, RG2 6GB UK Phone: +44 208 824 8690 Email: mshand@cisco.com Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, Ca. 95035 USA Email: ginsberg@cisco.com Shand, Ginsberg Expires Jul 2004 [Page 20] INTERNET DRAFT IS-IS restart Jan 2004 10. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Shand, Ginsberg Expires Jul 2004 [Page 21] --=====================_60164712==_-- From rtg-dir-admin@ietf.org Mon Jan 12 15:44:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18020 for ; Mon, 12 Jan 2004 15:44:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag8vF-0006lu-00 for rtg-dir-archive@ietf.org; Mon, 12 Jan 2004 15:44:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag8tI-0006cq-00 for rtg-dir-archive@ietf.org; Mon, 12 Jan 2004 15:42:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag8rv-0006W4-00 for rtg-dir-archive@ietf.org; Mon, 12 Jan 2004 15:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8rv-0004AQ-D3; Mon, 12 Jan 2004 15:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag8r6-00047z-Ak for rtg-dir@optimus.ietf.org; Mon, 12 Jan 2004 15:40:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17760 for ; Mon, 12 Jan 2004 15:40:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag8r4-0006SI-00 for rtg-dir@ietf.org; Mon, 12 Jan 2004 15:40:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag8pA-0006Nm-00 for rtg-dir@ietf.org; Mon, 12 Jan 2004 15:38:12 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ag8nk-0006Jl-00 for rtg-dir@ietf.org; Mon, 12 Jan 2004 15:36:44 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ag8nf-000M9E-8O; Mon, 12 Jan 2004 20:36:39 +0000 Date: Mon, 12 Jan 2004 12:33:54 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <130437179390.20040112123354@psg.com> To: Les Ginsberg CC: Jeff Parker , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , , Tony Li Subject: Re: AD-review comments on draft-ietf-isis-restart-05.txt In-Reply-To: <4.3.2.7.2.20040112074223.01b937f8@mira-sjc5-3.cisco.com> References: <4.3.2.7.2.20040109151927.01be2eb0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040109151927.01be2eb0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040112074223.01b937f8@mira-sjc5-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Thanks, Les! Looks great. We're ready to move on. I just requested that the IETF LC is started for it. -- Alex Monday, January 12, 2004, 7:45:00 AM, Les Ginsberg wrote: > Alex - > Attached is a new version which addresses the security issues discussed > below. Only the Security section has changed from the previous version. > Please let us know if that adequately addresses your concerns. > Thanx. > Les > At 07:33 PM 1/9/2004 -0800, Alex Zinin wrote: >>Les, >> >> >> > Alex - >> >> > Probably a good thing if we discuss this... :-) >> >> > The answer to your question is obviously "yes" - but what is the >> > significance of this? >> >> > First, the introduction of the restart TLV into IIHs does not make IIHs >> > easier/harder to spoof. >> >>Agreed. The adversary's work function hasn't changed, though the list of >>attacks did. >> >> > Now, if someone is able to spoof an IIH, what happens if we receive an >> > IIH-RR? If we currently have an adjacency in UP state, it remains in UP >> > state. No problem there. And, we may also trigger the sending of a set of >> > CSNPs. This would be a waste of cycles, but should cause no harm. >> >> > Now, what happens if we receive a spoofed IIH-RA? This is only significant >> > to a (re)starting router of course. It might cause T1 to be cancelled on a >> > circuit (if we also had received a complete set of CSNPs on that circuit). >> > That should not be a problem. In the case that none of our neighbors >> > actually support restart, it would prevent T1 from being cancelled on that >> > circuit immediately. Which just means it might take a bit longer for >> > restart to complete because we would have to wait for "N" expirations >> of T1 >> > on that circuit. >> >> > None of this seemed worthy of mention, but if you disagree we can add >> > something. >> >>The above is essentially a security analysis for those bits :) >>Something along these lines would be useful in the security section, >>as otherwise it will read as if the RR and RA bits haven't been >>analyzed. It should also make the draft easier to pass the review >>by the SEC ADs in the IESG. >> >>Regards >> >>Alex >> >> > We did discuss SA because spoofing in that case could have consequences >> > which are not possible without the SA bit. >> >> > If others feel that something is lacking, please say so. >> >> > Les From rtg-dir-admin@ietf.org Mon Jan 12 16:24:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20691 for ; Mon, 12 Jan 2004 16:24:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9Xv-00016a-00 for rtg-dir-archive@ietf.org; Mon, 12 Jan 2004 16:24:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9Vy-0000v4-00 for rtg-dir-archive@ietf.org; Mon, 12 Jan 2004 16:22:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ag9Ud-0000ov-00 for rtg-dir-archive@ietf.org; Mon, 12 Jan 2004 16:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9Ud-0005rW-J4; Mon, 12 Jan 2004 16:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ag9Tn-0005pq-Im for rtg-dir@optimus.ietf.org; Mon, 12 Jan 2004 16:20:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20435 for ; Mon, 12 Jan 2004 16:20:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ag9Tl-0000mv-00 for rtg-dir@ietf.org; Mon, 12 Jan 2004 16:20:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ag9S1-0000jr-00 for rtg-dir@ietf.org; Mon, 12 Jan 2004 16:18:22 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ag9RG-0000fY-00 for rtg-dir@ietf.org; Mon, 12 Jan 2004 16:17:34 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ag9RB-0001AU-Pp; Mon, 12 Jan 2004 21:17:30 +0000 Date: Mon, 12 Jan 2004 13:14:25 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <22439610426.20040112131425@psg.com> To: Les Ginsberg CC: Jeff Parker , Christian Hopps , Acee Lindem , Mike Shand , Tony Przygienda , , Tony Li Subject: Re: AD-review comments on draft-ietf-isis-restart-05.txt In-Reply-To: <4.3.2.7.2.20040112074223.01b937f8@mira-sjc5-3.cisco.com> References: <4.3.2.7.2.20040109151927.01be2eb0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040105095626.01add5f0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040109151927.01be2eb0@mira-sjc5-3.cisco.com> <4.3.2.7.2.20040112074223.01b937f8@mira-sjc5-3.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Les, I just realized that you have to submit the new rev before the LC is started :) Please do so asap. -- Alex http://www.psg.com/~zinin/ Monday, January 12, 2004, 7:45:00 AM, Les Ginsberg wrote: > Alex - > Attached is a new version which addresses the security issues discussed > below. Only the Security section has changed from the previous version. > Please let us know if that adequately addresses your concerns. > Thanx. > Les > At 07:33 PM 1/9/2004 -0800, Alex Zinin wrote: >>Les, >> >> >> > Alex - >> >> > Probably a good thing if we discuss this... :-) >> >> > The answer to your question is obviously "yes" - but what is the >> > significance of this? >> >> > First, the introduction of the restart TLV into IIHs does not make IIHs >> > easier/harder to spoof. >> >>Agreed. The adversary's work function hasn't changed, though the list of >>attacks did. >> >> > Now, if someone is able to spoof an IIH, what happens if we receive an >> > IIH-RR? If we currently have an adjacency in UP state, it remains in UP >> > state. No problem there. And, we may also trigger the sending of a set of >> > CSNPs. This would be a waste of cycles, but should cause no harm. >> >> > Now, what happens if we receive a spoofed IIH-RA? This is only significant >> > to a (re)starting router of course. It might cause T1 to be cancelled on a >> > circuit (if we also had received a complete set of CSNPs on that circuit). >> > That should not be a problem. In the case that none of our neighbors >> > actually support restart, it would prevent T1 from being cancelled on that >> > circuit immediately. Which just means it might take a bit longer for >> > restart to complete because we would have to wait for "N" expirations >> of T1 >> > on that circuit. >> >> > None of this seemed worthy of mention, but if you disagree we can add >> > something. >> >>The above is essentially a security analysis for those bits :) >>Something along these lines would be useful in the security section, >>as otherwise it will read as if the RR and RA bits haven't been >>analyzed. It should also make the draft easier to pass the review >>by the SEC ADs in the IESG. >> >>Regards >> >>Alex >> >> > We did discuss SA because spoofing in that case could have consequences >> > which are not possible without the SA bit. >> >> > If others feel that something is lacking, please say so. >> >> > Les From rtg-dir-admin@ietf.org Wed Jan 14 04:21:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06704 for ; Wed, 14 Jan 2004 04:21:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AghDZ-0004GP-00 for rtg-dir-archive@ietf.org; Wed, 14 Jan 2004 04:21:41 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AghAI-0003uh-00 for rtg-dir-archive@ietf.org; Wed, 14 Jan 2004 04:18:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AghA1-0002o3-2K; Wed, 14 Jan 2004 04:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Agh9K-0002mb-SL for rtg-dir@optimus.ietf.org; Wed, 14 Jan 2004 04:17:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06522 for ; Wed, 14 Jan 2004 04:17:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Agh9D-0003rn-00 for rtg-dir@ietf.org; Wed, 14 Jan 2004 04:17:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Agh19-0003dH-00 for rtg-dir@ietf.org; Wed, 14 Jan 2004 04:08:52 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aggyt-0003Tg-00 for rtg-dir@ietf.org; Wed, 14 Jan 2004 04:06:31 -0500 Received: from lsanca1-ar41-4-61-159-240.lsanca1.dsl-verizon.net ([4.61.159.240] helo=rtg-dir) by mx2.foretec.com with smtp (Exim 4.24) id 1Aggyt-0007pI-Tx for rtg-dir@ietf.org; Wed, 14 Jan 2004 04:06:32 -0500 Message-ID: From: "Rserpool" Date: Wed, 14 Jan 2004 01:07:14 +0200 To: rtg-dir@ietf.org Subject: Re: Herba.l Products of the year, 2003 MIME-Version: 1.0 Content-Type: text/html; charset=windows-1251 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.8 required=5.0 tests=ALL_NATURAL,AMAZING_STUFF,AWL, BIZ_TLD,DATE_IN_PAST_06_12,HG_HORMONE,HTML_50_60,HTML_FONTCOLOR_BLUE, HTML_FONTCOLOR_RED,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY, UPPERCASE_25_50 autolearn=no version=2.60 X-Spam-Report: * 1.3 ALL_NATURAL BODY: Spam is 100% natural?! * 2.6 AMAZING_STUFF BODY: Amazing Stuff * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.6 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date * 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag * 2.0 HG_HORMONE Talks about hormones for human growth * 0.3 UPPERCASE_25_50 message body is 25-50% uppercase * 0.0 AWL AWL: Auto-whitelist adjustment Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA06523 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable
Welcome To Herbal World!
Check Out Just Some Of Our Amazing Products.
Their all 100% Natural With Our 100% Mo.ney Back Guaran.tee!

HGH:
Turns Back Your Aging Process Naturally! Look 20 YEARS YOUNGER!
READ MORE INFO HERE

MAGNA-RX PATCH:
Increase Pe.nis Size By 2=92= =92 To 4=92=92.Your Pe.nis Will Be Thicker And Fuller.
READ MORE INFO HERE

ALPHA MALE PLUS:
Maintain harder, stronger e= rect.ions for hours. Have amazing se.x up to 20 times per day.
READ MORE INFO HERE

HERBAL-RX DIET PATCH:
Advanced appetite sup= pressant, metabolism booster, and energy enhancer.....all in one!
READ MORE INFO HERE

Real Doctors, Real Science, Real Results!


no more emailz

From rtg-dir-admin@ietf.org Thu Jan 15 05:17:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23252 for ; Thu, 15 Jan 2004 05:17:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah4ZE-0001hQ-00 for rtg-dir-archive@ietf.org; Thu, 15 Jan 2004 05:17:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah4Wm-0001Ck-00 for rtg-dir-archive@ietf.org; Thu, 15 Jan 2004 05:15:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ah4VW-00013i-04 for rtg-dir-archive@ietf.org; Thu, 15 Jan 2004 05:13:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah4Qw-0001BL-Ed; Thu, 15 Jan 2004 05:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ah4QG-00015p-Ue for rtg-dir@optimus.ietf.org; Thu, 15 Jan 2004 05:08:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22741 for ; Thu, 15 Jan 2004 05:08:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ah4QD-0000q5-00 for rtg-dir@ietf.org; Thu, 15 Jan 2004 05:08:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ah4PF-0000nB-00 for rtg-dir@ietf.org; Thu, 15 Jan 2004 05:07:17 -0500 Received: from ao1-m28.net.hinet.hr ([195.29.32.28] helo=rtg-dir) by ietf-mx with smtp (Exim 4.12) id 1Ah4OI-0000le-00 for rtg-dir@ietf.org; Thu, 15 Jan 2004 05:06:19 -0500 Message-ID: From: "Mercurio" Date: Thu, 15 Jan 2004 10:28:11 +0300 To: rtg-dir@ietf.org Subject: Fwd: Ejacu.late Like A P0RN Star MIME-Version: 1.0 Content-Type: text/html; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA22742 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=BIZ_TLD,FORGED_YAHOO_RCVD, HTML_60_70,HTML_FONTCOLOR_RED,HTML_FONT_BIG,HTML_MESSAGE,INCREASE_SEX, LINES_OF_YELLING,LINES_OF_YELLING_2,MIME_HTML_ONLY,UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable cumpills2
SHOWER YOUR LOVER WITH
BUCKET= LOADS OF SP.ERM!
=A0

It's Amazing & Has Finally Arrived! A Unique Pill That Will Increase Your Spe.rm By Up To 500% More -We Guaranteed It!

Maintain Rock Solid Erect.ions.
Increased Sex.ual Desire & Performance.
- Shoot Out Amazing Amounts Of Spe.rm Everywhere.
- Multiple Extreme Orga.sms! Have 2 Or 3 Each Time.
- 100% Mon.ey Back Guarantee With Every Order.
=A0

EJAC= U.LATE LIKE A PO.RN STAR

<= a hrefKiddehref=3Dhttp://bundles.com href=3D "http://www.bonkey.biz/kadafi/">READ MORE INFO HERE
=A0
=A0

no more emailz

=20 From rtg-dir-admin@ietf.org Sat Jan 17 22:10:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25163 for ; Sat, 17 Jan 2004 22:10:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ai3KV-0004Dq-00 for rtg-dir-archive@ietf.org; Sat, 17 Jan 2004 22:10:27 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ai3K4-0004Bm-00 for rtg-dir-archive@ietf.org; Sat, 17 Jan 2004 22:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ai3K6-0005Ye-Ds; Sat, 17 Jan 2004 22:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ai3Jc-0005Xf-5J for rtg-dir@optimus.ietf.org; Sat, 17 Jan 2004 22:09:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25145 for ; Sat, 17 Jan 2004 22:09:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ai3JY-0004Bf-00 for rtg-dir@ietf.org; Sat, 17 Jan 2004 22:09:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ai3Ib-0004AJ-00 for rtg-dir@ietf.org; Sat, 17 Jan 2004 22:08:30 -0500 Received: from p508fa2bf.dip.t-dialin.net ([80.143.162.191] helo=80.143.162.191) by ietf-mx with smtp (Exim 4.12) id 1Ai3I1-00048c-00 for rtg-dir@ietf.org; Sat, 17 Jan 2004 22:07:56 -0500 Date: Sat, 17 Jan 2004 21:03:19 -0600 From: 241763@mail.com X-Mailer: Web Mail 5.0.11-9 Reply-To: 241763@earthlink.net Organization: 429270637 X-Priority: 3 (Normal) To: rtg-dir@ietf.org Subject: OEM Software 241763 MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.2 required=5.0 tests=FROM_ALL_NUMS, FROM_ENDS_IN_NUMS,FROM_STARTS_WITH_NUMS,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_MESSAGE,HTML_TAG_BALANCE_A, HTML_TAG_BALANCE_TABLE,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, NO_REAL_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.6 FROM_STARTS_WITH_NUMS From: starts with nums * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.1 HTML_TAG_BALANCE_A BODY: HTML has excess "a" close tags * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.2 HTML_TAG_BALANCE_TABLE BODY: HTML is missing "table" close tags * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.2 FROM_ALL_NUMS From an address that is all numbers (non-phone) Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit OEM Software

Specials good thru 11/12/03. Please use discount code mail9221 to receive these prices.

Software: Windows XP Suites, Adobe software, Clearance, Corel Draw/Corel Ventura, Games, 3D Studio Max, Operating Systems, Utilities.
Microsoft Windows XP Professional OEM 

PowerQuest Partition Magic 8 (CD and Manual) Only $39.95  
Savings -$49.50

Microsoft Windows XP Professional goes beyond the benefits of Windows XP Home Edition with advanced capabilities designed specifically to.. PowerQuest Partition Magic 8 (CD and Manual)
* Use this Discount Code at Checkout: mail9872

Adobe Photoshop 7.0 OEM

Microsoft Works Suite 2003 (OEM) W/ Word 2002 Only $59.95
Savings -$255.50

Adobe Photoshop 7.0 software the professional image-editing standard helps you work more efficiently.. Microsoft Works Suite 2003 (OEM) W/ Word 2002
* Use this Discount Code at Checkout: mail9872

Microsoft Office XP Professional OEM

Symantec pcAnywhere 10.5 Host/Remote OEM CD Only $59.95
Savings -$50.50

Microsoft Windows XP Professional is a Windows operating system designed for businesses of all sizes and for individuals who demand the most from their computing Symantec pcAnywhere 10.5 Host/Remote OEM CD
* Use this Discount Code at Checkout: mail9872


Adobe Illustrator 10 OEM

Symantec Norton SystemWorks 2003 Pro OEM CD Only $59.95
Savings -$215.50

ENHANCED! Adobe Illustrator 10 software defines the future of vector graphics with groundbreaking creative options and powerful tools for efficiently publishing artwork on the Web, in print, everywhere...  Symantec Norton SystemWorks 2003 Pro OEM CD
* Use this Discount Code at Checkout: mail9872

From rtg-dir-admin@ietf.org Tue Jan 20 02:41:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17422 for ; Tue, 20 Jan 2004 02:41:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiqW8-0004Yk-00 for rtg-dir-archive@ietf.org; Tue, 20 Jan 2004 02:41:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiqTJ-0004SR-00 for rtg-dir-archive@ietf.org; Tue, 20 Jan 2004 02:38:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AiqRr-0004Nj-00 for rtg-dir-archive@ietf.org; Tue, 20 Jan 2004 02:37:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiqRa-0000sx-5Z; Tue, 20 Jan 2004 02:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AiqQb-0000oj-Ig for rtg-dir@optimus.ietf.org; Tue, 20 Jan 2004 02:36:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17322 for ; Tue, 20 Jan 2004 02:35:53 -0500 (EST) Resent-From: tbjfviqyyjc@rbaosemtv.everymakeup.info Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AiqQN-0004Li-00 for rtg-dir@ietf.org; Tue, 20 Jan 2004 02:35:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AiqPC-0004Ix-00 for rtg-dir@ietf.org; Tue, 20 Jan 2004 02:34:35 -0500 Received: from [216.193.200.21] (helo=default) by ietf-mx with esmtp (Exim 4.12) id 1AiqNh-0004Fc-00 for rtg-dir@ietf.org; Tue, 20 Jan 2004 02:33:01 -0500 Received: from ietf-mx.ietf.org (132.151.6.1) by with SMTP id DOX5UCGQOP5; Tue, 20 Jan 2004 03:06:40 -0400 Received: from iwnym.everymakeup.info (HELO iwnym) (172.16.67.239) by ietf-mx.ietf.org with SMTP; Tue, 20 Jan 2004 03:06:40 -0400 Reply-To: From: "Auel Un" Resent-To: rtg-dir@ietf.org To: "Rtg Pkmk" References: In-Reply-To: Subject: Headline NEWS - Modern Miracles Date: Tue, 20 Jan 2004 03:06:40 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/html; charset="US-ASCII" X-BBounce: list20007 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Resent-Message-Id: Resent-Date: Tue, 20 Jan 2004 02:33:01 -0500 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA17323 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.7 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE, HTML_FONT_BIG,HTML_FONT_INVISIBLE,HTML_MESSAGE,HTML_TAG_BALANCE_BODY, HTML_TAG_BALANCE_HTML,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable NEW Treatment Makes You Look Years Younger!
=A0
Beauty Secrets Newsletter
By: Jamie And= erton - Freelance Writer & Beauty Expert
<= /td>
=

Better than = Lip Injections?
.....................= .........................................................................= ......
Have you ever w= anted to get collagen injections? My research found an excellent pain=96f= ree option for you ladies that don't want to spend thousands of dollars o= n surgery....

Dear Jamie, Have= you ever heard of C'ity L'ips? One of my girlfriends uses i= t constantly and she swears up and down that it has really made her lips = bigger after just a few short weeks. I've wanted to get collagen injectio= ns for years but it's so expensive. Do you think C'ity L'ips w= ill make my lips fuller?

Amber Davies
New= port Beach, CA

=

Well Amber, I pers= onally interviewed a world renowned biochemist who developed the C= 'ity L'ips formula. I walked away from that interview with a ne= w respect for modern cosmetics. C'ity L'ips convinced me= that they have the most advanced Collagen Building Treatment available t= hat is different than any other product on the market today claiming to b= e a "lip plumper".

C'ity L'ips uses a unique Oligopeptide Technologythat stimulates lips to increase production of their own collagen an= d hyaluronic acid. C'ity L'ips then adds Celadrol=99<= /font> to protect the= new collagen from breakdown. Celadrol=99 is also a patented anti-inflamm= atory. How can an anti-inflammatory help plump your lips? That's exactly = what I asked! Celadrol helps retain moisture and repair damaged tissue, m= aking your lips full and healthy. He also pointed out that other lip plum= pers have harsh spices that irritate your lips and inflame them. C= 'ity L'ips actually builds collagen, making your lips grow!

SAVE THIS ARTICLE

:
:
:
:
:
::
:
:
:
:
:
:
:
:

C'ity L'ips impressed me with the shocking= revelation that they have had less than a 1% return rate on their Lip Pl= umping Treatment! City Lips is Guaranteed to work or your Money Back.
C'= ity L'ips is an International company that has cu= stomers in 70 countries. Movie stars, celebrities, doctors, and people = of all walks of life use C'ity= L'ips everyday=97They must = be doing something right!

C'ity L'ips is = a highly effective and inexpensive alternative to collagen injections. =A0= More Details HERE... =

=96 Jamie Anderton





Greetings to Beauty_News subscribers, members, and clients. This mess= age is intended for rtg-dir at ietf.org.=20 To update or cancel your subscription go to
http://nine.beauty-tip.info/cgi-local/u.cgi?e=3Drtg-dir!ietf.org&l=3Dlist= 20007




oplmlbxx nnlehfzx czqxqqqctkmc kazblrxdwpk fjvbygkwnu bczmgtm wwmjyix
zchrmwfjn wfwcvisfh elsgboy wtbagynkwnr pgttcbbql gsdvvkspvon nlcmptleo emmubqybjo atzflvxopwx lfmcdobbknwy jadxndnznn tsujusdnz ucsptkyw iqvodlr= qfcfn
jlagbui contqgqo xxucaof memlyxzevcn

From rtg-dir-admin@ietf.org Wed Jan 21 09:16:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22014 for ; Wed, 21 Jan 2004 09:16:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjJ9T-0007E9-00 for rtg-dir-archive@ietf.org; Wed, 21 Jan 2004 09:16:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjJ8X-00079E-00 for rtg-dir-archive@ietf.org; Wed, 21 Jan 2004 09:15:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjJ7V-00071o-00 for rtg-dir-archive@ietf.org; Wed, 21 Jan 2004 09:14:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjJ7L-0004Hd-Gn; Wed, 21 Jan 2004 09:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjJ6g-0004Dt-Mk for rtg-dir@optimus.ietf.org; Wed, 21 Jan 2004 09:13:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21725 for ; Wed, 21 Jan 2004 09:13:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjJ6f-0006xZ-00 for rtg-dir@ietf.org; Wed, 21 Jan 2004 09:13:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjJ5j-0006ph-00 for rtg-dir@ietf.org; Wed, 21 Jan 2004 09:12:24 -0500 Received: from pcp01520295pcs.potsvl01.pa.comcast.net ([68.82.95.222] helo=rtg-dir) by ietf-mx with smtp (Exim 4.12) id 1AjJ4Z-0006hz-00 for rtg-dir@ietf.org; Wed, 21 Jan 2004 09:11:11 -0500 Message-ID: From: "Rserpool" Date: Wed, 21 Jan 2004 09:14:43 -0000 To: rtg-dir@ietf.org Subject: Don't get busted ! ! . . . . . . . . . steaming MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,DATE_IN_PAST_03_06, HTML_50_60,HTML_MESSAGE,MANY_EXCLAMATIONS,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: 8bit cleanactpro
Keep Your Job - Keep Your Marriage - Keep Out Of Trouble

DID YOU KNOW!

That anyone who uses your computer can see what websites you've visited?
And that simply deleting history only removes part of the records.
If someone starts typing a web site, your browser will recall old sites you've visited?
Your boss or wife can start typing "www.dateline.com" and the browser will recall "www.datingclub.com"
Every picture on every site you've ever visited has been copied to your hard drive?
Deleting the cache does not permanently remove them!
And there are many more ways you are secretly tracked...


controller , dotted
From rtg-dir-admin@ietf.org Thu Jan 22 02:25:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11560 for ; Thu, 22 Jan 2004 02:25:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjZDc-0004JW-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 02:25:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjZCe-0004IN-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 02:24:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjZC2-0004HI-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 02:23:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjZC5-0003FA-5w; Thu, 22 Jan 2004 02:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjZBj-000399-MX for rtg-dir@optimus.ietf.org; Thu, 22 Jan 2004 02:23:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11400 for ; Thu, 22 Jan 2004 02:23:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjZBf-0004H3-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 02:23:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjZAm-0004G3-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 02:22:40 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AjZA3-0004Eb-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 02:21:55 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjZA4-000LGI-An for rtg-dir@ietf.org; Thu, 22 Jan 2004 07:21:56 +0000 Date: Wed, 21 Jan 2004 23:19:52 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1583905395.20040121231952@psg.com> To: rtg-dir@ietf.org Subject: interesting read: draft-orman-public-key-lengths-07.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit For those interested in information security, the draft in subj is a really great read (on the IESG agenda now). -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Thu Jan 22 17:52:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18098 for ; Thu, 22 Jan 2004 17:52:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajnh0-0005Ac-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 17:52:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajnfy-00051B-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 17:51:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjnfA-0004sR-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 17:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjnfC-0002d6-3Y; Thu, 22 Jan 2004 17:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjneR-0002Wt-OS for rtg-dir@optimus.ietf.org; Thu, 22 Jan 2004 17:50:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17784 for ; Thu, 22 Jan 2004 17:50:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjneP-0004kQ-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 17:50:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjncR-0004J6-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 17:48:14 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AjnYv-0003U1-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 17:44:34 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjnYv-000Khs-Dr for rtg-dir@ietf.org; Thu, 22 Jan 2004 22:44:33 +0000 Date: Thu, 22 Jan 2004 14:43:25 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <359318435.20040122144325@psg.com> To: rtg-dir@ietf.org Subject: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" In-Reply-To: <12758206266.20040122142453@psg.com> References: <12758206266.20040122142453@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This document puts requirements on the routers. Please review carefully, as it's likely to show up in RFPs... -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: routing-discussion@ietf.org Cc: iesg@ietf.org Date: Thursday, January 22, 2004, 2:24:53 PM Subject: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" ===8<==============Original message text=============== Folks- The IESG received a request to publish draft-jones-opsec as a BCP RFC. To ensure wide community review, we are soliciting comments on this document from the routing community. Please send your comments by February 5th, 2004. From the abstract: This document defines a list of operational security requirements for the infrastructure of large IP networks (routers and switches) which are considered to be best current practice (BCP). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors. Comments to: "opsec-comment@ops.ietf.org". When commenting, please use the Routing Area mailing list (routing-discussion@ietf.org). Alex Zinin IETF Routing Area Co-Director ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Thu Jan 22 17:57:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18450 for ; Thu, 22 Jan 2004 17:57:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjnlA-0005WQ-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 17:57:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjnkC-0005VD-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 17:56:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajnjz-0005U1-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 17:55:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajnk1-0002xH-Og; Thu, 22 Jan 2004 17:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjnjN-0002v8-2r for rtg-dir@optimus.ietf.org; Thu, 22 Jan 2004 17:55:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18400 for ; Thu, 22 Jan 2004 17:55:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjnjK-0005T7-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 17:55:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjniW-0005Pn-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 17:54:29 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ajnhl-0005KF-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 17:53:41 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ajnhl-000Ltc-CT for rtg-dir@ietf.org; Thu, 22 Jan 2004 22:53:41 +0000 Date: Thu, 22 Jan 2004 14:52:31 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <8159864280.20040122145231@psg.com> To: rtg-dir@ietf.org Subject: Under IESG review: draft-ietf-nsis-fw-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit This document was on the agenda this morning and will come back in two weeks. I have comments on scalability and routing-related issues that I will forward here today. More review welcome. Send comments by Jan 29th, please. Title: Next Steps in Signaling: Framework Abstract: The Next Steps in Signaling working group is considering protocols for signaling information about a data flow along its path in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for such signaling protocols. This document provides a model for the network entities that take part in such signaling, and the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with a separate upper layers for each specific signaling application. An initial proposal for the split between these layers is given, describing the overall functionality of the lower layer, and discussing the ways that upper layer behavior can be adapted to specific signaling application requirements. This framework also considers the general interactions between signaling and other network layer functions, specifically routing, mobility, and address translators. The different events that impact signaling operation are described, along with how their handling should be divided between the generic and application-specific layers. Finally, an example signaling application (for Quality of Service) is described in more detail. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Thu Jan 22 18:48:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20651 for ; Thu, 22 Jan 2004 18:48:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjoYY-00072V-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 18:48:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjoXg-000718-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 18:47:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjoXM-0006z4-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 18:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjoXN-0003mU-4G; Thu, 22 Jan 2004 18:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjoWe-0003lW-OE for rtg-dir@optimus.ietf.org; Thu, 22 Jan 2004 18:46:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20567 for ; Thu, 22 Jan 2004 18:46:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjoWb-0006xQ-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 18:46:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjoVg-0006vi-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 18:45:17 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AjoUv-0006u6-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 18:44:30 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjoUw-0001EB-0b for rtg-dir@ietf.org; Thu, 22 Jan 2004 23:44:30 +0000 Date: Thu, 22 Jan 2004 15:43:11 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <13962904121.20040122154311@psg.com> To: rtg-dir@ietf.org Subject: Re: Under IESG review: draft-ietf-nsis-fw-05.txt In-Reply-To: <8159864280.20040122145231@psg.com> References: <8159864280.20040122145231@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit and here's the url to it. http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-05.txt -- Alex http://www.psg.com/~zinin/ Thursday, January 22, 2004, 2:52:31 PM, Alex Zinin wrote: > This document was on the agenda this morning and will come back in two > weeks. I have comments on scalability and routing-related issues that > I will forward here today. > More review welcome. Send comments by Jan 29th, please. > Title: Next Steps in Signaling: Framework > Abstract: > The Next Steps in Signaling working group is considering protocols > for signaling information about a data flow along its path in the > network. Based on existing work on signaling requirements, this > document proposes an architectural framework for such signaling > protocols. > This document provides a model for the network entities that take > part in such signaling, and the relationship between signaling and > the rest of network operation. We decompose the overall signaling > protocol suite into a generic (lower) layer, with a separate upper > layers for each specific signaling application. An initial proposal > for the split between these layers is given, describing the overall > functionality of the lower layer, and discussing the ways that upper > layer behavior can be adapted to specific signaling application > requirements. > This framework also considers the general interactions between > signaling and other network layer functions, specifically routing, > mobility, and address translators. The different events that impact > signaling operation are described, along with how their handling > should be divided between the generic and application-specific > layers. Finally, an example signaling application (for Quality of > Service) is described in more detail. From rtg-dir-admin@ietf.org Thu Jan 22 19:47:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21958 for ; Thu, 22 Jan 2004 19:47:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjpTZ-00010N-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 19:47:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjpSb-0000wT-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 19:46:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AjpRf-0000r3-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 19:45:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjpRV-0007e3-SC; Thu, 22 Jan 2004 19:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AjpQk-0007d2-6s for rtg-dir@optimus.ietf.org; Thu, 22 Jan 2004 19:44:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21829 for ; Thu, 22 Jan 2004 19:44:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjpQd-0000pn-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 19:44:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjpOQ-0000lJ-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 19:41:50 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1AjpLz-0000gF-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 19:39:19 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id i0N0cZ3K007931; Thu, 22 Jan 2004 16:38:35 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.10/Submit) id i0N0cZZF007930; Thu, 22 Jan 2004 16:38:35 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2004 16:38:35 -0800 From: David Meyer To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: Under IESG review: draft-ietf-nsis-fw-05.txt Message-ID: <20040123003835.GA7918@1-4-5.net> References: <8159864280.20040122145231@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8159864280.20040122145231@psg.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Alex, What category they are asking for (the document doesn't say)? Thanks, Dave On Thu, Jan 22, 2004 at 02:52:31PM -0800, Alex Zinin wrote: >> >> This document was on the agenda this morning and will come back in two >> weeks. I have comments on scalability and routing-related issues that >> I will forward here today. >> >> More review welcome. Send comments by Jan 29th, please. >> >> Title: Next Steps in Signaling: Framework >> >> Abstract: >> >> The Next Steps in Signaling working group is considering protocols >> for signaling information about a data flow along its path in the >> network. Based on existing work on signaling requirements, this >> document proposes an architectural framework for such signaling >> protocols. >> >> This document provides a model for the network entities that take >> part in such signaling, and the relationship between signaling and >> the rest of network operation. We decompose the overall signaling >> protocol suite into a generic (lower) layer, with a separate upper >> >> layers for each specific signaling application. An initial proposal >> for the split between these layers is given, describing the overall >> functionality of the lower layer, and discussing the ways that upper >> layer behavior can be adapted to specific signaling application >> requirements. >> >> This framework also considers the general interactions between >> signaling and other network layer functions, specifically routing, >> mobility, and address translators. The different events that impact >> signaling operation are described, along with how their handling >> should be divided between the generic and application-specific >> layers. Finally, an example signaling application (for Quality of >> Service) is described in more detail. >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> From rtg-dir-admin@ietf.org Thu Jan 22 20:35:17 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23397 for ; Thu, 22 Jan 2004 20:35:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AjqE4-0002xo-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 20:35:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AjqAU-0002lx-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 20:31:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ajq6R-0002a7-00 for rtg-dir-archive@ietf.org; Thu, 22 Jan 2004 20:27:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajq69-0002Wa-Cj; Thu, 22 Jan 2004 20:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ajq5H-0002Vg-GN for rtg-dir@optimus.ietf.org; Thu, 22 Jan 2004 20:26:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23035 for ; Thu, 22 Jan 2004 20:26:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ajq5A-0002Vq-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 20:26:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ajq1m-0002Lz-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 20:22:31 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ajpy5-0002Aj-00 for rtg-dir@ietf.org; Thu, 22 Jan 2004 20:18:41 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ajpxg-000Ad5-C7; Fri, 23 Jan 2004 01:18:16 +0000 Date: Thu, 22 Jan 2004 17:16:55 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <12068528078.20040122171655@psg.com> To: David Meyer CC: rtg-dir@ietf.org Subject: Re: Under IESG review: draft-ietf-nsis-fw-05.txt In-Reply-To: <20040123003835.GA7918@1-4-5.net> References: <8159864280.20040122145231@psg.com> <20040123003835.GA7918@1-4-5.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dave, it's INFO. -- Alex http://www.psg.com/~zinin/ Thursday, January 22, 2004, 4:38:35 PM, David Meyer wrote: > Alex, > What category they are asking for (the document doesn't > say)? > Thanks, > Dave > On Thu, Jan 22, 2004 at 02:52:31PM -0800, Alex Zinin wrote: >>> >>> This document was on the agenda this morning and will come back in two >>> weeks. I have comments on scalability and routing-related issues that >>> I will forward here today. >>> >>> More review welcome. Send comments by Jan 29th, please. >>> >>> Title: Next Steps in Signaling: Framework >>> >>> Abstract: >>> >>> The Next Steps in Signaling working group is considering protocols >>> for signaling information about a data flow along its path in the >>> network. Based on existing work on signaling requirements, this >>> document proposes an architectural framework for such signaling >>> protocols. >>> >>> This document provides a model for the network entities that take >>> part in such signaling, and the relationship between signaling and >>> the rest of network operation. We decompose the overall signaling >>> protocol suite into a generic (lower) layer, with a separate upper >>> >>> layers for each specific signaling application. An initial proposal >>> for the split between these layers is given, describing the overall >>> functionality of the lower layer, and discussing the ways that upper >>> layer behavior can be adapted to specific signaling application >>> requirements. >>> >>> This framework also considers the general interactions between >>> signaling and other network layer functions, specifically routing, >>> mobility, and address translators. The different events that impact >>> signaling operation are described, along with how their handling >>> should be divided between the generic and application-specific >>> layers. Finally, an example signaling application (for Quality of >>> Service) is described in more detail. >>> >>> -- >>> Alex >>> http://www.psg.com/~zinin/ >>> From rtg-dir-admin@ietf.org Fri Jan 23 10:31:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05711 for ; Fri, 23 Jan 2004 10:31:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Hc-00037M-00 for rtg-dir-archive@ietf.org; Fri, 23 Jan 2004 10:31:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3Gm-00035x-00 for rtg-dir-archive@ietf.org; Fri, 23 Jan 2004 10:30:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Fx-00033s-00 for rtg-dir-archive@ietf.org; Fri, 23 Jan 2004 10:30:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Fx-0000Y8-Bp; Fri, 23 Jan 2004 10:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3Ff-0000TF-Sj for rtg-dir@optimus.ietf.org; Fri, 23 Jan 2004 10:29:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05513 for ; Fri, 23 Jan 2004 10:29:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Fd-00031z-00 for rtg-dir@ietf.org; Fri, 23 Jan 2004 10:29:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3Eh-00030D-00 for rtg-dir@ietf.org; Fri, 23 Jan 2004 10:28:44 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak3Dl-0002wi-00 for rtg-dir@ietf.org; Fri, 23 Jan 2004 10:27:45 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6F87D2D49C8; Fri, 23 Jan 2004 10:27:14 -0500 (EST) 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 20341-01-12; Fri, 23 Jan 2004 10:27:12 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id EF2742D4828; Fri, 23 Jan 2004 10:26:55 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i0NFQt109726; Fri, 23 Jan 2004 10:26:55 -0500 (EST) Date: Fri, 23 Jan 2004 10:26:55 -0500 From: Jeffrey Haas To: Alex Zinin Cc: rtg-dir@ietf.org Subject: Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" Message-ID: <20040123102655.C15406@nexthop.com> References: <12758206266.20040122142453@psg.com> <359318435.20040122144325@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <359318435.20040122144325@psg.com>; from zinin@psg.com on Thu, Jan 22, 2004 at 02:43:25PM -0800 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Presuming you comments to go here rather than routing-discussion. I'll repost there if that's not the case. I like this document in general and would make a few minor suggestions: Requiring the origin of the stack or the OS, while nice in theory, is unlikely to happen. While it may be common knowledge as to what certain vendors have based their products upon, that knowledge seems to be to the detriment of the vendor in many cases. "That vendor based their routing engine on Linux instead of FreeBSD" for example. While the origin may indeed affect the security implications it doesn't take into account internal security audits or modifications to the original. Similarly, separate resources for the management plane while a nice idea in theory seem unlikely to happen for lower-end boxes. Separate resources perhaps suggests a higher chip count to a box. It also potentially suggests an increase in complexity of the box and complexity is one of the banes of securing a system. I would suggest that it would be a Good Thing to make recommendations that the console interface support some common data transfer protocol, e.g. XMODEM. This seems partially addressed in the section that covers "support software installation", however that section seems to deal more with non-console mechanisms. With regards to the "slow link" issue, I would suggest that it would be a Good Thing to provide some form of text filtering mechanism in order to allow large queries of some form to return relevant data quickly. An example is the Cisco-style |include or |exclude. Grep is your friend over slow links. For the console fallback scenario, I would suggest that it is critical to log failed login attempts locally, preferably in some non-volatile storage to prevent attacks where the device is isolated from it's authentication interfaces and attacked at the console. On Thu, Jan 22, 2004 at 02:43:25PM -0800, Alex Zinin wrote: > This document puts requirements on the routers. Please > review carefully, as it's likely to show up in RFPs... > > -- > Alex > http://www.psg.com/~zinin/ > > This is a forwarded message > From: Alex Zinin > To: routing-discussion@ietf.org > Cc: iesg@ietf.org > Date: Thursday, January 22, 2004, 2:24:53 PM > Subject: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" > > ===8<==============Original message text=============== > > Folks- > > The IESG received a request to publish draft-jones-opsec as a BCP > RFC. To ensure wide community review, we are soliciting comments on > this document from the routing community. Please send your comments > by February 5th, 2004. > > From the abstract: > > This document defines a list of operational security requirements for > the infrastructure of large IP networks (routers and switches) which > are considered to be best current practice (BCP). A framework is > defined for specifying "profiles", which are collections of > requirements applicable to certain network topology contexts (all, > core-only, edge-only...). The goal is to provide network operators a > clear, concise way of communicating their security requirements to > vendors. Comments to: "opsec-comment@ops.ietf.org". > > When commenting, please use the Routing Area mailing list > (routing-discussion@ietf.org). > > Alex Zinin > IETF Routing Area Co-Director > > > > ===8<===========End of original message text=========== > > -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Fri Jan 23 11:04:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07754 for ; Fri, 23 Jan 2004 11:04:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3nY-0005Wg-00 for rtg-dir-archive@ietf.org; Fri, 23 Jan 2004 11:04:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3mP-0005KM-00 for rtg-dir-archive@ietf.org; Fri, 23 Jan 2004 11:03:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak3kx-000560-00 for rtg-dir-archive@ietf.org; Fri, 23 Jan 2004 11:02:03 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ak3kx-0007hn-Ol for rtg-dir-archive@ietf.org; Fri, 23 Jan 2004 11:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3kv-00041u-64; Fri, 23 Jan 2004 11:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak3k3-0003xE-Ag for rtg-dir@optimus.ietf.org; Fri, 23 Jan 2004 11:01:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07379 for ; Fri, 23 Jan 2004 11:01:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3k0-0004w9-00 for rtg-dir@ietf.org; Fri, 23 Jan 2004 11:01:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak3j3-0004nz-00 for rtg-dir@ietf.org; Fri, 23 Jan 2004 11:00:06 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1Ak3i1-0004Zv-00 for rtg-dir@ietf.org; Fri, 23 Jan 2004 10:59:01 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id i0NFwU3K013364; Fri, 23 Jan 2004 07:58:30 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.10/Submit) id i0NFwU4a013363; Fri, 23 Jan 2004 07:58:30 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 23 Jan 2004 07:58:30 -0800 From: David Meyer To: Jeffrey Haas Cc: Alex Zinin , rtg-dir@ietf.org Subject: Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" Message-ID: <20040123155830.GA13311@1-4-5.net> References: <12758206266.20040122142453@psg.com> <359318435.20040122144325@psg.com> <20040123102655.C15406@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040123102655.C15406@nexthop.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 On Fri, Jan 23, 2004 at 10:26:55AM -0500, Jeffrey Haas wrote: >> Presuming you comments to go here rather than routing-discussion. >> I'll repost there if that's not the case. >> >> I like this document in general and would make a few minor suggestions: >> >> Requiring the origin of the stack or the OS, while nice in theory, is >> unlikely to happen. While it may be common knowledge as to what >> certain vendors have based their products upon, that knowledge seems >> to be to the detriment of the vendor in many cases. "That vendor based >> their routing engine on Linux instead of FreeBSD" for example. While >> the origin may indeed affect the security implications it doesn't take >> into account internal security audits or modifications to the original. I agree with this. It seems to be a "punative-like" measure (or at least could be interpreted/used in that way). >> Similarly, separate resources for the management plane while a nice >> idea in theory seem unlikely to happen for lower-end boxes. Separate >> resources perhaps suggests a higher chip count to a box. It also >> potentially suggests an increase in complexity of the box and >> complexity is one of the banes of securing a system. ditto. >> I would suggest that it would be a Good Thing to make recommendations >> that the console interface support some common data transfer protocol, >> e.g. XMODEM. This seems partially addressed in the section that covers >> "support software installation", however that section seems to >> deal more with non-console mechanisms. I had though of that, but that would seem to violate "secure channel" requirement. Or does it? Dave From rtg-dir-admin@ietf.org Fri Jan 23 15:16:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19346 for ; Fri, 23 Jan 2004 15:16:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak7jU-000250-00 for rtg-dir-archive@ietf.org; Fri, 23 Jan 2004 15:16:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak7iX-00024A-00 for rtg-dir-archive@ietf.org; Fri, 23 Jan 2004 15:15:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ak7hl-00023U-00 for rtg-dir-archive@ietf.org; Fri, 23 Jan 2004 15:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7hl-0004fv-MP; Fri, 23 Jan 2004 15:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ak7hY-0004d2-Nb for rtg-dir@optimus.ietf.org; Fri, 23 Jan 2004 15:14:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19208 for ; Fri, 23 Jan 2004 15:14:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ak7hX-00022G-00 for rtg-dir@ietf.org; Fri, 23 Jan 2004 15:14:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ak7gY-000201-00 for rtg-dir@ietf.org; Fri, 23 Jan 2004 15:13:47 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Ak7fb-0001yB-00 for rtg-dir@ietf.org; Fri, 23 Jan 2004 15:12:47 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8AA9B2D4829; Fri, 23 Jan 2004 15:12:17 -0500 (EST) 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 28696-01-5; Fri, 23 Jan 2004 15:12:16 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9EFDC2D4818; Fri, 23 Jan 2004 15:12:16 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id i0NKCGA19227; Fri, 23 Jan 2004 15:12:16 -0500 (EST) Date: Fri, 23 Jan 2004 15:12:16 -0500 From: Jeffrey Haas To: David Meyer Cc: Alex Zinin , rtg-dir@ietf.org Subject: Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" Message-ID: <20040123151216.D15406@nexthop.com> References: <12758206266.20040122142453@psg.com> <359318435.20040122144325@psg.com> <20040123102655.C15406@nexthop.com> <20040123155830.GA13311@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040123155830.GA13311@1-4-5.net>; from dmm@1-4-5.net on Fri, Jan 23, 2004 at 07:58:30AM -0800 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 On Fri, Jan 23, 2004 at 07:58:30AM -0800, David Meyer wrote: > >> I would suggest that it would be a Good Thing to make recommendations > >> that the console interface support some common data transfer protocol, > >> e.g. XMODEM. This seems partially addressed in the section that covers > >> "support software installation", however that section seems to > >> deal more with non-console mechanisms. > > I had though of that, but that would seem to violate > "secure channel" requirement. Or does it? Did the document require a secure channel at the console? The profile is obviously different. I believe one of the requirements (without looking again) was that we be able to use it in plain text mode. Also, the presence of encryption would take a low-bandwidth medium and make it even lower bandwidth in many cases and more prone to issues due to line noise. > Dave -- Jeff Haas NextHop Technologies From rtg-dir-admin@ietf.org Tue Jan 27 21:48:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12696 for ; Tue, 27 Jan 2004 21:48:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlfkQ-0005W1-00 for rtg-dir-archive@ietf.org; Tue, 27 Jan 2004 21:48:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlfjY-0005Su-00 for rtg-dir-archive@ietf.org; Tue, 27 Jan 2004 21:47:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlfjG-0005Ow-00 for rtg-dir-archive@ietf.org; Tue, 27 Jan 2004 21:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfjI-0006RU-9I; Tue, 27 Jan 2004 21:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlfiV-0006OM-VY for rtg-dir@optimus.ietf.org; Tue, 27 Jan 2004 21:46:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12595 for ; Tue, 27 Jan 2004 21:46:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlfiT-0005Mg-00 for rtg-dir@ietf.org; Tue, 27 Jan 2004 21:46:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlfhV-0005Id-00 for rtg-dir@ietf.org; Tue, 27 Jan 2004 21:45:10 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Alfga-0005Ck-00; Tue, 27 Jan 2004 21:44:12 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Alfga-0004UY-GP; Wed, 28 Jan 2004 02:44:12 +0000 Date: Tue, 27 Jan 2004 18:43:47 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <37505740045.20040127184347@psg.com> To: rtg-chairs@ietf.org CC: rtg-dir@ietf.org Subject: Last Call'ing documents in RTG WGs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi! A couple of small requests to the chairs of the WGs in the Routing area. When Last Call'ing documents in your WGs: o please don't forget to indicate the target status of the document (INFO/EXP/Proposed Standard/Draft Standard); including the abstract from the draft is also a good idea. o please forward the Last Call message to the Routing Area directorate mailing list (rtg-dir@ietf.org) so that the directorate members can review the document earlier during the WG LC. This should speed up document processing and the AD-review process in particular a lot. Thank you. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Thu Jan 29 15:00:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13177 for ; Thu, 29 Jan 2004 15:00:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmIL9-0001EJ-00 for rtg-dir-archive@ietf.org; Thu, 29 Jan 2004 15:00:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmIKW-00017x-00 for rtg-dir-archive@ietf.org; Thu, 29 Jan 2004 15:00:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmIKX-0001X4-Ve; Thu, 29 Jan 2004 15:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmIJZ-0001Un-JZ for rtg-dir@optimus.ietf.org; Thu, 29 Jan 2004 14:59:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13035 for ; Thu, 29 Jan 2004 14:58:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmIJW-0000zt-00 for rtg-dir@ietf.org; Thu, 29 Jan 2004 14:58:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmIIk-0000rG-00 for rtg-dir@ietf.org; Thu, 29 Jan 2004 14:58:11 -0500 Received: from aneuilly-105-1-2-6.w80-13.abo.wanadoo.fr ([80.13.57.6] helo=80.13.57.6) by ietf-mx with smtp (Exim 4.12) id 1AmIHi-0000et-00 for rtg-dir@ietf.org; Thu, 29 Jan 2004 14:57:07 -0500 Date: Thu, 29 Jan 2004 13:56:59 -0600 From: Visa Service X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Reply-To: Visa Service Organization: Visa International Service X-Priority: 3 (Normal) To: rtg-dir@ietf.org Subject: Visa Security Update Mime-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.0 required=5.0 tests=DEAR_SOMETHING, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_50_60,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,HTTP_ESCAPED_HOST,HTTP_EXCESSIVE_ESCAPES, MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.2 DEAR_SOMETHING BODY: Contains 'Dear (something)' * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.7 HTTP_EXCESSIVE_ESCAPES URI: Completely unnecessary %-escapes inside a URL * 2.4 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit

Dear Sir/Madam,

We were informed that your credit card is used by another person or stolen. It could happen if you have been shopping on-line, and someone got your "Billing information" including your credit card number. To avoid and prevent any further fraud and billing mistakes and to refund your credit card, it is strongly recommended to proceed filling in the secure form on our site and applying for our Zero Liability program. Program is free and it will help us to confirm the fact of fraud and investigate this accident as soon as possible.

Sincerely yours, Visa Support Assistant, Alwin Desagun.

From rtg-dir-admin@ietf.org Fri Jan 30 12:48:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03478 for ; Fri, 30 Jan 2004 12:48:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amckz-0001R1-00 for rtg-dir-archive@ietf.org; Fri, 30 Jan 2004 12:48:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Amck5-0001GH-00 for rtg-dir-archive@ietf.org; Fri, 30 Jan 2004 12:47:46 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AmcjM-000168-00 for rtg-dir-archive@ietf.org; Fri, 30 Jan 2004 12:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmcjM-0005bS-Si; Fri, 30 Jan 2004 12:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Amciu-0005ZY-2J for rtg-dir@optimus.ietf.org; Fri, 30 Jan 2004 12:46:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03295 for ; Fri, 30 Jan 2004 12:46:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Amcis-000154-00 for rtg-dir@ietf.org; Fri, 30 Jan 2004 12:46:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmciB-0000xG-00 for rtg-dir@ietf.org; Fri, 30 Jan 2004 12:45:48 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AmchX-0000o8-00 for rtg-dir@ietf.org; Fri, 30 Jan 2004 12:45:07 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmchX-000Fnu-59 for rtg-dir@ietf.org; Fri, 30 Jan 2004 17:45:07 +0000 Date: Fri, 30 Jan 2004 09:44:46 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <19369746820.20040130094446@psg.com> To: rtg-dir@ietf.org Subject: Fwd: PRELIMINARY Agenda and Package for February 5, 2004 Telechat In-Reply-To: <200401292238.RAA24705@ietf.org> References: <200401292238.RAA24705@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA03296 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable draft iesg agenda for next thursday below. if you have comments on any documents--send here, pls. --=20 Alex http://www.psg.com/~zinin/ This is a forwarded message From: IESG Secretary To: iesg@ietf.org Cc: bfuller@foretec.com, amyk@foretec.com Date: Thursday, January 29, 2004, 2:38:48 PM Subject: PRELIMINARY Agenda and Package for February 5, 2004 Telechat =3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DOriginal message tex= t=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the February 5, 2004 IESG Teleconference This agenda was generated at 17:25:40 EDT, January 29, 2004 = =20 1. Administrivia = =20 o Roll Call o Bash the Agenda o Approval of the Minutes o Review of Action Items = =20 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Item o draft-ietf-ospf-2547-dnbit-03.txt Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs (Prop= osed=20 Standard) - 1 of 2=20 Note: In IETF LC till Feb 02, 2004.=20 Token: Alex Zinin o draft-ietf-smime-pss-03.txt Use of the PSS Signature Algorithm in CMS (Proposed Standard) - 2 of = 2=20 Token: Russ Housley 2.1.2 Returning Item o draft-ietf-xmpp-im-20.txt Extensible Messaging and Presence Protocol (XMPP): Instant Messaging = and=20 Presence (Proposed Standard) - 1 of 1=20 Note: Returning to telechat to review proposed changes.  Note th= at=20 changes to meet Allison's discuss may have deployment consequences, s= o a=20 quick security re-review is in order.=20 Token: Ted Hardie 2.2 Individual Submissions 2.2.1 New Item o draft-mealling-uuid-urn-01.txt A UUID URN Namespace (Proposed Standard) - 1 of 1=20 Token: Ted Hardie 2.2.2 Returning Item o draft-klyne-msghdr-registry-07.txt Registration procedures for message header fields (BCP) - 1 of 2=20 Note: Discuss response now sent to relevant ADs; now waiting. for the= m to=20 follow up.=20 Token: Ned Freed o draft-jones-opsec-03.txt Operational Security Requirements for IP Network Infrastructure (BCP)= - 2=20 of 2=20 Token: Steve Bellovin 3. Document Actions 3.1 WG Submissions 3.1.1 New Item o draft-ietf-midcom-semantics-07.txt MIDCOM Protocol Semantics (Informational) - 1 of 7=20 Token: Jon Peterson o draft-ietf-isis-gmpls-extensions-19.txt IS-IS Extensions in Support of Generalized MPLS (Informational) - 2 o= f 7=20 Note: Last Call ended 2003-06-23=20 Token: Alex Zinin o draft-ietf-rddp-problem-statement-03.txt RDMA over IP Problem Statement (Informational) - 3 of 7=20 Token: Jon Peterson o draft-ietf-rddp-arch-04.txt The Architecture of Direct Data Placement (DDP)And Remote Direct Memo= ry=20 Access (RDMA)On Internet Protocols (Informational) - 4 of 7=20 Token: Jon Peterson o draft-ietf-rmt-flute-07.txt FLUTE - File Delivery over Unidirectional Transport (Experimental) - = 5 of=20 7=20 Token: Allison Mankin o draft-ietf-isis-restart-05.txt Restart signaling for IS-IS (Informational) - 6 of 7=20 Token: Alex Zinin o Two-document ballot: - 7 of 7 - draft-ietf-avt-ilbc-codec-04.txt Internet Low Bit Rate Codec (Experimental)=20 Note: Codecs are not an area of strong expertise for IETF, so the = AVT=20 charter states that any codec specification would be taken only on= a=20 case-by-case basis.=E1 The review of the charter in 2003 admitted = this=20 codec, and it did receive both AVT and external review.=E1 From th= e=20 chairs' request to publish:=E1 "The codec has been reviewed by the= AVT=20 working group and several outside experts (Vladimir Cuperman, Nift= ybox=20 LLB; Frank Mertz, Christoph Erdmann and Peter Vary, Aachen Univers= ity;=20 and Gernot Kubin, Graz University of Technology) suggested by the=20 codec authors.=E1 We believe it to be stable and useful, but recom= mend=20 it be pubished as an Experimental RFC while further experience is=20 gained.".=20 - draft-ietf-avt-rtp-ilbc-04.txt RTP Payload Format for iLBC Speech (Experimental)=20 Note: IETF Last Call elicited no comments.  Codec and payload= =20 adopted by Cablelabs, even though codec, despite a good number of=20 solicited expert reviews, still held as experiment, being quite ne= w=20 type.=20 Token: Allison Mankin 3.1.2 Returning Item o draft-ietf-forces-framework-13.txt Forwarding and Control Element Separation (ForCES) Framework=20 (Informational) - 1 of 3=20 Note: Making sure previous comments have been addressed properly.=20 Token: Alex Zinin o draft-ietf-bgmp-spec-06.txt Border Gateway Multicast Protocol (BGMP): Protocol Specification=20 (Informational) - 2 of 3=20 Note: Back on agenda to check that comments have been addressed.=20 Token: Alex Zinin o draft-ietf-problem-issue-statement-05.txt IETF Problem Statement (Informational) - 3 of 3=20 Token: Harald Alvestrand 3.2 Individual Submissions Via AD 3.2.1 New Item o draft-huston-ipv6-documentation-prefix-02.txt IPv6 Documentation Address (Informational) - 1 of 1=20 Token: Thomas Narten 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor 3.3.1 New Item NONE 3.3.2 Returning Item o draft-touch-ipsec-vpn-06.txt Use of IPsec Transport Mode for Dynamic Routing (Informational) - 1 o= f 1=20 Note: Returning to see if previous comments have been adequately=20 addressed.=20 Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Improved Cross-Area Review (icar) - 1 of 4 Token: Harald Alvestrand o IKEv2 Mobility and Multihoming (mobike) - 2 of 4 Token: Steven Bellovin o Detecting Network Attachment (dna) - 3 of 4 Token: Margaret Wasserman o TCP Maintenance and Minor Extensions (tcpm) - 4 of 4 Token: Jon Peterson 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Site Multihoming in IPv6 (multi6) - 1 of 1 Token: David Kessens 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use From rtg-dir-admin@ietf.org Tue Feb 3 14:36:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26285 for ; Tue, 3 Feb 2004 14:36:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6Lg-0002fw-00 for rtg-dir-archive@ietf.org; Tue, 03 Feb 2004 14:36:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6Ki-0002Yy-00 for rtg-dir-archive@ietf.org; Tue, 03 Feb 2004 14:35:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6K3-0002T9-00 for rtg-dir-archive@ietf.org; Tue, 03 Feb 2004 14:34:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6K4-0006UH-DP; Tue, 03 Feb 2004 14:35:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6Jh-0006Tj-9q for rtg-dir@optimus.ietf.org; Tue, 03 Feb 2004 14:34:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26170 for ; Tue, 3 Feb 2004 14:34:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6Je-0002Ru-00 for rtg-dir@ietf.org; Tue, 03 Feb 2004 14:34:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6Il-0002Mp-00 for rtg-dir@ietf.org; Tue, 03 Feb 2004 14:33:40 -0500 Received: from [213.163.128.162] (helo=snifit.smb.utfors.se) by ietf-mx with esmtp (Exim 4.12) id 1Ao6I8-0002DF-00 for rtg-dir@ietf.org; Tue, 03 Feb 2004 14:33:00 -0500 Received: from pi.se (md4690a84.utfors.se [212.105.10.132]) by snifit.smb.utfors.se (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HSI00D7SWNRG6@snifit.smb.utfors.se> for rtg-dir@ietf.org; Tue, 03 Feb 2004 20:26:59 +0100 (MET) Date: Tue, 03 Feb 2004 20:25:28 +0100 From: Loa Andersson Subject: draft-ietf-mpls-lc-if-mib-01.txt To: MPLS wg , Alex Zinin , rtg-dir@ietf.org, George Swallow , "Wijnen, Bert (Bert)" Message-id: <401FF5A8.1090907@pi.se> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 Content-Transfer-Encoding: 7BIT Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 MPLS wg, the authors of draft-ietf-mpls-lc-if-mib-01.txt has requested a wg last call of their draft. This is is to initiate the wg last call ending on Feb 20 23.59PM PST. As usual all comments to the wg mailing list, we are looking both positive and negative comments. /Loa and George From rtg-dir-admin@ietf.org Tue Feb 3 14:48:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26898 for ; Tue, 3 Feb 2004 14:48:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6XE-0003zo-00 for rtg-dir-archive@ietf.org; Tue, 03 Feb 2004 14:48:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6WK-0003uA-00 for rtg-dir-archive@ietf.org; Tue, 03 Feb 2004 14:47:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6Ve-0003ok-00 for rtg-dir-archive@ietf.org; Tue, 03 Feb 2004 14:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6Vh-0007nP-1n; Tue, 03 Feb 2004 14:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6VI-0007lg-8G for rtg-dir@optimus.ietf.org; Tue, 03 Feb 2004 14:46:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26789 for ; Tue, 3 Feb 2004 14:46:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6VF-0003mz-00 for rtg-dir@ietf.org; Tue, 03 Feb 2004 14:46:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6UH-0003h5-00 for rtg-dir@ietf.org; Tue, 03 Feb 2004 14:45:33 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ao6TO-0003bC-00 for rtg-dir@ietf.org; Tue, 03 Feb 2004 14:44:38 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao6TC-000BQ4-3I; Tue, 03 Feb 2004 19:44:26 +0000 Date: Tue, 3 Feb 2004 11:43:36 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <125321704146.20040203114336@psg.com> To: rtg-dir@ietf.org CC: George Swallow , "Wijnen, Bert (Bert)" , , Loa Andersson Subject: Re: draft-ietf-mpls-lc-if-mib-01.txt In-Reply-To: <401FF5A8.1090907@pi.se> References: <401FF5A8.1090907@pi.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Thanks, Loa. From the rtg-dir, I'd like to ask Jeff Parker to review this document. Please ack. Sue, please assign a reviewer from the RTG-MIB group. Thanks. -- Alex http://www.psg.com/~zinin/ Tuesday, February 3, 2004, 11:25:28 AM, Loa Andersson wrote: > MPLS wg, > the authors of draft-ietf-mpls-lc-if-mib-01.txt has requested a > wg last call of their draft. > This is is to initiate the wg last call ending on > Feb 20 23.59PM PST. > As usual all comments to the wg mailing list, we are looking > both positive and negative comments. > /Loa and George From rtg-dir-admin@ietf.org Tue Feb 3 15:01:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27398 for ; Tue, 3 Feb 2004 15:01:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6jo-0005Hh-00 for rtg-dir-archive@ietf.org; Tue, 03 Feb 2004 15:01:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6is-0005Ck-00 for rtg-dir-archive@ietf.org; Tue, 03 Feb 2004 15:00:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6iG-00057s-00 for rtg-dir-archive@ietf.org; Tue, 03 Feb 2004 15:00:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6iH-0002YS-N2; Tue, 03 Feb 2004 15:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6hu-0002W9-Fr for rtg-dir@optimus.ietf.org; Tue, 03 Feb 2004 14:59:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27331 for ; Tue, 3 Feb 2004 14:59:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6hr-00057L-00 for rtg-dir@ietf.org; Tue, 03 Feb 2004 14:59:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6gv-00052l-00 for rtg-dir@ietf.org; Tue, 03 Feb 2004 14:58:38 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao6gB-0004t8-00 for rtg-dir@ietf.org; Tue, 03 Feb 2004 14:57:51 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i13JvH311146 for ; Tue, 3 Feb 2004 13:57:18 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Feb 2004 20:57:16 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC4F0@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Alex Zinin'" , rtg-dir@ietf.org Cc: George Swallow , "Wijnen, Bert (Bert)" , rtg-mibs@ops.ietf.org, Loa Andersson Subject: RE: draft-ietf-mpls-lc-if-mib-01.txt Date: Tue, 3 Feb 2004 20:57:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 As a quick fiorst shot! 1. Abstract and probably other places This memo defines how label switching controlled Frame-Relay and ATM interfaces can be realized given the interface stacking as defined in the MPLS-LSR and MPLS-TE MIBs. The names of these MIB Modules (as opposd to MIBs) have changed during the standardization process. PLEASE get all these (your) MPLS related MIB documents in sync in terms of names and terminology used! 2. The Last Call does not explicitly state it, but scanning the draft, it seems the call is for this doc to be considered as Proposed Standard. Did I get that right? Thanks, Bert > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: dinsdag 3 februari 2004 20:44 > To: rtg-dir@ietf.org > Cc: George Swallow; Wijnen, Bert (Bert); rtg-mibs@ops.ietf.org; Loa > Andersson > Subject: Re: draft-ietf-mpls-lc-if-mib-01.txt > > > Thanks, Loa. > > From the rtg-dir, I'd like to ask Jeff Parker to review this document. > Please ack. > > Sue, please assign a reviewer from the RTG-MIB group. > > Thanks. > > -- > Alex > http://www.psg.com/~zinin/ > > Tuesday, February 3, 2004, 11:25:28 AM, Loa Andersson wrote: > > MPLS wg, > > > the authors of draft-ietf-mpls-lc-if-mib-01.txt has requested a > > wg last call of their draft. > > > This is is to initiate the wg last call ending on > > Feb 20 23.59PM PST. > > > As usual all comments to the wg mailing list, we are looking > > both positive and negative comments. > > > > /Loa and George > From rtg-dir-admin@ietf.org Tue Feb 3 15:33:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29442 for ; Tue, 3 Feb 2004 15:33:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7El-0000Mg-00 for rtg-dir-archive@ietf.org; Tue, 03 Feb 2004 15:33:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7Dr-0000H0-00 for rtg-dir-archive@ietf.org; Tue, 03 Feb 2004 15:32:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7DD-0000Bs-00 for rtg-dir-archive@ietf.org; Tue, 03 Feb 2004 15:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7DE-00077a-1T; Tue, 03 Feb 2004 15:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Cp-00072n-8O for rtg-dir@optimus.ietf.org; Tue, 03 Feb 2004 15:31:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29358 for ; Tue, 3 Feb 2004 15:31:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7Cn-0000AI-00 for rtg-dir@ietf.org; Tue, 03 Feb 2004 15:31:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7Bs-000051-00 for rtg-dir@ietf.org; Tue, 03 Feb 2004 15:30:37 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao7Az-0007im-00 for rtg-dir@ietf.org; Tue, 03 Feb 2004 15:29:41 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 391282D49F6 for ; Tue, 3 Feb 2004 15:29:11 -0500 (EST) 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 50017-01-78 for ; Tue, 3 Feb 2004 15:29:09 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A8FA62D483F for ; Tue, 3 Feb 2004 15:29:09 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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: draft-ietf-mpls-lc-if-mib-01.txt Date: Tue, 3 Feb 2004 15:29:09 -0500 Message-ID: Thread-Topic: draft-ietf-mpls-lc-if-mib-01.txt Thread-Index: AcPqkA4yVwgOSr8SQEqsM1Oj2sL3awABE4KA From: "Susan Hares" To: "Wijnen, Bert (Bert)" , "Alex Zinin" , Cc: "George Swallow" , , "Loa Andersson" X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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: quoted-printable Will do. sue -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, February 03, 2004 2:57 PM To: 'Alex Zinin'; rtg-dir@ietf.org Cc: George Swallow; Wijnen, Bert (Bert); rtg-mibs@ops.ietf.org; Loa Andersson Subject: RE: draft-ietf-mpls-lc-if-mib-01.txt As a quick fiorst shot! 1. Abstract and probably other places This memo defines how label switching controlled Frame-Relay and ATM interfaces can be realized given the interface stacking as defined in the MPLS-LSR and MPLS-TE MIBs. The names of these MIB Modules (as opposd to MIBs) have changed during the standardization process. PLEASE get all these (your) MPLS related MIB documents in sync in terms of names and=20 terminology used! 2. The Last Call does not explicitly state it, but scanning the draft, it seems the call is for this doc to be considered as Proposed Standard. Did I get that right? Thanks, Bert=20 > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: dinsdag 3 februari 2004 20:44 > To: rtg-dir@ietf.org > Cc: George Swallow; Wijnen, Bert (Bert); rtg-mibs@ops.ietf.org; Loa > Andersson > Subject: Re: draft-ietf-mpls-lc-if-mib-01.txt >=20 >=20 > Thanks, Loa. >=20 > From the rtg-dir, I'd like to ask Jeff Parker to review this document. > Please ack. >=20 > Sue, please assign a reviewer from the RTG-MIB group. >=20 > Thanks. >=20 > --=20 > Alex > http://www.psg.com/~zinin/ >=20 > Tuesday, February 3, 2004, 11:25:28 AM, Loa Andersson wrote: > > MPLS wg, >=20 > > the authors of draft-ietf-mpls-lc-if-mib-01.txt has requested a > > wg last call of their draft. >=20 > > This is is to initiate the wg last call ending on > > Feb 20 23.59PM PST. >=20 > > As usual all comments to the wg mailing list, we are looking > > both positive and negative comments. >=20 >=20 > > /Loa and George >=20 From rtg-dir-admin@ietf.org Wed Feb 4 07:06:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02681 for ; Wed, 4 Feb 2004 07:06:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLna-0003WA-00 for rtg-dir-archive@ietf.org; Wed, 04 Feb 2004 07:06:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLmc-0003Nj-00 for rtg-dir-archive@ietf.org; Wed, 04 Feb 2004 07:05:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoLm7-0003FH-00 for rtg-dir-archive@ietf.org; Wed, 04 Feb 2004 07:04:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLmA-0006kT-Uv; Wed, 04 Feb 2004 07:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLlO-0006aE-AQ for rtg-dir@optimus.ietf.org; Wed, 04 Feb 2004 07:04:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02423 for ; Wed, 4 Feb 2004 07:04:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLlK-00039I-00 for rtg-dir@ietf.org; Wed, 04 Feb 2004 07:04:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLk3-0002ps-00 for rtg-dir@ietf.org; Wed, 04 Feb 2004 07:02:51 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AoLj2-0002dQ-00 for rtg-dir@ietf.org; Wed, 04 Feb 2004 07:01:48 -0500 Received: from 165.red-217-127-188.pooles.rima-tde.net ([217.127.188.165] helo=rtg-dir) by mx2.foretec.com with smtp (Exim 4.24) id 1AoLRN-0001Yg-MN for rtg-dir@ietf.org; Wed, 04 Feb 2004 06:43:34 -0500 Message-ID: From: "Sip" Date: Wed, 04 Feb 2004 12:48:15 -0000 To: rtg-dir@ietf.org Subject: Enlarge Ur C0ck By 3+inches bodice MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA02424 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=AWL,DISGUISE_PORN,HTML_70_80, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_FONT_BIG,HTML_MESSAGE, LINES_OF_YELLING,MIME_HTML_ONLY,UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable natgain+
THE NEW
NaturalGain+ Pen1s Enlargement Pi= lls
will
EXP= AND
LEN= GTHEN
and
ENL= ARGE YOUR PEN1S 3+ INCHES

* 100% Mon.ey Back Guaran.tee
* FR.EE Bottle Of NaturalGain+ Worth Over $= 50
* FR.EE "Male Help E-Book" Worth Over $50

MORE INFO HERE
=A0

no more emailz

hamperssinks From rtg-dir-admin@ietf.org Thu Feb 5 16:40:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12396 for ; Thu, 5 Feb 2004 16:40:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorET-00061K-00 for rtg-dir-archive@ietf.org; Thu, 05 Feb 2004 16:40:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorDY-0005yQ-00 for rtg-dir-archive@ietf.org; Thu, 05 Feb 2004 16:39:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AorD9-0005w6-00 for rtg-dir-archive@ietf.org; Thu, 05 Feb 2004 16:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorDA-00035P-SW; Thu, 05 Feb 2004 16:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorCV-0002yM-6m for rtg-dir@optimus.ietf.org; Thu, 05 Feb 2004 16:38:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12282 for ; Thu, 5 Feb 2004 16:38:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorCT-0005um-00 for rtg-dir@ietf.org; Thu, 05 Feb 2004 16:38:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorBa-0005rO-00 for rtg-dir@ietf.org; Thu, 05 Feb 2004 16:37:23 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AorAi-0005ki-00 for rtg-dir@ietf.org; Thu, 05 Feb 2004 16:36:28 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AorAi-00057m-1m; Thu, 05 Feb 2004 21:36:28 +0000 Date: Thu, 5 Feb 2004 13:35:40 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1898330391.20040205133540@psg.com> To: Jeffrey Haas CC: David Meyer , rtg-dir@ietf.org, George M Jones Subject: Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" In-Reply-To: <20040123151216.D15406@nexthop.com> References: <12758206266.20040122142453@psg.com> <359318435.20040122144325@psg.com> <20040123102655.C15406@nexthop.com> <20040123155830.GA13311@1-4-5.net> <20040123151216.D15406@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I just forwarded the comments to George. Will wait for his responses. -- Alex http://www.psg.com/~zinin/ Friday, January 23, 2004, 12:12:16 PM, Jeffrey Haas wrote: > On Fri, Jan 23, 2004 at 07:58:30AM -0800, David Meyer wrote: >> >> I would suggest that it would be a Good Thing to make recommendations >> >> that the console interface support some common data transfer protocol, >> >> e.g. XMODEM. This seems partially addressed in the section that covers >> >> "support software installation", however that section seems to >> >> deal more with non-console mechanisms. >> >> I had though of that, but that would seem to violate >> "secure channel" requirement. Or does it? > Did the document require a secure channel at the console? The > profile is obviously different. I believe one of the requirements > (without looking again) was that we be able to use it in plain text mode. > Also, the presence of encryption would take a low-bandwidth medium > and make it even lower bandwidth in many cases and more prone to > issues due to line noise. >> Dave From rtg-dir-admin@ietf.org Thu Feb 5 17:04:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15130 for ; Thu, 5 Feb 2004 17:04:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aorba-0001Fi-00 for rtg-dir-archive@ietf.org; Thu, 05 Feb 2004 17:04:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorZo-0000wY-00 for rtg-dir-archive@ietf.org; Thu, 05 Feb 2004 17:02:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AorXx-0000f8-00 for rtg-dir-archive@ietf.org; Thu, 05 Feb 2004 17:00:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AorXx-0008Ke-Kw for rtg-dir-archive@ietf.org; Thu, 05 Feb 2004 17:00:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorXb-000597-DB; Thu, 05 Feb 2004 17:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorWk-00054I-08 for rtg-dir@optimus.ietf.org; Thu, 05 Feb 2004 16:59:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14603 for ; Thu, 5 Feb 2004 16:59:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorWh-0000XP-00 for rtg-dir@ietf.org; Thu, 05 Feb 2004 16:59:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorVj-0000Vg-00 for rtg-dir@ietf.org; Thu, 05 Feb 2004 16:58:12 -0500 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1AorVZ-0000Ug-00 for rtg-dir@ietf.org; Thu, 05 Feb 2004 16:58:01 -0500 Message-ID: From: Jeff Parker To: "'Alex Zinin'" , rtg-dir@ietf.org Cc: George Swallow , "Wijnen, Bert (Bert)" , rtg-mibs@ops.ietf.org, Loa Andersson Subject: RE: draft-ietf-mpls-lc-if-mib-01.txt Date: Thu, 5 Feb 2004 16:57:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 > > the authors of draft-ietf-mpls-lc-if-mib-01.txt has requested a > > wg last call of their draft. I have read the draft. It is clear and well written. - jeff parker From rtg-dir-admin@ietf.org Thu Feb 5 17:08:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15573 for ; Thu, 5 Feb 2004 17:08:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorfT-0001ZT-00 for rtg-dir-archive@ietf.org; Thu, 05 Feb 2004 17:08:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aorej-0001Y7-00 for rtg-dir-archive@ietf.org; Thu, 05 Feb 2004 17:07:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoreG-0001Vi-00 for rtg-dir-archive@ietf.org; Thu, 05 Feb 2004 17:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoreH-0005vD-V8; Thu, 05 Feb 2004 17:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aorde-0005tQ-W9 for rtg-dir@optimus.ietf.org; Thu, 05 Feb 2004 17:06:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15437 for ; Thu, 5 Feb 2004 17:06:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aordc-0001UD-00 for rtg-dir@ietf.org; Thu, 05 Feb 2004 17:06:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aorco-0001Qk-00 for rtg-dir@ietf.org; Thu, 05 Feb 2004 17:05:31 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Aorbl-0001HY-00 for rtg-dir@ietf.org; Thu, 05 Feb 2004 17:04:25 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AorbZ-0009fu-M9; Thu, 05 Feb 2004 22:04:13 +0000 Date: Thu, 5 Feb 2004 14:03:22 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9599992411.20040205140322@psg.com> To: rtg-dir@ietf.org CC: George Swallow , "Wijnen, Bert (Bert)" , , Loa Andersson Subject: RE: draft-ietf-mpls-lc-if-mib-01.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Thanks, Jeff. Alex ===8<==============Original message text=============== >From jparker@axiowave.com Thu Feb 05 21:57:30 2004 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AorV4-0008df-0Y; Thu, 05 Feb 2004 21:57:30 +0000 Message-ID: From: Jeff Parker To: "'Alex Zinin'" , rtg-dir@ietf.org Cc: George Swallow , "Wijnen, Bert (Bert)" , rtg-mibs@ops.ietf.org, Loa Andersson Subject: RE: draft-ietf-mpls-lc-if-mib-01.txt Date: Thu, 5 Feb 2004 16:57:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 > > the authors of draft-ietf-mpls-lc-if-mib-01.txt has requested a > > wg last call of their draft. I have read the draft. It is clear and well written. - jeff parker ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Fri Feb 6 07:31:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22745 for ; Fri, 6 Feb 2004 07:31:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap592-0000Mn-00 for rtg-dir-archive@ietf.org; Fri, 06 Feb 2004 07:31:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap586-0000Kp-00 for rtg-dir-archive@ietf.org; Fri, 06 Feb 2004 07:30:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap57T-0000Id-00 for rtg-dir-archive@ietf.org; Fri, 06 Feb 2004 07:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap57S-0000S3-UH; Fri, 06 Feb 2004 07:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap577-0000Qi-Sl for rtg-dir@optimus.ietf.org; Fri, 06 Feb 2004 07:29:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22716 for ; Fri, 6 Feb 2004 07:29:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap577-0000Hy-00 for rtg-dir@ietf.org; Fri, 06 Feb 2004 07:29:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap56C-0000Fr-00 for rtg-dir@ietf.org; Fri, 06 Feb 2004 07:28:45 -0500 Received: from smtp-bedford-x.mitre.org ([192.160.51.76] helo=smtp-bedford.mitre.org) by ietf-mx with esmtp (Exim 4.12) id 1Ap562-0000DJ-00 for rtg-dir@ietf.org; Fri, 06 Feb 2004 07:28:34 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id i16CSYN16802 for ; Fri, 6 Feb 2004 07:28:34 -0500 Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id i16CSX616744; Fri, 6 Feb 2004 07:28:33 -0500 Received: from mm110847-2k.mitre.org (128.29.245.33) by mailhub1.mitre.org with SMTP id 5997489; Fri, 06 Feb 2004 07:28:30 -0500 Subject: Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" From: George M Jones To: Alex Zinin Cc: Jeffrey Haas , David Meyer , rtg-dir@ietf.org In-Reply-To: <1898330391.20040205133540@psg.com> References: <12758206266.20040122142453@psg.com> <359318435.20040122144325@psg.com> <20040123102655.C15406@nexthop.com> <20040123155830.GA13311@1-4-5.net> <20040123151216.D15406@nexthop.com> <1898330391.20040205133540@psg.com> Content-Type: text/plain Message-Id: <1076070459.2719.0.camel@mm110847-2k.mitre.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 06 Feb 2004 07:27:40 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 On Thu, 2004-02-05 at 16:35, Alex Zinin wrote: > I just forwarded the comments to George. > Will wait for his responses. Any objections if I cc the public opsec list with replies ? ---George From rtg-dir-admin@ietf.org Fri Feb 6 14:56:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12199 for ; Fri, 6 Feb 2004 14:56:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApC5y-0007NS-00 for rtg-dir-archive@ietf.org; Fri, 06 Feb 2004 14:56:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApC52-0007Iq-00 for rtg-dir-archive@ietf.org; Fri, 06 Feb 2004 14:56:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApC45-0007DH-00 for rtg-dir-archive@ietf.org; Fri, 06 Feb 2004 14:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApC45-0008DF-Um; Fri, 06 Feb 2004 14:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApC3A-0008Ak-Vk for rtg-dir@optimus.ietf.org; Fri, 06 Feb 2004 14:54:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11998 for ; Fri, 6 Feb 2004 14:54:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApC38-00077i-00 for rtg-dir@ietf.org; Fri, 06 Feb 2004 14:54:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApC2A-00073L-00 for rtg-dir@ietf.org; Fri, 06 Feb 2004 14:53:03 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ApC1X-0006ze-00 for rtg-dir@ietf.org; Fri, 06 Feb 2004 14:52:23 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ApC1W-00093u-Hd; Fri, 06 Feb 2004 19:52:22 +0000 Date: Fri, 6 Feb 2004 11:51:58 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <79178507810.20040206115158@psg.com> To: rtg-dir@ietf.org CC: Russ Housley , Stephen Kent Subject: Fwd: Re: My thoughts on the draft-ietf-pkix-x509-ipaddr-as-extn-03 comments In-Reply-To: References: <57267060612.20031124120539@psg.com> <19911164974.20031202141003@psg.com> <5.2.0.9.2.20040112122954.028a5e98@mail.binhost.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------231B2FC280067DF" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 ------------231B2FC280067DF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Russ, Sue- I'm forwarding the replies from Russ and Steve to the comments you provided on the draft in subj. Please check. Thanks. -- Alex ------------231B2FC280067DF Content-Type: message/rfc822; name="1.msg" Content-Disposition: attachment; filename="1.msg" Received: by psg.com (mbox zinin) (with Cubic Circle's cucipop (v1.31 1998/05/13) Tue Jan 13 00:01:12 2004) X-From_: housley@vigilsec.com Tue Jan 13 00:00:47 2004 Return-path: Received: from [144.202.240.3] (helo=woodstock.binhost.com) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AgBzC-000I1o-Qh for zinin@psg.com; Tue, 13 Jan 2004 00:00:46 +0000 Received: (qmail 30135 invoked by uid 0); 13 Jan 2004 00:00:30 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (64.69.75.34) by woodstock.binhost.com with SMTP; 13 Jan 2004 00:00:30 -0000 Message-Id: <5.2.0.9.2.20040112122954.028a5e98@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 12 Jan 2004 13:06:39 -0500 To: Alex Zinin From: Russ Housley Subject: My thoughts on the draft-ietf-pkix-x509-ipaddr-as-extn-03 comments CC: kent@bbn.com In-Reply-To: <99145736808.20031204140113@psg.com> References: <57267060612.20031124120539@psg.com> <19911164974.20031202141003@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Level: X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=2.60 Alex: >From: Russ White > >-- Section 2.1, in the examples of systems that could use such a >certificate, they could add soBGP as an example. Absolutely NOT. As we discussed at the Minneapolis IETF meeting, soBGP is not acceptable to many operators.. We do not want to link these documents. >-- Section 2.1.2 seems like it's unecessary to me. Is there any situation >where you would want to actually represent a block as a range, rather than >as a set of individual address spaces, or even a summary covering all of >them? The document says why. It allows "a more concise representation" by encoding the range. It is just a way to make the certificate extension smaller. >-- Sections 2.2.3.1, 2, and 3 don't seem to be of any use--the address >family is ipv6 or ipv4, which I thought was covered above in the different >types of addresses which could be encoded. And I can't imagine anyone >assigning authorization for a SAFI, since that' essentially just a topology >within an AFI (?). I do not have enough experience in this area to respond for the authors. >-- The entire draft assumes IANA will issue these cert's followed by >subcerts by the RIR's. What if anyone in the chain doesn't want to >participate? Should the draft provide the option for other forms of >authorization? In other words, it should be up to the receiver to trust the >signer has the authorization to sign, rather than up to the draft writers >to enforce who can and cannot sign a certificate. I do not think this is a issue in this context. IANA is the root of the network address assignment hierarchy. The system does not work if IANA and the RIRs do not do their job properly. We gotta trust them. >From: Susan Hares > >What I'm not qualified to chat on: > "inherit" mechanism in ASN.1. I'm > a little fuzzy on how that all should work. The inherit mechanism seems straightforward to me. The document says: If the IPAddressChoice CHOICE contains the inherit element, then the set of authorized IP addresses for the specified AFI and optional SAFI is taken from the issuer's certificate. >1st - AS - 4 bytes should be assigned now. > It would be good to start at this point to > use a TLV structure for AS's. A TLV encoding is used that supports integer values of any size: ASId ::= INTEGER >2nd - RDI's are supported in ISO, but > not really used in the BGP deployments. > Is this X.509 trying to support the very few > IDRP implementations? I think we want to allow flexibility when it does not add confusion or too much complexity. In this case, I do not see a problem. Am I missing something? >3rd - Private AS may be repeated many times > in practice. How does this specification deal > with private AS? Something should be set in > light of AS confederations. I do not have enough experience in this area to respond for the authors. >4th - Appendix C - is a useful description of the ASN.1 > encoding. Could C be extended or > a new mechanism to indicate how the > "inherit" function would be useful. > > [I for one would like to see the mechanisms of > inherit in an appendix.] I do not think that this is much work, but I do not think it will add much to the clarity of the document either. >5th - an ASN.1 expert should review this text to determine > If the Choice fields allow "non-specific" (or two > different types given the same sequence) of encodings. > Choice fields with the inherit may/may not lead to this. I have personally compiled the ASN.1 module. >From: Tony Tauber [mailto:tony.tauber@level3.com] > > -- Section 2.1.2 seems like it's unecessary to me. Is there any > > situation where you would want to actually represent a block as a > > range, rather than as a set of individual address spaces, or even a > > summary covering all of them? > >I've been thinking about that one, too. > >First I thought of a prefix as the logical way to represent such a >thing; however, addresses are actually assigned in ranges. Prefixes >are more of a routing idea, right? A range is what's assigned. The >"owner" is then free to advertise whatever prefixes they want within >that range (or to delegate further). I think that Tony is suggesting that the document is correct. > > -- The entire draft assumes IANA will issue these cert's followed by > > subcerts by the RIR's. What if anyone in the chain doesn't want to > > participate? Should the draft provide the option for other forms of > > authorization? In other words, it should be up to the receiver to > > trust the signer has the authorization to sign, rather than up to > > the draft writers to enforce who can and cannot sign a certificate. > >Agreed. Perhaps some verbiage indicating that the main use considered is >in the public Internet but that these certs could be used in a private >setting also. I guess this makes sense. IANA is the root for the public Internet. Private communities need to pick an appropriate alternative if they want to use this tool. >Last, since 4-byte ASNs are likely in the future, should 4-bytes be >set aside now? The syntax already support it as described above, Some text in the document could be changed to make this clear. Russ ------------231B2FC280067DF Content-Type: message/rfc822; name="2.msg" Content-Disposition: attachment; filename="2.msg" Received: by psg.com (mbox zinin) (with Cubic Circle's cucipop (v1.31 1998/05/13) Mon Jan 19 19:47:48 2004) X-From_: kent@bbn.com Mon Jan 19 19:33:00 2004 Return-path: Received: from [128.33.0.62] (helo=aragorn.bbn.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aif8u-0000Su-1w for zinin@psg.com; Mon, 19 Jan 2004 19:33:00 +0000 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 i0JJWwM9009123; Mon, 19 Jan 2004 14:32:59 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.2.20040112122954.028a5e98@mail.binhost.com> References: <57267060612.20031124120539@psg.com> <19911164974.20031202141003@psg.com> <5.2.0.9.2.20040112122954.028a5e98@mail.binhost.com> Date: Mon, 19 Jan 2004 14:27:37 -0500 To: Russ Housley , Alex Zinin From: Stephen Kent Subject: Re: My thoughts on the draft-ietf-pkix-x509-ipaddr-as-extn-03 comments CC: Stephen Kent 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.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Alex & Russ, There were a few unresolved issues that Russ asked us to address re your exchange. here are our responses: >>-- Sections 2.2.3.1, 2, and 3 don't seem to be of any use--the address >>family is ipv6 or ipv4, which I thought was covered above in the different >>types of addresses which could be encoded. And I can't imagine anyone >>assigning authorization for a SAFI, since that' essentially just a topology >>within an AFI (?). IANA maintains a registry for address types. The certificate extension uses SAFI to enable the extension to be used with other addresses, e.g., E.164. If folks only use IPv4 and IPv6 addresses, that is ok, the other possible values will not appear in certificates and ought not cause any confusion. >>-- The entire draft assumes IANA will issue these cert's followed by >>subcerts by the RIR's. What if anyone in the chain doesn't want to >>participate? Should the draft provide the option for other forms of >>authorization? In other words, it should be up to the receiver to trust the >>signer has the authorization to sign, rather than up to the draft writers >>to enforce who can and cannot sign a certificate. > >I do not think this is a issue in this context. IANA is the root of >the network address assignment hierarchy. The system does not work >if IANA and the RIRs do not do their job properly. We gotta trust >them. The primary focus of the RFC is the use of this extension in hierarchies, exactly equivalent to the existing hierarchies used for address prefix and As number allocation. However, it is possible to use the extension in private net contexts if the operators of such nets want to take advantage of the mechanism. It would be a local matter to configure trust anchors (a technical, PKI term for public keys and associated data used in cert path validation) to recognize authorities other than IANA, RIRs, and ISPs. We can modify the text to note this: 1. Introduction This document defines two X.509 v3 certificate extensions that allow representation of the transfer of the right to use IP addresses and autonomous system identifiers from one organization to other organizations. The primary use for these extensions is in the public Internet, where IANA is the root that delegates resources through the regional Internet registries (RIRs) to Internet service providers (ISPs) and to user organizations. However, these extensions and the associated processing mechanisms can be employed in private networks, under the auspices of a private PKI representing such delegation. >>2nd - RDI's are supported in ISO, but >> not really used in the BGP deployments. >> Is this X.509 trying to support the very few >> IDRP implementations? > >I think we want to allow flexibility when it does not add confusion >or too much complexity. In this case, I do not see a problem. Am I >missing something? there was no intent to support IDRP per se, but rather to provide a general framework for representing authorization info relative to address and AS number delegation. Our initial focus was S-BGP, but SEND is also a candidate for this PKI, and the support for other address types enables broader use, as noted above. So, unless the RDI provision > >>3rd - Private AS may be repeated many times >> in practice. How does this specification deal >> with private AS? Something should be set in >> light of AS confederations. > >I do not have enough experience in this area to respond for the authors. So long as private AS's are used only within local contexts, we can accommodate their use via this mechanism. As noted above, one can add trust anchors, locally, and in this fashion an ISP can represent itself as the owner of private AS IDs. if an UPDATE with a private AS is sent outside the purview of the ISP that created the private AS, then there would have to be co-ordination between ISPs to be able to make use of S-BGP in conjunction with these private AS IDs. >>1st - AS - 4 bytes should be assigned now. >> It would be good to start at this point to >> use a TLV structure for AS's. > >A TLV encoding is used that supports integer values of any size: > > ASId ::= INTEGER just for added clarity: 3.2.3.10. Type ASId The ASId type is an INTEGER. Note that ASN.1 INTEGERs can express both AS identifiers that are unsigned 16-bit quantities or unsigned 32-bit (or larger) quantities without change to the syntax. Are there are more questions we need to address? Steve ------------231B2FC280067DF-- From rtg-dir-admin@ietf.org Fri Feb 6 15:38:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14839 for ; Fri, 6 Feb 2004 15:38:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApCkY-000299-00 for rtg-dir-archive@ietf.org; Fri, 06 Feb 2004 15:38:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApCja-00026U-00 for rtg-dir-archive@ietf.org; Fri, 06 Feb 2004 15:37:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApCih-00024J-00 for rtg-dir-archive@ietf.org; Fri, 06 Feb 2004 15:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCii-0004mo-18; Fri, 06 Feb 2004 15:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApCid-0004ld-Di for rtg-dir@optimus.ietf.org; Fri, 06 Feb 2004 15:36:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14799 for ; Fri, 6 Feb 2004 15:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApCib-000245-00 for rtg-dir@ietf.org; Fri, 06 Feb 2004 15:36:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApChh-000222-00 for rtg-dir@ietf.org; Fri, 06 Feb 2004 15:35:57 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ApCgz-0001za-00 for rtg-dir@ietf.org; Fri, 06 Feb 2004 15:35:13 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ApCgx-000Fff-LH; Fri, 06 Feb 2004 20:35:11 +0000 Date: Fri, 6 Feb 2004 12:34:48 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <179181078036.20040206123448@psg.com> To: George M Jones CC: Jeffrey Haas , David Meyer , rtg-dir@ietf.org Subject: Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" In-Reply-To: <1076070459.2719.0.camel@mm110847-2k.mitre.org> References: <12758206266.20040122142453@psg.com> <359318435.20040122144325@psg.com> <20040123102655.C15406@nexthop.com> <20040123155830.GA13311@1-4-5.net> <20040123151216.D15406@nexthop.com> <1898330391.20040205133540@psg.com> <1076070459.2719.0.camel@mm110847-2k.mitre.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit George, Should be fine. -- Alex http://www.psg.com/~zinin/ Friday, February 6, 2004, 4:27:40 AM, George M Jones wrote: > On Thu, 2004-02-05 at 16:35, Alex Zinin wrote: >> I just forwarded the comments to George. >> Will wait for his responses. > Any objections if I cc the public opsec list with replies ? > ---George From rtg-dir-admin@ietf.org Mon Feb 9 08:07:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16869 for ; Mon, 9 Feb 2004 08:07:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqB8f-0002zB-00 for rtg-dir-archive@ietf.org; Mon, 09 Feb 2004 08:07:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqB74-0002n6-00 for rtg-dir-archive@ietf.org; Mon, 09 Feb 2004 08:06:11 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqB6n-0002hY-05 for rtg-dir-archive@ietf.org; Mon, 09 Feb 2004 08:05:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqB1C-0008Cx-M3 for rtg-dir-archive@ietf.org; Mon, 09 Feb 2004 08:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqB19-0004rC-JK; Mon, 09 Feb 2004 08:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqB0B-0004pN-2c for rtg-dir@optimus.ietf.org; Mon, 09 Feb 2004 07:59:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16660 for ; Mon, 9 Feb 2004 07:59:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqB0A-0002Hw-00 for rtg-dir@ietf.org; Mon, 09 Feb 2004 07:59:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqAzH-0002Dc-00 for rtg-dir@ietf.org; Mon, 09 Feb 2004 07:58:08 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AqAyr-00029A-00 for rtg-dir@ietf.org; Mon, 09 Feb 2004 07:57:41 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Feb 2004 04:57:07 -0800 Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i19Cv7YO023470; Mon, 9 Feb 2004 07:57:08 -0500 (EST) Received: from localhost (rtp-vpn1-66.cisco.com [10.82.224.66]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA00961; Mon, 9 Feb 2004 07:57:07 -0500 (EST) Date: Mon, 9 Feb 2004 07:57:04 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: Alex Zinin cc: rtg-dir@ietf.org, Russ Housley , Stephen Kent Subject: Re: Fwd: Re: My thoughts on the draft-ietf-pkix-x509-ipaddr-as-extn-03 comments In-Reply-To: <79178507810.20040206115158@psg.com> Message-ID: References: <57267060612.20031124120539@psg.com> <19911164974.20031202141003@psg.com> <5.2.0.9.2.20040112122954.028a5e98@mail.binhost.com> <79178507810.20040206115158@psg.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Alex: >From: Russ White > >-- Section 2.1, in the examples of systems that could use such a >certificate, they could add soBGP as an example. > Absolutely NOT. As we discussed at the Minneapolis IETF meeting, soBGP > is not acceptable to many operators.. We do not want to link these > documents. , so this reply doesn't surprise me at all. Of course, Listen-Whisper could also be included as an example, but I suppose since S-BGP is the _only_ acceptable solution for BGP security.... >-- Section 2.1.2 seems like it's unecessary to me. Is there any situation >where you would want to actually represent a block as a range, rather than >as a set of individual address spaces, or even a summary covering all of >them? > The document says why. It allows "a more concise representation" by > encoding the range. It is just a way to make the certificate extension > smaller. 10.1.0.0/16 is larger than 10.1.0.0 through 10.1.255.255? Since a summary is a range (the two are precisely the same thing), I consider this a distinction without a difference. >-- Sections 2.2.3.1, 2, and 3 don't seem to be of any use--the address >family is ipv6 or ipv4, which I thought was covered above in the different >types of addresses which could be encoded. And I can't imagine anyone >assigning authorization for a SAFI, since that' essentially just a topology >within an AFI (?). > I do not have enough experience in this area to respond for the authors. >-- The entire draft assumes IANA will issue these cert's followed by >subcerts by the RIR's. What if anyone in the chain doesn't want to >participate? Should the draft provide the option for other forms of >authorization? In other words, it should be up to the receiver to trust the >signer has the authorization to sign, rather than up to the draft writers >to enforce who can and cannot sign a certificate. > I do not think this is a issue in this context. IANA is the root of the > network address assignment hierarchy. The system does not work if IANA > and the RIRs do not do their job properly. We gotta trust them. >Agreed. Perhaps some verbiage indicating that the main use considered is >in the public Internet but that these certs could be used in a private >setting also. > I guess this makes sense. IANA is the root for the public > Internet. Private communities need to pick an appropriate alternative if > they want to use this tool. The system should work without the RIR's, if it needs to. I don't see any point in limiting it--who knows if the RIR's will be the root in 10 years time, and private usage may abound, as Tony has suggested. I don't see the problem with opening this text up some, even through a parenthetical, stating that "some top level authority within the context of the internetwork," must sign these certs. >1st - AS - 4 bytes should be assigned now. > It would be good to start at this point to > use a TLV structure for AS's. > A TLV encoding is used that supports integer values of any size: > ASId ::= INTEGER I don't follow... ? I don't see how this supports 4 byte numbers, and I don't see any reason why the current TLV couldn't be have the space added to it, rather than being forced to create a new tlv later (?). :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From rtg-dir-admin@ietf.org Mon Feb 9 15:40:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10382 for ; Mon, 9 Feb 2004 15:40:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqICd-0007CA-00 for rtg-dir-archive@ietf.org; Mon, 09 Feb 2004 15:40:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIBs-00077Y-00 for rtg-dir-archive@ietf.org; Mon, 09 Feb 2004 15:39:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqIBJ-00072W-00 for rtg-dir-archive@ietf.org; Mon, 09 Feb 2004 15:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIBI-0007KQ-U9; Mon, 09 Feb 2004 15:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIAe-0007Fm-2X for rtg-dir@optimus.ietf.org; Mon, 09 Feb 2004 15:38:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10270 for ; Mon, 9 Feb 2004 15:38:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIAc-00071d-00 for rtg-dir@ietf.org; Mon, 09 Feb 2004 15:38:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqI9l-0006xA-00 for rtg-dir@ietf.org; Mon, 09 Feb 2004 15:37:26 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1AqI9Q-0006qy-00 for rtg-dir@ietf.org; Mon, 09 Feb 2004 15:37:04 -0500 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 i19KaIM9021516; Mon, 9 Feb 2004 15:36:18 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: <57267060612.20031124120539@psg.com> <19911164974.20031202141003@psg.com> <5.2.0.9.2.20040112122954.028a5e98@mail.binhost.com> <79178507810.20040206115158@psg.com> Date: Mon, 9 Feb 2004 15:33:09 -0500 To: Russ White From: Stephen Kent Subject: Re: Fwd: Re: My thoughts on the draft-ietf-pkix-x509-ipaddr-as-extn-03 comments Cc: Alex Zinin , rtg-dir@ietf.org, Russ Housley , Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Russ, >Alex: > >>From: Russ White > > >>-- Section 2.1, in the examples of systems that could use such a >>certificate, they could add soBGP as an example. > >> Absolutely NOT. As we discussed at the Minneapolis IETF meeting, soBGP >> is not acceptable to many operators.. We do not want to link these >> documents. > >, so this reply doesn't surprise me at all. Of course, >Listen-Whisper could also be included as an example, but I suppose since >S-BGP is the _only_ acceptable solution for BGP security.... Russ Housely, not I, was the author of this comment. > >-- Section 2.1.2 seems like it's unecessary to me. Is there any situation >>where you would want to actually represent a block as a range, rather than >>as a set of individual address spaces, or even a summary covering all of >>them? > >> The document says why. It allows "a more concise representation" by >> encoding the range. It is just a way to make the certificate extension >> smaller. > >10.1.0.0/16 is larger than 10.1.0.0 through 10.1.255.255? Since a summary >is a range (the two are precisely the same thing), I consider this a >distinction without a difference. The document did not propose encoding a prefix in the character string format you noted above, although it described that convention as background. Sorry if that caused confusion. While the prefix notation is convenient for people to view and write, it is not so attractive for the machine-based comparisons used to determine whether one range is a subset of another. So, the proposed format in 2.1.2 is a sequence that defines the low and high values for the range, which is easy to encode and to process, and it is unique, which is critical for the DER encoding for certs. The UI for a CA or RA can accept the prefix notation format if that turns out to be a better format for a UI. > >-- Sections 2.2.3.1, 2, and 3 don't seem to be of any use--the address >>family is ipv6 or ipv4, which I thought was covered above in the different >>types of addresses which could be encoded. And I can't imagine anyone >>assigning authorization for a SAFI, since that' essentially just a topology >>within an AFI (?). > >> I do not have enough experience in this area to respond for the authors. > >>-- The entire draft assumes IANA will issue these cert's followed by >>subcerts by the RIR's. What if anyone in the chain doesn't want to >>participate? Should the draft provide the option for other forms of >>authorization? In other words, it should be up to the receiver to trust the >>signer has the authorization to sign, rather than up to the draft writers >>to enforce who can and cannot sign a certificate. > >> I do not think this is a issue in this context. IANA is the root of the >> network address assignment hierarchy. The system does not work if IANA >> and the RIRs do not do their job properly. We gotta trust them. > >>Agreed. Perhaps some verbiage indicating that the main use considered is >>in the public Internet but that these certs could be used in a private >>setting also. > >> I guess this makes sense. IANA is the root for the public >> Internet. Private communities need to pick an appropriate alternative if >> they want to use this tool. > >The system should work without the RIR's, if it needs to. I don't see any >point in limiting it--who knows if the RIR's will be the root in 10 years >time, and private usage may abound, as Tony has suggested. I don't see the >problem with opening this text up some, even through a parenthetical, >stating that "some top level authority within the context of the >internetwork," must sign these certs. Yes, one could use the extension in a purely private context, but for the public Internet it is essential that the CAs be authoritative for the extension data not arbitrary, "trusted" entities. BTW, the RIRs are not the "roots" but rather 2nd tier CAs in this scheme, under IANA. > >1st - AS - 4 bytes should be assigned now. >> It would be good to start at this point to >> use a TLV structure for AS's. > >> A TLV encoding is used that supports integer values of any size: >> ASId ::= INTEGER > >I don't follow... ? I don't see how this supports 4 byte numbers, and I >don't see any reason why the current TLV couldn't be have the space added >to it, rather than being forced to create a new tlv later (?). I' guessing this comment is a result of confusion about how ASN.1 encodes integers. By declaring a variable to be an integer in ASN.1, the code generated for populating the variable and for reading will be able to accommodate a range of integer sizes. Thus both 2 and 4 bytes AS IDs are accommodated automatically, and even bigger ones could be represented in the future, via this convention. Steve From rtg-dir-admin@ietf.org Mon Feb 9 15:49:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10675 for ; Mon, 9 Feb 2004 15:49:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqILD-00005y-00 for rtg-dir-archive@ietf.org; Mon, 09 Feb 2004 15:49:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIKH-00001l-00 for rtg-dir-archive@ietf.org; Mon, 09 Feb 2004 15:48:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqIK0-0007lc-00 for rtg-dir-archive@ietf.org; Mon, 09 Feb 2004 15:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIK1-0007yI-4B; Mon, 09 Feb 2004 15:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIJJ-0007te-J3 for rtg-dir@optimus.ietf.org; Mon, 09 Feb 2004 15:47:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10636 for ; Mon, 9 Feb 2004 15:47:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIJI-0007ko-00 for rtg-dir@ietf.org; Mon, 09 Feb 2004 15:47:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIIN-0007ge-00 for rtg-dir@ietf.org; Mon, 09 Feb 2004 15:46:19 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1AqIHs-0007bJ-00 for rtg-dir@ietf.org; Mon, 09 Feb 2004 15:45:48 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2004 12:44:44 -0800 Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i19KjGYO007480; Mon, 9 Feb 2004 15:45:16 -0500 (EST) Received: from localhost (rtp-vpn1-66.cisco.com [10.82.224.66]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA06923; Mon, 9 Feb 2004 15:45:15 -0500 (EST) Date: Mon, 9 Feb 2004 15:45:13 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: Stephen Kent cc: Alex Zinin , rtg-dir@ietf.org, Russ Housley Subject: Re: Fwd: Re: My thoughts on the draft-ietf-pkix-x509-ipaddr-as-extn-03 comments In-Reply-To: Message-ID: References: <57267060612.20031124120539@psg.com> <19911164974.20031202141003@psg.com> <5.2.0.9.2.20040112122954.028a5e98@mail.binhost.com> <79178507810.20040206115158@psg.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 > >> The document says why. It allows "a more concise representation" by > >> encoding the range. It is just a way to make the certificate extension > >> smaller. > > > >10.1.0.0/16 is larger than 10.1.0.0 through 10.1.255.255? Since a summary > >is a range (the two are precisely the same thing), I consider this a > >distinction without a difference. > > The document did not propose encoding a prefix in the character string > format you noted above, although it described that convention as > background. Sorry if that caused confusion. While the prefix notation is > convenient for people to view and write, it is not so attractive for the > machine-based comparisons used to determine whether one range is a subset > of another. After thinking about this, it really doesn't matter if both ways of representing a prefix block are in there--more flexibility is probably better, in the long run. :-) > Yes, one could use the extension in a purely private context, but for the > public Internet it is essential that the CAs be authoritative for the > extension data not arbitrary, "trusted" entities. BTW, the RIRs are not > the "roots" but rather 2nd tier CAs in this scheme, under IANA. Perhaps there should be a parenthetical about private usage? > > >1st - AS - 4 bytes should be assigned now. > >> It would be good to start at this point to > >> use a TLV structure for AS's. > > > >> A TLV encoding is used that supports integer values of any size: > >> ASId ::= INTEGER > > > >I don't follow... ? I don't see how this supports 4 byte numbers, and I > >don't see any reason why the current TLV couldn't be have the space added > >to it, rather than being forced to create a new tlv later (?). > > I' guessing this comment is a result of confusion about how ASN.1 encodes > integers. By declaring a variable to be an integer in ASN.1, the code > generated for populating the variable and for reading will be able to > accommodate a range of integer sizes. Thus both 2 and 4 bytes AS IDs are > accommodated automatically, and even bigger ones could be represented in > the future, via this convention. Okay, that's fine... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From rtg-dir-admin@ietf.org Tue Feb 10 17:17:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24593 for ; Tue, 10 Feb 2004 17:17:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgBm-0006sX-00 for rtg-dir-archive@ietf.org; Tue, 10 Feb 2004 17:17:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgAn-0006jy-00 for rtg-dir-archive@ietf.org; Tue, 10 Feb 2004 17:16:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqg9o-0006Z1-00 for rtg-dir-archive@ietf.org; Tue, 10 Feb 2004 17:15:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqg9p-0007qT-Dg; Tue, 10 Feb 2004 17:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqg9e-0007nI-57 for rtg-dir@optimus.ietf.org; Tue, 10 Feb 2004 17:14:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24329 for ; Tue, 10 Feb 2004 17:14:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqg9b-0006U7-00 for rtg-dir@ietf.org; Tue, 10 Feb 2004 17:14:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqg8T-0006F6-00 for rtg-dir@ietf.org; Tue, 10 Feb 2004 17:13:42 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1Aqg73-0005sx-00 for rtg-dir@ietf.org; Tue, 10 Feb 2004 17:12:13 -0500 Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i1AMBTM9028527; Tue, 10 Feb 2004 17:11:30 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: References: <57267060612.20031124120539@psg.com> <19911164974.20031202141003@psg.com> <5.2.0.9.2.20040112122954.028a5e98@mail.binhost.com> <79178507810.20040206115158@psg.com> Date: Tue, 10 Feb 2004 10:33:09 -0500 To: Russ White From: Stephen Kent Subject: Re: Fwd: Re: My thoughts on the draft-ietf-pkix-x509-ipaddr-as-extn-03 comments Cc: Alex Zinin , rtg-dir@ietf.org, Russ Housley , Stephen Kent Content-Type: multipart/alternative; boundary="============_-1135671416==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,DATE_IN_PAST_06_12, HTML_MESSAGE autolearn=no version=2.60 --============_-1135671416==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 15:45 -0500 2/9/04, Russ White wrote: > > >> The document says why. It allows "a more concise representation" by >> >> encoding the range. It is just a way to make the certificate extension >> >> smaller. >> > >> >10.1.0.0/16 is larger than 10.1.0.0 through 10.1.255.255? Since a summary >> >is a range (the two are precisely the same thing), I consider this a >> >distinction without a difference. >> >> The document did not propose encoding a prefix in the character string >> format you noted above, although it described that convention as >> background. Sorry if that caused confusion. While the prefix notation is >> convenient for people to view and write, it is not so attractive for the >> machine-based comparisons used to determine whether one range is a subset >> of another. > >After thinking about this, it really doesn't matter if both ways of >representing a prefix block are in there--more flexibility is probably >better, in the long run. :-) I don't want to unduly prolong this discussion, but I do want to be clear about this issue; the I-D provides exactly only one way to represent an individual address block in a certificate extension. The ability to provide different ways of specifying prefixes via UIs is what I think you are referring to, right? > > Yes, one could use the extension in a purely private context, but for the >> public Internet it is essential that the CAs be authoritative for the >> extension data not arbitrary, "trusted" entities. BTW, the RIRs are not >> the "roots" but rather 2nd tier CAs in this scheme, under IANA. > >Perhaps there should be a parenthetical about private usage? No problem. we already revised the text to say: 1. Introduction This document defines two X.509 v3 certificate extensions that allow representation of the transfer of the right to use IP addresses and autonomous system identifiers from one organization to other organizations. The primary use for these extensions is in the public Internet, where IANA is the root that delegates resources through the regional Internet registries (RIRs) to Internet service providers (ISPs) and to user organizations. However, these extensions and the associated processing mechanisms can be employed in private networks, under the auspices of a private PKI representing such delegation. Steve --============_-1135671416==_ma============ Content-Type: text/html; charset="us-ascii" Re: Fwd: Re: My thoughts on the draft-ietf-pkix-x509-ipadd
At 15:45 -0500 2/9/04, Russ White wrote:
> >>  The document says why.  It allows "a more concise representation" by
> >>  encoding the range.  It is just a way to make the certificate extension
> >>  smaller.
> >
> >10.1.0.0/16 is larger than 10.1.0.0 through 10.1.255.255? Since a summary
> >is a range (the two are precisely the same thing), I consider this a
> >distinction without a difference.
>
> The document did not propose encoding a prefix in the character string
> format you noted above, although it described that convention as
> background. Sorry if that caused confusion.  While the prefix notation is
> convenient for people to view and write, it is not so attractive for the
> machine-based comparisons used to determine whether one range is a subset
> of another.

After thinking about this, it really doesn't matter if both ways of
representing a prefix block are in there--more flexibility is probably
better, in the long run. :-)

I don't want to unduly prolong this discussion, but I do want to be clear about this issue; the I-D provides exactly only one way to represent an individual address block in a certificate extension. The ability to provide different ways of specifying prefixes via UIs is what I think you are referring to, right?

> Yes, one could use the extension in a purely private context, but for the
> public Internet it is essential that the CAs be authoritative for the
> extension data not arbitrary, "trusted" entities. BTW, the RIRs are not
> the "roots" but rather 2nd tier CAs in this scheme, under IANA.
Perhaps there should be a parenthetical about private usage?

No problem. we already revised the text to say:

1.  Introduction

   This document defines two X.509 v3 certificate extensions that allow
   representation of the transfer of the right to use IP addresses and
   autonomous system identifiers from one organization to other
   organizations.  The primary use for these extensions is in the
   public Internet, where IANA is the root that delegates resources
   through the regional Internet registries (RIRs) to Internet service
   providers (ISPs) and to user organizations. However, these extensions
   and the associated processing mechanisms can be employed in
   private networks, under the auspices of a private PKI
   representing such delegation.


Steve
--============_-1135671416==_ma============-- From rtg-dir-admin@ietf.org Tue Feb 10 17:20:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24842 for ; Tue, 10 Feb 2004 17:20:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgEp-0007El-00 for rtg-dir-archive@ietf.org; Tue, 10 Feb 2004 17:20:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgDy-00078T-00 for rtg-dir-archive@ietf.org; Tue, 10 Feb 2004 17:19:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqgDa-000721-00 for rtg-dir-archive@ietf.org; Tue, 10 Feb 2004 17:18:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgDc-00005D-F0; Tue, 10 Feb 2004 17:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgCt-0008Rw-7m for rtg-dir@optimus.ietf.org; Tue, 10 Feb 2004 17:18:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24673 for ; Tue, 10 Feb 2004 17:18:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgCq-00070F-00 for rtg-dir@ietf.org; Tue, 10 Feb 2004 17:18:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgBz-0006uU-00 for rtg-dir@ietf.org; Tue, 10 Feb 2004 17:17:19 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AqgBL-0006kQ-00 for rtg-dir@ietf.org; Tue, 10 Feb 2004 17:16:39 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Feb 2004 14:16:20 -0800 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 i1AMG5hu011173; Tue, 10 Feb 2004 17:16:06 -0500 (EST) Received: from localhost (rtp-vpn2-113.cisco.com [10.82.240.113]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA24931; Tue, 10 Feb 2004 17:16:04 -0500 (EST) Date: Tue, 10 Feb 2004 17:16:02 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: Stephen Kent cc: Alex Zinin , rtg-dir@ietf.org, Russ Housley Subject: Re: Fwd: Re: My thoughts on the draft-ietf-pkix-x509-ipaddr-as-extn-03 comments In-Reply-To: Message-ID: References: <57267060612.20031124120539@psg.com> <19911164974.20031202141003@psg.com> <5.2.0.9.2.20040112122954.028a5e98@mail.binhost.com> <79178507810.20040206115158@psg.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 > I don't want to unduly prolong this discussion, but I do want to be clear > about this issue; the I-D provides exactly only one way to represent an > individual address block in a certificate extension. The ability to > provide different ways of specifying prefixes via UIs is what I think you > are referring to, right? Why shouldn't the cert allow the representation of an address range as a prefix/length pair? In the original concept, were the draft authors thinking that you would always treat the ip address space as a number range, and say, for instance: 10.1.0.0 (through) 10.1.255.255? When you say that addresses are given out in ranges, do you mean they are given out this way? Can anyone think of an instance where a registry would give out 10.1.0.0 (through) 10.1.255.1, or some other odd space? If the range is 10.1.0.0 through 10.1.255.0, do you just assume the .255 on the end, since that seems to be what makes sense? I think the prefix lengths are a requirement to make sense of the address space, in normal usage. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From rtg-dir-admin@ietf.org Wed Feb 11 09:16:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01826 for ; Wed, 11 Feb 2004 09:16:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqvAS-0000R1-00 for rtg-dir-archive@ietf.org; Wed, 11 Feb 2004 09:16:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqv9X-0000LN-00 for rtg-dir-archive@ietf.org; Wed, 11 Feb 2004 09:15:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqv8p-0000FQ-00 for rtg-dir-archive@ietf.org; Wed, 11 Feb 2004 09:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqv8p-0005c3-Kg; Wed, 11 Feb 2004 09:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqv8j-0005bG-SM for rtg-dir@optimus.ietf.org; Wed, 11 Feb 2004 09:14:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01729 for ; Wed, 11 Feb 2004 09:14:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqv8i-0000Ei-00 for rtg-dir@ietf.org; Wed, 11 Feb 2004 09:14:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqv7p-00007s-00 for rtg-dir@ietf.org; Wed, 11 Feb 2004 09:14:02 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1Aqv7N-0007nD-00 for rtg-dir@ietf.org; Wed, 11 Feb 2004 09:13:33 -0500 Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i1BECnM9001079; Wed, 11 Feb 2004 09:12:50 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: <57267060612.20031124120539@psg.com> <19911164974.20031202141003@psg.com> <5.2.0.9.2.20040112122954.028a5e98@mail.binhost.com> <79178507810.20040206115158@psg.com> Date: Wed, 11 Feb 2004 09:07:36 -0500 To: Russ White From: Stephen Kent Subject: Re: Fwd: Re: My thoughts on the draft-ietf-pkix-x509-ipaddr-as-extn-03 comments Cc: Alex Zinin , rtg-dir@ietf.org, Russ Housley , Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,SUBJ_HAS_SPACES autolearn=no version=2.60 At 17:16 -0500 2/10/04, Russ White wrote: > > I don't want to unduly prolong this discussion, but I do want to be clear >> about this issue; the I-D provides exactly only one way to represent an >> individual address block in a certificate extension. The ability to >> provide different ways of specifying prefixes via UIs is what I think you >> are referring to, right? > >Why shouldn't the cert allow the representation of an address range as a >prefix/length pair? In the original concept, were the draft authors >thinking that you would always treat the ip address space as a number >range, and say, for instance: 10.1.0.0 (through) 10.1.255.255? When you say >that addresses are given out in ranges, do you mean they are given out this >way? I explained this in my previous response, but let me try again. The prefixes are represented in certs in a fashion that allows for easy comparisons for subset relationships. The low-high range representation can accommodate any address block, so there is no loss of generality when one adopts that representation. There was NEVER any intent to represent an address block as a value and a mask length in a cert. the text in the I-D merely described that convention as background. >Can anyone think of an instance where a registry would give out 10.1.0.0 >(through) 10.1.255.1, or some other odd space? If the range is 10.1.0.0 >through 10.1.255.0, do you just assume the .255 on the end, since that >seems to be what makes sense? > >I think the prefix lengths are a requirement to make sense of the address >space, in normal usage. I don't disagree that value and mask length make for a good UI convention, but there is no need to offer that as a separate encoding in the certs per se. having multiple ways to encode the same info leads to confusion and greater complexity in the security critical code that has to accommodate multiple representations. Steve From rtg-dir-admin@ietf.org Thu Feb 12 01:49:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27703 for ; Thu, 12 Feb 2004 01:49:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArAfa-0004Nn-00 for rtg-dir-archive@ietf.org; Thu, 12 Feb 2004 01:49:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArAec-0004I3-00 for rtg-dir-archive@ietf.org; Thu, 12 Feb 2004 01:48:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArAdj-0004Ce-00 for rtg-dir-archive@ietf.org; Thu, 12 Feb 2004 01:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAdl-0001xl-73; Thu, 12 Feb 2004 01:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArAdi-0001xV-DU for rtg-dir@optimus.ietf.org; Thu, 12 Feb 2004 01:47:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27605 for ; Thu, 12 Feb 2004 01:47:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArAdf-0004C6-00 for rtg-dir@ietf.org; Thu, 12 Feb 2004 01:47:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArAcj-00046w-00 for rtg-dir@ietf.org; Thu, 12 Feb 2004 01:46:58 -0500 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 1ArAc4-0003xP-00; Thu, 12 Feb 2004 01:46:16 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2004 22:53:28 +0000 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1C6jau7013976; Wed, 11 Feb 2004 22:45:45 -0800 (PST) Received: from holbrook-laptop.cisco.com (gorilla.cisco.com [171.69.23.149]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APC77846; Wed, 11 Feb 2004 22:43:46 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id BDBD910B834; Wed, 11 Feb 2004 22:45:31 -0800 (PST) From: Hugh Holbrook To: ssm@ietf.org Cc: rtg-dir@ietf.org, zinin@psg.com, fenner@research.att.com, holbrook@cisco.com, supratik@sprintlabs.com Subject: last call for draft-ietf-ssm-arch-04.txt Reply-To: holbrook@cisco.com Message-Id: <20040212064531.BDBD910B834@holbrook-laptop.cisco.com> Date: Wed, 11 Feb 2004 22:45:31 -0800 (PST) Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Hello everyone., At the last meeting of SSM (in Minneapolis, IETF-58) we had a discussion about draft-ietf-ssm-arch-04.txt that I am hoping we can now bring to a close. In Minneapolis, we discussed whether the draft was ready to advance to the IESG as a STD track document. The discussion centered around the point of whether the IPR claim statement put forth by Apple should delay the document from being advanced to the IESG for consideration as a Proposed Standard. There was clear consensus that the draft was ready to advance on technical grounds. The primary argument made for not advancing the document, was that, by not advancing at this time, we might have a better chance of getting the IPR claimant to change their licensing statement. However, we did not come up with any concrete ideas for achieving this or any explanation of how the delay would help. All but two people who spoke up were of the opinion that the document should advance immediately. It is the opinion of the chairs that the consensus in the room (two dissenting voices acknowledged) was to advance the document. So the purpose of this mail is to ratify that decision on the mailing list, so we can get moving with the next phase of the process. If anyone on the list has reason to think that the standardization process should be delayed, then please speak up now with your reasons. After two weeks with no dissent, this document will be submitted to the IESG for consideration as a Proposed Standard. Thanks! -Hugh and Supratik From rtg-dir-admin@ietf.org Thu Feb 12 22:13:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05031 for ; Thu, 12 Feb 2004 22:13:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTm6-0002tf-00 for rtg-dir-archive@ietf.org; Thu, 12 Feb 2004 22:13:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArTlA-0002nK-00 for rtg-dir-archive@ietf.org; Thu, 12 Feb 2004 22:12:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTlE-00006U-1L; Thu, 12 Feb 2004 22:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArTkt-0008Vv-7k for rtg-dir@optimus.ietf.org; Thu, 12 Feb 2004 22:12:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04968 for ; Thu, 12 Feb 2004 22:12:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArTko-0002kX-00 for rtg-dir@ietf.org; Thu, 12 Feb 2004 22:12:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArTjs-0002ek-00 for rtg-dir@ietf.org; Thu, 12 Feb 2004 22:11:36 -0500 Received: from [216.250.204.66] (helo=coolre41260.com) by ietf-mx with smtp (Exim 4.12) id 1ArTjX-0002aN-00 for rtg-dir@ietf.org; Thu, 12 Feb 2004 22:11:16 -0500 From: "ONYE AMIKWO GODDY" To: rtg-dir@ietf.org Date: Fri, 13 Feb 2004 04:11:31 +0100 Subject: HIGHLY CONFIDENTIAL X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.7 required=5.0 tests=FORGED_MUA_OUTLOOK, LINES_OF_YELLING,MSGID_FROM_MTA_SHORT,NIGERIAN_BODY1,NIGERIAN_BODY2, NIGERIAN_BODY3,NIGERIAN_BODY4,NIGERIAN_SCAM_VIRTUE, RATWARE_OE_MALFORMED,RISK_FREE,SUBJ_ALL_CAPS autolearn=no version=2.60 X-Spam-Report: * 2.8 RATWARE_OE_MALFORMED X-Mailer has malformed Outlook Express version * 0.7 RISK_FREE BODY: Risk free. Suuurreeee.... * 1.8 NIGERIAN_SCAM_VIRTUE BODY: Possible Nigerian Scam Text * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.6 SUBJ_ALL_CAPS Subject is all capitals * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.7 NIGERIAN_BODY2 Message body looks like a Nigerian spam message 2+ * 1.6 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+ * 0.7 NIGERIAN_BODY4 Message body looks like a Nigerian spam message 4+ * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 1.0 NIGERIAN_BODY3 Message body looks like a Nigerian spam message 3+ Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable HIGHLY CONFIDENTIAL FROM=3AMR=2E ONYE AMIKWO GODDY=2E ATTN=3AFRIEND =2E Firstly=2C I must solicit your confidence in this transaction=2C this is by virtue of its nature as being utterly confidential and top secret=2E Though I know that a transaction of this magnitude will make any one apprehensive and worried=2C but I am assuring you that all will be well at the end of the day=2EWe have decided to contact you due to the urgency of this transaction=2C as we have been reliably informed of it's swiftness and confidentiality=2E Let me start by first introducing my humble self to you=2E I am MR=2E ONYE AMIKWO GODDY=2C a Manager at the CONTINENTAL TRUST BANK NIGERIA PLC=2C Lagos=2E I came to know of you in my private search for a reliable and reputable person to handle a very confidential transaction=2C which involves the transfer of a huge sum of money to a foreign account requiring maximum confidence=2E A foreigner=2C Late Engineer William Adams=2C an oil Merchant =2Fcontractor with the federal Government of Nigeria=2C until his death three years ago in a ghastly air crash=2C banked with us here at CONTINENTAL TRUST BANK PLC=2CLagos=2C and had a closing balance of USD22=2E2M which the bank now unquestionably expects to be claimed by any of his available foreign Next of Kin or alternatively be donated to a discredited trust fund for arms and ammunition at a military war collage here in Nigeria=2E Fervent valuable efforts are being made by the CONTINENTAL TRUST BANK to get in touch with any of late Engr=2E William Adams's Next of Kin =28he had no known wife and children=29 that the management under the influence of our chairman=2C board of directors=2C Retired Major General Kalu Uke Kalu=2C that an arrangement for the fund to be declared =22UNCLAIMABLE =22 and then be subsequently donated to the trust fund for Arms and Ammunition=2C which will further enhance the course of war in Africa and the world in general=2E In order to avert this negative development=2C myself and some of my trusted colleagues in the bank now seek for your permission to have you stand as late Engr=2EWILLIAMS ADAMS Next of Kin so that the fund=2C USD$22=2E2M=2C would be subsequently transferred and paid into your bank account as the beneficiary Next of Kin=2E All documents and proves to enable you get this fund have been carefully worked out and we are assuring you a 100% risk free involvement=2E Your share would be 30% of the total amount=2E 10% has been set aside for expenses=2C while the rest would be for myself and my colleagues for purposes in your country=2E If this proposal is acceptable by you and you do not wish to take advantage of the trust we hope to bestow on you=2C then kindly get to me immediately through this my confidential=2C furnishing me with your most confidential telephone=2C mobile and fax numbers=2C so that I can forward to you the relevant details of this transaction and easy communication with you=2E Thank you in advance for your anticipated co-operation=2E Regards=2C MR=2EONYE AMIKWO GODDY=2E From rtg-dir-admin@ietf.org Fri Feb 13 01:41:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11118 for ; Fri, 13 Feb 2004 01:41:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArX1B-0005UX-00 for rtg-dir-archive@ietf.org; Fri, 13 Feb 2004 01:41:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArX0K-0005PR-00 for rtg-dir-archive@ietf.org; Fri, 13 Feb 2004 01:40:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArWzV-0005Kg-00 for rtg-dir-archive@ietf.org; Fri, 13 Feb 2004 01:39:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWzb-0005ZK-6X; Fri, 13 Feb 2004 01:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArWzW-0005YY-Ti for rtg-dir@optimus.ietf.org; Fri, 13 Feb 2004 01:39:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11052 for ; Fri, 13 Feb 2004 01:39:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArWzP-0005K1-00 for rtg-dir@ietf.org; Fri, 13 Feb 2004 01:39:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArWyT-0005EQ-00 for rtg-dir@ietf.org; Fri, 13 Feb 2004 01:38:53 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ArWxv-00058n-00; Fri, 13 Feb 2004 01:38:20 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArWxy-000Ijt-SK; Fri, 13 Feb 2004 06:38:22 +0000 Date: Thu, 12 Feb 2004 22:38:02 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <8930684742.20040212223802@psg.com> To: routing-discussion@ietf.org CC: rtg-dir@ietf.org Subject: Comments solicited: draft-kompella-zinin-early-allocation-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- Please review draft-kompella-zinin-early-allocation-00.txt and provide your comments. We're going to discuss it at the Routing Area meeting in Seoul. Below is the abstract from the document: 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. The document is available at: http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt Send your comments to routing-discussion@ietf.org, please. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Fri Feb 13 14:24:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27399 for ; Fri, 13 Feb 2004 14:24:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ariv0-00016o-00 for rtg-dir-archive@ietf.org; Fri, 13 Feb 2004 14:24:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ariu1-0000zk-00 for rtg-dir-archive@ietf.org; Fri, 13 Feb 2004 14:23:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arit2-0000pm-00 for rtg-dir-archive@ietf.org; Fri, 13 Feb 2004 14:22:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arit1-0001GG-8Y; Fri, 13 Feb 2004 14:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arisd-0001CK-0p for rtg-dir@optimus.ietf.org; Fri, 13 Feb 2004 14:21:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27147 for ; Fri, 13 Feb 2004 14:21:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arisa-0000mN-00 for rtg-dir@ietf.org; Fri, 13 Feb 2004 14:21:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arirg-0000bO-00 for rtg-dir@ietf.org; Fri, 13 Feb 2004 14:20:40 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Ariqa-0000SL-00 for rtg-dir@ietf.org; Fri, 13 Feb 2004 14:19:32 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ariqa-000CWB-5y for rtg-dir@ietf.org; Fri, 13 Feb 2004 19:19:32 +0000 Date: Fri, 13 Feb 2004 11:18:46 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4315037542.20040213111846@psg.com> To: rtg-dir@ietf.org Subject: RTG-DIR Dinner in Seoul MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- Please speak up if you're going to be in Seoul and if you'll be able to come to the rtg-dir dinner Sunday night. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Fri Feb 13 16:42:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08004 for ; Fri, 13 Feb 2004 16:42:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arl4Z-0007Ie-00 for rtg-dir-archive@ietf.org; Fri, 13 Feb 2004 16:42:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arl3B-00076X-00 for rtg-dir-archive@ietf.org; Fri, 13 Feb 2004 16:40:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arl2b-0006yr-00 for rtg-dir-archive@ietf.org; Fri, 13 Feb 2004 16:40:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arl2b-0007NQ-9b; Fri, 13 Feb 2004 16:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arl2D-0007L3-0Z for rtg-dir@optimus.ietf.org; Fri, 13 Feb 2004 16:39:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07766 for ; Fri, 13 Feb 2004 16:39:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arl2A-0006wl-00 for rtg-dir@ietf.org; Fri, 13 Feb 2004 16:39:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arl1S-0006nc-00 for rtg-dir@ietf.org; Fri, 13 Feb 2004 16:38:55 -0500 Received: from gwnj8.utstar.com ([65.200.123.8] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 1Arl0N-0006VK-00 for rtg-dir@ietf.org; Fri, 13 Feb 2004 16:37:47 -0500 Received: (qmail 9931 invoked by uid 404); 13 Feb 2004 21:37:17 -0000 Received: from prz@xebeo.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.263808 secs); 13 Feb 2004 21:37:17 -0000 Received: from unknown (HELO xebeo.com) (172.16.1.102) by lxmail.nj.us.utstar.com with SMTP; 13 Feb 2004 21:37:17 -0000 Message-ID: <402D438E.3010703@xebeo.com> Date: Fri, 13 Feb 2004 22:37:18 +0100 From: Tony Przygienda User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin , rtg-dir@ietf.org Subject: Re: Fwd: Comments solicited: draft-kompella-zinin-early-allocation-00.txt References: <8930684742.20040212223802@psg.com> <9531611775.20040212225329@psg.com> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Alex Zinin wrote: >This is a forwarded message >From: Alex Zinin >To: routing-discussion@ietf.org >Cc: rtg-dir@ietf.org >Date: Thursday, February 12, 2004, 10:38:02 PM >Subject: Comments solicited: draft-kompella-zinin-early-allocation-00.txt > >===8<==============Original message text=============== >Folks- > > Please review draft-kompella-zinin-early-allocation-00.txt and > provide your comments. We're going to discuss it at the Routing > Area meeting in Seoul. Below is the abstract from the document: > > 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. > > The document is available at: > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt > > Send your comments to routing-discussion@ietf.org, please. > > > from my reading necessary and sufficent. Point c) makes me a tad concerned. It ain't clear cut to decide that often but I struggle to come up with a better idea. Actually, I have one but it's not very practical, we could require that such an early allocation must have as structure Code Point followed by Version number but it's tad unwieldy. On the other hand, changing codepoints when a serious flaw preventing interop is detected will run havoc since we'll call 2 codepoints by same name for all practical purposes. Differentiam specificam between earlier and newer versions of draft are pretty opaque to the average feature user but the fact that feature X based on draft Y and feature X based on draft Y+1 will be called the same and not work together, is not. On the other hand, we have sometimes the situation today already so the policy here won't make matter worse I think 2c -- tony From rtg-dir-admin@ietf.org Sat Feb 14 12:55:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25402 for ; Sat, 14 Feb 2004 12:55:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As41J-0005Xd-00 for rtg-dir-archive@ietf.org; Sat, 14 Feb 2004 12:56:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As40L-0005Ot-00 for rtg-dir-archive@ietf.org; Sat, 14 Feb 2004 12:55:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As3zL-0005FI-00 for rtg-dir-archive@ietf.org; Sat, 14 Feb 2004 12:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3zM-0006mY-I4; Sat, 14 Feb 2004 12:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As3yW-0006bb-71 for rtg-dir@optimus.ietf.org; Sat, 14 Feb 2004 12:53:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25119 for ; Sat, 14 Feb 2004 12:53:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As3yU-000597-00 for rtg-dir@ietf.org; Sat, 14 Feb 2004 12:53:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As3xa-00053T-00 for rtg-dir@ietf.org; Sat, 14 Feb 2004 12:52:11 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1As3wv-0004xf-00; Sat, 14 Feb 2004 12:51:29 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1EHpRes024590; Sat, 14 Feb 2004 18:51:27 +0100 Received: from alcatel.be ([138.203.137.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004021418512710:1193 ; Sat, 14 Feb 2004 18:51:27 +0100 Message-ID: <402E6073.1090407@alcatel.be> Date: Sat, 14 Feb 2004 18:52:51 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin Cc: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt References: <8930684742.20040212223802@psg.com> In-Reply-To: <8930684742.20040212223802@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/14/2004 18:51:27, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/14/2004 18:51:28, Serialize complete at 02/14/2004 18:51:28 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hi alex, kireeti, all, would it be possible to detail the difference in procedure between a refresh, a renewal and a re-allocation "3.3. Expiry If early allocations expire before the document progresses to the point where IANA normally makes allocations, the authors and WG chairs may follow an abbreviated version of the process in section x.2 to request renewal of the code points. At most one renewal request may be made; thus, authors should choose carefully when the original request is to be made." the reason being that you're proposing "at most one renew" and i'd like to know if this means i can refresh at most once ? or that i may ask only once for a different code- point value - definition(s) may help here thanks for the clarification(s) - dimitri. Alex Zinin wrote: > Folks- > > Please review draft-kompella-zinin-early-allocation-00.txt and > provide your comments. We're going to discuss it at the Routing > Area meeting in Seoul. Below is the abstract from the document: > > 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. > > The document is available at: > > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt > > Send your comments to routing-discussion@ietf.org, please. > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From rtg-dir-admin@ietf.org Mon Feb 16 16:44:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29438 for ; Mon, 16 Feb 2004 16:44:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqXf-000536-00 for rtg-dir-archive@ietf.org; Mon, 16 Feb 2004 16:44:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqWq-0004ys-00 for rtg-dir-archive@ietf.org; Mon, 16 Feb 2004 16:43:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsqW4-0004uI-00 for rtg-dir-archive@ietf.org; Mon, 16 Feb 2004 16:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqW5-0000mc-9d; Mon, 16 Feb 2004 16:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsqVf-0000km-AG for rtg-dir@optimus.ietf.org; Mon, 16 Feb 2004 16:42:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29340 for ; Mon, 16 Feb 2004 16:42:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsqVd-0004qU-00 for rtg-dir@ietf.org; Mon, 16 Feb 2004 16:42:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsqUh-0004ib-00 for rtg-dir@ietf.org; Mon, 16 Feb 2004 16:41:36 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AsqTZ-0004QC-00 for rtg-dir@ietf.org; Mon, 16 Feb 2004 16:40:26 -0500 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 i1GLdtl22210; Mon, 16 Feb 2004 13:39:55 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp161.static.jnpr.net [172.24.253.161]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1GLdno73292; Mon, 16 Feb 2004 13:39:49 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040216163737.041e5ff0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 16 Feb 2004 16:39:11 -0500 To: Alex Zinin , rtg-dir@ietf.org From: Ross Callon Subject: Re: RTG-DIR Dinner in Seoul Cc: rcallon@juniper.net In-Reply-To: <4315037542.20040213111846@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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_MUA_EUDORA autolearn=no version=2.60 I should be able to attend (subject to preemption due to jet lag). I would propose that we do this reasonably early, on the basis that a fair number of us will be in need of sleep. Ross At 11:18 AM 2/13/2004 -0800, Alex Zinin wrote: >Folks- > > Please speak up if you're going to be in Seoul and if you'll be able > to come to the rtg-dir dinner Sunday night. > >-- >Alex >http://www.psg.com/~zinin/ > From rtg-dir-admin@ietf.org Tue Feb 17 10:40:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06258 for ; Tue, 17 Feb 2004 10:40:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7KX-0001Pk-00 for rtg-dir-archive@ietf.org; Tue, 17 Feb 2004 10:40:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7JU-0001G5-00 for rtg-dir-archive@ietf.org; Tue, 17 Feb 2004 10:39:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At7IV-0001A8-00 for rtg-dir-archive@ietf.org; Tue, 17 Feb 2004 10:38:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7IW-0001jt-JQ; Tue, 17 Feb 2004 10:38:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Hh-0001Li-6p for rtg-dir@optimus.ietf.org; Tue, 17 Feb 2004 10:37:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05855 for ; Tue, 17 Feb 2004 10:37:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7He-00016h-00 for rtg-dir@ietf.org; Tue, 17 Feb 2004 10:37:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7Gl-00012o-00 for rtg-dir@ietf.org; Tue, 17 Feb 2004 10:36:20 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1At7Fy-0000yj-00; Tue, 17 Feb 2004 10:35:30 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1At7Fx-000512-8B; Tue, 17 Feb 2004 15:35:29 +0000 Date: Tue, 17 Feb 2004 07:35:03 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <60347214007.20040217073503@psg.com> To: routing-discussion@ietf.org CC: rtg-dir@ietf.org Subject: Fwd: WG Review: Routing Area Working Group (rtgwg) In-Reply-To: <200402171438.JAA00108@ietf.org> References: <200402171438.JAA00108@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- As the charter says, we would like to create this "generic" routing WG to give home to smaller work items that don't fit in existing WGs and are not big enough for their own ones, such as BTSH, or draft-hsmit-mpls-igp-spf-01.txt. Transport area has some positive experience with TSVWG, which RTGWG was modeled after. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: The IESG To: Cc: Date: Tuesday, February 17, 2004, 6:38:43 AM Subject: WG Review: Routing Area Working Group (rtgwg) ===8<==============Original message text=============== A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by February 19. Routing Area Working Group (rtgwg) ---------------------------------- Current Status: Proposed Working Group Description of Working Group: The Routing area receives occasional proposals for the development and publication of RFCs dealing with routing topics, but for which the required work does not rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and a single BOF would not provide the time to ensure a mature proposal. The rtgwg will serve as the forum for developing these types of proposals. The rtgwg mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion. The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose. ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Tue Feb 17 19:20:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18732 for ; Tue, 17 Feb 2004 19:20:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtFS1-0005xb-00 for rtg-dir-archive@ietf.org; Tue, 17 Feb 2004 19:20:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtFRB-0005uE-00 for rtg-dir-archive@ietf.org; Tue, 17 Feb 2004 19:19:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtFQa-0005qO-00 for rtg-dir-archive@ietf.org; Tue, 17 Feb 2004 19:19:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtFQb-0006jf-GB; Tue, 17 Feb 2004 19:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtFQ6-0006gr-Gy for rtg-dir@optimus.ietf.org; Tue, 17 Feb 2004 19:18:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18669 for ; Tue, 17 Feb 2004 19:18:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtFQ5-0005og-00 for rtg-dir@ietf.org; Tue, 17 Feb 2004 19:18:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtFP9-0005lc-00 for rtg-dir@ietf.org; Tue, 17 Feb 2004 19:17:32 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AtFOv-0005iW-00 for rtg-dir@ietf.org; Tue, 17 Feb 2004 19:17:17 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtFOu-000FrS-TK for rtg-dir@ietf.org; Wed, 18 Feb 2004 00:17:16 +0000 Date: Tue, 17 Feb 2004 16:16:45 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <113378516237.20040217161645@psg.com> To: rtg-dir@ietf.org Subject: Fwd: UPDATED Agenda and Package for February 19, 2004 Telechat In-Reply-To: <200402162209.RAA01092@ietf.org> References: <200402162209.RAA01092@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA18670 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable IESG agenda for this Thursday. Comments to rtg-dir list, please. I'm on vacation Wed-Fri. --=20 Alex http://www.psg.com/~zinin/ INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the February 19, 2004 IESG Teleconference This agenda was generated at 15:19:0 EDT, February 16, 2004 = =20 1. Administrivia = =20 o Roll Call o Bash the Agenda o Approval of the Minutes o Review of Action Items = =20 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Item o draft-ietf-zeroconf-ipv4-linklocal-12.txt Dynamic Configuration of Link-Local IPv4 Addresses (Proposed Standard= ) -=20 1 of 9=20 Note: LC ends on Feb 20, but I'd like to flush out IESG comments and = not=20 lose momentum on finishing the doc and closing the WG.=20 Token: Thomas Narten o Two-document ballot: - 2 of 9 - draft-ietf-avt-rtcp-feedback-08.txt Extended RTP Profile for RTCP-based Feedback(RTP/AVPF) (Proposed=20 Standard)=20 Note: IANA Considerations -  RFC Editor Note  to be - ne= w=20 feedback types not be FCFS.=20 - draft-burmeister-avt-rtcp-feedback-sim-05.txt Extended RTP Profile for RTCP-based Feedback - Results of the Timi= ng=20 Rule Simulations (Informational)=20 Token: Allison Mankin o draft-ietf-ipv6-rfc2011-update-07.txt Management Information Base for the Internet Protocol (IP) (Proposed=20 Standard) - 3 of 9=20 Token: Margaret Wasserman o draft-ietf-dhc-server-mib-10.txt Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB=20 (Proposed Standard) - 4 of 9=20 Token: Margaret Wasserman o draft-ietf-imapext-sort-14.txt INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION (Propose= d=20 Standard) - 5 of 9=20 Token: Ned Freed o draft-ietf-dhc-auth-suboption-03.txt The Authentication Suboption for the DHCP Relay Agent Option (Propose= d=20 Standard) - 6 of 9=20 Token: Margaret Wasserman o draft-ietf-avt-rtp-clearmode-04.txt RTP payload format for a 64 kbit/s transparent call (Proposed Standar= d) -=20 7 of 9=20 Token: Allison Mankin o draft-ietf-send-cga-05.txt Cryptographically Generated Addresses (CGA) (Proposed Standard) - 8 o= f 9=20 Token: Margaret Wasserman o draft-ietf-pkix-sonof3039-05.txt Internet X.509 Public Key Infrastructure: Qualified Certificates Prof= ile=20 (Proposed Standard) - 9 of 9=20 Note: The example in Appendix C contains an error.=E1 The authors are= =20 generating a corrected version. ETSI standard TS 102 280 needs an RFC= =20 number.=20 Token: Russ Housley 2.1.2 Returning Item o draft-ietf-sigtran-sua-16.txt Signalling Connection Control Part User Adaptation Layer (SUA) (Propo= sed=20 Standard) - 1 of 4=20 Note: Returning to clear DISCUSSES.=20 Token: Jon Peterson o draft-ietf-aaa-diameter-mobileip-16.txt Diameter Mobile IPv4 Application (Proposed Standard) - 2 of 4=20 Note: This doc is back. It has been on IESG agenda in Nov . 2002 and=20 again mid 2003. Since has been so long,. I prefer to have IESG review= it=20 again instead of just . trying to figure out if DISCUSSes have been=20 addressed.=20 Token: Bert Wijnen o draft-ietf-mpls-in-ip-or-gre-05.txt Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) (Prop= osed=20 Standard) - 3 of 4=20 Note: Back to telechat to check if comments have been addressed prope= rly.=20 Token: Alex Zinin o draft-ietf-tsvwg-prsctp-03.txt SCTP Partial Reliability Extension (Proposed Standard) - 4 of 4=20 Note: Returning to try to clear DISCUSS.=20 Token: Jon Peterson 2.2 Individual Submissions 2.2.1 New Item o draft-eastlake-ip-mime-08.txt IP over MIME (Proposed Standard) - 1 of 5=20 Note: Recent IESG seem to indicate this document is acceptable. as-is= ;=20 ballot issued and added to the next agenda. We'll. see how it goes.=20 Token: Ned Freed o draft-weltman-ldapv3-proxy-12.txt LDAP Proxied Authentication Control (Proposed Standard) - 2 of 5=20 Token: Ted Hardie o draft-moore-auto-email-response-05.txt Recommendations for Automatic Responses to Electronic Mail (Proposed=20 Standard) - 3 of 5=20 Note: Revision received; added to 19-Feb-2004 IESG agenda=20 Token: Ned Freed o draft-legg-ldap-cmr-module-00.txt ASN.1 Module Definition for the LDAP & X.500 Component Matching Rules= =20 (Proposed Standard) - 4 of 5=20 Note: Connected to work needed by X500 working group=20 Token: Ted Hardie o draft-malamud-no-soliciting-06.txt A No Soliciting SMTP Service Extension (Proposed Standard) - 5 of 5=20 Note: Although last call for the doc doesn't end until. 26-Feb-2004, = I'd=20 really like to get feedback on this. time-sensitive specification fro= m=20 the IESG rather than. wait until after Korea. There's also the issue = of.=20 context being lost in the handoff to a new AD...=20 Token: Ned Freed 2.2.2 Returning Item o draft-zeilenga-ldap-authzid-08.txt LDAP 'Who am I?' Operation (Proposed Standard) - 1 of 1=20 Note: Proposed RFC Editor Note:. . RFC Editor note:. . In section 1,=20 please replace:. OLD:.       Bind controls are not=20 protected by the security layers.     established by the Bi= nd=20 operation which they are.     transferred as part of.. NEW:= .=20     Bind controls are not protected by the security layers.= =20     established by the Bind operation which includes them..= .=20 In section 3, please add the following sentence to the last paragraph= .=20 (which ends with "a multi-stage Bind operation"):. NEW:.    = ;=20 Where a request is received in violation of this absolute.   &nb= sp;=20 prohibition, the server should respond with an operationsError.  = ;=20   result code=20 Token: Ted Hardie 3. Document Actions 3.1 WG Submissions 3.1.1 New Item o draft-ietf-trade-iotp-v1.0-papi-05.txt Payment API for v1.0 Internet Open Trading Protocol (IOTP)=20 (Informational) - 1 of 4=20 Token: Ned Freed o draft-ietf-seamoby-card-protocol-06.txt Candidate Access Router Discovery (Experimental) - 2 of 4=20 Note: "Experimental" Experimental=20 Token: Allison Mankin o draft-ietf-pkix-pkixrep-02.txt Internet X.509 Public Key Infrastructure Repository Locator Service=20 (Experimental) - 3 of 4=20 Token: Russ Housley o draft-ietf-mip4-vpn-problem-statement-02.txt Problem Statement: Mobile IPv4 Traversal of VPN Gateways (Information= al)=20 - 4 of 4=20 Token: Thomas Narten 3.1.2 Returning Item o draft-ietf-opes-iab-04.txt OPES Treatment of IAB Considerations (Informational) - 1 of 2=20 Note: A bit late getting this on the agenda, sorry=20 Token: Ned Freed o draft-ietf-opes-end-comm-06.txt OPES entities and end points communication (Informational) - 2 of 2=20 Note: A bit late getting this on the agenda; sorry=20 Token: Ned Freed 3.2 Individual Submissions Via AD 3.2.1 New Item o draft-eastlake-rfc2777bis-selection-03.txt Publicly Verifiable Nomcom Random Selection (Informational) - 1 of 2=20 Note: Nomcom WG recommended that this be published as Informational, = at=20 the same time as 2727bis.=20 Token: Harald Alvestrand o draft-zilles-pdf-02.txt The application/pdf Media Type (Informational) - 2 of 2=20 Note: Larry Masinter asked for publication as informational=20 Token: Ned Freed 3.2.2 Returning Item o draft-huston-ipv6-documentation-prefix-03.txt IPv6 Address Prefix reserved for Documentation (Informational) - 1 of= 1=20 Note: On agenda to verify RIRs had no comments on this doc; otherwise= =20 ready to go.=20 Token: Thomas Narten 3.3 Individual Submissions Via RFC Editor 3.3.1 New Item o draft-baker-slem-architecture-02.txt Cisco Support for Lawful Intercept In IP Networks (Informational) - 1= of=20 2=20 Token: Steve Bellovin o Two-document ballot: - 2 of 2 - draft-irtf-nmrg-sming-07.txt SMIng - Next Generation Structure of Management Information=20 (Experimental)=20 - draft-irtf-nmrg-sming-snmp-05.txt SMIng Mappings to SNMP (Experimental)=20 Token: Bert Wijnen 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o New IETF Standards Track Discussion (newtrk) - 1 of 3 Token: Harald o Link-Enhancing Transport Intermediary Communication (letic) - 2 of 3 Token: Jon o Host Identity Payload (hip) - 3 of 3 Token: Margaret 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Transport Area Working Group (tsvwg) - 1 of 1 Token: Jon 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issue From rtg-dir-admin@ietf.org Tue Feb 17 22:32:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26018 for ; Tue, 17 Feb 2004 22:32:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtIS3-0004Hz-00 for rtg-dir-archive@ietf.org; Tue, 17 Feb 2004 22:32:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtIRL-0004E1-00 for rtg-dir-archive@ietf.org; Tue, 17 Feb 2004 22:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIRN-0005QM-MV; Tue, 17 Feb 2004 22:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtIRG-0005Pm-Iz for rtg-dir@optimus.ietf.org; Tue, 17 Feb 2004 22:31:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25969 for ; Tue, 17 Feb 2004 22:31:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtIRD-0004D9-00 for rtg-dir@ietf.org; Tue, 17 Feb 2004 22:31:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtIQD-00047t-00 for rtg-dir@ietf.org; Tue, 17 Feb 2004 22:30:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtIPU-00042U-00 for rtg-dir@ietf.org; Tue, 17 Feb 2004 22:30:04 -0500 Received: from [192.116.107.50] (helo=n2now2645.com) by mx2.foretec.com with smtp (Exim 4.24) id 1AtIPO-0004Aw-7q for rtg-dir@ietf.org; Tue, 17 Feb 2004 22:29:59 -0500 From: "DR.CRISTOPHER ADAMU" Reply-To: cadamu2003@sify.com To: rtg-dir@ietf.org Date: Wed, 18 Feb 2004 04:29:57 +0100 Subject: HELLO X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.8 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, FROM_ENDS_IN_NUMS,LINES_OF_YELLING,LINES_OF_YELLING_2,MILLION_USD, NIGERIAN_BODY1,NIGERIAN_BODY2,OPPORTUNITY,RATWARE_OE_MALFORMED, SUB_HELLO,UPPERCASE_75_100 autolearn=no version=2.60 X-Spam-Report: * 2.7 SUB_HELLO Subject starts with "Hello" * 0.9 FROM_ENDS_IN_NUMS From: ends in numbers * 2.8 RATWARE_OE_MALFORMED X-Mailer has malformed Outlook Express version * 0.9 MILLION_USD BODY: Talks about millions of dollars * 1.6 OPPORTUNITY BODY: Gives information about an opportunity * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 0.7 NIGERIAN_BODY2 Message body looks like a Nigerian spam message 2+ * 1.6 NIGERIAN_BODY1 Message body looks like a Nigerian spam message 1+ * 0.0 UPPERCASE_75_100 message body is 75-100% uppercase * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable FROM THE DESK OF DR CRISTOPHER ADAMU BILL AND EXCHANGE MANAGER=2C AFRICAN DEVELOPMENT BANK I AM THE MANAGER OF BILL AND EXCHANGE AT THE FOREIGN REMITTANCE DEPARTMENT OF AFRICAN DEVELOPMENT BANK=28ADB=29=2E AFTER A LONG SEARCH FOR A REPUTED FOREIGNER TO WHOM WE CAN CONFIDE A SENSITIVE MATTERS'OF THIS NATURE=2CI AND TWO OTHER OF MY COLLEAGUE NOW AGREE TO SEND YOU THIS PROPOSAL=2CFOLLOWING THE IMPRESSIVE INFORMATION WE RECENTLY GATHERED ABOUT YOU THROUGH ONE OFOUR FRIEND WHO RUN A CONSULTANCY FIRM IN YOUR COUNTRY=2EHE ASSURED US OF YOUR CAPABILITY AND RELIABILITY TO CHAMPION THIS BUSINESS OPPORTUNITY=2EIN MY DEPARTMENT WE DISCOVER AN ABANDON SUM OF $35=2E5USD=28THIRTY FIVE MILLION=2CFIVE HUNDRED THOUSAND UNITED STATE DOLLARS=29IN AN ACCOUNT THAT BELONG TO ONE OF OUR FOREIGN CUSTOMER WHO DIED ALONG WITH HIS ENTIRE FAMILY IN A CONCORD PLANE CRASH IN THE YEAR 2000 IN PARIS THAT ALMOST KILLED THE WHOLE PASSENGERS ON BOARD=2ESINCE WE GOT THE INFORMATION OF HIS DEATH=2CWE HAVE BEEN EXPECTING HIS NEXT OF KIN TO SHOW UP AND CLAIM THE FUND=2CWE HAD ALSO MADE SOME FRANTIC EFFORT TO CONTACT ANY OF HIS RELATIONS'BUT ALL TO NO AVAIL=2E MEANWHILE=2CWE DONT WANT THE FUND TO GO INTO THE BANK TREASURY AS THE BANKING LAW & GUIDELING OVER HERE STIPULATES THAT IF SUCH MONEY REMAIN UNCLAIM AFTER A SPACE OF THREE YEARS=2CTHE FUND AUTOMATICALLY BE TRANSFERRED INTO THE BANK TREASURY ACCOUNT AS UNCLAIM BILL=2EIN ANY CASE=2CWE GATHERED AT LONG LAST THAT THE SURPPOSE NEXT OF KIN OR RELATION DIED ALONGSIDE WITH HIM IN THE CRASH=2EIT IS THEREFORE UPON THIS DISCOVERY THAT I AND TWO OTHER DEPARTMENT MANAGERS REACHED ANGREEMENT TO CONTACT YOU=2E FIRST=2CTO RELEASE THE FUND INTO YOUR NOMINATED BANK ACCOUNT AS THE NEXT OF KIN OR THE RELATION TO THE DECEASED FOR SAFETY=2CMEANWHILE WE INTEND TO RESIGN OUR APPOINTMENT WITH ADB AND TRAVEL DOWN TO YOUR COUNTRY FOR DISBURSEMENT IMMEDIATLY THE FUND IS TRANSFERRED INTO YOUR NOMINATED BANK ACCOUNT=2E ONE OTHER REASON WHY THE REQUEST OF FOREIGNER AS THE NEXT OF KIN IN THIS BUSINESS WAS OCCASSION BY THE FACT THAT THE CUSTOMER IN QUESTION WAS A FOEREIGNER AND IS ONLY A FOREIGNER ALIKE CAN COME FORWARD FOR CLAIM=2E WE HAD EQUALLY AGREED TO SHARE THE FUND AS FOLLOW=3A60% FOR US AND 30% TO YOU FOR SAFEGUARDING & PROVIDING US THE ACCOUNT WHILE 10% IS SET ASIDE TO OFFSET ALL EXPENSE THAT WILL BE INCURED IN THE COURSE OF THE TRANSFERBY BOTH PARTIES=2E MAY I ALSO BRING TO YOUR NOTICE THAT THIS TRANSACTION IS HUNDRED PERCENT RISKFREE AND YOU SHOULD NOT ENTERTAIN ANY FORM OF FEAR OR WORRY YOUR CONCIENCE OVER THESE BREAKTHROUGH=2CAS CHANCES LIKE THIS COME ONCE IN A LIFE TIME=2CAND WE MUST MAKE MOST GOOD OF EVERY OPPORTUNITY=2E ALL MODERLITIES THAT WILL EFFECT A SMOOTH TRANSFER OF THE FUND INTO YOUR ACCOUNT HAS BEEN ARRANGED AT THE HIGHEST LEVEL=2EINCONCLUSION=2CI AND MY COLLEAGUE BENT ON HOLDING UNTO THE IMPRESSIVE INFORMATION WE HAD ABOUT YOU =2CHOPING YOU WILL NOT DISAPPOINT US DURING AND AFTER THE TRANSACTION=2E MORESO=2CWE WILL HIGHLY APPRECIATE YOUR COURAGE TO ASSIST US REALISE THIS GOAL AND ALSO ENDEAVOUR TO ENCLOSE YOUR TELEPHONE AND FAX NUMBER=2CYOUR BANK NAME & ACCOUNT NUMBER WERE THE FUND WILL BE EASILY TRANSFERRED INTO=2E PLEASE=2CALSO NOTE THAT WE ARE STILL IN ACTIVE SERVICE IN OUR VARIOUS DEPARTMENTS IN THE BANK AND WE CAN'T AFFORD ANYTHING TO JORPADISE THIS ONE IN A LIFE TIME FORTUNE=2CAS SUCH WE WILL MAKE TRUST=2FSTRICKLY CONFIDENTIALITY OUR UTMOST WATCHWARD=2E THANK YOU FOR YOUR ANTICIPATED RESPOND WHILE I lOOKFORWARD TO HEAR FROM YOU SOONEST=2E REGARDS DR=2ECRISTOPHER ADAMU BILL AND EXCHANGE MANAGER From rtg-dir-admin@ietf.org Wed Feb 18 09:00:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11298 for ; Wed, 18 Feb 2004 09:00:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSFy-0000I6-00 for rtg-dir-archive@ietf.org; Wed, 18 Feb 2004 09:00:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtSF4-0000Du-00 for rtg-dir-archive@ietf.org; Wed, 18 Feb 2004 08:59:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtSE8-00008R-00 for rtg-dir-archive@ietf.org; Wed, 18 Feb 2004 08:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSE9-00008k-2n; Wed, 18 Feb 2004 08:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSDy-00007r-IX for rtg-dir@optimus.ietf.org; Wed, 18 Feb 2004 08:58:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11138 for ; Wed, 18 Feb 2004 08:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSDx-00006V-00 for rtg-dir@ietf.org; Wed, 18 Feb 2004 08:58:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtSCz-00001N-00 for rtg-dir@ietf.org; Wed, 18 Feb 2004 08:57:50 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AtSC7-0007i8-00 for rtg-dir@ietf.org; Wed, 18 Feb 2004 08:56:55 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 304A32D48EE for ; Wed, 18 Feb 2004 08:56:20 -0500 (EST) 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 40042-02-46 for ; Wed, 18 Feb 2004 08:56:19 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id EBC752D4837 for ; Wed, 18 Feb 2004 08:56:17 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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: RTG-DIR Dinner in Seoul Date: Wed, 18 Feb 2004 08:56:17 -0500 Message-ID: Thread-Topic: RTG-DIR Dinner in Seoul Thread-Index: AcPyZq96RzDPfb+vTnWR+pcYHNwaQADmgm5A From: "Susan Hares" To: "Alex Zinin" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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: quoted-printable I'll be in Seoul, and I can come to a dinner Sunday night. sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Friday, February 13, 2004 2:19 PM To: rtg-dir@ietf.org Subject: RTG-DIR Dinner in Seoul Folks- Please speak up if you're going to be in Seoul and if you'll be able to come to the rtg-dir dinner Sunday night. --=20 Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Wed Feb 18 12:29:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00984 for ; Wed, 18 Feb 2004 12:29:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtVWL-0006Ro-00 for rtg-dir-archive@ietf.org; Wed, 18 Feb 2004 12:30:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVVP-0006NE-00 for rtg-dir-archive@ietf.org; Wed, 18 Feb 2004 12:29:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtVUP-0006Ib-00 for rtg-dir-archive@ietf.org; Wed, 18 Feb 2004 12:28:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVUP-00083x-KU; Wed, 18 Feb 2004 12:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVTV-00080O-7o for rtg-dir@optimus.ietf.org; Wed, 18 Feb 2004 12:27:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00814 for ; Wed, 18 Feb 2004 12:27:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtVTT-0006EH-00 for rtg-dir@ietf.org; Wed, 18 Feb 2004 12:27:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVSY-0006At-00 for rtg-dir@ietf.org; Wed, 18 Feb 2004 12:26:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1AtVRn-00067P-00; Wed, 18 Feb 2004 12:25:19 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtVRk-0004SN-Ud; Wed, 18 Feb 2004 17:25:17 +0000 Date: Wed, 18 Feb 2004 09:24:55 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <174440205962.20040218092455@psg.com> To: iesg@ietf.org CC: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Offline till Sunday MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Taking the family to Tahoe. Won't know the word "e-mail" until Sunday. -- Alex From rtg-dir-admin@ietf.org Wed Feb 18 13:10:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05784 for ; Wed, 18 Feb 2004 13:10:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtW97-0004uR-00 for rtg-dir-archive@ietf.org; Wed, 18 Feb 2004 13:10:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtW88-0004pP-00 for rtg-dir-archive@ietf.org; Wed, 18 Feb 2004 13:09:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtW77-0004kH-00 for rtg-dir-archive@ietf.org; Wed, 18 Feb 2004 13:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtW78-00038s-A9; Wed, 18 Feb 2004 13:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtW6A-0002rW-QF for rtg-dir@optimus.ietf.org; Wed, 18 Feb 2004 13:07:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05553 for ; Wed, 18 Feb 2004 13:06:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtW68-0004c7-00 for rtg-dir@ietf.org; Wed, 18 Feb 2004 13:07:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtW4z-0004Oq-00 for rtg-dir@ietf.org; Wed, 18 Feb 2004 13:05:49 -0500 Received: from mail-dark.research.att.com ([192.20.225.112]) by ietf-mx with esmtp (Exim 4.12) id 1AtW3L-0003uR-00; Wed, 18 Feb 2004 13:04:07 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mail-dark.research.att.com (Postfix) with ESMTP id EA5D5E80D8; Wed, 18 Feb 2004 13:04:28 -0500 (EST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id BE1D7F3B36; Wed, 18 Feb 2004 12:57:25 -0500 (EST) Received: from berkshire.research.att.com (sigaba.research.att.com [135.207.23.169]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id i1II3XZ12455; Wed, 18 Feb 2004 13:03:33 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 454DE7B43; Wed, 18 Feb 2004 13:03:33 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Alex Zinin Cc: iesg@ietf.org, rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: Offline till Sunday In-Reply-To: Your message of "Wed, 18 Feb 2004 09:24:55 PST." <174440205962.20040218092455@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Feb 2004 13:03:33 -0500 Message-Id: <20040218180333.454DE7B43@berkshire.research.att.com> Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 In message <174440205962.20040218092455@psg.com>, Alex Zinin writes: > >Taking the family to Tahoe. Won't know the word "e-mail" >until Sunday. > Enjoy! --Steve Bellovin, http://www.research.att.com/~smb From rtg-dir-admin@ietf.org Fri Feb 20 17:01:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17086 for ; Fri, 20 Feb 2004 17:01:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuIiH-0006g6-00 for rtg-dir-archive@ietf.org; Fri, 20 Feb 2004 17:01:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuIh2-0006ZZ-00 for rtg-dir-archive@ietf.org; Fri, 20 Feb 2004 17:00:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuIgm-0006V7-00 for rtg-dir-archive@ietf.org; Fri, 20 Feb 2004 17:00:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuIgm-0007a7-NP; Fri, 20 Feb 2004 17:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuIfx-0007Ym-6z for rtg-dir@optimus.ietf.org; Fri, 20 Feb 2004 16:59:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16988 for ; Fri, 20 Feb 2004 16:59:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuIfv-0006TT-00 for rtg-dir@ietf.org; Fri, 20 Feb 2004 16:59:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuIf3-0006Qo-00 for rtg-dir@ietf.org; Fri, 20 Feb 2004 16:58:18 -0500 Received: from dsl-200-67-36-146.prod-infinitum.com.mx ([200.67.36.146]) by ietf-mx with smtp (Exim 4.12) id 1AuIeS-0006NM-00; Fri, 20 Feb 2004 16:57:43 -0500 Received: from 204.146.32.233 by 200.67.36.146; Fri, 20 Feb 2004 21:01:17 -0100 Message-ID: From: "Ignacio Landis" Reply-To: "Ignacio Landis" To: rtg-bfd@ietf.org Cc: rtg-dir@ietf.org, rtg-rdd@ietf.org Subject: Do you smoke? Date: Fri, 20 Feb 2004 15:05:17 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1992149120213924141" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=HTML_50_60,HTML_FONTCOLOR_RED, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----1992149120213924141 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Brand Name Cigarettes Delivered To Your Door For Less.

Xinsensible debrief z barnett tomograph cochineal audible legging legatee = hinduism sanguinary=20 ? Wbeijing newbold stoppage adventurous ague bare a= ida=20. Wacreage gymnosperm huntley shish delphinium grandson success wit = sulfurous gladden antimony frankfurt scant asteria cede airman don't turmo= il hamburg diurnal anneal attic forward troglodyte precocity mammalian gay= abuilding staley broken unanimous circus duluth rhapsodic doorway alabama= neanderthal pl symphony teeter incontrollable palmolive facetious execute= bellicose spacious transmission revolt debbie haulage lignum army transfu= sable ensemble distinct petrology transect alexandria epicurean hartford=20= Yephemeris alberich laurel multiply parasitic condone credent demigod rad= ical anomie antioch gilligan phantasy obey bond moines indoeuropean orches= tra autograph desmond clobber ethane=20 . Wlend bursty mckeon inroad astig= mat blacksmith coauthor dolt fitzpatrick dreamlike decant lesbian cleanse = achromatic schema euclid sagebrush osteoporosis contraband carmichael=20!!= ! Gemerald chopin wink pretend wet dudley dreamt synapse ellipse gaze chat= tel hero aquarium guideline spoke radioactive emerald ajax ebb chop conest= oga lubricious crusoe dressmake=20.Tefflorescent invention multiplicand pe= rjure trumpet propensity hangar=20? Tcol circumlocution hearty cocklebur a= spidistra hall redemptive anathema doyle divorce=20; Kbrookside ragging ca= rfare calligraph twill slapstick tulane slam=20=20Xprojectile abash dispen= sary merlin extralegal smitten=20. Stangy delusive permalloy amanuensis ly= ra perform coleman edematous craggy cologne literary quickie crupper=20. S= produce abject thursday daniel mugging latch gabble iambic indistinguishab= le hypothesis scare crosswalk emery silty uterine cabinetry spoil carnival= eagan buckaroo stain planar percent gull sorption shutdown=20 Zbainite ab= horred mortem ahem bifocal=20!!! Bcollectible captivate badland britannica= paranoid delude contralateral campfire telescopic matinee corrigible demo= cratic pullman=20. Ebetty sawmill dictatorial affectate cannel ophiuchus d= ebunk chamber inadvisable beta radioactive lash hurricane hemorrhage proje= ctor endurance w cathedra glaucous pyrophosphate ode adamson glaze toiletr= y palette amra schaefer protozoan bib abode delicacy aerospace peal heron = impropriety=20 Npoetic von crossbow anarchy blocky fluoresce without carmi= ne ditto rightward margo selectmen allude=20 ? Fcapo hose cummings cartrid= ge checksumming bronchiolar edging noble despond riddle attache hilton tac= it manganese dram bangle metronome mongolia biaxial culpable sewerage crut= ch puck cauliflower nanking larry=20. Cdetour ferment cloak snuggle afflic= t annular baylor scroll congolese menelaus embargoes bindery arabesque sha= h=20.Xcredent english mimetic lithic coach lent suntanned toast auric ling= ua liquefaction=20 ? Pconcocter script rebecca toefl dispelled kodak bride= groom twosome floodlit mbabane krishna carne tow jericho askance lapel ogd= en centric confound lipid bursitis titanic gift gamesman fiction delight s= pearhead capitulate allegory endosperm sumptuous=20. Gslight cyst corundum= dearth scotsmen cornet coastline solitaire gooseberry closeup confine pra= gmatism acculturate cafe transmitting cosine buttonhole plushy palladia br= otherhood viscoelastic zoroaster sushi crumb expelled misanthrope acknowle= dge annihilate afterward shiloh goff mausoleum inaugurate goldfish ankara = dozen inhabitant chalet nebulous appellant=20.

Welcome to Cigarette War= ehouse

       &nbs= p;    3D"The
  New Products NOW OFFERING FREE SHIPPING = when your order 2 or more cartons!
3DWinston
Winston
$22.27
3DSalem
Salem
$22.27
3D"Lucky
Lucky Strike
$23.45
3D"Kent=
Kent 1mg
$23.45
3D"Camel
Camel Lights
$22.27
3DCamel
Camel
$22.27
Realize savings of HUNDREDS or even THOUSANDS of dol= lars over the course of a year whe<= /germanium>n purchasing cigarettes through = Cigarette Warehouse.

We stock only the freshest cigarettes of the highest quality= made by the biggest manufacturing names in the cigarette business! Our pr= oducts are guaranteed to be fresh a= nd genuine.

Don't get burned by unfair ciga<= /subtly>rette prices! Our representatives are s= tanding by to take your order. Once your order is received, it will= be processed and shipped to your home or office. Place your order = for quality low-cost cigarettes now= !

Please Visit Us Here...=

Wsculpture apprehend councilwoman delirious thoroughgoing=20! Rgentian jud= d degum delouse dorothy penitentiary negligible tiger stratum fetid slat p= op surcharge eider coagulate hallow imitable agreeing lotion tiny=20. Nabe= l strife deer totem adrenal afterward chickadee canvas tectonic bristol ps= ychometry censor bunny detractor magenta byway downstream candace wesley m= edicate bordeaux middlesex indiscernible=20=20%RND_SUBJECTcastor wallaby n= ominee administrate wino corpse mekong knowles sermon inquisitor wizard co= nfucius=201992149120213924141

----1992149120213924141-- From rtg-dir-admin@ietf.org Tue Feb 24 16:04:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11063 for ; Tue, 24 Feb 2004 16:04:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avjiw-0002IK-00 for rtg-dir-archive@ietf.org; Tue, 24 Feb 2004 16:04:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avji4-0002E6-00 for rtg-dir-archive@ietf.org; Tue, 24 Feb 2004 16:03:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avjhl-00029W-00 for rtg-dir-archive@ietf.org; Tue, 24 Feb 2004 16:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjhk-0001ff-RU; Tue, 24 Feb 2004 16:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avjh9-0001e8-Vq for rtg-dir@optimus.ietf.org; Tue, 24 Feb 2004 16:02:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10994 for ; Tue, 24 Feb 2004 16:02:21 -0500 (EST) From: fenner@research.att.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avjh8-00027r-00 for rtg-dir@ietf.org; Tue, 24 Feb 2004 16:02:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvjgI-00022o-00 for rtg-dir@ietf.org; Tue, 24 Feb 2004 16:01:30 -0500 Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1Avjfu-0001w3-00; Tue, 24 Feb 2004 16:01:06 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by mail-white.research.att.com (Postfix) with ESMTP id 285296640AB; Tue, 24 Feb 2004 15:59:08 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 1C4DAF3B76; Tue, 24 Feb 2004 15:56:14 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i1OL0Wf23123; Tue, 24 Feb 2004 13:00:32 -0800 (PST) Message-Id: <200402242100.i1OL0Wf23123@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: iesg@ietf.org, rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Lost email Date: Tue, 24 Feb 2004 13:00:31 -0800 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,NO_REAL_NAME autolearn=no version=2.60 Folks, I lost a significant amount of email on Feb 21, 22 and 23. If you sent me something important, please retransmit if you can. Thanks, Bill From rtg-dir-admin@ietf.org Wed Feb 25 01:37:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00643 for ; Wed, 25 Feb 2004 01:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avsfj-0003S9-00 for rtg-dir-archive@ietf.org; Wed, 25 Feb 2004 01:37:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avsev-0003O9-00 for rtg-dir-archive@ietf.org; Wed, 25 Feb 2004 01:36:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvseF-0003J6-00 for rtg-dir-archive@ietf.org; Wed, 25 Feb 2004 01:35:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvseH-0000Sb-8M; Wed, 25 Feb 2004 01:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avsdp-0000QD-L2 for rtg-dir@optimus.ietf.org; Wed, 25 Feb 2004 01:35:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00530 for ; Wed, 25 Feb 2004 01:35:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avsdm-0003GF-00 for rtg-dir@ietf.org; Wed, 25 Feb 2004 01:35:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avscn-00038o-00 for rtg-dir@ietf.org; Wed, 25 Feb 2004 01:34:30 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Avsbq-00030e-00 for rtg-dir@ietf.org; Wed, 25 Feb 2004 01:33:30 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avsbq-0009it-Sn for rtg-dir@ietf.org; Wed, 25 Feb 2004 06:33:30 +0000 Date: Tue, 24 Feb 2004 22:33:05 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1639659800.20040224223305@psg.com> To: rtg-dir@ietf.org Subject: Re: RTG-DIR Dinner in Seoul In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit So far I have Danny, Ross, and Sue. How about we meet Sunday 5pm near the hotel registration? -- Alex http://www.psg.com/~zinin/ Wednesday, February 18, 2004, 5:56:17 AM, Susan Hares wrote: > I'll be in Seoul, and I can > come to a dinner Sunday night. > sue > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Friday, February 13, 2004 2:19 PM > To: rtg-dir@ietf.org > Subject: RTG-DIR Dinner in Seoul > Folks- > Please speak up if you're going to be in Seoul and if you'll be able > to come to the rtg-dir dinner Sunday night. From rtg-dir-admin@ietf.org Wed Feb 25 17:14:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18459 for ; Wed, 25 Feb 2004 17:14:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7I3-00043c-00 for rtg-dir-archive@ietf.org; Wed, 25 Feb 2004 17:14:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7H2-0003uY-00 for rtg-dir-archive@ietf.org; Wed, 25 Feb 2004 17:13:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7G4-0003oA-00 for rtg-dir-archive@ietf.org; Wed, 25 Feb 2004 17:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7G4-0008Pm-L0; Wed, 25 Feb 2004 17:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw7FA-00087r-38 for rtg-dir@optimus.ietf.org; Wed, 25 Feb 2004 17:11:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18245 for ; Wed, 25 Feb 2004 17:11:00 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7F7-0003iq-00 for rtg-dir@ietf.org; Wed, 25 Feb 2004 17:11:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw7ED-0003dq-00 for rtg-dir@ietf.org; Wed, 25 Feb 2004 17:10:06 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1Aw7DH-0003Z2-00; Wed, 25 Feb 2004 17:09:08 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1PM95t24985; Thu, 26 Feb 2004 00:09:05 +0200 (EET) X-Scanned: Thu, 26 Feb 2004 00:09:04 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i1PM94SM031685; Thu, 26 Feb 2004 00:09:04 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00jStwaf; Thu, 26 Feb 2004 00:09:03 EET 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 i1PM92O07209; Thu, 26 Feb 2004 00:09:02 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 25 Feb 2004 16:08:13 -0600 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: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Date: Wed, 25 Feb 2004 16:08:13 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F799BA@daebe009.americas.nokia.com> Thread-Topic: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Thread-Index: AcPx/WgGX//BcEc6TwWWgLdi1KKV1QJ7KuRw To: , Cc: X-OriginalArrivalTime: 25 Feb 2004 22:08:13.0945 (UTC) FILETIME=[DCF53690:01C3FBEB] Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Alex, I finally got a chance to read the draft. The idea is good. I just=20 have a couple of questions/concerns about the expiry of the early allocations.. - Do you think that "at most one renewal" would work in practice ? There might be instances where there is a genuine need to keep the early allocations for more than a year (Consider VRRPv3). How do we deal with that situation ? If it is not possible to=20 renew the allocations more than once, do we need to ask for early allocations with new numbers (which ofcourse will make=20 the situation worse) or we should just ask/let IANA to delete and reassign those numbers (which would create problems as well).=20 - The draft seems to put the responsibility of changing the status of the early allocations on the WG chairs ? I know that our chairs are very very responsible but I think, it will be a good idea to have an alternate mechanism in place such that the early allocations=20 are marked deprecated/deleted automatically after a timeout. Regards Mukesh > -----Original Message----- > From: routing-discussion-admin@ietf.org > [mailto:routing-discussion-admin@ietf.org]On Behalf Of ext Alex Zinin > Sent: Thursday, February 12, 2004 10:38 PM > To: routing-discussion@ietf.org > Cc: rtg-dir@ietf.org > Subject: Comments solicited: > draft-kompella-zinin-early-allocation-00.txt >=20 >=20 > Folks- >=20 > Please review draft-kompella-zinin-early-allocation-00.txt and > provide your comments. We're going to discuss it at the Routing > Area meeting in Seoul. Below is the abstract from the document: >=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 > The document is available at: > =20 > =20 > http://www.ietf.org/internet-drafts/draft-kompella-zinin-early > -allocation-00.txt > =20 > Send your comments to routing-discussion@ietf.org, please. > =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 From rtg-dir-admin@ietf.org Thu Feb 26 09:46:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16190 for ; Thu, 26 Feb 2004 09:46:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMmh-0001Bo-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 09:46:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMln-00015k-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 09:45:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwMl3-0000zb-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 09:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMl4-0002Jq-MC; Thu, 26 Feb 2004 09:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwMko-0002It-T2 for rtg-dir@optimus.ietf.org; Thu, 26 Feb 2004 09:44:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16057 for ; Thu, 26 Feb 2004 09:44:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwMkn-0000y0-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 09:44:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwMju-0000sU-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 09:43:50 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AwMjU-0000mX-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 09:43:24 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id F31E42D482E for ; Thu, 26 Feb 2004 09:42:53 -0500 (EST) 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 34339-01-15 for ; Thu, 26 Feb 2004 09:42:52 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4448C2D4818 for ; Thu, 26 Feb 2004 09:42:52 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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: RTG-DIR Dinner in Seoul Date: Thu, 26 Feb 2004 09:42:52 -0500 Message-ID: Thread-Topic: RTG-DIR Dinner in Seoul Thread-Index: AcP7aakCx5HBA03gSBiRvmYrzl7GvAAnSc6A From: "Susan Hares" To: "Alex Zinin" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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: quoted-printable 6 -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Wednesday, February 25, 2004 1:33 AM To: rtg-dir@ietf.org Subject: Re: RTG-DIR Dinner in Seoul So far I have Danny, Ross, and Sue. 5:00 pm is great. Sue How about we meet Sunday 5pm near the hotel registration? --=20 Alex http://www.psg.com/~zinin/ Wednesday, February 18, 2004, 5:56:17 AM, Susan Hares wrote: > I'll be in Seoul, and I can > come to a dinner Sunday night. > sue > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Friday, February 13, 2004 2:19 PM > To: rtg-dir@ietf.org > Subject: RTG-DIR Dinner in Seoul > Folks- > Please speak up if you're going to be in Seoul and if you'll be able > to come to the rtg-dir dinner Sunday night. From rtg-dir-admin@ietf.org Thu Feb 26 11:28:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22903 for ; Thu, 26 Feb 2004 11:28:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwONM-0005aB-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 11:28:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwOMO-0005Uy-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 11:27:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwOLl-0005QS-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 11:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOLl-0002O0-PN; Thu, 26 Feb 2004 11:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOLQ-0002Kg-Rd for rtg-dir@optimus.ietf.org; Thu, 26 Feb 2004 11:26:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22754 for ; Thu, 26 Feb 2004 11:26:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwOLP-0005P6-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 11:26:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwOKW-0005K3-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 11:25:45 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AwOJq-00059n-00; Thu, 26 Feb 2004 11:25:02 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i1QGOWPg012095; Thu, 26 Feb 2004 08:24:32 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i1QGOVlO012092; Thu, 26 Feb 2004 08:24:31 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 26 Feb 2004 08:24:31 -0800 (PST) From: Kireeti Kompella To: Mukesh.Gupta@nokia.com cc: zinin@psg.com, routing-discussion@ietf.org, rtg-dir@ietf.org Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401F799BA@daebe009.americas.nokia.com> Message-ID: <20040226081555.S11637@kummer.juniper.net> References: <8D260779A766FB4A9C1739A476F84FA401F799BA@daebe009.americas.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 On Wed, 25 Feb 2004 Mukesh.Gupta@nokia.com wrote: > I finally got a chance to read the draft. The idea is good. I just > have a couple of questions/concerns about the expiry of the early > allocations.. > > - Do you think that "at most one renewal" would work in practice ? > There might be instances where there is a genuine need to keep > the early allocations for more than a year (Consider VRRPv3). > How do we deal with that situation ? If it is not possible to > renew the allocations more than once, do we need to ask for > early allocations with new numbers (which ofcourse will make > the situation worse) or we should just ask/let IANA to delete > and reassign those numbers (which would create problems as well). We mulled a bit over how many times the allocations should be renewed. The idea is that early allocation should NOT be requested as sson as an ID is written :-) One renewal may be a bit too aggressive, but it gives two years. Perhaps two renewals is okay, but no more (imho). > - The draft seems to put the responsibility of changing the status > of the early allocations on the WG chairs ? I know that our chairs > are very very responsible but I think, it will be a good idea to > have an alternate mechanism in place such that the early allocations > are marked deprecated/deleted automatically after a timeout. Automatic expiry was actually in the first version, but not everyone felt comfortable with that. We can (and should) review this, and perhaps make clearer what expiry means. Note that NOT adding to either IANA's or the IESG's workload is an explicit goal. Whatever we can do to avoid adding to WG chairs' workload is a 'nice-to-have' :-) Kireeti. ------- From rtg-dir-admin@ietf.org Thu Feb 26 12:01:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24641 for ; Thu, 26 Feb 2004 12:01:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwOtL-0001kO-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 12:01:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwOsF-0001VK-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 12:00:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwOqm-0001EM-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 11:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOqj-0005jy-7h; Thu, 26 Feb 2004 11:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwOqQ-0005i3-2C for rtg-dir@optimus.ietf.org; Thu, 26 Feb 2004 11:58:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24247 for ; Thu, 26 Feb 2004 11:58:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwOqO-0001Ak-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 11:58:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwOpN-0000wi-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 11:57:37 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AwOoR-0000mH-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 11:56:39 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwOoR-0004om-8W for rtg-dir@ietf.org; Thu, 26 Feb 2004 16:56:39 +0000 Date: Thu, 26 Feb 2004 08:55:44 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <2013044677.20040226085544@psg.com> To: rtg-dir@ietf.org Subject: rtg-dir += dimitri; rtg-dir += loa; MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- I would like to welcome Dimitri Papadimitriou and Loa Andersson to the directorate. They have just been added to the mailing list. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Thu Feb 26 12:40:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28872 for ; Thu, 26 Feb 2004 12:40:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwPV1-0006G4-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 12:40:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwPU9-0006Bk-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 12:39:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwPTR-000679-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 12:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwPTR-000266-KM; Thu, 26 Feb 2004 12:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwPT6-000224-1f for rtg-dir@optimus.ietf.org; Thu, 26 Feb 2004 12:38:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28757 for ; Thu, 26 Feb 2004 12:38:36 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwPT4-00065J-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 12:38:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwPSD-0005yy-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 12:37:46 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1AwPRN-0005or-00; Thu, 26 Feb 2004 12:36:54 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1QHai701253; Thu, 26 Feb 2004 19:36:44 +0200 (EET) X-Scanned: Thu, 26 Feb 2004 19:36:42 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1QHag6B010003; Thu, 26 Feb 2004 19:36:42 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00neFRuA; Thu, 26 Feb 2004 19:36:41 EET 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 i1QHaYO04946; Thu, 26 Feb 2004 19:36:35 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 26 Feb 2004 09:36:18 -0800 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: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Date: Thu, 26 Feb 2004 11:36:18 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F799BB@daebe009.americas.nokia.com> Thread-Topic: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Thread-Index: AcP8hVNWowijL9/PTOaMjv5zJLQ77gACGoFg To: Cc: , , X-OriginalArrivalTime: 26 Feb 2004 17:36:18.0739 (UTC) FILETIME=[0AC01830:01C3FC8F] Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Kireeti, > We mulled a bit over how many times the allocations should be renewed. > The idea is that early allocation should NOT be requested as sson as > an ID is written :-) One renewal may be a bit too aggressive, but > it gives two years. Perhaps two renewals is okay, but no more (imho). I understand the concern and I agree that 2 years should be long enough. I am interested in knowing about what happens when the early allocations expire and can't be renewed. Let say the ID is almost reaching the RFC state and because the early allocations are expired, they are assigned to some other protocol by IANA. =20 This will create the same problems that the draft is trying to solve. IMHO, the draft should explore that situation and describe the process for that case. > Automatic expiry was actually in the first version, but not everyone > felt comfortable with that. We can (and should) review this, and > perhaps make clearer what expiry means. That will certainly help. > Note that NOT adding to either IANA's or the IESG's workload is an > explicit goal. Whatever we can do to avoid adding to WG chairs' > workload is a 'nice-to-have' :-) I agree that the workload shouldn't be added to IANA's or IESG's. The concern I have is that the entries might remain there forever if a chair forgets to notify IANA about deprecating/deleting them. Regards Mukesh From rtg-dir-admin@ietf.org Thu Feb 26 13:46:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02056 for ; Thu, 26 Feb 2004 13:46:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwQXC-0005x0-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 13:46:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwQW9-0005jq-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 13:45:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwQV4-0005Tn-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 13:44:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQUv-0008Ok-AV; Thu, 26 Feb 2004 13:44:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQTx-0008Gt-0r for rtg-dir@optimus.ietf.org; Thu, 26 Feb 2004 13:43:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01587 for ; Thu, 26 Feb 2004 13:43:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwQTu-0005ID-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 13:43:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwQSj-000540-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 13:42:22 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1AwQRd-0004pN-00; Thu, 26 Feb 2004 13:41:13 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 26 Feb 2004 10:43:41 -0800 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 i1QIef0K010848; Thu, 26 Feb 2004 13:40:42 -0500 (EST) Message-Id: <200402261840.i1QIef0K010848@rtp-core-2.cisco.com> To: Alex Zinin cc: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-reply-to: Your message of Thu, 12 Feb 2004 22:38:02 -0800. <8930684742.20040212223802@psg.com> Reply-To: erosen@cisco.com 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 Date: Thu, 26 Feb 2004 13:40:41 -0500 From: Eric Rosen Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 The problem that this doc is trying to solve appears to be the following: - some codepoint spaces are small, not extensible, or otherwise not amenable to a FCFS style of allocation - early implementations that need codepoint values from these spaces can't rely on IANA, and have to make their own choices - if these implementations become widespread, the codepoint values they use become the defacto standard. I just don't see how the complicated rigamarole that the document proposes will solve this problem. If a particular use of a codepoint value becomes widespread, it will still become the defacto standard, no matter how what the IETF says about expirations, refreshes, renewals, etc., etc. If the implementation does not catch on, perhaps the proposed procedures would at least allow the codepoint value to be reclaimed. Well, probably not. The WG will have disbanded, or there will be a new WG chairman who doesn't know anything about the codepoint and has no idea that he is supposed to talk to IANA about it. The procedures do provide a way to get an "official" codepoint allocated from a "standards action" space without having to wait for a "standards action", but it doesn't really seem to get to the root of the problem, which is that the codepoint space is too small. As for two years being long enough, that's a joke. Two years after widespread deployment is usually about the time that the IESG is insisting on the need for the Requirements and Framework documents. From rtg-dir-admin@ietf.org Thu Feb 26 14:00:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02913 for ; Thu, 26 Feb 2004 14:00:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwQkU-0007I7-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 14:00:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwQjc-0007Cj-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 13:59:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwQip-00077h-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 13:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQir-00014T-6P; Thu, 26 Feb 2004 13:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQiY-000100-MF for rtg-dir@optimus.ietf.org; Thu, 26 Feb 2004 13:58:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02745 for ; Thu, 26 Feb 2004 13:58:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwQiW-00074x-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 13:58:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwQhX-0006xF-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 13:57:40 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AwQga-0006pf-00; Thu, 26 Feb 2004 13:56:40 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwQga-000IN7-C8; Thu, 26 Feb 2004 18:56:40 +0000 Date: Thu, 26 Feb 2004 09:48:31 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <7716212552.20040226094831@psg.com> To: Kireeti Kompella CC: Mukesh.Gupta@nokia.com, routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <20040226081555.S11637@kummer.juniper.net> References: <8D260779A766FB4A9C1739A476F84FA401F799BA@daebe009.americas.nokia.com> <20040226081555.S11637@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Kireeti, Mukesh- >> I finally got a chance to read the draft. The idea is good. I just >> have a couple of questions/concerns about the expiry of the early >> allocations.. >> >> - Do you think that "at most one renewal" would work in practice ? >> There might be instances where there is a genuine need to keep >> the early allocations for more than a year (Consider VRRPv3). >> How do we deal with that situation ? If it is not possible to >> renew the allocations more than once, do we need to ask for >> early allocations with new numbers (which ofcourse will make >> the situation worse) or we should just ask/let IANA to delete >> and reassign those numbers (which would create problems as well). > We mulled a bit over how many times the allocations should be renewed. > The idea is that early allocation should NOT be requested as sson as > an ID is written :-) One renewal may be a bit too aggressive, but > it gives two years. Perhaps two renewals is okay, but no more (imho). Maybe we could say that further renewals require IESG approval, so it is possible, but painful enough to make it less attractive than finishing the spec and advancing it to STD tracks. >> - The draft seems to put the responsibility of changing the status >> of the early allocations on the WG chairs ? I know that our chairs >> are very very responsible but I think, it will be a good idea to >> have an alternate mechanism in place such that the early allocations >> are marked deprecated/deleted automatically after a timeout. > Automatic expiry was actually in the first version, but not everyone > felt comfortable with that. We can (and should) review this, and > perhaps make clearer what expiry means. > Note that NOT adding to either IANA's or the IESG's workload is an > explicit goal. Whatever we can do to avoid adding to WG chairs' > workload is a 'nice-to-have' :-) Exactly. Unfortunately, automatic means a periodic human check for IANA--they don't have the infrastructure to automatically expire allocations. This may change in future, but at this point asking IANA to do so essentially means nobody will. Alex From rtg-dir-admin@ietf.org Thu Feb 26 14:00:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02923 for ; Thu, 26 Feb 2004 14:00:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwQkU-0007ID-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 14:00:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwQjd-0007Cr-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 13:59:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwQiq-00077o-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 13:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQis-00015c-8W; Thu, 26 Feb 2004 13:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwQia-00010g-Pd for rtg-dir@optimus.ietf.org; Thu, 26 Feb 2004 13:58:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02756 for ; Thu, 26 Feb 2004 13:58:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwQiY-00075C-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 13:58:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwQha-0006xg-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 13:57:43 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AwQgb-0006pv-00; Thu, 26 Feb 2004 13:56:42 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwQgc-000IN7-1U; Thu, 26 Feb 2004 18:56:42 +0000 Date: Thu, 26 Feb 2004 09:57:18 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <10716739600.20040226095718@psg.com> To: routing-discussion@ietf.org CC: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Fwd: WG Action: Routing Area Working Group (rtgwg) In-Reply-To: <200402261705.MAA24892@ietf.org> References: <200402261705.MAA24892@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit FYI below. I haven't yet received a confirmation from the secretariat that the list has been set up. I'll send an update when I have it. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: The IESG To: Cc: Bill Fenner , Alex Zinin Date: Thursday, February 26, 2004, 9:05:29 AM Subject: WG Action: Routing Area Working Group (rtgwg) ===8<==============Original message text=============== A new IETF working group has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. Routing Area Working Group (rtgwg) ---------------------------------- Current Status: Active Working Group Chair(s): Bill Fenner Alex Zinin Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Mailing Lists: General Discussion: rtgwg@ietf.org To Subscribe: rtgwg-request@ietf.org In Body: subscribe email_address Archive: ftp://ftp.ietf.org/ietf-mail-archive/rtgwg/ Description of Working Group: The Routing area receives occasional proposals for the development and publication of RFCs dealing with routing topics, but for which the required work does not rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and a single BOF would not provide the time to ensure a mature proposal. The rtgwg will serve as the forum for developing these types of proposals. The rtgwg mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion. The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose. Goals and Milestones: Mar 2004 Submit draft on calculation of IGP routes over TE tunnels to IESG for publication as Informational RFC ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Thu Feb 26 14:40:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04786 for ; Thu, 26 Feb 2004 14:40:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwRNG-0003uJ-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 14:40:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRMN-0003pR-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 14:39:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwRLX-0003kC-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 14:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRLZ-0004VJ-62; Thu, 26 Feb 2004 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRLP-0004UJ-OL for rtg-dir@optimus.ietf.org; Thu, 26 Feb 2004 14:38:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04725 for ; Thu, 26 Feb 2004 14:38:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwRLN-0003iw-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 14:38:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRKS-0003dd-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 14:37:53 -0500 Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx with esmtp (Exim 4.12) id 1AwRJr-0003Ss-00; Thu, 26 Feb 2004 14:37:15 -0500 Received: from lb-laptop.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 60E0FAE88; Thu, 26 Feb 2004 14:36:36 -0500 (EST) Message-Id: <6.0.3.0.2.20040226143327.03467ea8@mail.labn.net> X-Sender: lberger@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 26 Feb 2004 14:36:35 -0500 To: Kireeti Kompella From: Lou Berger Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Cc: Mukesh.Gupta@nokia.com, zinin@psg.com, routing-discussion@ietf.org, rtg-dir@ietf.org In-Reply-To: <20040226081555.S11637@kummer.juniper.net> References: <8D260779A766FB4A9C1739A476F84FA401F799BA@daebe009.americas.nokia.com> <20040226081555.S11637@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 How about linking assignment expiration to expiration of the draft, 3 months after? If the draft makes it to RFC, no issue, if the draft takes a long time through the editors queue (which can take ~1.5 years!), no issue, if the draft keeps changing, no issue. If the draft dies, so does the assignment. Lou At 11:24 AM 2/26/2004, Kireeti Kompella wrote: >On Wed, 25 Feb 2004 Mukesh.Gupta@nokia.com wrote: > > > I finally got a chance to read the draft. The idea is good. I just > > have a couple of questions/concerns about the expiry of the early > > allocations.. > > > > - Do you think that "at most one renewal" would work in practice ? > > There might be instances where there is a genuine need to keep > > the early allocations for more than a year (Consider VRRPv3). > > How do we deal with that situation ? If it is not possible to > > renew the allocations more than once, do we need to ask for > > early allocations with new numbers (which ofcourse will make > > the situation worse) or we should just ask/let IANA to delete > > and reassign those numbers (which would create problems as well). > >We mulled a bit over how many times the allocations should be renewed. >The idea is that early allocation should NOT be requested as sson as >an ID is written :-) One renewal may be a bit too aggressive, but >it gives two years. Perhaps two renewals is okay, but no more (imho). > > > - The draft seems to put the responsibility of changing the status > > of the early allocations on the WG chairs ? I know that our chairs > > are very very responsible but I think, it will be a good idea to > > have an alternate mechanism in place such that the early allocations > > are marked deprecated/deleted automatically after a timeout. > >Automatic expiry was actually in the first version, but not everyone >felt comfortable with that. We can (and should) review this, and >perhaps make clearer what expiry means. > >Note that NOT adding to either IANA's or the IESG's workload is an >explicit goal. Whatever we can do to avoid adding to WG chairs' >workload is a 'nice-to-have' :-) > >Kireeti. >------- > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-admin@ietf.org Thu Feb 26 16:25:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10088 for ; Thu, 26 Feb 2004 16:25:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwT16-0007Zx-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 16:26:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwT0A-0007Oz-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 16:25:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwSzJ-0007HW-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 16:24:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwSzH-0004XB-G4; Thu, 26 Feb 2004 16:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwS14-0000vu-6u for rtg-dir@optimus.ietf.org; Thu, 26 Feb 2004 15:21:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08269 for ; Thu, 26 Feb 2004 15:21:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwS12-00018n-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 15:21:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwS03-0000yg-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 15:20:52 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx with esmtp (Exim 4.12) id 1AwRzC-0000ot-00; Thu, 26 Feb 2004 15:19:58 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id E3D03E0698; Thu, 26 Feb 2004 15:19:54 -0500 (EST) Date: Thu, 26 Feb 2004 15:19:54 -0500 From: John Leslie To: Eric Rosen Cc: Alex Zinin , routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Message-ID: <20040226201954.GA66960@verdi> References: <8930684742.20040212223802@psg.com> <200402261840.i1QIef0K010848@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402261840.i1QIef0K010848@rtp-core-2.cisco.com> User-Agent: Mutt/1.4.1i Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Eric Rosen wrote: > > The problem that this doc is trying to solve appears to be the following: > - some codepoint spaces are small, not extensible, or otherwise not amenable > to a FCFS style of allocation > - early implementations that need codepoint values from these spaces can't > rely on IANA, and have to make their own choices > - if these implementations become widespread, the codepoint values they use > become the defacto standard. At first blush, Eric seems to have stated the problem correctly (albeit not politically correctly ;) He does, of course, gloss over the IESG action to declare a particular namespace appropriate for this early-allocation process. I assume that no codespace in imminent danger of exhaustion would be so designated... We need to clarify whether codespaces in danger of exhaustion MAY be so designated -- and possibly suggest conditions under which the designation would be withdrawn. > I just don't see how the complicated rigamarole that the document proposes > will solve this problem. If a particular use of a codepoint value becomes > widespread, it will still become the defacto standard, no matter how what > the IETF says about expirations, refreshes, renewals, etc., etc. As I think about this, we perhaps need the equivalent of the RFC1918 free-for-all zones: particular codes which may be used for interoperability testing, but are subject to other incompatible uses. > If the implementation does not catch on, perhaps the proposed procedures > would at least allow the codepoint value to be reclaimed. Well, probably > not. The WG will have disbanded, or there will be a new WG chairman who > doesn't know anything about the codepoint and has no idea that he is > supposed to talk to IANA about it. What does "reclaimed" mean? It's easy enough to remove it from IANA databases; but that doesn't stop its use by deployed equipment. Thus, I'd suggest we redefine "reclaimed" to mean RFC1918-style free-for-all. -- John Leslie From rtg-dir-admin@ietf.org Thu Feb 26 17:45:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14294 for ; Thu, 26 Feb 2004 17:45:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwUGM-0000uM-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 17:45:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwUFR-0000p2-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 17:44:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwUEZ-0000jl-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 17:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUEa-00040Q-Tt; Thu, 26 Feb 2004 17:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwUEW-00040F-5d for rtg-dir@optimus.ietf.org; Thu, 26 Feb 2004 17:43:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14254 for ; Thu, 26 Feb 2004 17:43:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwUET-0000it-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 17:43:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwUDb-0000dl-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 17:42:59 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1AwUCq-0000S8-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 17:42:12 -0500 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 i1QMfgl74378; Thu, 26 Feb 2004 14:41:42 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp041.static.jnpr.net [172.24.253.41]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1QMfao01170; Thu, 26 Feb 2004 14:41:36 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040226172928.01389130@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 26 Feb 2004 17:30:48 -0500 To: Alex Zinin , rtg-dir@ietf.org From: Ross Callon Subject: Re: RTG-DIR Dinner in Seoul In-Reply-To: <1639659800.20040224223305@psg.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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_MUA_EUDORA autolearn=no version=2.60 At 10:33 PM 2/24/2004 -0800, Alex Zinin wrote: >So far I have Danny, Ross, and Sue. > >How about we meet Sunday 5pm near the hotel registration? This is a good plan. I will plan on being there. I like the idea of meeting at 5pm (ie, relatively early). Ross From rtg-dir-admin@ietf.org Thu Feb 26 20:56:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22177 for ; Thu, 26 Feb 2004 20:56:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwXFL-0003WS-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 20:56:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwXEU-0003Qd-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 20:56:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwXDQ-0003KR-00 for rtg-dir-archive@ietf.org; Thu, 26 Feb 2004 20:55:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwXDR-0005Cw-MT; Thu, 26 Feb 2004 20:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwXCV-0005Au-N9 for rtg-dir@optimus.ietf.org; Thu, 26 Feb 2004 20:54:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22068 for ; Thu, 26 Feb 2004 20:54:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwXCT-0003DI-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 20:54:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwXBW-00036o-00 for rtg-dir@ietf.org; Thu, 26 Feb 2004 20:53:03 -0500 Received: from hs22.order-vault.net ([65.18.133.138]) by ietf-mx with esmtp (Exim 4.12) id 1AwXAo-0002vV-00; Thu, 26 Feb 2004 20:52:18 -0500 Received: from lb-laptop.labn.net (labn.net [65.18.134.4]) (authenticated (0 bits)) by hs22.order-vault.net (8.11.6/8.11.6) with ESMTP id i1R1pYd14203; Thu, 26 Feb 2004 20:51:34 -0500 Message-Id: <6.0.3.0.2.20040226205121.0620ebf8@mo-ex1> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 26 Feb 2004 20:51:35 -0500 To: Kireeti Kompella From: Lou Berger Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Cc: Mukesh.Gupta@nokia.com, zinin@psg.com, routing-discussion@ietf.org, rtg-dir@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 [resend] How about linking assignment expiration to expiration of the draft, 3 months after? If the draft makes it to RFC, no issue, if the draft takes a long time through the editors queue (which can take ~1.5 years!), no issue, if the draft keeps changing, no issue. If the draft dies, so does the assignment. Lou At 11:24 AM 2/26/2004, Kireeti Kompella wrote: >On Wed, 25 Feb 2004 Mukesh.Gupta@nokia.com wrote: > > > I finally got a chance to read the draft. The idea is good. I just > > have a couple of questions/concerns about the expiry of the early > > allocations.. > > > > - Do you think that "at most one renewal" would work in practice ? > > There might be instances where there is a genuine need to keep > > the early allocations for more than a year (Consider VRRPv3). > > How do we deal with that situation ? If it is not possible to > > renew the allocations more than once, do we need to ask for > > early allocations with new numbers (which ofcourse will make > > the situation worse) or we should just ask/let IANA to delete > > and reassign those numbers (which would create problems as well). > >We mulled a bit over how many times the allocations should be renewed. >The idea is that early allocation should NOT be requested as sson as >an ID is written :-) One renewal may be a bit too aggressive, but >it gives two years. Perhaps two renewals is okay, but no more (imho). > > > - The draft seems to put the responsibility of changing the status > > of the early allocations on the WG chairs ? I know that our chairs > > are very very responsible but I think, it will be a good idea to > > have an alternate mechanism in place such that the early allocations > > are marked deprecated/deleted automatically after a timeout. > >Automatic expiry was actually in the first version, but not everyone >felt comfortable with that. We can (and should) review this, and >perhaps make clearer what expiry means. > >Note that NOT adding to either IANA's or the IESG's workload is an >explicit goal. Whatever we can do to avoid adding to WG chairs' >workload is a 'nice-to-have' :-) > >Kireeti. >------- > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-admin@ietf.org Fri Feb 27 05:42:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25197 for ; Fri, 27 Feb 2004 05:42:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwfSI-0002jV-00 for rtg-dir-archive@ietf.org; Fri, 27 Feb 2004 05:42:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwfR1-0002dv-00 for rtg-dir-archive@ietf.org; Fri, 27 Feb 2004 05:41:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwfQS-0002Wf-00 for rtg-dir-archive@ietf.org; Fri, 27 Feb 2004 05:41:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwfQU-0006lj-LY; Fri, 27 Feb 2004 05:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwfQ2-0006kr-Md for rtg-dir@optimus.ietf.org; Fri, 27 Feb 2004 05:40:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25044 for ; Fri, 27 Feb 2004 05:40:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwfPz-0002V8-00 for rtg-dir@ietf.org; Fri, 27 Feb 2004 05:40:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwfOz-0002NX-00 for rtg-dir@ietf.org; Fri, 27 Feb 2004 05:39:29 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AwfON-0002Gy-00 for rtg-dir@ietf.org; Fri, 27 Feb 2004 05:38:51 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i1RAcpxM021010; Fri, 27 Feb 2004 11:38:51 +0100 Received: from alcatel.be ([138.203.118.5]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004022711384937:4959 ; Fri, 27 Feb 2004 11:38:49 +0100 Message-ID: <403F1EA9.6030007@alcatel.be> Date: Fri, 27 Feb 2004 11:40:41 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ross Callon Cc: Alex Zinin , rtg-dir@ietf.org, Dimitri Papadimitriou Subject: Re: RTG-DIR Dinner in Seoul References: <4.3.2.20040226172928.01389130@zircon.juniper.net> In-Reply-To: <4.3.2.20040226172928.01389130@zircon.juniper.net> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/27/2004 11:38:49, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/27/2004 11:38:50, Serialize complete at 02/27/2004 11:38:50 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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: 7bit hi ross, alex, all, i'd like to be part of the dinner this would be a good way to introduce myself. thanks, - dimitri. Ross Callon wrote: > At 10:33 PM 2/24/2004 -0800, Alex Zinin wrote: > >>So far I have Danny, Ross, and Sue. >> >>How about we meet Sunday 5pm near the hotel registration? > > > This is a good plan. I will plan on being there. > I like the idea of meeting at 5pm (ie, relatively early). > > Ross > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From rtg-dir-admin@ietf.org Fri Feb 27 08:34:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00419 for ; Fri, 27 Feb 2004 08:34:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awi8F-0004Ye-00 for rtg-dir-archive@ietf.org; Fri, 27 Feb 2004 08:34:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awi7I-0004TX-00 for rtg-dir-archive@ietf.org; Fri, 27 Feb 2004 08:33:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Awi6u-0004OJ-00 for rtg-dir-archive@ietf.org; Fri, 27 Feb 2004 08:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awi6u-00026O-C1; Fri, 27 Feb 2004 08:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awi6D-00024p-F1 for rtg-dir@optimus.ietf.org; Fri, 27 Feb 2004 08:32:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00360 for ; Fri, 27 Feb 2004 08:32:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awi6C-0004MT-00 for rtg-dir@ietf.org; Fri, 27 Feb 2004 08:32:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awi5D-0004Gc-00 for rtg-dir@ietf.org; Fri, 27 Feb 2004 08:31:16 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Awi4G-0004BM-00 for rtg-dir@ietf.org; Fri, 27 Feb 2004 08:30:16 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Awi4F-000OFf-06; Fri, 27 Feb 2004 13:30:15 +0000 Date: Fri, 27 Feb 2004 22:29:52 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6523711164.20040227222952@psg.com> To: Dimitri.Papadimitriou@alcatel.be CC: Ross Callon , rtg-dir@ietf.org, Dimitri Papadimitriou Subject: Re: RTG-DIR Dinner in Seoul In-Reply-To: <403F1EA9.6030007@alcatel.be> References: <4.3.2.20040226172928.01389130@zircon.juniper.net> <403F1EA9.6030007@alcatel.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dimitri, Of course! My bad for not inviting you and Loa to it. Please do join us! -- Alex http://www.psg.com/~zinin/ Friday, February 27, 2004, 7:40:41 PM, Dimitri.Papadimitriou@alcatel.be wrote: > hi ross, alex, all, > i'd like to be part of the dinner this would be > a good way to introduce myself. > thanks, > - dimitri. > Ross Callon wrote: >> At 10:33 PM 2/24/2004 -0800, Alex Zinin wrote: >> >>>So far I have Danny, Ross, and Sue. >>> >>>How about we meet Sunday 5pm near the hotel registration? >> >> >> This is a good plan. I will plan on being there. >> I like the idea of meeting at 5pm (ie, relatively early). >> >> Ross >> >> From rtg-dir-admin@ietf.org Fri Feb 27 08:44:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01354 for ; Fri, 27 Feb 2004 08:44:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwiHi-00061G-00 for rtg-dir-archive@ietf.org; Fri, 27 Feb 2004 08:44:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwiGf-0005nn-00 for rtg-dir-archive@ietf.org; Fri, 27 Feb 2004 08:43:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwiFh-0005a0-00 for rtg-dir-archive@ietf.org; Fri, 27 Feb 2004 08:42:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwiFi-000360-9p; Fri, 27 Feb 2004 08:42:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwiFa-00033i-Im for rtg-dir@optimus.ietf.org; Fri, 27 Feb 2004 08:41:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01011 for ; Fri, 27 Feb 2004 08:41:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwiFZ-0005Yg-00 for rtg-dir@ietf.org; Fri, 27 Feb 2004 08:41:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwiEP-0005Jx-00 for rtg-dir@ietf.org; Fri, 27 Feb 2004 08:40:46 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AwiDG-00056M-00; Fri, 27 Feb 2004 08:39:34 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwiDF-000PUU-JM; Fri, 27 Feb 2004 13:39:33 +0000 Date: Fri, 27 Feb 2004 22:39:11 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <2024269687.20040227223911@psg.com> To: routing-discussion@ietf.org, rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Re: WG Action: Routing Area Working Group (rtgwg) In-Reply-To: <10716739600.20040226095718@psg.com> References: <200402261705.MAA24892@ietf.org> <10716739600.20040226095718@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit FYI, the mailing list is up and running. General Discussion: rtgwg@ietf.org To Subscribe: rtgwg-request@ietf.org In Body: subscribe email_address -- Alex http://www.psg.com/~zinin/ Friday, February 27, 2004, 2:57:18 AM, Alex Zinin wrote: > FYI below. > I haven't yet received a confirmation from the secretariat that the > list has been set up. I'll send an update when I have it. From rtg-dir-admin@ietf.org Sat Feb 28 02:57:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06502 for ; Sat, 28 Feb 2004 02:57:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwzMA-0001tc-00 for rtg-dir-archive@ietf.org; Sat, 28 Feb 2004 02:57:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwzLF-0001nQ-00 for rtg-dir-archive@ietf.org; Sat, 28 Feb 2004 02:56:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwzKM-0001gq-00 for rtg-dir-archive@ietf.org; Sat, 28 Feb 2004 02:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwzKO-00045f-EP; Sat, 28 Feb 2004 02:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwzJY-00042I-L6 for rtg-dir@optimus.ietf.org; Sat, 28 Feb 2004 02:55:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06357 for ; Sat, 28 Feb 2004 02:55:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwzJU-0001ZC-00 for rtg-dir@ietf.org; Sat, 28 Feb 2004 02:55:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwzIZ-0001Qy-00 for rtg-dir@ietf.org; Sat, 28 Feb 2004 02:54:12 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AwzHe-0001JW-00 for rtg-dir@ietf.org; Sat, 28 Feb 2004 02:53:15 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwzHf-000KTW-Ur for rtg-dir@ietf.org; Sat, 28 Feb 2004 07:53:16 +0000 Date: Sat, 28 Feb 2004 16:52:42 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <6889880801.20040228165242@psg.com> To: rtg-dir@ietf.org Subject: Re: RTG-DIR Dinner in Seoul In-Reply-To: <6523711164.20040227222952@psg.com> References: <4.3.2.20040226172928.01389130@zircon.juniper.net> <403F1EA9.6030007@alcatel.be> <6523711164.20040227222952@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Guys, those coming to dinner--I did some scouting today. There is a quite lovely district right across the street from the hotel. There are many rather small local places, but there is also (do NOT freak out!) Outback, if fact two of them, about 50 meters from each other ;), and (pls sit down) Tony Roma's. For some reason I am not so much excited about Korean food, and would vouch for Outback. Opinions? -- Alex From rtg-dir-admin@ietf.org Sat Feb 28 05:11:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10194 for ; Sat, 28 Feb 2004 05:11:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1Rt-00008U-00 for rtg-dir-archive@ietf.org; Sat, 28 Feb 2004 05:11:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1Qx-00002A-00 for rtg-dir-archive@ietf.org; Sat, 28 Feb 2004 05:11:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1Q0-0007jJ-00 for rtg-dir-archive@ietf.org; Sat, 28 Feb 2004 05:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1Q2-0004U3-4E; Sat, 28 Feb 2004 05:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax1P5-0004R4-5O for rtg-dir@optimus.ietf.org; Sat, 28 Feb 2004 05:09:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10051 for ; Sat, 28 Feb 2004 05:08:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1P1-0007cf-00 for rtg-dir@ietf.org; Sat, 28 Feb 2004 05:08:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax1OC-0007WW-00 for rtg-dir@ietf.org; Sat, 28 Feb 2004 05:08:08 -0500 Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx with esmtp (Exim 4.12) id 1Ax1NV-0007OA-00 for rtg-dir@ietf.org; Sat, 28 Feb 2004 05:07:25 -0500 Received: from NtscpUsrLoa@netscape.net by imo-d02.mx.aol.com (mail_out_v36_r4.14.) id p.2a.c2e4bed (16237); Sat, 28 Feb 2004 05:06:52 -0500 (EST) Received: from netscape.net (tla-loa.dhcp.ietf59.or.kr [218.37.227.218]) by air-in03.mx.aol.com (v98.11) with ESMTP id MAILININ31-3f6d40406839300; Sat, 28 Feb 2004 05:06:51 -0500 Message-ID: <4040682C.9080804@netscape.net> Date: Sat, 28 Feb 2004 11:06:36 +0100 From: Loa Andersson Reply-To: loa@pi.se 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: Alex Zinin CC: rtg-dir@ietf.org Subject: Re: RTG-DIR Dinner in Seoul References: <4.3.2.20040226172928.01389130@zircon.juniper.net> <403F1EA9.6030007@alcatel.be> <6523711164.20040227222952@psg.com> <6889880801.20040228165242@psg.com> In-Reply-To: <6889880801.20040228165242@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 218.37.227.218 X-Mailer: Unknown (No Version) Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Alex, I'm in. /Loa Alex Zinin wrote: > Guys, those coming to dinner--I did some scouting today. There is a quite lovely > district right across the street from the hotel. There are many rather small > local places, but there is also (do NOT freak out!) Outback, if fact two of > them, about 50 meters from each other ;), and (pls sit down) Tony Roma's. > > For some reason I am not so much excited about Korean food, and would vouch > for Outback. Opinions? > -- Loa Andersson mobile +46 739 81 21 64 From rtg-dir-admin@ietf.org Sat Feb 28 11:21:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23628 for ; Sat, 28 Feb 2004 11:21:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax7DH-0001b6-00 for rtg-dir-archive@ietf.org; Sat, 28 Feb 2004 11:21:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax7CK-0001Vz-00 for rtg-dir-archive@ietf.org; Sat, 28 Feb 2004 11:20:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax7C6-0001Qh-00 for rtg-dir-archive@ietf.org; Sat, 28 Feb 2004 11:20:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax7C6-0003c7-AH; Sat, 28 Feb 2004 11:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax7BI-0003aF-0F for rtg-dir@optimus.ietf.org; Sat, 28 Feb 2004 11:19:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23591 for ; Sat, 28 Feb 2004 11:19:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax7BH-0001PU-00 for rtg-dir@ietf.org; Sat, 28 Feb 2004 11:19:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax7AI-0001K5-00 for rtg-dir@ietf.org; Sat, 28 Feb 2004 11:18:11 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Ax79r-0001Ex-00 for rtg-dir@ietf.org; Sat, 28 Feb 2004 11:17:43 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id BE5CE2D48EA for ; Sat, 28 Feb 2004 11:17:11 -0500 (EST) 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 89136-02-3 for ; Sat, 28 Feb 2004 11:17:11 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 1CF0F2D484D for ; Sat, 28 Feb 2004 11:17:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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: RTG-DIR Dinner in Seoul Date: Sat, 28 Feb 2004 11:17:09 -0500 Message-ID: Thread-Topic: RTG-DIR Dinner in Seoul Thread-Index: AcP90FeBaUoQ70pIQwWl/UUpO/YwDQAOjszg From: "Susan Hares" To: "Alex Zinin" , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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: quoted-printable I vote Korean food, but will go anywhere. Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Saturday, February 28, 2004 2:53 AM To: rtg-dir@ietf.org Subject: Re: RTG-DIR Dinner in Seoul Guys, those coming to dinner--I did some scouting today. There is a = quite lovely district right across the street from the hotel. There are many rather = small local places, but there is also (do NOT freak out!) Outback, if fact two = of them, about 50 meters from each other ;), and (pls sit down) Tony = Roma's. For some reason I am not so much excited about Korean food, and would = vouch for Outback. Opinions? --=20 Alex From rtg-dir-admin@ietf.org Sat Feb 28 20:40:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14964 for ; Sat, 28 Feb 2004 20:40:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFwo-0005qs-00 for rtg-dir-archive@ietf.org; Sat, 28 Feb 2004 20:40:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxFvY-0005iR-02 for rtg-dir-archive@ietf.org; Sat, 28 Feb 2004 20:39:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxFn8-0008KF-5D for rtg-dir-archive@ietf.org; Sat, 28 Feb 2004 20:30:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFh0-0005pM-4w; Sat, 28 Feb 2004 20:24:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxFZM-0005ET-7m for rtg-dir@optimus.ietf.org; Sat, 28 Feb 2004 20:16:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14064 for ; Sat, 28 Feb 2004 20:16:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxFZK-0003Lm-00 for rtg-dir@ietf.org; Sat, 28 Feb 2004 20:16:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxFYR-0003Fo-00 for rtg-dir@ietf.org; Sat, 28 Feb 2004 20:15:40 -0500 Received: from 56.red-80-33-211.pooles.rima-tde.net ([80.33.211.56]) by ietf-mx with smtp (Exim 4.12) id 1AxFY1-00038I-00 for rtg-dir@ietf.org; Sat, 28 Feb 2004 20:15:22 -0500 Received: from [208.53.71.132] by 56.Red-80-33-211.pooles.rima-tde.net id b2yc8fjvb4oB; Sun, 29 Feb 2004 21:06:14 -0200 Message-ID: <3r3-2-2$4vk8y5--$1-$$k@4x7wj.jb.wtty> From: "Geneva Burns" Reply-To: "Geneva Burns" To: Subject: weight |oss 1s Date: Sun, 29 Feb 04 21:06:14 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="BDA.__BC_D_27" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=16.3 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_40_50, HTML_IMAGE_ONLY_04,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,USERPASS autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.1 USERPASS URI: URL contains username and (optional) password * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , --BDA.__BC_D_27 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Best quality weight |oss product - |ose your weight fast and guaranteed !

http:= //www.procitravin.net/index27.html

Procitravin is designed to help you lose weight
and feel more energetic. Our patented formula
including Advantra Z bitter orange releases
energy from fats and carbohydrates will make
the pounds melt away!

Remove your add= ress from our database.

Thanks,
Doma Greg



mj mogtrw g bfgt cjdayq j nlycjpvvy rxdeo --BDA.__BC_D_27-- From rtg-dir-admin@ietf.org Sun Feb 29 00:18:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22324 for ; Sun, 29 Feb 2004 00:18:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJL6-0003JH-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 00:18:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJKG-000389-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 00:17:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxJJ2-0002tU-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 00:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJJ3-0003gK-SN; Sun, 29 Feb 2004 00:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJIh-0003e3-P9 for rtg-dir@optimus.ietf.org; Sun, 29 Feb 2004 00:15:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21960 for ; Sun, 29 Feb 2004 00:15:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJIf-0002p6-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 00:15:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJHg-0002kG-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 00:14:37 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxJHT-0002fv-00; Sun, 29 Feb 2004 00:14:23 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxJHU-000CMz-K5; Sun, 29 Feb 2004 05:14:24 +0000 Date: Sun, 29 Feb 2004 14:14:01 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <32969213.20040229141401@psg.com> To: Eric Rosen CC: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <200402261840.i1QIef0K010848@rtp-core-2.cisco.com> References: <200402261840.i1QIef0K010848@rtp-core-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Eric, > The problem that this doc is trying to solve appears to be the following: Not exactly. Corrections below: > - some codepoint spaces are small, not extensible, or otherwise not amenable > to a FCFS style of allocation Change this to: - for whatever reason a decision has been made to make the allocation policy for a codepoint space the Standards Action, whether this space is large or small > - early implementations that need codepoint values from these spaces can't > rely on IANA, and have to make their own choices Change this to: - early implementations required by the process (or because it's a hot technology) can't get the codepoint from IANA because a Standards Action is required, yet implementations are needed to approve the standard, so they simply grab the next number available hoping it'll do. > - if these implementations become widespread, the codepoint values they use > become the defacto standard. Change this to: - if these implementations get deployed in the same network at some point-- they collide > I just don't see how the complicated rigamarole that the document proposes > will solve this problem. If a particular use of a codepoint value becomes > widespread, it will still become the defacto standard, no matter how what > the IETF says about expirations, refreshes, renewals, etc., etc. > If the implementation does not catch on, perhaps the proposed procedures > would at least allow the codepoint value to be reclaimed. Well, probably > not. The WG will have disbanded, or there will be a new WG chairman who > doesn't know anything about the codepoint and has no idea that he is > supposed to talk to IANA about it. > The procedures do provide a way to get an "official" codepoint allocated > from a "standards action" space without having to wait for a "standards > action", but it doesn't really seem to get to the root of the problem, which > is that the codepoint space is too small. I think you're missing the problem. It is not the size of the space. It is the circular dependency between IANA allocation and STD action. Alex From rtg-dir-admin@ietf.org Sun Feb 29 00:21:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22557 for ; Sun, 29 Feb 2004 00:21:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJOW-0003lU-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 00:21:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJNi-0003fc-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 00:20:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxJMw-0003ZL-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 00:20:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJMy-00043S-4O; Sun, 29 Feb 2004 00:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJMb-00041p-1P for rtg-dir@optimus.ietf.org; Sun, 29 Feb 2004 00:19:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22416 for ; Sun, 29 Feb 2004 00:19:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJMY-0003W0-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 00:19:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJLZ-0003Ov-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 00:18:37 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxJKd-0003Ey-00; Sun, 29 Feb 2004 00:17:39 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxJKd-000Chl-CX; Sun, 29 Feb 2004 05:17:39 +0000 Date: Sun, 29 Feb 2004 14:17:14 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <421162421.20040229141714@psg.com> To: John Leslie CC: Eric Rosen , routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <20040226201954.GA66960@verdi> References: <8930684742.20040212223802@psg.com> <200402261840.i1QIef0K010848@rtp-core-2.cisco.com> <20040226201954.GA66960@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit John, > As I think about this, we perhaps need the equivalent of the RFC1918 > free-for-all zones: particular codes which may be used for interoperability > testing, but are subject to other incompatible uses. Experimental allocation policy should cover this. See RFC 3692. Alex From rtg-dir-admin@ietf.org Sun Feb 29 00:25:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22757 for ; Sun, 29 Feb 2004 00:25:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJSS-0004Bz-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 00:25:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJRU-000462-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 00:24:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxJQl-00040O-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 00:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJQn-0004Rx-1D; Sun, 29 Feb 2004 00:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxJQT-0004QM-Le for rtg-dir@optimus.ietf.org; Sun, 29 Feb 2004 00:23:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22642 for ; Sun, 29 Feb 2004 00:23:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxJQR-0003yo-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 00:23:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxJPV-0003sJ-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 00:22:42 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxJOW-0003lV-00; Sun, 29 Feb 2004 00:21:40 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxJOW-000D39-EK; Sun, 29 Feb 2004 05:21:40 +0000 Date: Sun, 29 Feb 2004 14:21:16 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <391404519.20040229142116@psg.com> To: Lou Berger CC: Kireeti Kompella , Mukesh.Gupta@nokia.com, routing-discussion@ietf.org, Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <6.0.3.0.2.20040226205121.0620ebf8@mo-ex1> References: <6.0.3.0.2.20040226205121.0620ebf8@mo-ex1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Lou, This would tie expiration to the author's ability to resubmit the draft, rather than to how the doc progresses. We could instead say that once the doc is submitted to the IESG, the codepoint is "frozen". -- Alex http://www.psg.com/~zinin/ Friday, February 27, 2004, 10:51:35 AM, Lou Berger wrote: > [resend] > How about linking assignment expiration to expiration of the draft, 3 > months after? If the draft makes it to RFC, no issue, if the draft takes a > long time through the editors queue (which can take ~1.5 years!), no issue, > if the draft keeps changing, no issue. If the draft dies, so does the > assignment. > Lou > At 11:24 AM 2/26/2004, Kireeti Kompella wrote: >>On Wed, 25 Feb 2004 Mukesh.Gupta@nokia.com wrote: >> >> > I finally got a chance to read the draft. The idea is good. I just >> > have a couple of questions/concerns about the expiry of the early >> > allocations.. >> > >> > - Do you think that "at most one renewal" would work in practice ? >> > There might be instances where there is a genuine need to keep >> > the early allocations for more than a year (Consider VRRPv3). >> > How do we deal with that situation ? If it is not possible to >> > renew the allocations more than once, do we need to ask for >> > early allocations with new numbers (which ofcourse will make >> > the situation worse) or we should just ask/let IANA to delete >> > and reassign those numbers (which would create problems as well). >> >>We mulled a bit over how many times the allocations should be renewed. >>The idea is that early allocation should NOT be requested as sson as >>an ID is written :-) One renewal may be a bit too aggressive, but >>it gives two years. Perhaps two renewals is okay, but no more (imho). >> >> > - The draft seems to put the responsibility of changing the status >> > of the early allocations on the WG chairs ? I know that our chairs >> > are very very responsible but I think, it will be a good idea to >> > have an alternate mechanism in place such that the early allocations >> > are marked deprecated/deleted automatically after a timeout. >> >>Automatic expiry was actually in the first version, but not everyone >>felt comfortable with that. We can (and should) review this, and >>perhaps make clearer what expiry means. >> >>Note that NOT adding to either IANA's or the IESG's workload is an >>explicit goal. Whatever we can do to avoid adding to WG chairs' >>workload is a 'nice-to-have' :-) >> >>Kireeti. >>------- >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-admin@ietf.org Sun Feb 29 02:10:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08282 for ; Sun, 29 Feb 2004 02:10:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxL64-0006bM-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 02:10:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxL5A-0006WJ-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 02:09:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxL4P-0006Qn-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 02:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxL4R-0007qI-IK; Sun, 29 Feb 2004 02:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxL4J-0007ms-JP for rtg-dir@optimus.ietf.org; Sun, 29 Feb 2004 02:08:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06015 for ; Sun, 29 Feb 2004 02:08:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxL4F-0006Pd-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 02:08:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxL3E-0006Jo-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 02:07:49 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AxL2w-0006ET-00; Sun, 29 Feb 2004 02:07:31 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id F2E6D2D4935; Sun, 29 Feb 2004 02:07:01 -0500 (EST) 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 01346-05-7; Sun, 29 Feb 2004 02:07:01 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CD0312D482A; Sun, 29 Feb 2004 02:06:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Date: Sun, 29 Feb 2004 02:06:59 -0500 Message-ID: Thread-Topic: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Thread-Index: AcP+g7am4ahwRSX7SrCpT9w2tOLLOwABzoFg From: "Susan Hares" To: "Alex Zinin" , "John Leslie" Cc: "Eric Rosen" , , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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: quoted-printable Alex: My suggestion just gives a practical means to assign the AFI/SAFI. I think it fits within your concept.=20 Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Sunday, February 29, 2004 12:17 AM To: John Leslie Cc: Eric Rosen; routing-discussion@ietf.org; rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt John, > As I think about this, we perhaps need the equivalent of the = RFC1918 > free-for-all zones: particular codes which may be used for = interoperability > testing, but are subject to other incompatible uses. Experimental allocation policy should cover this. See RFC 3692. Alex From rtg-dir-admin@ietf.org Sun Feb 29 02:29:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10836 for ; Sun, 29 Feb 2004 02:29:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxLOb-0000nQ-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 02:29:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxLNn-0000gP-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 02:29:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxLMl-0000YD-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 02:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLMo-00069R-48; Sun, 29 Feb 2004 02:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxLMh-00067G-6g for rtg-dir@optimus.ietf.org; Sun, 29 Feb 2004 02:27:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10543 for ; Sun, 29 Feb 2004 02:27:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxLMd-0000We-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 02:27:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxLLh-0000QC-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 02:26:54 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1AxLLN-0000IG-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 02:26:33 -0500 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 i1T7Q4Bm011701; Sat, 28 Feb 2004 23:26:04 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt.juniper.net (securepptp140.static.jnpr.net [172.24.253.140]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1T7Q3o56730; Sat, 28 Feb 2004 23:26:03 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <4.3.2.20040229022406.02f92d10@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sun, 29 Feb 2004 02:26:00 -0500 To: Alex Zinin , rtg-dir@ietf.org From: Ross Callon Subject: Re: RTG-DIR Dinner in Seoul In-Reply-To: <6889880801.20040228165242@psg.com> References: <6523711164.20040227222952@psg.com> <4.3.2.20040226172928.01389130@zircon.juniper.net> <403F1EA9.6030007@alcatel.be> <6523711164.20040227222952@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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_MUA_EUDORA autolearn=no version=2.60 At 04:52 PM 2/28/2004 +0900, Alex Zinin wrote: >Guys, those coming to dinner--I did some scouting today. There is a quite lovely >district right across the street from the hotel. There are many rather small >local places, but there is also (do NOT freak out!) Outback, if fact two of >them, about 50 meters from each other ;), and (pls sit down) Tony Roma's. > >For some reason I am not so much excited about Korean food, and would vouch >for Outback. Opinions? > >-- >Alex I like rice, but I am quite confident that I will have enough Korean food during other meals this week. Thus I am fine with either Outback or Tony Roma's. Ross From rtg-dir-admin@ietf.org Sun Feb 29 03:11:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12165 for ; Sun, 29 Feb 2004 03:11:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxM33-0004Qb-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 03:11:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxM27-0004Lu-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 03:10:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxM1O-0004H4-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 03:09:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxM1R-00022Y-JG; Sun, 29 Feb 2004 03:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxM1G-00021q-0A for rtg-dir@optimus.ietf.org; Sun, 29 Feb 2004 03:09:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12134 for ; Sun, 29 Feb 2004 03:09:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxM1C-0004GM-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 03:09:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxM0I-0004BZ-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 03:08:51 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx with esmtp (Exim 4.12) id 1AxLzl-00045y-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 03:08:17 -0500 Received: from [218.37.229.130] (rambler.dhcp.ietf59.or.kr [218.37.229.130]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id CA0BE94275; Sun, 29 Feb 2004 01:08:13 -0700 (MST) In-Reply-To: <1639659800.20040224223305@psg.com> References: <1639659800.20040224223305@psg.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6A90FE2E-6A8E-11D8-BD94-000393D54EA6@arbor.net> Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org From: Danny McPherson Subject: Re: RTG-DIR Dinner in Seoul Date: Sun, 29 Feb 2004 01:08:11 -0700 To: Alex Zinin X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 FYI... We're meeting at Main HOTEL registration. -danny On Feb 24, 2004, at 11:33 PM, Alex Zinin wrote: > So far I have Danny, Ross, and Sue. > > How about we meet Sunday 5pm near the hotel registration? > > -- > Alex > http://www.psg.com/~zinin/ > > Wednesday, February 18, 2004, 5:56:17 AM, Susan Hares wrote: > >> I'll be in Seoul, and I can >> come to a dinner Sunday night. > >> sue >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: Friday, February 13, 2004 2:19 PM >> To: rtg-dir@ietf.org >> Subject: RTG-DIR Dinner in Seoul > > >> Folks- > >> Please speak up if you're going to be in Seoul and if you'll be able >> to come to the rtg-dir dinner Sunday night. > > From rtg-dir-admin@ietf.org Sun Feb 29 03:19:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12414 for ; Sun, 29 Feb 2004 03:19:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMAu-0005DI-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 03:19:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMA2-00057s-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 03:18:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxM9A-00051g-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 03:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxM9B-0002a2-EH; Sun, 29 Feb 2004 03:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxM8r-0002Ua-NV for rtg-dir@optimus.ietf.org; Sun, 29 Feb 2004 03:17:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12318 for ; Sun, 29 Feb 2004 03:17:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxM8p-0004zD-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 03:17:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxM7q-0004sb-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 03:16:39 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx with esmtp (Exim 4.12) id 1AxM6r-0004io-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 03:15:37 -0500 Received: from [218.37.229.130] (rambler.dhcp.ietf59.or.kr [218.37.229.130]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 7BEC994275; Sun, 29 Feb 2004 01:15:37 -0700 (MST) In-Reply-To: <1639659800.20040224223305@psg.com> References: <1639659800.20040224223305@psg.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6EEDEC2C-6A8F-11D8-BD94-000393D54EA6@arbor.net> Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org From: Danny McPherson Subject: Re: RTG-DIR Dinner in Seoul Date: Sun, 29 Feb 2004 01:15:28 -0700 To: Alex Zinin X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 FYI... We're meeting at Main HOTEL registration. -danny On Feb 24, 2004, at 11:33 PM, Alex Zinin wrote: > So far I have Danny, Ross, and Sue. > > How about we meet Sunday 5pm near the hotel registration? > > -- > Alex > http://www.psg.com/~zinin/ > > Wednesday, February 18, 2004, 5:56:17 AM, Susan Hares wrote: > >> I'll be in Seoul, and I can >> come to a dinner Sunday night. > >> sue >> -----Original Message----- >> From: Alex Zinin [mailto:zinin@psg.com] >> Sent: Friday, February 13, 2004 2:19 PM >> To: rtg-dir@ietf.org >> Subject: RTG-DIR Dinner in Seoul > > >> Folks- > >> Please speak up if you're going to be in Seoul and if you'll be able >> to come to the rtg-dir dinner Sunday night. > > From rtg-dir-admin@ietf.org Sun Feb 29 03:26:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12587 for ; Sun, 29 Feb 2004 03:26:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMHa-0005lZ-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 03:26:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMGe-0005hA-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 03:25:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxMFw-0005cf-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 03:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMFx-0003Fv-Ts; Sun, 29 Feb 2004 03:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxMFe-0003FP-1k for rtg-dir@optimus.ietf.org; Sun, 29 Feb 2004 03:24:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12548 for ; Sun, 29 Feb 2004 03:24:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxMFb-0005bs-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 03:24:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxMEj-0005Xg-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 03:23:45 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx with esmtp (Exim 4.12) id 1AxME2-0005TB-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 03:23:02 -0500 Received: from [218.37.229.130] (rambler.dhcp.ietf59.or.kr [218.37.229.130]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 2575194275 for ; Sun, 29 Feb 2004 01:23:03 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <6A90FE2E-6A8E-11D8-BD94-000393D54EA6@arbor.net> References: <1639659800.20040224223305@psg.com> <6A90FE2E-6A8E-11D8-BD94-000393D54EA6@arbor.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7CFC8207-6A90-11D8-BD94-000393D54EA6@arbor.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: RTG-DIR Dinner in Seoul Date: Sun, 29 Feb 2004 01:23:01 -0700 To: rtg-dir@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 We're heading to Outback (the left one -- whatever that means). If we missed you... -danny +1 303.888.7144 On Feb 29, 2004, at 1:08 AM, Danny McPherson wrote: > > FYI... We're meeting at Main HOTEL registration. From rtg-dir-admin@ietf.org Sun Feb 29 20:23:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20473 for ; Sun, 29 Feb 2004 20:23:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axc9U-0007ZS-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 20:23:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axc8R-0007UK-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 20:22:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axc87-0007Pg-00 for rtg-dir-archive@ietf.org; Sun, 29 Feb 2004 20:21:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc88-0006As-PK; Sun, 29 Feb 2004 20:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc7R-00069d-OA for rtg-dir@optimus.ietf.org; Sun, 29 Feb 2004 20:21:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20358 for ; Sun, 29 Feb 2004 20:21:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axc7P-0007OL-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 20:21:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axc6S-0007Jr-00 for rtg-dir@ietf.org; Sun, 29 Feb 2004 20:20:17 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Axc5n-0007Bc-00; Sun, 29 Feb 2004 20:19:35 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i211IwPg026250; Sun, 29 Feb 2004 17:18:58 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i211Iw3T026247; Sun, 29 Feb 2004 17:18:58 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Sun, 29 Feb 2004 17:18:58 -0800 (PST) From: Kireeti Kompella To: Alex Zinin cc: Eric Rosen , routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <32969213.20040229141401@psg.com> Message-ID: <20040229171734.A26083@kummer.juniper.net> References: <200402261840.i1QIef0K010848@rtp-core-2.cisco.com> <32969213.20040229141401@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 On Sun, 29 Feb 2004, Alex Zinin wrote: > I think you're missing the problem. It is not the size of the space. It is > the circular dependency between IANA allocation and STD action. Exactly. Kireeti. ------- From rtg-dir-admin@ietf.org Mon Mar 1 03:23:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01325 for ; Mon, 1 Mar 2004 03:23:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axii5-0004ni-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 03:23:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxihB-0004i0-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 03:22:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axigd-0004cg-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 03:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axige-0006Ke-DS; Mon, 01 Mar 2004 03:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifq-0006GJ-39 for rtg-dir@optimus.ietf.org; Mon, 01 Mar 2004 03:21:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01002 for ; Mon, 1 Mar 2004 03:21:12 -0500 (EST) From: kireeti@juniper.net Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxibG-0004AM-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 03:16:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiaO-00043s-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 03:15:37 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1AxiZc-0003sb-00; Mon, 01 Mar 2004 03:14:48 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i218EIPg027691; Mon, 1 Mar 2004 00:14:18 -0800 (PST) (envelope-from kireeti@kummer.juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) id i218EIIa027690; Mon, 1 Mar 2004 00:14:18 -0800 (PST) Date: Mon, 1 Mar 2004 00:14:18 -0800 (PST) Message-Id: <200403010814.i218EIIa027690@kummer.juniper.net> To: lberger@labn.net, zinin@psg.com Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Cc: kireeti@juniper.net, Mukesh.Gupta@nokia.com, routing-discussion@ietf.org, rtg-dir@ietf.org In-Reply-To: <6.0.3.0.2.20040301030646.03121d78@mail.labn.net> Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,NO_REAL_NAME autolearn=no version=2.60 > okay, got found your message. I think this should work for most > cases. I'd suggest adding text that allows for >1 renewal with IESG > approval (in unusual circumstances). Okay, unless I hear strong arguments to the contrary, I will add >1 renewals to the doc. Kireeti. From rtg-dir-admin@ietf.org Mon Mar 1 03:23:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01339 for ; Mon, 1 Mar 2004 03:23:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axii6-0004ns-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 03:23:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxihC-0004iH-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 03:22:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axigh-0004cl-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 03:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigi-0006Lh-24; Mon, 01 Mar 2004 03:22:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axift-0006Gt-LF for rtg-dir@optimus.ietf.org; Mon, 01 Mar 2004 03:21:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01041 for ; Mon, 1 Mar 2004 03:21:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiZL-0003wi-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 03:14:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiYN-0003pw-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 03:13:32 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxiXN-0003k7-00; Mon, 01 Mar 2004 03:12:29 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxiXN-000HP1-L4; Mon, 01 Mar 2004 08:12:29 +0000 Date: Mon, 1 Mar 2004 17:12:06 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <7834347198.20040301171206@psg.com> To: Lou Berger CC: Kireeti Kompella , Mukesh.Gupta@nokia.com, routing-discussion@ietf.org, Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <6.0.3.0.2.20040301030646.03121d78@mail.labn.net> References: <6.0.3.0.2.20040226205121.0620ebf8@mo-ex1> <391404519.20040229142116@psg.com> <6.0.3.0.2.20040301030646.03121d78@mail.labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Fair enough. -- Alex http://www.psg.com/~zinin/ Monday, March 1, 2004, 5:11:03 PM, Lou Berger wrote: > Alex, > okay, got found your message. I think this should work for most > cases. I'd suggest adding text that allows for >1 renewal with IESG > approval (in unusual circumstances). > Lou > At 12:21 AM 2/29/2004, Alex Zinin wrote: >>Lou, >> >> This would tie expiration to the author's ability to resubmit the draft, >> rather than to how the doc progresses. We could instead say that once >> the doc >> is submitted to the IESG, the codepoint is "frozen". >> >>-- >>Alex >>http://www.psg.com/~zinin/ >> >>Friday, February 27, 2004, 10:51:35 AM, Lou Berger wrote: >> >> > [resend] >> >> > How about linking assignment expiration to expiration of the draft, 3 >> > months after? If the draft makes it to RFC, no issue, if the draft >> takes a >> > long time through the editors queue (which can take ~1.5 years!), no >> issue, >> > if the draft keeps changing, no issue. If the draft dies, so does the >> > assignment. >> >> > Lou >> >> > At 11:24 AM 2/26/2004, Kireeti Kompella wrote: >> >>On Wed, 25 Feb 2004 Mukesh.Gupta@nokia.com wrote: >> >> >> >> > I finally got a chance to read the draft. The idea is good. I just >> >> > have a couple of questions/concerns about the expiry of the early >> >> > allocations.. >> >> > >> >> > - Do you think that "at most one renewal" would work in practice ? >> >> > There might be instances where there is a genuine need to keep >> >> > the early allocations for more than a year (Consider VRRPv3). >> >> > How do we deal with that situation ? If it is not possible to >> >> > renew the allocations more than once, do we need to ask for >> >> > early allocations with new numbers (which ofcourse will make >> >> > the situation worse) or we should just ask/let IANA to delete >> >> > and reassign those numbers (which would create problems as well). >> >> >> >>We mulled a bit over how many times the allocations should be renewed. >> >>The idea is that early allocation should NOT be requested as sson as >> >>an ID is written :-) One renewal may be a bit too aggressive, but >> >>it gives two years. Perhaps two renewals is okay, but no more (imho). >> >> >> >> > - The draft seems to put the responsibility of changing the status >> >> > of the early allocations on the WG chairs ? I know that our chairs >> >> > are very very responsible but I think, it will be a good idea to >> >> > have an alternate mechanism in place such that the early allocations >> >> > are marked deprecated/deleted automatically after a timeout. >> >> >> >>Automatic expiry was actually in the first version, but not everyone >> >>felt comfortable with that. We can (and should) review this, and >> >>perhaps make clearer what expiry means. >> >> >> >>Note that NOT adding to either IANA's or the IESG's workload is an >> >>explicit goal. Whatever we can do to avoid adding to WG chairs' >> >>workload is a 'nice-to-have' :-) >> >> >> >>Kireeti. >> >>------- >> >> >> >>_______________________________________________ >> >>routing-discussion mailing list >> >>routing-discussion@ietf.org >> >>https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-admin@ietf.org Mon Mar 1 03:23:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01371 for ; Mon, 1 Mar 2004 03:23:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axii8-0004o7-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 03:23:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxihF-0004ie-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 03:22:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axigl-0004cp-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 03:22:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axigm-0006NM-IA; Mon, 01 Mar 2004 03:22:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axifv-0006HB-4r for rtg-dir@optimus.ietf.org; Mon, 01 Mar 2004 03:21:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01061 for ; Mon, 1 Mar 2004 03:21:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxiZG-0003vy-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 03:14:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxiYH-0003ov-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 03:13:25 -0500 Received: from hs22.order-vault.net ([65.18.133.138]) by ietf-mx with esmtp (Exim 4.12) id 1AxiXI-0003gA-00; Mon, 01 Mar 2004 03:12:25 -0500 Received: from lb-laptop.labn.net (labn.net [65.18.134.4]) (authenticated (0 bits)) by hs22.order-vault.net (8.11.6/8.11.6) with ESMTP id i218B6p01313; Mon, 1 Mar 2004 03:11:06 -0500 Message-Id: <6.0.3.0.2.20040301030646.03121d78@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 01 Mar 2004 03:11:03 -0500 To: Alex Zinin From: Lou Berger Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Cc: Kireeti Kompella , Mukesh.Gupta@nokia.com, routing-discussion@ietf.org, In-Reply-To: <391404519.20040229142116@psg.com> References: <6.0.3.0.2.20040226205121.0620ebf8@mo-ex1> <391404519.20040229142116@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Alex, okay, got found your message. I think this should work for most cases. I'd suggest adding text that allows for >1 renewal with IESG approval (in unusual circumstances). Lou At 12:21 AM 2/29/2004, Alex Zinin wrote: >Lou, > > This would tie expiration to the author's ability to resubmit the draft, > rather than to how the doc progresses. We could instead say that once > the doc > is submitted to the IESG, the codepoint is "frozen". > >-- >Alex >http://www.psg.com/~zinin/ > >Friday, February 27, 2004, 10:51:35 AM, Lou Berger wrote: > > > [resend] > > > How about linking assignment expiration to expiration of the draft, 3 > > months after? If the draft makes it to RFC, no issue, if the draft > takes a > > long time through the editors queue (which can take ~1.5 years!), no > issue, > > if the draft keeps changing, no issue. If the draft dies, so does the > > assignment. > > > Lou > > > At 11:24 AM 2/26/2004, Kireeti Kompella wrote: > >>On Wed, 25 Feb 2004 Mukesh.Gupta@nokia.com wrote: > >> > >> > I finally got a chance to read the draft. The idea is good. I just > >> > have a couple of questions/concerns about the expiry of the early > >> > allocations.. > >> > > >> > - Do you think that "at most one renewal" would work in practice ? > >> > There might be instances where there is a genuine need to keep > >> > the early allocations for more than a year (Consider VRRPv3). > >> > How do we deal with that situation ? If it is not possible to > >> > renew the allocations more than once, do we need to ask for > >> > early allocations with new numbers (which ofcourse will make > >> > the situation worse) or we should just ask/let IANA to delete > >> > and reassign those numbers (which would create problems as well). > >> > >>We mulled a bit over how many times the allocations should be renewed. > >>The idea is that early allocation should NOT be requested as sson as > >>an ID is written :-) One renewal may be a bit too aggressive, but > >>it gives two years. Perhaps two renewals is okay, but no more (imho). > >> > >> > - The draft seems to put the responsibility of changing the status > >> > of the early allocations on the WG chairs ? I know that our chairs > >> > are very very responsible but I think, it will be a good idea to > >> > have an alternate mechanism in place such that the early allocations > >> > are marked deprecated/deleted automatically after a timeout. > >> > >>Automatic expiry was actually in the first version, but not everyone > >>felt comfortable with that. We can (and should) review this, and > >>perhaps make clearer what expiry means. > >> > >>Note that NOT adding to either IANA's or the IESG's workload is an > >>explicit goal. Whatever we can do to avoid adding to WG chairs' > >>workload is a 'nice-to-have' :-) > >> > >>Kireeti. > >>------- > >> > >>_______________________________________________ > >>routing-discussion mailing list > >>routing-discussion@ietf.org > >>https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-admin@ietf.org Mon Mar 1 05:00:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06332 for ; Mon, 1 Mar 2004 05:00:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxkE0-000752-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 05:00:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxkD6-0006zM-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 04:59:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxkCQ-0006tv-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 04:58:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkCT-000847-6e; Mon, 01 Mar 2004 04:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkC0-00082j-Dk for rtg-dir@optimus.ietf.org; Mon, 01 Mar 2004 04:58:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06215 for ; Mon, 1 Mar 2004 04:58:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxkBw-0006pb-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 04:58:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxkAy-0006j2-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 04:57:29 -0500 Received: from [4.10.165.31] (helo=FAMILY-B87XG2IW) by ietf-mx with smtp (Exim 4.12) id 1Axk9y-0006ZB-00; Mon, 01 Mar 2004 04:56:27 -0500 Received: from 52.67.124.105 by 4.10.165.31; Mon, 01 Mar 2004 14:58:37 +0500 Message-ID: From: "Adrian Heard" Reply-To: "Adrian Heard" To: rtg-dir@ietf.org Subject: Fioricet, Ambien, Buspar, Prozac, and more Prescribed ... Date: Mon, 01 Mar 2004 10:51:37 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0997821806647855" X-Originating-IP: 132.151.6.1 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,HTML_WEB_BUGS,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----0997821806647855 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Almost 75% OFF ON HUNDREDS OF MEDICATIONS
Absolutely No Doctor Appointment Needed!

Order prescription medication including weight loss/diet pill, skin care, birth control, muscle relaxants, high level pain relief, anxiety, prescription sleeping aids, anti-depressant medications and more.

The product will be filled and shipped by a US licensed pharmacist overnight to your door, immediately and discreetly.

We make it easier and faster than ever to get the medications you need!

Order by 2 pm EST and you get your meds tomorrow.

Get Your Meds Here and Save!

Ualice maseru deprive cube boo inadvertent acid oxidate pbs ascomycetes randolph tyrannosaurus . Jclaus selenite barberry bouncy capsule allied kinematic tuba deliberate cadaver crude tnt belittle germicidal crotchety coronet technetium scab infinitive : Npolygynous colza dryad cheeky ostentatious celluloid expeditious carburetor cretan stannic weary estimate thelma compendium fix longstanding counterattack dorcas airport dusky durkee carte analeptic noose commune acetone halley yank absolute ca abduct Tinaccurate proponent coastline dyer furbish camouflage ; Bsomal amerada myeline nebulae madhouse stank brusque cloud brushwork mayhem smatter embarrass dunce sheehan anthony miser imaginary caveman cradle poisonous capture . Targinine ointment redtop estella ginn swirly baklava produce assist corcoran flatulent doctrine restitution demurred potboil degas tweedy counsel sciatica candy yeasty faculty fissile rabbit headstand n! euroanatomy bagel wuhan max polyphemus contaminant delegate megohm enid prank amplify bookstore hypoactive deform notch elisha belgrade capillary die Kcamp window catastrophic accredit coverall wastewater comet deficient adipic rickety . Pcantonese sapling koala archipelago petunia pluton saskatoon greenland dictionary !! Xteapot thwack abbey nazi insecure bodhisattva counsel postulate afford lightface trapezium occurrent layton purgatory cartographer stun titan amity intestine blare histidine coexistent aida claim aging caller edwardine hat bouquet davit universe diabetes astronaut Scrucifix crossroad adolph arab shari logjam premature . Hquicksand install coset fat discussant coot grammarian . Alossy cedric lausanne parkway corps lunchroom bodyguard crosslink steady propeller deviant regular chalcedony pantry belies endicott lucifer therefor mescal level impede elton grape converse chassis patrolmen lang molar prow boldface austria edmonds utmost thyronine cabinetry cou! rse bestselling haiti hinge sore brussels

If this notice has reached you in error, please notify us by clicking here
----0997821806647855-- From rtg-dir-admin@ietf.org Mon Mar 1 06:05:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10066 for ; Mon, 1 Mar 2004 06:05:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxlF2-0006My-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 06:05:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxlE4-0006HG-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 06:04:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxlDK-0006Bi-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 06:03:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlDN-0006Me-Iz; Mon, 01 Mar 2004 06:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxlD7-0006LH-TP for rtg-dir@optimus.ietf.org; Mon, 01 Mar 2004 06:03:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09954 for ; Mon, 1 Mar 2004 06:03:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxlD4-0006AJ-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 06:03:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxlCC-00064y-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 06:02:49 -0500 Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx with esmtp (Exim 4.12) id 1AxlBi-0005yj-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 06:02:18 -0500 Received: from NtscpUsrLoa@netscape.net by imo-d02.mx.aol.com (mail_out_v36_r4.14.) id 1.7.c7ff2fc (16240); Mon, 1 Mar 2004 06:01:46 -0500 (EST) Received: from netscape.net (tla-loa.dhcp.ietf59.or.kr [218.37.227.218]) by air-in03.mx.aol.com (v98.11) with ESMTP id MAILININ34-3f704043181711c; Mon, 01 Mar 2004 06:01:46 -0500 Message-ID: <40431804.7050106@netscape.net> Date: Mon, 01 Mar 2004 20:01:24 +0900 From: Loa Andersson Reply-To: loa@pi.se 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: MPLS wg , rtg-dir@ietf.org CC: George Swallow , Alex Zinin Subject: WG last call for draft-ietf-mpls-oam-requirements-02.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 218.37.227.218 X-Mailer: Unknown (No Version) Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 WG, This is to initiate a WG last call for due to the ongoing IETF meeting the WG last call will end March 21 12PM EST. The drafts is intended as Proposed Standard on the standards track. Please send comments to the mpls working group mailing list. -------------------------------------------------------------------- Abstract (included as informaiton) As transport of diverse traffic types such as voice, frame relay, and ATM over MPLS become more common, the ability to detect, handle and diagnose control and data plane defects becomes critical. Detection and specification of how to handle those defects is not only important because such defects may not only affect the fundamental operation of an MPLS network, but also because they may impact SLA commitments for customers of that network. This Internet draft describes requirements for user and data plane operations and management (OAM) for Multi-Protocol Label Switching (MPLS). These requirements have been gathered from network operators who have extensive experience deploying MPLS networks, similarly some of these requirements have appeared in other documents [Y1710]. This draft specifies OAM requirements for MPLS, as well as for applications of MPLS such as pseudowire voice and VPN services. Those interested in specific issues relating to instrumenting MPLS for OAM purposes are directed to [FRAMEWORK] ------------------------------------------------------------------------ /Loa -- Loa Andersson mobile +46 739 81 21 64 From rtg-dir-admin@ietf.org Mon Mar 1 11:42:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18805 for ; Mon, 1 Mar 2004 11:42:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxqGB-0003cV-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 11:27:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxqDa-0002SQ-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 11:24:35 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxqAy-0001Vs-01 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 11:21:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axpw6-0000nQ-Rk for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 11:06:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpvz-0002gY-BJ; Mon, 01 Mar 2004 11:06:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpvb-0002Me-Ro for rtg-dir@optimus.ietf.org; Mon, 01 Mar 2004 11:05:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13885 for ; Mon, 1 Mar 2004 11:05:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axphl-0007Qs-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 10:51:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxpTP-0002cA-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 10:36:55 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Axp1j-0002xB-00; Mon, 01 Mar 2004 10:08:15 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2004 07:06:33 -0800 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i21F7gT4028601; Mon, 1 Mar 2004 10:07:42 -0500 (EST) Message-Id: <200403011507.i21F7gT4028601@rtp-core-1.cisco.com> To: Alex Zinin cc: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-reply-to: Your message of Sun, 29 Feb 2004 14:14:01 +0900. <32969213.20040229141401@psg.com> Reply-To: erosen@cisco.com 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 Date: Mon, 01 Mar 2004 10:07:42 -0500 From: Eric Rosen Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 > I think you're missing the problem. It is not the size of the space. It is > the circular dependency between IANA allocation and STD action. I think there is only a practical problem if the space is small. If the space is large, the problem is easily solved by making a part of it available for FCFS assignment. In fact, it seems evident that it doesn't make any sense to put a large space in the "STD action" category, as there is no means to enforce it. From rtg-dir-admin@ietf.org Mon Mar 1 12:47:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24264 for ; Mon, 1 Mar 2004 12:47:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrWA-0000yg-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 12:47:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrVI-0000tZ-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 12:46:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxrUQ-0000ng-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 12:46:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrUP-0004OW-Cy; Mon, 01 Mar 2004 12:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxrUL-0004OA-FX for rtg-dir@optimus.ietf.org; Mon, 01 Mar 2004 12:45:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24167 for ; Mon, 1 Mar 2004 12:45:54 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxrUJ-0000mX-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 12:45:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxrTP-0000gm-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 12:44:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AxrSy-0000as-00; Mon, 01 Mar 2004 12:44:32 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i21HiRT26019; Mon, 1 Mar 2004 19:44:27 +0200 (EET) X-Scanned: Mon, 1 Mar 2004 19:44:24 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i21HiOmJ032192; Mon, 1 Mar 2004 19:44:24 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00BriZNt; Mon, 01 Mar 2004 19:44:23 EET 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 i21HiLO27705; Mon, 1 Mar 2004 19:44:22 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Mar 2004 09:43:43 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Date: Mon, 1 Mar 2004 11:43:41 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401547311@daebe009.americas.nokia.com> Thread-Topic: Comments solicited: draft-kompella-zinin-early-allocation-00.txt Thread-Index: AcP/ZYhIyqRAsFFORx2VxOn7reii7gATyAMQ To: , , Cc: , X-OriginalArrivalTime: 01 Mar 2004 17:43:43.0941 (UTC) FILETIME=[BDC38750:01C3FFB4] Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > Okay, unless I hear strong arguments to the contrary, I will add >1 > renewals to the doc. If at all it matters, count my vote for this too. From rtg-dir-admin@ietf.org Mon Mar 1 14:29:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29434 for ; Mon, 1 Mar 2004 14:29:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt70-0005IE-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 14:29:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt5x-00057p-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 14:28:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axt54-000504-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 14:27:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt56-0002fx-Hb; Mon, 01 Mar 2004 14:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axt55-0002fh-2s for rtg-dir@optimus.ietf.org; Mon, 01 Mar 2004 14:27:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29075 for ; Mon, 1 Mar 2004 14:27:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axt4v-0004yo-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 14:27:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axt3x-0004rS-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 14:26:49 -0500 Received: from natint2.juniper.net ([207.17.136.150] helo=roque-bsd.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Axt2y-0004g6-00; Mon, 01 Mar 2004 14:25:48 -0500 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 i21JPI1K049498; Mon, 1 Mar 2004 11:25:18 -0800 (PST) (envelope-from roque@roque-bsd.juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.12.8p1/8.12.3/Submit) id i21JPI65049495; Mon, 1 Mar 2004 11:25:18 -0800 (PST) Date: Mon, 1 Mar 2004 11:25:18 -0800 (PST) Message-Id: <200403011925.i21JPI65049495@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Lou Berger Cc: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <6.0.3.0.2.20040226143327.03467ea8@mail.labn.net> References: <8D260779A766FB4A9C1739A476F84FA401F799BA@daebe009.americas.nokia.com> <20040226081555.S11637@kummer.juniper.net> <6.0.3.0.2.20040226143327.03467ea8@mail.labn.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Lou Berger writes: > How about linking assignment expiration to expiration of the draft, > 3 months after? If the draft makes it to RFC, no issue, if the > draft takes a long time through the editors queue (which can take > ~1.5 years!), no issue, if the draft keeps changing, no issue. If > the draft dies, so does the assignment. Just make sure you don't try to reuse the same assigned number for something else in less than 10 years, if it ever gets into software... That is about the lifetime for 'deprecated' behaviour. While the ietf may be able to assume that an assigment "dies"... the decision may not be so simple in the real world. I would at least like to have a good idea of everyone that claims to have implemented said code point... Ask your self the question: How many networks are running TDP, which is a protocol that "died" in the ietf ? And would you like to reuse its code point ? I'm sure that people can come up w/ many other examples. Pedro. From rtg-dir-admin@ietf.org Mon Mar 1 19:40:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16368 for ; Mon, 1 Mar 2004 19:40:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axxxz-0000ve-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 19:40:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axxx1-0000oF-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 19:39:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axxw3-0000eF-00 for rtg-dir-archive@ietf.org; Mon, 01 Mar 2004 19:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axxw5-0007W1-20; Mon, 01 Mar 2004 19:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxvU-0007Nd-J4 for rtg-dir@optimus.ietf.org; Mon, 01 Mar 2004 19:38:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15979 for ; Mon, 1 Mar 2004 19:38:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxvS-0000Vz-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 19:38:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxuV-0000Lk-00 for rtg-dir@ietf.org; Mon, 01 Mar 2004 19:37:23 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AxxtO-0000CP-00; Mon, 01 Mar 2004 19:36:14 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxxtO-000FC9-KT; Tue, 02 Mar 2004 00:36:14 +0000 Date: Tue, 2 Mar 2004 09:35:53 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4055365811.20040302093553@psg.com> To: Eric Rosen CC: routing-discussion@ietf.org, rtg-dir@ietf.org Subject: Re: Comments solicited: draft-kompella-zinin-early-allocation-00.txt In-Reply-To: <200403011507.i21F7gT4028601@rtp-core-1.cisco.com> References: <200403011507.i21F7gT4028601@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Eric, > I think there is only a practical problem if the space is small. If the > space is large, the problem is easily solved by making a part of it > available for FCFS assignment. In fact, it seems evident that it doesn't > make any sense to put a large space in the "STD action" category, as there > is no means to enforce it. I see your point now. Note that "STD action" and a space being small are not directly related--it is feasible to use "STD action" even if the space is big enough (e.g. for change control), and on the other hand, it is possible to use other policies for scarce resources (Expert Review, IESG Approval, IETF Consensus). Also note, that there several existing registries with "STD action" as the policy and that need this issue solved. Alex From rtg-dir-admin@ietf.org Tue Mar 2 20:46:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19341 for ; Tue, 2 Mar 2004 20:46:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLTM-0001tt-00 for rtg-dir-archive@ietf.org; Tue, 02 Mar 2004 20:46:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLSR-0001jx-00 for rtg-dir-archive@ietf.org; Tue, 02 Mar 2004 20:45:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyLRV-0001Yb-00 for rtg-dir-archive@ietf.org; Tue, 02 Mar 2004 20:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLRV-00037K-SR; Tue, 02 Mar 2004 20:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLQb-00034V-9E for rtg-dir@optimus.ietf.org; Tue, 02 Mar 2004 20:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19178 for ; Tue, 2 Mar 2004 20:44:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLQY-0001PF-00 for rtg-dir@ietf.org; Tue, 02 Mar 2004 20:44:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLPm-0001HY-00 for rtg-dir@ietf.org; Tue, 02 Mar 2004 20:43:15 -0500 Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx with esmtp (Exim 4.12) id 1AyLP6-00018o-00 for rtg-dir@ietf.org; Tue, 02 Mar 2004 20:42:32 -0500 Received: from NtscpUsrLoa@netscape.net by imo-d02.mx.aol.com (mail_out_v37.4.) id 1.1b1.9d7be0f (22683); Tue, 2 Mar 2004 20:41:57 -0500 (EST) Received: from netscape.net (tla-loa.wireless.ietf59.or.kr [218.37.227.218]) by air-in04.mx.aol.com (v98.11) with ESMTP id MAILININ44-589b404537e132a; Tue, 02 Mar 2004 20:41:57 -0500 Message-ID: <404537DE.30300@netscape.net> Date: Wed, 03 Mar 2004 10:41:50 +0900 From: Loa Andersson Reply-To: loa@pi.se 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: MPLS wg CC: loa@pi.se, rtg-dir@ietf.org, George Swallow , Alex Zinin Subject: Re: WG last call for draft-ietf-mpls-oam-requirements-02.txt - correction References: <40431804.7050106@netscape.net> In-Reply-To: <40431804.7050106@netscape.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 218.37.227.218 X-Mailer: Unknown (No Version) Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 WG, it has correctly been pointed out that this is not for the standards track, but will be an Informational RFC. /Loa Loa Andersson wrote: > WG, > > This is to initiate a WG last call for > > > > due to the ongoing IETF meeting the WG last call will end March 21 > 12PM EST. > > The drafts is intended as Proposed Standard on the standards track. > Please send comments to the mpls working group mailing list. > > -------------------------------------------------------------------- > Abstract (included as informaiton) > > As transport of diverse traffic types such as voice, frame > relay, and ATM over MPLS become more common, the ability to detect, > handle and diagnose control and data plane defects becomes > critical. > > Detection and specification of how to handle those defects is not > only important because such defects may not only affect the > fundamental operation of an MPLS network, but also because they > may impact SLA commitments for customers of that network. > > This Internet draft describes requirements for user and data > plane operations and management (OAM) for Multi-Protocol > Label Switching (MPLS). These requirements have been gathered > from network operators who have extensive experience deploying > MPLS networks, similarly some of these requirements have > appeared in other documents [Y1710]. This draft specifies OAM > requirements for MPLS, as well as for applications of MPLS such > as pseudowire voice and VPN services. Those interested in specific > issues relating to instrumenting MPLS for OAM purposes are directed > to [FRAMEWORK] > ------------------------------------------------------------------------ > > /Loa -- Loa Andersson mobile +46 739 81 21 64 From rtg-dir-admin@ietf.org Thu Mar 4 07:53:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16989 for ; Thu, 4 Mar 2004 07:53:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AysM7-0004vW-00 for rtg-dir-archive@ietf.org; Thu, 04 Mar 2004 07:53:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AysLE-0004jv-00 for rtg-dir-archive@ietf.org; Thu, 04 Mar 2004 07:52:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AysKW-0004Xt-00 for rtg-dir-archive@ietf.org; Thu, 04 Mar 2004 07:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AysKW-0001VW-Fx; Thu, 04 Mar 2004 07:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AysK2-0001Tn-Na for rtg-dir@optimus.ietf.org; Thu, 04 Mar 2004 07:51:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16643 for ; Thu, 4 Mar 2004 07:51:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AysK1-0004To-00 for rtg-dir@ietf.org; Thu, 04 Mar 2004 07:51:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AysJ1-0004Ds-00 for rtg-dir@ietf.org; Thu, 04 Mar 2004 07:50:28 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AysI1-0003yD-00 for Rtg-dir@ietf.org; Thu, 04 Mar 2004 07:49:25 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AysHp-000MJU-Fo; Thu, 04 Mar 2004 12:49:13 +0000 Date: Thu, 4 Mar 2004 21:48:45 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <69208952517.20040304214845@psg.com> To: ccamp@ops.ietf.org CC: Rtg-dir@ietf.org Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO, SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- Please find below comments from the RTG area directorate that I would like the WG to consider. Thank you. -- Alex Zinin Technical: ---------- Section 3.2: 1. Figure 1 misses the STM-0 branch Section 3.4.3: 2. In comparison table, PNNI word appears for the first time in this document, any specific reason to mention PNNI in a GMPLS context ? Section 3.5 3. "New simplified encapsulations could reduce this overhead to as low as 3%, but the gain is not huge compared to SDH and SONET, which have other benefits as well.)" any reference available for these new simplified encapsulation(s) ? 4. "Any encapsulation of IP over WDM should at least provide error monitoring capabilities (to detect signal degradation), error correction capabilities, such as FEC (Forward Error Correction) that are particularly needed for ultra long haul transmission, sufficient timing information, to allow robust synchronization (that is, to detect the beginning of a packet), and capacity to transport signaling, routing and management messages, in order to control the optical switches." The first part refers to data plane capabilities, however the requirement: the "encapsulation of IP over WDM" should deliver the capacity to transport IP based control plane information - why is this the case ? an out of band network would also do the job and this statement makes thus the implicit assumption that data and control plane topology is congruent Section 6: 5. "Due to the increase in information transferred in the routing protocol, it may be useful to separate the relatively static parameters concerning a link from those that may be subject to frequent changes. The current GMPLS routing extensions [12],[13], [14] do not make such a separation, however." it may be thus worth asking the question was the dissemination of these quasi-static "link capabilities" using the same rules as for any other TE LSA Type 1 sub-TLV the right approach ? Section 6.1: 6. what does the following sentence brings in the scope of this control plane framework (and this is even not necessarily true when vcat is provided over different line cards): "Note that this inverse multiplexing process can be significantly easier to implement with SONET/SDH signals rather than packets." Section 6.3: 7. "However, if only standard concatenation is supported then reporting gets trickier since there are constraints on where the STS-1s can be placed. SDH has still more options and constraints, hence it is not yet clear which is the best way to advertise bandwidth resource availability/usage in SONET/SDH. At present, the GMPLS routing protocol extensions define minimum and maximum values for available bandwidth, which allows a remote node to make some deductions about the amount of capacity available at a remote link and the types of signals it can accommodate. However, due to the multiplexed nature of the signals, the authors are of the opinion that reporting of bandwidth particular to signal types rather than as a single aggregate bit rate is probably very desirable." -> the authors do not explain from which perspective and the reasons this particular bw accounting report is desirable (sections 2.4.3 & 2.4.8 of GMPLS routing explains how these values are used to take into account the multiplexing capability of a SONET/SDH interface), there is no real determination of the missing information at remote nodes for the establishment of an LSP with a certain amount of bw (note that it is not an issue of flexible vs standard concatenation issue but a control plane issue) Section 7.3: 8. "This information is specified in three parts [17], each of which refers to a different network layer." The description of the signaling elements shall mention the following: (section 7.3 refers to [17] but the latter does not correspond to the description given in this section) 1. GENERALIZED_LABEL REQUEST (as [RFC3471/3]) which contains three parts: LSP Encoding Type, Switching Type, G-PID 2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as SENDER_TSPEC/FLOWSPEC which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT, Transparency, Profile 3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3]) 4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as [RFC3473]) ---- Editorial: ---------- Section 3: 1. Sometimes this document refers to GMPLS other to MPLS and sometimes as above as "extending IP technology" Section 3.1 2. "When a packet reaches a core packet LSR, this LSR uses the label as an index into a forwarding table to determine the next hop and the corresponding outgoing label (and, possibly, the QoS treatment to be given to the packet), writes the new label into the packet, and forwards the packet to the next hop. " -> replace "core packet LSR" by "packet LSR" Section 3.2: 3. "SDH and SONET are two TDM standards widely used by operators to transport and multiplex different tributary signals over optical links, thus creating a multiplexing structure, which we call the SDH/SONET multiplex. SDH, which was developed by the ETSI and later standardized by the ITU-T [4], is now used worldwide, while SONET, which was standardized by the ANSI [5], is mainly used in the US. However, these two standards have several similarities, and to some extent SONET can be viewed as a subset of SDH. Internetworking between the two is possible using gateways. Should be rather as "ITU-T SDH (G.707) includes both the European ETSI SDH hierarchy and the USA ANSI SONET hierarchy (T1.105)." [...] "The ETSI SDH and SONET standards regarding frame structures and higher order multiplexing are the same. There are some regional differences on the terminology, on the use of some overhead bytes, and lower order multiplexing. Interworking between the two lower order hierarchies is possible using gateways." Section 3.2 4. "In addition, a pointer (in the form of the H1, H2 and H3 bytes) indicates the beginning of the VC/SPE in the payload of the overall STM/SDH frame." -> replace "STM/SDH frame" by "STM/STS frame" Section 4.1 5. "The SONET case is a bit difficult to explain since, unlike in SDH, SPEs in SONET do not have individual names." they are simply referred to as VT-N SPE Section 6: 6. Since this document distinguishes between "optical networks", TDM, and WDM it would advisable to avoid the "optical TDM" as mentioned in the below sentence (it has another meaning than MSn/RSn switching) Section 6.1: 7. Table 2, misses the equivalence between VC-4 and STS-3c SPE > Section 6.1: 8. "Standard and flexible concatenations are network services, while virtual concatenation is a SONET/SDH end-system service recently approved by the committee T1 of ANSI and ITU-T." remove "recently approved by the committee T1 of ANSI and ITU-T." and add the corr. reference. 9. "In one example of virtual concatenation, two end systems supporting this feature could essentially "inverse multiplex" two STS-1s into a virtual STS-2c for the efficient transport of 100 Mbps Ethernet traffic." -> STS-1-2v instead of "virtual STS-2c" 10. "Section layer: Preserves all section overhead, Basically does not touch any of the SONET/SDH bits." -> replace last part by "Basically does not modify or terminate any of the SONET/SDH overhead bits" left column of the table misses the SDH overhead equivalent 11. Multiplexing of (?) in the following sentence "To perform multiplexing, a SONET network element should be line terminating." Section 6.2: 12. In the following "Standardized SONET line level protection techniques include: Linear 1+1 and linear 1:N automatic protection switching (APS) and both two-fiber and four-fiber bi-directional line switched rings (BLSRs). At the path layer, SONET offers uni-directional path switched ring protection." the same applies to SDH (to be adapted using the corr. terminology) Section 7: 13. "This VC-4 LSP can, in fact, be established between two non- adjacent internal nodes in an SDH network, and later advertised by a routing protocol as a new (virtual) link called a Forwarding Adjacency (FA)." -> add MPLS-HIERARCHY as reference 14. The following paragraph "For instance, the payload of an SDH STM-1 frame does not fully contain a complete unit of user data. In fact, the user data is contained in a virtual container (VC) that is allowed to float over two contiguous frames for synchronization purposes. A pointer in the Section Overhead (SOH) indicates the beginning of the VC in the payload." mixes SDH with SONET - pointers in SDH in H1/H2/H3 From rtg-dir-admin@ietf.org Sat Mar 6 15:32:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04172 for ; Sat, 6 Mar 2004 15:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AziSq-0003Cp-00 for rtg-dir-archive@ietf.org; Sat, 06 Mar 2004 15:32:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AziRr-0002zr-00 for rtg-dir-archive@ietf.org; Sat, 06 Mar 2004 15:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AziRr-0001h9-Tc; Sat, 06 Mar 2004 15:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AziRa-0001cH-Dg for rtg-dir@optimus.ietf.org; Sat, 06 Mar 2004 15:30:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04002 for ; Sat, 6 Mar 2004 15:30:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AziRZ-0002wc-00 for rtg-dir@ietf.org; Sat, 06 Mar 2004 15:30:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AziQX-0002bg-00 for rtg-dir@ietf.org; Sat, 06 Mar 2004 15:29:41 -0500 Received: from lns-th2-12-82-64-182-135.adsl.proxad.net ([82.64.182.135] helo=82.64.182.135) by ietf-mx with smtp (Exim 4.12) id 1AziPS-0002Nv-00 for rtg-dir@ietf.org; Sat, 06 Mar 2004 15:28:36 -0500 From: hostmaster@cnchost.com To: rtg-dir@ietf.org Subject: Your credit card has been successfully charged for $69.95 Date: Sun, 07 Mar 2004 04:27:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.3 required=5.0 tests=AWL,DATE_IN_FUTURE_12_24, FORGED_MUA_OUTLOOK,IMPOTENCE,MSGID_FROM_MTA_SHORT,NO_REAL_NAME, RCVD_NUMERIC_HELO,SUBJ_YOUR_DEBT,VIAGRA autolearn=no version=2.60 X-Spam-Report: * 0.7 SUBJ_YOUR_DEBT Subject contains "Your Bills" or similar * 0.3 NO_REAL_NAME From: does not include a real name * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 4.2 IMPOTENCE BODY: Impotence cure * 1.9 VIAGRA BODY: Plugs Viagra * 2.0 DATE_IN_FUTURE_12_24 Date: is 12 to 24 hours after Received: date * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -1.0 AWL AWL: Auto-whitelist adjustment Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Administration of www.shadowcrew.com online store would like to thank you for your purchase of Viagra tablets. Couple of words about our products and services. Viagra is a prescription drug used to treat erection difficulties, such as erectile dysfunction, which also refers to as an impotence. At this condition men do not experience normal erection, necessary for the sexual act. VIAGRA works only in reply to sexual excitation and does not influence reproductive function in any way. Your tablets will be sent to the address specified by you within 24 hours. You should store VIAGRA at temperature below 30 degrees in original packing and out of reach of children. Do not take preparation after expiry date which is located on top of the package. We are the only official dealers that offer you tablets in original packaging. We guarantee to refund your money during 30 days. If you never purchased this product please contact us at: 1.888.575.6398 To cancel this purchase please contact us at: 1.408-817-2800 To change the shipping address on the order: 1.877.999.8779 If you suffer any side effects please contact: 1.866.963.9696 For bulk purchases please contact: 1.703.547.2000 Thank you for choosing www.shadowcrew.com We are the first - the best. From rtg-dir-admin@ietf.org Sun Mar 7 09:27:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20400 for ; Sun, 7 Mar 2004 09:27:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzzG3-0002rC-00 for rtg-dir-archive@ietf.org; Sun, 07 Mar 2004 09:27:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzzF9-0002eW-00 for rtg-dir-archive@ietf.org; Sun, 07 Mar 2004 09:27:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzzE9-0002RE-00 for rtg-dir-archive@ietf.org; Sun, 07 Mar 2004 09:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzzE9-0002jD-SK; Sun, 07 Mar 2004 09:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzzDl-0002iR-5i for rtg-dir@optimus.ietf.org; Sun, 07 Mar 2004 09:25:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20239 for ; Sun, 7 Mar 2004 09:25:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzzDj-0002NW-00 for rtg-dir@ietf.org; Sun, 07 Mar 2004 09:25:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzzCS-0001z4-00 for rtg-dir@ietf.org; Sun, 07 Mar 2004 09:24:17 -0500 Received: from [210.150.186.27] (helo=vbn.inter-touch.net) by ietf-mx with esmtp (Exim 4.12) id 1AzzAo-0001V8-00 for rtg-dir@ietf.org; Sun, 07 Mar 2004 09:22:34 -0500 Received: from Puppy (unknown [10.5.0.13]) by vbn.inter-touch.net (Postfix) with SMTP id 138E414D008; Sun, 7 Mar 2004 14:21:50 +0000 (/etc/localtime) Message-ID: <015501c4044f$95a39630$0800050a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "MPLS wg" , Cc: "George Swallow" , "Alex Zinin" References: <40431804.7050106@netscape.net> Subject: Re: WG last call for draft-ietf-mpls-oam-requirements-02.txt Date: Sun, 7 Mar 2004 14:22:06 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Hi, Questions: 1. There is no explicit description of operation of OAM in the presence of PHP. Should there be? 2. Call me a pedant if you like, but where section 3.4 describes measuring the SLA shouldn't it really talk about measuing the service and comparing it with the SLA? 3. There is no requirement placed on the avoidance of the negative impact of OAM on the customer's service. 4. Section 3.7 describes error detection and recovery. While it is clearly the responsibility of OAM to assist in error detection and reporting, I don't see OAM playing any further part in recovery. Should you re-cast this section in terms of facilitation of recovery? 5. 3.10.1 has (2) At an intermediate LSR, accounting of traffic through LSPs for each pair of ingress to egress. This is interesting. If the label stack has just one label then I guess we can peep inside (if the payload is IP). Is this what you intended, or is this requirement really only limited to "non-merging" LSPs such as LSP tunnels? 6. I think the security section is a bit weak. traceroute and ping have long been considered to have important security considerations beyond simple exposure of private network topologies. I think this is an important area where you should get some advice from a security expert. I know the RFC editor can sort out these types of problems, but given the amount of pressure that the editor is under at the moment, we should really try to clean up our drafts vefore pushing them through last call. Here are a few nits from a brief scan of the draft. The draft should indicate its category. Informational or standards track? Indentation is varried between sections Abstract Detection and specification of how to handle those defects is not only important because such defects may not only affect the fundamental operation of an MPLS network, but also because they may impact SLA commitments for customers of that network. The use of "not only" twice is confusing. Abstract This Internet draft describes requirements for user and data Please state "This document" Abstract This Internet draft describes requirements for user and data plane operations and management (OAM) for Multi-Protocol Label Switching (MPLS). Insert final word "networks" Abstract This draft specifies OAM requirements for MPLS, as well as for applications of MPLS such Please state "This document" Abstract contains citations by reference. It mustn't. Page numbers in index are out of date Introduction This Internet draft describes requirements for user and data Please state "This document" Introduction This Internet draft describes requirements for user and data plane operations and management (OAM) for Multi-Protocol Label Switching (MPLS). Insert final word "networks" Introduction This draft specifies OAM requirements for MPLS, Please state "This document" Introduction No specific mechanisms are proposed to address these requirements at this time. Say rather "in this document" (time is relative :-) Introduction The goal of this draft is to identify a commonly applicable set of requirements for MPLS OAM. Please state "...this document" Section 2 formating is off Section 2 (and remainder of doc) LSP: Label Switch Path "Switched"! Section 2 (and remainder of doc) LSR: Label Switch Router This is one of Loa's favorites. Best get it right! Section 3 For example, the use of RSVP or LDP signaling and defects may be covered in some deployments, Please say "RSVP-TE" Section 3 As MPLS matures relationships between providers has become more complex. Please read As MPLS matures, relationships between providers have become more complex. Section 3 Furthermore, the deployment of multiple concurrent applications of MPLS is common place. "commonplace" is a single word Section 3 Requirements How many section 3s are you allowed? :-) Section 3.1, 3.2, 3.3 headings needs to be out-dented Section 3.1 instead,this function should be automated and performed from the origination of that LSP. read "instead, this function" Section 3.1 contains several stray double spaces. Suggest you search the whole document. Section 3.1 If the time to detect is known, then automated responses can be specified both w.r.t.with regard to resiliency and SLA reporting. Erm... "w.r.t. with"? Section 3.1 For example, failures can be may occur where inconsistencies exist between the IP and MPLS forwarding tables, inconsistencies in the MPLS control and data plane or problems with the reply path (i.e.: a reverse MPLS path does not exist). Something wrong with this sentence beyond "...failures may occur..." Section 3.2 needs spaces between paragraphs Section 3.2 This is particularly true for misbranching defects which are particularly difficult to specify recovery actions in an LDP network. ??? This is particularly true for misbranching defects for which it is particularly difficult to specify recovery actions in an LDP network. Section 3.2 Experience suggests that this is best accomplished via a path trace function that can return the entire list of LSRs and links used by a certain LSP (or at least the set of LSRs/links up to the location of the defect) is required. Delete "is required" Section 3.3 The ability of a path trace function to reveal details of LSR forwarding operations relevant to OAM functionality. This is not a sentence. Section 3.5 You have two of these, too. Section 3.5 (the first) The operator MUST be have the flexibility to configure OAM Delete "be" Section 3.5 (the second) capitalisation in header Section 3.5 (2nd) Devices must provide alarm suppression functionality that prevents the generation of superfluous generation of alarms. Delete "generation of" Section 3.8 is missing a title Section 3.8 This will be reflected in the the integration of standard MPLS-related MIBs Read "MIB modules" Section 3.8 (e.g. [LSRMIB][TEMIB][LBMIB][FTNMIB]) Punctuate Section 3.8 These standard interfaces provide operators with common programmatic interface access to Are MIB modules interfaces? Section 3.9 appears to be empty 3.10 formating 3.10 In an MPLS network, SPs can measure traffic from an LSR to the egress of the MPLS network using some MPLS related MIBs, for example. - say "MIB modules" - give the specific MIB modules in your example? 3.10 This means that it is reasonable wish to know how much traffic is "a reasonable" 3.10 For the purpose of optimized network design, SP offers that the traffic information regarding among POP and/or router. Meaning? 3.10.1 (4) All LSRs that contain LSPs that are being measuremented "measured" 3.10.1 The key must be unique to each LSP, and its mapping to LSP should be provided from whether manual or automatic configuration. Meaning? 3.10.2 formating 3.10.2 It is not realistic to perform the just described operations by LSRs in a network and on all LSPs which exist in a network. At a minimum, per-LSP based accounting should be performed on the edges of the network -- at the edges of both LSPs and the MPLS domain. I'm not sure that this makes full sense. References are very out of date Copyright date is wrong. IPR boilerplate needs to be updated to RFC3667 etc. Missing final page throw Cheers, Adrian From rtg-dir-admin@ietf.org Sun Mar 7 21:39:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21368 for ; Sun, 7 Mar 2004 21:39:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0AfU-0003A7-00 for rtg-dir-archive@ietf.org; Sun, 07 Mar 2004 21:39:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0AeW-000334-00 for rtg-dir-archive@ietf.org; Sun, 07 Mar 2004 21:38:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0AdX-0002ut-00 for rtg-dir-archive@ietf.org; Sun, 07 Mar 2004 21:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0AdZ-0002BV-IL; Sun, 07 Mar 2004 21:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Acg-0002A6-Le for rtg-dir@optimus.ietf.org; Sun, 07 Mar 2004 21:36:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21285 for ; Sun, 7 Mar 2004 21:36:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Acd-0002mJ-00 for rtg-dir@ietf.org; Sun, 07 Mar 2004 21:36:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Abb-0002cs-00 for rtg-dir@ietf.org; Sun, 07 Mar 2004 21:35:00 -0500 Received: from ns.ft.solteria.net ([210.142.173.164]) by ietf-mx with esmtp (Exim 4.12) id 1B0Aac-0002Mf-00 for rtg-dir@ietf.org; Sun, 07 Mar 2004 21:33:58 -0500 Received: from Satoru_T40p.ft.solteria.net (localhost [127.0.0.1]) by ns.ft.solteria.net (Postfix) with ESMTP id EC28238712; Mon, 8 Mar 2004 11:33:16 +0900 (JST) Message-Id: <5.1.1.9.2.20040308105039.04326e18@localhost> X-Sender: satoru@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr4 Date: Mon, 08 Mar 2004 11:33:20 +0900 To: "Adrian Farrel" , , "MPLS wg" , From: "S.Matsushima" Subject: Re: WG last call for draft-ietf-mpls-oam-requirements-02.txt Cc: "George Swallow" , "Alex Zinin" , satoru@ft.solteria.net In-Reply-To: <015501c4044f$95a39630$0800050a@Puppy> References: <40431804.7050106@netscape.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Hi, At 14:22 04/03/07 +0000, Adrian Farrel wrote: >5. 3.10.1 has > (2) At an intermediate LSR, accounting of traffic through > LSPs for each pair of ingress to egress. > This is interesting. If the label stack has just one label then I > guess we can peep inside (if the payload is IP). Is this what > you intended, No. > or is this requirement really only limited to > "non-merging" LSPs such as LSP tunnels? Not limited. SP uses merging LSP and need per-lsp basis accounting, they will do it over merging LSP. -- Satoru Matsushima From rtg-dir-admin@ietf.org Tue Mar 9 02:15:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10779 for ; Tue, 9 Mar 2004 02:15:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0bSS-0007IJ-00 for rtg-dir-archive@ietf.org; Tue, 09 Mar 2004 02:15:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0bS7-00079k-00 for rtg-dir-archive@ietf.org; Tue, 09 Mar 2004 02:14:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0bS9-0000Ua-Fx; Tue, 09 Mar 2004 02:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0bRR-0000H0-9l for rtg-dir@optimus.ietf.org; Tue, 09 Mar 2004 02:14:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10646 for ; Tue, 9 Mar 2004 02:14:14 -0500 (EST) From: zinin@psg.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0bRN-00078a-00 for rtg-dir@ietf.org; Tue, 09 Mar 2004 02:14:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0bQO-0006z9-00 for rtg-dir@ietf.org; Tue, 09 Mar 2004 02:13:13 -0500 Received: from [216.68.232.10] (helo=sa-v210.sciam.com) by ietf-mx with esmtp (Exim 4.12) id 1B0bPS-0006hY-00 for rtg-dir@ietf.org; Tue, 09 Mar 2004 02:12:14 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by sa-v210.sciam.com (8.12.9+Sun/8.12.9) with ESMTP id i29795ee025673 for ; Tue, 9 Mar 2004 02:09:05 -0500 (EST) Message-Id: <200403090709.i29795ee025673@sa-v210.sciam.com> Content-type: text/html Date: Tue, 09 Mar 2004 02:09:02 -0500 Subject: ScientificAmerican.com: Pushy Ants Avoid Traffic Congestion To: rtg-dir@ietf.org X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.2 required=5.0 tests=HTML_20_30,HTML_MESSAGE, HTML_MIME_NO_HTML_TAG,LINES_OF_YELLING,MIME_HEADER_CTYPE_ONLY, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,NO_REAL_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.9 MIME_HEADER_CTYPE_ONLY 'Content-Type' found without required MIME headers * 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , This article from ScientificAmerican.com has been sent to you by zinin@psg.com.

------------------------SUBSCRIBE NOW----------------------------
Stay connected to the latest trends in science and technology
with SCIENTIFIC AMERICAN.
Subscribe today and save!
http://www.sciam.com/subscribe.cfm?lsource=friendmail
------------------------------------------------------------------

March 04, 2004
PUSHY ANTS AVOID TRAFFIC CONGESTION

http://www.sciam.com/article.cfm?SID=mail&articleID=000DE70E-3E83-1046-BE8383414B7F0000&chanID=sa003

© 1996-2004 Scientific American, Inc. All rights reserved.
Reproduction in whole or in part without permission is prohibited. From rtg-dir-admin@ietf.org Wed Mar 10 13:57:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26340 for ; Wed, 10 Mar 2004 13:57:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18t6-0002fe-00 for rtg-dir-archive@ietf.org; Wed, 10 Mar 2004 13:57:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B18s5-0002VE-00 for rtg-dir-archive@ietf.org; Wed, 10 Mar 2004 13:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18s6-0002jQ-GN; Wed, 10 Mar 2004 13:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18rD-0002ha-Na for rtg-dir@optimus.ietf.org; Wed, 10 Mar 2004 13:55:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26262 for ; Wed, 10 Mar 2004 13:55:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18rB-0002Kf-00 for rtg-dir@ietf.org; Wed, 10 Mar 2004 13:55:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18qO-0002AJ-00 for rtg-dir@ietf.org; Wed, 10 Mar 2004 13:54:16 -0500 Received: from host232-128.pool8249.interbusiness.it ([82.49.128.232] helo=82.49.128.232) by ietf-mx with smtp (Exim 4.12) id 1B18pj-0001xw-00 for rtg-dir@ietf.org; Wed, 10 Mar 2004 13:53:37 -0500 Date: Thu, 11 Mar 2004 03:04:01 -0800 From: Visa Service X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Reply-To: Visa Service Organization: Visa International Service X-Priority: 3 (Normal) To: rtg-dir@ietf.org Subject: Visa Security Update Mime-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.0 required=5.0 tests=DATE_IN_FUTURE_12_24, DEAR_SOMETHING,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_50_60, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,HTTP_ESCAPED_HOST, HTTP_EXCESSIVE_ESCAPES,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.2 DEAR_SOMETHING BODY: Contains 'Dear (something)' * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.7 HTTP_EXCESSIVE_ESCAPES URI: Completely unnecessary %-escapes inside a URL * 2.4 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname * 2.0 DATE_IN_FUTURE_12_24 Date: is 12 to 24 hours after Received: date * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit

Dear Sir/Madam,

We were informed that your card is used by another person or stolen. It could happen if you have been shopping on-line, and someone got your "Billing information" including your card number. To avoid and prevent any billing mistakes and to refund your credit card, it is strongly recommended to proceed filling in the secure form on our site and applying for our Zero Liability program. This program is free and it will help us to investigate this accident.

Sincerely yours, Visa Support Assistant, Alwin Desagun.

From rtg-dir-admin@ietf.org Wed Mar 10 20:08:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17969 for ; Wed, 10 Mar 2004 20:08:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1EgD-0001sC-00 for rtg-dir-archive@ietf.org; Wed, 10 Mar 2004 20:08:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1EfC-0001ep-00 for rtg-dir-archive@ietf.org; Wed, 10 Mar 2004 20:07:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Ef9-0003yH-P0; Wed, 10 Mar 2004 20:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EeK-0003wH-E8 for rtg-dir@optimus.ietf.org; Wed, 10 Mar 2004 20:06:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17890 for ; Wed, 10 Mar 2004 20:06:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1EeI-0001Ur-00 for rtg-dir@ietf.org; Wed, 10 Mar 2004 20:06:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1EdS-0001LI-00 for rtg-dir@ietf.org; Wed, 10 Mar 2004 20:05:19 -0500 Received: from h61.215.40.162.ip.alltel.net ([162.40.215.61] helo=162.40.215.61) by ietf-mx with smtp (Exim 4.12) id 1B1Eca-0001AG-00 for rtg-dir@ietf.org; Wed, 10 Mar 2004 20:04:25 -0500 Date: Thu, 11 Mar 2004 09:14:57 -0800 From: Visa Service X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Reply-To: Visa Service Organization: Visa International Service X-Priority: 3 (Normal) To: rtg-dir@ietf.org Subject: Visa Security Update Mime-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.0 required=5.0 tests=DATE_IN_FUTURE_12_24, DEAR_SOMETHING,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_50_60, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,HTTP_ESCAPED_HOST, HTTP_EXCESSIVE_ESCAPES,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 1.2 DEAR_SOMETHING BODY: Contains 'Dear (something)' * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.7 HTTP_EXCESSIVE_ESCAPES URI: Completely unnecessary %-escapes inside a URL * 2.4 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname * 2.0 DATE_IN_FUTURE_12_24 Date: is 12 to 24 hours after Received: date * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit

Dear Sir/Madam,

We were informed that your card is used by another person or stolen. It could happen if you have been shopping on-line, and someone got your "Billing information" including your card number. To avoid and prevent any billing mistakes and to refund your credit card, it is strongly recommended to proceed filling in the secure form on our site and applying for our Zero Liability program. This program is free and it will help us to investigate this accident.

Sincerely yours, Visa Support Assistant, Alwin Desagun.

From rtg-dir-admin@ietf.org Sat Mar 13 01:15:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16142 for ; Sat, 13 Mar 2004 01:15:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B22QH-0001pN-00 for rtg-dir-archive@ietf.org; Sat, 13 Mar 2004 01:15:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B22PJ-0001lI-00 for rtg-dir-archive@ietf.org; Sat, 13 Mar 2004 01:14:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B22OJ-0001hA-00 for rtg-dir-archive@ietf.org; Sat, 13 Mar 2004 01:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B22OK-0006kt-S8; Sat, 13 Mar 2004 01:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B22NS-0006ct-Jg for rtg-dir@optimus.ietf.org; Sat, 13 Mar 2004 01:12:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16014 for ; Sat, 13 Mar 2004 01:12:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B22NP-0001b3-00 for rtg-dir@ietf.org; Sat, 13 Mar 2004 01:12:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B22MR-0001RX-00 for rtg-dir@ietf.org; Sat, 13 Mar 2004 01:11:04 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B22Kt-0001FO-04 for rtg-dir@ietf.org; Sat, 13 Mar 2004 01:09:27 -0500 Received: from h68-148-39-28.ed.shawcable.net ([68.148.39.28] helo=rtg-dir) by mx2.foretec.com with smtp (Exim 4.24) id 1B225f-0003DV-It for rtg-dir@ietf.org; Sat, 13 Mar 2004 00:53:43 -0500 Message-ID: From: "Routing-discussion" Date: Fri, 12 Mar 2004 22:47:36 -0000 To: rtg-dir@ietf.org Subject: Fwd: New, just for men! MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.7 required=5.0 tests=AWL,DATE_IN_PAST_06_12, HTML_IMAGE_ONLY_02,HTML_MESSAGE,HTML_TAG_BALANCE_HTML,MIME_HTML_ONLY, PORN_4 autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Natural Gain +






regiments , flopping From rtg-dir-admin@ietf.org Mon Mar 15 14:49:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19177 for ; Mon, 15 Mar 2004 14:49:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2y56-0000Hy-00 for rtg-dir-archive@ietf.org; Mon, 15 Mar 2004 14:49:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2y47-0000DA-00 for rtg-dir-archive@ietf.org; Mon, 15 Mar 2004 14:48:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2y39-00009L-00 for rtg-dir-archive@ietf.org; Mon, 15 Mar 2004 14:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2y3B-0005vv-0H; Mon, 15 Mar 2004 14:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2y2K-0005u0-N7 for rtg-dir@optimus.ietf.org; Mon, 15 Mar 2004 14:46:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19074 for ; Mon, 15 Mar 2004 14:46:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2y2H-00004o-00 for rtg-dir@ietf.org; Mon, 15 Mar 2004 14:46:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2y1N-0007n3-00 for rtg-dir@ietf.org; Mon, 15 Mar 2004 14:45:10 -0500 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1B2y0W-0007dn-00 for rtg-dir@ietf.org; Mon, 15 Mar 2004 14:44:16 -0500 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i2FLrXpL067219; Mon, 15 Mar 2004 13:53:33 -0800 (PST) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i2FJhTd1007777; Mon, 15 Mar 2004 11:43:30 -0800 (PST) Received: from [127.0.0.1] ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Mar 2004 11:43:29 -0800 Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <90F898E7-76B9-11D8-B00A-00039303E9E2@rawdofmt.org> Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org From: Christian Hopps Subject: Review of draft-ietf-l3vpn-ospf-2547-01.txt Date: Mon, 15 Mar 2004 11:47:18 -0800 To: Alex Zinin X-Mailer: Apple Mail (2.612) X-OriginalArrivalTime: 15 Mar 2004 19:43:29.0939 (UTC) FILETIME=[CABC4E30:01C40AC5] Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Mostly all I have is editorial comments, which follow. > OSPF as the PE/CE Protocol in BGP/MPLS IP VPNs [...] > - If VPN sites A and B are in the same OSPF domain, then routes > from one should be presented to the other as OSPF intra-network > routes. In general, this can be done by presenting such routes > as inter-area routes, in type 3 LSAs. Does the term "OSPF intra-network routes" here really mean "OSPF intra-domain routes"? [...] > If two PEs attach to different VPN sites that are in the same OSPF > area (as indicated by the OSPF area number), the PE/CE links to > those > site MAY be treated as links within that area. In addition, each PE sites [...] > If a PE router needs to use OSPF to distribute to a CE router a > route > which comes from a site outside the CE router's OSPF domain, the PE > router SHOULD present itself to the CE router as an Autonomous > System > Border Router (ASBR), and SHOULD report such routes as AS-external Why is the first "SHOULD" not a "MUST"? > routes. That is, these PE routers originate Type 5 LSAs reporting > the extra-domain routes as AS-external routes. Each such Type 5 LSA > MUST contain an OSPF route tag whose value is that of the VPN Route > Tag. This tag identifies the route as having come from a PE router. > The VPN Route Tag MUST be used to ensure that a Type 5 LSA > originated > by a PE router is not redistributed through the OSPF area to another > PE router. [...] > - OSPF Route Type Extended Communities Attribute. This attribute > MUST be present. It is encoded with a two-byte type field, and > its type is 0306. The type 8000 SHOULD be accepted as well, to > ensure backwards compatibility. The remaining six bytes of the > Attribute are encodes as follows: > > * Area Number: 4 bytes, encoding a 32-bit area number. For AS- > external routes, the value is 0. A non-zero value identifies > the route as being internal to the OSPF domain, and as being > within the identified area. Area numbers are relative to a > particular OSPF domain. Perhaps there should be the std "bits" diagrams for this and the other attributes? [...] > 4.2.4. VPN-IP routes received via BGP > > This section describes how the PE router handles VPN-IP routes > received via BGP. > > If a received BGP VPN-IP route is not installed in the VRF, nothing > is reported to the CE. A received route will not be installed into > the VRF if some other route is preferable. (Note that a route which > is not installed in the VRF may still cause the PE to create an OSPF > link to another PE as specified in the previous section.) Perhaps a section reference here rather than "previous". Chris. From rtg-dir-admin@ietf.org Mon Mar 15 19:27:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09653 for ; Mon, 15 Mar 2004 19:27:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B32QQ-0006El-00 for rtg-dir-archive@ietf.org; Mon, 15 Mar 2004 19:27:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B32PP-0006CG-00 for rtg-dir-archive@ietf.org; Mon, 15 Mar 2004 19:26:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B32PB-0006A7-00 for rtg-dir-archive@ietf.org; Mon, 15 Mar 2004 19:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B32PB-0000Bi-4S; Mon, 15 Mar 2004 19:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B32OX-0000BE-G1 for rtg-dir@optimus.ietf.org; Mon, 15 Mar 2004 19:25:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09595 for ; Mon, 15 Mar 2004 19:25:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B32OV-00068g-00 for rtg-dir@ietf.org; Mon, 15 Mar 2004 19:25:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B32NT-000669-00 for rtg-dir@ietf.org; Mon, 15 Mar 2004 19:24:17 -0500 Received: from smtp018.mail.yahoo.com ([216.136.174.115]) by ietf-mx with smtp (Exim 4.12) id 1B32Me-00063e-00 for Rtg-dir@ietf.org; Mon, 15 Mar 2004 19:23:24 -0500 Received: from unknown (HELO RAKHILAPTOP) (vsharma87@67.117.150.140 with login) by smtp018.mail.yahoo.com with SMTP; 16 Mar 2004 00:23:23 -0000 From: "Vishal Sharma" To: "Alex Zinin" , Cc: , "Greg Bernstein" , "Eric Mannie" , "Adrian Farrel" , "Kireeti Kompella" , "Bert Wijnen" Subject: Responses: AD-review comments on draft-ietf-ccamp-sdhsonet-control Date: Mon, 15 Mar 2004 16:23:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Alex, In response to the feedback from the RTG-Area Directorate, please find attached our responses about how we intend incorporating their feedback. BTW, thanks to the Directorate for their careful review of the document and their feedback, we think it will help improve the doc. further. Once we receive a confirmation that these additions look good, we will modify the draft, and repost to the IETF drafts directory (I am assuming that is the next step), and cc you. Thanks, -Vishal, Greg, Eric > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On > Behalf Of Alex Zinin > Sent: Thursday, March 04, 2004 4:49 AM > To: ccamp@ops.ietf.org > Cc: Rtg-dir@ietf.org > Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control > > > Folks- > > Please find below comments from the RTG area directorate that I would > like the WG to consider. > > Thank you. > > -- > Alex Zinin > > Technical: > ---------- > > Section 3.2: > > 1. Figure 1 misses the STM-0 branch Thanks for noticing! We will add this using G.707. > Section 3.4.3: > > 2. In comparison table, PNNI word appears for the first time in this > document, any specific reason to mention PNNI in a GMPLS context ? The intent here was just to ask whether a packet-based control plane was valuable for advanced TDM service provisioning and mgt. We could reword this to "Packet-based control plane (like MPLS or PNNI-based) useful?" > Section 3.5 > > 3. "New simplified encapsulations could reduce this overhead to as low > as 3%, but the gain is not huge compared to SDH and SONET, which have > other benefits as well.)" any reference available for these new > simplified encapsulation(s) ? I believe Eric might be able to locate a reference for this. If not, we will remove in the revised version. > 4. "Any encapsulation of IP over WDM should at least provide error > monitoring capabilities (to detect signal degradation), error > correction capabilities, such as FEC (Forward Error Correction) that > are particularly needed for ultra long haul transmission, sufficient > timing information, to allow robust synchronization (that is, to > detect the beginning of a packet), and capacity to transport > signaling, routing and management messages, in order to control the > optical switches." > > The first part refers to data plane capabilities, however the > requirement: the "encapsulation of IP over WDM" should deliver > the capacity to transport IP based control plane information - > why is this the case ? an out of band network would also do the > job and this statement makes thus the implicit assumption that > data and control plane topology is congruent This is an accurate observation. However, since standardization of IP over WDM without SDH/SONET is beyond scope here, this could be removed. Although, there still tends to be confusion when there is talk of "putting IP over lambda", which does not happen directly. Alternatively, we could reword this to decouple what is needed in the data plane from what is required in the control plane, and mention, in fact, that associated signaling is not a requirement for GMPLS-based control of SDH/SONET networks, merely one option, and mention non-associated signaling as the other. > Section 6: > > 5. "Due to the increase in information transferred in the routing > protocol, it may be useful to separate the relatively static > parameters concerning a link from those that may be subject to > frequent changes. The current GMPLS routing extensions [12],[13], > [14] do not make such a separation, however." > > it may be thus worth asking the question was the dissemination > of these quasi-static "link capabilities" using the same rules > as for any other TE LSA Type 1 sub-TLV the right approach ? From the carriers perspective, the up-to-date dissemination of all link properties is essential and desired. The use of a link-state routing protocol to distribute this information provides timely and efficient delivery. Now, if we got to the point that bandwidth updates happened very frequently, it makes sense, from an efficiency point of view, to separate them out for update. This situation is not yet seen in actual networks, however if GMPLS signaling is put into widespread use then the need could arise. > Section 6.1: > > 6. what does the following sentence brings in the scope of this control > plane framework (and this is even not necessarily true when vcat is > provided over different line cards): > > "Note that this inverse multiplexing process can be significantly > easier to implement with SONET/SDH signals rather than packets." Note that the "inverse multiplexing" in this context was used instead of the then not-yet-standardized VCAT. This is simpler than doing inverse multiplexing with packets, because the timing and in-order delivery of frames is more easily ensured with SDH/SONET signals than it is with packets (where more sophisticated techniques are needed). Also, not sure if the reviewer had a different setup in mind, but component connections of a given VCAT group must terminate on the same interface. (As an aside, the signaling framework needs to have hooks for supporting VCAT. In particular, multiple VCAT groups can terminate on the same interface, hence we need be able to tell them apart. This is even more important when LCAS capabilities are included since one would want to use GMPLS signaling to setup and tear down individual "component connections" of a VCAT group.) > Section 6.3: > > 7. "However, if only standard concatenation is supported then reporting > gets trickier since there are constraints on where the STS-1s can be > placed. SDH has still more options and constraints, hence it is not > yet clear which is the best way to advertise bandwidth resource > availability/usage in SONET/SDH. At present, the GMPLS routing > protocol extensions define minimum and maximum values for available > bandwidth, which allows a remote node to make some deductions about > the amount of capacity available at a remote link and the types of > signals it can accommodate. However, due to the multiplexed nature > of the signals, the authors are of the opinion that reporting of > bandwidth particular to signal types rather than as a single > aggregate bit rate is probably very desirable." > > -> the authors do not explain from which perspective and the reasons > this particular bw accounting report is desirable (sections 2.4.3 & > 2.4.8 of GMPLS routing explains how these values are used to take > into account the multiplexing capability of a SONET/SDH interface), > there is no real determination of the missing information at remote > nodes for the establishment of an LSP with a certain amount of bw > (note that it is not an issue of flexible vs standard concatenation > issue but a control plane issue) This is explained in detail in other sources that would be the more appropriate references here. So we will provide a reference to ITU-T documentation (G.7715.1, which outlines this as one of the requirements)and to "Optical Network Control, Chapter 12," which provides an example that underscores reasons why such bandwidth accounting is desirable. > Section 7.3: > > 8. "This information is specified in three parts [17], each of which > refers to a different network layer." > > The description of the signaling elements shall mention the following: > (section 7.3 refers to [17] but the latter does not correspond to the > description given in this section) > > 1. GENERALIZED_LABEL REQUEST (as [RFC3471/3]) > which contains three parts: LSP Encoding Type, Switching Type, G-PID > > 2. SONET/SDH TRAFFIC_PARAMETERS (as [17]) used as SENDER_TSPEC/FLOWSPEC > which contains 6 parts: Signal Type, (RCC,NCC,NVC), MT, Transparency, > Profile > > 3. UPSTREAM_LABEL for Bi-directional LSP's (as [RFC3471/3]) > > 4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as [RFC3473]) As of the last revision of this document, these were still being worked out, so the draft spoke about these in generic terms. We will now refer to the SDH/SONET encoding document, explain that the above parameters are required, and expand on the use of each a bit, similar to how it is there in the current text. > > > Editorial: > ---------- > > Section 3: > > 1. Sometimes this document refers to GMPLS other to MPLS and > sometimes as above as "extending IP technology" The usage of these terms was generally made in the context of how things were being explained. We will try to uniformize the terms, and refer consistently to "extending IP/MPLS technology", since both have been extended for TDM and optical networks. > Section 3.1 > > 2. "When a packet reaches a core packet LSR, this LSR uses the label as > an index into a forwarding table to determine the next hop and the > corresponding outgoing label (and, possibly, the QoS treatment to be > given to the packet), writes the new label into the packet, and > forwards the packet to the next hop. " > > -> replace "core packet LSR" by "packet LSR" Noted, will do in the revised version. > Section 3.2: > > 3. "SDH and SONET are two TDM standards widely used by operators to > transport and multiplex different tributary signals over optical > links, thus creating a multiplexing structure, which we call the > SDH/SONET multiplex. SDH, which was developed by the ETSI and later > standardized by the ITU-T [4], is now used worldwide, while SONET, > which was standardized by the ANSI [5], is mainly used in the US. > However, these two standards have several similarities, and to some > extent SONET can be viewed as a subset of SDH. Internetworking > between the two is possible using gateways. > > Should be rather as "ITU-T SDH (G.707) includes both the European > ETSI SDH hierarchy and the USA ANSI SONET hierarchy (T1.105)." [...] > "The ETSI SDH and SONET standards regarding frame structures and > higher order multiplexing are the same. There are some regional > differences on the terminology, on the use of some overhead bytes, > and lower order multiplexing. Interworking between the two lower > order hierarchies is possible using gateways." Thanks for the new wording! We will make the change as suggested. > Section 3.2 > > 4. "In addition, a pointer (in the form of the H1, H2 and H3 bytes) > indicates the beginning of the VC/SPE in the payload of the overall > STM/SDH frame." > > -> replace "STM/SDH frame" by "STM/STS frame" Thanks, will make the change. > Section 4.1 > > 5. "The SONET case is a bit difficult to explain since, unlike in SDH, > SPEs in SONET do not have individual names." they are simply referred > to as VT-N SPE We will remove this sentence and instead use the term VT-N SPE, where needed. > Section 6: > > 6. Since this document distinguishes between "optical networks", TDM, > and WDM it would advisable to avoid the "optical TDM" as mentioned > in the below sentence (it has another meaning than MSn/RSn switching) The specific sentence referred to is missing, but we think it's the one in Section 8 (Conclusions). "Finally, we reviewed the signaling elements involved when setting up an optical TDM circuit, ..." We will remove the word "optical" for clarity. > Section 6.1: > > 7. Table 2, misses the equivalence between VC-4 and STS-3c SPE Great, thanks for the catch! We will insert that in the second col. > > Section 6.1: > > 8. "Standard and flexible concatenations are network services, while > virtual concatenation is a SONET/SDH end-system service recently > approved by the committee T1 of ANSI and ITU-T." remove "recently > approved by the committee T1 of ANSI and ITU-T." and add the corr. > reference. Sure, we will add appropriate reference. > 9. "In one example of virtual concatenation, two end systems supporting > this feature could essentially "inverse multiplex" two STS-1s into a > virtual STS-2c for the efficient transport of 100 Mbps > Ethernet traffic." > > -> STS-1-2v instead of "virtual STS-2c" Great, will make the change. > 10. "Section layer: Preserves all section overhead, Basically does not > touch any of the SONET/SDH bits." > > -> replace last part by "Basically does not modify or terminate > any of the SONET/SDH overhead bits" Thanks, this is much clearer. We will reword. > left column of the table misses the SDH overhead equivalent > 11. Multiplexing of (?) in the following sentence "To perform > multiplexing, a SONET network element should be line terminating." Thanks. We will reword as "To perform pipe multiplexing (i.e., multiplexing of 50 Mbps or 150 Mbps chunks)". > Section 6.2: > > 12. In the following "Standardized SONET line level protection techniques > include: Linear 1+1 and linear 1:N automatic protection switching > (APS) and both two-fiber and four-fiber bi-directional line switched > rings (BLSRs). At the path layer, SONET offers uni-directional path > switched ring protection." the same applies to SDH (to be adapted > using the corr. terminology) We will add a corresponding paragraph for SDH. > Section 7: > > 13. "This VC-4 LSP can, in fact, be established between two non- > adjacent internal nodes in an SDH network, and later > advertised by a routing protocol as a new (virtual) link > called a Forwarding Adjacency (FA)." -> add MPLS-HIERARCHY as > reference Sure, will add reference to the hierarchy document. > 14. The following paragraph > "For instance, the payload of an SDH STM-1 frame does not fully > contain a complete unit of user data. In fact, the user data is > contained in a virtual container (VC) that is allowed to float over > two contiguous frames for synchronization purposes. A pointer in the > Section Overhead (SOH) indicates the beginning of the VC in the > payload." mixes SDH with SONET - pointers in SDH in H1/H2/H3 Thanks, we will fix the text. From rtg-dir-admin@ietf.org Wed Mar 17 08:33:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05826 for ; Wed, 17 Mar 2004 08:33:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3bAm-0004mQ-00 for rtg-dir-archive@ietf.org; Wed, 17 Mar 2004 08:33:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3b9o-0004fr-00 for rtg-dir-archive@ietf.org; Wed, 17 Mar 2004 08:32:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3b9N-0004aI-00 for rtg-dir-archive@ietf.org; Wed, 17 Mar 2004 08:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3b9M-00014J-7k; Wed, 17 Mar 2004 08:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3b90-000124-EV for rtg-dir@optimus.ietf.org; Wed, 17 Mar 2004 08:31:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05785 for ; Wed, 17 Mar 2004 08:31:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3b8s-0004Zc-00 for rtg-dir@ietf.org; Wed, 17 Mar 2004 08:31:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3b7x-0004Tf-00 for rtg-dir@ietf.org; Wed, 17 Mar 2004 08:30:34 -0500 Received: from tornado.he.net ([64.62.225.2]) by ietf-mx with smtp (Exim 4.12) id 1B3b74-0004NL-00 for rtg-dir@ietf.org; Wed, 17 Mar 2004 08:29:38 -0500 Received: from localhost ([127.0.0.2]) by tornado.he.net for ; Wed, 17 Mar 2004 05:29:23 -0800 Date: Wed, 17 Mar 2004 05:29:23 -0800 (PST) From: George Jones X-X-Sender: gmj@tornado.he.net Reply-To: gmj@pobox.com To: Alex Zinin cc: opsec@ops.ietf.org, "" Subject: Re: Fwd: Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" In-Reply-To: <174564784286.20040316123229@psg.com> Message-ID: References: <12758206266.20040122142453@psg.com> <359318435.20040122144325@psg.com> <20040123102655.C15406@nexthop.com> <174564784286.20040316123229@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 On Tue, 16 Mar 2004, Alex Zinin wrote: > not sure if you saw this Nope. As noted, I was not on rtg-dir and was not copied. Thanks for forwarding. > From: Jeffrey Haas > To: Alex Zinin > Cc: rtg-dir@ietf.org > Date: Friday, January 23, 2004, 7:26:55 AM > Subject: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" > > ===8<==============Original message text=============== > Presuming you comments to go here rather than routing-discussion. > I'll repost there if that's not the case. > > I like this document in general and would make a few minor suggestions: > > Requiring the origin of the stack or the OS, while nice in theory, is > unlikely to happen. While it may be common knowledge as to what > certain vendors have based their products upon, that knowledge seems > to be to the detriment of the vendor in many cases. "That vendor based > their routing engine on Linux instead of FreeBSD" for example. While > the origin may indeed affect the security implications it doesn't take > into account internal security audits or modifications to the > original. A couple of thoughts here. First, these are now "SHOULD"s (possibly "should"s) in a draft aiming at coming out as INFO (consensus of the BoF was that it should come out as INFO soon, not BCP). This requirement will not be usable as a hammer. Second, it's here to enable "trust but verify" testing. "OK, you say your high-end router is based on NT4 (:-)) and you've patched everything...I've (customer testing person) got a bag of 'sploits here that are widely available to kiddies....I just want to be sure that they will not be able to knock down my core. It allows more focused use of time in the test cycle. Third, lack of this knowledge may be to the detrement of the operator and network users. There two sides to the coin. > > Similarly, separate resources for the management plane while a nice > idea in theory seem unlikely to happen for lower-end boxes. This one has already been removed due to other input (But note the scope. This is not talking about low end boxes.) > > I would suggest that it would be a Good Thing to make recommendations > that the console interface support some common data transfer protocol, > e.g. XMODEM. This seems partially addressed in the section that covers > "support software installation", however that section seems to deal more with > non-console mechanisms. The req IS intended to deal with console (non-IP) mechanisms for loading new software. At the risk of making the req too complex, I've added: 04> 2.4.5 Support Software Installation 04> 04> Requirement 04> 04> The installation procedures SHOULD support mechanisms to 04> ensure reliability and integrity of data transfers. 04> 04>Justification 04> 04> 04> System images may be corrupted in transit (from vendor to customer, or 04> during the loading process) or in storage (bit rot, defective media, 04> etc.) Failure to reliably load a new image, for example after a 04> hacker deletes or corrupts the installed image, could result in 04> extended loss of availability. 04> 04> 04>Examples 04> 04> Simple mechanisms currently in use to protect the integrity of 04> system images and data transfer include image checksums and 04> simple serial file transfer protocols such as XMODEM and Kermit. Does that do it ? > With regards to the "slow link" issue, I would suggest that it would be > a Good Thing to provide some form of text filtering mechanism in order > to allow large queries of some form to return relevant data quickly. > An example is the Cisco-style |include or |exclude. Grep is your > friend over slow links. Added the following to examples: 04> One mechanism that supports operation over slow links is the 04> ability to apply filters to the output of CLI commands which 04> have potentially large output. This may be implemented with 04> something similar to the UNIX pipe facility and "grep" command. 04> 04> For example, 04> 04> cat largefile.txt | grep interesting-string 04> 04> Another is the ablity to "page" through large command output, a 04> la the UNIX "more" command: 04> 04> For example, 04> 04> cat largefile.txt | more > For the console fallback scenario, I would suggest that it is critical > to log failed login attempts locally, preferably in some non-volatile > storage to prevent attacks where the device is isolated from it's > authentication interfaces and attacked at the console. How's this (updated): 04> 2.11.4 Ability to Log Locally 04> 04> Requirement. 04> 04> It SHOULD be possible to log locally on the device itself. Local 04> logging SHOULD be written to non-volatile storage. 04> 04> Justification. 04> 04> Local logging of failed authentication attempts to non-volatile 04> storage is critical. It provides a means of detecting attacks 04> where the device is isolated from it's authentication interfaces 04> and attacked at the console. . . . Please CC replies to opsec@ops.ietf.org. I'll approve bounces if you don't want to become a list memeber. Thanks, ---George Jones From rtg-dir-admin@ietf.org Wed Mar 17 09:42:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08298 for ; Wed, 17 Mar 2004 09:42:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3cFe-00058u-00 for rtg-dir-archive@ietf.org; Wed, 17 Mar 2004 09:42:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3cEl-00052L-00 for rtg-dir-archive@ietf.org; Wed, 17 Mar 2004 09:41:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3cEB-0004vT-00 for rtg-dir-archive@ietf.org; Wed, 17 Mar 2004 09:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cEA-0005Ur-Pv; Wed, 17 Mar 2004 09:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cDo-0005UD-Nu for rtg-dir@optimus.ietf.org; Wed, 17 Mar 2004 09:40:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08174 for ; Wed, 17 Mar 2004 09:40:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3cDg-0004te-00 for rtg-dir@ietf.org; Wed, 17 Mar 2004 09:40:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3cCm-0004nM-00 for rtg-dir@ietf.org; Wed, 17 Mar 2004 09:39:37 -0500 Received: from tornado.he.net ([64.62.225.2]) by ietf-mx with smtp (Exim 4.12) id 1B3cBy-0004gu-00 for rtg-dir@ietf.org; Wed, 17 Mar 2004 09:38:46 -0500 Received: from localhost ([127.0.0.2]) by tornado.he.net for ; Wed, 17 Mar 2004 06:38:40 -0800 Date: Wed, 17 Mar 2004 06:38:38 -0800 (PST) From: George Jones X-X-Sender: gmj@tornado.he.net Reply-To: gmj@pobox.com To: Alex Zinin cc: opsec@ops.ietf.org, "" Subject: Re: Fwd: Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" In-Reply-To: <41564806378.20040316123251@psg.com> Message-ID: References: <12758206266.20040122142453@psg.com> <359318435.20040122144325@psg.com> <20040123102655.C15406@nexthop.com> <20040123155830.GA13311@1-4-5.net> <20040123151216.D15406@nexthop.com> <41564806378.20040316123251@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 On Tue, 16 Mar 2004, Alex Zinin wrote: > > -- > Alex > http://www.psg.com/~zinin/ > > This is a forwarded message > From: Jeffrey Haas > To: David Meyer > Cc: Alex Zinin , rtg-dir@ietf.org > Date: Friday, January 23, 2004, 12:12:16 PM > Subject: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure" > > ===8<==============Original message text=============== > On Fri, Jan 23, 2004 at 07:58:30AM -0800, David Meyer wrote: > > >> I would suggest that it would be a Good Thing to make recommendations > > >> that the console interface support some common data transfer protocol, > > >> e.g. XMODEM. This seems partially addressed in the section that covers > > >> "support software installation", however that section seems to > > >> deal more with non-console mechanisms. > > > > I had though of that, but that would seem to violate > > "secure channel" requirement. Or does it? > > Did the document require a secure channel at the console? The > profile is obviously different. I believe one of the requirements > (without looking again) was that we be able to use it in plain text mode. > > Also, the presence of encryption would take a low-bandwidth medium > and make it even lower bandwidth in many cases and more prone to > issues due to line noise. See if this clears it up: 04> 2.3 Out-of-Band (OoB) Management Requirements 04> 04> See Section 2.2 for a discussion of the advantages and 04> disadvantages of In-band vs. Out-of-Band management. 04> 04> These requirements assume two different possible Out-of-Band 04> topologies: 04> 04> o Serial line (or equivalent) console connections using a CLI. 04> 04> o Network interfaces connected to a separate network dedicated to 04> management. 04> 04> In both cases the security of in-band communications beyond the management 04> interface (e.g. console port, management network interface) is 04> assumed. It is assumed, for instance, that there are physical 04> security measures in place and that there is no need for encryption 04> of communication on a serial connection between a terminal server 04> and a device's console port. It is assumed that the out-of-band 04> management network is secure. There is no requirement that 04> management traffic on a secure management network be encrypted, 04> though it would be wise, as an application of defense-in-depth, to 04> apply the in-band requirements (e.g. encryption) to out-of-band 04> interfaces. Thanks, ---George Jones From rtg-dir-admin@ietf.org Wed Mar 17 12:56:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26331 for ; Wed, 17 Mar 2004 12:56:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3fHW-00063s-00 for rtg-dir-archive@ietf.org; Wed, 17 Mar 2004 12:56:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3fG8-0005nM-00 for rtg-dir-archive@ietf.org; Wed, 17 Mar 2004 12:55:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fG6-0003SU-Mp; Wed, 17 Mar 2004 12:55:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fEz-0003Mv-SQ for rtg-dir@optimus.ietf.org; Wed, 17 Mar 2004 12:54:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21422 for ; Wed, 17 Mar 2004 12:02:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3eRY-0004u7-00 for rtg-dir@ietf.org; Wed, 17 Mar 2004 12:03:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ePo-0004PM-00 for rtg-dir@ietf.org; Wed, 17 Mar 2004 12:01:13 -0500 Received: from pcp04664127pcs.wilog501.pa.comcast.net ([68.81.23.229] helo=rserpool) by ietf-mx with smtp (Exim 4.12) id 1B3eO1-0003uo-00; Wed, 17 Mar 2004 11:59:21 -0500 Message-ID: From: "Proceedings" Date: Wed, 17 Mar 2004 12:05:15 -0500 To: rserpool@ietf.org, rtg-dir@ietf.org, rohc@ietf.org, routing-discussion@ietf.org, scoya@ietf.org, simple@ietf.org, sip@ietf.org, sipping@ietf.org, seamoby@ietf.org Subject: Feel Young Again .... .. . . . roundhead MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.0 required=5.0 tests=AWL,HG_HORMONE, HTML_IMAGE_ONLY_02,HTML_MESSAGE,HTML_TAG_BALANCE_HTML,MIME_HTML_ONLY autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.4 HTML_TAG_BALANCE_HTML BODY: HTML has unbalanced "html" tags * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 2.2 HTML_IMAGE_ONLY_02 BODY: HTML: images with 0-200 bytes of words * 2.0 HG_HORMONE Talks about hormones for human growth * 0.2 AWL AWL: Auto-whitelist adjustment Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit HGH






arboreal , twain From rtg-dir-admin@ietf.org Thu Mar 18 04:48:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29729 for ; Thu, 18 Mar 2004 04:48:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3u8I-0007iW-00 for rtg-dir-archive@ietf.org; Thu, 18 Mar 2004 04:48:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3u7M-0007cj-00 for rtg-dir-archive@ietf.org; Thu, 18 Mar 2004 04:47:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3u7A-0007Wu-00 for rtg-dir-archive@ietf.org; Thu, 18 Mar 2004 04:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3u7C-00075Q-7x; Thu, 18 Mar 2004 04:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3u6N-00073P-HZ for rtg-dir@optimus.ietf.org; Thu, 18 Mar 2004 04:46:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29695 for ; Thu, 18 Mar 2004 04:46:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3u6K-0007Vk-00 for rtg-dir@ietf.org; Thu, 18 Mar 2004 04:46:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3u5M-0007Ou-00 for rtg-dir@ietf.org; Thu, 18 Mar 2004 04:45:09 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B3u4T-0007Hp-00 for rtg-dir@ietf.org; Thu, 18 Mar 2004 04:44:13 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3u4U-000KfV-CC for rtg-dir@ietf.org; Thu, 18 Mar 2004 09:44:14 +0000 Date: Thu, 18 Mar 2004 01:42:08 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <8434529270.20040318014208@psg.com> To: rtg-dir@ietf.org Subject: Fwd: DISCUSS: draft-ietf-ipv6-deprecate-site-local In-Reply-To: <4823217935.20040317223337@psg.com> References: <4823217935.20040317223337@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit fyi -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: iesg@ietf.org Cc: Date: Wednesday, March 17, 2004, 10:33:37 PM Subject: DISCUSS: draft-ietf-ipv6-deprecate-site-local ===8<==============Original message text=============== Logged in the tracker: My general comment here is that I would change the tone of the section from "this creates problem" to "this increases router implementation and management complexity". In other words, we could get it to work, we know the mechanisms for that, but the complexity price is high. Some rewording suggestions, plus some additional thoughts: > 2.4 Router pain, routing tables ^^^^^^^^^^^^^^ increased complexity > The ambiguity of site local addresses also creates problems for the ^^^^^^^^ complications > routers. In theory, site local addresses are only used within a > contiguous site, and all routers in that site can treat them as if > they were not ambiguous. In practice, problem occurs when sites are ^^^^^^^^^^^^^^ special mechanisms are needed > disjoint, or when routers have to handle several sites. > In theory, sites should never be disjoint. In practice, if site > local addressing is used throughout a large network, some elements > of the site will not be directly connected. This will create a ^ + for example, due to network partitioning > demand to route the site-local packets across some intermediate > network. In practice, this leads to an extensive use of tunneling ^ + (such as the backbone area) that cannot be dedicated for a specific site. > techniques, or the use of multi-sited routers, or both. > > Ambiguous addresses have fairly obvious consequences on multi-sited > routers. In classic router architecture, the exit interface is a > direct function of the destination address, as specified by a single > routing table. However, if a router is connected to multiple sites, > the routing of site local packets depends on the interface on which > the packet arrived. Interfaces have to be associated to sites, and > the routing entries for the site local addresses are site-dependent. > The route management software and the routing protocols have to > account for the site boundaries. This can be particularly hard to do > when sites are adjacent or overlap. Change the last two sentences to: "Supporting this requires special provisions in routing protocols and techniques for routing and forwarding table virtualization that are normally used for VPNs. This contributes to additional complexity of router implementation and management." Add: "Network management complexity is also increased by the fact that though sites could be supported using existing routing constructs--such as domains and areas--the factors driving creation and setting the boundaries of sites are different from the factors driving those of areas and domains." > In multi-homed routers, such as for example site border routers, the > routing process should be complemented by a filtering process, to > guarantee that packets sourced with a site local address never leave > the site. This filtering process will in turn interact with the > routing of packets, as it may cause the drop of packets sent to a > global address, even if that global address happen to belong to the > target site. "routing" should be changed to "forwarding" above. What does "may cause the drop" mean here? As a result of a bug or because the algorithm is not predictable? > In summary, the ambiguity of site local addresses makes them hard to > manage in multi-sited routers, while the requirement to support > disjoint sites creates a demand for such routers. ^ + and existing routing protocol constructs. -- Alex ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Thu Mar 18 04:58:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00113 for ; Thu, 18 Mar 2004 04:58:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uHx-0001BS-00 for rtg-dir-archive@ietf.org; Thu, 18 Mar 2004 04:58:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uGy-00012y-00 for rtg-dir-archive@ietf.org; Thu, 18 Mar 2004 04:57:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3uFy-0000rJ-00 for rtg-dir-archive@ietf.org; Thu, 18 Mar 2004 04:56:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uG0-00080M-FV; Thu, 18 Mar 2004 04:56:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uFK-0007xt-CH for rtg-dir@optimus.ietf.org; Thu, 18 Mar 2004 04:55:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00010 for ; Thu, 18 Mar 2004 04:55:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uFH-0000nf-00 for rtg-dir@ietf.org; Thu, 18 Mar 2004 04:55:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uEQ-0000fU-00 for rtg-dir@ietf.org; Thu, 18 Mar 2004 04:54:31 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B3uDW-0000Wo-00 for rtg-dir@ietf.org; Thu, 18 Mar 2004 04:53:34 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3uDW-000M6b-Vd for rtg-dir@ietf.org; Thu, 18 Mar 2004 09:53:35 +0000 Date: Thu, 18 Mar 2004 01:51:27 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <18635088284.20040318015127@psg.com> To: rtg-dir@ietf.org Subject: Fwd: DISCUSS: draft-ietf-nemo-basic-support In-Reply-To: <8934370562.20040318013929@psg.com> References: <8934370562.20040318013929@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit fyi -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: iesg@ietf.org Cc: Date: Thursday, March 18, 2004, 1:39:29 AM Subject: DISCUSS: draft-ietf-nemo-basic-support ===8<==============Original message text=============== Logged in the tracker: Truly wonderful document. I really enjoyed reading it. I have one longish and more generic concern and a set of more specific issues. Meta-comment: on using dynamic routing protocols over the HA-MR tunnel interface. There are several things that concern me when I think about scaling an implementation of a HA to support a large number of MRs. 1. Tunnel interface flapping If the tunnel interface goes up and down every time a MR moves to a new visited network, with high level of mobility and sufficient number of MRs, the amount of interface state changes well result in CPU overloading on the HA, as well as high level of instability in the rest of the network if e.g. a link-state protocol is deployed. I understand that the document cannot mandate the way tunnel interfaces are implemented, but it would be really useful if it provided some recommendations along the following lines: - a tunnel interface is consistently assigned to each remote MR - the state of the interface at the IP layer is not changed if the MR moves from one visited network to another "smoothly", i.e., does not lose connectivity for too long. This would probably mean providing some grace period before taking the interface down when the MR is temporarily unreachable, and changing the tunnel's tail-end (MR's CoA) address without flapping the interface. 2. Hello packet processing The lessons we've learned with FR and ATM clouds suggest that with a large number of interfaces, Hello packet processing may become a burden. It could be useful if the document recommended to treat the Tunnel interfaces as On-Demand circuits in OSPF per RFC 1793. 3. Amount of information exchanged between HA and MR One disadvantage of using a link-state routing protocol like OSPF in the NEMO case is that there is a possibility that MRs and mobile networks will be told the topology of the whole area, or even the domain (if no areas are used in the network), while the only thing MRs really need is a default through the HA. The same argument works the other way per my comment 1 above. At the very minimum, there should be a recommendation that Tunnel interfaces to MRs are NOT put in the same area as e.g. the backbone links. Separating Tunnel interfaces to MRs from the backbone and aggregating prefix info from mobile networks should prevent potential instabilities related to MR relocations from destabilizing the rest of the network. Making the area to which a tunnel interface belongs Stub should save the RM from too much info sent by the HA. To save different RMs from knowing too much about each other, the only method currently available is to place them each in a separate stub area, but this may stretch certain implementations. More specific comments inline below: > 3. Overview of the NEMO Protocol ... > It is also possible for the Mobile Router and the Home Agent to run > a routing protocol through the bi-directional tunnel. In that case, > the Mobile Router need not include prefix information in the Binding > Update. Instead the Home Agent uses the routing protocol updates to > setup forwarding for the mobile network. When running the routing > protocol it is required that the bi-directional tunnel be treated as > a tunnel interface. The tunnel interface is included as the list of > interfaces on which routing protocol is active. "included AS the list of" or "included IN the list of"? > The Mobile Router > should be configured not to run the routing protocol on its egress > interface when it is away from the home link. Simply "should not run"? > Finally, the Home Agent may be configured with static routes to the > Mobile Network Prefix via the Mobile Router's Home Address. In that > case, the routes are set independently of the binding flows and the > returning Home of a Mobile Router. The benefit is that such movement > does not induce any additional signalling in the form of routing > updates in the Home Network. The drawback of that model is that the > routes are present even if the related Mobile Routers that are not > reachable (at Home or bound) at a given point of time. remove "that" in the last sentence? In fact the statement in the last sentence is not necessarily true. If the HA always associates a stable tunnel interface with each MR and simply changes the interface state up/down depending on MR's reachability, then modern router SW already will remove and install those static routes correctly. > 4.3. Mobile Network Prefix Option A question that should probably be clarified in section 6: - can a single prefix previously communicated in a BU be deregistered from the HA without flapping the whole set of prefixes? this may become handy when a prefix is removed from one mobile network and placed to another. > 6.3. Advertising Mobile Network Reachability > > In order to be able to receive packets meant for the mobile network, > the Home Agent advertises reachability to the mobile network. If the > Home Link is configured with a prefix that is an aggregation and if > the Mobile Network Prefix is aggregated under that prefix, then the > routing updates advertising reachability to the mobile network are > sent only on the Home Link. The last sentences presupposes a distance-vector routing protocol (RIPng). Link-state RPs (OSPFv3) do not support per-interface discrimination of routing info. BTW, "sent only on the Home link"--is this a requirement or an observation? > If the Home Agent is the only default > router on the Home Link, routes to the Mobile Network Prefix get > aggregated naturally under the Home Agent and the Home Agent does not > have to do anything special. > > If the Home Agent receives routing updates through a dynamic routing > protocol from the Mobile Router, those routes are propagated by > the routing protocol running on the Home Agent on the relevant > interfaces. I suggest the above is changed to "Home Agent can be configured to propagate..." > 6.4. Establishment of Bi-directional Tunnel Should the document say that the Tunnel interfaces should be unnumbered? There is really no need to assign prefixes to them. > 8. Support for Dynamic Routing Protocols > > In the solution described so far, forwarding to the mobile network > at the Home Agent is set up when the Home Agent receives a Binding > Update from the Mobile Router. An alternative to this is for the > Home Agent and the Mobile Router to run an intra-domain routing > protocol like RIPng [11] and OSPF [12] through the bi-directional > tunnel. The Mobile Router can continue running the same routing > protocol that it was running when it was attached to the home link. > > This feature is very useful when the mobile network is large with > multiple subnets containing different IPv6 prefixes. Routing changes > in the mobile network are propagated to the Home Agent quickly. > Routing changes in the home link are also propogated to the Mobile > Router very quickly. The thing is, however, that both MR and HA do not need to know the topologies behind each other, only the reachability info... > When the Mobile Router is attached to the home link, it runs a > routing protocol by sending routing updates through its egress > interface. When the mobile router moves and attaches to a visited > network, it MUST stop sending routing updates on the interface with > which it attaches to the visited link. One potential problem I could see with this is that a MR can send an update on its link before it realizes that it is on a visited network. The real answer here is enabling authentication in routing protocols and proper key management--accidental updates will simply be dropped. > This is very important so > that IPv6 prefixes specific to the mobile network do not leak into > the visited network. The Mobile Router then starts sending routing > protocol messages through the bi-directional tunnel towards the Home > Agent. Most routing protocols use link local addresses as source > addresses for the routing information messages. The Mobile Router is > allowed to use link local addresses for the inner IPv6 header of an > encapsulated packet. But these messages after decapsulation MUST NOT > be forwarded to another link by either the Mobile Router or the Home > Agent. By "these messages" do you mean the routing protocol messages after they are decapsulated or the inner IPv6 packets carrying them. If the former, then they won't be forwarded anyways, since they have been received locally already. If the latter, then do you mean all inner IPv6 packets or only those with link-local addresses? > When the Home Agent receives the encapsulated routing protocol > message, it processes the inner packets and updates its routing table > accordingly. Should be the other way around: When the Home Agent receives the inner packet, it processes encapsulated routing protocol messages and updates its routing table accordingly. > The next hop information in these routing entries is > filled with the Mobile Router's link local address with the outgoing > interface set to the bi-directional tunnel. Let's make it "As part of normal routing protocol operation, the next hop information..." so that it doesn't sound like a change in RP's operation. > Similary, the Home Agent also sends routing updates through the > bi-directional tunnel to the Mobile Router. The Mobile Router > processes these routing protocol messages and updates its routing > table. For all routes advertised by the Home Agent, the Mobile > Router sets the outgoing interface to the bi-directional tunnel to > the Home Agent. > > When the Mobile Router and the Home Agent exchange routes through > a dynamic routing protocol, the Mobile Router should be careful in > including the same Mobile Network Prefixes in the Binding Update to > the Home Agent and in the routing protocol updates. This isn't really a useful suggestion. It is not reasonable to expect the MR to keep track of the routes that have been announced through the tunnel and somehow make an intelligent decision about the contents of the BU message, because e.g. in OSPF, the flooding mechanism that performs the transport function has no clue about the semantics of the LSA internals it carries. > The Home Agent > depending on its configuration might not add routes based on the > prefix information in the Binding Updates at all, and might use only > the routing protocol updates. Moreover, including the same prefix > information in both the Binding Update and the routing protocol > update is redundant. There are also potential cases where the routing protocol has removed a prefix and the HA still has it from the BU.... Should the doc simply suggest that the MR should not be configured to announce prefixes in the BU if those prefixes will be delivered to the HA by the routing protocol? > Since the routing protocol messages from the Home Agent to the Mobile > Router could potentially contain information about the internal > routing structure of the home network, these messages require > authentications and confidentiality protection. Confidentialy Confidentiality > protection using IPsec ESP [4] MUST be supported and SHOULD be > used. ESP at what level is meant above? If you mean at the Tunnel level, please say so. "SHOULD be used" seems like a strange requirement that will be impossible to check, since it is not for the implementation, but for the used. > For protecting routing protocol messages using ESP, the > bi-directional tunnel between the Mobile Router and the Home > Agent should be treated as the outgoing interface, with link local > addresses as source and destination addresses for the messages. What is meant by "messages" here? Encapsulating packets or encapsulated packets? Why do you need to insist on link-local addresses here? OSPF, for example has a case (virtual links) where packets are sent over more than one hop. > IPsec ESP with a non-null encryption algorithm should be used > in transport mode for protecting the routing protocol messages. > Examples of SPD entries for protecting OSPFv3 messages are described > in [13]. I suggest that the above is reworded to say something like "appropriate authentication and confidentiality protection mechanisms defined in [12,13] should be configured when necessary", instead of trying to define (again) here what they are. > 9. Security Considerations ... > When the Mobile Router is running a dynamic routing protocol as > described in Section 8, it injects routing update messages into the > Home Link. The Home Agent MUST verify that the Mobile Router is > allowed to send routing updates before processing the messages and > propagating the routing information. What is meant by "MUST verify" here? If protocol-specific authentication mechanisms, then they of course may be configured, but mandating that seems strange. If you mean source-address checking, then it is not a strong security mechanism. Alex ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Fri Mar 19 14:35:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17722 for ; Fri, 19 Mar 2004 14:35:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4PmD-0000xd-00 for rtg-dir-archive@ietf.org; Fri, 19 Mar 2004 14:35:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4PlS-0000sE-00 for rtg-dir-archive@ietf.org; Fri, 19 Mar 2004 14:34:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Pkm-0000lt-00 for rtg-dir-archive@ietf.org; Fri, 19 Mar 2004 14:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pkn-0000AT-St; Fri, 19 Mar 2004 14:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Pk7-0008WM-R5 for rtg-dir@optimus.ietf.org; Fri, 19 Mar 2004 14:33:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17506 for ; Fri, 19 Mar 2004 14:33:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Pk5-0000hP-00 for rtg-dir@ietf.org; Fri, 19 Mar 2004 14:33:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Pj5-0000ZG-00 for rtg-dir@ietf.org; Fri, 19 Mar 2004 14:32:16 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B4Pi7-0000QS-00; Fri, 19 Mar 2004 14:31:16 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4Phx-000PyS-Ar; Fri, 19 Mar 2004 19:31:05 +0000 Date: Fri, 19 Mar 2004 11:30:30 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <139156231539.20040319113030@psg.com> To: idr@ietf.org, rtg-dir@ietf.org, ops-dir@ops.ietf.org Subject: FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks- Below is the IETF LC announcement that should have made it to several lists and hasn't yet http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html -- Alex http://www.psg.com/~zinin/ > * To: IETF-Announce :; > * Subject: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard > * From: The IESG > * Date: Tue, 16 Mar 2004 16:29:24 -0500 > * Cc: idr at ietf.org;rtg-dir at ietf.org; > * Reply-to: iesg at ietf.org > * Sender: owner-ietf-announce at ietf.org > > The IESG has received a request from the Inter-Domain Routing WG to consider > the following set of documents updating the Border Gateway Protocol 4 > specification. > > BGP4 protocol-related documents: > > - 'A Border Gateway Protocol 4 (BGP-4) ' > as a Draft Standard > - 'BGP Security Vulnerabilities Analysis ' > as an Informational RFC > - 'BGP-4 Protocol Analysis ' > as an Informational RFC > - 'Experience with the BGP-4 Protocol ' > as an Informational RFC > > BGP4 MIB-related documents: > > - 'Definitions of Managed Objects for the Fourth Version of Border Gateway > Protocol (BGP-4) ' > as a Proposed Standard > > Implementation reports: > > - 'BGP 4 Implementation Report ' > as an Informational RFC > - 'BGP MIB V1 implementation survey ' > as an Informational RFC > > The documents above satisfy the standardization criteria for Routing > Protocols described in RFC 1264. > > Since draft-ietf-idr-bgp4-23.txt specifies the TCP MD5 Signature Option (RFC > 2385), which is a Proposed Standard, as the mandatory to implement > authentication mechanism, the IESG is planning to apply the variance > procedure per RFC 2026 to allow the BGP4 protocol specification at the Draft > Standard level to have a normative reference to RFC 2385. The variance > prodedure request is documented in the following document: > > - 'Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC > 2385) and the BGP-4 Specification ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-04-13. > > The files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-23.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-vuln-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol- > 03.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-13.txt > http://www.ietf.org/internet-drafts/draft-iesg-tcpmd5app-00.txt > > Implementation Reports can be accessed at > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.tx From rtg-dir-admin@ietf.org Sat Mar 20 15:16:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23261 for ; Sat, 20 Mar 2004 15:16:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4mtT-0003Mf-00 for rtg-dir-archive@ietf.org; Sat, 20 Mar 2004 15:16:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4msU-0003Ca-00 for rtg-dir-archive@ietf.org; Sat, 20 Mar 2004 15:15:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B4mrM-00032l-04 for rtg-dir-archive@ietf.org; Sat, 20 Mar 2004 15:14:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B4mcq-0000CI-Ac for rtg-dir-archive@ietf.org; Sat, 20 Mar 2004 14:59:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4mcg-0003qi-VI; Sat, 20 Mar 2004 14:59:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4mTt-0003HJ-S8 for rtg-dir@optimus.ietf.org; Sat, 20 Mar 2004 14:50:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21393 for ; Sat, 20 Mar 2004 14:50:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4mTr-0000MX-00 for rtg-dir@ietf.org; Sat, 20 Mar 2004 14:50:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4mSu-0000HU-00 for rtg-dir@ietf.org; Sat, 20 Mar 2004 14:49:04 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B4mS7-0000CZ-00 for rtg-dir@ietf.org; Sat, 20 Mar 2004 14:48:16 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4mS8-000Fd5-15; Sat, 20 Mar 2004 19:48:16 +0000 Date: Sat, 20 Mar 2004 11:47:45 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <11455623.20040320114745@psg.com> To: Christian Hopps CC: rtg-dir@ietf.org, Ross Callon , Ron Bonica , Rick Wilder Subject: Re: Review of draft-ietf-l3vpn-ospf-2547-01.txt In-Reply-To: <90F898E7-76B9-11D8-B00A-00039303E9E2@rawdofmt.org> References: <90F898E7-76B9-11D8-B00A-00039303E9E2@rawdofmt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Thanks, Chris! I'm cc'ing the L3VPN WG chairs who should be able to take this to the WG. -- Alex http://www.psg.com/~zinin/ Monday, March 15, 2004, 11:47:18 AM, Christian Hopps wrote: > Mostly all I have is editorial comments, which follow. >> OSPF as the PE/CE Protocol in BGP/MPLS IP VPNs > [...] >> - If VPN sites A and B are in the same OSPF domain, then routes >> from one should be presented to the other as OSPF intra-network >> routes. In general, this can be done by presenting such routes >> as inter-area routes, in type 3 LSAs. > Does the term "OSPF intra-network routes" here really mean "OSPF > intra-domain routes"? > [...] >> If two PEs attach to different VPN sites that are in the same OSPF >> area (as indicated by the OSPF area number), the PE/CE links to >> those >> site MAY be treated as links within that area. In addition, each PE > sites > [...] >> If a PE router needs to use OSPF to distribute to a CE router a >> route >> which comes from a site outside the CE router's OSPF domain, the PE >> router SHOULD present itself to the CE router as an Autonomous >> System >> Border Router (ASBR), and SHOULD report such routes as AS-external > Why is the first "SHOULD" not a "MUST"? >> routes. That is, these PE routers originate Type 5 LSAs reporting >> the extra-domain routes as AS-external routes. Each such Type 5 LSA >> MUST contain an OSPF route tag whose value is that of the VPN Route >> Tag. This tag identifies the route as having come from a PE router. >> The VPN Route Tag MUST be used to ensure that a Type 5 LSA >> originated >> by a PE router is not redistributed through the OSPF area to another >> PE router. > [...] >> - OSPF Route Type Extended Communities Attribute. This attribute >> MUST be present. It is encoded with a two-byte type field, and >> its type is 0306. The type 8000 SHOULD be accepted as well, to >> ensure backwards compatibility. The remaining six bytes of the >> Attribute are encodes as follows: >> >> * Area Number: 4 bytes, encoding a 32-bit area number. For AS- >> external routes, the value is 0. A non-zero value identifies >> the route as being internal to the OSPF domain, and as being >> within the identified area. Area numbers are relative to a >> particular OSPF domain. > Perhaps there should be the std "bits" diagrams for this and the other > attributes? > [...] >> 4.2.4. VPN-IP routes received via BGP >> >> This section describes how the PE router handles VPN-IP routes >> received via BGP. >> >> If a received BGP VPN-IP route is not installed in the VRF, nothing >> is reported to the CE. A received route will not be installed into >> the VRF if some other route is preferable. (Note that a route which >> is not installed in the VRF may still cause the PE to create an OSPF >> link to another PE as specified in the previous section.) > Perhaps a section reference here rather than "previous". > Chris. From rtg-dir-admin@ietf.org Sun Mar 21 12:53:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21875 for ; Sun, 21 Mar 2004 12:53:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B578y-0003xb-00 for rtg-dir-archive@ietf.org; Sun, 21 Mar 2004 12:53:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5787-0003sb-00 for rtg-dir-archive@ietf.org; Sun, 21 Mar 2004 12:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5788-0007HO-RX; Sun, 21 Mar 2004 12:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5780-0007H8-Gr for rtg-dir@optimus.ietf.org; Sun, 21 Mar 2004 12:52:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21832 for ; Sun, 21 Mar 2004 12:52:48 -0500 (EST) From: SymantecSMTPSecurityServer@tataisp.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B577y-0003rK-00 for rtg-dir@ietf.org; Sun, 21 Mar 2004 12:52:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5774-0003lt-00 for rtg-dir@ietf.org; Sun, 21 Mar 2004 12:51:55 -0500 Received: from [203.124.230.142] (helo=network.tataisp.com) by ietf-mx with smtp (Exim 4.12) id 1B576a-0003gL-00 for rtg-dir@ietf.org; Sun, 21 Mar 2004 12:51:24 -0500 To: rtg-dir@ietf.org Subject: This message contains unsolicited data Date: Sun, 21 Mar 2004 23:20:55 -0800 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.5 required=5.0 tests=DATE_IN_FUTURE_12_24, MSGID_FROM_MTA_SHORT,NO_REAL_NAME autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 2.0 DATE_IN_FUTURE_12_24 Date: is 12 to 24 hours after Received: date * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Your email message could not be sent to the receipent either because the subject title or the attached file type is blocked on the SMTP server. Please check the following message. From: rtg-dir@ietf.org To: sudeer.babu@tataisp.com The message was dropped. Subject: hello Matching Subject: hello From rtg-dir-admin@ietf.org Mon Mar 22 08:52:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24664 for ; Mon, 22 Mar 2004 08:52:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PrG-0003mD-00 for rtg-dir-archive@ietf.org; Mon, 22 Mar 2004 08:52:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PqP-0003b9-00 for rtg-dir-archive@ietf.org; Mon, 22 Mar 2004 08:51:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5Ppe-0003RZ-01 for rtg-dir-archive@ietf.org; Mon, 22 Mar 2004 08:51:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5Pb6-0005GM-Nd for rtg-dir-archive@ietf.org; Mon, 22 Mar 2004 08:36:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Pb4-0000Lp-R6; Mon, 22 Mar 2004 08:36:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PaH-0000F2-AO for rtg-dir@optimus.ietf.org; Mon, 22 Mar 2004 08:35:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23396 for ; Mon, 22 Mar 2004 08:35:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PaG-0001Ku-00 for rtg-dir@ietf.org; Mon, 22 Mar 2004 08:35:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PZ4-00017w-00 for rtg-dir@ietf.org; Mon, 22 Mar 2004 08:34:02 -0500 Received: from 213-35-175-225-dsl.prn.estpak.ee ([213.35.175.225] helo=rddp) by ietf-mx with smtp (Exim 4.12) id 1B5PXX-0000td-00; Mon, 22 Mar 2004 08:32:27 -0500 Message-ID: From: "Owner-ietf-announce" Date: Mon, 22 Mar 2004 15:32:03 +0200 To: rddp@ietf.org, research-funding@ietf.org, research-funding-web-archive@ietf.org, rmt@ietf.org, rmonmib@ietf.org, rpsec@ietf.org, rserpool@ietf.org, rtg-dir@ietf.org, rohc@ietf.org Subject: Fwd:In-crease Your Manhood By 3+inches!!.........zoned MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_BALANCE_HTML,LINES_OF_YELLING,MIME_HTML_ONLY,UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: 8bit natgain+

THE NEW
NaturalGain+ PEN1S Enlargement Pills
will
EXPAND
LENGTHEN
and
ENLARGE YOUR PEN1S 3+ INCHES

* 100% Mon.ey Back Guaran.tee
* FR.EE Bottle Of NaturalGain+ Worth Over $50
* FR.EE "Male Help E-Book" Worth Over $50

MORE INFO HERE

no more emailz

Seoulconverge From rtg-dir-admin@ietf.org Tue Mar 23 14:03:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18248 for ; Tue, 23 Mar 2004 14:03:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rBT-0002I4-00 for rtg-dir-archive@ietf.org; Tue, 23 Mar 2004 14:03:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5r9n-0002CJ-00 for rtg-dir-archive@ietf.org; Tue, 23 Mar 2004 14:01:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5r93-00027J-00 for rtg-dir-archive@ietf.org; Tue, 23 Mar 2004 14:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5r95-0006RD-7r; Tue, 23 Mar 2004 14:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5r8g-0006LV-1b for rtg-dir@optimus.ietf.org; Tue, 23 Mar 2004 14:00:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18096 for ; Tue, 23 Mar 2004 14:00:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5r8d-00024K-00 for rtg-dir@ietf.org; Tue, 23 Mar 2004 14:00:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5r7h-0001zL-00 for rtg-dir@ietf.org; Tue, 23 Mar 2004 13:59:38 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B5r6t-0001va-00; Tue, 23 Mar 2004 13:58:48 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5r6r-000HNa-Jm; Tue, 23 Mar 2004 18:58:45 +0000 Date: Tue, 23 Mar 2004 10:58:13 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1089693161.20040323105813@psg.com> To: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Idea: IETF RTG project list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Guys- Opinions sought: I've been approached by a number of people at different times asking how they can be useful in the IETF and RTG WGs in particular. I also know some of us struggle finding volunteers with cycles to take certain projects, MIBs not being the only one. So I had an idea: we have an area on the rtg.ietf.org web-page, where WG chairs can post project descriptions and contact info. Whenever a project is added, an e-mail is sent to the routing-discussion mailing list. Volunteers then can also look at the web-page and see pick the project to help with. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Tue Mar 23 14:46:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20967 for ; Tue, 23 Mar 2004 14:46:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rrM-0005ry-00 for rtg-dir-archive@ietf.org; Tue, 23 Mar 2004 14:46:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rqJ-0005ko-00 for rtg-dir-archive@ietf.org; Tue, 23 Mar 2004 14:45:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5rpc-0005fS-00 for rtg-dir-archive@ietf.org; Tue, 23 Mar 2004 14:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rpd-0003DL-NK; Tue, 23 Mar 2004 14:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rkQ-0002sA-5u for rtg-dir@optimus.ietf.org; Tue, 23 Mar 2004 14:39:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20473 for ; Tue, 23 Mar 2004 14:39:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rkN-0005FP-00 for rtg-dir@ietf.org; Tue, 23 Mar 2004 14:39:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rjg-0005Aw-00 for rtg-dir@ietf.org; Tue, 23 Mar 2004 14:38:53 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5rik-00056U-00; Tue, 23 Mar 2004 14:37:54 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 6C09BB768A6; Tue, 23 Mar 2004 11:37:53 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13530-08; Tue, 23 Mar 2004 11:37:53 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.177]) by prattle.redback.com (Postfix) with SMTP id 7CD36B768A2; Tue, 23 Mar 2004 11:37:52 -0800 (PST) Message-ID: <181901c4110e$4ccaa5e0$0302a8c0@aceeinspiron> From: "Acee Lindem" To: "Alex Zinin" , , References: <1089693161.20040323105813@psg.com> Subject: Re: IETF RTG project list Date: Tue, 23 Mar 2004 14:37:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Alex, I don't like the idea at all. I believe that many times the people who volunteer will be the ones that will do a superficial job and it will fall upon the WG chairs to clean up the drafts. I can recall one particular "short and simple" draft where it would have been infinitely easier to author it myself than go through the many iterations while avoiding hurting the authors feelings. I think the existing model with the routing directory is a much better. Thanks, Acee ----- Original Message ----- From: "Alex Zinin" To: ; Sent: Tuesday, March 23, 2004 1:58 PM Subject: Idea: IETF RTG project list > Guys- > > Opinions sought: > > I've been approached by a number of people at different times asking how they > can be useful in the IETF and RTG WGs in particular. > > I also know some of us struggle finding volunteers with cycles to take certain > projects, MIBs not being the only one. > > So I had an idea: we have an area on the rtg.ietf.org web-page, where WG chairs > can post project descriptions and contact info. Whenever a project is added, an > e-mail is sent to the routing-discussion mailing list. Volunteers then can also > look at the web-page and see pick the project to help with. > > -- > Alex > http://www.psg.com/~zinin/ > > From rtg-dir-admin@ietf.org Tue Mar 23 18:30:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11847 for ; Tue, 23 Mar 2004 18:30:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vM3-00012u-00 for rtg-dir-archive@ietf.org; Tue, 23 Mar 2004 18:30:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vLC-0000y3-00 for rtg-dir-archive@ietf.org; Tue, 23 Mar 2004 18:29:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5vKM-0000sd-00 for rtg-dir-archive@ietf.org; Tue, 23 Mar 2004 18:28:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vKP-0002fI-9C; Tue, 23 Mar 2004 18:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vKL-0002ep-2v for rtg-dir@optimus.ietf.org; Tue, 23 Mar 2004 18:28:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11708 for ; Tue, 23 Mar 2004 18:28:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vKI-0000ro-00 for rtg-dir@ietf.org; Tue, 23 Mar 2004 18:28:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vJH-0000la-00 for rtg-dir@ietf.org; Tue, 23 Mar 2004 18:27:52 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B5vId-0000fy-00; Tue, 23 Mar 2004 18:27:11 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5vId-0001vy-Ez; Tue, 23 Mar 2004 23:27:11 +0000 Date: Tue, 23 Mar 2004 15:26:40 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <109105799741.20040323152640@psg.com> To: "Acee Lindem" CC: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Re: IETF RTG project list In-Reply-To: <181901c4110e$4ccaa5e0$0302a8c0@aceeinspiron> References: <1089693161.20040323105813@psg.com> <181901c4110e$4ccaa5e0$0302a8c0@aceeinspiron> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Acee, Let see... The problem I am trying to solve is when it is when all usual suspects have been asked and the work is still not going forward or goes really slow... Examples: BGP/MIB implementation reports, security documents. It doesn't necessarily have to be a search for new authors, could be solicitation for more review or feedback, etc... If we have people working on something already, or you, as WG chairs, feel you should be careful about who does a specific piece of work-- then we simply don't post it there... -- Alex http://www.psg.com/~zinin/ Tuesday, March 23, 2004, 11:37:37 AM, Acee Lindem wrote: > Alex, > I don't like the idea at all. I believe that many times the people > who volunteer will be the ones that will do a superficial > job and it will fall upon the WG chairs to clean up > the drafts. I can recall one particular "short and simple" draft > where it would have been infinitely easier to author it myself than > go through the many iterations while avoiding hurting the authors > feelings. I think the existing model with the routing directory is a > much better. > Thanks, > Acee > ----- Original Message ----- > From: "Alex Zinin" > To: ; > Sent: Tuesday, March 23, 2004 1:58 PM > Subject: Idea: IETF RTG project list >> Guys- >> >> Opinions sought: >> >> I've been approached by a number of people at different times asking how they >> can be useful in the IETF and RTG WGs in particular. >> >> I also know some of us struggle finding volunteers with cycles to take certain >> projects, MIBs not being the only one. >> >> So I had an idea: we have an area on the rtg.ietf.org web-page, where WG chairs >> can post project descriptions and contact info. Whenever a project is added, an >> e-mail is sent to the routing-discussion mailing list. Volunteers then can also >> look at the web-page and see pick the project to help with. >> >> -- >> Alex >> http://www.psg.com/~zinin/ >> >> From rtg-dir-admin@ietf.org Wed Mar 24 03:56:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06415 for ; Wed, 24 Mar 2004 03:56:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B64C0-0007fr-00 for rtg-dir-archive@ietf.org; Wed, 24 Mar 2004 03:56:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B64B5-0007Td-00 for rtg-dir-archive@ietf.org; Wed, 24 Mar 2004 03:55:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B64A7-0007Gw-00 for rtg-dir-archive@ietf.org; Wed, 24 Mar 2004 03:54:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64A9-0000ej-Lk; Wed, 24 Mar 2004 03:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B649D-0000X0-BV for rtg-dir@optimus.ietf.org; Wed, 24 Mar 2004 03:54:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06279 for ; Wed, 24 Mar 2004 03:54:01 -0500 (EST) From: Mukesh.Gupta@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B649A-00074m-00 for rtg-dir@ietf.org; Wed, 24 Mar 2004 03:54:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B648I-0006si-00 for rtg-dir@ietf.org; Wed, 24 Mar 2004 03:53:07 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B647M-0006dg-00; Wed, 24 Mar 2004 03:52:08 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2O8q5I02702; Wed, 24 Mar 2004 10:52:05 +0200 (EET) X-Scanned: Wed, 24 Mar 2004 10:51:05 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i2O8p5Ds009183; Wed, 24 Mar 2004 10:51:05 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00LkGQCl; Wed, 24 Mar 2004 10:00:58 EET 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 i2O7xIF20133; Wed, 24 Mar 2004 09:59:18 +0200 (EET) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 23 Mar 2004 23:59:16 -0800 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: IETF RTG project list Date: Wed, 24 Mar 2004 01:59:17 -0600 Message-ID: <8D260779A766FB4A9C1739A476F84FA401F799E4@daebe009.americas.nokia.com> Thread-Topic: IETF RTG project list Thread-Index: AcQRLupfkKz6mVCVQ3WMPGnCoGSPLAARfoaw To: , Cc: , X-OriginalArrivalTime: 24 Mar 2004 07:59:16.0888 (UTC) FILETIME=[E7AC2180:01C41175] Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Alex, I support the idea. I understand Acee's concern but I think we need to help new people come on-board by letting them start with small contributions. I agree that the WG chair might need to do little extra work if someone new is trying to get something done but=20 doing everything yourself because it will be faster does not scale well in future as well. And as you already pointed out, the WG chair can decide about what to post on these pages. If something really requires technical expertise, the chairs can decide to choose people using other methods. In summary, I would like to see this in action. Regards Mukesh > -----Original Message----- > From: ext Alex Zinin [mailto:zinin@psg.com] > Sent: Tuesday, March 23, 2004 3:27 PM > To: Acee Lindem > Cc: rtg-chairs@ietf.org; rtg-dir@ietf.org > Subject: Re: IETF RTG project list >=20 >=20 > Acee, >=20 > Let see... > =20 > The problem I am trying to solve is when it is when all=20 > usual suspects > have been asked and the work is still not going forward or=20 > goes really > slow... Examples: BGP/MIB implementation reports, security=20 > documents. > It doesn't necessarily have to be a search for new authors, could be > solicitation for more review or feedback, etc... >=20 > If we have people working on something already, or you, as=20 > WG chairs, > feel you should be careful about who does a specific piece of work-- > then we simply don't post it there... >=20 > --=20 > Alex > http://www.psg.com/~zinin/ >=20 > Tuesday, March 23, 2004, 11:37:37 AM, Acee Lindem wrote: > > Alex, >=20 > > I don't like the idea at all. I believe that many times the people > > who volunteer will be the ones that will do a superficial > > job and it will fall upon the WG chairs to clean up=20 > > the drafts. I can recall one particular "short and simple" draft=20 > > where it would have been infinitely easier to author it myself than > > go through the many iterations while avoiding hurting the authors > > feelings. I think the existing model with the routing=20 > directory is a=20 > > much better.=20 >=20 > > Thanks, > > Acee=20 >=20 > > ----- Original Message -----=20 > > From: "Alex Zinin" > > To: ; > > Sent: Tuesday, March 23, 2004 1:58 PM > > Subject: Idea: IETF RTG project list >=20 >=20 > >> Guys- > >>=20 > >> Opinions sought: > >>=20 > >> I've been approached by a number of people at different=20 > times asking how they > >> can be useful in the IETF and RTG WGs in particular. > >>=20 > >> I also know some of us struggle finding volunteers with=20 > cycles to take certain > >> projects, MIBs not being the only one. > >>=20 > >> So I had an idea: we have an area on the rtg.ietf.org=20 > web-page, where WG chairs > >> can post project descriptions and contact info. Whenever=20 > a project is added, an > >> e-mail is sent to the routing-discussion mailing list.=20 > Volunteers then can also > >> look at the web-page and see pick the project to help with. > >>=20 > >> --=20 > >> Alex > >> http://www.psg.com/~zinin/ > >>=20 > >>=20 >=20 >=20 From rtg-dir-admin@ietf.org Thu Mar 25 09:28:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23664 for ; Thu, 25 Mar 2004 09:28:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VqR-0000c6-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 09:28:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6VoS-0000G9-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 09:26:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6Vmr-0007ly-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 09:24:49 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6Va6-0005Xh-TF for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 09:11:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZu-0007vW-EM; Thu, 25 Mar 2004 09:11:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Uq9-00037D-9Y for rtg-dir@optimus.ietf.org; Thu, 25 Mar 2004 08:24:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19587 for ; Thu, 25 Mar 2004 08:24:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Uq8-0001Ji-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 08:24:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Up8-0001Az-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 08:23:06 -0500 Received: from [222.100.52.30] (helo=rtg-dir) by ietf-mx with smtp (Exim 4.12) id 1B6UoZ-000142-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 08:22:31 -0500 Message-ID: From: "Rmt" Date: Tue, 23 Mar 2004 22:22:09 +0200 To: rtg-dir@ietf.org Subject: Only DeerAntler+ Can Give Men Multiple 0rgasms! . . . . stuff MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,HTML_70_80, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: 8bit DeerAntler+






audiometry , lucked From rtg-dir-admin@ietf.org Thu Mar 25 17:18:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27866 for ; Thu, 25 Mar 2004 17:18:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6dBO-0007KV-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 17:18:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6d9s-000769-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 17:17:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6d8P-0006tn-03 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 17:15:33 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6cuK-0006D1-UO for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 17:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cuK-0006ez-UU; Thu, 25 Mar 2004 17:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ctr-0006d5-8l for rtg-dir@optimus.ietf.org; Thu, 25 Mar 2004 17:00:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27160 for ; Thu, 25 Mar 2004 17:00:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ctp-0006C2-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 17:00:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6csv-00068e-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 16:59:33 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B6csF-00066m-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 16:58:51 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6csF-000Fzm-RV; Thu, 25 Mar 2004 21:58:51 +0000 Date: Thu, 25 Mar 2004 13:58:51 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <227964963.20040325135851@psg.com> To: MPLS WG CC: rtg-dir@ietf.org Subject: AD-review comments on draft-ietf-mpls-nodeid-subobject-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA27161 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Folks- Please find below my comments on this document. Substantial: In section 3, in the following para-- > An implementation MAY either decide to support of one the following > options: --not clear language and not clear what the "MAY" specifies. There should be a description of what implementation supporting this spec MUST do so that other nodes can leverage that. Editorial: - poor general formatting, affects readability, please fix - Section 1 "Terminology": "CSPF" defined, but not used ditto for "NHOP bypass tunnel" ditto for "NNHOP bypass tunnel" - Section 2: The illustration is not captioned, though references to Figure 1 ar= e made in the document. - Section 3. Non-ASCII characters in the following para: > > As mentioned above, the limitation that we need to address is the > generality of the contents of the RRO IPv4 and IPv6 subobjects, as > defined in [RSVP-TE].[RFC3209] defines the IPv4 and IPv6 RRO subobject= s > along with two flags (namely the (Local Protection Available=F7 and > (Local protection in use=F7 bits). Moreover, other bits have been > specified in [FAST-REROUTE] and [SOFT-PREEMPTION]. please check throughout the document. > Authors' Address: Should be "Addresses" Alex From rtg-dir-admin@ietf.org Thu Mar 25 18:28:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02726 for ; Thu, 25 Mar 2004 18:28:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6eHC-0004BG-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 18:28:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6eGQ-000474-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 18:27:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6eFW-000426-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 18:26:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6eFY-0005VD-MG; Thu, 25 Mar 2004 18:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6eF8-0005Se-0Y for rtg-dir@optimus.ietf.org; Thu, 25 Mar 2004 18:26:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02575 for ; Thu, 25 Mar 2004 18:26:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6eF5-0003xV-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 18:26:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6eE8-0003rJ-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 18:25:33 -0500 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 1B6eDD-0003jP-01 for rtg-dir@ietf.org; Thu, 25 Mar 2004 18:24:35 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2004 15:30:58 +0000 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2PNORUe024716; Thu, 25 Mar 2004 15:24:27 -0800 (PST) Received: from jvasseur-w2k01.cisco.com (che-vpn-cluster-1-41.cisco.com [10.86.240.41]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA25253; Thu, 25 Mar 2004 15:24:26 -0800 (PST) Message-Id: <4.3.2.7.2.20040325182346.033c5158@wells.cisco.com> X-Sender: jvasseur@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Mar 2004 18:24:24 -0500 To: Alex Zinin From: Jean Philippe Vasseur Subject: Re: AD-review comments on draft-ietf-mpls-nodeid-subobject-02.txt Cc: MPLS WG , rtg-dir@ietf.org In-Reply-To: <227964963.20040325135851@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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: quoted-printable Thanks a lot Alex: I'll quickly address the comments and post another= revision. thanks. JP. At 01:58 PM 3/25/2004 -0800, Alex Zinin wrote: >Folks- > > Please find below my comments on this document. > > Substantial: > > In section 3, in the following para-- > > > An implementation MAY either decide to support of one the following > > options: > > --not clear language and not clear what the "MAY" specifies. > There should be a description of what implementation supporting this > spec MUST do so that other nodes can leverage that. > > Editorial: > > - poor general formatting, affects readability, please fix > > - Section 1 "Terminology": > "CSPF" defined, but not used > ditto for "NHOP bypass tunnel" > ditto for "NNHOP bypass tunnel" > > - Section 2: > > The illustration is not captioned, though references to Figure 1 are > made in the document. > > - Section 3. Non-ASCII characters in the following para: > > > > As mentioned above, the limitation that we need to address is the > > generality of the contents of the RRO IPv4 and IPv6 subobjects, as > > defined in [RSVP-TE].[RFC3209] defines the IPv4 and IPv6 RRO subobjects > > along with two flags (namely the (Local Protection Available=F7 and > > (Local protection in use=F7 bits). Moreover, other bits have been > > specified in [FAST-REROUTE] and [SOFT-PREEMPTION]. > > please check throughout the document. > > > Authors' Address: > > Should be "Addresses" > >Alex From rtg-dir-admin@ietf.org Thu Mar 25 21:39:34 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10207 for ; Thu, 25 Mar 2004 21:39:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6hFu-0001LF-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 21:39:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6hF4-0001Hx-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 21:38:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6hEN-0001F3-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 21:37:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hEP-0001zt-Eb; Thu, 25 Mar 2004 21:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hDS-0001i9-QQ for rtg-dir@optimus.ietf.org; Thu, 25 Mar 2004 21:37:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10068 for ; Thu, 25 Mar 2004 21:36:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6hDQ-00018z-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 21:37:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6hCP-00012e-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 21:35:58 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B6hBS-0000xi-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 21:34:58 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6hBT-0003Tu-5E for rtg-dir@ietf.org; Fri, 26 Mar 2004 02:34:59 +0000 Date: Thu, 25 Mar 2004 18:34:59 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <11424532976.20040325183459@psg.com> To: rtg-dir@ietf.org Subject: Other pieces of the MT-routing "puzzle"? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit RTG-DIR folks- So we have MT extensions to IS-IS, and a draft for OSPF has been recently published. One of my concerns with MT-ISIS a while back was the situation where an interface belongs to more than one MT. In this case the association between an incoming packet and the FIB to look in is not obvious, and both drafts are silent about it (which is sort of ok given that they describe the control part of the story). Management is supposed to ensure consistent configuration among MT routers to avoid loops and black holes, but there is a potentially unlimited number of ways to mux/demux MTs on a link, and it seems that defining a few IETF standards for this would help interoperability... In other words, STD-wise, we've been operating in a single-MT environment. What we're seeing is the RP-related part of the story, and it seems that we need the encaps/forwarding part of it and (possibly) the overarching architecture. Opinions? -- Alex From rtg-dir-admin@ietf.org Thu Mar 25 21:57:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10875 for ; Thu, 25 Mar 2004 21:57:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6hXR-0002Pn-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 21:57:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6hWZ-0002Lj-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 21:56:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6hVn-0002IP-00 for rtg-dir-archive@ietf.org; Thu, 25 Mar 2004 21:55:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hVp-0002qT-HT; Thu, 25 Mar 2004 21:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6hVS-0002np-U0 for rtg-dir@optimus.ietf.org; Thu, 25 Mar 2004 21:55:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10787 for ; Thu, 25 Mar 2004 21:55:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6hVQ-0002Gp-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 21:55:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6hUX-0002EE-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 21:54:42 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B6hTo-0002Bg-00 for rtg-dir@ietf.org; Thu, 25 Mar 2004 21:53:56 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6hTp-0006ea-1Z for rtg-dir@ietf.org; Fri, 26 Mar 2004 02:53:57 +0000 Date: Thu, 25 Mar 2004 18:53:56 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <16725670632.20040325185356@psg.com> To: rtg-dir@ietf.org Subject: Fwd: PRELIMINARY Agenda and Package for April 2, 2004 Telechat In-Reply-To: <200403252241.RAA28900@ietf.org> References: <200403252241.RAA28900@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA10788 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable FYI --=20 Alex INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the April 2, 2004 IESG Teleconference This agenda was generated at 17:22:37 EDT, March 25, 2004 = =20 1. Administrivia = =20 o Roll Call o Bash the Agenda o Approval of the Minutes o Review of Action Items = =20 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Item o Three-document ballot: - 1 of 7 - draft-ietf-fax-tiff-fx-13.txt File Format for Internet Fax (Draft Standard)=20 - draft-ietf-fax-tiff-fx-reg-v2-00.txt Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME=20 Sub-type Registration (Draft Standard)=20 - RFC 3302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registrati= on=20 (Draft)=20 Token: Scott Hollenbeck o draft-ietf-vpim-ivm-05.txt Internet Voice Messaging (Proposed Standard) - 2 of 7=20 Token: Scott Hollenbeck o draft-ietf-magma-igmp-proxy-05.txt IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying') (Proposed=20 Standard) - 3 of 7=20 Token: Margaret Wasserman o Two-document ballot: - 4 of 7 - draft-ietf-ipsec-ikev2-algorithms-04.txt Cryptographic Algorithms for use in the Internet Key Exchange Vers= ion=20 2 (Proposed Standard)=20 - draft-ietf-ipsec-ui-suites-04.txt Cryptographic Suites for IPsec (Proposed Standard)=20 Token: Russ Housley o draft-ietf-dhc-leasequery-07.txt DHCP Lease Query (Proposed Standard) - 5 of 7=20 Token: Margaret Wasserman o draft-ietf-v6ops-3gpp-analysis-09.txt Analysis on IPv6 Transition in 3GPP Networks (BCP) - 6 of 7=20 Token: David Kessens o draft-ietf-krb-wg-gssapi-cfx-07.txt The Kerberos Version 5 GSS-API Mechanism: Version 2 (Proposed Standar= d) -=20 7 of 7=20 Token: Russ Housley 2.1.2 Returning Item o draft-ietf-ipsec-udp-encaps-08.txt UDP Encapsulation of IPsec Packets (Proposed Standard) - 1 of 2=20 Token: Russ Housley o draft-ietf-dhc-server-mib-10.txt Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB=20 (Proposed Standard) - 2 of 2=20 Token: Margaret Wasserman 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item o draft-ema-vpim-clid-08.txt Calling Line Identification for Voice Mail Messages (Proposed Standar= d) -=20 1 of 1=20 Note: Old text ballot incomplete; need to re-issue ballot.=20 Token: Scott Hollenbeck 3. Document Actions 3.1 WG Submissions 3.1.1 New Item o draft-ietf-bmwg-conterm-05.txt Terminology for Benchmarking BGP Device Convergence in the Control Pl= ane=20 (Informational) - 1 of 7=20 Token: David Kessens o draft-ietf-bmwg-mcastm-14.txt Methodology for IP Multicast Benchmarking (Informational) - 2 of 7=20 Token: Bert Wijnen o Three-document ballot: - 3 of 7 - draft-ietf-bmwg-ospfconv-term-07.txt OSPF Benchmarking Terminology and Concepts (Informational)=20 - draft-ietf-bmwg-ospfconv-applicability-04.txt Benchmarking Applicability for Basic OSPF Convergence (Information= al)=20 - draft-ietf-bmwg-ospfconv-intraarea-07.txt Benchmarking Basic OPSF Single Router Control Plane Convergence=20 (Informational)=20 Token: David Kessens o draft-ietf-ips-command-ordering-02.txt SCSI Command Ordering Considerations with iSCSI (Informational) - 4 o= f 7=20 Token: Allison Mankin o draft-ietf-l3vpn-security-framework-01.txt Security Framework for Provider Provisioned Virtual Private Networks=20 (Informational) - 5 of 7=20 Note: Note: incorporates comments from security review solicited by R= uss.=20 I've put in a Discuss on things that are editorial and formatting; Gi= ven=20 that it took almost 4 months to get the (small number of) changes fro= m=20 the security review done, I want to go ahead and get the full IESG=20 comments before going back to the WG/authors.=20 Token: Thomas Narten o draft-leinen-ipfix-eval-contrib-02.txt Evaluation of Candidate Protocols for IP Flow Information Export (IPF= IX)=20 (Informational) - 6 of 7=20 Note: Move normative reference:. =E1 [3]=E1 Djernaes, M., "Cisco Syst= ems=20 NetFlow Services Export Version 9. =E1 =E1 =E1 =E1 Transport",=20 draft-djernaes-netflow-9-transport-00 (work in. =E1 =E1 =E1 =E1 progr= ess),=20 February 2003. to an informative reference.=20 Token: Bert Wijnen o Two-document ballot: - 7 of 7 - draft-ietf-rmt-bb-norm-08.txt NACK-Oriented Reliable Multicast (NORM) Building Blocks (Experimen= tal)=20 - draft-ietf-rmt-pi-norm-09.txt NACK-Oriented Reliable Multicast Protocol (NORM) (Experimental)=20 Note: RFC note will remove IPSec reference.. This protocol is=20 deployed.=20 Token: Allison Mankin 3.1.2 Returning Item o draft-ietf-vpim-ivm-goals-06.txt High-Level Requirements for Internet Voice Mail (Informational) - 1 o= f 4=20 Token: Scott Hollenbeck o draft-ietf-l3vpn-generic-reqts-03.txt Generic Requirements for Provider Provisioned Virtual Private Network= s=20 (Informational) - 2 of 4=20 Note: 2004-03-23: -03 is out and should address bellovin's discuss as= =20 well as the other comments. IESG: one change that was made in respons= e to=20 the comment that "2119 was cited, but no terms were used" was that so= me=20 of the should/must wording was changed to SHOULD/MUST wording. I've=20 reviewed these changes, and don't have a problem with them. However, = I=20 wanted to make the IESG aware of these changes in case anyone wanted = to=20 re-review these changes.=20 Token: Thomas Narten o draft-ietf-ipv6-prefix-delegation-requirement-04.txt Requirements for IPv6 prefix delegation (Informational) - 3 of 4=20 Note: 2004-03-23: This document should be approved now. A revised ID = was=20 needed to deal with comments originally from Randy. This document is = back=20 on the agenda only because it's an "old-style" ballot, so there is no= =20 formal record that the IESG signed off on the document, modulo Randy'= s=20 comments. Please, no new review of this document; it just needs to be= =20 approved.=20 Token: Thomas Narten o draft-ietf-ipoib-architecture-03.txt IP over InfiniBand(IPoIB) Architecture (Informational) - 4 of 4=20 Note: This document has references in the abstract that will need to = be=20 removed.=20 Token: Margaret Wasserman 3.2 Individual Submissions Via AD 3.2.1 New Item o draft-blake-wilson-xmldsig-ecdsa-09.txt Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital=20 Signatures (Informational) - 1 of 2=20 Token: Russ Housley o draft-swartz-rdfcore-rdfxml-mediatype-04.txt application/rdf+xml Media Type Registration (Informational) - 2 of 2=20 Token: Scott Hollenbeck 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor 3.3.1 New Item o draft-arkko-map-doi-08.txt The Mobile Application Part SECurity (MAPSEC) Domain of Interpretatio= n=20 (DOI) for the Internet Security Association and Key Management Protoc= ol=20 (ISAKMP) (Informational) - 1 of 2=20 Token: Russ Housley o Two-document ballot: - 2 of 2 - draft-sjkoh-rmt-bb-tree-config-03.txt Reliable Multicast Transport Building Block: Tree Auto-Configurati= on=20 (Informational)=20 - draft-chiu-rmt-bb-track-03.txt Reliable Multicast Transport Building Block:Tree based ACK (TRACK)= =20 Mechanisms (Informational)=20 Note: Note sent to RMT Chairs reminding them of these and suggesti= ng=20 reminder to WG (to avoid surprise).=E1 IESG ex-WG note to be put o= n.=E1=20 Token: Allison Mankin 3.3.2 Returning Item o draft-adams-cmpaltcert-03.txt Alternative Certificate Formats for the PKIX Certificate Management=20 Protocols (Informational) - 1 of 1=20 Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o MTA Authorization Records in DNS (marid) - 1 of 1 Token: Ted 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issue From rtg-dir-admin@ietf.org Fri Mar 26 06:28:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13973 for ; Fri, 26 Mar 2004 06:28:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6pWA-0006EI-00 for rtg-dir-archive@ietf.org; Fri, 26 Mar 2004 06:28:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6pVD-00066o-00 for rtg-dir-archive@ietf.org; Fri, 26 Mar 2004 06:27:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6pUI-00060g-00 for rtg-dir-archive@ietf.org; Fri, 26 Mar 2004 06:26:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6pUL-0005HR-LP; Fri, 26 Mar 2004 06:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6pTT-0005F6-EK for rtg-dir@optimus.ietf.org; Fri, 26 Mar 2004 06:26:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13791 for ; Fri, 26 Mar 2004 06:26:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6pTP-0005v0-00 for rtg-dir@ietf.org; Fri, 26 Mar 2004 06:26:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6pSK-0005nU-00 for rtg-dir@ietf.org; Fri, 26 Mar 2004 06:24:56 -0500 Received: from cpc3-bsfd2-5-0-cust176.cmbg.cable.ntl.com ([81.100.85.176] helo=rtg-dir) by ietf-mx with smtp (Exim 4.12) id 1B6pRL-0005gg-00 for rtg-dir@ietf.org; Fri, 26 Mar 2004 06:23:56 -0500 Message-ID: From: "Sip" Date: Fri, 26 Mar 2004 11:25:19 +0000 To: rtg-dir@ietf.org Subject: Deer Antler Plus:Multiple 0rgasms, Longer Harder Erect-ions! . .retire MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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=HTML_70_80,HTML_IMAGE_ONLY_02, HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: 8bit DeerAntler+






diplomas , besotter From rtg-dir-admin@ietf.org Fri Mar 26 11:50:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01006 for ; Fri, 26 Mar 2004 11:50:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6uX3-0002YG-00 for rtg-dir-archive@ietf.org; Fri, 26 Mar 2004 11:50:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6uW8-0002WI-00 for rtg-dir-archive@ietf.org; Fri, 26 Mar 2004 11:49:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6uVw-0002U9-00 for rtg-dir-archive@ietf.org; Fri, 26 Mar 2004 11:49:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6uVw-0008Dp-Kg; Fri, 26 Mar 2004 11:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6uV8-0008DA-5Y for rtg-dir@optimus.ietf.org; Fri, 26 Mar 2004 11:48:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00960 for ; Fri, 26 Mar 2004 11:48:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6uV7-0002Se-00 for rtg-dir@ietf.org; Fri, 26 Mar 2004 11:48:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6uUL-0002Qq-00 for rtg-dir@ietf.org; Fri, 26 Mar 2004 11:47:22 -0500 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6uTj-0002Ns-00 for rtg-dir@ietf.org; Fri, 26 Mar 2004 11:46:43 -0500 Received: from net4u.ch (zux006-032-023.adsl.green.ch [81.6.32.23]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id i2QGkfb0017440; Fri, 26 Mar 2004 17:46:41 +0100 Message-ID: <40645E73.4040307@net4u.ch> Date: Fri, 26 Mar 2004 17:46:43 +0100 From: Tony Przygienda User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: rtg-dir@ietf.org Subject: Re: Other pieces of the MT-routing "puzzle"? References: <11424532976.20040325183459@psg.com> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Alex Zinin wrote: >RTG-DIR folks- > > So we have MT extensions to IS-IS, and a draft for OSPF has been recently > published. > > One of my concerns with MT-ISIS a while back was the situation where an > interface belongs to more than one MT. > > In this case the association between an > incoming packet and the FIB to look in is not obvious, and both drafts are > silent about it (which is sort of ok given that they describe the control part > of the story). > The problem space has been clasified in mt-isis draft version #6, section 12 more than a year ago. --- tony From rtg-dir-admin@ietf.org Fri Mar 26 12:08:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01783 for ; Fri, 26 Mar 2004 12:08:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6uom-0003qt-00 for rtg-dir-archive@ietf.org; Fri, 26 Mar 2004 12:08:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6unj-0003lj-00 for rtg-dir-archive@ietf.org; Fri, 26 Mar 2004 12:07:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6unM-0003iT-00 for rtg-dir-archive@ietf.org; Fri, 26 Mar 2004 12:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6unN-0001id-44; Fri, 26 Mar 2004 12:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6umd-0001di-Kv for rtg-dir@optimus.ietf.org; Fri, 26 Mar 2004 12:06:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01658 for ; Fri, 26 Mar 2004 12:06:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6umc-0003gg-00 for rtg-dir@ietf.org; Fri, 26 Mar 2004 12:06:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ulu-0003d4-00 for rtg-dir@ietf.org; Fri, 26 Mar 2004 12:05:30 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B6ulB-0003YB-00 for rtg-dir@ietf.org; Fri, 26 Mar 2004 12:04:45 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6ulB-000KXp-EC; Fri, 26 Mar 2004 17:04:45 +0000 Date: Fri, 26 Mar 2004 09:04:44 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1487061323.20040326090444@psg.com> To: Tony Przygienda CC: rtg-dir@ietf.org Subject: Re: Other pieces of the MT-routing "puzzle"? In-Reply-To: <40645E73.4040307@net4u.ch> References: <11424532976.20040325183459@psg.com> <40645E73.4040307@net4u.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Friday, March 26, 2004, 8:46:43 AM, Tony Przygienda wrote: > The problem space has been clasified in mt-isis draft version #6, > section 12 more than a year > ago. It was apparently a long time ago when I read this draft. Now that I look at it, you're right, the document indeed classifies the problem space. Using the draft's words, my general sentiment is whether this-- > 12.2.2. Multiple MTs share an interface with overlapping addresses ... > The generic approach of packet to multiple MT RIB mapping over > the same inbound interface is outside the scope of this draft. --should be addressed. Alex From rtg-dir-admin@ietf.org Fri Mar 26 14:18:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09398 for ; Fri, 26 Mar 2004 14:18:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6wqf-0007CO-00 for rtg-dir-archive@ietf.org; Fri, 26 Mar 2004 14:18:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wpe-00074Y-00 for rtg-dir-archive@ietf.org; Fri, 26 Mar 2004 14:17:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6woc-0006qL-00 for rtg-dir-archive@ietf.org; Fri, 26 Mar 2004 14:16:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6woH-0004RT-4q; Fri, 26 Mar 2004 14:16:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6wnY-0004Js-HO for rtg-dir@optimus.ietf.org; Fri, 26 Mar 2004 14:15:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08810 for ; Fri, 26 Mar 2004 14:15:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6wnV-0006jM-00 for rtg-dir@ietf.org; Fri, 26 Mar 2004 14:15:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6wm9-0006U6-00 for rtg-dir@ietf.org; Fri, 26 Mar 2004 14:13:54 -0500 Received: from lsanca2-ar27-4-46-188-250.lsanca2.dsl-verizon.net ([4.46.188.250] helo=rmt) by ietf-mx with smtp (Exim 4.12) id 1B6wl3-0006Km-00; Fri, 26 Mar 2004 14:12:46 -0500 Message-ID: From: "Owner-wgchairs" Date: Fri, 26 Mar 2004 11:08:27 -0800 To: rmt@ietf.org, rmonmib@ietf.org, rpsec@ietf.org, rserpool@ietf.org, rtg-dir@ietf.org, rohc@ietf.org, routing-discussion@ietf.org, scoya@ietf.org, simple@ietf.org Subject: Fwd:In-crease Your Manhood By 3+inches!!.........obsessions MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_BALANCE_HTML,LINES_OF_YELLING,MIME_HTML_ONLY,UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: 8bit natgain+

THE NEW
NaturalGain+ PEN1S Enlargement Pills
will
EXPAND
LENGTHEN
and
ENLARGE YOUR PEN1S 3+ INCHES

* 100% Mon.ey Back Guaran.tee
* FR.EE Bottle Of NaturalGain+ Worth Over $50
* FR.EE "Male Help E-Book" Worth Over $50

MORE INFO HERE

no more emailz

belittlingsubscribed From rtg-dir-admin@ietf.org Sat Mar 27 00:08:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10704 for ; Sat, 27 Mar 2004 00:08:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B763i-0001aU-00 for rtg-dir-archive@ietf.org; Sat, 27 Mar 2004 00:08:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B762m-0001Vc-00 for rtg-dir-archive@ietf.org; Sat, 27 Mar 2004 00:07:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7627-0001R0-00 for rtg-dir-archive@ietf.org; Sat, 27 Mar 2004 00:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7628-00026b-LK; Sat, 27 Mar 2004 00:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B761e-00025S-U0 for rtg-dir@optimus.ietf.org; Sat, 27 Mar 2004 00:06:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10629 for ; Sat, 27 Mar 2004 00:06:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B761c-0001P7-00 for rtg-dir@ietf.org; Sat, 27 Mar 2004 00:06:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B760i-0001KO-00 for rtg-dir@ietf.org; Sat, 27 Mar 2004 00:05:33 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B7601-0001Go-00 for rtg-dir@ietf.org; Sat, 27 Mar 2004 00:04:49 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B7602-0004C2-NU for rtg-dir@ietf.org; Sat, 27 Mar 2004 05:04:50 +0000 Date: Fri, 26 Mar 2004 21:04:49 -0800 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <181360993.20040326210449@psg.com> To: rtg-dir@ietf.org Subject: Fwd: grow: Request to Advance "BGP Communities for Data Collection" In-Reply-To: <200403231613.i2NGDKPd028324@m106.maoz.com> References: <200403231613.i2NGDKPd028324@m106.maoz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit In case someone didn't have a chance to review this one. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: David Meyer To: david.kessens@nokia.com, bwijnen@lucent.com Cc: iesg-secretary@ietf.org, grow@lists.uoregon.edu, gih@telstra.net Date: Tuesday, March 23, 2004, 8:13:20 AM Subject: grow: Request to Advance "BGP Communities for Data Collection" ===8<==============Original message text=============== David and Bert, On behalf of the GROW WG, we'd like to request that the following document be published as BCP RFC: BGP Communities for Data Collection http://www.ietf.org/internet-drafts/draft-ietf-grow-collection-communities-04.txt Working Group Last Call (WGLC) for this documents was completed on 17 October 2004. During this period it was revised twice: once to close a minor issue raised during the WGLC, and once to correct a few minor I-D nits. Thank you for your time and consideration, Geoff and Dave _________________________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/grow.html web archive: http://darkwing.uoregon.edu/~llynch/grow/ ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Sun Mar 28 09:06:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18006 for ; Sun, 28 Mar 2004 09:06:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7avv-0005fF-00 for rtg-dir-archive@ietf.org; Sun, 28 Mar 2004 09:06:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7av1-0005YI-00 for rtg-dir-archive@ietf.org; Sun, 28 Mar 2004 09:05:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7auK-0005R0-00 for rtg-dir-archive@ietf.org; Sun, 28 Mar 2004 09:05:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7auK-00050k-DY; Sun, 28 Mar 2004 09:05:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7atz-0004uh-Ch for rtg-dir@optimus.ietf.org; Sun, 28 Mar 2004 09:04:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17952 for ; Sun, 28 Mar 2004 09:04:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7atx-0005PX-00 for rtg-dir@ietf.org; Sun, 28 Mar 2004 09:04:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7at1-0005IP-00 for rtg-dir@ietf.org; Sun, 28 Mar 2004 09:03:40 -0500 Received: from relay.clara.net ([195.8.69.77] helo=relay0.mail.uk.clara.net) by ietf-mx with esmtp (Exim 4.12) id 1B7asD-0005BX-00; Sun, 28 Mar 2004 09:02:49 -0500 Received: from du-069-0671.access.clara.net ([217.158.156.162] helo=Puppy) by relay0.mail.uk.clara.net with smtp (Exim 4.22) id 1B7as4-000OzX-3M; Sun, 28 Mar 2004 15:02:40 +0100 Message-ID: <128301c414cd$55144720$1100050a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , References: <8D260779A766FB4A9C1739A476F84FA401F799E4@daebe009.americas.nokia.com> Subject: Re: IETF RTG project list Date: Sun, 28 Mar 2004 14:01:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Alex, I cannot see it doing any harm. The current state of affairs is that it (should) falls to the WG chairs to pick up the pieces anyway - the worst that can happen here is that some new valuable contributions are made. Assuming that the process for "posting" will be simple. But why do you assume that this would work where solicitations to the MLs direct have failed? A ----- Original Message ----- From: To: ; Cc: ; Sent: Wednesday, March 24, 2004 8:59 AM Subject: RE: IETF RTG project list Alex, I support the idea. I understand Acee's concern but I think we need to help new people come on-board by letting them start with small contributions. I agree that the WG chair might need to do little extra work if someone new is trying to get something done but doing everything yourself because it will be faster does not scale well in future as well. And as you already pointed out, the WG chair can decide about what to post on these pages. If something really requires technical expertise, the chairs can decide to choose people using other methods. In summary, I would like to see this in action. Regards Mukesh > -----Original Message----- > From: ext Alex Zinin [mailto:zinin@psg.com] > Sent: Tuesday, March 23, 2004 3:27 PM > To: Acee Lindem > Cc: rtg-chairs@ietf.org; rtg-dir@ietf.org > Subject: Re: IETF RTG project list > > > Acee, > > Let see... > > The problem I am trying to solve is when it is when all > usual suspects > have been asked and the work is still not going forward or > goes really > slow... Examples: BGP/MIB implementation reports, security > documents. > It doesn't necessarily have to be a search for new authors, could be > solicitation for more review or feedback, etc... > > If we have people working on something already, or you, as > WG chairs, > feel you should be careful about who does a specific piece of work-- > then we simply don't post it there... > > -- > Alex > http://www.psg.com/~zinin/ > > Tuesday, March 23, 2004, 11:37:37 AM, Acee Lindem wrote: > > Alex, > > > I don't like the idea at all. I believe that many times the people > > who volunteer will be the ones that will do a superficial > > job and it will fall upon the WG chairs to clean up > > the drafts. I can recall one particular "short and simple" draft > > where it would have been infinitely easier to author it myself than > > go through the many iterations while avoiding hurting the authors > > feelings. I think the existing model with the routing > directory is a > > much better. > > > Thanks, > > Acee > > > ----- Original Message ----- > > From: "Alex Zinin" > > To: ; > > Sent: Tuesday, March 23, 2004 1:58 PM > > Subject: Idea: IETF RTG project list > > > >> Guys- > >> > >> Opinions sought: > >> > >> I've been approached by a number of people at different > times asking how they > >> can be useful in the IETF and RTG WGs in particular. > >> > >> I also know some of us struggle finding volunteers with > cycles to take certain > >> projects, MIBs not being the only one. > >> > >> So I had an idea: we have an area on the rtg.ietf.org > web-page, where WG chairs > >> can post project descriptions and contact info. Whenever > a project is added, an > >> e-mail is sent to the routing-discussion mailing list. > Volunteers then can also > >> look at the web-page and see pick the project to help with. > >> > >> -- > >> Alex > >> http://www.psg.com/~zinin/ > >> > >> > > From rtg-dir-admin@ietf.org Mon Mar 29 01:39:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29015 for ; Mon, 29 Mar 2004 01:39:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7qQf-0004m1-00 for rtg-dir-archive@ietf.org; Mon, 29 Mar 2004 01:39:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7qQE-0004db-00 for rtg-dir-archive@ietf.org; Mon, 29 Mar 2004 01:38:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qQG-0003nE-UO; Mon, 29 Mar 2004 01:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qPi-0003kj-BL for rtg-dir@optimus.ietf.org; Mon, 29 Mar 2004 01:38:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28955 for ; Mon, 29 Mar 2004 01:38:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7qPf-0004c4-00 for rtg-dir@ietf.org; Mon, 29 Mar 2004 01:38:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7qOi-0004Su-00 for rtg-dir@ietf.org; Mon, 29 Mar 2004 01:37:25 -0500 Received: from [213.9.244.33] (helo=world-foundation.org) by ietf-mx with esmtp (Exim 4.12) id 1B7qO2-0004In-00 for rtg-dir@ietf.org; Mon, 29 Mar 2004 01:36:44 -0500 Received: from STEPC020 by world-foundation.org with SMTP (MDaemon.v3.1.2.R) for ; Mon, 29 Mar 2004 08:11:00 +0200 From: "SN World Foundation" Subject: Worldwide Partners program To: rtg-dir@ietf.org Content-Type: multipart/alternative; boundary="=_NextPart_2rfkindysadvnqw3nerasdf"; MIME-Version: 1.0 Date: Mon, 29 Mar 2004 08:10:59 +0200 X-Priority: 3 X-Library: Indy 8.0.22 X-MDRcpt-To: rtg-dir@ietf.org X-Return-Path: wf@world-foundation.org X-MDaemon-Deliver-To: rtg-dir@ietf.org Reply-To: wf@world-foundation.org Message-ID: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.9 required=5.0 tests=AWL,CLICK_BELOW,EXCUSE_16, EXCUSE_3,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,MAILTO_SUBJ_REMOVE, MAILTO_TO_REMOVE,MIME_BOUND_NEXTPART,MIME_BOUND_RKFINDY, PRIORITY_NO_NAME,X_LIBRARY autolearn=no version=2.60 X-Spam-Report: * 1.4 X_LIBRARY Message has X-Library header * 2.8 MIME_BOUND_RKFINDY Spam tool pattern in MIME boundary (rfkindy) * 0.2 EXCUSE_16 BODY: I wonder how many emails they sent in error * 0.1 EXCUSE_3 BODY: Claims you can be removed from the list * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.0 CLICK_BELOW Asks you to click below * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 0.0 AWL AWL: Auto-whitelist adjustment Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New Technology for the Third World, April 2004 Production Mini-plants in mobile containers. Worldwide Partners program SN World Foundation will supply to countries and developing regions the technology and necessary support for production in series of Mini-plants in mobile=20containers (40-foot). The Mini-plant system is designed in such a way that all the production machinery is fixed on the platform of the container, with all wiring,=20piping, and installation parts; that is, they are fully equipped... and the mini-plant is ready for production.=22 More than 700 portable production systems: Bakeries, Water purification, Dehydrated food, Steel Nails, Fruit juice preparation, Tire Retreading, Reinforcement Bar=20Bending for Construction Framework, Sheeting for Roofing, Ceilings and Fa=E7ades, Plated Drums, Aluminum Buckets, Injected Polypropylene Housewares, Pressed=20Melamine Items (Glasses, Cups, Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Mesh, Plastic Bags and Packaging, Medical assistance mobile=20units, Sanitary Material, Hypodermic Syringes, Hemostatic Clamps, etc.=20 SN World Foundation has started a Co-investment program for the installation of small Assembly plants to manufacture in series the Mini-plants of portable=20production on site, region or country where required. One of the most relevant features is the fact that these plants will be connected to the International Trade=20System, with access to more than 50 million raw materials, products and services and automatic transactions for world trade. Due to financial reasons, involving cost and social impact, the best solution is setting up assembly plants on the same countries and regions, using local resources=20(labor, some equipment, etc.) SN World Foundation participates at 50% (fifty percent) for investment of each Assembly plant. If you are interested in being a partner in your country or region, you can send your CV to: SN World Foundation (click here) Worldwide Partners Program By Sarah Mathews, Manager Program ------------------------------------------------------------------------- If you received this in error or would like to be removed from our list, please return us indicating: remove or un-subscribe in subject field, Thanks. Manager Program =A9 2004 SN World Foundation. All rights reserved. --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New Technology for the Third World, April 2004

Production Mini-plants in mobile containers. Worldwide Partners program

SN World Foundation will supply to countries and developing regions the technology and necessary support for production in series of Mini-plants in mobile containers (40-foot). The Mini-plant system is designed in such a way that all the production machinery is fixed on the platform of the container, with all wiring, piping, and installation parts; that is, they are fully equipped... and the mini-plant is ready for production.=22

More than 700 portable production systems: Bakeries, Water purification, Dehydrated food, Steel Nails, Fruit juice preparation, Tire Retreading, Reinforcement Bar Bending for Construction Framework, Sheeting for Roofing, Ceilings and Façades, Plated Drums, Aluminum Buckets, Injected Polypropylene Housewares, Pressed Melamine Items (Glasses, Cups, Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Mesh, Plastic Bags and Packaging, Medical assistance mobile units, Sanitary Material, Hypodermic Syringes, Hemostatic Clamps, etc.

SN World Foundation has started a Co-investment program for the installation of small Assembly plants to manufacture in series the Mini-plants of portable production on site, region or country where required. One of the most relevant features is the fact that these plants will be connected to the International Trade System, with access to more than 50 million raw materials, products and services and automatic transactions for world trade.

Due to financial reasons, involving cost and social impact, the best solution is setting up assembly plants on the same countries and regions, using local resources (labor, some equipment, etc.) SN World Foundation participates at 50% (fifty percent) for investment of each Assembly plant.

If you are interested in being a partner in your country or region, you can send your CV to: SN World Foundation (click here) Worldwide Partners Program

By Sarah Mathews, Manager Program

-------------------------------------------------------------------------
If you received this in error or would like to be removed from our list, please return us indicating: remove or un-subscribe in subject field, Thanks. Manager Program
© 2004 SN World Foundation. All rights reserved.
 --=_NextPart_2rfkindysadvnqw3nerasdf-- From rtg-dir-admin@ietf.org Mon Mar 29 16:25:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27586 for ; Mon, 29 Mar 2004 16:25:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B84G2-0001Gw-00 for rtg-dir-archive@ietf.org; Mon, 29 Mar 2004 16:25:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B84F3-00011l-00 for rtg-dir-archive@ietf.org; Mon, 29 Mar 2004 16:24:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B84Dq-0000jD-00 for rtg-dir-archive@ietf.org; Mon, 29 Mar 2004 16:23:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B84Dn-0005K0-MT; Mon, 29 Mar 2004 16:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B84Da-0005HU-LV for rtg-dir@optimus.ietf.org; Mon, 29 Mar 2004 16:22:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27208 for ; Mon, 29 Mar 2004 16:22:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B84DY-0000gP-00 for rtg-dir@ietf.org; Mon, 29 Mar 2004 16:22:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B84Ca-0000Qo-00 for rtg-dir@ietf.org; Mon, 29 Mar 2004 16:21:49 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1B84BT-00004v-00; Mon, 29 Mar 2004 16:20:39 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 57DE22D48A4; Mon, 29 Mar 2004 16:20:09 -0500 (EST) 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 69536-01-99; Mon, 29 Mar 2004 16:20:09 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 031932D4883; Mon, 29 Mar 2004 16:20:08 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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: IETF RTG project list Date: Mon, 29 Mar 2004 16:20:07 -0500 Message-ID: Thread-Topic: IETF RTG project list Thread-Index: AcQRLupfkKz6mVCVQ3WMPGnCoGSPLAARfoawAReotaA= From: "Susan Hares" To: , , Cc: , X-Virus-Scanned: by amavisd-new at nexthop.com Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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: quoted-printable Perhaps some language about working group chair approval and checking -- might help. Sue -----Original Message----- From: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] Sent: Wednesday, March 24, 2004 2:59 AM To: zinin@psg.com; acee@redback.com Cc: rtg-chairs@ietf.org; rtg-dir@ietf.org Subject: RE: IETF RTG project list Alex, I support the idea. I understand Acee's concern but I think we need to help new people come on-board by letting them start with small contributions. I agree that the WG chair might need to do little extra work if someone new is trying to get something done but=20 doing everything yourself because it will be faster does not scale well in future as well. And as you already pointed out, the WG chair can decide about what to post on these pages. If something really requires technical expertise, the chairs can decide to choose people using other methods. In summary, I would like to see this in action. Regards Mukesh > -----Original Message----- > From: ext Alex Zinin [mailto:zinin@psg.com] > Sent: Tuesday, March 23, 2004 3:27 PM > To: Acee Lindem > Cc: rtg-chairs@ietf.org; rtg-dir@ietf.org > Subject: Re: IETF RTG project list >=20 >=20 > Acee, >=20 > Let see... > =20 > The problem I am trying to solve is when it is when all=20 > usual suspects > have been asked and the work is still not going forward or=20 > goes really > slow... Examples: BGP/MIB implementation reports, security=20 > documents. > It doesn't necessarily have to be a search for new authors, could be > solicitation for more review or feedback, etc... >=20 > If we have people working on something already, or you, as=20 > WG chairs, > feel you should be careful about who does a specific piece of work-- > then we simply don't post it there... >=20 > --=20 > Alex > http://www.psg.com/~zinin/ >=20 > Tuesday, March 23, 2004, 11:37:37 AM, Acee Lindem wrote: > > Alex, >=20 > > I don't like the idea at all. I believe that many times the people > > who volunteer will be the ones that will do a superficial > > job and it will fall upon the WG chairs to clean up=20 > > the drafts. I can recall one particular "short and simple" draft=20 > > where it would have been infinitely easier to author it myself than > > go through the many iterations while avoiding hurting the authors > > feelings. I think the existing model with the routing=20 > directory is a=20 > > much better.=20 >=20 > > Thanks, > > Acee=20 >=20 > > ----- Original Message -----=20 > > From: "Alex Zinin" > > To: ; > > Sent: Tuesday, March 23, 2004 1:58 PM > > Subject: Idea: IETF RTG project list >=20 >=20 > >> Guys- > >>=20 > >> Opinions sought: > >>=20 > >> I've been approached by a number of people at different=20 > times asking how they > >> can be useful in the IETF and RTG WGs in particular. > >>=20 > >> I also know some of us struggle finding volunteers with=20 > cycles to take certain > >> projects, MIBs not being the only one. > >>=20 > >> So I had an idea: we have an area on the rtg.ietf.org=20 > web-page, where WG chairs > >> can post project descriptions and contact info. Whenever=20 > a project is added, an > >> e-mail is sent to the routing-discussion mailing list.=20 > Volunteers then can also > >> look at the web-page and see pick the project to help with. > >>=20 > >> --=20 > >> Alex > >> http://www.psg.com/~zinin/ > >>=20 > >>=20 >=20 >=20 From rtg-dir-admin@ietf.org Tue Mar 30 07:28:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15498 for ; Tue, 30 Mar 2004 07:28:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ILx-0005kF-00 for rtg-dir-archive@ietf.org; Tue, 30 Mar 2004 07:28:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8IL2-0005bb-00 for rtg-dir-archive@ietf.org; Tue, 30 Mar 2004 07:27:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8IKb-0005Sf-00 for rtg-dir-archive@ietf.org; Tue, 30 Mar 2004 07:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8IKb-0005Re-G5; Tue, 30 Mar 2004 07:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8IJy-0005Pj-7G for rtg-dir@optimus.ietf.org; Tue, 30 Mar 2004 07:26:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15423 for ; Tue, 30 Mar 2004 07:26:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8IJx-0005RQ-00 for rtg-dir@ietf.org; Tue, 30 Mar 2004 07:26:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8IJ2-0005Iy-00 for rtg-dir@ietf.org; Tue, 30 Mar 2004 07:25:24 -0500 Received: from av3-2-sn3.vrr.skanova.net ([81.228.9.110]) by ietf-mx with esmtp (Exim 4.12) id 1B8IIJ-00052u-00 for rtg-dir@ietf.org; Tue, 30 Mar 2004 07:24:39 -0500 Received: by av3-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 00B9E37E91; Tue, 30 Mar 2004 14:24:07 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id E5F5137E48; Tue, 30 Mar 2004 14:24:07 +0200 (CEST) Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id ABEC03802A; Tue, 30 Mar 2004 14:24:07 +0200 (CEST) Message-ID: <406966B6.7070907@pi.se> Date: Tue, 30 Mar 2004 14:23:18 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: loa@pi.se Cc: MPLS wg , rtg-dir@ietf.org, George Swallow , Alex Zinin Subject: Re: WG last call for draft-ietf-mpls-oam-requirements-02.txt References: <40431804.7050106@netscape.net> In-Reply-To: <40431804.7050106@netscape.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 All, this wg last call has ended. Could the authors please update (or address comments as appropriate) and re-submit the draft. /Loa Loa Andersson wrote: > WG, > > This is to initiate a WG last call for > > > > due to the ongoing IETF meeting the WG last call will end March 21 > 12PM EST. > > The drafts is intended as Proposed Standard on the standards track. > Please send comments to the mpls working group mailing list. > > -------------------------------------------------------------------- > Abstract (included as informaiton) > > As transport of diverse traffic types such as voice, frame > relay, and ATM over MPLS become more common, the ability to detect, > handle and diagnose control and data plane defects becomes > critical. > > Detection and specification of how to handle those defects is not > only important because such defects may not only affect the > fundamental operation of an MPLS network, but also because they > may impact SLA commitments for customers of that network. > > This Internet draft describes requirements for user and data > plane operations and management (OAM) for Multi-Protocol > Label Switching (MPLS). These requirements have been gathered > from network operators who have extensive experience deploying > MPLS networks, similarly some of these requirements have > appeared in other documents [Y1710]. This draft specifies OAM > requirements for MPLS, as well as for applications of MPLS such > as pseudowire voice and VPN services. Those interested in specific > issues relating to instrumenting MPLS for OAM purposes are directed > to [FRAMEWORK] > ------------------------------------------------------------------------ > > /Loa -- Loa Andersson mobile +46 739 81 21 64 From rtg-dir-admin@ietf.org Tue Mar 30 12:22:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01029 for ; Tue, 30 Mar 2004 12:22:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8MwD-00070D-00 for rtg-dir-archive@ietf.org; Tue, 30 Mar 2004 12:22:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Mw8-0006zn-00 for rtg-dir-archive@ietf.org; Tue, 30 Mar 2004 12:22:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8Mvb-0006sG-02 for rtg-dir-archive@ietf.org; Tue, 30 Mar 2004 12:21:31 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8MtX-0002ZR-1s for rtg-dir-archive@ietf.org; Tue, 30 Mar 2004 12:19:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MtL-000370-45; Tue, 30 Mar 2004 12:19:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8MYT-0001FK-U0 for rtg-dir@optimus.ietf.org; Tue, 30 Mar 2004 11:57:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28887 for ; Tue, 30 Mar 2004 11:57:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8MYS-0001rW-00 for rtg-dir@ietf.org; Tue, 30 Mar 2004 11:57:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8MXf-0001dC-00 for rtg-dir@ietf.org; Tue, 30 Mar 2004 11:56:48 -0500 Received: from av1-2-sn3.vrr.skanova.net ([81.228.9.106]) by ietf-mx with esmtp (Exim 4.12) id 1B8MW7-00014f-00 for rtg-dir@ietf.org; Tue, 30 Mar 2004 11:55:12 -0500 Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id CAE0937EB7; Tue, 30 Mar 2004 18:54:40 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id BE54037E47; Tue, 30 Mar 2004 18:54:40 +0200 (CEST) Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 8E3693801D; Tue, 30 Mar 2004 18:54:40 +0200 (CEST) Message-ID: <4069A61F.8080905@pi.se> Date: Tue, 30 Mar 2004 18:53:51 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MPLS wg , rtg-dir@ietf.org, George Swallow , Alex Zinin Subject: wg last call on draft-ietf-mpls-p2mp-requirement-02.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 WG, this mails initiates a working group last call on draft-ietf-mpls-p2mp-requirement-02.txt The document has been updated as suggested in Seoul. Comments to the working group mail list and the working group chairs. The last call end April 16. /Loa and George PS from Loa I've one immediate point myself, in the header of the document says "Standards Track", my take is that it should be "Informational", but I'm prepared to hear comments on that also. Becasue of this I'm not stting whether the doument is for Standards track or not. -- Loa Andersson mobile +46 739 81 21 64 From rtg-dir-admin@ietf.org Tue Mar 30 15:05:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07654 for ; Tue, 30 Mar 2004 15:05:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8PUV-0001rS-00 for rtg-dir-archive@ietf.org; Tue, 30 Mar 2004 15:05:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8PTZ-0001hU-00 for rtg-dir-archive@ietf.org; Tue, 30 Mar 2004 15:04:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8PSo-0001XO-00 for rtg-dir-archive@ietf.org; Tue, 30 Mar 2004 15:03:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8PSq-0005wT-IL; Tue, 30 Mar 2004 15:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8PSY-0005ld-5T for rtg-dir@optimus.ietf.org; Tue, 30 Mar 2004 15:03:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07393 for ; Tue, 30 Mar 2004 15:03:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8PSV-0001Vu-00 for rtg-dir@ietf.org; Tue, 30 Mar 2004 15:03:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8PRh-0001MA-00 for rtg-dir@ietf.org; Tue, 30 Mar 2004 15:02:49 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B8PQo-0001C8-00; Tue, 30 Mar 2004 15:01:55 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B8PQo-000AZq-Tm; Tue, 30 Mar 2004 21:01:54 +0100 Date: Tue, 30 Mar 2004 12:01:54 -0800 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1276466141.20040330120154@psg.com> To: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Bill & Alex are at IESG retreat till Thursday; slow e-mail response . EOM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit From rtg-dir-admin@ietf.org Thu Apr 1 19:20:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13308 for ; Thu, 1 Apr 2004 19:20:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9CQA-0000vX-00 for rtg-dir-archive@ietf.org; Thu, 01 Apr 2004 19:20:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9CPJ-0000pL-00 for rtg-dir-archive@ietf.org; Thu, 01 Apr 2004 19:19:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9COb-0000j6-00 for rtg-dir-archive@ietf.org; Thu, 01 Apr 2004 19:18:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9A9J-0007Po-DW; Thu, 01 Apr 2004 16:54:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B96ln-000264-Vl for rtg-dir@optimus.ietf.org; Thu, 01 Apr 2004 13:18:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24656 for ; Thu, 1 Apr 2004 13:18:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B96lb-0001Rh-00 for rtg-dir@ietf.org; Thu, 01 Apr 2004 13:18:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B96km-0001Na-00 for rtg-dir@ietf.org; Thu, 01 Apr 2004 13:17:25 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1B96k2-0001C4-00 for rtg-dir@ietf.org; Thu, 01 Apr 2004 13:16:38 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 01 Apr 2004 10:15:44 -0800 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 i31IG6A6027772; Thu, 1 Apr 2004 13:16:06 -0500 (EST) Message-Id: <200404011816.i31IG6A6027772@rtp-core-2.cisco.com> To: Loa Andersson cc: MPLS wg , rtg-dir@ietf.org, George Swallow , Alex Zinin Subject: Re: wg last call on draft-ietf-mpls-p2mp-requirement-02.txt In-reply-to: Your message of Tue, 30 Mar 2004 18:53:51 +0200. <4069A61F.8080905@pi.se> Reply-To: erosen@cisco.com 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 Date: Thu, 01 Apr 2004 13:16:01 -0500 From: Eric Rosen Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 I do not think this document should be advanced to RFC status in its current form, even as Informational. I think there are a number of problems: 1. Basically what this document says is "obviously we need a solution which provides traffic engineered multicast distribution trees, and we require that the solution be RSVP-TE extensions for setting up multicast distribution trees". The problem to which this is a solution is not very well characterized or explored, so it is hard to judge from this document whether this particular solution is the best one. There is no serious consideration of alternatives, so we don't know really know why one particular solution should be required over another. In any event, the requirements should be general enough so that we can compare various solutions to them. If the requirement is "use RSVP-TE", it's hard to compare other solutions against it. The solution being required might be the best solution to some problem, but one really can't tell from this document. 2. The document attempts to exhibit the required solution as being a good solution for a variety of problems being considered by other WGs, such as L2VPN, L3VPN, and PWE3. However, the solutions which this document sketches out are not fully thought out, and fail to consider a variety of thorny issues. For example: - Providing ethernet multicast support is more complex than merely setting up a P2MP LSP, as the ethernet specs pose ordering requirements that would be violated unless unicast packets were also sent on the multicast tree. - The suggestion to use this solution for VPN multicast seems to clash with existing proposals for VPN multicast, but this is not even considered. Frankly, if we are looking for requirements that apply to L2VPN and L3VPN problems, we should be getting the requirements from those WGs, not telling those WGs that they are required to use a particular solution. 3. There is a "requirement" that the solution be applicable to GMPLS as well as MPLS. I don't see where this requirement comes from. For all I know, GMPLS might introduce a variety of additional complications that aren't necessary in MPLS. If this is so, I would not necessarily support using the same solution in both cases. 4. There is a "requirement" that it be possible to set up multicast distribution trees without using multicast routing protocols. Presumably the assumption is that setting up the distribution trees is greatly simplified if multicast routing is not used. While this may be true, it certainly needs to be argued in more detail. I think we also need to understand better whether TE multicast trees can be mixed in a network with non-TE multicast trees. 5. Central to the original design of RSVP was the goal of using it to establish QoS for multicast distribution trees. This might make one think that RSVP could be combined with PIM to allow for dynamically created distribution trees to which QoS can be applied. However, this possibility seems to be immediately ruled out by the "requirements". It's not very clear whether the use of PIM to set up multicast distribution trees is supposed to be compatible or incompatible with the traffic engineering of those trees. 6. The requirement that RSVP be enhanced so that it can add/remove receivers dynamically raises the question of whether too much multicast stuff is being moved into RSVP. Do we need to invent new multicast join/prune mechanisms? What's wrong with the ones we already have? 7. The document has a number of places where it is asserted that something is or is not "optimal" or "efficient", without any statement of just what resource is being used suboptimally or inefficiently. 8. It is not clear to me whether these "requirements" rule out (or are intended to rule out) the use of bidirectional multicast trees. 9. There is mention of using RSVP-TE multicast LSPs to carry layer 2 traffic, apparently without a PWE3 encapsulation. This might be taken to infringe upon PWE3's charter. 10. It is blithely stated that RSVP-TE multicast allows for the creation of inter-AS multicast distribution trees. Since inter-AS considerations have proven to be quite thorny for both multicast and TE, it is hard to imagine that combining multicast with TE makes the inter-AS considerations any simpler. So I think the document needs considerable additional work before we can consider advancing it. By the way, these comments should not be interpreted as an objection to extending RSVP-TE to support multicast traffic engineering. The comments are directed specifically at the particular document under discussion, and are not meant to favor or disfavor any particular solution. From rtg-dir-admin@ietf.org Fri Apr 2 00:26:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10614 for ; Fri, 2 Apr 2004 00:26:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9HCR-0005k7-00 for rtg-dir-archive@ietf.org; Fri, 02 Apr 2004 00:26:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9HBX-0005bF-00 for rtg-dir-archive@ietf.org; Fri, 02 Apr 2004 00:25:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9HAb-0005Ta-00 for rtg-dir-archive@ietf.org; Fri, 02 Apr 2004 00:24:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E6I-0004uV-IH; Thu, 01 Apr 2004 21:08:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9B5q-0003YP-4f for rtg-dir@optimus.ietf.org; Thu, 01 Apr 2004 17:55:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06045 for ; Thu, 1 Apr 2004 17:55:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9B5n-0006AO-00 for rtg-dir@ietf.org; Thu, 01 Apr 2004 17:55:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9B4r-00065J-00 for rtg-dir@ietf.org; Thu, 01 Apr 2004 17:54:26 -0500 Received: from cerberus.uk.clara.net ([195.8.69.103]) by ietf-mx with esmtp (Exim 4.12) id 1B9B4L-00060i-00 for rtg-dir@ietf.org; Thu, 01 Apr 2004 17:53:53 -0500 Received: from du-069-0333.access.clara.net ([217.158.145.79] helo=Puppy) by cerberus.uk.clara.net with smtp (Exim 4.22) id 1B9B4G-000J12-51; Thu, 01 Apr 2004 23:53:49 +0100 Message-ID: <014d01c4183c$33b6aa10$7a9c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Eric Rosen" , "Loa Andersson" Cc: "MPLS wg" , , "George Swallow" , "Alex Zinin" References: <200404011816.i31IG6A6027772@rtp-core-2.cisco.com> Subject: Re: wg last call on draft-ietf-mpls-p2mp-requirement-02.txt Date: Thu, 1 Apr 2004 23:52:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Hi Eric, We certainly welcome your detailed review. To cover a general point first, the scope of the document is to provide "Requirements for Point to Multipoint extension to RSVP-TE" as requested by the WG. This scope clearly does not cover the questions: - do we need multicast TE? - is RSVP-TE the right protocol for multicast TE? These may be valid questions for the WG, although by the charter items (and the ruling on RSVP-TE as the only MPLS TE protocol) I had assumed that the decision had already been taken. Perhaps it was not sufficiently widely discussed. Further comment in line. > I do not think this document should be advanced to RFC status in its current > form, even as Informational. I think there are a number of problems: > > 1. Basically what this document says is "obviously we need a solution which > provides traffic engineered multicast distribution trees, and we require > that the solution be RSVP-TE extensions for setting up multicast > distribution trees". > > The problem to which this is a solution is not very well characterized or > explored, so it is hard to judge from this document whether this > particular solution is the best one. There is no serious consideration > of alternatives, so we don't know really know why one particular > solution should be required over another. In any event, the requirements > should be general enough so that we can compare various solutions to > them. If the requirement is "use RSVP-TE", it's hard to compare other > solutions against it. > > The solution being required might be the best solution to some problem, > but one really can't tell from this document. As per the note at the head of the email. The problem that is addressed is as specified in the title of the document. > 2. The document attempts to exhibit the required solution as being a good > solution for a variety of problems being considered by other WGs, such as > L2VPN, L3VPN, and PWE3. However, the solutions which this document > sketches out are not fully thought out, and fail to consider a variety of > thorny issues. For example: > > - Providing ethernet multicast support is more complex than merely > setting up a P2MP LSP, as the ethernet specs pose ordering requirements > that would be violated unless unicast packets were also sent on the > multicast tree. Is this problem not identical with parallel unicast LSPs? > - The suggestion to use this solution for VPN multicast seems to clash > with existing proposals for VPN multicast, but this is not even > considered. > > Frankly, if we are looking for requirements that apply to L2VPN and L3VPN > problems, we should be getting the requirements from those WGs, not > telling those WGs that they are required to use a particular solution. It is certainly not the intention to tell anyone how to solve any other problem, merely to characterise the requirements on RSVP-TE if it were to be used to solve a particular problem. It would clearly be bad news to extend RSVP-TE for P2MP and miss a key requirement. > 3. There is a "requirement" that the solution be applicable to GMPLS as well > as MPLS. I don't see where this requirement comes from. For all I know, > GMPLS might introduce a variety of additional complications that aren't > necessary in MPLS. If this is so, I would not necessarily support using > the same solution in both cases. Well, you know we differ on this subject slightly :-) It is my understanding that the requirement comes from the ADs. But, if GMPLS does not introduce a variety of additional complications, it would surely be sensible to have the same protocol extensions in both MPLS and GMPLS. Further, if a minor tweak to the MPLS solution made it equally applicable to GMPLS, wouldn't that be a good thing all round? So, yes, a value judgement could be made about the complexity introduced to MPLS by harmonizing with GMPLS. > 4. There is a "requirement" that it be possible to set up multicast > distribution trees without using multicast routing protocols. Presumably > the assumption is that setting up the distribution trees is greatly > simplified if multicast routing is not used. While this may be true, it > certainly needs to be argued in more detail. I think we also need to > understand better whether TE multicast trees can be mixed in a network > with non-TE multicast trees. An interesting question. One might consider extending a multicast routing protocol to support TE, but I suspect this may be quite a complex problem. Why is it not enough to allow the TEDB at the ingress (or offline) to be processed to derive the multicast distribution tree? This is, after all, a TE (explicitly routed) solution not one of hop-by-hop forwarding. > 5. Central to the original design of RSVP was the goal of using it to > establish QoS for multicast distribution trees. This might make one > think that RSVP could be combined with PIM to allow for dynamically > created distribution trees to which QoS can be applied. However, this > possibility seems to be immediately ruled out by the "requirements". > It's not very clear whether the use of PIM to set up multicast > distribution trees is supposed to be compatible or incompatible with the > traffic engineering of those trees. The requirements rule out depending on any multicast protocol. They do not rule out using one. I would emphasise that this draft in no way detracts from multicast routing, but simply recognises that TE is a different problem space from multicast IP. > 6. The requirement that RSVP be enhanced so that it can add/remove receivers > dynamically raises the question of whether too much multicast stuff is > being moved into RSVP. Do we need to invent new multicast join/prune > mechanisms? What's wrong with the ones we already have? Nothing. No mention is made of how the ingress discovers who is in a destination set when it builds a multicast distribution tree and uses that to signal a P2MP LSP for TE purposes. All that is stated is that receivers are expected to come and go. Consequent on this if the requirement that it should be possible to add and remove receivers from the LSP. > 7. The document has a number of places where it is asserted that something > is or is not "optimal" or "efficient", without any statement of just what > resource is being used suboptimally or inefficiently. Agreed these terms are subjective and are, perhaps, used a little freely. If I search for "optimal" I find... Section 1 - there is a reasonable statement about what is found to be suboptimal Section 3.1 - the subsequent sentence gives a statement about what is required (but this could be clarified). Section 3.1 (2nd usage) - the subsequent sentence gives a clear description Section 5.8 - this usage is deliberately vague since it refers to reoptimization as described in section 2.5 of RFC3209 If I search for "efficient" I find... Section 1 - "efficient" here contrasts with the previous paragraph. This could be clearer especially as such a bold statement is made. Section 1 (2nd usage) - I think this is clear in the context of the previous text, but there would be no harm in explaining the word in the context of packet or data replication. Section 3.1 - Here is a good example of "efficient resource optimization" with no further details. To some extent, this is using the terminology as used in section 2.2 of RFC3209, but we could probably set out a bit more explicitly what we mean by a network resource. Section 3.1 (2nd usage) - as section 1 2nd usage Section 3.2 - I think be this point we will have established what is meant in this context > 8. It is not clear to me whether these "requirements" rule out (or are > intended to rule out) the use of bidirectional multicast trees. MPLS LSPs are unicast. GMPLS supports bidirectional LSPs. Section 5.16 states... Finally, note that bi-directional TE LSPs are not applicable to multicast traffic. Although many leaf nodes may be considered as senders in a multicast group, a P2MP TE LSP models a single distribution tree from a sender to multiple recipients. If such a tree were made bi-directional it would be a multipoint-to-point tree in the reverse direction. Thus, if you want to model bidirectional multicast trees you would be required to set up multiple LSPs. Do you believe we should add a section outlining the requirements for bidirectional multicast trees? Do you think they are required for TE or is TE a way of supporting them? > 9. There is mention of using RSVP-TE multicast LSPs to carry layer 2 > traffic, apparently without a PWE3 encapsulation. This might be taken to > infringe upon PWE3's charter. Well, the text only floats some options and certainly doesn't tell anyone that they have to use this facility. No intent to treat on anyone's shadow. If this infringes then I'm sure we'd happily delete the text. Alternatively, we would happily be corrected if the suggestions are wrong or need refinement - and especially if additional requirements are imposed by the support of this function. > 10. It is blithely stated that RSVP-TE multicast allows for the creation of > inter-AS multicast distribution trees. Since inter-AS considerations > have proven to be quite thorny for both multicast and TE, it is hard to > imagine that combining multicast with TE makes the inter-AS > considerations any simpler. Blithe? I trust not. I rarely make jokes in IDs and I certainly couldn't be described as sprightly. Actually, I don't find anything that says "that RSVP-TE multicast allows for the creation of inter-AS multicast distribution trees." I do find... Section 4.1 Note that a P2MP TE LSP can be established over multiple areas/ASs and that the egress LSRs may deliver data into an IP multicast network. I agree that this should be toned down to something like... Note that the egress LSRs of a P2MP TE LSP may deliver data into IP multicast networks. There is also a long-term requirement to support P2MP TE LSPs that cross area/AS boundaries. Section 5.3 Note that a P2MP TE LSP can be established over multiple areas/ASs and that the egress LSRs may deliver data into an IP multicast network. A true, but rather skimpy statement. Could use some flesh, but given that multi-area/AS is largely out of scope (see below) I'm not sure that we should add to it except to refer to section 5.12. and finally 5.12 Multi-Area/AS LSP P2MP TE solutions SHOULD support multi-area/AS P2MP LSPs. The precise requirements in support of multi-area/AS P2MP LSPs is out of the scope of this document. It is expected that a separate document will cover this requirement. This last point reflects exactly your concern, and I agree with you whole-heartedly. That is why we asked in Seoul and got agreement to defer such a complex matter for a future requirements statement once there is more experience with both P2MP and inter-area/AS TE. > So I think the document needs considerable additional work before we can > consider advancing it. Can you help us narrow it down? Some of the points you raise need some editorial attention (as is typical in last call). Other points may be sticking points for you. With my explanations/comments in place, can you tell us which these are. > By the way, these comments should not be interpreted as an objection to > extending RSVP-TE to support multicast traffic engineering. The comments > are directed specifically at the particular document under discussion, and > are not meant to favor or disfavor any particular solution. Thanks again for your thorough review of the document. Cheers, Adrian From rtg-dir-admin@ietf.org Sat Apr 3 08:00:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19361 for ; Sat, 3 Apr 2004 08:00:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9klS-0001sf-00 for rtg-dir-archive@ietf.org; Sat, 03 Apr 2004 08:00:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9kkZ-0001m7-00 for rtg-dir-archive@ietf.org; Sat, 03 Apr 2004 07:59:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9kjl-0001fG-00 for rtg-dir-archive@ietf.org; Sat, 03 Apr 2004 07:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9kjl-0000sQ-C0; Sat, 03 Apr 2004 07:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9kjY-0000re-7F for rtg-dir@optimus.ietf.org; Sat, 03 Apr 2004 07:58:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19297 for ; Sat, 3 Apr 2004 07:58:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9kjX-0001e9-00 for rtg-dir@ietf.org; Sat, 03 Apr 2004 07:58:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9kiY-0001Wz-00 for rtg-dir@ietf.org; Sat, 03 Apr 2004 07:57:47 -0500 Received: from [61.187.19.216] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1B9khb-0001KS-00; Sat, 03 Apr 2004 07:57:07 -0500 Received: from 72.208.244.178 by 61.187.19.216; Sat, 03 Apr 2004 15:58:10 +0300 Message-ID: From: "Walter Lucero" Reply-To: "Walter Lucero" To: rtg-dir@ietf.org Subject: Purchase Prescription Medication Here Without Any Prescription. Overnight FedEx Date: Sat, 03 Apr 2004 18:52:10 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--48314634869294439254" X-IP: 106.176.153.140 X-Priority: 3 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=AWL,BIZ_TLD,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME, RCVD_NUMERIC_HELO autolearn=no version=2.60 ----48314634869294439254 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Hello,

Cialis, Phentermine, Viagra, Soma, Ambien, Levitra, Floricet, Imitrex, Paxil, Prozac, Zoloft . . . and many many more prescription drugs!

We are your private source for FDA Approved prescription medications. Once we receive your orders and one of our 24x7 onboard US Physicians will approve of your order (99.9% granted).

Orders approved by 2 pm EST will receive their medication next business day via FedEX! (where available)

Start Saving. Order your Medications Here

Bbilayer trojan outlawry compute hempstead grist btl ought scrotum reeve manslaughter positive ! Apolitician surround watergate tarantara yost claustrophobia phoenix bassi donaldson caine cheesecake otherworld pretoria chanson . Uboo carbon sawmill bucket hyde brash cancel josef alicia brownell session saran atmospheric exudation clod stealthy samoa affirmation consider decryption song celibacy angular drown conscious echinoderm forrest wreath cannel enunciable rig bellatrix bullfrog appetite immodest biotic limp devon pony smudge baron piston bombast teletype infamous cedar orchestrate hartman eluate archive guerrilla conscientious lucky mayhem janice .

If this notice has reached you in error, please notify us by clicking here ----48314634869294439254-- From rtg-dir-admin@ietf.org Sun Apr 4 11:27:51 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02947 for ; Sun, 4 Apr 2004 11:27:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA9XM-0004f8-00 for rtg-dir-archive@ietf.org; Sun, 04 Apr 2004 11:27:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BA9WW-0004ZB-00 for rtg-dir-archive@ietf.org; Sun, 04 Apr 2004 11:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA9WW-0007Fi-Ba; Sun, 04 Apr 2004 11:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BA9WO-0007FX-VZ for rtg-dir@optimus.ietf.org; Sun, 04 Apr 2004 11:26: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 LAA02906 for ; Sun, 4 Apr 2004 11:26:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BA9WO-0004YF-00 for rtg-dir@ietf.org; Sun, 04 Apr 2004 11:26:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BA9VK-0004Sn-00 for rtg-dir@ietf.org; Sun, 04 Apr 2004 11:25:47 -0400 Received: from host3.btamail.net.cn ([202.106.196.73] helo=btmail.net.cn) by ietf-mx with smtp (Exim 4.12) id 1BA9Uo-0004NQ-00 for rtg-dir@ietf.org; Sun, 04 Apr 2004 11:25:14 -0400 Subject: Mail Error Date: 04 Apr 2004 23:25:10 GMT From: "Jetmail System" <> To: rtg-dir@ietf.org Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.3 required=5.0 tests=BTAMAIL_URL, DATE_IN_FUTURE_06_12,FROM_NO_USER,MSGID_FROM_MTA_SHORT autolearn=no version=2.60 X-Spam-Report: * 1.3 FROM_NO_USER From: has no local-part before @ sign * 2.8 BTAMAIL_URL URI: Frequent Spam content * 1.9 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Your mail cannot be delivered to the following address(es): deathmask "(2), ErrMsg=mail box space not enough, account=deathmask " Please check the above address(es) and then try again. ---- Header of the source mail attached ---- Received: from btamail.net.cn([211.67.24.168]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm3e407085d7; Sun, 4 Apr 2004 15:25:09 -0000 From: rtg-dir@ietf.org To: deathmask@btamail.net.cn Subject: Mail Delivery (failure deathmask@btamail.net.cn) Date: Sun, 4 Apr 2004 23:25:30 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA80.6B015D10" X-Priority: 3 X-MSMail-Priority: Normal From rtg-dir-admin@ietf.org Mon Apr 5 09:17:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29080 for ; Mon, 5 Apr 2004 09:17:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATz1-0003Dh-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 09:17:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BATyG-00035A-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 09:17:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATyH-00059V-4W; Mon, 05 Apr 2004 09:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BATxf-00054q-Ay for rtg-dir@optimus.ietf.org; Mon, 05 Apr 2004 09:16: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 JAA29004 for ; Mon, 5 Apr 2004 09:16:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BATxd-00031G-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 09:16:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BATwf-0002rk-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 09:15:22 -0400 Received: from [213.154.86.159] (helo=helimore1470.com) by ietf-mx with smtp (Exim 4.12) id 1BATvd-0002c7-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 09:14:18 -0400 From: "LOTTERY AWARD DEPT" To: rtg-dir@ietf.org Date: Mon, 5 Apr 2004 13:18:13 +0000 Subject: LOTTERY WIN NOTIFICATION X-Mailer: Microsoft Outlook Express 5.00.2919.6900 DM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.3 required=5.0 tests=FORGED_MUA_OUTLOOK, FROM_NO_LOWER,LINES_OF_YELLING,LINES_OF_YELLING_2, MSGID_FROM_MTA_SHORT,RATWARE_OE_MALFORMED,SUBJ_ALL_CAPS autolearn=no version=2.60 X-Spam-Report: * 1.9 FROM_NO_LOWER 'From' has no lower-case characters * 2.8 RATWARE_OE_MALFORMED X-Mailer has malformed Outlook Express version * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 0.6 SUBJ_ALL_CAPS Subject is all capitals * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable INTL=2E LOTTERY COMISSION CALLE SAN BERNADO 2 5C 28009 MADRID SPAIN=2E FROM=3A THE DIRECTOR OF THE PRIZE AWARD DEPARTMENT REF=3A NO EG=2F38807886091=2F04BATCH=3A 340=2F1608=2FRDL=2E ATTN=3A WINNER =2C RE=3A AWARD NOTIFICATION FINAL NOTICE=2E We are pleased to inform you of the release on 26=2F27 March=2C 2004 of the result of the FLASH FORTUNE LOTTO=2C Spanish sweepstake lottery Int promotion=2E Programs held on the 22th=2CFebuary 2004=2EDue to the holidays and recent Bomb-Blast in Spain-Madrid we were unable to contact our Winners ealier=85=2E=2E Your name and email adress attached to the ticket number 033-1146993-750 with serial number 1223-05 drew the lucky number 13-15-16-21-34-36 which consequently won lottery in the 2nd category=2E You are therefore been approved for a lump sum of 815=2E810=2E00 =28Eight hundred and fifteen thousand=2C eight hundred and ten euro=29=2Ein cash credited to the file No EG=2F38807886091=2F04=2C this is from the total cash prize of 13=2C868=2C770=2E00 =28Thirteen million Eight hundred and sixty eight thousand=2C seven hundred and seventy Euro=29=2C shared among the seventeen international winners in this category=2E Your fund is now deposited with a security company insured in your name Due to mixed up of some numbers and names =2Cwe ask that you keep this award top secret from public notice until your claims has been processed and your money remitted to your account as this is part of our security protocol to avoid double claiming or unwarranted taking of advantage of this program by participants=2EAll participants were selected through a computer ballot system drawn from 25=2C000 names from all over the world as a part of our International promotion program which we conduct twice every year =2EWe hope with a part of your prize you will take part in our end of the year high stake US$1=2E3bn lottery=2E To avoid scam please contact only your assigned agent below=2E To begin your claim=2C please contact your claim agent=3A Mr=2E FRED COLLINS=2C The Foreign Service manager of DMTFINANCE $ SECURITY=2C On Tel=3A 00221 574 10 64 and email=3Asantir=40globalprolific=2Enet=2E for processing and remittance of your money to a designated account of your choice=2E Remember all prize money must be claimed not later than 2 weeks from the date of this notice after this date all Funds will be returned to the ministerio de economia y hacienda as Unclaimed=2E Note in order to avoid unnecessary delays and complications=2C please quote your ref =2EAnd batch no=2E in every correspondence with your agent=2E Further more shall there be any change of address=2C do please inform your claims agent as soon as possible=2ECongratulations again from all members of staff and thank you for being a part of our promotions program=2E Yours Sincerely MANAGEMENT NB=3AContact our agent in Dakar Senegal for the onward transfer of your funds=2EDo not reply to this email=2E From rtg-dir-admin@ietf.org Mon Apr 5 17:02:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09394 for ; Mon, 5 Apr 2004 17:02:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAbEn-0003rc-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 17:02:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAb3Q-0001hY-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 16:50:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAace-0006b3-03 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 16:23:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaO5-000527-2n; Mon, 05 Apr 2004 16:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAaNa-0004jt-QF for rtg-dir@optimus.ietf.org; Mon, 05 Apr 2004 16:07: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 QAA04213 for ; Mon, 5 Apr 2004 16:07:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAaNZ-0005EO-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 16:07:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAaJq-0004Sk-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 16:03:45 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BAa9E-0002Xf-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 15:52:44 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2004 13:02:01 -0700 X-BrightmailFiltered: true Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i35JqBcp015638; Mon, 5 Apr 2004 15:52:11 -0400 (EDT) Message-Id: <200404051952.i35JqBcp015638@rtp-core-1.cisco.com> To: "Adrian Farrel" cc: "Loa Andersson" , "MPLS wg" , rtg-dir@ietf.org, "George Swallow" , "Alex Zinin" Subject: Re: wg last call on draft-ietf-mpls-p2mp-requirement-02.txt In-reply-to: Your message of Thu, 01 Apr 2004 23:52:37 +0100. <014d01c4183c$33b6aa10$7a9c9ed9@Puppy> Reply-To: erosen@cisco.com 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 Date: Mon, 05 Apr 2004 15:52:11 -0400 From: Eric Rosen Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Adrian> To cover a general point first, the scope of the document is to Adrian> provide "Requirements for Point to Multipoint extension to RSVP-TE" Adrian> as requested by the WG. This scope clearly does not cover the Adrian> questions: Adrian> - do we need multicast TE? Adrian> - is RSVP-TE the right protocol for multicast TE? Well, I found the title ambiguous; I couldn't tell whether it means (a) "Extensions to RSVP-TE are required, and here's why", or (b) "If we ever decide that P2MP Extensions to RSVP-TE are needed, here are some conditions those extensions must satisfy". I think you're saying now that it means (b), but I'm not sure it is sensible to argue for (b) without also arguing for (a). How do we know what the requirements for extending RSVP-TE are if we don't understand, e.g., the requirements for mixing TE multicast and non-TE multicast in the same network. As another example, in the realm of unicast we have a pretty good understanding of how traffic moves between TE areas and non-TE area; do we have the same understanding for multicast? Adrian> These may be valid questions for the WG, although by the charter Adrian> items (and the ruling on RSVP-TE as the only MPLS TE protocol) I had Adrian> assumed that the decision had already been taken. Perhaps it was not Adrian> sufficiently widely discussed. I'm sure there will be people who say that TE should be done by extending existing multicast routing protocols. Or by using RSVP in combination with existing multicast routing protocols. If we do not think this is the case, we need a stronger argument than "it's required by charter". Eric> Providing ethernet multicast support is more complex than merely Eric> setting up a P2MP LSP, as the ethernet specs pose ordering Eric> requirements that would be violated unless unicast packets were also Eric> sent on the multicast tree. Adrian> Is this problem not identical with parallel unicast LSPs? Not sure what you're asking. Adrian> It is certainly not the intention to tell anyone how to solve any Adrian> other problem, merely to characterise the requirements on RSVP-TE if Adrian> it were to be used to solve a particular problem. It would clearly Adrian> be bad news to extend RSVP-TE for P2MP and miss a key requirement. Unless the document has been given careful consideration by folks working on all the various problems that might be solved via multicast TE, how do we know we haven't missed a requirement? Eric> There is a "requirement" that the solution be applicable to GMPLS as Eric> well as MPLS. I don't see where this requirement comes from. For all Eric> I know, GMPLS might introduce a variety of additional complications Eric> that aren't necessary in MPLS. If this is so, I would not necessarily Eric> support using the same solution in both cases. Adrian> It is my understanding that the requirement comes from the ADs. Then your document should clearly distinguish the requirements that are there because of politics from the requirements that are there for technical reasons ;-) Adrian> But, if GMPLS does not introduce a variety of additional Adrian> complications, it would surely be sensible to have the same protocol Adrian> extensions in both MPLS and GMPLS. Further, if a minor tweak to the Adrian> MPLS solution made it equally applicable to GMPLS, wouldn't that be Adrian> a good thing all round? Absolutely. Does GMPLS introduce such complications? I have no idea. If GMPLS introduces requirements of its own, these should be clearly stated in the document. If GMPLS introduces no new requirements of its own, then there's no issue, of course. But what I get from the document is "we don't know what additional requirements GMPLS may introduce, but whatever they are, they must be satisfied by the MPLS solution." I don't think that is a reasonable position to take. Adrian> Why is it not enough to allow the TEDB at the ingress (or offline) Adrian> to be processed to derive the multicast distribution tree? It's not completely obvious what this means, given the way that receivers dynamically join and leave multicast groups. It's worth noting that existing multicast tree creation protocols tend to set up the tree from the receivers to the transmitters, while this draft seems to be requiring the reverse. A discussion of this difference would be useful. Adrian> This is, after all, a TE (explicitly routed) solution not one of Adrian> hop-by-hop forwarding. Well, in unicast TE is not exactly synonymous with "explicit routing". Using the TE toolset you have a mixture of strict routes, loose routes, tunnels, aggregation. constraint-based routing, admissions control, bandwidth guarantees, link protection, node protection, etc., etc. If one were doing a "requirements for multicast traffic engineering", one would have to understand the applicability of all these things to multicast. >> 5. Central to the original design of RSVP was the goal of using it to >> establish QoS for multicast distribution trees. This might make one >> think that RSVP could be combined with PIM to allow for dynamically >> created distribution trees to which QoS can be applied. However, this >> possibility seems to be immediately ruled out by the "requirements". >> It's not very clear whether the use of PIM to set up multicast >> distribution trees is supposed to be compatible or incompatible with the >> traffic engineering of those trees. Adrian> The requirements rule out depending on any multicast protocol. They Adrian> do not rule out using one. Insofar as there is no requirement for the extended RSVP-TE to interwork with non-TE multicast in any way, a solution which meets the requirements might be incompatible with existing multicast paradigms. Whether this is satisfactory needs to be thought out more fully. Adrian> I would emphasise that this draft in no way detracts from multicast Adrian> routing, but simply recognises that TE is a different problem space Adrian> from multicast IP. I would say it presupposes that TE is a different problem space, but I think this deserves some analysis. Adrian> No mention is made of how the ingress discovers who is in a Adrian> destination set when it builds a multicast distribution tree and Adrian> uses that to signal a P2MP LSP for TE purposes. There needs to be some discussion of the requirements for this discovery process. In "conventional" multicast, this discovery is often based on the multicast routing protocol itself. I read the document as indicating that RSVP be extended (somehow) to provide this discovery capability, but it's not completely obvious that that's the way to go. Adrian> All that is stated is that receivers are expected to come and go. Adrian> Consequent on this if the requirement that it should be possible to Adrian> add and remove receivers from the LSP. Can't argue with that one. Eric> The document has a number of places where it is asserted that Eric> something is or is not "optimal" or "efficient", without any statement Eric> of just what resource is being used suboptimally or inefficiently. Adrian> Agreed these terms are subjective and are, perhaps, used a little Adrian> freely. Adrian> If I search for "optimal" I find... I'm not going to go through the use of the term occurrence by occurrence ;-) But I've found that in talking about the scalability/optimality/efficiency etc. of multicast schemes, it is best to be very specific. For example, every multicast scheme claims to be scalable, but some scale well as the number of receivers increases, but not as the number of transmitters increases. Some scale well as the number of transmitters increases, but not as the amount of traffic increases. Some scale well as the amount of traffic increases, but not as the number of groups increases. Some are optimal in that every packet follows an optimal route, but at the same time sub-optimal in the amount of state kept in the network core. Some are optimized for dynamic join/prune operations, some not. I'd think that this sort of thing needs to be discussed carefully in a requirements document. Eric> 8. It is not clear to me whether these "requirements" rule out (or are Eric> intended to rule out) the use of bidirectional multicast trees. Adrian> Do you believe we should add a section outlining the requirements Adrian> for bidirectional multicast trees? Do you think they are required Adrian> for TE or is TE a way of supporting them? I think the requirements document needs to take one of two positions. Either (a) it is necessary to apply TE to bidir trees, and here are the requirements, or else (b) it is not necessary to apply TE to bidir trees, and here is why not. >> 9. There is mention of using RSVP-TE multicast LSPs to carry layer 2 >> traffic, apparently without a PWE3 encapsulation. This might be taken to >> infringe upon PWE3's charter. Adrian> Well, the text only floats some options and certainly doesn't tell Adrian> anyone that they have to use this facility. I would suggest deleting the suggestions on how multicast TE might be used to solve VPN or PWE3 problems. These suggestions tend to make multicast TE look like a solution in search of a problem. On the inter-AS requirements, from the draft: P2MP TE solutions SHOULD support multi-area/AS P2MP LSPs. The precise requirements in support of multi-area/AS P2MP LSPs is out of the scope of this document. It is expected that a separate document will cover this requirement. Adrian> This last point reflects exactly your concern, and I agree with you Adrian> whole-heartedly. That is why we asked in Seoul and got agreement to Adrian> defer such a complex matter for a future requirements statement once Adrian> there is more experience with both P2MP and inter-area/AS TE. How do we know that a solution designed to the current requirements will meet those future requirements? Especially given the difficulties that have been encountered in extending both TE and multicast over multiple providers, why do we think that the RSVP-TE solution will meet this requirement? Eric> So I think the document needs considerable additional work before we Eric> can consider advancing it. Adrian> Can you help us narrow it down? Gee, I thought I had. Insofar as these requirements lead toward a solution which is very different than existing multicast paradigms, these differences should be addressed and justified. I don't see any reason why multicast TE would not be expected to coexist with and interwork with non-TE multicast, but I don't see how that would work with a TE solution that meets these requirements. Each of the various capabilities that TE provides should be discussed, to see the requirements that each such capability places on multicast. Insofar as the requirements tend to lead toward one solution rather than another, the requirements need to have some justification. From rtg-dir-admin@ietf.org Mon Apr 5 19:10:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20642 for ; Mon, 5 Apr 2004 19:10:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAdEg-0003At-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 19:10:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAcw6-0000bh-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 18:51:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAcSg-0005PU-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 18:20:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAcSj-0006KB-4T; Mon, 05 Apr 2004 18:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAcSW-0006IS-9Q for rtg-dir@optimus.ietf.org; Mon, 05 Apr 2004 18:20: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 SAA16758 for ; Mon, 5 Apr 2004 18:20:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAcST-0005OO-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 18:20:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAcCj-0003Vh-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 18:04:30 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BAbwX-0000SP-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 17:47:46 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BAbwY-0007Lq-8T for rtg-dir@ietf.org; Mon, 05 Apr 2004 21:47:46 +0000 Date: Mon, 5 Apr 2004 14:47:45 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1411756003.20040405144745@psg.com> To: rtg-dir@ietf.org Subject: Re: Other pieces of the MT-routing "puzzle"? In-Reply-To: <1487061323.20040326090444@psg.com> References: <11424532976.20040325183459@psg.com> <40645E73.4040307@net4u.ch> <1487061323.20040326090444@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit More opinions on this? -- Alex http://www.psg.com/~zinin/ Friday, March 26, 2004, 10:04:44 AM, Alex Zinin wrote: > Friday, March 26, 2004, 8:46:43 AM, Tony Przygienda wrote: >> The problem space has been clasified in mt-isis draft version #6, >> section 12 more than a year >> ago. > It was apparently a long time ago when I read this draft. > Now that I look at it, you're right, the document indeed classifies > the problem space. Using the draft's words, my general sentiment > is whether this-- >> 12.2.2. Multiple MTs share an interface with overlapping addresses > ... >> The generic approach of packet to multiple MT RIB mapping over >> the same inbound interface is outside the scope of this draft. > --should be addressed. > Alex From rtg-dir-admin@ietf.org Mon Apr 5 20:29:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26856 for ; Mon, 5 Apr 2004 20:29:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAeT1-0004G5-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 20:29:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAe5C-0001iK-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 20:04:50 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAdm1-0006h8-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 19:45:01 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAdm2-0002lt-Db for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 19:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAdm1-0000kn-Jf; Mon, 05 Apr 2004 19:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAdlB-0000e2-SP for rtg-dir@optimus.ietf.org; Mon, 05 Apr 2004 19:44: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 TAA22455 for ; Mon, 5 Apr 2004 19:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAdlA-0006XK-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 19:44:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAdIG-0003ha-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 19:14:16 -0400 Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1BAd5h-0002J9-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 19:01:17 -0400 Message-ID: From: Jeff Parker To: "'Alex Zinin'" , rtg-dir@ietf.org Subject: Should we address conflicting addresses on single MT interface? Date: Mon, 5 Apr 2004 19:00:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Alex - quoting from http://www.ietf.org/proceedings/03jul/I-D/draft-ietf-isis-wg-multi-topology- 06.txt >> 12.2.2. Multiple MTs share an interface with overlapping addresses Some additional mechanism is needed to select the correct RIBs for the incoming IP packets to determine the correct RIB to make a forwarding decision. For example, if the topologies are QoS partitioned, then the DSCP bits in the IP packet header can be utilized to make the decision. Some IP header or even packet data information may be checked to make the forwarding table selection, such as source IP address in the header can be used to determine the desired forwarding behavior. >> The generic approach of packet to multiple MT RIB mapping over >> the same inbound interface is outside the scope of this draft. I assume that the motivation to sort this out would be to provide interoperable implementations. The draft defines a mechanism, and leaves open the definition of particulars in this case. Is this something that needs to be decided now? Are there competing interpretations? Are there competing demands for this functionality? I see the value in having agreement, but wonder if we have enough experience with the idea to know how ISPs would want to use it tomorrow. - jeff parker From rtg-dir-admin@ietf.org Mon Apr 5 20:57:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29792 for ; Mon, 5 Apr 2004 20:57:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAetz-0007jK-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 20:57:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAeda-0005Rl-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 20:40:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAeFL-0002st-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 20:15:19 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAe5S-0003ru-N4 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 20:05:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAe5Q-0006L8-Ny; Mon, 05 Apr 2004 20:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAe5K-0006IY-IT for rtg-dir@optimus.ietf.org; Mon, 05 Apr 2004 20:04: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 UAA25115 for ; Mon, 5 Apr 2004 20:04:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAe5I-0001j1-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 20:04:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAdm6-0006hd-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 19:45:08 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BAdJH-0003uf-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 19:15:19 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BAdJB-0004Mq-BF; Mon, 05 Apr 2004 23:15:13 +0000 Date: Mon, 5 Apr 2004 16:15:11 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <179540304.20040405161511@psg.com> To: "Vishal Sharma" CC: "Greg Bernstein" , "Eric Mannie" , "Adrian Farrel" , "Kireeti Kompella" , "Bert Wijnen" , Subject: Re: Responses: AD-review comments on draft-ietf-ccamp-sdhsonet-control In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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, SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Vishal, I'm cc'ing the RTG-DIR so Dimitri can follow up with you directly if necessary. Most of the replies are fine, some comments inline below, pls. Dimitri will follow up on the rest. Thanks. -- Alex http://www.psg.com/~zinin/ Friday, March 26, 2004, 2:51:32 PM, Vishal Sharma wrote: > Hi Alex, > We had sent these suggestions for addressing the review > comments, and were wondering if you could let us know > if they are adequate. > If so, we would like to make changes to the document, and > resubmit to help move it forward. > Thanks, > -Vishal >> -----Original Message----- >> From: Vishal Sharma [mailto:v.sharma@ieee.org] >> Sent: Monday, March 15, 2004 4:23 PM >> To: Alex Zinin; ccamp@ops.ietf.org >> Cc: Rtg-dir@ietf.org; Greg Bernstein; Eric Mannie; Adrian Farrel; >> Kireeti Kompella; Bert Wijnen >> Subject: Responses: AD-review comments on >> draft-ietf-ccamp-sdhsonet-control >> >> >> Hi Alex, >> >> In response to the feedback from the RTG-Area Directorate, please find >> attached our responses about how we intend incorporating their >> feedback. >> >> BTW, thanks to the Directorate for their careful review of the document >> and their feedback, we think it will help improve the doc. further. >> >> Once we receive a confirmation that these additions look good, we >> will modify the draft, and repost to the IETF drafts directory (I >> am assuming that is the next step), and cc you. >> >> Thanks, >> -Vishal, Greg, Eric >> >> >> > -----Original Message----- >> > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On >> > Behalf Of Alex Zinin >> > Sent: Thursday, March 04, 2004 4:49 AM >> > To: ccamp@ops.ietf.org >> > Cc: Rtg-dir@ietf.org >> > Subject: AD-review comments on draft-ietf-ccamp-sdhsonet-control >> > >> > >> > Folks- >> > >> > Please find below comments from the RTG area directorate that I would >> > like the WG to consider. >> > >> > Thank you. >> > >> > -- >> > Alex Zinin >> > >> > Technical: >> > ---------- >> > >> > Section 3.2: >> > >> > 1. Figure 1 misses the STM-0 branch >> >> Thanks for noticing! We will add this using G.707. >> >> > Section 3.4.3: >> > >> > 2. In comparison table, PNNI word appears for the first time in this >> > document, any specific reason to mention PNNI in a GMPLS context ? >> >> The intent here was just to ask whether a packet-based control >> plane was valuable for advanced TDM service provisioning and mgt. >> We could reword this to >> "Packet-based control plane (like MPLS or PNNI-based) useful?" I don't have a strong opinion on this, as PNNI is mentioned for informational purposes only, it seems. >> > Section 3.5 >> > >> > 3. "New simplified encapsulations could reduce this overhead to as low >> > as 3%, but the gain is not huge compared to SDH and SONET, >> which have >> > other benefits as well.)" any reference available for these new >> > simplified encapsulation(s) ? >> >> >> I believe Eric might be able to locate a reference for this. If not, we >> will remove in the revised version. >> >> > 4. "Any encapsulation of IP over WDM should at least provide error >> > monitoring capabilities (to detect signal degradation), error >> > correction capabilities, such as FEC (Forward Error Correction) that >> > are particularly needed for ultra long haul transmission, sufficient >> > timing information, to allow robust synchronization (that is, to >> > detect the beginning of a packet), and capacity to transport >> > signaling, routing and management messages, in order to control the >> > optical switches." >> > >> > The first part refers to data plane capabilities, however the >> > requirement: the "encapsulation of IP over WDM" should deliver >> > the capacity to transport IP based control plane information - >> > why is this the case ? an out of band network would also do the >> > job and this statement makes thus the implicit assumption that >> > data and control plane topology is congruent >> >> This is an accurate observation. >> However, since standardization of IP over WDM without SDH/SONET >> is beyond scope here, this could be removed. Although, there still >> tends to be confusion when there is talk of "putting IP over lambda", >> which does not happen directly. >> >> Alternatively, we could reword this to decouple what >> is needed in the data plane from what is required in the control plane, >> and mention, in fact, that associated signaling is not a requirement >> for GMPLS-based control of SDH/SONET networks, merely one option, and >> mention non-associated signaling as the other. I suggest that this part of the text is reworded so it doesn't sound like a requirement for IP-o-WDM encapsulation (or did you mean it to sound that way?). >> > Section 6: >> > >> > 5. "Due to the increase in information transferred in the routing >> > protocol, it may be useful to separate the relatively static >> > parameters concerning a link from those that may be subject to >> > frequent changes. The current GMPLS routing extensions [12],[13], >> > [14] do not make such a separation, however." >> > >> > it may be thus worth asking the question was the dissemination >> > of these quasi-static "link capabilities" using the same rules >> > as for any other TE LSA Type 1 sub-TLV the right approach ? >> >> From the carriers perspective, the up-to-date dissemination of all link >> properties is essential and desired. The use of a link-state routing >> protocol to distribute this information provides timely and efficient >> delivery. Now, if we got to the point that bandwidth updates happened >> very frequently, it makes sense, from an efficiency point of view, to >> separate them out for update. This situation is not yet seen in >> actual networks, however if GMPLS signaling is put into widespread use >> then the need could arise. I have a feeling that if start peeling this onion (separation of more-static vs more-dynamic info distribution), we'll get into a rat-hole. It is clear that this direction hasn't been pursued. It is not clear if it will ever be. How do you guys feel about removing this statement? EOM From rtg-dir-admin@ietf.org Mon Apr 5 21:11:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00879 for ; Mon, 5 Apr 2004 21:11:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAf82-0001Sv-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 21:11:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAepR-0006tB-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 20:52:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAeRf-0003yX-00 for rtg-dir-archive@ietf.org; Mon, 05 Apr 2004 20:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAeRd-0002WF-7g; Mon, 05 Apr 2004 20: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 1BAeRN-0002MZ-1l for rtg-dir@optimus.ietf.org; Mon, 05 Apr 2004 20:27: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 UAA26449 for ; Mon, 5 Apr 2004 20:27:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAeRK-0003vs-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 20:27:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAe0k-0001A2-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 20:00:16 -0400 Received: from zephir.uk.clara.net ([195.8.69.53]) by ietf-mx with esmtp (Exim 4.12) id 1BAdgj-0005xL-00 for rtg-dir@ietf.org; Mon, 05 Apr 2004 19:39:33 -0400 Received: from du-069-0128.access.clara.net ([217.158.132.128] helo=Puppy) by zephir.uk.clara.net with smtp (Exim 4.22) id 1BAdgW-000IX5-9Z; Tue, 06 Apr 2004 00:39:21 +0100 Message-ID: <010101c41b67$3827cb50$f99c9ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Alex Zinin" , "Vishal Sharma" Cc: "Greg Bernstein" , "Eric Mannie" , "Kireeti Kompella" , "Bert Wijnen" , References: <179540304.20040405161511@psg.com> Subject: Re: Responses: AD-review comments on draft-ietf-ccamp-sdhsonet-control Date: Tue, 6 Apr 2004 00:39:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Two pennies below. > >> > 5. "Due to the increase in information transferred in the routing > >> > protocol, it may be useful to separate the relatively static > >> > parameters concerning a link from those that may be subject to > >> > frequent changes. The current GMPLS routing extensions [12],[13], > >> > [14] do not make such a separation, however." > >> > > >> > it may be thus worth asking the question was the dissemination > >> > of these quasi-static "link capabilities" using the same rules > >> > as for any other TE LSA Type 1 sub-TLV the right approach ? > >> > >> From the carriers perspective, the up-to-date dissemination of all link > >> properties is essential and desired. The use of a link-state routing > >> protocol to distribute this information provides timely and efficient > >> delivery. Now, if we got to the point that bandwidth updates happened > >> very frequently, it makes sense, from an efficiency point of view, to > >> separate them out for update. This situation is not yet seen in > >> actual networks, however if GMPLS signaling is put into widespread use > >> then the need could arise. > > I have a feeling that if start peeling this onion (separation of more-static vs > more-dynamic info distribution), we'll get into a rat-hole. It is clear that > this direction hasn't been pursued. It is not clear if it will ever be. > How do you guys feel about removing this statement? Depending on what you mean by "very frequently" I don't see why: - GMPLS-TE is different from MPLS-TE - this isn't already an issue in TE networks - it can't be handled (as it is today) by damping the information flood according to percentage change etc. A From rtg-dir-admin@ietf.org Thu Apr 8 01:06:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19850 for ; Thu, 8 Apr 2004 01:06:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBRkf-0004fl-00 for rtg-dir-archive@ietf.org; Thu, 08 Apr 2004 01:06:57 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBPeT-0006Y5-01 for rtg-dir-archive@ietf.org; Wed, 07 Apr 2004 22:52:25 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBPNg-0007xU-BJ for rtg-dir-archive@ietf.org; Wed, 07 Apr 2004 22:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBPNf-0006jb-Dl; Wed, 07 Apr 2004 22: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 1BBPN6-0006Th-4a for rtg-dir@optimus.ietf.org; Wed, 07 Apr 2004 22:34: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 WAA09737 for ; Wed, 7 Apr 2004 22:34:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBPN2-00053j-00 for rtg-dir@ietf.org; Wed, 07 Apr 2004 22:34:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBO0n-0000qR-00 for rtg-dir@ietf.org; Wed, 07 Apr 2004 21:07:23 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBM3z-0002me-00 for rtg-dir@ietf.org; Wed, 07 Apr 2004 19:02:31 -0400 Received: from c-24-15-22-254.client.comcast.net ([24.15.22.254]) by mx2.foretec.com with smtp (Exim 4.24) id 1BBM3s-0007IM-EH for rtg-dir@ietf.org; Wed, 07 Apr 2004 19:02:25 -0400 Received: from 71.252.179.202 by 24.15.22.254; Thu, 08 Apr 2004 04:01:20 +0400 Message-ID: From: "Alissa Norris" Reply-To: "Alissa Norris" To: rtg-dir@ietf.org Subject: Valium drugs for sale - Valium sales - Valium online - Valium diazepam Date: Thu, 08 Apr 2004 06:00:20 +0600 X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0474809006316965074" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.9 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ----0474809006316965074 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable



If the messa= ge is n ot loading try this<= /center>


Pdormitory feedback sc earnest confession transposition dump bliss aar= hus mcmillan abstinent plagiarist set compartment schoenberg upstream atla= ntic=20?Qbed chang attribution cony procedure tool assemble plummet sedate= archaic beak aqua drapery eel coarsen resourceful faustus balzac attentiv= e=20.Xretentive pluperfect aperiodic dominique desolate cufflink fag ziegl= er panicle chicory guardhouse iliad penthouse trip constellate echo erbium= transplant epicyclic scanty echoes mildred hilt constraint miller smudgy = bertrand vomit sprung=20.Gclarify copyright substitution claustrophobic pe= rimeter travelogue got tine problem injury laborious disruption=20.Fdogtro= t empire inhospitable hannah journalese wilfred jargon circumvention bois = uncouth persia hydrochloride cloture nnw barnet rowland sierra=20!Cdisputa= nt absolute pantheist galvanic ironside maritime accompanist excelsior hap= penstance coherent blumenthal extend infinitesimal regal constrict florica= n dapple beautify scarsdale=20,Jbator geochemistry michelson rhoda atreus = aching utterance bureau nasa mobster antiphonal dahomey inoperative mckenn= a peck brainwash brahmsian dolt hieronymus=20,Lschizoid broad cortege agne= w gossip hank boardinghouse finitary univalent climatology butyrate inhibi= tion feathertop adipic annette faust=20.Dscrapbook defrock slice rise slay= glaucoma separable dispensable thoroughbred=20.Xdutchess fanny flout ginm= ill ax acknowledgeable ammo baroque audacious ruddy algenib genre wondrous= crystallography circle lycopodium platonic marquess=20,Xmullah exclamator= y mcbride asset preference countersunk bison elliott sunlit lunatic chatea= u dark sphere militia altar epoxy cotman miss showmen husbandry converge a= cadia hibachi piggy=20,Fmaddox adage juicy massage deduce compunction anti= cipate occupy blinn animism quadratic donor oregon crocodilian chest=20'Fp= ainful uptrend servitor cognizable horowitz carven ronnie abbot latinate m= oser=20;Nconcessionaire isotropy document nationwide protrude karp littora= l dodson q's contrariety suitcase bey morel credential fogging teaspoonful= careworn duplex royalty incurring interlude cellulose antagonism cardioid= tirade neptunium debility cavendish=20. Odovetail parabola farrell inflec= t jimmie buttonweed snapdragon deleterious genesis briefcase erskine=20,Wm= emorable lambert business fanfold lean arteriole judas manley goodbye soph= ie chairman week triphenylphosphine copperhead chide dual savvy lark conne= ct calculate candelabra medicate mortify anchorage callus devise heinz=20?= Vdelhi feast louis beard swabby housewife cramp wainwright grate dane skil= l chirp dowling gumption shrivel static furniture cornish impulsive debona= ir ntis=20'Tbizarre harass alias u.s.a alive feeble autotransformer egg cu= ltivate upset mudd sawmill mulligatawny excoriate esther corbett concubine= childbirth claustrophobia stephenson confirm bloat variety stewart climat= ic blacken rhombic=20,Wtattletale atlanta during chimney seamen consequent= handline nutshell lavoisier norma tapir snafu polymerase nnw dielectric b= eginner panel scrabble silkworm medial ti backstage gaunt mosquito h's stu= dent superlative transept harmonica refrain=20;Jconsign goodwill conferred= vance blandish axial blade butyric contraceptive mayfair louise lockout=20= ;Fspawn boyle issuant urbanite roman salamander kitakyushu afterlife motio= n balk incidental phillips remediable bellboy righteous embroil gu=20;Oban= gor beautify diplomatic acadia neck roast lapel cataclysmic diaphanous slo= venia=20,Kbyte string perfumery still resumption emblem upper mach oxide r= esort template teahouse bitternut maritime surmise quail firsthand sacred = ingenuity=20.Vcollimate civil infima ado crewman covenant loaf anachronist= ic cluster nerve dwyer cordial dandy women cdc flabbergast scops tedious d= en harmony fig beginner added dear bard anyone vade affectionate competito= r berth=20;Lbyron pilgrimage jeffrey midday jeopard abutted conferrable gl= ossy preliminary promethean deliverance bondsman admittance accessory petr= ifaction charismatic cliffhang compulsion sockeye=20.

----0474809006316965074-- From rtg-dir-admin@ietf.org Thu Apr 8 16:43:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21437 for ; Thu, 8 Apr 2004 16:43:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBgMv-0001Bx-00 for rtg-dir-archive@ietf.org; Thu, 08 Apr 2004 16:43:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBdaQ-0005PW-00 for rtg-dir-archive@ietf.org; Thu, 08 Apr 2004 13:45:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBbVM-0005hl-00 for rtg-dir-archive@ietf.org; Thu, 08 Apr 2004 11:31:48 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBaxr-0003tB-Su for rtg-dir-archive@ietf.org; Thu, 08 Apr 2004 10:57:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBaxg-0002bQ-VZ; Thu, 08 Apr 2004 10:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBawm-0002Tp-KR for rtg-dir@optimus.ietf.org; Thu, 08 Apr 2004 10:56: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 KAA25164 for ; Thu, 8 Apr 2004 10:56:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBawj-0003GL-00 for rtg-dir@ietf.org; Thu, 08 Apr 2004 10:56:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBYrg-00036W-00 for rtg-dir@ietf.org; Thu, 08 Apr 2004 08:42:41 -0400 Received: from [220.197.36.249] (helo=rserpool) by ietf-mx with smtp (Exim 4.12) id 1BBWVI-0002sL-00; Thu, 08 Apr 2004 06:11:24 -0400 Message-ID: From: "Pilc" Date: Thu, 08 Apr 2004 18:19:12 +0800 To: rserpool@ietf.org, rtg-dir@ietf.org, rohc@ietf.org, routing-discussion@ietf.org, scoya@ietf.org, simple@ietf.org, sip@ietf.org, sipping@ietf.org, seamoby@ietf.org Subject: Become A Sexual God 2day!. . . . . . .Rankin MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA25165 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.6 required=5.0 tests=FORGED_YAHOO_RCVD, FROM_HAS_ULINE_NUMS,HTML_30_40,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable
= DeerAntler+ -=C2=A0 *New Product*

* Increase testosterone levels up to 500%
* Prevent premature ejac\ulation
* Enhance pe\nis size up to 3 inches
* Maintain harder, stronger erections for hours
* Have amazing s\ex up to 20 times per day
* Improve sex\ual stamina dramatically
* Increase se\xual self-confidence
* Satisfy yourself and your lover like never before
* 100% Safe To Take, With NO Side Effects
* Fast Priority USPS Shipping WorldWide
* Doctor Approved And Recommended
* 100% Mo\ney Back Gua\rantee
* FREE Bottle Of DeerAntler+ Worth Over $50
* FREE "Male Help E-Book" Worth Over $50

MORE INFO HERE






reputable Quasimodo secure


No Thanks, Rem\ove
From rtg-dir-admin@ietf.org Mon Apr 12 20:55:41 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29305 for ; Mon, 12 Apr 2004 20:55:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDCDE-0004QS-00 for rtg-dir-archive@ietf.org; Mon, 12 Apr 2004 20:55:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDCA9-00040c-00 for rtg-dir-archive@ietf.org; Mon, 12 Apr 2004 20:52:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDC6m-0003Xv-00 for rtg-dir-archive@ietf.org; Mon, 12 Apr 2004 20:49:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDC6m-0003UB-Nb; Mon, 12 Apr 2004 20:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDC60-0003Sh-Nb for rtg-dir@optimus.ietf.org; Mon, 12 Apr 2004 20:48: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 UAA28822 for ; Mon, 12 Apr 2004 20:48:09 -0400 (EDT) Resent-From: apzsz@pbowsf.yourmakeup.info Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDC5x-0003Uc-00 for rtg-dir@ietf.org; Mon, 12 Apr 2004 20:48:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDC1M-0002uT-00 for rtg-dir@ietf.org; Mon, 12 Apr 2004 20:43:26 -0400 Received: from [203.208.169.132] (helo=nartixm.yourmakeup.info) by ietf-mx with esmtp (Exim 4.12) id 1BDBuP-0002F4-00 for rtg-dir@ietf.org; Mon, 12 Apr 2004 20:36:13 -0400 Received: from ietf-mx.ietf.org (132.151.6.1) by nartixm.yourmakeup.info with SMTP id 8561GJIJWE8; Mon, 12 Apr 2004 20:40:44 -0400 Received: from ddmmn.yourmakeup.info (HELO ddmmn) (172.16.235.212) by ietf-mx.ietf.org with SMTP; Mon, 12 Apr 2004 20:40:44 -0400 Reply-To: From: "Staci" Resent-To: rtg-dir@ietf.org To: References: In-Reply-To: Subject: Treatment Increases Collagen In Lips! ..please forward Date: Mon, 12 Apr 2004 20:40:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/html; charset="US-ASCII" X-BBounce: list20007 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Resent-Message-Id: Resent-Date: Mon, 12 Apr 2004 20:36:13 -0400 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA28823 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE, HTML_FONT_BIG,HTML_FONT_INVISIBLE,HTML_MESSAGE,HTML_TAG_BALANCE_BODY, HTML_TAG_BALANCE_HTML,HTML_TITLE_EMPTY,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable
B'eauty Secrets Newsletter
By: Jamie And= erton - Freelance Writer & B'eauty Expert
<= /td>

Better than = Lip I'<= font face=3D"arial" size=3D"6" color=3D"#BA5B8B">njections?
.....................= .........................................................................= ......
Have you ever w= anted to get c= 'ollagen i'njections? My research found an exce= llent pain free option for you ladies that don=92t want to spend thousand= s of dollars on surgery=85

Dear Jamie, Have= you ever heard of C'ity L'ips? One of my girlfriends uses i= t constantly and she swears up and down that it has really made her lips = bigger after just a few short weeks. I=92ve wanted to get c'ollagen i'njections for years but it=92s so expensive. Do you think C'ity L'ips will make my lips fuller?

Amber Davies
New= port Beach, CA

Well Amber, I pers= onally interviewed a world renowned biochemist who developed the C= 'ity L'ips formula. I walked away from that interview with a ne= w respect for modern c'osmet= ics. C'= ity L'ips convinced me that they have the most ad= vanced C'ollagen Building T<= /font>'reatment available that is d= ifferent than any other product on the market today claiming to be a "lip= p'lumper".

C'ity L'ips uses a unique Oligopept'ide Technology that stimulates lips to increase production of their own c'ollagen and hy'alonuronic acid. C'ity L'ips then = adds C= 'eladrol to protect the new c'ollagen from breakdown. C'eladrol is also a patented anti-in= flammatory. How can an anti-inflammatory help plump your lips? That=92s e= xactly what I asked! C'eladr= ol helps retain moisture and repair damaged tissue, making your lips full= and healthy. He also pointed out that other lip p'lumpers have harsh spices that irritate your lips a= nd inflame them. C'ity L'ips actually builds c'ollagen, making your lips grow!

SAVE THIS ARTICLE

:
:
:
:
:
::
:
:
:
:
:
:
:
:

C'ity L'ips impressed me with the shocking= revelation that they have had less than a 1% return rate on their Lip P<= /font>'lumping T'reatment! C'ity L'<= /font>ips is Guaranteed= to work or your Money Back.

C'ity L= 'ips is an Int= ernational company that has customers in 74 countries. Movie stars, cel= ebrities, doctors, and people of all walks of life use C'ity L'ips everyday They must be doing something right!

C<= /font>'ity L'ips is a highly effective and inexpensive alternati= ve to c'ollagen i'njections. More Details HERE... <= /font>

Jamie Anderton












Imitation is the sincerest form of flattery. Better lat= e than never.

Home is where the heart is. Habit is second nature. A = picture is worth a thousand words. Where there is a will, there is a way.= Misery makes strange bedfellows.

No news is good news. The best adv= ice is found on the pillow.




From rtg-dir-admin@ietf.org Tue Apr 13 07:07:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04968 for ; Tue, 13 Apr 2004 07:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDLlV-0007Rc-00 for rtg-dir-archive@ietf.org; Tue, 13 Apr 2004 07:07:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDLga-0006tB-00 for rtg-dir-archive@ietf.org; Tue, 13 Apr 2004 07:02:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDLcI-0006TH-00 for rtg-dir-archive@ietf.org; Tue, 13 Apr 2004 06:58:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDLcA-0005wU-JX; Tue, 13 Apr 2004 06: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 1BDLbu-0005uV-LP for rtg-dir@optimus.ietf.org; Tue, 13 Apr 2004 06:57: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 GAA04414 for ; Tue, 13 Apr 2004 06:57:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDLbq-0006Rl-00 for rtg-dir@ietf.org; Tue, 13 Apr 2004 06:57:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDLXH-00062s-00 for rtg-dir@ietf.org; Tue, 13 Apr 2004 06:52:59 -0400 Received: from 0x5358a4de.naenxx9.adsl-dhcp.tele.dk ([83.88.164.222] helo=policy) by ietf-mx with smtp (Exim 4.12) id 1BDLTL-0005du-00; Tue, 13 Apr 2004 06:48:55 -0400 Message-ID: From: "Nomcom" Date: Tue, 13 Apr 2004 12:48:02 +0100 To: policy@ietf.org, pwe3@ietf.org, research-funding-web-archive@ietf.org, rmt@ietf.org, rmonmib@ietf.org, rpsec@ietf.org, rserpool@ietf.org, rtg-dir@ietf.org, rohc@ietf.org Subject: Rock Solid Erect.ions In 60 Seconds! MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_MESSAGE,LINES_OF_YELLING, MIME_HTML_ONLY,UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: 8bit hardonoil1

MASSIVE ROCK-SOLID EREC.TIONS
IN 60 SECONDS OR LESS!

ITS HERE THE NEW
VirilityEx Oil
- Immediate Rock-Solid Erec.tions
- Total, Oversize Arousal
- Double-Strength Org.asms
- Super Staying Power
- Maximum Sexual Health
- Increase the Size and Intensity of your Erec.tions!
- Completely Safe and Effective Lubri.cant!

READ MORE INFO HERE



no more emailz

From rtg-dir-admin@ietf.org Wed Apr 14 11:11:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00225 for ; Wed, 14 Apr 2004 11:11:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDm2f-00013P-00 for rtg-dir-archive@ietf.org; Wed, 14 Apr 2004 11:11:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDm1v-00010e-00 for rtg-dir-archive@ietf.org; Wed, 14 Apr 2004 11:10:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDloz-0005Zf-3P; Wed, 14 Apr 2004 10: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 1BDll7-0004nC-0w for rtg-dir@optimus.ietf.org; Wed, 14 Apr 2004 10:53: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 KAA28966 for ; Wed, 14 Apr 2004 10:52:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDll4-000045-00 for rtg-dir@ietf.org; Wed, 14 Apr 2004 10:52:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDlk5-0007l5-00 for rtg-dir@ietf.org; Wed, 14 Apr 2004 10:51:58 -0400 Received: from g17219.upc-g.chello.nl ([80.57.17.219]) by ietf-mx with smtp (Exim 4.12) id 1BDljX-0007ex-00 for rtg-dir@ietf.org; Wed, 14 Apr 2004 10:51:25 -0400 Received: from 224.253.98.135 by 80.57.17.219; Wed, 14 Apr 2004 11:42:20 -0400 Message-ID: From: "Joaquin Mccall" Reply-To: "Joaquin Mccall" To: rtg-dir@ietf.org Subject: Stop Cravings! Switch OFF Hunger! ACHIEVE Permanent Weight Loss! Date: Wed, 14 Apr 2004 17:50:20 +0200 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--76205102243927155507" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.2 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_30_40,HTML_IMAGE_ONLY_10, HTML_MESSAGE,MANY_EXCLAMATIONS,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.1 HTML_IMAGE_ONLY_10 BODY: HTML: images with 800-1000 bytes of words * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 0.4 MANY_EXCLAMATIONS Subject has many exclamations Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ----76205102243927155507 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


If the message is not loading try here


Ahomo delete chairperson bangkok canvas inelegant imbroglio emission v= ideo affectionate brainard duplicable balky hygrometer compleat blackberry= bluet homology decimal bottleneck resistible enumerable kolkhoz bawdy=20,= Halmost auk stimulate marion maximilian o'connell bisque bratwurst=20;Fdai= ry deceive tradeoff principal lindholm neath crosby charlotte chickweed mo= rel gagging brigham continue=20,Tcoliseum penn gentle second tribal thrift= boyle coltsfoot baptistery=20;Fwiden rally magnolia quinn bookshelves ani= onic alphonse bunkmate calve monoceros waters hovel lisp perilous discreti= on sailor cowardice armadillo carob cite coke=20,Rexecutor screwball dough= erty allison blister during anton gymnasium saran minion coffee combinator= ial herman hyperboloid notocord preposition yaqui harshen burglary sloop w= idthwise ecology=20'

----76205102243927155507-- From rtg-dir-admin@ietf.org Thu Apr 15 05:45:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13766 for ; Thu, 15 Apr 2004 05:45:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE3Qb-00078I-00 for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 05:45:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE3Pa-00073F-00 for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 05:43:59 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE3OY-0006wl-00 for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 05:42:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3Jp-0007B5-Qa; Thu, 15 Apr 2004 05:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3Hx-0006MW-IY for rtg-dir@optimus.ietf.org; Thu, 15 Apr 2004 05:36: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 FAA13456 for ; Thu, 15 Apr 2004 05:36:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE3Hu-0006U0-00 for rtg-dir@ietf.org; Thu, 15 Apr 2004 05:36:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE3Gx-0006QB-00 for rtg-dir@ietf.org; Thu, 15 Apr 2004 05:35:03 -0400 Received: from zephir.uk.clara.net ([195.8.69.53]) by ietf-mx with esmtp (Exim 4.12) id 1BE3GN-0006MY-00 for rtg-dir@ietf.org; Thu, 15 Apr 2004 05:34:27 -0400 Received: from du-069-0056.access.clara.net ([217.158.132.56] helo=Puppy) by zephir.uk.clara.net with smtp (Exim 4.22) id 1BE3GO-000PZE-6c; Thu, 15 Apr 2004 10:34:28 +0100 Message-ID: <005701c422cc$d8fcb790$83919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" Subject: Heads up - CCAMP last call on draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Thu, 15 Apr 2004 10:33:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Hi, This is a heads up on the working group last call of a CCAMP informational draft that crosses some working group boundaries. The last call ends on May 28th. http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt captures the requirements placed on GMPLS routing protocols by the ITU-T's ASON architecture. As the abstract puts it... The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document concentrates on the routing requirements on the GMPLS suite of protocols to support the capabilities and functionalities for an Automatically Switched Optical Network (ASON) as defined by ITU-T. We would welcome any comments at this stage either on the CCAMP mailing list or direct to the chairs: Adrian Farrel adrian@olddog.co.uk Kireeti Kompella kireeti@olddog.co.uk Thanks, Adrian From rtg-dir-admin@ietf.org Thu Apr 15 05:55:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14282 for ; Thu, 15 Apr 2004 05:55:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE3aJ-00005a-00 for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 05:55:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE3ZM-00001p-00 for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 05:54:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE3Yk-0007mD-00 for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 05:53:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3TU-0001cf-IZ; Thu, 15 Apr 2004 05:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE3RY-00013J-4i for rtg-dir@optimus.ietf.org; Thu, 15 Apr 2004 05:46: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 FAA13797 for ; Thu, 15 Apr 2004 05:45:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE3RU-0007CT-00 for rtg-dir@ietf.org; Thu, 15 Apr 2004 05:45:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE3QW-00077g-00 for rtg-dir@ietf.org; Thu, 15 Apr 2004 05:44:57 -0400 Received: from zephir.uk.clara.net ([195.8.69.53]) by ietf-mx with esmtp (Exim 4.12) id 1BE3PY-00072k-00 for rtg-dir@ietf.org; Thu, 15 Apr 2004 05:43:56 -0400 Received: from du-069-0056.access.clara.net ([217.158.132.56] helo=Puppy) by zephir.uk.clara.net with smtp (Exim 4.22) id 1BE3PZ-0006tj-74; Thu, 15 Apr 2004 10:43:57 +0100 Message-ID: <008301c422ce$2c3d03a0$83919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" Subject: Re: Heads up - CCAMP last call on draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Date: Thu, 15 Apr 2004 10:43:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Rats! That should read April 28th. Adrian ----- Original Message ----- From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" Sent: Thursday, April 15, 2004 10:33 AM Subject: Heads up - CCAMP last call on draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt > Hi, > > This is a heads up on the working group last call of a CCAMP informational draft that > crosses some working group boundaries. The last call ends on May 28th. > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt > captures the requirements placed on GMPLS routing protocols by the ITU-T's ASON > architecture. > > As the abstract puts it... > The Generalized MPLS (GMPLS) suite of protocols has been defined to > control different switching technologies as well as different > applications. These include support for requesting TDM connections > including SONET/SDH and Optical Transport Networks (OTNs). > > This document concentrates on the routing requirements on the GMPLS > suite of protocols to support the capabilities and functionalities > for an Automatically Switched Optical Network (ASON) as defined by > ITU-T. > > We would welcome any comments at this stage either on the CCAMP mailing list or direct to > the chairs: > Adrian Farrel adrian@olddog.co.uk > Kireeti Kompella kireeti@olddog.co.uk > > Thanks, > Adrian > > From rtg-dir-admin@ietf.org Thu Apr 15 08:30:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19252 for ; Thu, 15 Apr 2004 08:30:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE60U-0003yC-00 for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 08:30:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE60E-0003tx-00 for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 08:29:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE5uV-0003qr-Tz; Thu, 15 Apr 2004 08: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 1BE4lz-0001Oi-0Y for rtg-dir@optimus.ietf.org; Thu, 15 Apr 2004 07:11: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 HAA16919 for ; Thu, 15 Apr 2004 07:11:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE4lu-0005og-00 for rtg-dir@ietf.org; Thu, 15 Apr 2004 07:11:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE4ks-0005dX-00 for rtg-dir@ietf.org; Thu, 15 Apr 2004 07:10:03 -0400 Received: from acb05bd4.ipt.aol.com ([172.176.91.212] helo=rtg-dir) by ietf-mx with smtp (Exim 4.12) id 1BE4ju-0005XA-00 for rtg-dir@ietf.org; Thu, 15 Apr 2004 07:09:03 -0400 Message-ID: From: "Vincent" Date: Thu, 15 Apr 2004 13:08:23 -0200 To: rtg-dir@ietf.org Subject: Fwd:Lose Weight Easily & Naturally!.............aligning MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.9 required=5.0 tests=ALL_NATURAL,AWL, BANG_EXERCISE,BIZ_TLD,DATE_IN_FUTURE_03_06,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_MESSAGE,LINES_OF_YELLING, LINES_OF_YELLING_2,LOSE_POUNDS,MIME_HTML_ONLY,URI_OFFERS autolearn=no version=2.60 X-Spam-Report: * 2.8 LOSE_POUNDS Subject talks about losing pounds * 1.2 BANG_EXERCISE BODY: Talks about exercise with an exclamation! * 1.3 ALL_NATURAL BODY: Spam is 100% natural?! * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 2.4 URI_OFFERS URI: Message has link to company offers * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * -1.1 AWL AWL: Auto-whitelist adjustment Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit fatpatch1
LOSE WEIGHT THE EASIER WAY
"ITS NOT A DIET.....ITS A PATCH"

Diet Patch Pro is a cutting-edge, advanced appetite suppressant, metabolism booster, and energy enhancer...all in one! With Diet Patch Pro, there are no more starvation diets and no difficult and dangerous exercises! It works all day & all night long!

Diet Patch Pro is a 100% percent all natural product that produces no side effects or allergic reactions and is completely safe to use. The SFP is so easy to use just peel and stick then watch the pounds melt away.

READ MORE INFO HERE
?

no more emailz

luncheonsdamnation From rtg-dir-admin@ietf.org Thu Apr 15 19:55:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11015 for ; Thu, 15 Apr 2004 19:55: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 1BEGhm-0007i2-8F for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 19:55:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEGgs-0007gG-00 for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 19:54:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEGgX-0007eK-00 for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 19:54:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEGUb-0000J6-N8; Thu, 15 Apr 2004 19:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEGMg-0006mr-PS for rtg-dir@optimus.ietf.org; Thu, 15 Apr 2004 19:33: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 TAA10109 for ; Thu, 15 Apr 2004 19: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 1BEGMe-0006gx-VX for rtg-dir@ietf.org; Thu, 15 Apr 2004 19:33:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEGLg-0006cH-00 for rtg-dir@ietf.org; Thu, 15 Apr 2004 19:32:49 -0400 Received: from [12.106.35.5] (helo=mango.attlabs.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BEGLF-0006YU-00 for rtg-dir@ietf.org; Thu, 15 Apr 2004 19:32:22 -0400 Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id i3FNVjxN059755 for ; Thu, 15 Apr 2004 16:31:46 -0700 (PDT) (envelope-from fenner@mango.attlabs.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id i3FNVjsc059748 for rtg-dir@ietf.org; Thu, 15 Apr 2004 16:31:45 -0700 (PDT) (envelope-from fenner) Date: Thu, 15 Apr 2004 16:31:45 -0700 (PDT) From: Bill Fenner Message-Id: <200404152331.i3FNVjsc059748@mango.attlabs.att.com> To: rtg-dir@ietf.org Subject: Bill is on vacation Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Hi, I'm going on vacation until April 26th. If you need anything from me urgently while I'm gone you could try a short message to fenner+page@research.att.com . Bill From rtg-dir-admin@ietf.org Thu Apr 15 20:29:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12735 for ; Thu, 15 Apr 2004 20:29: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 1BEHEi-0001m0-2W for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 20:29:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEHDk-0001fb-00 for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 20:28:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEHCo-0001cA-00 for rtg-dir-archive@ietf.org; Thu, 15 Apr 2004 20:27:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEH1Y-0007aM-Em; Thu, 15 Apr 2004 20:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEGvX-0005un-P0 for rtg-dir@optimus.ietf.org; Thu, 15 Apr 2004 20:09: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 UAA11679 for ; Thu, 15 Apr 2004 20:09: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 1BEGvV-0000b1-Kj for rtg-dir@ietf.org; Thu, 15 Apr 2004 20:09:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEGun-0000Y6-00 for rtg-dir@ietf.org; Thu, 15 Apr 2004 20:09:06 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BEGuA-0000To-00; Thu, 15 Apr 2004 20:08:26 -0400 Received: from dhcp16479106.woh.rr.com ([24.164.79.106]) by mx2.foretec.com with smtp (Exim 4.24) id 1BEGuA-0002CP-Ag; Thu, 15 Apr 2004 20:08:27 -0400 Content-Type: text/html; MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Subject: what is this? From: "Maria Coker" To: rtg-bfd@ietf.org, rtg-dir@ietf.org, rtg-rdd@ietf.org X-Priority: 3 Date: Thu, 15 Apr 2004 22:59:22 -0200 Message-Id: Content-Transfer-Encoding: 7Bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.7 required=5.0 tests=HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_IMAGE_ONLY_04,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7Bit These people will be there with you for a long time and yes they will have a major impact on what you turn out to be it the future.





It comes from the individuals ability to think, reason and form an opinion. Men and women are different because of society has set them up with. From rtg-dir-admin@ietf.org Fri Apr 16 19:47:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20697 for ; Fri, 16 Apr 2004 19:47: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 1BEd3r-0003sI-8g for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 19:47:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEd2s-0003n2-00 for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 19:46:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEd2E-0003hK-00 for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 19:46:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcuJ-0003Nl-L2; Fri, 16 Apr 2004 19:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcru-0001tg-2p for rtg-dir@optimus.ietf.org; Fri, 16 Apr 2004 19:35: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 TAA19869 for ; Fri, 16 Apr 2004 19:35: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 1BEcrs-0002yu-BJ for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:35:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcqv-0002wS-00 for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:34:34 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BEcqO-0002tx-00; Fri, 16 Apr 2004 19:34:00 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BEcqO-000J9A-Kz; Fri, 16 Apr 2004 23:34:00 +0000 Date: Fri, 16 Apr 2004 16:33:59 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1578065036.20040416163359@psg.com> To: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Work on IP fast rerouting in IGPs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Folks- As many of you know, the topic of fast rerouting in IP (as opposed to MPLS-based FRR) has been brought up several times at the IETF meetings recently (see reading material at the end of the message). I believe that this work is important and there's even some room for standardization here. More specifically, even though the exact algorithms of route calculation in IGPs are historically non-normative, the criteria, such as shortest path first, are. Forwarding packets along the feasible (non-SPT, but loop-free) next-hops, strictly speaking violates those, and if done incorrectly is likely to lead to routing loops. Hence, the need to standardize at least the criteria for feasible next-hop calculation and document possible algorithms for informational purposes (pretty much the way OSPF and ISIS do this.) Per above, I would like bring this work to the RTGWG and ask the IESG to add a corresponding item to its milestone. Regarding specific proposals. It seems that Alia's work could be used as a good basis. However, I am quite dubious about the U-turn part. I wouldn't feel comfortable including U-turns in the standard-track specification. At most, we could have an experimental document for this part. I will be sending a similar message to RTGWG next week, so comments are appreciated. Reading material: - Cengiz's slides at 55th IETF http://www.packetdesign.com/news/presentations/2002/fast-reroute6.pdf - Alia's slides at 59th IETF http://www.ietf.org/proceedings/04mar/slides/rtgarea-2/index.html Alia's draft: draft-atlas-ip-local-protect-00.txt - Early draft http://www.potaroo.net/ietf/old-ids/draft-kini-traf-restore-nsp-00.txt -- Alex From rtg-dir-admin@ietf.org Fri Apr 16 19:50:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20829 for ; Fri, 16 Apr 2004 19: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 1BEd6G-00042H-Vl for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 19:50:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEd5J-0003yC-00 for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 19:49:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEd4P-0003ul-00 for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 19:48:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEd2z-000665-1E; Fri, 16 Apr 2004 19: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 1BEcuw-0003d6-DX for rtg-dir@optimus.ietf.org; Fri, 16 Apr 2004 19:38: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 TAA20020 for ; Fri, 16 Apr 2004 19:38: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 1BEcuu-0003BT-ME for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:38:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEcu0-00037S-00 for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:37:44 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BEctQ-00033d-00 for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:37:08 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BEctQ-000KFG-I8; Fri, 16 Apr 2004 23:37:08 +0000 Date: Fri, 16 Apr 2004 16:37:06 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1445640327.20040416163706@psg.com> To: Jeff Parker CC: rtg-dir@ietf.org Subject: Re: Should we address conflicting addresses on single MT interface? In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Jeff, Sorry for the delay--catching up. Monday, April 5, 2004, 4:00:34 PM, Jeff Parker wrote: > Alex - > quoting from > http://www.ietf.org/proceedings/03jul/I-D/draft-ietf-isis-wg-multi-topology- > 06.txt >>> 12.2.2. Multiple MTs share an interface with overlapping addresses > Some additional mechanism is needed to select the correct RIBs > for the incoming IP packets to determine the correct RIB to make > a forwarding decision. For example, if the topologies are > QoS partitioned, then the DSCP bits in the IP packet header can > be utilized to make the decision. Some IP header or even packet > data information may be checked to make the forwarding table > selection, such as source IP address in the header can be used > to determine the desired forwarding behavior. >>> The generic approach of packet to multiple MT RIB mapping over >>> the same inbound interface is outside the scope of this draft. > I assume that the motivation to sort this out would be to provide > interoperable implementations. Exactly. While not limiting other options, providing the "feature set" that would ensure interop. > The draft defines a mechanism, and > leaves open the definition of particulars in this case. > Is this something that needs to be decided now? Are > there competing interpretations? Are there competing > demands for this functionality? I see the value in > having agreement, but wonder if we have enough experience > with the idea to know how ISPs would want to use it tomorrow. What I'll do is ask the ops-dir to give them a heads-up and see if there are any strong opinions there and then bring this to the rtg area mailing list. Alex From rtg-dir-admin@ietf.org Fri Apr 16 20:09:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21730 for ; Fri, 16 Apr 2004 20:09: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 1BEdOl-00057k-Sz for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 20:09:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEdNr-000552-00 for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 20:08:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEdNT-000526-00 for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 20:08:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdHY-0001sp-2F; Fri, 16 Apr 2004 20:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEd8J-0007f7-Ij for rtg-dir@optimus.ietf.org; Fri, 16 Apr 2004 19:52: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 TAA20948 for ; Fri, 16 Apr 2004 19:52: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 1BEd8H-0004Dc-Mc for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:52:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEd7G-00047D-00 for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:51:27 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BEd6F-000427-00 for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:50:24 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BEd6F-000PFJ-Jv; Fri, 16 Apr 2004 23:50:23 +0000 Date: Fri, 16 Apr 2004 16:50:22 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <909608580.20040416165022@psg.com> To: ops-dir@ops.ietf.org CC: rtg-dir@ietf.org Subject: Fwd: Other pieces of the MT-routing "puzzle"? In-Reply-To: <11424532976.20040325183459@psg.com> References: <11424532976.20040325183459@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 We would be interested in knowing what ops-dir people think about the need to defining the enaps/forwarding part and the overall framework of MT routing. For the control part of it, please see the following drafts: http://www.ietf.org/proceedings/03nov/I-D/draft-ietf-isis-wg-multi-topology-06.txt http://www.ietf.org/internet-drafts/draft-psenak-mt-ospf-00.txt To correct my message below, the isis draft is not silent about it, but neither of the drafts defines a mandatory to implement mechanism. Opinions appreciated. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: rtg-dir@ietf.org Cc: Date: Thursday, March 25, 2004, 7:34:59 PM Subject: Other pieces of the MT-routing "puzzle"? ===8<==============Original message text=============== RTG-DIR folks- So we have MT extensions to IS-IS, and a draft for OSPF has been recently published. One of my concerns with MT-ISIS a while back was the situation where an interface belongs to more than one MT. In this case the association between an incoming packet and the FIB to look in is not obvious, and both drafts are silent about it (which is sort of ok given that they describe the control part of the story). Management is supposed to ensure consistent configuration among MT routers to avoid loops and black holes, but there is a potentially unlimited number of ways to mux/demux MTs on a link, and it seems that defining a few IETF standards for this would help interoperability... In other words, STD-wise, we've been operating in a single-MT environment. What we're seeing is the RP-related part of the story, and it seems that we need the encaps/forwarding part of it and (possibly) the overarching architecture. Opinions? -- Alex ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Fri Apr 16 20:13:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21952 for ; Fri, 16 Apr 2004 20:13: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 1BEdSh-0005Lf-2H for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 20:13:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEdRo-0005I6-00 for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 20:12:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEdRE-0005EH-00 for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 20:12:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdHa-0001tj-Rs; Fri, 16 Apr 2004 20:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdAE-0008Ay-5T for rtg-dir@optimus.ietf.org; Fri, 16 Apr 2004 19:54: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 TAA21148 for ; Fri, 16 Apr 2004 19:54: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 1BEdAC-0004NZ-2X for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:54:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEd9F-0004JW-00 for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:53:29 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BEd8H-0004Dd-00 for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:52:29 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BEd8H-000Pss-4u for rtg-dir@ietf.org; Fri, 16 Apr 2004 23:52:30 +0000 Date: Fri, 16 Apr 2004 16:52:27 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1676537501.20040416165227@psg.com> To: rtg-dir@ietf.org Subject: Fwd: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-00.txt In-Reply-To: <1778578854.20040414194151@psg.com> References: <1778578854.20040414194151@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: idr@ietf.org Cc: Date: Wednesday, April 14, 2004, 7:41:51 PM Subject: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-00.txt ===8<==============Original message text=============== Folks- Several comments inline below. > 1.1 General > > This draft of BGP-4 attempts to bring BGP standard as described in 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. > > 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 Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Fri Apr 16 20:13:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21963 for ; Fri, 16 Apr 2004 20:13: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 1BEdSi-0005Lr-Ja for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 20:13:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEdRq-0005IM-00 for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 20:12:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEdRV-0005EZ-00 for rtg-dir-archive@ietf.org; Fri, 16 Apr 2004 20:12:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdHa-0001tp-Vy; Fri, 16 Apr 2004 20:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdAE-0008B0-Vg for rtg-dir@optimus.ietf.org; Fri, 16 Apr 2004 19:54: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 TAA21151 for ; Fri, 16 Apr 2004 19:54: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 1BEdAC-0004Ng-Qj for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:54:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEd9G-0004Jf-00 for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:53:31 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BEd8H-0004De-00 for rtg-dir@ietf.org; Fri, 16 Apr 2004 19:52:30 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BEd8H-000Psr-2z for rtg-dir@ietf.org; Fri, 16 Apr 2004 23:52:29 +0000 Date: Fri, 16 Apr 2004 16:52:27 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <857217708.20040416165227@psg.com> To: rtg-dir@ietf.org Subject: Fwd: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt In-Reply-To: <513361939.20040414192319@psg.com> References: <513361939.20040414192319@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: idr@ietf.org Cc: Date: Wednesday, April 14, 2004, 7:23:19 PM Subject: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt ===8<==============Original message text=============== Folks- I have some technical comments regarding periods of stability and instability in the Internet, BGP steady state, and the security considerations, plus several editorial remarks. See inline below, please. > 2.1. Key Features ... > One of the most important path attributes is the Autonomous System > Path, or AS_PATH. AS reachability information traverses the ^^ "As" > Internet, this information is augmented by the list of autonomous > systems that have been traversed thus far, forming the AS_PATH. The > AS_PATH allows straightforward suppression of the looping of routing > information. In addition, the AS_PATH serves as a powerful and > versatile mechanism for policy-based routing. > > BGP enhances the AS_PATH attribute to include sets of autonomous > systems as well as lists via the AS_SET attribute. This extended > format allows generated aggregate routes to carry path information > from the more specific routes used to generate the aggregate. It > should be noted however, that as of this writing, AS_SETs are rarely > used in the Internet [ROUTEVIEWS]. > > > > 2.2. BGP Algorithms > > > 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. > BGP uses an incremental update strategy in order to conserve > bandwidth and processing power. That is, after initial exchange of > complete routing information, a pair of BGP routers exchanges only > changes to that information. Such an incremental update design > requires reliable transport between a pair of BGP routers to function > correctly. BGP solves this problem by using TCP for reliable > transport. Should also note that use of TCP as the transport mechanism helps control congestion and CPU utilization. > > In addition to incremental updates, BGP has added the concept of > route aggregation so that information about groups of networks may be > > > > Meyer and Patel Section 2.2. [Page 5] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > aggregated and sent as a single Network Layer Reachability (NLRI). this doesn't read well. Neither "reachability" nor "information" are countable. "Single prefix" instead? > Finally, note that BGP is a self-contained protocol. That is, BGP > specifies how routing information is exchanged both between BGP > speakers in different autonomous systems, and between BGP speakers > within a single autonomous system. > > > > 2.3. BGP Finite State Machine (FSM) > > > The BGP FSM is a set of rules that are applied to a BGP speaker's set > of configured peers for the BGP operation. A BGP implementation > requires that a BGP speaker must connect to and listen on TCP port > 179 for accepting any new BGP connections from its peers. The BGP > Finite State Machine, or FSM, must be initiated and maintained for > each new incoming and outgoing peer connections. However, in steady > state operation, there will be only one BGP FSM per connection per > peer. > > There may exist a temporary period where in a BGP peer may have > separate incoming and outgoing connections resulting into two > different BGP FSMs for a peer (instead of one). This can be resolved > following BGP connection collision rules defined in the [BGP4]. > > Following are different states of BGP FSM for its peers: > > IDLE: State when BGP peer refuses any incoming > connections. > > CONNECT: State in which BGP peer is waiting for > its TCP connection to be completed. > > ACTIVE: State in which BGP peer is trying to acquire a > peer by listening and accepting TCP connection. > > OPENSENT: BGP peer is waiting for OPEN message from its > peer. > > OPENCONFIRM: BGP peer is waiting for KEEPALIVE or NOTIFICATION > message from its peer. > > ESTABLISHED: BGP peer connection is established and exchanges > UPDATE, NOTIFICATION, and KEEPALIVE messages with > its peer. > > There are different BGP events that operate on above mentioned states > > > > Meyer and Patel Section 2.3. [Page 6] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > of BGP FSM for its peers. These BGP events are used for initiating and > terminating peer connections. They also assist BGP in identifying any > persistent peer connection oscillations and provide a mechanism > for controlling them. > > Following are different BGP events: > > Manual Start: Manually start the peer connection. > > Manual Stop: Manually stop the peer connection. > > Automatic Start: Local system automatically starts the peer > connection. > > Manual start with > passive TCP flag: Local system administrator manually starts the > peer connection with peer in passive mode. > > Automatic start > with passive TCP flag: Local system administrator automatically starts > the peer connection with peer in passive mode. > > Automatic start > with bgp_stop_flap > option set: Local system administrator automatically starts > the peer connection with peer oscillation > damping enabled. > > Automatic start with > bgp_stop_flap option > set and passive TCP > establishment > option set: Local system administrator automatically starts > the peer connection with peer oscillation > damping enabled and with peer in passive mode. > > Automatic stop: Local system automatically stops the > BGP connection. > > Both, Manual Start and Manual Stop are mandatory BGP events. All > other events are optional. > Ummmm... the above are "administrative" events only. There are other events in the FSM, and most of other events are mandatory. > > > > > > > > > Meyer and Patel Section 2.3. [Page 7] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > 3. BGP Capabilities > > > The BGP Capability mechanism [RFC2842] provides an easy and flexible > way to introduce new features within the protocol. In particular, > the BGP capability mechanism allows peers to negotiate various > optional features during startup. This allows the base BGP protocol > to contain only essential functionality, while at the same time > providing a flexible mechanism for signaling protocol extensions. > > > > 4. BGP Persistent Peer Oscillations > > > Ideally, whenever a BGP speaker detects an error in any peer > connection, it shuts down the peer and changes its FSM state to IDLE. > BGP speaker requires a Start event to re-initiate its idle peer > connection. If the error remains persistent and BGP speaker > generates Start event automatically then it may result in persistent > peer flapping. However, although peer oscillation is found to be > wide-spread in BGP implementations, methods for preventing persistent > peer oscillations are outside the scope of base BGP protocol > specification. > > > > 5. Implementation Guidelines > > > A robust BGP implementation is work conserving. This means that if > the number of prefixes is bound, arbitrarily high levels of route > change can be tolerated with bounded impact on route convergence for > occasionally changes in generally stable routes. "occasional"? > > A BGP implementation under high load conditions should empty as much > inbound routing updates from its input streams, processing only the > most recent route if the route for a given NLRI changes multiple > times. TCP also provides blocking on the writes on the sender side. > A BGP implementation under load should expect blocks on write calls > and send only the most recent routes when sockets unblock rather than > sending entire history. > > A robust implementation of BGP should have the following > characteristics: > 1. It is able to operate in almost arbitrarily high levels > of route flap without loosing peerings (failing to send > keepalives) or loosing other protocol adjacencies as a > > > > Meyer and Patel Section 5. [Page 8] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > result of BGP load. > > 2. Instability of a subset of routes should not affect the > route advertisements or forwarding associated with the set > of stable routes. > > 3. High levels of instability and peers of different CPU speed > or load resulting in faster or slower processing of routes > should not cause instability and should have a bounded > impact on the convergence time for generally stable routes. > > Numerous robust BGP implementations exist. Producing a robust > implementation is not a trivial matter but clearly achievable. > > > > > 6. BGP Performance characteristics and Scalability > > > In this section, we provide "order of magnitude" answers to the > questions of how much link bandwidth, router memory and router CPU > cycles the BGP protocol will consume under normal conditions. In > particular, we will address the scalability of BGP and its > limitations. > > > > 6.1. Link bandwidth and CPU utilization > > > Immediately after the initial BGP connection setup, BGP peers > exchange complete set of routing information. If we denote the total > number of routes in the Internet by N, the mean AS distance of the > Internet by M (distance at the level of an autonomous system, > expressed in terms of the number of autonomous systems), the total > number of unique AS paths by A, and assume that the networks are > uniformly distributed among the autonomous systems, then the worst > case amount of bandwidth consumed during the initial exchange between > a pair of BGP speakers is > > BW = O(N + (M * A)) > > The following table illustrates the typical amount of bandwidth > consumed during the initial exchange between a pair of BGP speakers > based on the above assumptions (ignoring bandwidth consumed by the > BGP Header). For purposes of the estimates here, we will calculate > BW = 4 * (N + (M * A)). > > > > Meyer and Patel Section 6.1. [Page 9] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > # NLRI Mean AS Distance # AS's Bandwidth (MR) > ---------- ---------------- ------ ---------------- > 40,000 15 400 184,000 bytes > 100,000 10 10,000 800,000 bytes > 120,000 10 15,000 1,080,000 bytes > 140,000 15 20,000 1,760,000 bytes > > [note that most of this bandwidth is consumed by the NLRI exchange] Is the caption for column 3 correct? It says "# AS's", which reads as "number of AS's" while it seems it should be the number of unique paths. > > BGP was created specifically to reduce the size of the set of NLRI > entries which have to be carried and exchanged by border routers. > The aggregation scheme, defined in RFC 1519 [RFC1519], describes the > provider-based aggregation scheme in use in today's Internet. > > Due to the advantages of advertising a few large aggregate blocks > instead of many smaller class-based individual networks, it is > difficult to estimate the actual reduction in bandwidth and > processing that BGP has provided over BGP-3. If we simply enumerate > all aggregate blocks into their individual class-based networks, we > would not take into account "dead" space that has been reserved for > future expansion. The best metric for determining the success of > BGP's aggregation is to sample the number NLRI entries in the > globally connected Internet today and compare it to projected growth > rates before BGP was deployed. > > At the time of this writing, the full set of exterior routes carried > by BGP is approximately 120,000 network entries [ROUTEVIEWS]. > > > > 6.1.1. CPU utilization > > > An important and fundamental feature of BGP is that BGP's CPU > utilization depends only on the stability of the Internet. If the > Internet is stable, then the only link bandwidth and router CPU > cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE > messages. The KEEPALIVE messages are exchanged only between peers. > The suggested frequency of the exchange is 30 seconds. The KEEPALIVE > messages are quite short (19 octets), and require virtually no > processing. As a result, the bandwidth consumed by the KEEPALIVE > messages is about 5 bits/sec. Operational experience confirms that > the overhead (in terms of bandwidth and CPU) associated with the > KEEPALIVE messages should be viewed as negligible. > > During periods of Internet instability, changes to the reachability > information are passed between routers in UPDATE messages. The While theoretically the text is correct and we could talk about periods of stability and instability of the Internet, I wonder if this text is still applicable from the practical perspective. I.e., the continuous churn that the Internet BGP speakers experience ensures that they practically always have something to process. Probably instead of talking about periods of "Internet stability" and "Internet instability" we could talk about something like "periods of stable state among BGP speakers when they do no have new updates to communicate to each other". > > Meyer and Patel Section 6.1.1. [Page 10] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > greatest overhead per UPDATE message occurs when each UPDATE message > contains only a single network. It should be pointed out that in > practice routing changes exhibit strong locality with respect to the > AS path. That is, routes that change are likely to have common AS > path. In this case, multiple networks can be grouped into a single > UPDATE message, thus significantly reducing the amount of bandwidth > required (see also Appendix F.1 of [BGP4]). > > Since in the steady state the link bandwidth and router CPU cycles > consumed by the BGP protocol are dependent only on the stability of > the Internet, it follows that BGP should have no scaling problems in > the areas of link bandwidth and router CPU utilization. Not sure I follow here. What is meant by the "steady state" here? If it means convergence on a stable topology after the initial exchange of updates, then why talk about "stability of the Internet"? In other words, if the Internet is unstable then can we say that the BGP speakers are in steady state? In the lack of topology changes, it seems that the consumption should instead depend on the number of peers (affects KEEPALIVE processing) and the number of persistently oscillating routes potentially present in the network... > This assumes > that as the Internet grows, the overall stability of the inter-AS > connectivity of the Internet can be controlled. please specify how it is assumed to be "controlled", e.g. through operational practices. > In particular, while > the size of the IPv4 Internet routing table is bounded by O(232 * M), 232 or 2^32? > (where M is a slow-moving function describing the AS > interconnectivity of the network), slow-moving or slow-growing? > no such bound can be formulated > for the dynamic properties (i.e., stability) of BGP. Although, the > dynamic properties of the network cannot be quantitatively bounded, > they can be controlled within BGP. Beyond certain changes in the > network, BGP can start to suppress such changes using BGP Route Flap > Damping [RFC2439], pacing of its route updates, or BGP would be > unable to keep up with the changes and force suppression of multiple > changes over very short periods by causing the BGP peer socket to > block on the sender. > > > > 6.1.2. Memory requirements > > > To quantify the worst case memory requirements for BGP, we denote the > total number of networks in the Internet by N, the mean AS distance > of the Internet by M (distance at the level of an autonomous system, > expressed in terms of the number of autonomous systems), the total > number of unique AS paths as A. Then the worst case memory > requirements (MR) can be expressed as > > > MR = O(N + (M * A)) > > > Since a mean AS distance M is a slow moving function of the > interconnectivity ("meshiness") of the Internet, for all practical > purposes the worst case router memory requirements are on the order > of the total number of networks in the Internet times the number of > peers the local system is peering with. We expect that the total > number of networks in the Internet will grow much faster than the > > > > Meyer and Patel Section 6.1.2. [Page 11] > > INTERNET-DRAFT Expires: March 2004 September 2003 > > > average number of peers per router. As a result, BGP's memory > scaling properties are linearly related to the total number of > networks in the Internet. > > The following table illustrates typical memory requirements of a > router running BGP. We denote average number of routes advertised by > each peer as N, the total number of unique AS paths as A, the mean AS > distance of the Internet as M (distance at the level of an autonomous > system, expressed in terms of the number of autonomous systems), > number of bytes required to store a route as R, and number of bytes > required to store one AS in an AS path as P. It is assumed that each > network is encoded as four bytes, each AS is encoded as two bytes, > and each networks is reachable via some fraction of all of the peers > (# BGP peers/per net). For purposes of the estimates here, we will > calculate MR = ((N * R) + (M * A) * P) > > > # Networks Mean AS Distance # AS's # BGP peers/per net Memory Req (MR) > ---------- ---------------- ------ ------------------- -------------- > 100,000 20 3,000 20 1,040,000 > 100,000 20 15,000 20 1,040,000 > 120,000 10 15,000 100 75,000,000 > 140,000 15 20,000 100 116,000,000 > > > In analyzing BGP's memory requirements, we focus on the size of the > forwarding table (and ignoring implementation details). In > particular, we derive upper bounds for the size of the forwarding > table. The above doesn't look like calculations for a forwarding table--the FIB doesn't normally contact AS-PATH info or all possible paths to a destination. > > 11. Security Considerations > > > This document presents an analysis of the BGP protocol and as such > presents no new security implications for BGP. I'm afraid the IESG will expect to see some more here. Specifically, I would suggest that the document talks about available security mechanisms, and the analysis of how they affect processing overhead, BW, and scalability. Certainly a pointer to the bgp-vuln document would be useful. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Sun Apr 18 15:06:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05949 for ; Sun, 18 Apr 2004 15:06: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 1BFHcz-00029e-Nr for rtg-dir-archive@ietf.org; Sun, 18 Apr 2004 15:06:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BFHbh-0001pr-02 for rtg-dir-archive@ietf.org; Sun, 18 Apr 2004 15:05:33 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BFHOo-00088k-Mn for rtg-dir-archive@ietf.org; Sun, 18 Apr 2004 14:52:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFHNd-0006sO-DH; Sun, 18 Apr 2004 14: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 1BFHIx-00068P-Ho for rtg-dir@optimus.ietf.org; Sun, 18 Apr 2004 14:46: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 OAA04920 for ; Sun, 18 Apr 2004 14:46: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 1BFHIu-0005eA-KO for rtg-dir@ietf.org; Sun, 18 Apr 2004 14:46:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFHHv-0005Re-00 for rtg-dir@ietf.org; Sun, 18 Apr 2004 14:45:08 -0400 Received: from [213.9.244.33] (helo=world-foundation.org) by ietf-mx with esmtp (Exim 4.12) id 1BFHGq-00054C-00 for rtg-dir@ietf.org; Sun, 18 Apr 2004 14:44:02 -0400 Received: from STEPC020 (stepc020 [192.168.0.9]) by linux.local (Postfix) with ESMTP id 094648C52B for ; Sun, 18 Apr 2004 16:53:56 +0200 (CEST) From: "SN World Foundation" Subject: Worldwide Partners program To: rtg-dir@ietf.org Content-Type: multipart/alternative; boundary="=_NextPart_2rfkindysadvnqw3nerasdf"; MIME-Version: 1.0 Date: Sun, 18 Apr 2004 16:53:55 +0200 X-Priority: 3 X-Library: Indy 8.0.22 Message-Id: <20040418145356.094648C52B@linux.local> X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.9 required=5.0 tests=AWL,CLICK_BELOW,EXCUSE_16, EXCUSE_3,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,MAILTO_SUBJ_REMOVE, MAILTO_TO_REMOVE,MIME_BOUND_NEXTPART,MIME_BOUND_RKFINDY, PRIORITY_NO_NAME,X_LIBRARY autolearn=no version=2.60 X-Spam-Report: * 1.4 X_LIBRARY Message has X-Library header * 2.8 MIME_BOUND_RKFINDY Spam tool pattern in MIME boundary (rfkindy) * 0.2 EXCUSE_16 BODY: I wonder how many emails they sent in error * 0.1 EXCUSE_3 BODY: Claims you can be removed from the list * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.0 CLICK_BELOW Asks you to click below * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 0.8 PRIORITY_NO_NAME Message has priority setting, but no X-Mailer * 0.0 AWL AWL: Auto-whitelist adjustment Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New Technology for the Third World, April 2004 Production Mini-plants in mobile containers. Worldwide Partners program SN World Foundation will supply to countries and developing regions the technology and necessary support for production in series of Mini-plants in mobile=20containers (40-foot). The Mini-plant system is designed in such a way that all the production machinery is fixed on the platform of the container, with all wiring,=20piping, and installation parts; that is, they are fully equipped... and the mini-plant is ready for production.=22 More than 700 portable production systems: Bakeries, Water purification, Dehydrated food, Steel Nails, Fruit juice preparation, Tire Retreading, Reinforcement Bar=20Bending for Construction Framework, Sheeting for Roofing, Ceilings and Fa=E7ades, Plated Drums, Aluminum Buckets, Injected Polypropylene Housewares, Pressed=20Melamine Items (Glasses, Cups, Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Mesh, Plastic Bags and Packaging, Medical assistance mobile=20units, Sanitary Material, Hypodermic Syringes, Hemostatic Clamps, etc.=20 SN World Foundation has started a Co-investment program for the installation of small Assembly plants to manufacture in series the Mini-plants of portable=20production on site, region or country where required. One of the most relevant features is the fact that these plants will be connected to the International Trade=20System, with access to more than 50 million raw materials, products and services and automatic transactions for world trade. Due to financial reasons, involving cost and social impact, the best solution is setting up assembly plants on the same countries and regions, using local resources=20(labor, some equipment, etc.) SN World Foundation participates at 50% (fifty percent) for investment of each Assembly plant. If you are interested in being a partner in your country or region, you can send your CV to: SN World Foundation (click here) Worldwide Partners Program By Sarah Mathews, Manager Program ------------------------------------------------------------------------- If you received this in error or would like to be removed from our list, please return us indicating: remove or un-subscribe in subject field, Thanks. Manager Program =A9 2004 SN World Foundation. All rights reserved. --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New Technology for the Third World, April 2004

Production Mini-plants in mobile containers. Worldwide Partners program

SN World Foundation will supply to countries and developing regions the technology and necessary support for production in series of Mini-plants in mobile containers (40-foot). The Mini-plant system is designed in such a way that all the production machinery is fixed on the platform of the container, with all wiring, piping, and installation parts; that is, they are fully equipped... and the mini-plant is ready for production.=22

More than 700 portable production systems: Bakeries, Water purification, Dehydrated food, Steel Nails, Fruit juice preparation, Tire Retreading, Reinforcement Bar Bending for Construction Framework, Sheeting for Roofing, Ceilings and Façades, Plated Drums, Aluminum Buckets, Injected Polypropylene Housewares, Pressed Melamine Items (Glasses, Cups, Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Mesh, Plastic Bags and Packaging, Medical assistance mobile units, Sanitary Material, Hypodermic Syringes, Hemostatic Clamps, etc.

SN World Foundation has started a Co-investment program for the installation of small Assembly plants to manufacture in series the Mini-plants of portable production on site, region or country where required. One of the most relevant features is the fact that these plants will be connected to the International Trade System, with access to more than 50 million raw materials, products and services and automatic transactions for world trade.

Due to financial reasons, involving cost and social impact, the best solution is setting up assembly plants on the same countries and regions, using local resources (labor, some equipment, etc.) SN World Foundation participates at 50% (fifty percent) for investment of each Assembly plant.

If you are interested in being a partner in your country or region, you can send your CV to: SN World Foundation (click here) Worldwide Partners Program

By Sarah Mathews, Manager Program

-------------------------------------------------------------------------
If you received this in error or would like to be removed from our list, please return us indicating: remove or un-subscribe in subject field, Thanks. Manager Program
© 2004 SN World Foundation. All rights reserved.
 --=_NextPart_2rfkindysadvnqw3nerasdf-- From rtg-dir-admin@ietf.org Mon Apr 19 04:36:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26064 for ; Mon, 19 Apr 2004 04:36: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 1BFUGj-0003pX-M8 for rtg-dir-archive@ietf.org; Mon, 19 Apr 2004 04:36:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFUFh-0003Wb-00 for rtg-dir-archive@ietf.org; Mon, 19 Apr 2004 04:35:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFUEf-00036K-00 for rtg-dir-archive@ietf.org; Mon, 19 Apr 2004 04:34:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFU5H-0000hz-4m; Mon, 19 Apr 2004 04:24:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFTUL-0001sJ-C3 for rtg-dir@optimus.ietf.org; Mon, 19 Apr 2004 03:46: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 DAA23009 for ; Mon, 19 Apr 2004 03:46: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 1BFTUI-0007ae-RO for rtg-dir@ietf.org; Mon, 19 Apr 2004 03:46:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFTTQ-0007OE-00 for rtg-dir@ietf.org; Mon, 19 Apr 2004 03:45:49 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BFTSb-0007Bg-00 for rtg-dir@ietf.org; Mon, 19 Apr 2004 03:44:57 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BFTSc-000BFq-Ft for rtg-dir@ietf.org; Mon, 19 Apr 2004 07:44:58 +0000 Date: Fri, 16 Apr 2004 16:52:28 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1509951518.20040416165228@psg.com> To: rtg-dir@ietf.org Subject: Fwd: [Idr] AD-review comments on draft-ietf-idr-bgp4-experience-protocol-03.txt In-Reply-To: <953258565.20040414195525@psg.com> References: <953258565.20040414195525@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: idr@ietf.org Cc: Date: Wednesday, April 14, 2004, 7:55:25 PM Subject: [Idr] AD-review comments on draft-ietf-idr-bgp4-experience-protocol-03.txt ===8<==============Original message text=============== Folks- I'm generally quite happy with this document. The only comment I had was about the way the 2119 requirements language is used. In some places (simple search for "MUST" would reveal), the document reads as defining protocol procedures, which should be in the protocol spec. If the intention is to quote the spec, the wording should be changed accordingly. Refs to SBGP and SoBGP should be filled in. Thanks. Alex _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Mon Apr 19 16:35:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08272 for ; Mon, 19 Apr 2004 16:35: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 1BFfUE-0000La-Ed for rtg-dir-archive@ietf.org; Mon, 19 Apr 2004 16:35:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfTM-00007G-00 for rtg-dir-archive@ietf.org; Mon, 19 Apr 2004 16:34:32 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFfSP-0007f0-00 for rtg-dir-archive@ietf.org; Mon, 19 Apr 2004 16:33:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfOz-0007Tb-Aq; Mon, 19 Apr 2004 16:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfGV-0004kl-Vn for rtg-dir@optimus.ietf.org; Mon, 19 Apr 2004 16:21: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 QAA07287 for ; Mon, 19 Apr 2004 16:21: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 1BFfGT-0004Ya-Tn for rtg-dir@ietf.org; Mon, 19 Apr 2004 16:21:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfFU-0004Je-00 for rtg-dir@ietf.org; Mon, 19 Apr 2004 16:20:12 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1BFfER-0003su-00 for rtg-dir@ietf.org; Mon, 19 Apr 2004 16:19:07 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3JKIkQP006265; Mon, 19 Apr 2004 22:18:46 +0200 Received: from alcatel.be ([138.203.67.90]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004041922184495:5270 ; Mon, 19 Apr 2004 22:18:44 +0200 Message-ID: <4084349E.7000206@alcatel.be> Date: Mon, 19 Apr 2004 22:20:46 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishal Sharma Cc: Alex Zinin , Greg Bernstein , Eric Mannie , Adrian Farrel , Kireeti Kompella , Bert Wijnen , rtg-dir@ietf.org Subject: Re: Responses: AD-review comments on draft-ietf-ccamp-sdhsonet-control References: <179540304.20040405161511@psg.com> In-Reply-To: <179540304.20040405161511@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/19/2004 22:18:44, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/19/2004 22:18:46, Serialize complete at 04/19/2004 22:18:46 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,NO_REAL_NAME, SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hi vishal, and co-authors, this short notice to know whether we can expect an update of this i-d in order to move forward ? or are there any specific issue that remains to be further processed from your side or suggestions from latest e-mail exchange were not clear enough for this to happen ? please let us know thanks, - dimitri. Alex Zinin wrote: > Vishal, > > I'm cc'ing the RTG-DIR so Dimitri can follow up with you directly if > necessary. Most of the replies are fine, some comments inline below, pls. > Dimitri will follow up on the rest. > > Thanks. > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium hone : +32 3 240-8491 From rtg-dir-admin@ietf.org Mon Apr 19 16:58:16 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09791 for ; Mon, 19 Apr 2004 16: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 1BFfqL-00067J-KP for rtg-dir-archive@ietf.org; Mon, 19 Apr 2004 16:58:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfpS-0005sg-00 for rtg-dir-archive@ietf.org; Mon, 19 Apr 2004 16:57:23 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFfod-0005eS-00 for rtg-dir-archive@ietf.org; Mon, 19 Apr 2004 16:56:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfaf-000249-Be; Mon, 19 Apr 2004 16:42:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFfX6-0001LZ-95 for rtg-dir@optimus.ietf.org; Mon, 19 Apr 2004 16:38: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 QAA08425 for ; Mon, 19 Apr 2004 16: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 1BFfX4-00011Z-AP for rtg-dir@ietf.org; Mon, 19 Apr 2004 16:38:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFfW9-0000no-00 for rtg-dir@ietf.org; Mon, 19 Apr 2004 16:37:25 -0400 Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx with smtp (Exim 4.12) id 1BFfVq-0000a0-00 for rtg-dir@ietf.org; Mon, 19 Apr 2004 16:37:06 -0400 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.206.94.120 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 19 Apr 2004 20:33:33 -0000 Reply-To: From: "Vishal Sharma" To: Cc: "Alex Zinin" , "Greg Bernstein" , "Eric Mannie" , "Adrian Farrel" , "Kireeti Kompella" , "Bert Wijnen" , Subject: RE: Responses: AD-review comments on draft-ietf-ccamp-sdhsonet-control Date: Mon, 19 Apr 2004 13:33:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4084349E.7000206@alcatel.be> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi Dimitri, Before updating the ID, we just wanted to confirm that the enhancements we proposed address the comments appropriately (so that this is almost the final revision before processing further by IESG). Alex seemed satisfied with what we proposed, but he wanted make sure you were too. If there are no other comments on our responses, then we will make all the changes we proposed in our response, and re-issue the draft in the next week or so. Do let us know. -Vishal > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Monday, April 19, 2004 1:21 PM > To: Vishal Sharma > Cc: Alex Zinin; Greg Bernstein; Eric Mannie; Adrian Farrel; Kireeti > Kompella; Bert Wijnen; rtg-dir@ietf.org > Subject: Re: Responses: AD-review comments on > draft-ietf-ccamp-sdhsonet-control > > > hi vishal, and co-authors, > > this short notice to know whether we can expect an update of this i-d in > order to move forward ? or are there any specific issue that remains to > be further processed from your side or suggestions from latest e-mail > exchange were not clear enough for this to happen ? please let us know > > thanks, > - dimitri. > > Alex Zinin wrote: > > > Vishal, > > > > I'm cc'ing the RTG-DIR so Dimitri can follow up with you directly if > > necessary. Most of the replies are fine, some comments inline > below, pls. > > Dimitri will follow up on the rest. > > > > Thanks. > > > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > E-mail : dpapadimitriou@psg.com > Webpage: http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > hone : +32 3 240-8491 From rtg-dir-admin@ietf.org Tue Apr 20 03:33:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28604 for ; Tue, 20 Apr 2004 03:33: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 1BFplL-0004C9-BZ for rtg-dir-archive@ietf.org; Tue, 20 Apr 2004 03:33:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFpkR-0003xG-00 for rtg-dir-archive@ietf.org; Tue, 20 Apr 2004 03:32:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFpjv-0003iF-00 for rtg-dir-archive@ietf.org; Tue, 20 Apr 2004 03:32:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFpcs-0000rn-Hn; Tue, 20 Apr 2004 03:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFpUx-0007lR-Uw for rtg-dir@optimus.ietf.org; Tue, 20 Apr 2004 03: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 DAA28069 for ; Tue, 20 Apr 2004 03: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 1BFpUv-00001c-Nv for rtg-dir@ietf.org; Tue, 20 Apr 2004 03:16:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFpU2-0007aH-00 for rtg-dir@ietf.org; Tue, 20 Apr 2004 03:15:54 -0400 Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx with esmtp (Exim 4.12) id 1BFpTV-0007KU-00 for rtg-dir@ietf.org; Tue, 20 Apr 2004 03:15:21 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i3K7FDQP012922; Tue, 20 Apr 2004 09:15:13 +0200 Received: from alcatel.be ([138.203.118.3]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004042009151138:1410 ; Tue, 20 Apr 2004 09:15:11 +0200 Message-ID: <4084CE93.5030709@alcatel.be> Date: Tue, 20 Apr 2004 09:17:39 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v.sharma@ieee.org Cc: Alex Zinin , Greg Bernstein , Eric Mannie , Adrian Farrel , Kireeti Kompella , Bert Wijnen , rtg-dir@ietf.org Subject: Re: Responses: AD-review comments on draft-ietf-ccamp-sdhsonet-control References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/20/2004 09:15:11, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/20/2004 09:15:13, Serialize complete at 04/20/2004 09:15:13 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,NO_REAL_NAME, SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit vishal, some suggestions were made after receiving you response (to close some of the remaining points e.g. the issue on "more static vs more dynamic" information distribution), please include them in your proposed update (including the other proposals) so that this i-d can move forward thanks, - dimitri. Vishal Sharma wrote: > Hi Dimitri, > > Before updating the ID, we just wanted to confirm that the enhancements > we proposed address the comments appropriately (so that this is > almost the final revision before processing further by IESG). > > Alex seemed satisfied with what we proposed, but he wanted make > sure you were too. > > If there are no other comments on our responses, then we will make > all the changes we proposed in our response, and re-issue the > draft in the next week or so. > > Do let us know. > > -Vishal > > >>-----Original Message----- >>From: Dimitri.Papadimitriou@alcatel.be >>[mailto:Dimitri.Papadimitriou@alcatel.be] >>Sent: Monday, April 19, 2004 1:21 PM >>To: Vishal Sharma >>Cc: Alex Zinin; Greg Bernstein; Eric Mannie; Adrian Farrel; Kireeti >>Kompella; Bert Wijnen; rtg-dir@ietf.org >>Subject: Re: Responses: AD-review comments on >>draft-ietf-ccamp-sdhsonet-control >> >> >>hi vishal, and co-authors, >> >>this short notice to know whether we can expect an update of this i-d in >>order to move forward ? or are there any specific issue that remains to >>be further processed from your side or suggestions from latest e-mail >>exchange were not clear enough for this to happen ? please let us know >> >>thanks, >>- dimitri. >> >>Alex Zinin wrote: >> >> >>>Vishal, >>> >>> I'm cc'ing the RTG-DIR so Dimitri can follow up with you directly if >>> necessary. Most of the replies are fine, some comments inline >> >>below, pls. >> >>> Dimitri will follow up on the rest. >>> >>> Thanks. >>> >> >>-- >>Papadimitriou Dimitri >>E-mail : dimitri.papadimitriou@alcatel.be >>E-mail : dpapadimitriou@psg.com >>Webpage: http://psg.com/~dpapadimitriou/ >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium >>hone : +32 3 240-8491 > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From rtg-dir-admin@ietf.org Tue Apr 20 03:39:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28892 for ; Tue, 20 Apr 2004 03:39: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 1BFpqN-0005bC-RO for rtg-dir-archive@ietf.org; Tue, 20 Apr 2004 03:38:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFppN-0005Kc-00 for rtg-dir-archive@ietf.org; Tue, 20 Apr 2004 03:37:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFpoy-00054k-00 for rtg-dir-archive@ietf.org; Tue, 20 Apr 2004 03:37:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFpcu-0000sB-T2; Tue, 20 Apr 2004 03:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFpXl-0008Eg-8P for rtg-dir@optimus.ietf.org; Tue, 20 Apr 2004 03:19: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 DAA28249 for ; Tue, 20 Apr 2004 03:19: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 1BFpXj-0000nO-0r for rtg-dir@ietf.org; Tue, 20 Apr 2004 03:19:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFpWi-0000X2-00 for rtg-dir@ietf.org; Tue, 20 Apr 2004 03:18:41 -0400 Received: from smtp811.mail.sc5.yahoo.com ([66.163.170.81]) by ietf-mx with smtp (Exim 4.12) id 1BFpVi-0000AE-00 for rtg-dir@ietf.org; Tue, 20 Apr 2004 03:17:38 -0400 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.202.178.144 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 20 Apr 2004 07:17:38 -0000 Reply-To: From: "Vishal Sharma" To: Cc: "Alex Zinin" , "Greg Bernstein" , "Eric Mannie" , "Adrian Farrel" , "Kireeti Kompella" , "Bert Wijnen" , Subject: RE: Responses: AD-review comments on draft-ietf-ccamp-sdhsonet-control Date: Tue, 20 Apr 2004 00:17:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4084CE93.5030709@alcatel.be> Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Dimitri, Great, thanks. Will do, and, as promised, will re-issue the ID in a week or so. Will let everyone on the list here know once the ID has posted. -Vishal > -----Original Message----- > From: Dimitri.Papadimitriou@alcatel.be > [mailto:Dimitri.Papadimitriou@alcatel.be] > Sent: Tuesday, April 20, 2004 12:18 AM > To: v.sharma@ieee.org > Cc: Alex Zinin; Greg Bernstein; Eric Mannie; Adrian Farrel; Kireeti > Kompella; Bert Wijnen; rtg-dir@ietf.org > Subject: Re: Responses: AD-review comments on > draft-ietf-ccamp-sdhsonet-control > > > vishal, > > some suggestions were made after receiving you response (to close some > of the remaining points e.g. the issue on "more static vs more dynamic" > information distribution), please include them in your proposed update > (including the other proposals) so that this i-d can move forward > > thanks, > - dimitri. > > Vishal Sharma wrote: > > Hi Dimitri, > > > > Before updating the ID, we just wanted to confirm that the enhancements > > we proposed address the comments appropriately (so that this is > > almost the final revision before processing further by IESG). > > > > Alex seemed satisfied with what we proposed, but he wanted make > > sure you were too. > > > > If there are no other comments on our responses, then we will make > > all the changes we proposed in our response, and re-issue the > > draft in the next week or so. > > > > Do let us know. > > > > -Vishal > > > > > >>-----Original Message----- > >>From: Dimitri.Papadimitriou@alcatel.be > >>[mailto:Dimitri.Papadimitriou@alcatel.be] > >>Sent: Monday, April 19, 2004 1:21 PM > >>To: Vishal Sharma > >>Cc: Alex Zinin; Greg Bernstein; Eric Mannie; Adrian Farrel; Kireeti > >>Kompella; Bert Wijnen; rtg-dir@ietf.org > >>Subject: Re: Responses: AD-review comments on > >>draft-ietf-ccamp-sdhsonet-control > >> > >> > >>hi vishal, and co-authors, > >> > >>this short notice to know whether we can expect an update of > this i-d in > >>order to move forward ? or are there any specific issue that remains to > >>be further processed from your side or suggestions from latest e-mail > >>exchange were not clear enough for this to happen ? please let us know > >> > >>thanks, > >>- dimitri. > >> > >>Alex Zinin wrote: > >> > >> > >>>Vishal, > >>> > >>> I'm cc'ing the RTG-DIR so Dimitri can follow up with you directly if > >>> necessary. Most of the replies are fine, some comments inline > >> > >>below, pls. > >> > >>> Dimitri will follow up on the rest. > >>> > >>> Thanks. > >>> > >> > >>-- > >>Papadimitriou Dimitri > >>E-mail : dimitri.papadimitriou@alcatel.be > >>E-mail : dpapadimitriou@psg.com > >>Webpage: http://psg.com/~dpapadimitriou/ > >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > >>hone : +32 3 240-8491 > > > > > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > E-mail : dpapadimitriou@psg.com > Webpage: http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 From rtg-dir-admin@ietf.org Tue Apr 20 20:41:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11383 for ; Tue, 20 Apr 2004 20:41: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 1BG5nq-0002sD-S3 for rtg-dir-archive@ietf.org; Tue, 20 Apr 2004 20:41:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG5mu-0002mq-00 for rtg-dir-archive@ietf.org; Tue, 20 Apr 2004 20:40:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BG5mQ-0002i5-00 for rtg-dir-archive@ietf.org; Tue, 20 Apr 2004 20:39:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5c2-0003Op-Qn; Tue, 20 Apr 2004 20:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BG5aN-0001pz-CH for rtg-dir@optimus.ietf.org; Tue, 20 Apr 2004 20:27: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 UAA10393 for ; Tue, 20 Apr 2004 20:27: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 1BG5aL-0001T0-8C for rtg-dir@ietf.org; Tue, 20 Apr 2004 20:27:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BG5ZR-0001Mp-00 for rtg-dir@ietf.org; Tue, 20 Apr 2004 20:26:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BG5YP-0001HE-00 for rtg-dir@ietf.org; Tue, 20 Apr 2004 20:25:29 -0400 Received: from [69.158.6.54] (helo=USER-PJJS35AFZ5 ident=[ness]441956) by mx2.foretec.com with smtp (Exim 4.24) id 1BG5YO-0004tY-UA for rtg-dir@ietf.org; Tue, 20 Apr 2004 20:25:30 -0400 Received: from 16.16.65.48 by 69.158.6.54; Tue, 20 Apr 2004 22:24:13 -0300 Message-ID: From: "Sonia Rudd" Reply-To: "Sonia Rudd" To: rtg-dir@ietf.org Subject: Want Meds? We Have Them All Prescribed Online. Overnight Delivery via FedEx Date: Tue, 20 Apr 2004 21:17:13 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0993516944401496" X-IP: 46.40.170.206 X-Priority: 3 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.7 required=5.0 tests=BIZ_TLD,HTML_70_80, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME autolearn=no version=2.60 ----0993516944401496 Content-Type: text/html; Content-Transfer-Encoding: 7Bit
Ultram
Vlagra
Phentermlne
Soma
Amblen
Valium
Cialls
Xanax
Get over 300 medicatlons online shlpped overnight to your front door with no prescrlption.
   *  NoPrescriptlon Needed
   *  Fully Confidential
   *  No Embarrassment
   *  No Waiting Rooms
   *  Shipped Overnight
   *  DiscreetPackaging

Ucoulter systemwide beheld bocklogged flatus follow snowstorm pinochle coalesce countrify ambrosia volley badminton conqueror foliage mathieu oneself retort lowboy : Aviburnum asia creed deathward angus foyer oppenheimer cabinet cambridge e's diphthong agreeable deemphasize splay downpour deodorant barefaced pharmacology accreditation brendan collate casket brigade grenade cox apatite submitting tapir dialect invigorate doghouse abidjan ! Mfeat surge trig masque impractical evince actuate died weinstein companionway breadfruit these carabao tumult eyebright information mouthpiece arsine desire afterglow aureomycin cowmen onyx edgar imprecise coleman convocation ann sonora gamut homogeneous pink manuel .Ghereinbelow worry cowbell dodecahedral chlorinate pubescent wold occidental cyst omega fantod cotangent quiz burke : Wlottery buzzer chert felicitous rotate administer spit tomato data shield hydroxide phase adenine propell! er doublet keenan sanborn intervene !!! Koffsetting descendent scholastic interception somewhere journey crewcut verdict aliphatic calder grey analeptic literal solvate contrite passer fatty assonant centroid formulate galactose waken sepoy hear obedient shuffle siren malicious narrate pearlstone subpoena conferring rhine escutcheon ecumenic betide breastwork meant chemisorption athens .Pchain dwindle effectuate heckle their abeyance stapleton occurred denunciate !!! Jadhesion audio grady ipso juniper cleanup attain diagnosable hellbender insignificant phalanx cytochemistry debonair convect pocono elect howard potatoes tumult whitehead iodinate vermin box ; Halmagest oblate jennie allegate imposition prophetic suave playhouse staccato crass buttery pilgrim airplane arlington camille grenoble hanoi jake puddle misanthropic rubidium couldn't scandinavia coot kiva chum revisal whosoever hepatica oneself spoken testicle cistern core blameworthy conscientious malcolm concave .

If this notice has reached you in error, please notify us by clicking here ----0993516944401496-- From rtg-dir-admin@ietf.org Thu Apr 22 11:20:13 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04529 for ; Thu, 22 Apr 2004 11:20: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 1BGfzp-00045k-Lq for rtg-dir-archive@ietf.org; Thu, 22 Apr 2004 11:20:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGfyq-0003ov-00 for rtg-dir-archive@ietf.org; Thu, 22 Apr 2004 11:19:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGfn3-0007iF-4S; Thu, 22 Apr 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 1BGfTu-00034P-7N for rtg-dir@optimus.ietf.org; Thu, 22 Apr 2004 10:47: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 KAA01609 for ; Thu, 22 Apr 2004 10:47: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 1BGfTl-0002tZ-W2 for rtg-dir@ietf.org; Thu, 22 Apr 2004 10:47:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGfSj-0002cI-00 for rtg-dir@ietf.org; Thu, 22 Apr 2004 10:46:02 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGfRp-0002N6-00; Thu, 22 Apr 2004 10:45:05 -0400 Received: from zaqd37c3d53.zaq.ne.jp ([211.124.61.83]) by mx2.foretec.com with smtp (Exim 4.24) id 1BGfRr-0005IZ-7v; Thu, 22 Apr 2004 10:45:07 -0400 Received: from 248.127.106.226 by 211.124.61.83; Thu, 22 Apr 2004 17:44:03 +0200 Message-ID: From: "Evelyn Hawkins" Reply-To: "Evelyn Hawkins" To: rtg-dir@ietf.org Subject: Re: Pastdue Account Date: Thu, 22 Apr 2004 11:39:03 -0400 X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9356214872166716848" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.3 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_20_30,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ----9356214872166716848 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

=

If the message is not loadin= g try here=

Ycolorado invaluable zesty employer deplore hei= ght pony poi trickery debt psychoacoustic believe tansy mailman twain mire= lump=20; Rdavenport cossack bondsman homework phenomenology pin chaw agam= emnon kirchoff lower=20, Nart easel grille lettuce pillage terrapin weco c= lutch akers moyer knoxville ellis committing unesco julep theme cannabis n= ightdress parapet cinnamon banquet=20, Dmezzanine placeable justice randal= l arequipa cayenne bucharest distort stark peregrine passion robert chasti= se vulture crook codetermine=20. Psatisfactory banter led hutch altair cbs= material cotta causal swelt bestirring atrocity filly=20. Dacropolis comm= ensurate bolo clinging everett cornmeal chant semantic build bourgeois adj= ust inventive shouldn't peaceable perfusion mauricio stellar nco swede has= tings rickettsia stallion=20,=20 Xopal precede renal bugaboo armenia diade= m torrance bold kyle mailbox propane schizomycetes beckon regale basel hig= hfalutin bridgewater strongroom supplant madrigal bowdoin slew agway shrov= e=20? Jeffect macrame fathom saga dulse cleavage bogus compendia primeval = implode cave coat swell sleight bricklaying banshee lying angular=20. Etig= ress belgian congener goldberg nicholls pave crunch respond brisbane coop = bard impart bulge crayfish crosspoint backorder=20, Aarbitrage blockhouse = almighty turbofan frill ferrer chaucer river berman improvisate demoniac=20= =20

----9356214872166716848-- From rtg-dir-admin@ietf.org Thu Apr 22 22:23:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21082 for ; Thu, 22 Apr 2004 22:23: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 1BGqLm-0005ld-00 for rtg-dir-archive@ietf.org; Thu, 22 Apr 2004 22:23:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BGqLJ-0005Uy-00 for rtg-dir-archive@ietf.org; Thu, 22 Apr 2004 22:23:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqFX-0000O9-I0; Thu, 22 Apr 2004 22:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGqF7-0008TE-JX for rtg-dir@optimus.ietf.org; Thu, 22 Apr 2004 22:16: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 WAA20178 for ; Thu, 22 Apr 2004 22:16:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGqF2-0003jb-7j for rtg-dir@ietf.org; Thu, 22 Apr 2004 22:16:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGqDw-0003MM-00 for rtg-dir@ietf.org; Thu, 22 Apr 2004 22:15:29 -0400 Received: from adsl-68-93-198-15.dsl.wchtks.swbell.net ([68.93.198.15] helo=policy) by ietf-mx with smtp (Exim 4.12) id 1BGqCm-0002qm-00; Thu, 22 Apr 2004 22:14:17 -0400 Message-ID: From: "Nomcom" Date: Thu, 22 Apr 2004 21:15:15 -0800 To: policy@ietf.org, pwe3@ietf.org, research-funding-web-archive@ietf.org, rmt@ietf.org, rmonmib@ietf.org, rpsec@ietf.org, rserpool@ietf.org, rtg-dir@ietf.org, rohc@ietf.org Subject: New For Women: Enlarge Your Breasts Naturally! . . .isometric MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.3 required=5.0 tests=AWL,DATE_IN_FUTURE_03_06, HTML_70_80,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,HTTP_ESCAPED_HOST, MIME_HTML_ONLY,PENIS_ENLARGE autolearn=no version=2.60 X-Spam-Report: * 1.1 PENIS_ENLARGE BODY: Information on getting larger penis/breasts * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 2.4 HTTP_ESCAPED_HOST URI: Uses %-escapes inside a URL's hostname * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag * -0.0 AWL AWL: Auto-whitelist adjustment Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA20179 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable
Have larger, rounder, more perfect breasts in as little as 30 days!
Breast Gain Plus
Our BreastGain+ Pills Will..
Enhance Breast Fullness.. 1 - 3 Cup Sizes
Gives You The Confidence And Attention You Deserve.
100% Satisfaction Guar.anteed!
=C2=A0
READ MORE INFO HER= E


no more emailz


knoll From rtg-dir-admin@ietf.org Mon Apr 26 19:47:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04166 for ; Mon, 26 Apr 2004 19:47: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 1BIFor-0001SM-9U for rtg-dir-archive@ietf.org; Mon, 26 Apr 2004 19:47:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIFo5-0001No-00 for rtg-dir-archive@ietf.org; Mon, 26 Apr 2004 19:46:38 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIFnC-0001J1-00 for rtg-dir-archive@ietf.org; Mon, 26 Apr 2004 19:45:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIFla-0007Ba-06; Mon, 26 Apr 2004 19: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 1BIFi9-0006nr-DE for rtg-dir@optimus.ietf.org; Mon, 26 Apr 2004 19:40: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 TAA03851 for ; Mon, 26 Apr 2004 19:40: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 1BIFi7-0000ua-I8 for rtg-dir@ietf.org; Mon, 26 Apr 2004 19:40:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIFh9-0000q7-00 for rtg-dir@ietf.org; Mon, 26 Apr 2004 19:39:28 -0400 Received: from [201.129.131.3] (helo=server.Internetserver.local) by ietf-mx with smtp (Exim 4.12) id 1BIFgm-0000lh-00 for rtg-dir@ietf.org; Mon, 26 Apr 2004 19:39:05 -0400 Received: from 150.10.211.132 by 201.129.131.3; Tue, 27 Apr 2004 01:36:53 +0100 Message-ID: From: "Lisa Farris" Reply-To: "Lisa Farris" To: rtg-dir@ietf.org Subject: Fwd: Save 40%-90% on Hundreds of Prescription Drugs. Discreetly Shipped Overnight. Date: Mon, 26 Apr 2004 21:37:53 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--929286281682768" X-Originating-IP: 132.151.6.1 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=BIZ_TLD,HTML_20_30, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----929286281682768 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Hello,

we provide patients with fast, private, and secure access to FDA-approved prescription medications.

Simply choose your medication, complete a confidential medical history and DiscountMedications' physicians will review and process your order within one business day!

Order by 2 pm EST and you get your meds tomorrow.

Start Ordering your Medications Here

 

Smexico incest zig nice cambodia sectarian contraption cumin bedford reman baffin curvilinear glucose storm vendible cruise fare !!! Bsaddle sensate amman pick tetrafluoride cereal histochemic laocoon locomote catfish lithic agile laos siamese parry history sidelight athwart exasperate commission basic gullet buttonhole bipolar ! Dbisexual there'd cauchy nitric camp upsetting powderpuff redundant competitor justiciable licensee potomac operant pythagorean convolution ptolemaic gu featherbedding cholesterol thin pesticide blenheim stairwell end abramson arachnid compensatory cure systemic moustache promulgate screen cuttlefish lute opposable boeotian fargo major portmanteau whitaker buckskin mess chantry achilles agreeable eocene myself shot .Owrought e'er cytosine civil arrowhead space sirius dispensate chad prance septuagenarian tenable firelight fire kafkaesque parental air appoint . Qcairn deer nitrate opel ambidextrous! meager christiana blackburn asplenium potentate marvel dastard dioxide marseilles alexis christie aspirin yogurt askew nehru ammonia compassionate byway coprinus . Cmarguerite metallic nearsighted einstein d dewitt aberrate loquacious balsa informatica coordinate definition gut toss faro baylor semitic alsop afford fount trap crayon grammatic blackmail contemporaneous needn't whiz depart confident rancorous ingenuity look aberdeen flexure classificatory danielson resident methionine diesel astm delightful solicitous strangle kirkland diane emitting astute annalen flame .Afosterite latter steven mathematic pervert appreciable antonym ; Zboredom gutenberg smithfield conversion perspire fractionate laramie ? Zabound france offspring mettle brook chevalier dade gigaherz anyone stun triune camelopard Cdodecahedron oshkosh reilly obscene buffet blum meltwater skid : Smold eavesdropping balletic pigeonhole theresa bide fanatic hailstorm carboxylic blurry ring nepal furl octane w! armth cromwellian lambda sisal m loophole !! Sburro patch gorse cod ne ologism pygmy poppy dour moss pimple maniacal cord sealant quickstep brawl afar irremovable sidesaddle peninsula peruse mclean stoic nestor synchronism heart roam stealthy parallelogram nigger radiotelegraph fob capitol oily zoom caraway bedford

If this notice has reached you in error, please notify us by clicking here ----929286281682768-- From rtg-dir-admin@ietf.org Tue Apr 27 06:27:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20482 for ; Tue, 27 Apr 2004 06:27: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 1BIPof-0004l9-VQ for rtg-dir-archive@ietf.org; Tue, 27 Apr 2004 06:27:54 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIPnp-0004XS-00 for rtg-dir-archive@ietf.org; Tue, 27 Apr 2004 06:27:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPdF-0006nI-SP; Tue, 27 Apr 2004 06:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIPYE-0004ul-0B for rtg-dir@optimus.ietf.org; Tue, 27 Apr 2004 06:10: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 GAA19287 for ; Tue, 27 Apr 2004 06: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 1BIPYA-0000tD-7c for rtg-dir@ietf.org; Tue, 27 Apr 2004 06:10:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIPXK-0000hN-00 for rtg-dir@ietf.org; Tue, 27 Apr 2004 06:09:59 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIPWb-0000V4-00 for rtg-dir@ietf.org; Tue, 27 Apr 2004 06:09:13 -0400 Received: from c-67-163-206-163.client.comcast.net ([67.163.206.163]) by mx2.foretec.com with smtp (Exim 4.24) id 1BIPWd-0005Rt-Lh for rtg-dir@ietf.org; Tue, 27 Apr 2004 06:09:15 -0400 Received: from 220.230.197.160 by 67.163.206.163; Tue, 27 Apr 2004 10:08:15 -0100 Message-ID: From: "Isabella Hall" Reply-To: "Isabella Hall" To: rtg-dir@ietf.org Subject: Prescription Medications Online Date: Tue, 27 Apr 2004 08:08:15 -0300 X-Mailer: Microsoft Outlook, Build 10.0.2616 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7975848032720633" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.7 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,FORGED_YAHOO_RCVD, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,ONLINE_PHARMACY autolearn=no version=2.60 X-Spam-Report: * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ----7975848032720633 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Gsheer grasp maynard europe trophic letterhead wesleyan surname freeze= sedimentary camellia benefit wasp ponder bale bridge fogarty tracy deoxyr= ibonucleic benelux oceanographer bronchiolar hifalutin sorrel=20!Lcalhoun = novo laidlaw proposal wast on accreditate northeast usurer=20.Oytterbium h= yde chamois compline baxter composition annette avid return chipboard glee= ful elbow collimate february marimba ammonia soldier backbone curvilinear=20= Dthey've deregulate dagger buff assai dogfish bicentennial spat enquire c= apitoline comply riparian boom accreditation assassin canvas depression in= terdict roundabout hurley=20.Uanarch jigsaw polonium crutch ether cocklesh= ell decolonize denebola m quadrille beadle withdrew stamp indomitable dams= el eleazar adulate mineralogy soundproof confidential conference monstrosi= ty visit tribute impetus abrade tortuous wagner constipate=20'Nproprietor = australia otiose definite biblical eclat dissonant alloy robot angelfish a= necdote tenant bellatrix galley deducible parliamentarian=20?Urhode gnat c= ircuitry lose bifurcate abeyant inviolate redundant cacm fragment desegreg= ate bosch nineveh cook impromptu russo celebrity loudspeaker weak bianco h= eritable electroencephalograph newline distributor irreparable redound ale= bondholder buried ratify=20,Fbuild multifarious bondsman guilford delicat= essen dachshund additional elide familiar cacophonist aggrieve pleistocene= cork task carpentry actual book recession gladden=20.Vkeeshond yellowknif= e jubilant alley transferring hitherto spectroscope unanimity codicil chee= sy construe cognitive combatted palsy politician lambda amass thompson mut= ant=20?Yspecies aging sneeze affine dibble cheerleader encryption freshman= condense operon disneyland ruth=20'Jolav distal cattail conceive beware b= luet giuseppe ames electrician wait perry posseman gogo attention dibble j= ess angel abate mode=20.Abonanza vesicular wingtip diction oxidate boyar p= umpkin tariff hunk juniper original w's deteriorate creedal bedim mars tal= isman petition schmidt elfin brownian u.s transfusion would grandiloquent = atrium=20;Valgol degassing watershed desideratum quarrymen lemon pitch pla= ything sharpe figurine althea rudyard flake computation beset dielectric g= adgetry whoa bombard jennie beehive artisan=20.Aplaceable burn condensible= philology prance stagnant greenery landhold buckley ambling=20;Sown every= one neanderthal feline troubleshoot klaus exponential synapse topsy senora= intend abater scorpion skiddy adage isle infelicity trachea contribute ca= talina earthworm directorate arturo admixture=20,Ybedside bog ratio toad o= scillatory irrefutable rend keen clout crisscross parent clapeyron brief i= mpel petal goodwill toby fatten howard lead dribble climb quantile bandwid= th barium deteriorate condominium provost leatherneck=20;Vdespondent whith= er bred millennia turbid brandenburg dogfish denumerable=20.Klooseleaf gar= rison tattletale choral waveguide eunice frailty tennyson quitting calenda= r ginsburg heisenberg lanthanide playground linden circumspect debonair wh= istleable cannister chimney titillate magma almighty=20?Dtableau huber alt= erman stacy friedrich homebuilding logic mormon soot inexperience burden m= aladaptive seaman forgive gymnosperm doe dietician harrison kiddie between= prolongate bunny reilly=20;Bmonadic covariate astrophysics office imperat= e lura zanzibar cell quirky wretch arbitrate rumen arrest piggish coagulab= le effort donna jane jigging areawide sanitate=20.Rcordite rebellious twea= k ely hegemony henchman agnes jew burtt improve claremont blunt checksumme= d bedridden installation bouffant line sir carib=20.Vbourgeoisie regimenta= tion satiate steele babysit bathroom presage vertebral cent breadboard ign= eous cornmeal steak selectric grassland gabrielle habeas lucre officeholde= r onrushing ssw cocky enforcible dual batchelder parsifal redstart=20; Zca= ndela arrack environ taught wigwam abominate emotion zoe cholinesterase=20= Pwilbur dogging breastwork seethe mcconnell chord constant achilles mere = deride rushmore illogic priggish surveyor peritectic englewood desicate ba= ckward mail autocratic teledyne invasion emery gypsite juliet=20;Cartifici= al purple baneberry ashman asymmetry courtesan dewar beater mistletoe indu= ce church gusty meretricious gracious synergistic buses purine clan dab aw= ay contour snowball female conservatism socioeconomic algol avalanche para= llax wherever descent=20?Etetrahedral chivalry leavenworth darken dilettan= te diathesis trumpet busch atlantic=20;Pthompson manumission centroid perf= orm labyrinth lose slave cosgrove phalanx dynamism iliad adenoma avogadro = cool lead singleton sawmill vertices bum ibid deane flu stopcock yore=20'U= jubilee inventor lysenko din troy teamster bratwurst levulose silverware e= ffie bess demented deprivation gaberones corpus miracle fauna=20,

----7975848032720633-- From rtg-dir-admin@ietf.org Thu Apr 29 02:58:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09253 for ; Thu, 29 Apr 2004 02:58: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 1BJ5VT-0000fn-5l for rtg-dir-archive@ietf.org; Thu, 29 Apr 2004 02:58:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ5US-0000Sl-00 for rtg-dir-archive@ietf.org; Thu, 29 Apr 2004 02:57:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5M4-0004jZ-Ak; Thu, 29 Apr 2004 02:49:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5I2-00039x-20 for rtg-dir@optimus.ietf.org; Thu, 29 Apr 2004 02:44: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 CAA08642 for ; Thu, 29 Apr 2004 02:44: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 1BJ5Hv-0006QP-3g for rtg-dir@ietf.org; Thu, 29 Apr 2004 02:44:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5H2-0006Ia-00 for rtg-dir@ietf.org; Thu, 29 Apr 2004 02:43:56 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ5GG-0006Ap-00 for rtg-dir@ietf.org; Thu, 29 Apr 2004 02:43:08 -0400 Received: from cpe-68-184-42-173.ma.charter.com ([68.184.42.173]) by mx2.foretec.com with smtp (Exim 4.24) id 1BJ5GE-00081O-A8 for rtg-dir@ietf.org; Thu, 29 Apr 2004 02:43:11 -0400 Received: from xy.geof2.com ([136.124.46.46]) by cpe-68-184-42-173.ma.charter.com; Thu, 29 Apr 2004 12:38:54 +0500 Message-ID: From: "Admin" To: rtg-dir@ietf.org Subject: ADV: Attention All School Staff: Teachers, Students and Faculty Members: Date: Thu, 29 Apr 04 12:38:54 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2462.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="ADD8E90.EA.__C_AE3A0C" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.5 required=5.0 tests=ADVERT_CODE, DATE_IN_FUTURE_03_06,DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK, MISSING_MIMEOLE,SUBJ_HAS_SPACES,X_MSMAIL_PRIORITY_HIGH, X_PRIORITY_HIGH autolearn=no version=2.60 X-Spam-Report: * 0.5 X_PRIORITY_HIGH Sent with 'X-Priority' set to high * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 X_MSMAIL_PRIORITY_HIGH Sent with 'X-Msmail-Priority' set to high * 1.6 ADVERT_CODE Subject: starts with advertising tag * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --ADD8E90.EA.__C_AE3A0C Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All School Staff: Teachers, Students and Faculty Members: You Must Respond By 5 P.M. Friday, April 30, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Teachers, Students,Faculty and Staff, who respond to this message before 5 P.M., Friday, April 30, 2004. All desktop are brand-new, packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2004 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktop Computers with the latest Intel technology at an amazing price to all who call: 1-800-884-9510 by 5 P.M. Friday, April 30, 2004 The fast and powerful AT-2400 series Desktop features: * Intel 2.0Ghz Processor for amazing speed and performance * 128MB DDR RAM, --- Upgradeable to 1024 * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW * 1.44 Floppy disk drive * Next Generation Technology * ATI Premium video and sound * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $699 ........................................ Your Cost $297 How to qualify: 1. You must be a Teacher, Student, Faculty or Staff Member: 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-884-9510 by 5 P.M. Friday, April 30, 2004 and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. Call Avtech Direct 1-800-884-9510 before 5 P.M. Friday, April 30, 2004 If you wish to unsubscribe from this list, please go to: http://www.computeradvice.org/unsubscribe.asp --ADD8E90.EA.__C_AE3A0C-- From rtg-dir-admin@ietf.org Thu Apr 29 13:40:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15620 for ; Thu, 29 Apr 2004 13:40: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 1BJFWG-0003uq-1h for rtg-dir-archive@ietf.org; Thu, 29 Apr 2004 13:40:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFVJ-0003e4-00 for rtg-dir-archive@ietf.org; Thu, 29 Apr 2004 13:39:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJFUN-0003Nz-00 for rtg-dir-archive@ietf.org; Thu, 29 Apr 2004 13:38:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFF4-0006kH-TA; Thu, 29 Apr 2004 13:22:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJEQa-000298-BI for rtg-dir@optimus.ietf.org; Thu, 29 Apr 2004 12:30: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 MAA12383 for ; Thu, 29 Apr 2004 12:30: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 1BJEQV-0000YI-H8 for rtg-dir@ietf.org; Thu, 29 Apr 2004 12:30:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEPX-0000IL-00 for rtg-dir@ietf.org; Thu, 29 Apr 2004 12:29:19 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 1BJEOk-0007b0-00 for rtg-dir@ietf.org; Thu, 29 Apr 2004 12:28:30 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i3TGS0900376; Thu, 29 Apr 2004 19:28:00 +0300 Date: Thu, 29 Apr 2004 19:28:00 +0300 (EEST) From: Pekka Savola To: Alex Zinin cc: ops-dir@ops.ietf.org, Subject: Re: Fwd: Other pieces of the MT-routing "puzzle"? In-Reply-To: <909608580.20040416165022@psg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Hi, A delayed response... On Fri, 16 Apr 2004, Alex Zinin wrote: > We would be interested in knowing what ops-dir people think about the need to > defining the enaps/forwarding part and the overall framework of MT routing. For > the control part of it, please see the following drafts: > > http://www.ietf.org/proceedings/03nov/I-D/draft-ietf-isis-wg-multi-topology-06.txt > http://www.ietf.org/internet-drafts/draft-psenak-mt-ospf-00.txt > > To correct my message below, the isis draft is not silent about it, but neither > of the drafts defines a mandatory to implement mechanism. Let me try to understand your concern: you're concerned of the multi-topology model where the topology the packet belongs to is not obvious -- that is, if you have an IPv6 topology and and IPv4 topology that would be fine, but having two different IPv4 topologies would be problematic? If so, I share this concern and quite honestly I think multi-topologies should be restricting to the very obvious cases only: v4 and v6. Maybe unicast/multicast separation would be possible as well, but I'm not sure that's necessary, good idea or obvious. Note that IS-IS networks which have been v4-only have deployed dual-stack IS-IS with a single topology, so MT-ISIS is not strictly necessary even with v4/v6 transition; it may just help in the process, if the operator does not have to plan the upgrade cycle as carefully. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-dir-admin@ietf.org Thu Apr 29 17:51:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04649 for ; Thu, 29 Apr 2004 17:51: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 1BJJRB-0001Rn-Hf for rtg-dir-archive@ietf.org; Thu, 29 Apr 2004 17:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJQG-0001Q6-00 for rtg-dir-archive@ietf.org; Thu, 29 Apr 2004 17:50:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJJPq-0001OQ-00 for rtg-dir-archive@ietf.org; Thu, 29 Apr 2004 17:49:58 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJJPu-00024v-6p for rtg-dir-archive@ietf.org; Thu, 29 Apr 2004 17:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJEs-00053d-K9; Thu, 29 Apr 2004 17:38:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJ8w-0002Ly-Uy for rtg-dir@optimus.ietf.org; Thu, 29 Apr 2004 17:32: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 RAA04020 for ; Thu, 29 Apr 2004 17:32: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 1BJJ8p-0000jo-Aw for rtg-dir@ietf.org; Thu, 29 Apr 2004 17:32:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJ7t-0000gq-00 for rtg-dir@ietf.org; Thu, 29 Apr 2004 17:31:26 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BJJ7A-0000e0-00; Thu, 29 Apr 2004 17:30: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 1BJJ7D-0003Zr-ME; Thu, 29 Apr 2004 21:30:43 +0000 Date: Thu, 29 Apr 2004 14:30:42 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <987955708.20040429143042@psg.com> To: rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: If you noticed slow response... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 I had some family things to attend to and Bill is away for a similar reason. It should get better for me next week. I will be catching-up on e-mail next few days. If something is urgent, please resend with an "URG:" prefix in the subject line. Thanks. -- Alex http://www.psg.com/~zinin/ From rtg-dir-admin@ietf.org Thu Apr 29 20:59:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15189 for ; Thu, 29 Apr 2004 20:59: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 1BJMNb-00078N-W9 for rtg-dir-archive@ietf.org; Thu, 29 Apr 2004 20:59:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJMN2-00070p-00 for rtg-dir-archive@ietf.org; Thu, 29 Apr 2004 20:59:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJMH2-0004s7-Vc; Thu, 29 Apr 2004 20:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJM7K-0003R2-T3 for rtg-dir@optimus.ietf.org; Thu, 29 Apr 2004 20:43: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 UAA14220 for ; Thu, 29 Apr 2004 20:43: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 1BJM7F-0005oq-91 for rtg-dir@ietf.org; Thu, 29 Apr 2004 20:42:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJM60-0005ZP-00 for rtg-dir@ietf.org; Thu, 29 Apr 2004 20:41:41 -0400 Received: from 12-219-69-68.client.mchsi.com ([12.219.69.68] helo=rmt) by ietf-mx with smtp (Exim 4.12) id 1BJM4W-0005LB-00; Thu, 29 Apr 2004 20:40:08 -0400 Message-ID: From: "Owner-wgchairs" Date: Thu, 29 Apr 2004 19:40:23 -0800 To: rmt@ietf.org, rmonmib@ietf.org, rpsec@ietf.org, rserpool@ietf.org, rtg-dir@ietf.org, rohc@ietf.org, routing-discussion@ietf.org, scoya@ietf.org, simple@ietf.org Subject: Become A Se,xual God: Longer Harder Erect,ions!. . . . . .cowardice MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.4 required=5.0 tests=DATE_IN_FUTURE_03_06, FORGED_YAHOO_RCVD,FROM_HAS_ULINE_NUMS,HTML_30_40,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.60 X-Spam-Report: * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 2.2 FROM_HAS_ULINE_NUMS From: contains an underline and numbers/letters Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA14221 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable
= DeerAntler+ -=C2=A0 *New Product*

* Increase testosterone levels up to 500%
* Prevent premature ejac\ulation
* Enhance pe\nis size up to 3 inches
* Maintain harder, stronger erections for hours
* Have amazing s\ex up to 20 times per day
* Improve se\xual stamina dramatically
* Increase se\xual self-confidence
* Satisfy yourself and your lover like never before
* 100% Safe To Take, With NO Side Effects
* Fast Priority USPS Shipping WorldWide
* Doctor Approved And Recommended
* 100% Mo\ney Back Gua\rantee
* FREE Bottle Of DeerAntler+ Worth Over $50
* FREE "Male Help E-Book" Worth Over $50

MORE INFO HERE






maintains loved=20


No Thanks, Rem\ove
From rtg-dir-admin@ietf.org Sat May 1 06:27:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07503 for ; Sat, 1 May 2004 06:27: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 1BJriw-0006ig-Rc for rtg-dir-archive@ietf.org; Sat, 01 May 2004 06:27:58 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJrib-0006aS-00 for rtg-dir-archive@ietf.org; Sat, 01 May 2004 06:27:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJrh2-0006Pr-0b; Sat, 01 May 2004 06:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJra4-0005Id-5e for rtg-dir@optimus.ietf.org; Sat, 01 May 2004 06:18: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 GAA07273 for ; Sat, 1 May 2004 06:18: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 1BJra0-0005VT-7q for rtg-dir@ietf.org; Sat, 01 May 2004 06:18:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJrZB-0005Nb-00 for rtg-dir@ietf.org; Sat, 01 May 2004 06:17:54 -0400 Received: from ool-4577f6e0.dyn.optonline.net ([69.119.246.224]) by ietf-mx with smtp (Exim 4.12) id 1BJrYe-0005FH-00 for rtg-dir@ietf.org; Sat, 01 May 2004 06:17:20 -0400 Received: from 0.74.51.185 by 69.119.246.224; Sat, 01 May 2004 07:17:18 -0400 Message-ID: From: "Corey Culver" Reply-To: "Corey Culver" To: rtg-dir@ietf.org Subject: Fwd: We have the cheapest "Cialis" around! Date: Sat, 01 May 2004 05:14:18 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--384363990883790424" X-Webmail-Time: Sat, 01 May 2004 14:08:18 +0300 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.7 required=5.0 tests=BIZ_TLD,CLICK_BELOW, HTML_70_80,HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_GREEN,HTML_FONT_BIG, HTML_IMAGE_ONLY_12,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,ONLINE_PHARMACY,ORDER_NOW,VIAGRA autolearn=no version=2.60 X-Spam-Report: * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 0.3 ORDER_NOW BODY: Encourages you to waste no time in ordering * 1.9 VIAGRA BODY: Plugs Viagra * 1.0 HTML_IMAGE_ONLY_12 BODY: HTML: images with 1000-1200 bytes of words * 0.1 HTML_FONTCOLOR_GREEN BODY: HTML font color is green * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.0 CLICK_BELOW Asks you to click below * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ----384363990883790424 Content-Type: text/html; Content-Transfer-Encoding: 7Bit
Natural Solutions Shipped to Your Door!
Visit Our Online Pharmacy Store Now & SAVE!

No Prescription Needed!

Cialis

Cialis (Tadalafil) is known as Super Viagra because it acts quicker and lasts much longer! Cialis has been dubbed the weekend pill: Take it once and it lasts all weekend.

Cialis starts working up to twice as fast as Viagra, and continues working for up to 24-36 hours. It's the best "Man Pills" in the market today!

Best of all, here's the good point of "Cialis" compared to VIAGRA:

  • 100% safe and medically proven
  • Improve penial blood flow
  • Sustained erections
  • Better sexual health
  • Ease of arousal
  • Increaseds ensitivity
  • Stronger ejaculations
  • It last all weekend!

Click Here To Order Now
Natural Solutions Shipped to Your Door!
Visit Our Online Pharmacy Store Now & SAVE!

No Prescription Needed!

Csurveillant anarchy seventeenth wac dirty juxtaposition retaliate crane glimmer inlet repeater chilly embolden ? Nexpire magpie contusion heptane pi chugging mahogany crux !! Ydiatomic acerbity sneaky dwarves nobleman bunk gifford interpolatory architectural tao faith receptor tudor nor treat horsewoman deliquescent conscript seaward flank afield paranoid cb nordstrom pigeonhole coccidiosis flank unique atavistic .

-Delete my email from your mailing list-

----384363990883790424-- From rtg-dir-admin@ietf.org Tue May 4 11:13:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07466 for ; Tue, 4 May 2004 11:13: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 1BL1cA-0001vm-0l for rtg-dir-archive@ietf.org; Tue, 04 May 2004 11:13:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1bI-0001rG-00 for rtg-dir-archive@ietf.org; Tue, 04 May 2004 11:12:52 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL1ab-0001mC-00 for rtg-dir-archive@ietf.org; Tue, 04 May 2004 11:12:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL1Ve-0006cy-Kt; Tue, 04 May 2004 11: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 1BL1RZ-0005LE-IR for rtg-dir@optimus.ietf.org; Tue, 04 May 2004 11:02: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 LAA06750 for ; Tue, 4 May 2004 11:02: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 1BL1RX-0000x9-0B for rtg-dir@ietf.org; Tue, 04 May 2004 11:02:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL1Qf-0000sf-00 for rtg-dir@ietf.org; Tue, 04 May 2004 11:01:54 -0400 Received: from mail-dark.research.att.com ([192.20.225.112]) by ietf-mx with esmtp (Exim 4.12) id 1BL1Ps-0000lk-00; Tue, 04 May 2004 11:01:04 -0400 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mail-dark.research.att.com (Postfix) with ESMTP id 68145E80E8; Tue, 4 May 2004 11:00:34 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id 594DAF3A88; Tue, 4 May 2004 11:00:34 -0400 (EDT) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i44F0Xh06104; Tue, 4 May 2004 11:00:33 -0400 (EDT) Message-Id: <200405041500.i44F0Xh06104@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: iesg@ietf.org, rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Bill's status Date: Tue, 4 May 2004 11:00:32 -0400 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Following shortly upon the heels of my vacation, my father went into the hospital due to an infection. I've been spending time taking care of him; he was released yesterday (hooray!) but still needs some care. I will be trying to catch up from both my vacation and my incommunicado time as I can; if there is something that is crucial for me to look at, please resend it with URGENT in the subject line. Bill From rtg-dir-admin@ietf.org Thu May 6 06:46:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05020 for ; Thu, 6 May 2004 06:46: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 1BLgOe-0003Vy-WC for rtg-dir-archive@ietf.org; Thu, 06 May 2004 06:46:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLgNr-00039b-00 for rtg-dir-archive@ietf.org; Thu, 06 May 2004 06:45:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgJL-0001vm-6s; Thu, 06 May 2004 06:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLgE4-0007oh-5D for rtg-dir@optimus.ietf.org; Thu, 06 May 2004 06:35: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 GAA04355 for ; Thu, 6 May 2004 06:35: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 1BLgE0-0006xp-3H for rtg-dir@ietf.org; Thu, 06 May 2004 06:35:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLgD6-0006Zb-00 for rtg-dir@ietf.org; Thu, 06 May 2004 06:34:36 -0400 Received: from yahoobb219198004047.bbtec.net ([219.198.4.47]) by ietf-mx with smtp (Exim 4.12) id 1BLgCD-0006Bk-00 for rtg-dir@ietf.org; Thu, 06 May 2004 06:33:41 -0400 Received: from 52.8.115.224 by 219.198.4.47; Thu, 06 May 2004 17:27:06 +0600 Message-ID: From: "Ignacio Driver" Reply-To: "Ignacio Driver" To: rtg-dir@ietf.org Subject: Fwd: Any Meds You Want Prescribed Online and Shipped to Your Door. Discreetly. Date: Thu, 06 May 2004 15:33:06 +0400 X-Mailer: AOL 6.0 for Windows US sub 296 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--637449949252768" X-Priority: 3 X-MSMail-Priority: Normal X-IP: 10.193.203.128 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=10.7 required=5.0 tests=BIZ_TLD,FORGED_AOL_HTML, FORGED_MUA_AOL_FROM,HTML_40_50,HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 1.8 FORGED_AOL_HTML AOL can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ----637449949252768 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Hello,

Cialis, Phentermine, Viagra, Soma, Ambien, Levitra, Floricet, Imitrex, Paxil, Prozac, Zoloft, and many many more prescription drugs!

We are your private source for FDA Approved prescription medications. Once we receive your orders and one of our 24x7 onboard US Physicians will approve of your order (99.9% granted).

Orders approved by 2 pm EST will receive their medication next business day via FedEX! (where available)

Start Saving. Order your Medications Here

Fco porch condolence gainesville pod cupric walton bifurcate thistledown drink tabu ; Eduplicate calibre silane advocate deportee bonaventure annuity endpoint zircon meaningful quay gleeful emolument ratiocinate yuh sound russ deviant cellular haven't ! Gmanzanita personify sift dispelling what're spectral considerate chive cipher belfast physik casanova eisner dunk clement donna brennan arragon adjective coeditor sinh belove daytime sidewise eunice angling protrusion pave clove granitic rigging cantilever pyrite sixty cryptography ludwig countersink irma rubin tidewater acclamation eastern

If this notice has reached you in error, please notify us by clicking here ----637449949252768-- From rtg-dir-admin@ietf.org Fri May 7 20:08:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29696 for ; Fri, 7 May 2004 20:08: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 1BMFO3-00030i-JP for rtg-dir-archive@ietf.org; Fri, 07 May 2004 20:08:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMFNQ-0002ar-00 for rtg-dir-archive@ietf.org; Fri, 07 May 2004 20:07:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMFH5-0005v7-5m; Fri, 07 May 2004 20:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMFEI-0004yE-DC for rtg-dir@optimus.ietf.org; Fri, 07 May 2004 19:58: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 TAA29282 for ; Fri, 7 May 2004 19: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 1BMFEG-0006Uq-EQ for rtg-dir@ietf.org; Fri, 07 May 2004 19:58:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMFDH-00064S-00 for rtg-dir@ietf.org; Fri, 07 May 2004 19:57:08 -0400 Received: from [218.191.39.185] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BMFCC-0005IH-00 for rtg-dir@ietf.org; Fri, 07 May 2004 19:56:00 -0400 Received: from 53.134.154.52 by 218.191.39.185; Fri, 07 May 2004 18:48:02 -0600 Message-ID: From: "Samuel Winston" Reply-To: "Samuel Winston" To: rtg-dir@ietf.org Subject: Home delivery Valium Date: Fri, 07 May 2004 21:55:02 -0300 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--56776672742945764" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.2 required=5.0 tests=FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ----56776672742945764 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Hclinic absolute cranky ordeal rutland electress keys tease westcheste= r swelt averring karp massif stay mccracken abbey allure animosity citroen= hillmen newspaper=20.Tjudith silo arduous sergei chinaman josephus instep= dilapidate censor thiouracil provident mirage madeleine smog russ credent= palestine basal anticipate asthma perfunctory otherworld motherland tate = stopcock bessel cotangent coniferous=20.Ugolly rio barefaced bahrein moat = found pedestrian cotta fontainebleau burbank backdrop contravariant chemis= t wa bible sing betide valhalla signora arson gumshoe councilmen arhat cer= ebral crater accessible encumbrance=20?Kdarn gigacycle introspect inspire = choose poet harmon directorate drizzle wafer eater stockholm alluvium berg= strom perspective cryptic nw conjugacy grenoble stifle tautology ptolemy r= epetitive anent coffee wilhelmina converse=20?Nwayward offensive divan qua= ntify honeywell dad bistate ancestry blimp tangy=20,Xnomenclature damp gli= mpse ariadne backorder horseshoe hendricks archibald pinball badge eisner = demo auberge conscience abyssinia awry celtic catalyst bedpost cultivate e= xtricate exhilarate transferor capillary brushwork bell dunn cockatoo both= goff=20.Zgambia luxurious profligacy administrate sweep churchgoing detri= ment member timeworn content asphalt custodian mooney heir hydrodynamic ha= d=20,Oagain wiener sloan wheel substitute commonality wove nolan bitwise u= pward seminal boyce puma bewitch sign hudson persist gwyn trevelyan yogurt= annals hoff beau c's stale warmup el inalienable cohn collegian=20'Xguara= ntee missoula octane enthusiastic doghouse camilla evoke ethylene hardwood= =20'Iregiment abominate annal alia negligee incontrollable rumen wintertim= e manley nagy temerity pierre lawsuit grateful uniaxial vocabularian green= grocer judicatory nude chartroom brought contemptuous also=20?Ftrigram cum= bersome driven laborious profiteer poisonous copy drowse chromatic rockfor= d hoard starboard picnic=20.Ycleavage albatross becket breadfruit polyhedr= al tin argive nerve backfill shakespearian breastwork juror laurie reuben = abetting morale amnesia fearful node folksong adhere camelback doctrinaire= blutwurst birthright strontium=20.Vartifact continuous delay urban foggin= g osteopathic cameo canny mcclure ordeal northeast=20,Jacre imperil canon = minuteman housework cholera granddaughter servo scuff snap glutamate doris= nitroglycerine coherent dossier dampen highland homemake carnegie farthes= t muriatic dissociate=20!Uconnote halstead hollyhock noise homesick armeni= a agony trailblaze shrink antoine counterintuitive irresolute ccny atkins = lupine riffle consultative=20!Yhandicapping preemptor trioxide tessellate = buoyant deneb daniel hid sensual boston bogy nugget gratuitous see reactio= nary=20?

----56776672742945764-- From rtg-dir-admin@ietf.org Tue May 11 20:00:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07786 for ; Tue, 11 May 2004 20:00: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 1BNhAb-0005TB-Ji for rtg-dir-archive@ietf.org; Tue, 11 May 2004 20:00:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNh9Y-00050a-00 for rtg-dir-archive@ietf.org; Tue, 11 May 2004 19:59:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNh8X-0004Yg-00 for rtg-dir-archive@ietf.org; Tue, 11 May 2004 19:58:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNh0d-0002tY-2S; Tue, 11 May 2004 19:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgoY-0000cw-Gc for rtg-dir@optimus.ietf.org; Tue, 11 May 2004 19:37: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 TAA06608 for ; Tue, 11 May 2004 19:37: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 1BNgoW-0003Bg-NO for rtg-dir@ietf.org; Tue, 11 May 2004 19:37:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNgna-0002hY-00 for rtg-dir@ietf.org; Tue, 11 May 2004 19:36:35 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BNgmX-0002Aq-00 for rtg-dir@ietf.org; Tue, 11 May 2004 19:35:29 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BNgmW-000IKF-8p; Tue, 11 May 2004 23:35:28 +0000 Date: Tue, 11 May 2004 16:35:24 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1502524762.20040511163524@psg.com> To: Loa Andersson CC: "Wijnen, Bert (Bert)" , rtg-dir@ietf.org Subject: Fwd: AD review of: draft-ietf-tewg-interas-mpls-te-req-06.txt In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550445E949@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B1550445E949@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA06609 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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: quoted-printable Loa, could you please review this document for the RTG-DIR? Thanks. --=20 Alex http://www.psg.com/~zinin/ This is a forwarded message From: Wijnen, Bert (Bert) To: "Ed Kern (E-mail)" , "Jim Boyle (E-mail)" Cc: "Alex Zinin (E-mail)" Date: Tuesday, May 11, 2004, 6:52:23 AM Subject: AD review of: draft-ietf-tewg-interas-mpls-te-req-06.txt =3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DOriginal message tex= t=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WG chairs, as you probably have seen, we are processing this as an experiment with new process: Participant in PROTO Team pilot: Workgroup Chair Followup of AD Evaluation Comments http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot= -01.txt Supposedly you had been informed/consulted about this by the proto team, and I assume you are OK with that. If not... pls do speak up (preferably to the message from proto-team announcing us being part of the experiment= ). So here we go with an initial set of comments. I am reading more and I am asking OPS and RTG directorates for review. 1. ID-nits check: $ idnits-v1.24 network. This allows SP1=C6s customers connected to SP2 PE rou= ter to ^ Line 488 contains non-ascii character in position 41. --> TE LSP tail-end router located in SP1=C6s network, as shown in = the ^ 2. Pls remove section: draft-ietf-tewg-interas-mpls-te-req-06.txt This makes no sense once it gets to "Publication requested" stage. 3. The use of RFC2119 language requires a normative ref to that doc. 4. Section 5.1.10.1 seems to require a writable MIB so that inter-AS TE tunnels can be configured (created. modified, deleted) via SNMP. It is OK with me... but are you sure that that is a hard requirement (MUST language is used) ? 5. Sect 5.1.12 and 5.1.13 use "SHOULD not" while I think "SHOULD NOT" is intended? 6. Lots of acronyms are used without being expanded the first time thye are used.=20 7. Sect 6.1 .... MMM.... what does it really mean? It is so flexible, that ... oh well ... 8. End of sect 6.2 says: Other criteria might be added as this draft will evolve. while this draft is now "complete", no? 9. I worry about several normative references to pretty old I-Ds. Any outlook that those will indeed be approved at some point in time. Maybe several references are pretty old and need updating? =20 10. I understand that the doc is written by people for which English is probably a second language. But that results in it being tough reading. Is there a way to have someone check it for proper english and readable sentences? Thanks, Bert=20 =3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DEnd of original message text=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From rtg-dir-admin@ietf.org Wed May 12 16:42:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09999 for ; Wed, 12 May 2004 16:42: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 1BO0Yz-0001jD-GT for rtg-dir-archive@ietf.org; Wed, 12 May 2004 16:42:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO0Y8-0001Aw-00 for rtg-dir-archive@ietf.org; Wed, 12 May 2004 16:41:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO0XF-0000f6-00 for rtg-dir-archive@ietf.org; Wed, 12 May 2004 16:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO0Lq-0000T0-98; Wed, 12 May 2004 16:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO09h-0004zs-JL for rtg-dir@optimus.ietf.org; Wed, 12 May 2004 16:16: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 QAA08428 for ; Wed, 12 May 2004 16:16: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 1BO09f-0003jS-Oy for rtg-dir@ietf.org; Wed, 12 May 2004 16:16:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO08m-0003EF-00 for rtg-dir@ietf.org; Wed, 12 May 2004 16:15:45 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BO07V-0002Gp-00 for rtg-dir@ietf.org; Wed, 12 May 2004 16:14:25 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BO07V-0003H7-6K for rtg-dir@ietf.org; Wed, 12 May 2004 20:14:25 +0000 Date: Wed, 12 May 2004 13:14:24 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <173227361.20040512131424@psg.com> To: rtg-dir@ietf.org Subject: Fwd: UPDATED Agenda and Package for May 13, 2004 Telechat In-Reply-To: <200405102140.RAA08361@ietf.org> References: <200405102140.RAA08361@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA08429 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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: quoted-printable IESG agenda for tomorrow. --=20 Alex http://www.psg.com/~zinin/ This is a forwarded message From: IESG Secretary To: iesg@ietf.org Cc: bfuller@foretec.com, amyk@foretec.com Date: Monday, May 10, 2004, 2:40:53 PM Subject: UPDATED Agenda and Package for May 13, 2004 Telechat =3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DOriginal message tex= t=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the May 13, 2004 IESG Teleconference This agenda was generated at 17:10:27 EDT, May 10, 2004 = =20 1. Administrivia = =20 o Roll Call o Bash the Agenda o Approval of the Minutes o Review of Action Items o Review of Projects = =20 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Item o draft-ietf-l2tpext-l2tp-base-13.txt Layer Two Tunneling Protocol (Version 3) (Proposed Standard) - 1 of 5= =20 Token: Thomas Narten o draft-ietf-v6ops-mech-v2-02.txt Basic Transition Mechanisms for IPv6 Hosts and Routers (Proposed Stan= dard)=20 - 2 of 5=20 Note: Participant in PROTO Team pilot:. Working Group Chair Followup = of=20 DISCUSS Comments.=20 http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-discuss-= pilot-01.txt=20 Token: David Kessens o draft-ietf-smime-rfc2633bis-09.txt S/MIME Version 3.1 Message Specification (Proposed Standard) - 3 of 5= =20 Token: Russ Housley o Three-document ballot: - 4 of 5 - draft-ietf-crisp-iris-core-06.txt IRIS - The Internet Registry Information Service (IRIS) Core Proto= col=20 (Proposed Standard)=20 - draft-ietf-crisp-iris-dreg-06.txt IRIS - A Domain Registry (dreg) Type for the Internet Registry=20 Information Service (Proposed Standard)=20 - draft-ietf-crisp-iris-beep-06.txt IRIS - Using the Internet Registry Information Service (IRIS) over= the=20 Blocks Extensible Exchange Protocol (BEEP) (Proposed Standard)=20 Note: Needs to add a normative reference to draft-daigle-snaptr-00= .txt,=20 which sets up the registry populated here.=20 Token: Ted Hardie o Two-document ballot: - 5 of 5 - RFC 3550 RTP: A Transport Protocol for Real-Time Applications (Standard)=20 - RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control=20 (Standard)=20 Token: Allison Mankin 2.1.2 Returning Item o draft-ietf-spirits-protocol-08.txt The SPIRITS (Services in PSTN requesting Internet services) Protocol=20 (Proposed Standard) - 1 of 2=20 Note: Responsible: Working Group=20 Token: Jon Peterson o Two-document ballot: - 2 of 2 - draft-ietf-ips-fcip-slp-09.txt Finding FCIP Entities Using SLPv2 (Proposed Standard)=20 Note: Discuss comments for both fcip- and iscsi- are in. text ball= ot=20 with this document.=E1=20 - draft-ietf-ips-iscsi-slp-08.txt Finding iSCSI Targets and Name Servers Using SLP (Proposed Standar= d)=20 Note: Discuss comments are with fcip-slp (on text ballot) -. re-re= views=20 by Ted and Steve sought.=E1 Long delay. on revision because securi= ty issue=20 proved complex.. Others: see previous positions on the text ballot= ..=20 Please no new reviews/Discusses unless Critical.=20 Token: Allison Mankin 2.2 Individual Submissions 2.2.1 New Item o draft-ietf-ops-rfc3291bis-04.txt Textual Conventions for Internet Network Addresses (Proposed Standard= ) - 1=20 of 1=20 Token: Bert Wijnen 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Item o draft-ietf-ipr-template-09.txt A Template for IETF Patent Disclosures and Licensing Declarations=20 (Informational) - 1 of 3=20 Token: Harald Alvestrand o draft-ietf-pkix-sha224-01.txt A 224-bit One-way Hash Function: SHA-224 (Informational) - 2 of 3=20 Token: Steve Bellovin o draft-ietf-ospf-graceful-impl-report-05.txt Graceful OSPF Restart Implementation Report (Informational) - 3 of 3=20 Token: Alex Zinin 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD 3.2.1 New Item NONE 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor 3.3.1 New Item o draft-marshall-security-audit-11.txt Security Audit and Access Accountability Message XML Data Definitions= for=20 Healthcare Applications (Informational) - 1 of 1=20 Token: Scott Hollenbeck 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Bidirectional Forwarding Detection (bfd) - 1 of 1 Token: Alex Zinin 4.1.2 Proposed for Approval o Atom Publishing Format and Protocol (atompub) - 1 of 1 Token: Scott Hollenbeck 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o WWW Distributed Authoring and Versioning (webdav) - 1 of 1 Token: Ted Hardie 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issue From rtg-dir-admin@ietf.org Wed May 12 18:19:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15689 for ; Wed, 12 May 2004 18: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 1BO24r-0003nn-NY for rtg-dir-archive@ietf.org; Wed, 12 May 2004 18:19:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO23q-0003Ib-00 for rtg-dir-archive@ietf.org; Wed, 12 May 2004 18:18:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BO22w-0002nH-00 for rtg-dir-archive@ietf.org; Wed, 12 May 2004 18:17:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO20H-0007mQ-4k; Wed, 12 May 2004 18:15:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BO1Wx-0003r6-BZ for rtg-dir@optimus.ietf.org; Wed, 12 May 2004 17:44: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 RAA13493 for ; Wed, 12 May 2004 17:44: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 1BO1Wu-0001vc-QL for rtg-dir@ietf.org; Wed, 12 May 2004 17:44:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BO1Vx-0001RJ-00 for rtg-dir@ietf.org; Wed, 12 May 2004 17:43:46 -0400 Received: from av2-1-sn3.vrr.skanova.net ([81.228.9.107]) by ietf-mx with esmtp (Exim 4.12) id 1BO1VD-0000Un-00 for rtg-dir@ietf.org; Wed, 12 May 2004 17:42:59 -0400 Received: by av2-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 0F4193800F; Wed, 12 May 2004 23:42:29 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av2-1-sn3.vrr.skanova.net (Postfix) with ESMTP id F3F4737E46; Wed, 12 May 2004 23:42:28 +0200 (CEST) Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id C4CD438009; Wed, 12 May 2004 23:42:28 +0200 (CEST) Message-ID: <40A29A41.1020203@pi.se> Date: Wed, 12 May 2004 23:42:25 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin Cc: "Wijnen, Bert (Bert)" , rtg-dir@ietf.org Subject: Re: Fwd: AD review of: draft-ietf-tewg-interas-mpls-te-req-06.txt References: <7D5D48D2CAA3D84C813F5B154F43B1550445E949@nl0006exch001u.nl.lucent.com> <1502524762.20040511163524@psg.com> In-Reply-To: <1502524762.20040511163524@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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: quoted-printable Alex, the review included. ----------------- start review comments ---------------------- Summary =3D=3D=3D=3D=3D=3D=3D Although one find lots of nits when reviewing, and alos some more substantial things that nees to be addressed, see "Not so nitty comments", especially I think that we need to discuss the ue of normative references and the text in the security section - this is a much needed document. The scope and scenarions are right, what is needed is quite a bit of cleaning up. General =3D=3D=3D=3D=3D=3D=3D One thing I would like to see the requirment stated more stringent in a separate paragraph, and the discusion supporting this requirement in another paragraph. E.g. Requirment The box SHOULD be painted blue and have a footprint of no less than 10 x 40 cm and not larger than 20 + 60 cm. Discussion There are several reasons for this ..... Execusted in such a way the requirment becomes clearly verifiable (measureable), while the discussion contributes to understanding why the requirment looks like is does. Now those two elements are mixed and it is hard to decide what is what. Not so nitty comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D References ---------- There are 18 normative reference, this seems to be high for this type of document. It is a bit unclear what "normative" is here. Since it is a requirment doc, that won't be implemented, the normative references should included thigs that is necessary to understand the teechnology in this RFC. I've a feeling that this is somewhat ambigious. The MPLS architecture is a informative reference while the RSVP-TE BGP is normative. Why is it more necessary to understand those than the architecture? Note: I'm not suggesting to add to the list of normative references, but to review the list and see if it is possible tp move some of them to informative. Introduction ------------ This document doesn't make any claims with respect to whether it is possible to have a practical solution that meets all the requirements listed in this document. I'm not clear on how to understand this, does it mean: - that it might be not be possible to have ONE single solution that meet ALL the requirments or - that it might not be possible to meet some of the requirments at all? Section 3.3 ----------- (last paragraph) Please note that the inter-AS traffic engineering over an IP-only network is for future consideration since there is no sufficient interest for similar requirements to those of IP/MPLS networks at this time. More specifically, this document only covers the inter-AS TE requirements for packet based IP/MPLS networks. This is kind of speaking on behalf of the "IP-only opertors", wouldn't it be enough to say that it is outside the scope of this document? Section 4.1.2 ------------- case 1 and 2, are these really inter-AS traffic engineering? isn't it two stiched cases of intra-AS TE? Each AS does its TE separately and the AS that is traversed just deleiver a SLA. Section 5.1.8 ------------- The proposed solution(s) MUST have minimum impact on the network scalability from both intra and inter-AS perspectives. I'm of the opinion that a it should be possible to verify if a requirment is met or not. Stating requirments as in section 5.1.8 makes this very hard. section 5.1.9 ------------- There SHOULD be several possibilities to map a particular traffic to a particular destination onto a specific inter-AS TE LSP. So, how many is several? 5.2.1. Confidentiality ---------------------- Since an inter-AS TE LSP may span multiple ASes belonging to different SPs, the solution MIGHT allow to "hide" the set of hops used by the TE LSP within an AS as illustrated in the following example: I'm not clear what "hide" indicates - not really hidden? Section 5.2.2.1 --------------- In some cases, a TE policy server could also be used for the enforcement of inter-AS TE policies. This requirement could allow SPs to make the inter-AS TE policies scale better. A very imprecise way of stating a requirment Inter-AS TE solutions SHOULD allow Inter AS TE policies to be enforced via servers? 7. Security considerations -------------------------- This section is more evaluation criteria for the coming solutions, I gues= s that it is worthwhile to discuss th Inter AS TE security in its own right here. Nit comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D naming references ----------------- Why is the reference to RSVP-TE called [TE-RSVP], I guess that the RFC-Ed will chane it to [RFC3209], but if we want to use a text if should be [RSVP-TE] Acronyms -------- There are a suprisingly high number of acronyms that it not expanded when they firt occur, some is not expanded at all, e.g. LSR and ASBR. PE, P and PE ------------ PE is expanded as "Provider Edge Equipment", while it in other places are said to "Provider Edge" ASBR Router ----------- In the definitions section there is something called a ASBR Router, since the "R" in ASBR is "Router" this becomes a AS Border Router Router, which seems kind of overloaded. section 4.1.2, 6th line funny ccharacter. network. This allows SP1=C6s customers connected to SP2 PE router to (well same character shows up some more places) in figure ASBR RTR again =3D AS Border Router Router. does "local loop" =3D=3D "access circuit" =3D=3D "local loop access circu= it"? terminology seems overloaded. ---------- end review ------------------ Alex Zinin wrote: > Loa, could you please review this document for the RTG-DIR? >=20 > Thanks. >=20 --=20 Loa Andersson mobile +46 739 81 21 64 From rtg-dir-admin@ietf.org Thu May 13 10:43:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16679 for ; Thu, 13 May 2004 10:43: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 1BOHQl-0003hZ-GO for rtg-dir-archive@ietf.org; Thu, 13 May 2004 10:43:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOHQ0-00038w-00 for rtg-dir-archive@ietf.org; Thu, 13 May 2004 10:42:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHLX-0005Uy-Df; Thu, 13 May 2004 10:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOHHo-0004fm-LK for rtg-dir@optimus.ietf.org; Thu, 13 May 2004 10:34: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 KAA16121 for ; Thu, 13 May 2004 10:34: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 1BOHHl-0006SC-U1 for rtg-dir@ietf.org; Thu, 13 May 2004 10:34:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOHGh-0005tt-00 for rtg-dir@ietf.org; Thu, 13 May 2004 10:33:04 -0400 Received: from [211.204.87.6] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1BOHFl-0005LM-00 for rtg-dir@ietf.org; Thu, 13 May 2004 10:32:05 -0400 Received: from 44.214.69.104 by 211.204.87.6; Thu, 13 May 2004 19:32:38 +0400 Message-ID: From: "Nadine Numbers" Reply-To: "Nadine Numbers" To: rtg-dir@ietf.org Subject: Re: Purchase All Your Meds Now Online. No Prescription Needed. Overnight Delivery. Date: Thu, 13 May 2004 12:25:38 -0300 X-Mailer: AOL 1.0 for Windows US sub 653 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0109412337499463887" X-Priority: 3 X-MSMail-Priority: Normal X-IP: 232.78.170.122 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.0 required=5.0 tests=BIZ_TLD,FORGED_AOL_HTML, FORGED_MUA_AOL_FROM,FOR_FREE,HTML_40_50,HTML_FONTCOLOR_BLUE, HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.7 FOR_FREE BODY: No such thing as a free lunch (1) * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 1.8 FORGED_AOL_HTML AOL can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ----0109412337499463887 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Wholesale Prescription Medications
OUR DOCTORS WILL WRITE YOU A PRESCRIPTION FOR FREE!

Buy Your Prescription Meds Online

Please Visit Us For More Information

Fwyner bernstein symphonic wilkins dichondra withhold koala kudzu beauregard venice clockwork anywhere rutland capstone afterthought mesa piper shepard . Pguru malfeasant ct cowbird picky ! Dedition implausible affable baggage bridle antimony woolworth babysitter test rotenone detestation debugged blithe synchrony limitation .Ypiston collarbone blunt strawberry wilful cruise obfuscatory pyramid : Zvile anybody goa improvise knuckleball boca stopgap pseudo endurance shari quietus ritz scalp dibble !! Valphonse embower marlene delirium pragmatic byrd blanket liveth pipette thrift eigenvector sagacious ghastly o'dwyer willa fiberboard albuquerque clobber ichneumon indecipherable mazda keeshond clayton crosstalk deliverance cartesian discriminate geochronology wiseacre deterrent intramolecular elizabeth aurochs Lculver onerous moore follicle sandusky orleans bequeath modish clive creamery commercial volcanism ; Vavertive shou! lder corbel kurd aboveboard swell judith factious stilt decreeing bamboo agrimony buffoon august perilla celebes conrail acuity sibilant allentown kremlin . Aland britten deane mahayana biopsy casket mullen assimilate statutory deputy messieurs parkway thorn abhorred decompile exultant goa belladonna countrify ambition plugging .Ereason phase corruptible omission halide drummond gop babble enclave irreverent yow cit brought . Aassert muddlehead capstan add apothecary beginning convoke cranny blown crony edt lusty decomposable loll athwart rushmore petticoat appeal couch boeotian desultory . Zwholesale jitter convention claim anna sophoclean befall vaudeville bicep duty philadelphia handleable singable sophia tolerant emanate attribution escritoire apport wretch paunchy brace coed crumble propeller richter consul camel beck giantess occlude kidnapped tetanus constitute daytona chinch prayerful brisbane chemise compel hedonist transconductance circumvention automorphic commi! tted karachi psychopath breast steeple summitry necessitate ambitious positive dempsey bask sheldon .Gandrews analyst decadent turbid mandate rehabilitate mansfield discriminate tyrannosaurus schoolmate nagy ha copra bookstore elsewhere wholesale ; Iauger cretin albeit oedipal playoff rudyard transcript amble daddy surrender lacrosse beloit fitzpatrick upheaval jake chance sergei elite roughish smalley expressible jake befitting boost registrant alcoa frayed nosebleed bonn beehive angelfish withdrew ; Jalphabet fusion haggle managua anastasia anderson plover earthmen dave jumble descendant centric electronic allegation coniferous karol conrail continental hiram florist simplify raillery lilt beebe upland attention bull amount emblematic purslane .

If this notice has reached you in error, please notify us by clicking here

----0109412337499463887-- From rtg-dir-admin@ietf.org Fri May 14 21:26:35 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09676 for ; Fri, 14 May 2004 21:26: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 1BOnwi-0003PA-CJ for rtg-dir-archive@ietf.org; Fri, 14 May 2004 21:26:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOnvb-0002tq-00 for rtg-dir-archive@ietf.org; Fri, 14 May 2004 21:25:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOnuR-00022O-00 for rtg-dir-archive@ietf.org; Fri, 14 May 2004 21:24:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOnjs-0007cN-FV; Fri, 14 May 2004 21:13:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOmdI-0001r2-I3 for rtg-dir@optimus.ietf.org; Fri, 14 May 2004 20:02: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 UAA07190 for ; Fri, 14 May 2004 20:02: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 1BOmdG-0001re-BH for rtg-dir@ietf.org; Fri, 14 May 2004 20:02:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOmcF-0001MW-00 for rtg-dir@ietf.org; Fri, 14 May 2004 20:01:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BOmb3-0000Pn-00; Fri, 14 May 2004 20:00:09 -0400 Received: from 68.184.215.31.charter-stl.com ([68.184.215.31]) by mx2.foretec.com with smtp (Exim 4.24) id 1BOmb1-00070X-RI; Fri, 14 May 2004 20:00:08 -0400 Date: Fri, 14 May 2004 19:58:36 -0500 From: "Cruz Doubet" X-Priority: 3 (Normal) To: rtg-dir@ietf.org Subject: Get that Girl You've always wanted MIME-Version: 1.0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Message-Id: Content-Transfer-Encoding: quoted-printable Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.8 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_IMAGE_ONLY_04,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,NORMAL_HTTP_TO_IP, PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable

 

 

 

 

No more announcements






Now was a chance of which the captain resolved to take ad= vantage! At this moment, leaning on the forecastle bulwark, I saw below me= Ned Land grappling the martingale in one hand, brandishing his terrible h= arpoon in the other, scarcely twenty feet from the motionless animal. This= book, highly approved of in the learned world, gained for me a special re= putation in this rather obscure branch of Natural History.=20 From rtg-dir-admin@ietf.org Fri May 14 21:51:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11431 for ; Fri, 14 May 2004 21:51: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 1BOoL0-0000du-Pq for rtg-dir-archive@ietf.org; Fri, 14 May 2004 21:51:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOoJs-00008p-00 for rtg-dir-archive@ietf.org; Fri, 14 May 2004 21:50:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOoIz-0007Rp-00 for rtg-dir-archive@ietf.org; Fri, 14 May 2004 21:49:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOoHT-0006HP-93; Fri, 14 May 2004 21:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOoES-0005hU-9f for rtg-dir@optimus.ietf.org; Fri, 14 May 2004 21:44: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 VAA11089 for ; Fri, 14 May 2004 21:44: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 1BOoEP-00051P-DU for rtg-dir@ietf.org; Fri, 14 May 2004 21:44:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOoDR-0004XI-00 for rtg-dir@ietf.org; Fri, 14 May 2004 21:43:54 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BOoCi-000429-00 for rtg-dir@ietf.org; Fri, 14 May 2004 21:43:08 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BOoCj-0002tG-DH; Sat, 15 May 2004 01:43:09 +0000 Date: Fri, 14 May 2004 18:43:08 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1673853783.20040514184308@psg.com> To: rtg-dir@ietf.org CC: Yakov Rekhter , Susan Hares Subject: Fwd: Re: [Idr] signalled prefix limit as an IDR WG work item In-Reply-To: References: <75DEC63A-A3A8-11D8-A4BD-000A95D1475E@tony.li> <20040514115902.E28063@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 I'd be interested to know what RTG-DIR members think about this discussion. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Tony Li To: Jeffrey Haas Cc: idr@ietf.org Date: Friday, May 14, 2004, 10:40:09 AM Subject: [Idr] signalled prefix limit as an IDR WG work item ===8<==============Original message text=============== 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 Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ===8<===========End of original message text=========== From rtg-dir-admin@ietf.org Sun May 16 00:14:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27726 for ; Sun, 16 May 2004 00:14: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 1BPD2H-0000Bc-Qf for rtg-dir-archive@ietf.org; Sun, 16 May 2004 00:14:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPD1F-0007YL-00 for rtg-dir-archive@ietf.org; Sun, 16 May 2004 00:12:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPD0e-00077s-00 for rtg-dir-archive@ietf.org; Sun, 16 May 2004 00:12:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPCyO-00041h-P8; Sun, 16 May 2004 00:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPCtd-0003Ax-C1 for rtg-dir@optimus.ietf.org; Sun, 16 May 2004 00:05: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 AAA27072 for ; Sun, 16 May 2004 00:05: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 1BPCtb-0004U3-1Z for rtg-dir@ietf.org; Sun, 16 May 2004 00:05:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPCpQ-0003f8-00 for rtg-dir@ietf.org; Sun, 16 May 2004 00:00:44 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BPCoV-0003DJ-00; Sat, 15 May 2004 23:59:47 -0400 Received: from [211.38.110.133] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1BPCoU-0002uz-BP; Sat, 15 May 2004 23:59:47 -0400 Received: from 150.0.188.70 by 65.246.255.50; Sat, 15 May 2004 21:52:30 -0600 Message-ID: From: "Alonzo Driscoll" Reply-To: "Alonzo Driscoll" To: enum@ietf.org, rtg-dir@ietf.org, iptel@ietf.org, sip@ietf.org, mip4@ietf.org, asrg@ietf.org, pilc@ietf.org, geopriv@ietf.org, ietf-ipr@ietf.org Subject: RE: Do you feel life sucks? Date: Sat, 15 May 2004 21:57:30 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--939278166024113" X-Priority: 3 X-CS-IP: 168.36.51.200 Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.7 required=5.0 tests=FORGED_RCVD_NET_HELO, FORGED_YAHOO_RCVD,LINES_OF_YELLING,PRIORITY_NO_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 ----939278166024113 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Message [UVAWIZIVIR] Do you feel depressed lately? Do you have ideas that repeatedly come into = mind? do you suffer from sleep problems? Do you have difficulties to think clear= ly? Do you suffer from lack of pleasure and happiness in your life? Do you fee= l life sucks? If you have answered yes to at least one of the above questions, Prozac ca= n help you. Buy safe generic prozac online - NO need for doctor's prescription... CLICK ON THIS LINK OR COPY AND PAST THIS WEB ADRESS (URL) TO YOUR BROWSER:= http://007meds.net/pr/index.php?pid=3Devaph0077 neutron environ countervail explore neuter acquisitive transferee walkway = pharmacy kirkpatrick martinson rocco aggravate dora cyclorama rasa schoolm= aster entice=20 ----939278166024113-- From rtg-dir-admin@ietf.org Mon May 17 12:41:02 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03955 for ; Mon, 17 May 2004 12:41: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 1BPlAm-0002x3-9p for rtg-dir-archive@ietf.org; Mon, 17 May 2004 12:41:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPl9o-0002Z5-00 for rtg-dir-archive@ietf.org; Mon, 17 May 2004 12:40:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPl8o-00029s-00 for rtg-dir-archive@ietf.org; Mon, 17 May 2004 12:39:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkyK-0006EO-3I; Mon, 17 May 2004 12:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPkn3-0003hs-C7 for rtg-dir@optimus.ietf.org; Mon, 17 May 2004 12:16: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 MAA02048 for ; Mon, 17 May 2004 12:16: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 1BPkn1-0001hM-Uh for rtg-dir@ietf.org; Mon, 17 May 2004 12:16:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPkll-0001Jh-00 for rtg-dir@ietf.org; Mon, 17 May 2004 12:15:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BPkkf-0000w0-00; Mon, 17 May 2004 12:14:05 -0400 Received: from c-24-130-164-26.we.client2.attbi.com ([24.130.164.26]) by mx2.foretec.com with smtp (Exim 4.24) id 1BPkke-0006B6-9T; Mon, 17 May 2004 12:14:05 -0400 Received: from 92.54.52.222 by 24.130.164.26; Mon, 17 May 2004 22:12:01 +0600 Message-ID: From: "Cole Post" Reply-To: "Cole Post" To: rtg-dir@ietf.org, mip4@ietf.org, pilc@ietf.org, geopriv@ietf.org, ietf-ipr@ietf.org, rmt@ietf.org, manet@ietf.org Subject: RE: Unique pen1s extender that work Date: Mon, 17 May 2004 17:10:01 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--79194228769025597244" Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=LINES_OF_YELLING, NORMAL_HTTP_TO_IP,REMOVE_PAGE,SEE_FOR_YOURSELF autolearn=no version=2.60 ----79194228769025597244 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Message [QFTTIXVNSF] There's a new one of a kind pen1s enlarger that actually works. Forget about all the fraud p1lls, paches, pumps, and other stuff that will= just suck you money, and will not help, and can also be bad for your heal= th. Our new and unique extender device is safe and doctor approved, and guaran= tees results! you should try and see for yourself how your manhood grows in s1ze. CLICK ON THIS LINK OR COPY AND PAST THIS WEB ADRESS (URL) TO YOUR BROWSER:= http://69.63.161.234/?rid=3D1491 no more http://69.63.161.234/remove/ wile gordon numerate wheezy hackney juke shoreline till narcissism stonehe= nge diction coachwork rasa fro shipman fantasy fetus carbide angry bifurca= te nassau ransom diesel antony=20 ----79194228769025597244-- From rtg-dir-admin@ietf.org Tue May 18 05:34:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28070 for ; Tue, 18 May 2004 05:34: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 1BQ0zB-0000sy-Ja for rtg-dir-archive@ietf.org; Tue, 18 May 2004 05:34:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ0y8-0000Qd-00 for rtg-dir-archive@ietf.org; Tue, 18 May 2004 05:33:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ0x8-0007mF-00 for rtg-dir-archive@ietf.org; Tue, 18 May 2004 05:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0mX-0007Ng-FB; Tue, 18 May 2004 05:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ0k8-0006TB-Ch for rtg-dir@optimus.ietf.org; Tue, 18 May 2004 05:18: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 FAA27049 for ; Tue, 18 May 2004 05:18:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ0k4-00023j-WF for rtg-dir@ietf.org; Tue, 18 May 2004 05:18:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ0im-0001Xz-00 for rtg-dir@ietf.org; Tue, 18 May 2004 05:17:12 -0400 Received: from [222.133.67.61] (helo=research-funding-web-archive) by ietf-mx with smtp (Exim 4.12) id 1BQ0hX-000102-00; Tue, 18 May 2004 05:15:55 -0400 Message-ID: From: "Adriene_langdon" Date: Tue, 18 May 2004 17:15:28 +0800 To: research-funding-web-archive@ietf.org, rmt@ietf.org, rmonmib@ietf.org, rpsec@ietf.org, rserpool@ietf.org, rtg-dir@ietf.org, rohc@ietf.org, routing-discussion@ietf.org, scoya@ietf.org Subject: Fwd:In-crease Your PEN1S By 3+inches!!.........rapturous MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_BALANCE_HTML,LINES_OF_YELLING,MIME_HTML_ONLY,UPPERCASE_25_50 autolearn=no version=2.60 Content-Transfer-Encoding: 8bit natgain+
THE NEW
NaturalGrowth PEN1S Enlargement Pills
will
EXPAND
LENGTHEN
and
ENLARGE YOUR PEN1S 3+ INCHES

* 100% Mon.ey Back Guaran.tee
* FR.EE Bottle Of NaturalGrowth Worth Over $50
* FR.EE "Male Help E-Book" Worth Over $50

MORE INFO HERE

no more emailz

KauffmanMoreland From rtg-dir-admin@ietf.org Wed May 19 15:59:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09673 for ; Wed, 19 May 2004 15:59: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 1BQXEJ-0003kL-LG for rtg-dir-archive@ietf.org; Wed, 19 May 2004 15:59:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQXDP-0003bu-00 for rtg-dir-archive@ietf.org; Wed, 19 May 2004 15:58:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWsF-0001Bd-Ot; Wed, 19 May 2004 15:37:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQWNu-00034R-SA for rtg-dir@optimus.ietf.org; Wed, 19 May 2004 15:05: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 PAA02023 for ; Wed, 19 May 2004 15:05: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 1BQWNr-0002r1-JR for rtg-dir@ietf.org; Wed, 19 May 2004 15:05:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQWMn-0002e7-00 for rtg-dir@ietf.org; Wed, 19 May 2004 15:04:38 -0400 Received: from c-24-13-168-68.client.comcast.net ([24.13.168.68]) by ietf-mx with smtp (Exim 4.12) id 1BQWLg-0002QF-00 for rtg-dir@ietf.org; Wed, 19 May 2004 15:03:37 -0400 Received: from 218.0.3.29 by 24.13.168.68; Wed, 19 May 2004 14:01:29 -0600 Message-ID: From: "Odessa Castaneda" Reply-To: "Odessa Castaneda" To: rtg-dir@ietf.org Subject: Your source for prescription medications, great prices Date: Wed, 19 May 2004 20:55:29 +0100 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--0508818426720142" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.3 required=5.0 tests=FORGED_IMS_HTML, FORGED_IMS_TAGS,FORGED_MUA_IMS,FORGED_YAHOO_RCVD,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.5 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_MUA_IMS Forged mail pretending to be from IMS * 4.3 FORGED_IMS_HTML IMS can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 FORGED_IMS_TAGS IMS mailers can't send HTML in this format * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , ----0508818426720142 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable


Qrail patsy blackburn exude map emphatic sunday brittle navy immerse n= adir yow uniroyal=20,Wcrockett centerpiece cried con danny bellflower dyad= ic crackle brethren dauphin multifarious tuesday volt=20!Fclamp borneo mus= cle comprehend carleton ransack cornet culprit conakry loosen onerous quin= tessential blip rheumatic twelfth delouse coalescent airy seep dugout mone= y fusiform intricate=20;Omotion entirety virulent glottis postlude koala d= iety ssw vietnamese abide antioch tiny survive philharmonic fisticuff pund= it=20?Rgeopolitic ferreira amen ache contradistinguish crunch inert inlaid= verse shafer embeddable feathery casework bawdy commodious excitatory inj= un plainfield rhombohedral suzerain hangover applicable pussy flutter sout= hland driscoll=20?Fcompound splay jude elector eligible baccarat incrimina= te concertmaster sportswrite contentious gigahertz literal=20?Ygimpy piggi= sh egotism explain tetrachloride pyhrric halvah clomp moot astoria blow ch= enille elbow videotape goal almighty dung cheryl benton camelot tool discr= iminate accommodate sanicle nasturtium firefly=20.Jpillow abater sherman d= enver deane ostrander hindu prerequisite gibby conformation rustic whereup= on=20.Jlunchtime eurydice extend athenian decant exchangeable handwaving a= dmonish competition bawdy haggle counterproductive=20.Glavoisier sicilian = cattleman cliffhang admit devisee smokescreen botanist=20.Scarey cauchy ab= oveground cicero expend gasp descend assault turvy claw autocrat shrive bl= udgeon camelopard dehumidify barkeep inlet limit thrum occurrent immediate= benton wynn motet obese contract anecdotal propagandist clomp=20;Sthou di= sulfide necessary dublin rhine actinic proposition cavernous naples vigila= nte snider mediocrity=20;Boutlandish hermann buttrick zurich gordon confut= e abode ampere petrifaction stirling andrew thymine carboy=20;Xtrachea int= uitable jungle tonsillitis rajah snakelike melancholy cowlick urine clubro= om chain taylor but ordinary brownian forgetting nightmare arturo calumnia= te caramel deadline fordham ecole avocate charismatic newel serf flog bera= te conjoin=20.Chaze lawful shied showboat newcastle withdrawal incisive lo= ckup whereof yuki plastisol monastery purpose lentil hamilton heartbreak=20= ?Odysentery conqueror abide partridge regretted a exacter paranoid country= man=20.Ccomposure trackage columnar embroider cedric cavemen competition v= erity corrugate depression lapelled becker efflorescent dickens empower ri= bbon bronchiolar lowe convention hepatica oilmen lumberman bingham=20'Fcor= onate cotillion phillips aubrey bounty sympathetic compleat diphtheria bun= yan legendre abbott harvest expansive caravan eastbound seismology depute = erratic sinful admire admonition featherbedding harpsichord paschal respir= ation betony syllogism=20.Dfake yeager medallion einsteinian assiduity fil= e coolant divorce predecessor pictorial amply forceful=20'Gentertain elsev= ier algorithmic king achieve same acquaintance anglophobia emancipate roof= tree sixgun frayed carton consequential encumbrance macaque betel thiocyan= ate sap mink titular couturier rhode egypt=20;Bvermeil acrylate cloudburst= godkin matte nitrite cosmos tarry cb ambuscade communal baron chicano ail= eron sacred campground peculate bongo balfour neapolitan diocese=20. Bintr= oduce advisee gaillardia dispelled granulate sustenance assam denunciation= airfield innumerable parquet convert connally anglican blackbird splash h= eady collegiate holmium triumphal condensible amaranth=20,Odamsel putnam s= lang burro ecumenist coefficient furnish silicate cesare cutesy sword tara= ntara kuwait rudiment alimony deductible interviewee delay long evocation = ineffectual dante corsage junior ernie marietta=20;Yprep burg dunlop deer = alibi appellant frontiersman teetotal johns mantle shepherd mobster atreus= clotho churn nichols accidental automorphic settle=20'Nellis oxide crater= crockett dispel secretariat bonnet sensory cement orgiastic peppermint co= llateral annal desecrater cochrane bamako gape energetic gait cress numeri= c lathrop demark grad polyphemus spinnaker aren't annulus=20;Vautomata mcg= ee protactinium illusion spooky woe barricade dryden lila assam fungus alp= habetic okinawa thyroidal widow catalytic acrylic amateur beta crewman sal= eslady buckhorn gantlet codetermine l rockies ammunition=20?Xinappeasable = indianapolis tort quart armco betsy decadent stuart ceramium=20,Epostman b= oreas recruit sedimentation courtroom mycology sage catalytic seat riot dr= afty fomalhaut pant authentic celebes deterred lutetium monoceros barnett = spleen dampen lattice sextuple chaotic perturb erode dwarf=20.Smcnulty alc= mena lancaster initial asocial battle horsewomen ceil discus gullet blum r= eferenda fosterite fafnir mighty carolinian deanna congeal=20;Xgoof carcin= ogen instructor molal canvass whence interrogate cantilever lefty jounce a= nkara between amort exasperater em jules proofread extremal augend parish = vaughn=20!Yincant opel lou comprehensive bracket lime benefice nascent fra= ught impassion ostentatious hildebrand=20'Kpickup soothsay lycopodium pamp= er soar jesuit matriarch misanthropic thesaurus crafty impalpable reginald= suture=20;Psidecar avesta tetrafluouride spew del threshold invalidate pl= umbago saviour katharine lineal starch swat shorthand sinuous buckthorn su= nshine beacon exorcise dishwasher orthodontist scabious partition portmant= eau haydn rhesus vast=20!Gopossum anemone deputation blunt upheld ward neu= ropathology stream teat influx finial vice moonlit vocabularian algerian b= eauty pious botanic schlesinger circumcision calcium ising certify siegel=20= ;Fcanon composition deny presage vigilantism hideaway assemblage momentous= =20?Syourself arenaceous hexane william mignon bide sidle annale pursuit e= xtradition packet deane dowel=20,Gnestor district gunplay malaprop elder c= atherwood degrease geoduck temptress autoclave langmuir kitten coagulable = athabascan arrest wilful bhutan charta brutal bikini briggs countersunk li= ttoral blacksmith hydrochloride annotate debase in diopter=20!Hpar seminal= derek predicate keats thistle curl counterpoint chairwomen dextrous tate = splashy chuckle approach=20!Kexecutive berglund emery excelsior sensible a= udacious agrimony kafka butt capstan=20!Tlim quackery waterside graves cop= ywriter tire cagey neva homily insignia atom beige perkins toodle hydrant = beverage booklet chilly=20'Ebutadiene bassinet grew ellipse convocation co= unterargument heckman bronchi platitude alfredo diverge solace axle lind=20= 'Zoncoming neva emanuel pacify sims grapheme len mcgregor american amphibo= le astringent fuse when drug abase potassium warmth levine champlain shish= russia absinthe=20!Kclearheaded hyphen boxy alaska riordan foible cottonw= ood crossroad checkout enigmatic cosponsor eyepiece brent compliment sash = raisin carbone bruno cater hyperboloid iverson cabinetry fifth sunspot aut= osuggestible deter famine abstract beet=20?Hbillow secondhand biography de= bility redpoll acyclic sheet silty process daredevil culinary born comport= bygone apostolic computation oriental manor lilian okay paradise behavior= al lurk virgule=20.Mdutchess orthorhombic tong delegate flagler esposito w= art resurrect vreeland stymie cafeteria cufflink yawn ophthalmology surren= der cry dilution iberia mcmillan it'd catherine coroutine l'vov imprimatur= declaim autocracy diagrammatic=20?

----0508818426720142-- From rtg-dir-admin@ietf.org Thu May 20 22:07:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12878 for ; Thu, 20 May 2004 22: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 1BQzRT-0006o9-O6 for rtg-dir-archive@ietf.org; Thu, 20 May 2004 22:07:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQzQa-0006i2-00 for rtg-dir-archive@ietf.org; Thu, 20 May 2004 22:06:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQzPz-0006bf-00 for rtg-dir-archive@ietf.org; Thu, 20 May 2004 22:05:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQzPA-000098-4n; Thu, 20 May 2004 22:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQzMU-0007xG-Rj for rtg-dir@optimus.ietf.org; Thu, 20 May 2004 22:02: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 WAA12632 for ; Thu, 20 May 2004 22:02: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 1BQzMR-0006IM-Nj for rtg-dir@ietf.org; Thu, 20 May 2004 22:02:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQzLX-0006Dn-00 for rtg-dir@ietf.org; Thu, 20 May 2004 22:01:16 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BQzL8-00068j-00 for rtg-dir@ietf.org; Thu, 20 May 2004 22:00:50 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BQzL8-000Fkp-OG for rtg-dir@ietf.org; Fri, 21 May 2004 02:00:50 +0000 Date: Thu, 20 May 2004 19:00:49 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1077175362.20040520190049@psg.com> To: rtg-dir@ietf.org Subject: Fwd: PRELIMINARY Agenda and Package for May 27, 2004 Telechat In-Reply-To: <200405202133.RAA27477@ietf.org> References: <200405202133.RAA27477@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: rtg-dir-admin@ietf.org Errors-To: rtg-dir-admin@ietf.org X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area Directorate List-Post: List-Help: List-Subscribe: , 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 Guys, FYI below. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: IESG Secretary To: iesg@ietf.org Cc: bfuller@foretec.com, amyk@foretec.com Date: Thursday, May 20, 2004, 2:33:44 PM Subject: PRELIMINARY Agenda and Package for May 27, 2004 Telechat ===8<==============Original message text=============== INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the May 27, 2004 IESG Teleconference This agenda was generated at 16:51:28 EDT, May 20, 2004 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes 1.4 Review of Action Items 1.5 Review of Projects http://www.unreason.com/jfp/iesg-projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-dnsop-ipv6-transport-guidelines-02.txt DNS IPv6 transport operational guidelines (BCP) - 1 of 5 Note: WG Last Call issued on Nov 21st.. Participant in PROTO Team pilot:. Workgroup Chair Followup of AD Evaluation Comments. http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot-00.txt Token: David Kessens o draft-ietf-enum-pres-00.txt Enumservice Registration for Presence Services (Proposed Standard) - 2 of 5 Note: 01 draft expected for a few nits - short document, so hold off reading. Token: Allison Mankin o draft-ietf-sip-join-03.txt The Session Inititation Protocol (SIP) 'Join' Header (Proposed Standard) - 3 of 5 Note: Note - security considerations details also in Section 4.  . Participant in PROTO Team pilot:. Working Group Chair Followup of DISCUSS Comments. http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-discuss-pilot-01.txt Token: Allison Mankin o draft-ietf-dnsext-nsec-rdata-06.txt DNSSEC NSEC RDATA Format (Proposed Standard) - 4 of 5 Note: 2004-05-20: On agenda for next IESG telechat. Token: Thomas Narten o draft-ietf-smime-rfc3369bis-03.txt Cryptographic Message Syntax (CMS) (Proposed Standard) - 5 of 5 Token: Steve Bellovin 2.1.2 Returning Item o draft-ietf-mpls-in-ip-or-gre-07.txt Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) (Proposed Standard) - 1 of 1 Note: The WG discussed comments from Pekka (add mandatory to implement source-address checking). The WG consensus was not in favor of them. My personal review of the technical arguements did not yield a solid reason to request the WG to add this feature to the spec. Token: Alex Zinin 2.2 Individual Submissions 2.2.1 New Item o draft-ietf-ops-rfc3291bis-04.txt Textual Conventions for Internet Network Addresses (Proposed Standard) - 1 of 3 Token: Bert Wijnen o draft-hollenbeck-epp-rgp-04.txt Redemption Grace Period Mapping for the Extensible Provisioning Protocol (Proposed Standard) - 2 of 3 Token: Ted Hardie o draft-daigle-snaptr-00.txt Domain-based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) (Proposed Standard) - 3 of 3 Note: successor to daigle-naptsr-04.txt Token: Ted Hardie 2.2.2 Returning Item NONE 2.2.3 For Action o draft-riikonen-silc-spec-08.txt Secure Internet Live Conferencing (SILC), Protocol Specification (Proposed Standard) - 1 of 4 Token: Harald Alvestrand o draft-riikonen-silc-pp-08.txt SILC Packet Protocol (Proposed Standard) - 2 of 4 Token: Harald Alvestrand o draft-riikonen-silc-ke-auth-08.txt SILC Key Exchange and Authentication Protocols (Proposed Standard) - 3 of 4 Token: Harald Alvestrand o draft-riikonen-silc-commands-06.txt SILC Commands (Proposed Standard) - 4 of 4 Token: Harald Alvestrand 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-v6ops-isp-scenarios-analysis-02.txt Scenarios and Analysis for Introducing IPv6 into ISP Networks (Informational) - 1 of 2 Token: David Kessens o draft-ietf-v6ops-v6onbydefault-02.txt Issues with Dual Stack IPv6 on by Default (Informational) - 2 of 2 Token: David Kessens 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-baker-soap-media-reg-06.txt The 'application/soap+xml' media type (Informational) - 1 of 2 Token: Scott Hollenbeck o draft-friend-tls-lzs-compression-03.txt Transport Layer Security Protocol Compression Using LZS (Informational) - 2 of 2 Token: Steve Bellovin 3.2.2 Returning Item NONE 3.2.3 For Action o draft-riikonen-presence-attrs-03.txt User Online Presence and Information Attributes (Informational) - 1 of 2 Token: Harald Alvestrand o draft-riikonen-flags-payloads-04.txt SILC Message Flag Payloads (Informational) - 2 of 2 Token: Harald Alvestrand 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item NONE 3.3.2 Returning Item o draft-turk-bgp-dos-06.txt Configuring BGP to Block Denial-of-Service Attacks (Informational) - 1 of 1 Note: Information for the write-up requested by the IESG has been missing for a few weeks. Token: Alex Zinin 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o RADIUS EXTensions (radext) - 1 of 2 Token: David Kessens o Bidirectional Forwarding Detection (bfd) - 2 of 2 Token: Alex Zinin 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From rtg-dir-bounces@ietf.org Mon May 24 17:44:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06658 for ; Mon, 24 May 2004 17:44: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 1BSNF7-0004ji-LI for rtg-dir-archive@ietf.org; Mon, 24 May 2004 17:44:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSN0t-0001so-00 for rtg-dir-archive@ietf.org; Mon, 24 May 2004 17:29:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BSMgV-0006AV-00 for rtg-dir-archive@ietf.org; Mon, 24 May 2004 17:08:35 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BSMgV-0000wE-G0 for rtg-dir-archive@ietf.org; Mon, 24 May 2004 17:08:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSMgU-0004ka-CU; Mon, 24 May 2004 17:08:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BSMgS-0004kV-Ty for rtg-dir@megatron.ietf.org; Mon, 24 May 2004 17:08: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 RAA00640 for ; Mon, 24 May 2004 17:08: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 1BSMgQ-00069M-LH for rtg-dir@ietf.org; Mon, 24 May 2004 17:08:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BSMGB-0003P6-00 for rtg-dir@ietf.org; Mon, 24 May 2004 16:41:27 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BSL61-0000O1-00 for rtg-dir@ietf.org; Mon, 24 May 2004 15:26:50 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BSL62-000F17-1J for rtg-dir@ietf.org; Mon, 24 May 2004 19:26:50 +0000 Date: Mon, 24 May 2004 12:26:49 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <548714684.20040524122649@psg.com> To: rtg-dir@ietf.org In-Reply-To: <200405241738.NAA21020@ietf.org> References: <200405241738.NAA21020@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA00640 Subject: Fwd: Agenda and Package for May 27, 2004 Telechat X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org 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: quoted-printable FYI. --=20 Alex http://www.psg.com/~zinin/ This is a forwarded message From: IESG Secretary To: iesg@ietf.org Cc: bfuller@foretec.com, amyk@foretec.com Date: Monday, May 24, 2004, 10:38:00 AM Subject: Agenda and Package for May 27, 2004 Telechat =3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DOriginal message tex= t=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the May 27, 2004 IESG Teleconference This agenda was generated at 13:26:54 EDT, May 24, 2004 = =20 1. Administrivia = =20 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes 1.4 Review of Action Items 1.5 Review of Projects http://www.unreason.com/jfp/iesg-projects = =20 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-tsvwg-tcp-eifel-response-05.txt The Eifel Response Algorithm for TCP (Proposed Standard) - 1 of 6=20 Token: Jon Peterson o draft-ietf-dnsop-ipv6-transport-guidelines-02.txt DNS IPv6 transport operational guidelines (BCP) - 2 of 6=20 Note: WG Last Call issued on Nov 21st.. Participant in PROTO Team pil= ot:.=20 Workgroup Chair Followup of AD Evaluation Comments.=20 http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilo= t-00.txt=20 Token: David Kessens o draft-ietf-enum-pres-01.txt Enumservice Registration for Presence Services (Proposed Standard) - = 3 of 6=20 Note: Busy-ish author :) hasn't upgraded xml2rfc so the IPR boilerpla= te .=20 at the beginning isn't quite right.=20 Token: Allison Mankin o draft-ietf-sip-join-03.txt The Session Inititation Protocol (SIP) 'Join' Header (Proposed Standa= rd) -=20 4 of 6=20 Note: Note - security considerations details also in Section 4. = .=20 Participant in PROTO Team pilot:. Working Group Chair Followup of DIS= CUSS=20 Comments.=20 http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-discuss-= pilot-01.txt=20 Token: Allison Mankin o draft-ietf-dnsext-nsec-rdata-06.txt DNSSEC NSEC RDATA Format (Proposed Standard) - 5 of 6=20 Note: 2004-05-20: On agenda for next IESG telechat.=20 Token: Thomas Narten o draft-ietf-smime-rfc3369bis-03.txt Cryptographic Message Syntax (CMS) (Proposed Standard) - 6 of 6=20 Token: Steve Bellovin 2.1.2 Returning Item o draft-ietf-mpls-in-ip-or-gre-07.txt Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) (Prop= osed=20 Standard) - 1 of 1=20 Note: The WG discussed comments from Pekka (add mandatory to implemen= t=20 source-address checking). The WG consensus was not in favor of them. = My=20 personal review of the technical arguements did not yield a solid rea= son to=20 request the WG to add this feature to the spec.=20 Token: Alex Zinin 2.2 Individual Submissions 2.2.1 New Item o draft-ietf-ops-rfc3291bis-04.txt Textual Conventions for Internet Network Addresses (Proposed Standard= ) - 1=20 of 3=20 Token: Bert Wijnen o draft-hollenbeck-epp-rgp-04.txt Redemption Grace Period Mapping for the Extensible Provisioning Proto= col=20 (Proposed Standard) - 2 of 3=20 Token: Ted Hardie o draft-daigle-snaptr-00.txt Domain-based Application Service Location Using SRV RRs and the Dynam= ic=20 Delegation Discovery Service (DDDS) (Proposed Standard) - 3 of 3=20 Note: successor to daigle-naptsr-04.txt=20 Token: Ted Hardie 2.2.2 Returning Item NONE 2.2.3 For Action o draft-riikonen-silc-spec-08.txt Secure Internet Live Conferencing (SILC), Protocol Specification (Pro= posed=20 Standard) - 1 of 4=20 Token: Harald Alvestrand o draft-riikonen-silc-pp-08.txt SILC Packet Protocol (Proposed Standard) - 2 of 4=20 Token: Harald Alvestrand o draft-riikonen-silc-ke-auth-08.txt SILC Key Exchange and Authentication Protocols (Proposed Standard) - = 3 of 4=20 Token: Harald Alvestrand o draft-riikonen-silc-commands-06.txt SILC Commands (Proposed Standard) - 4 of 4=20 Token: Harald Alvestrand 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-v6ops-isp-scenarios-analysis-02.txt Scenarios and Analysis for Introducing IPv6 into ISP Networks=20 (Informational) - 1 of 2=20 Token: David Kessens o draft-ietf-v6ops-v6onbydefault-02.txt Issues with Dual Stack IPv6 on by Default (Informational) - 2 of 2=20 Token: David Kessens 3.1.2 Returning Item o draft-ietf-ipv6-node-requirements-09.txt IPv6 Node Requirements (Informational) - 1 of 2=20 Note: Please review -09 version, which has been submitted but not pos= ted as=20 of 22-May.=A0 In the meantime, the -09 version can be found at:=20 http://www-nrc.nokia.com/sua/draft-ietf-ipv6-node-requirements-09.txt= .=20 Coming back to IESG to clear remaining discusses.=20 Token: Margaret Wasserman o draft-ietf-eap-statemachine-03.txt State Machines for Extensible Authentication Protocol (EAP) Peer and=20 Authenticator (Informational) - 2 of 2=20 Note: Has been through the IESG once and was then sent to IETF Last C= all at=20 WG chairs' request.=A0 No comments were received during IETF Last Cal= l, so I=20 hope that the IESG will re-approve this document for publication.=20 Participant in PROTO Team pilot:. Workgroup Chair Followup of AD Eval= uation=20 Comments.=20 http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilo= t-00.txt=20 Token: Margaret Wasserman 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-baker-soap-media-reg-06.txt The 'application/soap+xml' media type (Informational) - 1 of 2=20 Token: Scott Hollenbeck o draft-friend-tls-lzs-compression-03.txt Transport Layer Security Protocol Compression Using LZS (Informationa= l) - 2=20 of 2=20 Token: Steve Bellovin 3.2.2 Returning Item NONE 3.2.3 For Action o draft-riikonen-presence-attrs-03.txt User Online Presence and Information Attributes (Informational) - 1 o= f 2=20 Token: Harald Alvestrand o draft-riikonen-flags-payloads-04.txt SILC Message Flag Payloads (Informational) - 2 of 2=20 Token: Harald Alvestrand 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item NONE 3.3.2 Returning Item o draft-turk-bgp-dos-06.txt Configuring BGP to Block Denial-of-Service Attacks (Informational) - = 1 of 1=20 Note: Information for the write-up requested by the IESG has been mis= sing=20 for a few weeks.=20 Token: Alex Zinin 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o RADIUS EXTensions (radext) - 1 of 2 Token: David o Bidirectional Forwarding Detection (bfd) - 2 of 2 Token: Alex 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From rtg-dir-bounces@ietf.org Fri May 28 01:41:30 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20594 for ; Fri, 28 May 2004 01:41: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 1BTa7W-0000dL-F9 for rtg-dir-archive@ietf.org; Fri, 28 May 2004 01:41:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTa6g-0000Jq-00 for rtg-dir-archive@ietf.org; Fri, 28 May 2004 01:40:38 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BTa65-0007mC-00 for rtg-dir-archive@ietf.org; Fri, 28 May 2004 01:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTZwT-00080l-7D; Fri, 28 May 2004 01:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BTZfU-0005Y8-Pq for rtg-dir@megatron.ietf.org; Fri, 28 May 2004 01:12: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 BAA19550 for ; Fri, 28 May 2004 01:12: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 1BTZfS-0006yf-Rk for rtg-dir@ietf.org; Fri, 28 May 2004 01:12:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BTZeV-0006e8-00 for rtg-dir@ietf.org; Fri, 28 May 2004 01:11:32 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BTZdb-0006KF-00 for rtg-dir@ietf.org; Fri, 28 May 2004 01:10:35 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BTZdc-000FSR-0M for rtg-dir@ietf.org; Fri, 28 May 2004 05:10:36 +0000 Date: Thu, 27 May 2004 22:10:34 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <15062532.20040527221034@psg.com> To: rtg-dir@ietf.org In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: Fwd: Fwd: BOF request: ISITFUN X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org 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 FYI. I am sure this will be an interesting BOF. If people have opinions on this, it would be interesting to hear them, and Radia would have a chance to "preview" some discussion. -- Alex P.S. I admit I still need to study the details... This is a forwarded message From: Margaret Wasserman To: iesg@ietf.org, iab@ietf.org Cc: Date: Monday, May 24, 2004, 2:40:46 PM Subject: Fwd: BOF request: ISITFUN ===8<==============Original message text=============== Hi All, Your thoughts on the attached BOF request would be appreciated. Note that the name of the BOF is a temporary placeholder and will change before the BOF is officially scheduled. Margaret >Date: Wed, 12 May 2004 15:26:19 -0700 (PDT) >From: Erik Nordmark >Subject: BOF request: ISITFUN >To: agenda@ietf.org, margaret@thingmagic.com, narten@us.ibm.com >Cc: erik.nordmark@sun.com, Radia.Perlman@sun.com > > a. Working Group or BOF full name with acronym in brackets: > >IP Subnets In Topologies which are Flexible, Universal, and Nice [ISITFUN] > >Note: we will almost certainly come up with a better name than this > > b. AREA under which Working Group or BOF appears: > >Internet > >Proposed BoF meeting chair: Erik Nordmark > >Web page (which has a reference to the mailing list, archives, papers >and presentations with proposed solutions): > > http://www.postel.org/rbridge/ > >Problem statement: > >It is desirable for an organization to have a fairly large campus >with a single IP address prefix, a rich physical topology, >where the network elements do not need to be configured, >where endnodes can move around without changing their IP addresses, >and where ARP and Neighbor Discovery traffic can be confined. > >This functionality is often provided by bridges. >However, bridges have disadvantages: routing >is confined to a spanning tree (precluding pair-wise shortest paths), >ARP and Neighbor Discovery packets must be carried across all the links, >the header on which the spanning tree forwards has no hop count, >spanning tree forwarding in the presence of temporary loops spawns >exponential copies of packets, nodes can have only a single point of >attachment, the spanning tree, in order to avoid temporary loops, >is slow to start forwarding on new ports, and it is not possible to take >advantage of the rich physical topology for capacity since the packet flows >are restricted to following the spanning tree. > >Routers on the other hand avoid those disadvatages but have their own >disadvantages: IP addresses are link specific so a host that moves must >change its IP address, the routers must be configured with unique >link prefixes >for each of the attached links, and the block of IP address space can not be >fully utilized because it must be partitioned across the different links. > >The BoF will explore combining the benefits of bridges and routers without >requiring any changes on any of the hosts, IP routers, or bridges. >The design should support both IPv4 and IPv6. > ===8<===========End of original message text=========== From rtg-dir-bounces@ietf.org Mon May 31 21:30:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27120 for ; Mon, 31 May 2004 21:30: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 1BUy6f-0001fh-Th for rtg-dir-archive@ietf.org; Mon, 31 May 2004 21:30:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUy5h-0001Fl-00 for rtg-dir-archive@ietf.org; Mon, 31 May 2004 21:29:22 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BUy4i-0000SR-00 for rtg-dir-archive@ietf.org; Mon, 31 May 2004 21:28:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUy0w-0000mG-4B; Mon, 31 May 2004 21:24:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BUxv2-0000A0-5V for rtg-dir@megatron.ietf.org; Mon, 31 May 2004 21:18: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 VAA26516 for ; Mon, 31 May 2004 21:18: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 1BUxv0-0004TY-FG for rtg-dir@ietf.org; Mon, 31 May 2004 21:18:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BUxu2-000450-00 for rtg-dir@ietf.org; Mon, 31 May 2004 21:17:19 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BUxt4-0003g7-00 for rtg-dir@ietf.org; Mon, 31 May 2004 21:16:18 -0400 Received: from wll-17-pppoe165.t-net.net.ve ([200.31.131.165] helo=mycomputer) by mx2.foretec.com with smtp (Exim 4.24) id 1BUxt5-0002R8-CN for rtg-dir@ietf.org; Mon, 31 May 2004 21:16:19 -0400 Date: Tue, 1 Jun 2004 01:16:23 GMT From: $HAJIA$KHALID To: rtg-dir@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: Content-Transfer-Encoding: 7bit Subject: I NEED YOUR HELP X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org 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,NO_REAL_NAME,SUBJ_ALL_CAPS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit No: 24A Idrisa Road, Baghdad. Republic of Iraq. Salam Greetings to you in the name of our Allah i got your e mail through the help of my nurse who scanned the internet and gave me your mail. I am Mrs Mariam Khalid a devoted muslim,a new muslim convert of 74 years old after being converted from a christian family by my husband.For quite a good number of years now,I have been suffering from cancer of the b reast and fibroid of the womb which has for a long time now affected my health a nd from all indications my condition is deteriorating by day and by my doctor's prediction I have less than six months to live. My husband who is now late was killed during the US/British attack against the president of my country (Sadam Hussain).My late husband was a member of the contract award committee of the republican ministry of petroleum and resources of Iraq under the regime of Sadam Hussein Throughout the period of my marriage with my husband,all efforts to bear children proved abortive because of my poor state of health.My husband was a very wealthy and influential man during the post war Iraq. After his death,I inherited all his wealth since he has no other next of kin. Since it is now obvious that I may not survive my poor state of health, I have deemed it necessary to leave a legacy on Earth and give a positive account and justification of the life I lived on Earth before the Almighty Allah. This I want to achieve by committing part of this wealth in all sincerlity to fund , Islamic orphanages,widows and the less priviledge peoples all over the world. I know that afterdeath, I will be with ALLAH the most beneficent and the most merciful. Please, note that this sum(us$35 Million) was securely deposited in a security/financial company overseas in my name by my husband . I have highlighted my attorney on the said sum and all the possible assistance he would render to you on the documents covering the money so as to enable you receive it as I cannot follow it up because of my ill health,this e mail is being written for me by the nurse in my private hospital. Presently, my attorney is in Europe waiting for anybody willing. I will also issue you a letter of authorization to anable the money be paid to you.I want you and the Muslim community and all servants of the almighty where you reside to always pray for me .It does not matter your religion or wether i trust you but do actualize my dreams with this money for the sake of the almighty.My happiness is that i lived a life of a true devoted life worthy of emulation. Lastly, I honestly pray that this money when remitted to you will be judiciously used for the said purpose and you will take 10% as a compensation for your assistance in carrying out these humanitarian services. Whoever wants to serve God must serve him in truth and in fairness. Please always be prayerful all through your life. Any delay in your reply will give me room to source for another person or a devoted muslim for this same purpose.Until I hear from you, my dreams will rest squarely on your shoulders. May the almighty ALLAH continue to bless you Best regards. Hajia Mariam Khalid. From rtg-dir-bounces@ietf.org Mon Jun 7 19:22:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02387 for ; Mon, 7 Jun 2004 19:22: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 1BXTSA-0001cH-P4 for rtg-dir-archive@ietf.org; Mon, 07 Jun 2004 19:22:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXTRA-00011G-00 for rtg-dir-archive@ietf.org; Mon, 07 Jun 2004 19:21:53 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXTQZ-0000QN-00 for rtg-dir-archive@ietf.org; Mon, 07 Jun 2004 19:21:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXTJn-0003WY-3I; Mon, 07 Jun 2004 19:14:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXTCf-0000pU-1z for rtg-dir@megatron.ietf.org; Mon, 07 Jun 2004 19:06: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 TAA01618 for ; Mon, 7 Jun 2004 19:06: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 1BXTCd-00005w-Bk for rtg-dir@ietf.org; Mon, 07 Jun 2004 19:06:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXTBr-0007KU-00 for rtg-dir@ietf.org; Mon, 07 Jun 2004 19:06:04 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BXTB5-0006ks-00 for rtg-dir@ietf.org; Mon, 07 Jun 2004 19:05:15 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1BXTB5-000OPC-NR for rtg-dir@ietf.org; Mon, 07 Jun 2004 23:05:15 +0000 Date: Mon, 7 Jun 2004 16:05:15 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <3110651711.20040607160515@psg.com> To: rtg-dir@ietf.org In-Reply-To: <200406072229.SAA29969@ietf.org> References: <200406072229.SAA29969@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: Fwd: UPDATED Agenda and Package for June 10, 2004 Telechat X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org 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 FYI. Comments /if any/ by Wed, please. -- Alex http://www.psg.com/~zinin This is a forwarded message From: IESG Secretary To: iesg@ietf.org Cc: bfuller@foretec.com, amyk@foretec.com Date: Monday, June 7, 2004, 3:29:18 PM Subject: UPDATED Agenda and Package for June 10, 2004 Telechat ===8<==============Original message text=============== INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the June 10, 2004 IESG Teleconference This agenda was generated at 17:23:6 EDT, June 7, 2004 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes 1.4 Review of Action Items 1.5 Review of Projects http://www.unreason.com/jfp/iesg-projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o Two-document ballot: - 1 of 7 - draft-ietf-l3vpn-rfc2547bis-01.txt BGP/MPLS IP VPNs (Proposed Standard) - draft-ietf-l3vpn-as2547-05.txt Applicability Statement for BGP/MPLS IP VPNs (Informational) Token: Thomas Narten o draft-ietf-iptel-rfc2806bis-08.txt The tel URI for Telephone Numbers (Proposed Standard) - 2 of 7 Token: Jon Peterson o draft-ietf-ipsec-ikev2-14.txt Internet Key Exchange (IKEv2) Protocol (Proposed Standard) - 3 of 7 Token: Russ Housley o draft-ietf-tewg-mib-08.txt A Traffic Engineering MIB (Proposed Standard) - 4 of 7 Note: Participant in PROTO Team pilot:. Workgroup Chair Followup of AD Evaluation Comments. http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot-00.txt Token: Bert Wijnen o draft-iesg-rfced-documents-02.txt The IESG and RFC Editor documents: Procedures (BCP) - 5 of 7 Token: David Kessens o draft-ietf-send-ndopt-05.txt SEcure Neighbor Discovery (SEND) (Proposed Standard) - 6 of 7 Token: Margaret Wasserman o draft-ietf-smime-rfc2632bis-07.txt S/MIME Version 3.1 Certificate Handling (Proposed Standard) - 7 of 7 Token: Russ Housley 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-ietf-nat-natmib-09.txt Definitions of Managed Objects for Network Address Translators (NAT) (Proposed Standard) - 1 of 3 Note: Had careful MIB doctor review.  Wrt function, allowed to configure. only the NAT's address range and not NAT/firewall binds or. firewall policies.  This means no conflict with MIDCOM. Token: Allison Mankin o draft-ymbk-downref-02.txt Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level (BCP) - 2 of 3 Token: Harald Alvestrand o draft-klensin-process-july14-02.txt A model for IETF Process Experiments (BCP) - 3 of 3 Token: Harald Alvestrand 2.2.2 Returning Item NONE 2.2.3 For Action o draft-duerst-iri-08.txt Internationalized Resource Identifiers (IRIs) (Proposed Standard) - 1 of 1 Token: Harald Alvestrand 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-ieprep-framework-09.txt Framework for Supporting ETS in IP Telephony (Informational) - 1 of 7 Token: Jon Peterson o draft-ietf-l3vpn-ppvpn-terminology-02.txt PPVPN terminology (Informational) - 2 of 7 Note: 2004-06-07: on IESG agenda for review; needed by other ppvpn documents. Token: Thomas Narten o draft-ietf-v6ops-application-transition-02.txt Application Aspects of IPv6 Transition (Informational) - 3 of 7 Note: Participant in PROTO Team pilot:. Working Group Chair Followup of DISCUSS Comments. http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-discuss-pilot-01.txt Token: David Kessens o draft-ietf-dnsop-ipv6-dns-issues-07.txt Operational Considerations and Issues with IPv6 DNS (Informational) - 4 of 7 Note: Participant in PROTO Team pilot: Workgroup Chair Followup of AD Evaluation Comments http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot-00.txt Token: David Kessens o draft-ietf-dnsop-misbehavior-against-aaaa-01.txt Common Misbehavior against DNS Queries for IPv6 Addresses (Informational) - 5 of 7 Note: Participant in PROTO Team pilot: Workgroup Chair Followup of AD Evaluation Comments http://www.ietf.org/internet-drafts/draft-ietf-proto-ad-comments-pilot-00.txt Token: David Kessens o draft-ietf-mboned-mroutesec-01.txt PIM-SM Multicast Routing Security Issues and Enhancements (Informational) - 6 of 7 Token: David Kessens o draft-ietf-rtgwg-igp-shortcut-01.txt Calculating IGP Routes Over Traffic Engineering Tunnels (Informational) - 7 of 7 Token: Alex Zinin 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-walker-ieee802-req-01.txt EAP Method Requirements for Wireless LANs (Informational) - 1 of 1 Note: To be reviewed by the IESG BLUE TEAM! Token: Margaret Wasserman 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item o draft-wlai-tewg-bcmodel-04.txt Bandwidth Constraints Models for Diffserv-aware MPLS Traffic Engineering: Performance Evaluation (Informational) - 1 of 1 Token: Bert Wijnen 3.3.2 Returning Item o draft-dfncis-netnews-admin-sys-06.txt Netnews Administration System (NAS) (Experimental) - 1 of 1 Note: Re-review in light of new procedures for individual submissions via the RFC Editor.  This one has been in the IESG's hands for two years! Token: Scott Hollenbeck 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Protocol for carrying Authentication for Network Access (pana) - 1 of 3 Token: Thomas Narten o Extensible Authentication Protocol (eap) - 2 of 3 Token: Margaret Wasserman o Multiprotocol Label Switching (mpls) - 3 of 3 Token: Alex Zinin 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issue 7.1 PERM - Protected Entertainment Rights Management (Harald Alvestrand) 7.2 3667/3668 fix (Steve Bellovin) From rtg-dir-bounces@ietf.org Tue Jun 8 09:36:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26047 for ; Tue, 8 Jun 2004 09:36: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 1BXgmD-0000Tl-AO for rtg-dir-archive@ietf.org; Tue, 08 Jun 2004 09:36:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXgl8-0007WK-00 for rtg-dir-archive@ietf.org; Tue, 08 Jun 2004 09:35:23 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BXgjq-00064V-00 for rtg-dir-archive@ietf.org; Tue, 08 Jun 2004 09:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXgdE-0001gi-D6; Tue, 08 Jun 2004 09:27:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXgXu-0000QJ-SP for rtg-dir@megatron.ietf.org; Tue, 08 Jun 2004 09:21: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 JAA25207 for ; Tue, 8 Jun 2004 09:21: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 1BXgXu-0004qG-69 for rtg-dir@ietf.org; Tue, 08 Jun 2004 09:21:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXgWs-00044d-00 for rtg-dir@ietf.org; Tue, 08 Jun 2004 09:20:39 -0400 Received: from [213.180.125.182] (helo=rmt) by ietf-mx with smtp (Exim 4.12) id 1BXgW5-0003L7-00; Tue, 08 Jun 2004 09:19:50 -0400 Message-ID: From: "Aliu" Date: Tue, 08 Jun 2004 16:19:40 +0200 To: rmt@ietf.org, rmonmib@ietf.org, rpsec@ietf.org, rserpool@ietf.org, rtg-dir@ietf.org, rohc@ietf.org, routing-discussion@ietf.org, scoya@ietf.org, simple@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA25207 Subject: Massive discounts on leading software ! X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE, HTML_TITLE_EMPTY,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Huge discounts on great software!

MS Windows XP Professional , $200=C2=A0 ONLY $80
Microsoft Office 2003 Professional, $300 ONLY $120
Adobe Photoshop 7.0, $500<= /span> ONLY $90
Norton Antivirus 2004 Professional, $100 ONLY $60
Easy CD & DVD Creator 6, $90 ONLY $50

Plus many many more

Vist the website today






No Thanks
From rtg-dir-bounces@ietf.org Wed Jun 16 11:30:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09124 for ; Wed, 16 Jun 2004 11:30: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 1BacMT-00023t-UZ for rtg-dir-archive@ietf.org; Wed, 16 Jun 2004 11:30:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Babc4-0002Kn-00 for rtg-dir-archive@ietf.org; Wed, 16 Jun 2004 10:42:05 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaahM-0001bw-00 for rtg-dir-archive@ietf.org; Wed, 16 Jun 2004 09:43:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BaZol-0000lF-33 for rtg-dir-archive@ietf.org; Wed, 16 Jun 2004 08:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaXMH-0007S2-RX; Wed, 16 Jun 2004 06:09:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaTYT-0006u9-L3 for rtg-dir@megatron.ietf.org; Wed, 16 Jun 2004 02:05: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 CAA08853 for ; Wed, 16 Jun 2004 02:05: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 1BaTYR-0005Dy-Fl for rtg-dir@ietf.org; Wed, 16 Jun 2004 02:05:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaQpt-00044J-00 for rtg-dir@ietf.org; Tue, 15 Jun 2004 23:11:37 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BaM9L-0005r5-00 for rtg-dir@ietf.org; Tue, 15 Jun 2004 18:11:24 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaM9M-000J7M-Dn for rtg-dir@ietf.org; Tue, 15 Jun 2004 22:11:24 +0000 Date: Tue, 15 Jun 2004 15:11:24 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1710720649.20040615151124@psg.com> To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: draft-shen-ip-te-rsp-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org 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 I like the idea a lot. Opinions? -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Wed Jun 16 13:50:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24648 for ; Wed, 16 Jun 2004 13:50: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 1BaeXz-0000Ul-Mg for rtg-dir-archive@ietf.org; Wed, 16 Jun 2004 13:50:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BadvT-0003Nq-00 for rtg-dir-archive@ietf.org; Wed, 16 Jun 2004 13:10:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BadaZ-00077G-00 for rtg-dir-archive@ietf.org; Wed, 16 Jun 2004 12:48:39 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BadV2-0006D4-48 for rtg-dir-archive@ietf.org; Wed, 16 Jun 2004 12:42:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BadCP-0000gy-25; Wed, 16 Jun 2004 12:23:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacfG-0003Xd-5z for rtg-dir@megatron.ietf.org; Wed, 16 Jun 2004 11:49: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 LAA12606 for ; Wed, 16 Jun 2004 11:49: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 1BacfC-0005MA-Gd for rtg-dir@ietf.org; Wed, 16 Jun 2004 11:49:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bac5c-0007A2-00 for rtg-dir@ietf.org; Wed, 16 Jun 2004 11:12:37 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BabIS-00075i-00 for rtg-dir@ietf.org; Wed, 16 Jun 2004 10:21:48 -0400 Received: from psg.com ([147.28.0.62]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BabIT-0008Fq-0W; Wed, 16 Jun 2004 14:21:49 +0000 Message-ID: <40D0577A.7050707@psg.com> Date: Wed, 16 Jun 2004 16:21:46 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <1710720649.20040615151124@psg.com> In-Reply-To: <1710720649.20040615151124@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: draft-shen-ip-te-rsp-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org 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 alex, i'm personally in favor in moving forward with this idea, specific details concerning the proposed solution should be further discussed (e.g. bi- directional tunnels, definition and processing of the newly proposed objects, detail usage of mandatory RSVP objects, etc.) but overal the idea seems really promising --- Alex Zinin wrote: > I like the idea a lot. > Opinions? > From rtg-dir-bounces@ietf.org Wed Jun 16 19:36:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01526 for ; Wed, 16 Jun 2004 19: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 1Bajwp-0001Rx-3h for rtg-dir-archive@ietf.org; Wed, 16 Jun 2004 19:36:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bajvu-00013X-00 for rtg-dir-archive@ietf.org; Wed, 16 Jun 2004 19:35:14 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bajv1-0000N3-00 for rtg-dir-archive@ietf.org; Wed, 16 Jun 2004 19:34:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BajlW-0003bA-BD; Wed, 16 Jun 2004 19:24:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaiwB-0008Vh-S1 for rtg-dir@megatron.ietf.org; Wed, 16 Jun 2004 18:31: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 SAA25935 for ; Wed, 16 Jun 2004 18:31: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 1Baiw7-0007ZL-9b for rtg-dir@ietf.org; Wed, 16 Jun 2004 18:31:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaivG-00079E-00 for rtg-dir@ietf.org; Wed, 16 Jun 2004 18:30:31 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BaiuA-0006gz-00 for rtg-dir@ietf.org; Wed, 16 Jun 2004 18:29:14 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BaiuC-000DYq-7z; Wed, 16 Jun 2004 22:29:17 +0000 Date: Wed, 16 Jun 2004 15:29:15 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1051626490.20040616152915@psg.com> To: rtg-dir@ietf.org, George Swallow , Loa Andersson In-Reply-To: <001701c451b6$267e84e0$6601a8c0@MITRE.ORG> References: <9C422444DE99BC46B3AD3C6EAFC9711B0644B9CF@tayexc13.americas.cpqcorp.net> <001701c451b6$267e84e0$6601a8c0@MITRE.ORG> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------71E75CEBD4BBB" X-Mailman-Approved-At: Wed, 16 Jun 2004 19:24:21 -0400 Cc: Sham Chakravorty Subject: Fwd: draft-ietf-chakravorty-6LSA-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org 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 ------------71E75CEBD4BBB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks- Sham is looking for feedback on this document. (I haven't read it myself yet.) Thanks. -- Alex http://www.psg.com/~zinin This is a forwarded message From: Sham Chakravorty To: Cc: "Bound, Jim" , "'Sham Chakravorty'" Date: Sunday, June 13, 2004, 7:20:24 PM Subject: draft-ietf-chakravorty-6LSA-00.txt ===8<==============Original message text=============== Alex, Attached is the Internet Draft on IPv6 Label Switching Architecture (6LSA) that I am submitting to you for inclusion into the rtgwg per your advice to Jim. I will soon be developing the second draft on the detailed TE aspects of the architecture with some folks from other companies to enrich the IPv6 TE process going forward. Please let me know if you have questions or comments. And, thanks in advance for all your considerations, Sham Chakravorty Mitre Corp. Ph: 703-883-7443 -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Wednesday, May 05, 2004 11:57 AM To: Bound, Jim Cc: fenner@research.att.com; Scott Bradner Subject: Re: Advice: Label Switching Optimization using the IPv6 Flow Label Jim, In general, something like what you described would belong to RTG. Without looking at the spec, I would suspect that such a proposal is bound to be a flame attraction device given how much investment has been put in MPLS. What we could do is bring this doc for review to the RTG Directorate and ask folks to comment. This would give the author a flavor of what to expect in public... -- Alex http://www.psg.com/~zinin/ Tuesday, May 4, 2004, 10:04:37 PM, Bound, Jim wrote: > Bill and Alex, > Need some advice. I know of engineer who works with the DOD that has > developed a specification that does label switching via use of the > IPv6 Flow label and I have reviewed the spec. It is written very well > and presents some new ideas and a mehod that avoids some of the > pitfalls in MPLS. The first document presents a Label Switching > Architecture for IPv6. The engiener is sensitive to presenting the > work and wants it to be worked on the IETF. I believe it clearly > belongs in the routing area. The question is where should the > engineer submit the spec for us in the IETF to review. I re-read the > MPLS charter and it sounds like a place to do it, but I am not sure. > Or should it be a BOF for new Working Group? But it would be good to > send this to IETF soon is my view. What is your advice? I cpied > Scott for his advice too as he has done much work with routers in the > industry. I think we want to see this engineers work in the IETF. > But, I also don't want to see engineer in political disadvantage by sending to MPLS WG. > Thanks > /jim ===8<===========End of original message text=========== ------------71E75CEBD4BBB Content-Type: TEXT/PLAIN; name="draft-ietf-chakravorty-6lsa-00.txt" Content-Disposition: attachment; filename="draft-ietf-chakravorty-6lsa-00.txt" Content-Transfer-Encoding: quoted-printable draft-ietf-chakravorty-6lsa-0.txt August 20= 04=20 =20 =20 =20 Internet Draft S. Chakra= vorty=20 Document: draft-ietf-chakravorty-6LSA-00.txt Mitre = Corp.=20 Expires: December 2004 August= 2004=20 =20 =20 IPv6 Label Switching Architecture (6LSA)=20 draft-ietf-chakravorty-6lsa-0.txt=20 =20 =20 Status of this Memo=20 =20 This document provides specifications for IPv6 label switching architectu= re (6LSA)=20 and associated IPv6 packet transport mechanisms. =20 =20 Distribution of this memo is unlimited.=20 =20 This document is an Internet-Draft and is in full conformance with all pr= ovisions=20 of Section 10 of RFC 2026. Internet-Drafts are working documents of the = Internet=20 Engineering Task Force (IETF), its areas, and its working groups. Note t= hat other=20 groups may also distribute working documents as Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months and= may be=20 updated, replaced, or obsoleted by other documents at any time. It is=20 inappropriate to use Internet-Drafts as reference material or to cite t= hem other=20 than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at: =20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed at:=20 http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 This specification provides an architectural framework, called IPv6 Labe= l=20 Switching Architecture or 6LSA, for an end-to-end, IP-centric packet swi= tching=20 technique that uses the IPv6 packet header Flow Label, header extensions= , and=20 unique routing algorithms, the latter two when needed, to establish IPv6= -based=20 label switched paths. The label switched paths, called 6LSPs, provide a= pplication=20 and user specified routes for speedier transport of packets and as means= for=20 quality of service (QoS) solutions as in IPv4-based MPLS or ATM. Since = MPLS-like=20 protocol labeling will be redundant for IPv6 and since there are no wide= ly-known=20 QoS deployments of IPv6 over any of the layer 2 switching mechanisms suc= h as ATM,=20 the 6LSA framework fills the technology void without the link overhead f= rom=20 extraneous layer 2 labeling and signaling of MPLS, or packet fragmentati= on and=20 added signaling as in ATM. Through the use of fast switching of 20-bit = labels=20 instead of 128-bit IPv6 address look-ups, the architecture presented her= e also=20 provides processing savings through significantly reduced address fetche= s for the=20 low-powered, handheld devices. =20 =20 Table of Contents=20 =20 1. Introduction.....................................................2=20 2. Overview.........................................................3=20 =0C3. Terminology......................................................4=20 4. Distinguishing Characteristics of 6LSA...........................6=20 5. Routing Versus Switching of IP Traffic...........................7=20 6. 6LSA Basic Components and Their Attributes.......................8=20 6.1 Label.......................................................8=20 =20 =20 Chakravorty Expires - December 2004 [Page 1= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 6.2 Flow........................................................8=20 6.3 Pseudoflow..................................................9=20 6.4 Forwarding Equivalence Class (FEC).........................10=20 6.5 Labeled Packet.............................................10=20 6.6 IPv6 Label Switching Router (6LSR).........................10=20 6.7 Lead Packet................................................11=20 6.8 Packet Identifier (PID) Field..............................11=20 6.9 Switching Table............................................11=20 6.10 Attributes of Label Binding...............................11=20 6.11 IPv6 Label Switched Path (6LSP)...........................12=20 7. 6LSA Functionalities............................................14=20 7.1 Label Assignment...........................................14=20 7.2 Scope and Uniqueness of Labels.............................16=20 7.3 Label Retention Mode.......................................18=20 7.4 Packet Forwarding..........................................18=20 7.5 Label Stacking.............................................18=20 7.6 Label Swapping.............................................18=20 7.7 Packet Processing Algorithm................................18=20 7.8 Fast Switching.............................................25=20 7.9 FEC Mapping................................................25=20 7.10 Penultimate 6LSR Label Processing.........................25=20 7.11 Invalid Incoming Labels...................................25=20 7.12 Aggregation...............................................26=20 7.13 Route Selection...........................................26=20 7.14 Control...................................................26=20 7.15 Label Encodings...........................................26=20 7.16 Anycast in 6LSA...........................................26=20 7.17 Multicast in 6LSA.........................................27=20 8. Security Considerations.........................................27=20 9. Informative References..........................................27=20 10. Acknowledgements...............................................28=20 11. Author=92s Addresses.............................................28=20 12.................................................................28=20 =20 =20 1. =0D=20 Introduction=20 =20 Several approaches have been developed over the past decade to provide p= acket=20 switching and QoS to IPv4 flows. These include MPLS, ATM, extensions to= routing=20 protocols such as IGP, IS-IS and OSPF, and proprietary. Some of these t= echniques=20 can also be applied to IPv6 transport but not directly. An MPLS mechani= sm for=20 IPv6 would amount to redundant labeling; what is commonly proposed is IP= v6 to IPv4=20 translation or tunneling and then using MPLS. There is no widely known = deployment=20 where one or more of the common layer 2 switching techniques have been u= sed with=20 IPv6 for QoS delivery. However, IPv6 offers strong features to enable s= witching=20 of IPv6 packets, most significant among them are the provision of the Fl= ow Label=20 and the Routing Header extension. This framework thus fills the void th= at absence=20 of such IPv6 switching technologies present. =20 =20 The IPv6 Label Switching Architecture (6LSA) eliminates the link overhea= d from=20 extraneous layer 2 labeling and signaling as in MPLS, or packet fragment= ation and=20 added signaling as in ATM. The fast switching of 20-bit labels instead = of 128-bit=20 IPv6 address look-ups also provides processing savings because address f= etches for=20 low-powered, handheld devices, which are mostly 32-bit architectures, wo= uld be=20 four times as fast. =20 =0C =20 This document introduces an architectural framework for the use of IPv6 = packet=20 header Flow Labels for setting up label switched paths of local signific= ance to=20 provide QoS for connection-oriented flows that cannot be provided by a p= urely=20 routed, connectionless approach. The 6LSA allows local label generation= that can=20 =20 =20 Chakravorty Expires - December 2004 [Page 2= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 help update label values in a synchronized manner across the network to = reduce=20 man-in-the-middle attacks. In essence, the 6LSA provides the means for = static and=20 mobile nodes to set up label switched paths, automatically and/or manual= ly, to=20 provide secure end-to-end QoS. =20 =20 2. =0D=20 Overview=20 =20 The IPv6 label switching mechanism makes use of the 20-bit Flow Label in= the IPv6=20 header to assign flow IDs which are used for IPv6 Flow Label switched pa= ths, also=20 called IPv6 label switched paths (6LSPs). The specification of IPv6 lab= el is in=20 conformance with [2] RFC 3697, IPv6 Flow Label Specification, in which t= he use of=20 Flow Label has been recommended for establishing different types of flow= s end-to- end. Indeed, the proposed mechanism of IPv6 label switching significantl= y broadens=20 the scope of the use of Flow Labels beyond its mere use for flow identif= ication.=20 =20 In a conventional router, the forwarding decision is independently made = in each=20 router as the packet travels from one router to the next. In each route= r, the=20 packet=92s header is analyzed using a network layer routing algorithm to= find the=20 best next-hop that is often the shortest distance to the next router. S= ince this=20 forwarding in each router is "independent" of how the previous packet fo= r the same=20 destination was processed and forwarded, the routing is considered conne= ctionless.=20 =20 As noted in [1] =96 RFC 3031, MPLS Architecture, e. Rosen, et al, IP pac= ket header=20 contains significantly more information than is needed for the selection= of the=20 best next hop. The process specified in this document provides two func= tions:=20 first, grouping of packets of similar flow requirements into a Forwardin= g=20 Equivalence Class (FEC), and second, forwarding all packets belonging to= an FEC=20 along the same path or set of paths, the latter when multiple paths are = allowed,=20 for example, in case of load balancing. The assignment of packets to an= FEC is=20 called binding. =20 =20 In 6LSA, the FEC may be encoded in the Flow Label field as a non-zero va= lue, which=20 is also called label in this document. The label is thus either availab= le in the=20 incoming packet=92s Flow Label, locally generated based on certain algor= ithm or=20 policy, or distributed through a label distribution process. =20 =20 Once a binding of a label to a given FEC is performed, the forwarding tr= eatment of=20 the packet may be represented through the label and is maintained at a m= inimum for=20 the duration of the session. As in the MPLS Architecture [1], a packet = is labeled=20 before it is forwarded, however, unlike MPLS, the label may be strictly = local-node=20 based as also the processing of the packet. =20 =20 Several models for how to build and use the 6LSA labels are presented in= this=20 document. The IP packet header, specifically the IPv6 packet header, co= ntains=20 more information than is needed to determine the next hop and forward th= e packet. =20 The 6LSA label can easily support the forwarding of packets belonging to= the same=20 FEC along a 6LSP. =20 =20 In the 6LSA, only the first packet of a flow is analyzed for FEC determi= nation and=20 label selection. Subsequent packets of the same flow may not go through= the same=20 process of label selection and assignment. =20 =20 Packet forwarding is done using the label only after the label binding t= o a FEC=20 has taken place. =20 =20 =0C At each router, the label assigned to a packet, along with the packet= =92s source and=20 destination addresses, and other processing criteria are entered into a = packet=20 forwarding table, also called a switching table. The label is assigned = to the=20 lead packet of a flow, which may or may not be the same as first packet = of the=20 flow. As subsequent packets arrive, the switching table is checked usin= g the=20 =20 =20 Chakravorty Expires - December 2004 [Page 3= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 algorithms described here to see if there is a label for the flow. If n= one=20 exists, a label is assigned to the packet and the packet is treated as a= lead=20 packet. If a label value exists in the switching table, then the packet= is given=20 the same forwarding treatment as the label binding indicates.=20 =20 Since the packet forwarding decision can be made based on the switching = look up,=20 the packet processing is fast, as per a known forwarding treatment, and = takes=20 place over a known path.=20 =20 The selection of a label is based on the FEC which itself is based on on= e or more=20 packet characteristics. What characteristics should be chosen for what = FEC is an=20 administrative, QoS, or policy decision, or a combination thereof. Such= a=20 decision is meant to support certain traffic engineering requirements, s= uch as=20 those based on DSCP code points or other similar values encoded or confi= gured into=20 the Traffic Class field of IPv6 packet header. This selection and encod= ing=20 procedure is outside the scope of this specification. Selection of FEC = may be a=20 configurable parameter of the router, server, host or any other device t= hat=20 implements this specification of 6LSA. =20 =20 Finally, 6LSA is applicable to any device that is capable of processing = and=20 forwarding IPv6 packets. This protocol is not constrained by any layer = 2 or layer=20 1 technology.=20 =20 3. =0D=20 Terminology=20 =20 This section provides a general overview of the terms used in this docume= nt. Some=20 of these terms are more precisely defined in the later sections of this d= ocument. =20 Most of the definitions mirror those provided in RFC 3031 [1] and are app= lied to=20 the 6LSA specification as appropriate for consistency.=20 =20 =20 FEC Forwarding Equivalent Class; the forwarding tr= eatment=20 that a collection of IP packets receives; such= =20 packets all have the same characteristics from = a=20 QoS perspective, receive the same forwarding=20 treatment, and are generally forwarded over the= =20 same label switched path (6LSP) =20 =20 label the IPv6 Flow Label which is carried in the IP= v6 packet=20 header and used in 6LSA, and which may represen= t=20 the packet's FEC=20 =20 flow a flow is a sequence of packets identified by = the 3- tuple of source and destination addresses, and = the=20 Flow Label=20 =20 Flow Label the 20-bit label in the IPv6 header used for= =20 identifying flows=20 =20 flow merge same as label merging, when it is applied to f= lows =20 =20 label merging the replacement of multiple incoming labels wi= th a=20 single outgoing label=20 =20 label swapping the basic forwarding operation consisting of l= ooking up=20 =0C an incoming label to determine the outgoing = label,=20 port, and other data handling information and t= hen=20 replacing the incoming label with the outgoing= =20 label which may or may not be the same as the= =20 incoming label=20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 4= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 label switching a fast forwarding operation allowing streamlin= ed=20 forwarding of packets by using labels to identi= fy=20 classes of data packets which are treated=20 indistinguishably when forwarding=20 =20 label switched hop the hop between two 6LSA nodes, on which forwa= rding is=20 done using labels=20 =20 label switched path a virtual path through which all packets in a = flow are=20 routed across a routing or administrative domai= n =20 =20 lead packet a packet arriving at a 6LSA node that is the f= irst=20 packet in the flow that this node has received = and=20 carries a 0 (zero) label if arriving from a non- 6LSA domain and may carry a non-zero label if= =20 arriving from an upstream 6LSA node next-to-the- lead packet a packet that arrives at a 6LSA nod= e=20 after the lead packet of the flow, also called = an=20 NTL packet =20 =20 node may be a source or intermediate node in the 6L= SA domain=20 or non-6LSA domain unless identified specifical= ly=20 as a source node =20 =20 pseudoflow a flow that has the lead packet carrying a 0 (= zero)=20 label, or packets carrying source address of a = node=20 other than where the flow originated and=20 destination address of a node other than where = the=20 flow will terminate=20 =20 6LSA domain a contiguous set of nodes that perform 6LSA ro= uting and=20 forwarding operations and are in one routing or= =20 administrative domain=20 =20 6LSA egress node a 6LSA edge node in its role of handling traff= ic as the=20 traffic leaves a 6LSA domain=20 =20 6LSA ingress node a 6LSA edge node in its role of handling traff= ic as the=20 traffic enters a 6LSA domain=20 =20 6LSP a label switched path through a pair or more 6= LSRs =20 =20 6LSR IPv6 label switching router that is capable of= =20 forwarding IPv6 packets based on certain pre- selected FEC attributes=20 =20 source node a node that is the source of one or more packe= ts which=20 all may be associated with a flow =20 =20 subsequent packet any packet that arrives at a 6LSA node after t= he NTL=20 packet=20 =20 switched path synonymous with label switched path=20 =20 virtual circuit (VC) a circuit used by a connection-oriented layer = 2=20 technologies such as ATM or Frame Relay, requir= ing=20 =0C the maintenance of state information in laye= r 2=20 switches=20 =20 VC merge label merging where the 6LSA label is carried = in the=20 ATM VCI field (or in the combined VPI/VCI field= ),=20 so as to allow multiple VCs to merge into one= =20 single VC=20 =20 =20 Chakravorty Expires - December 2004 [Page 5= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 =20 VP merge label merging where the 6LSA label is carried i= n the ATM=20 VPI field, so as to allow multiple VPs to be me= rged=20 into one single VP; in this case two cells woul= d=20 have the same VCI value only if they originated= =20 from the same node; this allows cells from=20 different sources to be distinguished via the V= CI=20 =20 =20 4. =0D=20 Distinguishing Characteristics of 6LSA =20 =20 The 6LSA characteristics justify its application wherever IPv6 is deploy= ed and=20 where QoS network performance delivery is required or where other availa= ble packet=20 switching mechanisms cannot deliver network performance end-to-end. The= special=20 characteristics of 6LSA are listed here in no particular order:=20 =20 o IP Transparency End-to-End - By being a layer 3 protocal and by =20 avoiding encapsulation (as in MPLS) or fragmentation (as in ATM) of I= P, the=20 6LSA retains the IP transparency end-to-end. =20 =20 o No-Extraneous-Label-Binding Option =96 6LSA offers the option to avoi= d the use of=20 any extraneous labels and thus avoid the need for label distribution = across=20 the network in the control plane as is done in MPLS.=20 =20 o No Label Distribution Protocols - There is no need for label =20 distribution protocol so as to be able to map labels to addresses acr= oss the=20 network(s).=20 =20 o Elimination of Label Distribution Traffic =96 Absent a control =20 plane for label distribution, there is no control plane traffic.=20 =20 o No Label Distribution State Machine =96 Without label distribution, = =20 there is no need for a separate state machine for the maintenance of= =20 extraneous labels.=20 =20 o Free of Layer 2 Overheads - Being a layer 3 packet switching =20 solution, 6LSA does not need a layer 2 packet switching mechanism =20 such as ATM, MPLS or switched Frame Relay and as such 6LSA avoids ATM= =92s=20 fragmentation and reassembly of IP packets and thus eliminates the re= sulting=20 header overhead. It also avoids the need for added signaling and sta= te=20 machine mechanisms to provide ATM switched paths and ship-by-night=20 capabilities. Additionally, 6LSA tends to avoid the potential for O(= N2) and=20 O(N3) problems. =20 =20 o Deployment Ease - The 6LSA can be deployed over simple layer 2 =20 protocols such as Ethernet and PPP. This should help expedite the de= ployment=20 of IP over DWDM. There is no layer 2 interface limitation in 6LSA.= =20 =20 o Extensive QoS Label Space - The 20-bit Flow Label in addition to =20 the 8-bit Traffic Class field can provide a huge traffic classificati= on space=20 if needed, conversely, both the fields may be used together in the 6L= SA. =20 (This is a subject for further work and documentation.) Neither MPLS= or nor=20 ATM provides this capability, indeed MPLS is allowed to forfeit up to= 5 bits=20 from its label space for QoS marking.=20 =20 =0C o Feature Visibility to Applications =96 Unlike ATM or MPLS, all of = =20 IPv6=92s packet features are available to upper layer APIs. In the c= ase of ATM,=20 whole IP packets have to be reassembled for common IP APIs to work, w= hile in=20 MPLS, one or more labels have to be removed. =20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 6= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 o Extensive Operational Flexibility - 6LSA provides the flexibility =20 between switching and routing as needed without the need for label po= pping or=20 any additional processing for exiting the 6LSA mode of operation and = then=20 again reverting back to 6LSA. Thus any two peering nodes can have a = best- effort routing between them on a pair of interfaces while on other in= terfaces,=20 the same two nodes may forward the same packets over 6LSPs. The 6LSA= thus=20 allows the best of both worlds for transmission =96 one with a single= class of=20 traffic and the other with multiple classes of traffic.=20 =20 o Security Enhancement =96 since 6LSA allows node-local generation of = =20 labels, such generation where adopted can be made totally random or= =20 periodically synchronized across the 6LSA domain to considerably redu= ce man- in-the-middle attacks.=20 =20 o Hop Limit field - the 8-bit hop limit field in the IPv6 header =20 is available for loop prevention. There is no need to port this valu= e to an=20 extraneous label.=20 =20 o No MTU Violation =96 since the packet size does not change because = =20 of the addition of extraneous labels, 6LSA eliminates the potential f= or MTU=20 violations.=20 =20 o Fast Switching in IPv6 =96 the 6LSA protocol provides for a fast =20 label switching mechanism heretofore available only in IPv4 =20 through the use of MPLS.=20 =20 To summarize, 6LSA provides a significantly efficient and powerful layer= 3=20 mechanism for switching IP packets - with little or no added overhead fo= r=20 establishing label switched paths - for end-to-end, granular QoS deliver= y. =20 =20 =20 5. =0D=20 Routing Versus Switching of IP Traffic=20 =20 The routing of packets on the Internet has the following essential=20 characteristics.=20 =20 =96 Routing is connectionless and comprises non-sequential packet =20 transport.=20 =20 =96 The technique is essentially store-and-forward and involves slow ro= ute=20 processing. =20 =20 =96 The paths are not dedicated (non-switched) virtual paths - for the = duration of=20 a session, the inter-router or inter-device paths may vary many time= s for a=20 given flow.=20 =20 =96 There are generally no delivery or QoS guarantees - a single class = of traffic=20 is available.=20 =20 =96 The process is geared more toward routing flexibility than speed.= =20 =20 =96 The routing protocols are generally developed by the IETF.=20 =20 =20 Switching of packets has the following basic characteristics.=20 =0C =20 =96 The =93routing=94 of packets is connection-oriented; the flow of p= ackets comprises=20 sequential packets.=20 =20 =96 The packet processing can be cut-through and therefore extremely f= ast.=20 =20 =20 Chakravorty Expires - December 2004 [Page 7= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 =20 =96 The packets travel over dedicated, virtual paths which are either = permanent or=20 temporary.=20 =20 =96 Switching is generally associated with certain delivery guarantees= and traffic=20 classification. =20 =20 =96 The technique is geared more toward speed than routing flexibility= .=20 =20 The issues with switching are:=20 =20 =AD There are delays caused by VC setup time across the network. =20 =20 =AD There is the need for VC state maintenance.=20 =20 =AD IP address to VC translation latency is always present however sma= ll.=20 =20 =AD Hardware performance has not always been up to demand since switch= ing is a=20 rather fast process.=20 =20 =AD Potential for large resource wastage in case of link or node failu= re in IP=20 virtual network over switched network, for example IP over ATM that = may cause=20 N2 and N3 problems. =20 =20 =AD Generally there is no error correction enroute.=20 =20 =AD Most switching protocols are not developed by the IETF. The 6LSA = overcomes=20 most of these disadvantages as will be shown below.=20 =20 =20 6. =0D=20 6LSA Basic Components and Their Attributes=20 =20 In this section, we define the basic components and their attributes pertai= ning to an=20 IPv6.=20 =20 =20 6.1 =0D=20 Label=20 =20 Labels are 20-bit, fixed length Flow Label identifiers in the IPv6 header t= hat a node=20 in the 6LSA binds to a Forwarding Equivalency Class (FEC) and uses it to fo= rward the=20 packet. The label thus represents the FEC. In the 6LSA, the FEC indicates= the=20 forwarding treatment a group or class of packets (with a given label) recei= ves. This=20 label and the FEC it represents have only local (per hop) significance unle= ss the=20 attributes associated with a FEC are shared among multiple nodes.=20 =20 A label in an incoming packet is called an =93incoming label=94, and that i= n an outgoing=20 packet is called an =93outgoing label.=94=20 =20 A label is associated with both the flow and Forwarding Equivalence Class (= FEC). A=20 flow cannot be identified without a label; the forwarding treatment associa= ted with a=20 FEC may be identified by the value of the label.=20 =20 In this document, the nomenclature of label or Flow Label is variously used= though=20 the meaning is the same and while referring to the word label used in other= =20 =0Ctechnologies, such as in MPLS, the context of the technology is also men= tioned to=20 distinguish the application and meaning of the word.=20 =20 =20 6.2 =0D=20 Flow=20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 8= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 A flow is a sequence of packets sent from a particular source node to a par= ticular=20 unicast, anycast or multicast destination node for which the source node de= sires=20 special handling by the intervening nodes. The nature of that special hand= ling might=20 be conveyed to the routers by a control protocol, such as the resource rese= rvation=20 protocol (RSVP), Differentiated Services Traffic Engineering (DSTE) mechani= sm, or by=20 information within the flow's packets themselves. =20 =20 A flow comprises source and destination addresses as well as the label valu= e in the=20 Flow Label. All packets belonging to the same flow must be sent with the sa= me source=20 address, destination address and flow label. =20 =20 There may be multiple active flows in the 6LSA at any given time. Furth= er=20 applicable statements are quoted here from [3] RFC 2460 for clarity.=20 =20 =93A flow label is assigned to a flow by the flow's source node. New fl= ow labels=20 must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFF = hex. The=20 purpose of the random allocation is to make any set of bits within the Fl= ow Label=20 field suitable for use as a hash key by routers, for looking up the state= =20 associated with the flow.=20 =20 If any of those packets includes a Hop-by-Hop Options header, then they all= must be=20 originated with the same Hop-by-Hop Options header contents (excluding th= e Next=20 Header field of the Hop-by-Hop Options header).=20 =20 If any of those packets includes a Routing header, then they all must be or= iginated=20 with the same contents in all extension headers up to and including the R= outing=20 header (excluding the Next Header field in the Routing header). The rout= ers or=20 destinations are permitted, but not required, to verify that these condit= ions are=20 satisfied. If a violation is detected, it should be reported to the sour= ce by an=20 ICMP=20 Parameter Problem message, Code 0, pointing to the high-order octet of the = Flow Label=20 field (i.e., offset 1 within the IPv6 packet).=20 =20 The maximum lifetime of any flow-handling state established along a flow's = path must=20 be specified as part of the description of the state-establishment mechan= ism, e.g.,=20 the resource reservation protocol or the flow-setup hop-by-hop option. A= source=20 must not re- use a flow label for a new flow within the maximum lifetime = of any =20 flow-handling state that might have been established for the prior use of= that flow=20 label.=94=20 =20 =20 6.3 =0D=20 Pseudoflow=20 =20 This specification introduces the concept of pseudoflow. In 6LSA, if a Flo= w Label=20 has a zero value, a 0 (zero) label, the packet containing such a label may = still be=20 treated as a part of a group of packets in a =93flow=94 in which all packet= s have the=20 same source and destination addresses and the same label binding to FEC. T= he 6LSA=20 node may bind the packet to a FEC and process the packet such that it can l= ater be=20 associated with other packets with the same source and destination addresse= s and FEC=20 binding. The transmission of such packets is called a pseudoflow to distin= guish it=20 from the conventional version of flow that comprises a non-zero label.=20 =20 In a pseudoflow, packets may carry source address of a node other than wher= e the=20 pseudoflow originated and destination address of a node other than where th= e=20 pseudoflow will terminate. Thus, a pseudoflow originating at an upstream n= ode, which=20 =0Cmay not be the source node, continues to the next-hop node and terminate= s in the=20 next-hop node, which may not be the destination node. The label binding in= the lead=20 packet may be reused for a pseudoflow going via nodes downstream of the pse= udoflow=20 origination node. =20 =20 In this document, for simplicity, a pseudoflow is often called a flow when = the=20 context is clearly stated.=20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 9= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 =20 6.4 =0D=20 Forwarding Equivalence Class (FEC)=20 =20 The Forwarding Equivalence Class (FEC) represents forwarding treatment a gr= oup of=20 IPv6 packets receive. The forwarding treatment may be based on one or more= =20 attributes associated with the flow or other processing requirements impose= d on the=20 flow externally. =20 =20 Several flows from multiple sources may receive the same forwarding treatme= nt and=20 thus belong to the same FEC. For example, if multiple flows are to be proc= essed in=20 the same outgoing queue because they all deliver the same QoS, they are ide= ntified by=20 the same FEC.=20 =20 =20 6.5 =0D=20 Labeled Packet=20 =20 In 6LSA, a packet that has a label value that a node can bind to a FEC is c= alled a=20 labeled packet. A labeled packet is an IPv6 packet whose header has a zero= or non- zero Flow Label value. =20 =20 All packets in a flow in 6LSA have a non-zero label value, while all packet= s in a=20 pseudoflow may have zero label value. If an incoming packet into a 6LSA no= de has a=20 zero label value and it is not a lead packet (see Section 6.7), it is assig= ned a non- zero label value before forwarding it. This is because in 6LSA, a zero lab= el is used=20 to indicate that the packet is part of a pseudoflow.=20 =20 The label is a part of the IPv6 header and not an extraneous, encapsulating= label=20 loaded on the packet. However, the value of the label may be transferred f= rom a=20 packet Flow Label field to a label field in layer 2 such as into an MPLS la= bel space,=20 if adequate label space is available, as the packet moves from a 6LSA domai= n to an=20 MPLS-enabled network domain or vice versa. In the case of ATM, the label v= alue may=20 be encoded in the VPI/VCI fields to extend the label and related FEC attrib= utes to=20 the ATM layer. =20 =20 The label from a flow in the 6LSA thus may be transferred to a non-6LSA net= work layer=20 or to a non-6LSA data link layer as long as there is a field available that= can carry=20 the 6LSA label. The particular encoding technique and its significance mus= t be=20 agreed by both the layers - layer 3, the network layer, and layer 2, the da= ta link=20 layer. Specifics of the method of this encoding are outside the scope of = this=20 document.=20 =20 =20 6.6 =0D=20 IPv6 Label Switching Router (6LSR)=20 =20 A router operating in the 6LSA is an IPv6 label switching router, called 6L= SR, which=20 performs as a minimum the two 6LSA functions of: 1) replacing (swapping) an= incoming=20 label in a packet with an outgoing label, and 2) forwarding the packet base= d on the=20 appropriate forwarding treatment. If the packet is not to be assigned to a= FEC, as=20 in the case when the packet exits a 6LSA network and if it is a subsequent = packet,=20 the non-zero label is removed and in its place the original non-6LSA label,= a zero=20 value label, is inserted as needed. =20 =20 A 6LSR is so called in this specification because other protocols, such as = the MPLS,=20 =0Cidentify a label switching router as an LSR which has different capabili= ties. This=20 helps avoid any ambiguity with the definition of LSR.=20 =20 A 6LSR is either an upstream 6LSR or downstream 6LSR =96 the relationship m= eans that=20 with respect to a given label binding, a particular label represents a spec= ific FEC=20 for packets traveling out of the former into a next-hop node or 6LSR, or in= to the=20 latter from a next-hop node or 6LSR. =20 =20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 10= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 6.7 =0D=20 Lead Packet=20 =20 A packet arriving at a 6LSA node is a lead packet if it is the first packet= of the=20 flow that this node has received. A lead packet may or may not be the firs= t packet=20 of the flow that the upstream router or 6LSR forwarded to this 6LSR. It is= possible=20 that the first packet in the flow is lost or misdirected, or for that matte= r, first=20 few packets in the flow are lost or misdirected. =20 =20 All lead packets, whether they are the first packet from the upstream route= r or 6LSR=20 or not, are treated like they were the first packet of the flow.=20 =20 Lead packet has no existing entry in the switching table of the 6LSR. All = lead=20 packets have a 0 (zero) label coming into the 6LSA nodes from a best-effort= network. =20 When source nodes are 6LSA nodes, lead packets may carry non-zero labels. = =20 =20 =20 6.8 =0D=20 Packet Identifier (PID) Field=20 =20 An identifier, called Packet Identifier (PID) is a field in the switching t= able=20 entry. The concept of switching table is later described in this specifica= tion (see=20 Section 6.9). This field is updated whenever a packet is received by 6LSR.= The PID=20 value entered is 0 (zero), if the packet is identified as a lead packet, if= it is 1=20 (one), the packet is a NTL or subsequent packet, that is, it is not a lead = packet.=20 =20 =20 6.9 =0D=20 Switching Table=20 =20 A switching table in 6SLA, often called the forwarding table in the network= ing=20 literature, comprises the following information as they become available:= =20 =20 =95 Label value from the lead packet, if there is a non-zero label, othe= rwise a=20 zero value is entered=20 =95 Packet Identifier (PID) Field value of 0 (zero) or 1 (one)=20 =95 Incoming interface, that is, interface on which the packet arrived= =20 =95 Packet=92s next hop=20 =95 Outgoing interface, that is, the interface on which the packet is fo= rwarded to=20 the next-hop 6LSR=20 =95 FEC value that identifies the forwarding operation that needs to be = performed=20 on a packet; this may include ordering and queuing of the packet prio= r to its=20 transmission=20 =20 The outgoing label entered in the switching table has to be unique so that = the 6LSR=20 is able to identify a unique LSP for the packet. An exception would be whe= n multiple=20 LSPs are merged. [This is discussed further in the following sections.]=20 =20 Additional information that may be available in the switching table is as f= ollows.=20 =20 =95 The data link layer and encapsulation to use=20 =95 How the label value needs to be encoded in the Flow Label field=20 =95 Timers associated with the packet =20 =95 Last packet in the flow=20 =95 Information with regard to how to discard labels or packets=20 =20 =0CThe format and content of the switching table entry are implementation a= nd=20 configuration specific and are not specified here. =20 =20 =20 6.10 =0D=20 Attributes of Label Binding=20 =20 The binding of a label to a FEC is based on known attributes of the packet = or on=20 externally applied constraints. The former may be one or more of the follo= wing:=20 Traffic Class, label value, source address, destination address, TCP/UDP po= rt number,=20 RTP value, one or more extension headers, special cookie marker in the pack= et, or=20 =20 =20 Chakravorty Expires - December 2004 [Page 11= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 special bit encoding in the body of the message past the protocol headers. = The=20 latter may be packet-forwarding parameters selected by the network administ= rator=20 apriori. For instance, if an attribute is a 1 Mbps bandwidth allocation to= a flow=20 then this allocation is taken care of in the forwarding treatment of the pa= cket=20 identified by the binding to the proper FEC.=20 =20 The binding of a label to a FEC is local to a 6LSR unless such binding is p= romulgated=20 across the network through some exterior means such as a using a label dist= ribution=20 protocol (LDP) commonly used for MPLS. LDP is outside the scope of this do= cument.=20 =20 The attributes of a label binding are configurable or encodable parameters = in the=20 6LSA. The details of how the attributes are activated will be presented in= a future=20 traffic engineering specification.=20 =20 =20 6.11 =0D=20 IPv6 Label Switched Path (6LSP)=20 =20 A label switched path in the 6LSA is called 6LSP and identifies a virtual c= ircuit=20 through which one or more flows are routed to the next-hop 6LSR. =20 =20 While a flow has a local, per-hop significance, a 6LSP has end-to-end, mult= iple-hop=20 significance within the 6LSA. A 6LSP is thus identified with a sequence of= 6LSAs,=20 such that the following characteristics are applicable:=20 =20 =95 R1, the ingress 6LSR, acquires a label and swaps it with the current= label in=20 packet P unless the packet is a lead packet;=20 =20 =95 For all values of i, where 1 < i < n+1, there is only one label in e= ach IPv6=20 packet, P, and this label value is encoded in the Flow Label field of= P;=20 =20 =95 At no time during P=92s transit through the network of 6LSRs within = a 6LSP, the=20 label value is not bound to a FEC, however, a FEC can be a best-effor= t delivery=20 FEC;=20 =20 =95 For all i, where 1 < i < n or 1 < i < n+1, Ri transmits P to R[i+1] = by using=20 the outgoing label in the packet (which is the same as the incoming l= abel value=20 in case of the lead packet);=20 =20 =95 For all i, 1 < i < n, if a system S receives and forwards P after P = is=20 transmitted by Ri and before P is received by R[i+1], the forwarding = decision=20 that S makes is not based on the specifications applicable to 6LSA as= =20 identified in this document; such forwarding decision will imply that= a layer 2=20 or other non-6LSA decision has been made outside the scope of this=20 specification;=20 =20 =95 Rn, the egress 6LSR, removes the incoming label and swaps it with th= e original=20 label (that the ingress 6LSR received) and forwards the packet out ba= sed on the=20 next-hop address unless there is penultimate 6LSR label swapping, in = which=20 case, Rn may forward the packet based on the FEC but without binding = the=20 outgoing label to the FEC. =20 =20 The sequence of 6LSA nodes, more accurately, the sequence of node interface= s through=20 which P is transported represents a 6LSP. A 6LSP is thus represented by a = label=20 between any two nodes, and by one or more sequence of labels between ingres= s and=20 egress 6LSRs, or between two or more hosts, or any combination thereof. = =20 =0C=20 Conversely, it also represents the FEC binding of each flow in each of the = 6LSR on=20 the 6LSP. In this regard, 6LSP closely resembles a virtual circuit (VC) in= ATM, and=20 LSP in MPLS. =20 =20 =20 =20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 12= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 |L=20 | =20 +-+-+ =20 | |=20 +------------------+ D +---------------+ = =20 Non-6LSA | | | | =20 | 6LSA +-+-+ |=20 | domain | | =20 | | |=20 | |L2 (LSP) | =20 | | |=20 +-+-+ L1 (LSP) +-+-+ +-+-+=20 L | +----------------+ | | |=20 ------+ | L2 (LSP) | | L6 (LSP) | | L=20 ----> ------+ A +----------------+ B +-------------+ E +--->=20 ------+ | L3 (LSP) | | | | =20 | +----------------+ | | |=20 +-+-+ +-+-+ +-+-+ =20 | | |=20 | |L2 (LSP) | =20 | | | =20 | | | =20 | +-+-+ |=20 | | | |=20 +------------------+ C +---------------+ = =20 | | =20 +-+-+ =20 |=20 |L=20 =20 Representation of 6LSPs inside a 6LSA=20 Figure 1. =20 =20 =20 A representative 6LSA layout is shown in Figure 1. In this layout, labels = are=20 encoded in the Flow Label field of the outgoing packets that are not lead p= ackets,=20 out of the ingress 6LSR, A, the intermediate 6LSR, B, and removed only at t= he egress=20 6LSRs, C, D and E when the flow of packets is from west to east. The proce= ss is=20 similar for the flows entering into the four border 6LSRs, A, C, D, and E i= n the=20 opposite direction and for intermediate 6LSR. =20 =20 There can be many ingress, intermediate and egress 6LSRs in a 6LSA. =20 =20 Multiple 6LSPs may merge at a 6LSR if they can be identified with the same = FEC and=20 their outgoing route (6LSP) is the same in that they can terminate on the s= ame next- hop 6LSR interface. =20 =20 If there are no other egress routers but E, in the representative configura= tion shown=20 in Figure 2, the flows coming on three 6LSPs represented by L1, L2, and L3 = into B are=20 merged and sent out on one 6LSP represented by L6. In this case, the flows= maintain=20 their identity by their source and destination addresses even if their outg= oing=20 labels are the same on 6LSP. =20 =20 This is also true of the lead packet flows where labels out of A would be a= ll of 0=20 (zero) value.=20 =20 =0C=20 =20 =20 +--------------------------------------+ =20 Non-6LSA domain | | =20 | 6LSA domain |=20 | | =20 =20 =20 Chakravorty Expires - December 2004 [Page 13= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 | |=20 | |=20 +-+-+ L1 (LSP) +-+-+ +-+-+=20 L | +----------------+ | | |=20 ------+ | L2 (LSP) | | L6 (LSP) | | L=20 ------+ A +----------------+ B +-------------+ E +---=20 ------+ | L3 (LSP) | | | | =20 | +----------------+ | | |=20 +-+-+ +-+-+ +-+-+ =20 | | =20 | |=20 +--------------------------------------+ =20 =20 =20 Representation of 6LSPs inside a 6LSA=20 Figure 2.=20 =20 =20 Each 6LSP is maintained at least for the duration of the session of transpo= rt of all=20 packets in a flow. In 6LSA, labels may be maintained for a pre-determined = time after=20 a session has ceased to exist, that is, for a fixed amount of time determin= ed apriori=20 after packets belonging to a flow have ceased to arrive. =20 =20 A 6LSP may extend all the way to the end-system if the end-system is operat= ing within=20 the 6LSA.=20 =20 =20 7. =0D=20 6LSA Functionalities=20 =20 This section provides details of 6LSA functionalities including label acqui= ring,=20 label binding to FEC, and label swapping.=20 =20 =20 7.1 =0D=20 Label Assignment=20 =20 In the 6LSA, the decision to assign or bind a label to a particular FEC is = made by a=20 6LSA node, generally the ingress 6LSR if it is the origination point for th= at flow =96=20 in this case the flow is a pseudoflow by definition. The host or 6LSR node= then=20 informs the next-hop, downstream node of this binding via the labeled IPv6 = packet=20 that is transmitted or via some other method depending on the nature of lab= el=20 generation and distribution methodologies. =20 =20 The 6LSA incorporates three models for acquiring label space. The first mo= del=20 specifies locally generated labels; the second model refers to label distri= bution,=20 and the third, acquires labels from the Flow Labels available in the incomi= ng packet=20 headers. Only one of these three models of label assignment is allowed in = a network=20 of 6LSA-based nodes. =20 =20 Once a label binding is available, the 6LSA requires that the label binding= be=20 retained for the duration of the session. =20 =20 It is quite possible that multiple flows may require the same label and lab= el binding=20 to a single FEC. In these cases, all such flows may be multiplexed togethe= r as one=20 outgoing flow and forwarded on one 6LSP using the same label. At the de-mu= ltiplexing=20 =0C6LSA node downstream, the flows must be discernible through the unique s= ource and=20 destination addresses or through other means. =20 =20 The 6LSA does not prevent any 6LSA node from storing any label generated at= a time=20 different from when it is being used nor does the 6LSA prevent a node from = using any=20 label that was used earlier or gotten from a flow that used an algorithm or= a model=20 other than those specified here. The three models for label generation in = this=20 document are detailed below.=20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 14= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 =20 7.1.1 Locally Generated Label Model =20 =20 In this model, 6LSA allows a node to generate its own labels to be used in = the IPv6=20 header. The specification for the algorithm(s) used to generate the 20-bit= labels is=20 beyond the scope of this document. An example algorithm for generating flow= labels is=20 a pseudorandom number generator outputting values within the parameters alg= orithm in=20 which the bit field values are within the parameters specified in Section 6= .1, Label. =20 =20 The Locally Generated Label model does not preclude manual generation of a = label or=20 range of labels through a configurator or similar other means. The locally= generated=20 label may have a value related to one or more attributes that is applicable= to the=20 next-hop 6LSR or nodes across the network. =20 =20 The 6LSA specification allows labels that are locally generated but may hav= e non- local significance. Such attributes may be regularly or randomly refreshed= by any=20 network management or other systems. Methodologies for such refreshment ar= e outside=20 the scope of this specification. =20 =20 The model is not a mandatory part of 6LSA, i.e., a node is not required to = implement=20 the Locally Generated Label Model mechanism in order to be considered 6LSA-= compliant. =20 However, when a 6LSA node claims to implement the Locally Generated Label M= odel, the=20 implementation must conform to the specification given in this document. = =20 =20 This document encourages the use of this model because it is simple, effici= ent and=20 avoids control plane traffic such as that present in the Distributed Label = Model. =20 The Locally Generated Label Model enhances security since the labels have l= ocal=20 significance only and can be randomly or periodically refreshed all through= the 6LSA=20 domain prior to their use.=20 =20 7.1.2 Distributed Label Model=20 =20 The 6LSA allows distribution of label space generated in one or more nodes = or=20 externally in a server. The architecture also allows more than one label= =20 distribution protocol and sharing of necessary information amongst the labe= l=20 distribution peers. Current protocols that allow a 20-bit label distributi= on and do=20 not violate any of this 6LSA specifications with regard to use of such labe= ls and the=20 operation of 6LSA nodes are allowed. The specifics of label distribution p= rotocols=20 are outside the scope of this document. =20 =20 How label binding is distributed when applicable in the 6LSA and how a node= binds a=20 label to a FEC are outside the scope of this document. The flows generated= by the=20 6LSA nodes using this model do not meet the definition of flow as specified= in [2]=20 and [3]. =20 =20 7.1.3 Reuse Label Model=20 =20 The 6LSA allows a node to reuse existing label available in the node or obt= ained from=20 labels in the incoming packets and where the flows can be associated with u= nique=20 label bindings. =20 =20 This label model is not recommended for large 6LSA domains; in large domain= s=20 undesirable duplication of labels can occur. This model requires a single-= bit field,=20 the MSB field, in the label to represent the identity of the packet as the = lead=20 packet or non-lead packet. It is similar to the PID value in the switching= table. =20 In the model, if the =93PID-representative=94 bit is 0 (zero), the packet i= s a lead=20 =0Cpacket and if it is 1 (one), the packet is not a lead packet but a NTL o= r subsequent=20 packet. This bit assignment requires IANA registration which has not been = done for=20 this specification. This bit assignment potentially reduces the number of = 6LSPs=20 between two peering nodes to one half of a million from a million.=20 =20 Details of this model remain to be developed for future specification.=20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 15= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 =20 7.2 =0D=20 Scope and Uniqueness of Labels=20 =20 A label in a packet on a 6LSP must be unique to a flow, in any given direct= ion,=20 between interfaces on peering nodes that are one hop apart. =20 =20 A flow always originates at the upstream source node in the 6LSA domain, co= ntinues=20 through multiple 6LSRs and terminates in the destination node which also mu= st exist=20 in the 6LSA. Such a flow must carry a non-zero label in its lead packet. = =20 =20 A pseudoflow, on the other hand, originates at an upstream 6LSA node, which= may be a=20 6LSR, continues to the next-hop node and terminates there. This next-hop n= ode may=20 also be a 6LSR. The lead packet in a pseudoflow carries a 0 (zero) label.= =20 =20 For the example shown in figure 3, an upstream 6LSA node, A, may bind a lab= el L1 to=20 FEC X for a flow to a downstream node, B, and B may use the same label, L1,= or a=20 different label (not shown) to identify a return flow Y from B to A, while = at the=20 same time A may bind another label L2 to FEC X for a different flow to node= , C, which=20 in turn may bind label L1 to FEC X for a flow to node D and label L2 to FEC= X to=20 another node E. =20 =20 =20 =20 | =20 |=20 +-+-+ +---+ =20 L1 | |L1/X --> | | =20 --------------------------+ A +-----------------+ B |----=20 | |<-- L1/Y | | =20 +-+-+ +---+ =20 | =20 |L2/X =20 |=20 |=20 +---+ +-+-+ +---+=20 L4 | | L1/X | |L2/X | |=20 -------+ D +-----------------+ C +-----------------+ E +----=20 | | | | | |=20 +---+ +-+-+ +---+=20 =20 =20 Unique Labels for Unique Flows=20 Figure 3.=20 =20 =20 Conversely, a given upstream node, A, may bind label L to FEC F1 and then t= o FEC F2=20 so long as these FECs represent flows to different downstream nodes, in thi= s case, B=20 and C. See Figure 4 below.=20 =20 =20 =20 =20 =20 =20 =20 =0C=20 =20 =20 | =20 |=20 +-+-+ +---+ =20 L | |L/F1 | | =20 --------------------------+ A +-----------------+ B +----=20 =20 =20 Chakravorty Expires - December 2004 [Page 16= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 | | | | =20 +-+-+ +---+ =20 |L/F2=20 | =20 | =20 |=20 |=20 |=20 +---+ +-+-+ +---+=20 L | | L/F2 | |L/F2 | |=20 -------+ D +-----------------+ C +-----------------+ E +----=20 | | | | | |=20 +---+ +-+-+ +---+=20 =20 Same Label in Multiple Flows=20 Figure 4.=20 =20 =20 However, two upstream nodes, A and C, may bind label L to FEC F1 and also t= o FEC F2=20 for two different flows to the same downstream node, B, provided B is able = to=20 determine that the two flows are different otherwise the 6LSA requires that= the=20 upstream 6LSR not bind the same label to two different flows to the same ne= xt-hop=20 6LSR. See Figure 5 below, in this case the downstream 6LSR is able to dete= rmine that=20 the two flows are different. What applies to two flows also applies to more= than two=20 flows.=20 =20 =20 +---+ +---+ =20 | | | | =20 ------+ A | | C +------=20 ____ | | | | =20 +-+-+ +-+-+ =20 | | =20 | | L/F2 =20 | +---------+=20 | | =20 | +-+-+ =20 | L/F1 | | =20 +--------------------+ B +----=20 | | =20 +-+-+ =20 =20 Same Label for Multiple Flows into Different Interfaces=20 Figure 5.=20 =20 =20 Multiple flows from upstream 6LSRs may bind label L to multiple FECs F1, F2= , F3,=20 etc., for multiple flows as shown in Figure 6, or to the same FEC F for mul= tiple=20 flows. The 6LSR B binds one label to all the outgoing flows to the downstr= eam 6LSR=20 C. This is called flow merging. In this case, C is not able to determine o= n its own=20 that multiple flows from B are different because they carry the same label = and arrive=20 on the same interface. The differentiation is possible if the downstream 6= LSR can=20 identify the uniqueness of the flows through source and destination address= es, if an=20 extraneous label distribution protocol such as LDP is used, or if the 6LSA = locally=20 distributed label model carries a specific lead packet identifier bit, such= as the=20 PID-representative bit as in the Reuse Label model. =20 =0C=20 =20 =20 | =20 | =20 |L/F4=20 +---+ +-+-+ +---+=20 =20 =20 Chakravorty Expires - December 2004 [Page 17= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 | | L/F1, F2, F3--> | | | |=20 -----+ +-----------------+ |L/F5--> | +----=20 -----+ A +-----------------+ B +-----------------+ C +----=20 -----+ +-----------------+ | | +----=20 | | | | | |_ =20 +---+ +-+-+ +---+ = =20 =20 =20 Merging Flows=20 Figure 6.=20 =20 =20 7.3 =0D=20 Label Retention Mode=20 =20 If a 6LSR B receives a label binding from a 6LSR A for a particular FEC via= an LDP,=20 even though B is more than one hop apart from A, then such binding may be r= etained or=20 discarded by B. If the binding is retained, then this binding may be used = later when=20 A becomes a next hop 6LSR to B. If the binding is discarded, then B will h= ave to=20 acquire a new binding for traffic from A through one of the three models de= scribed in=20 Section 6.5. =20 =20 =20 7.4 =0D=20 Packet Forwarding=20 =20 Whatever the incoming label, unless the label carries some special signific= ance=20 because of certain bit arrangement in the label or some parameters associat= ed with=20 the label that were configured apriori, the forwarding treatment of the lab= el is of=20 local significance and decided by the 6LSA node itself. This treatment may= or may=20 not be the same the packet receives in any other node. The 6LSP chosen for= the=20 packet is thus based on the local FEC. The nature of the forwarding treatm= ent and=20 how it is applied is out of scope for this document. The only exception to= this rule=20 may be a case when a label value is assigned globally, by policy for exampl= e.=20 =20 =20 7.5 =0D=20 Label Stacking=20 =20 The 6LSA does not allow label stacking. There is only one label in a packe= t and this=20 label must be in the Flow Label field in the IPv6 packet header. The 6LSA = allows=20 multiple label spaces per platform however the use of the label must confor= m to the=20 specifications here in this document.=20 =20 =20 7.6 =0D=20 Label Swapping=20 =20 Label swapping or switching is a process in which the incoming label in a p= acket is=20 replaced with an outgoing label. In this document, this process is associa= ted with=20 multiple other activities elaborated below. These activities include match= ing=20 switching table entries with certain incoming packet header fields, binding= a label=20 to the FEC, updating the switching table and forwarding the packet. Howeve= r, when=20 the swapping involves only incoming label replacement with an outgoing labe= l, it is=20 called label switching, which is typically is fast process and may be carri= ed out in=20 the interface card itself.=20 =0C=20 =20 7.7 =0D=20 Packet Processing Algorithm=20 =20 The 6LSA packet processing algorithm includes handling packets that arrive = from the=20 ouside networks into the 6LSA domain or when they arrive from hosts in the = same 6LSA=20 domain. The 6LSA domain processing provides QoS priority handling or such = other=20 treatment that the packets need.=20 =20 In this section, the sequence of basic steps needed for processing a packe= t inside=20 6LSA is detailed. =20 =20 =20 Chakravorty Expires - December 2004 [Page 18= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 =20 The simplest 6LSA domain consists of three nodes: the source node or ingres= s 6LSR,=20 one destination node or egress 6LSR, and one 6LSR in between, the intermedi= ate 6LSR. =20 In the next, more complex network configuration, there are four or more nod= es with=20 two or more intermediate 6LSRs. =20 =20 The incoming flows into any of the nodes can arrive on one or more 6LSPs. = If the=20 outgoing flows are merged onto the same 6LSP, the downstream node receives = the merged=20 flow with the same label and the flow arrives on the same interface. Since= there is=20 no label stacking in 6LSA, there is no inherent advantage in flow merging. = =20 Packets from different flows when merged into a single flow will still have= different=20 source and destination addresses, and distinction between flows thus can be= made by=20 the source and destination addresses when the merged flow arrives at a down= stream=20 node. =20 =20 If the incoming flows arrive on different 6LSPs and thus on different inter= faces,=20 then flows can be distinguished by their labels and/or by incoming interfac= es. As=20 the complexity grows, there may be a combination of incoming flows represen= ting=20 different LSPs =96 merged and non-merged. =20 =20 In each step of packet processing, there are activities that are related to= the=20 components of the IPv6 header in addition to the Flow Label. One such comp= onent is=20 the Hop Limit that is incremented every time a packet passes through a node= in the=20 6LSA. Additionally, if the packet has header extensions, such as Hop-by-Ho= p or=20 Routing Header, they are processed as in the conventional IPv6 routing envi= ronment. =20 Such extensions may be represented in the FEC.=20 =20 Recall that a 6LSA node must use only one label model at any time, for exam= ple, if it=20 is using the Distributed Label Model, it must not use the Locally Generated= Label=20 Model.=20 =20 7.7.1 Packet Processing in Locally Generated Label Model=20 =20 The key considerations of packet processing in this model are as follows:= =20 =20 =95 A 6LSA domain network peers with one or more other networking domain= s such that=20 all packets into and out of 6LSA domains carry 0 (zero) labels.=20 =20 =95 Within a 6LSA domain, a source node may generate one or more unique = labels and=20 forward all packets with one, unique label for a given flow, or may f= orward=20 lead packet with the locally generated 0 (zero) label and the NTL and= =20 subsequent packets with the unique label, the former is defined as a = flow,=20 while the latter, a pseudoflow in this specification.=20 =20 =95 If the lead packet from an upstream node is lost before reaching the= next-hop=20 6LSR, then the NTL packet with a non-zero label will be treated by th= e=20 downstream 6LSR as the lead packet and forwarded with the same incomi= ng non- zero label. =20 =20 =95 If a lead packet with a 0 (zero) label in a flow is forwarded to a n= ext-hop=20 6LSR different from the one to which the NTL and subsequent packets f= rom the=20 same flow (such all packets having the same source and destination ad= dresses)=20 are forwarded to, then two scenarios are possible. If the lead packe= t shows up=20 before the NTL packet in the downstream 6LSR, then the forwarding pro= cess will=20 be as specified here. However, if the lead packet shows up after the= NTL or=20 subsequent packet, then the lead packet is processed as a lead packet= while the=20 =0C NTL packet is also processed as a lead packet but with its non-zer= o label. =20 Based on the flow characteristics and label bindings, the 6LSR howeve= r may=20 provide the same forwarding treatment to both flows and thus forward = the=20 packets out the same interface over the same 6LSP. If this is an egr= ess 6LSR,=20 the outgoing label will be zero in all the packets. =20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 19= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 =95 If a lead packet with a non-zero label in a flow is forwarded to a n= ext-hop=20 6LSR different from the one to which the NTL and subsequent packets f= rom the=20 same flow (such all packets having the same source and destination ad= dresses)=20 are forwarded to, then two scenarios are possible here as well. If t= he lead=20 packet shows up before the NTL packet in the downstream 6LSR, then th= e=20 forwarding process will be as specified here. However, if the lead p= acket=20 shows up after the NTL or subsequent packet, then the lead packet is = processed=20 as an NTL or subsequent packet while the NTL packet is processed as a= lead=20 packet all with the same non-zero label. Based on the flow character= istics and=20 label bindings, the 6LSR however may provide the same forwarding trea= tment to=20 both the incoming flows and thus forward the packets out the same int= erface=20 over the same 6LSP. If this is an egress 6LSR, the outgoing label wi= ll be zero=20 in all the packets. =20 =20 =95 If there is a match for the incoming label and interface in the swit= ching=20 table, then the incoming label is swapped with the outgoing label fro= m the=20 switching table. The PID value in the switching table is updated to = 1 (one) if=20 it was 0 (zero). =20 =20 =95 In the egress 6LSR peering with some other network router, FEC does = not exist=20 since the packets are transmitted out to the other network; the packe= ts are=20 forwarded based on the next-hop address.=20 =20 =95 If packets carrying non-zero labels arrives from an external, non-6L= SA domain=20 into the 6LSA domain, either erroneously or maliciously, the 6LSA dom= ain does=20 not guarantee the forwarding of such packets with the incoming label = via its=20 domain out to the same or other external domain unless the label bind= ing is=20 available apriori to the egress 6LSR. If this is not the case, the 6= LSA domain=20 may forward the packet with a zero-label from the egress 6LSR. This = may by=20 default enhance security of the overall end-to-end networking. =20 =20 In the following paragraphs, the packet processing in three different types= of 6LSA=20 nodes is detailed for non-merging and merging flows.=20 =20 7.7.1.1 Packet Processing Example=20 =20 For an understanding of the process of label switching, a relatively simple= =20 configuration is used, see Figure 7 in which pseudoflows, called flows in t= his=20 description for simplicity, originate in each of the upstream node and term= inate in=20 the next-hop, downstream node. =20 =20 =20 +-----------------------------------------------------+=20 | |=20 | |=20 | Ingress Intermdt. Egress |=20 | 6LSR 6LSR 6LSR |=20 | +-------+ +-------+ +-------+ |=20 | | | | | | | | =20 ---|--+ +----------+ +----------+ +----|---=20 | | A | | C | | B | | =20 ---|--+ +----------+ +----------+ +----|---=20 | | | | | | | |=20 | +-------+ +-------+ +-------+ | =20 | |=20 | |=20 =0C | | =20 +-----------------------------------------------------+=20 =20 Packet Processing=20 Figure 7.=20 =20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 20= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 Representative packet flows and switching table entries are given in the ta= ble in=20 Figure 8. In the table, for each packet in each switching table entry colu= mn, 0=20 (zero) and Ln are the label values in the top row, Sn and Dn are the source= and=20 destination addresses in the bottom row, and 0 (zero) and 1 (one) are the P= ID values=20 in the middle row. The values in the incoming, transiting and outgoing pac= ket=20 columns below indicate incoming label, and source and destination address v= alues. =20 All packets are arriving into A from a non-6LSA, best effort domain and goi= ng out of=20 C into a non-6LSA and therefore all packets have 0 (zero) label.=20 =20 =20 ----------------------------------------------------------------------_ = _ =20 | | | | | |=20 Incoming |Swtchg.|Transiting|Swtchg.|Transiting|Swtchg.| Outgoing=20 Packet | Table | Packet | Table | Packet | Table | Packet=20 | Entry | | Entry | | Entry |=20 ----------------------------------------------------------------------=20 First Flow --------->=20 =20 | | | | | |=20 0 |0 L1| 0 |0 L2| 0 |0 0| 0=20 Lead Pkt --> | 0 |--------->| 0 |--------->| 0 |----> =20 S1,D1 | S1,D1 | S1,D1 | S1,D1 | S1,D1 | S1,D1 |S1,D1=20 | | | | | | =20 =20 =20 | | | | | |=20 0 |0 L1| L1 |L1 L2| L2 |L2 0| 0=20 NTL Pkt ---> | 1 |--------->| 1 |--------->| 1 |----> =20 S1,D1 | S1,D1 | S1,D1 | S1,D1 | S1,D1 | S1,D1 |S1,D1=20 | | | | | | =20 =20 | | | | | |=20 0 |0 L1| L1 |L1 L2| L2 |L2 0| 0=20 Sub. Pkt---> | 1 |--------->| 1 |--------->| 1 |----> =20 S1,D1 | S1,D1 | S1,D1 | | S1,D1 | S1,D1 |S1,D1=20 | | | | | | =20 =20 =20 All other packets in this flow have the same characteristics.=20 =20 ----------------------------------------------------------------------=20 Second Flow --------->=20 =20 | | | | | |=20 0 |0 L3| 0 |0 L4| 0 |0 0| 0=20 Lead Pkt --->| 0 |--------->| 0 |--------->| 0 |-----> =20 S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 =20 | | | | | | =20 =20 =20 | | | | | |=20 0 |0 L3| L3 |L3 L4| L4 |L4 0| 0=20 NTL Pkt ---> | 1 |--------->| 1 |--------->| 1 |-----> =20 S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2=20 | | | | | | =20 =20 =0C | | | | | |=20 0 |0 L1| L3 |L3 L4| L4 |L4 0| 0=20 Sub. Pkt--->| 1 |--------->| 1 |--------->| 1 |-----> =20 S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2 | S2,D2=20 | | | | | | =20 =20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 21= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 All other packets in this flow have the same characteristics; following flo= ws are=20 similar to this flow.=20 ------------------------------------------------------------------------=20 ------------------------------------------------------------------------=20 =20 Label Swapping for Non-Merging Flows=20 Figure 8.=20 =20 The following observations represent the packet processing in Figure 8. = =20 =20 The label in the lead packet of a flow is not swapped in any of the 6LSRs r= egardless=20 of its label. The PID value in the switching table is 0 (zero) for the lea= d packet. =20 The 6LSR acquires a label, binds the lead packet label to a FEC and makes a= n entry in=20 the 6LSR switching table for the incoming label as well as the acquired lab= el for=20 this flow, incoming interface (the physical port or link on which the packe= t arrived=20 =96 not shown), outgoing interface (not shown), source and destination addr= esses, and=20 the FEC (not shown). The outgoing interface, that is, the physical port or= link on=20 which the packet has to be transmitted out is determined from the IPv6 rout= ing table,=20 FEC or other similar means, and entered into the switching table. How the = 6LSR=20 determines the best interface for the given FEC is outside the scope of thi= s document=20 and will be specified in future work.=20 =20 The label in each NTL packet, as well as the label in each packet thereafte= r is=20 swapped with an outgoing label, meaning, the incoming label is replaced wit= h a=20 unique, acquired label. This label is the same in all outgoing packets for= the same=20 flow irrespective of whether the outgoing label is acquired through Locally= Generated=20 Label Model or through some other means. =20 =20 The label entry may be flagged for the way the label was acquired by the 6L= SR,=20 however, such flagging is outside the scope of this specification. After t= he label=20 is swapped, the 6LSR binds the label to the FEC and applies the forwarding = treatment=20 for that FEC. The labeled packet is forwarded out of the interface that is= =20 determined by the applicable routing protocol.=20 =20 7.7.1.2 Algorithm for Non-Merging Flows=20 =20 The following steps describe the operations of this algorithm. The algorit= hm changes=20 for the 6LSA in which all nodes, that is, the source and destination nodes = as well as=20 all 6LSRs, exist in the 6LSA domain. In this case, lead packets from the s= ource node=20 may carry non-zero labels. When such packets arrive at the first 6LSR, the= latter=20 can determine they are lead packets, and maintains the label. So does all = other=20 intermediate 6LSRs. The last 6LSR, one hop upstream of the destination nod= e,=20 maintains this label also since the next node, the destination node is in t= he 6LSA=20 domain.=20 =20 a) Ingress 6LSR: when a packet arrives on an interface, match source and d= estination=20 addresses in the incoming packet with those in the switching table.=20 =20 i) If there is no match, this is a lead packet; acquire an outgoing labe= l, bind=20 the outgoing label to the pre-selected FEC for this flow, make switc= hing=20 table entry for this packet including the labels and the PID value o= f 0=20 (zero), and forward the packet out; there is no swapping of incoming= with the=20 outgoing label.=20 =20 ii) If there is a match, and the PID value is 0 (zero) in the switching t= able,=20 this is an NTL packet in the flow. Swap the incoming label with the= outgoing=20 =0C one in the switching table, set the PID to 1 (one), and forward t= he packet=20 out.=20 =20 iii)If there is a match and the PID value is 1 (one) in the switching tab= le, this=20 is the third or later packet, that is, a subsequent packet in the fl= ow,=20 switch the incoming label with the outgoing label and forward the pa= cket.=20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 22= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 b) Intermediate 6LSR: when a packet arrives on an interface, match the inc= oming=20 label and interface with those in the switching table.=20 =20 i) If there is no match, this is a lead packet; acquire an outgoing labe= l, bind=20 the outgoing label to the pre-selected FEC for this flow, make switc= hing=20 table entry for this packet including the labels and the PID value o= f 0=20 (zero) and forward the packet out with the incoming label; there is = no=20 swapping of labels.=20 =20 ii) If there is a match for only the incoming label, i.e., if no outgoing= label=20 exists, then this is a lead packet; acquire an outgoing label, bind = the=20 outgoing label to the pre-selected FEC for this flow, make switching= table=20 entry for this packet including the labels and the PID value of 0 (z= ero) and=20 forward the packet out; there is no swapping of labels.=20 =20 iii)If there is a match, for both the label and the interface, this is an= NTL or a=20 subsequent packet in this flow. Switch the incoming label with the = outgoing=20 label and forward the packet out.=20 =20 c) Egress 6LSR: when a packet arrives on an interface, match the incoming = label and=20 interface with those in the switching table.=20 =20 i) If there is no match, this is a lead packet, look up the next-hop rou= te and=20 make switching table entry for this packet including the label includ= ing the=20 PID value of 0 (zero) and the route for the outgoing packet, and forw= ard the=20 packet out; there is no label binding, and there is no swapping of in= coming=20 with the outgoing labels if the incoming label is 0 (zero) otherwise = swap the=20 incoming label with 0 (zero) label for the peering best-effort networ= k.=20 =20 ii) If there is a match for only the incoming label and not the interface= , then=20 this is a lead packet; look up the next-hop route and make switching = table=20 entry for this packet including the label, the PID value of 0 (zero) = and route=20 for the outgoing packet, and forward the packet out; there is no swap= ping of=20 labels if the incoming label is 0 (zero) otherwise swap the incoming = label=20 with 0 (zero) label for the peering best-effort network.=20 =20 iii)If there is a match for both the label and interface in the same entr= y, this=20 is an NTL or a subsequent packet in this flow; switch the incoming la= bel with=20 0 (zero) label and forward the packet out for the peering best-effort= network=20 based on the next-hop route from the switching table.=20 =20 7.7.1.3 Algorithm for Merging Flows=20 =20 Packets arriving at a downstream 6LSA node that belong to different flows b= ut have=20 the same label and arrive on the same interface are said to belong to a mer= ged flow. =20 Such packets cannot be differentiated by the downstream node without the ap= riori=20 knowledge of how the flows were merged in the upstream 6LSR or through some= other=20 means.=20 =20 The following steps describe the operations of the algorithm when the flows= out of=20 the upstream 6LSR are merged and forwarded as a single flow to the next-hop= 6SLR.=20 =20 a) Ingress 6LSR: when a packet arrives on an interface, match source and d= estination=20 addresses in the incoming packet with that in the switching table. The= matching=20 by source and destination addresses identifies the uniqueness of the fl= ow.=20 =20 =0Ci) If there is no match, this is a lead packet; acquire an outgoing lab= el which is=20 unique for the outgoing interface, bind the outgoing label to the pre-selec= ted FEC=20 for this flow, make switching table entry for this packet including the lab= els and=20 the PID value of 0 (zero) for the outgoing packet and forward the packet ou= t; there=20 is no swapping of incoming with the outgoing labels.=20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 23= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 ii) If there is a match, and the PID value is 0 (zero) in the switching ta= ble, this=20 is an NTL packet in the flow, swap the incoming label with the outgoing one= in the=20 switching table, increment the PID to 1 (one), and forward the packet out.= =20 =20 iii) If there is a match and the PID value is 1 (one) in the switching tab= le, this a=20 subsequent packet in the flow, switch the incoming label with the outgoing = label and=20 forward the packet out.=20 =20 b) Intermediate 6LSR: when a packet arrives on an interface, match the inc= oming=20 label and interface with those in the switching table.=20 =20 i) If there is no match, this is a lead packet; acquire an outgoing label = which is=20 unique, bind the outgoing label to the pre-selected FEC for this flow, = make=20 switching table entry for this packet including the labels and the PID = value of=20 0 (zero) and forward the packet out and forward the packet out; there i= s no=20 swapping of incoming with the outgoing labels.=20 =20 ii) If there is a match for the incoming label and not the incoming interfa= ce, and=20 the PID value is 0 (zero) in the switching table, then this is a lead p= acket;=20 acquire an outgoing label, bind the outgoing label to the pre-selected = FEC for=20 this flow, make switching table entry for this packet including the lab= els and=20 the PID value of 0 (zero) for the outgoing packet and forward the packe= t out;=20 there is no swapping of incoming with the outgoing labels.=20 =20 iii) If there is a match for both the label and the interface in the same e= ntry, this=20 is an NTL or a subsequent packet in this flow or another flow (if the u= pstream=20 6LSA node is merging flows), find a match for the source and destinatio= n=20 addresses =96=20 =20 =AD If there is a match, this is an NTL or a subsequent packet; acquire a= unique=20 outgoing label, bind the outgoing label to the pre-selected FEC for thi= s flow,=20 make switching table entry for this packet including the labels and the= PID value=20 to 1 (one) if it was a 0 (zero) and forward the packet out after swappi= ng=20 incoming label with the outgoing label.=20 =20 =AD If there is no match, this is a lead packet and the operations are th= e same as=20 described before for the lead packet.=20 =20 c) In the egress 6LSR, when a packet arrives on an interface, match the in= coming=20 label and interface with those in the switching table.=20 =20 i) If there is no match, this is a lead packet, look up the next-hop route= and make=20 switching table entry for this packet including the label, the PID valu= e of 0=20 (zero), and route for the outgoing packet, forward the packet out; swap= the=20 incoming label with 0 (zero) outgoing label if the incoming label is no= n-zero.=20 =20 ii) If there is a match for only the incoming label and not the interface, = and the=20 PID value is 0 (zero) in the switching table, then this is a lead packe= t; look=20 up the next-hop route and make switching table entry for this packet in= cluding=20 the label, the PID value of 0 (zero), and route for the outgoing packet= , forward=20 the packet out; swap the incoming label with the 0 (zero) outgoing labe= l if the=20 incoming label is non-zero.=20 =20 iii)If there is a match for both the label and the interface in the same en= try, then=20 this is an NTL or a subsequent packet in this flow or another flow (if = the=20 upstream 6LSR is merging flows). Find matches for the source and desti= nation=20 =0C addresses =96=20 =20 o If there is a match of the addresses, this is a next-to-lead or subsequ= ent=20 packet; increment the PID to 1 (one) and forward the packet out after s= wapping=20 incoming label with a 0 (zero) label.=20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 24= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 o If there is no match, this is a lead packet and the operations are the = same as=20 described before for a lead packet.=20 =20 7.7.2 Packet Processing in Reuse Label Model=20 =20 Packet processing in this model is similar to that in the above packet proc= essing=20 description for the Locally Generated Label Model. The main difference is = that in=20 the label, the PID-representative bit is 0 (zero) when the packet is proces= sed as a=20 lead packet and 1 (one), when the packet is processed not as a lead packet.= =20 =20 7.7.3 Packet Processing in the Distributed Label Model=20 =20 Packet processing in this model is out of scope of this specification. Thi= s if for=20 future work and specification.=20 =20 7.8 =0D=20 Fast Switching=20 =20 When a 6LSR can simply swap an incoming label with an outgoing label withou= t going=20 through insertion of new entry in the switching table for that packet, then= this=20 swapping is termed fast switching in this specification.=20 =20 7.9 =0D=20 FEC Mapping=20 =20 Each FEC may map to a set of flows, node and route characteristics which ma= y be=20 represented in the switching table. The switching table may consist of mor= e than one=20 entry that a particular FEC can be mapped to and forwarded via a labeled pa= cket. =20 =20 7.10 =0D=20 Penultimate 6LSR Label Processing=20 =20 If the label in a non-lead packet is acquired through the Locally Generated= Label=20 model and not through other means and applied to a packet in the 6LSR upstr= eam of the=20 penultimate 6LSR, the latter being the 6LSR one hop upstream of the egress = 6LSR, the=20 penultimate 6LSR may decide to not bind the label to the FEC for this flow = but simply=20 insert it in the packet and forward the packet out since the next hop is no= t affected=20 by the absence of any prior label binding. The egress 6LSR forwards the pa= cket out=20 based on the outgoing route. This saves processing related to binding at a= minimum.=20 =20 7.11 =0D=20 Invalid Incoming Labels=20 =20 An incoming or acquired label is invalid if it has a value that does not al= low the=20 6LSA node to bind the label to a FEC. Such a label may be discarded after = the lead=20 packet is forwarded in a pseudoflow. Invalid labels may not include a zero= -labeled=20 packet.=20 =20 7.11.1 LSP Control: Ordered and Loose=20 =20 As described in the MPLS label switching architecture [1], some FECs corres= pond to=20 address prefixes which are available from dynamic routing algorithm running= in a=20 node. There are two methods in 6LSA for setting up LSPs for these FECs: Or= dered and=20 Loose. The control of LSP is a local function at a 6LSA node. In 6LSA, ea= ch FEC is=20 identified with a set of attributes. =20 =20 =0CIf the traffic in a particular FEC has to follow the same path that has = a specified=20 set of attributes such as bandwidth and other resources (QoS parameters) et= c., then=20 ordered control must be used. How this ordered control is initiated and ma= intained=20 is out of the scope of this document. This is for further work and documen= tation.=20 =20 In the loose control, a 6LSR after binding a label to a FEC, distributes th= at binding=20 to its label distribution peers more like the routing algorithms. =20 =20 Ordered control and loose control are fully interoperable.=20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 25= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 7.12 =0D=20 Aggregation=20 =20 The 6LSA allows aggregation of labels when FECs represent address prefixes.= Since=20 IPv6 address prefixes are =93aggregatable=94, aggregation of FECs correspon= ding to=20 aggregatable prefixes is allowed in the 6LSA. The extent of aggregation is= a=20 function of the address aggregation, granularity of service desired or both= . Such=20 aggregation may further be decided by the IPv6 packet header Traffic Class= =20 parameters.=20 =20 7.13 =0D=20 Route Selection =20 =20 The method of selecting the proper 6LSP for a particular FEC is called rout= e=20 selection in the 6LSA and the options the 6LSA allows are (1) hop-by-hop ro= uting, and=20 (2) explicit routing. =20 =20 The hop-by-hop option has been described above in Section 7.7 in which each= node in=20 the 6LSA independently selects the next hop based on a given FEC. This is = very=20 similar to the =93best-effort=94 routing except that the forwarding in this= mode of 6LSA=20 is FEC driven. =20 =20 7.13.1 Hop-by-Hop Routing using Hop-by-Hop Header Extension=20 =20 To ensure per hop 6LSP execution, the 6LSA allows use of Hop-by-Hop Options= header,=20 identified by a Next Header value of 0 (zero) in the IPv6 header. This inc= reases=20 processing at each node since the packet carries optional information that = needs=20 processing by every 6LSR along a packet=92s route.=20 =20 7.13.2 Explicit Routing using Routing Header Extension =20 =20 To ensure explicit routing of packets, the 6LSA allows use of IPv6 Routing = Header=20 extensions. The Next Header value of 43 is then an attribute that a given = FEC must=20 include. In this case, the label binding to the FEC represents explicit ro= uting=20 using the Next Header value. The forwarding treatment a packet gets in a 6= LSR=20 comprises transmitting the packet to the next-hop 6LSR identified in the de= stination=20 address field of the packet. The final destination of the packet in an exp= licitly=20 routed packet may be outside of the 6LSA domain. =20 =20 7.14 =0D=20 Control=20 =20 The 6LSA specification requires the Hop Limit value in the packet header be= =20 decremented by 1 (one) in each 6LSR. The 6LSA processing of Hop Limit rema= ins the=20 same as in conventional IPv6 packet processing.=20 =20 7.15 =0D=20 Label Encodings =20 =20 The 6LSA allows encoding of the label value in layer 2 protocols such as in= ATM=20 packet=92s VPI/VCI fields. Since only one label is used and that each such= label is=20 uniquely identifiable in the 6LSA, encoding the label in the ATM VPI/VCI fi= eld is=20 feasible. Considerations with respect to how flows are identified, the FEC= -based=20 forwarding treatment and flow merging issues need careful planning in layer= 2 label=20 encoding. =20 =20 =0CHow a 6LSA label value is encoded in the ATM VPI/VCI field is outside th= e scope of=20 this document. =20 7.16 =0D=20 Anycast in 6LSA =20 =20 IPv6 defines the anycast address like a regular unicast address with a pref= ix=20 specifying the subnet and an identifier that is set to all zeroes. Anycast= packets=20 delivered to this address are delivered to one router in that subnet. Ther= e are=20 reserved subnet anycast addresses such as for mobile IPv6 Home-Agents anyca= st. The=20 6LSA allows the use of anycast addressing. Whenever a 6LSR is a node in an= y anycast=20 subnet, such a subnet may be a 6LSA, a subset of 6LSA or some other part of= 6LSA. =20 When an anycast packet arrives in anycast subnet 6LSR where the subnet is a= part or=20 =20 =20 Chakravorty Expires - December 2004 [Page 26= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 whole of 6SLA, the 6LSR binds the packet to a FEC which has anycast routing= as part=20 of the forwarding treatment attributes of the FEC. The packet is thus forw= arded to a=20 next-hop 6LSR through an interface determined by the FEC attributes related= to=20 anycast forwarding.=20 =20 7.17 =0D=20 Multicast in 6LSA=20 =20 IPv6 defines the mutlicast address by the high-order octet FF or 11111111 i= n binary=20 notation and 4 bits for the scope of the multicast and an identifier bit th= at=20 indicates whether the multicast address belongs to a well-known IANA multic= ast=20 address group or is a temporary address. =20 =20 The 6LSA allows the use mutlicast addressing. Whenever a 6LSR is a node in= any=20 mutlicast tree, such a tree may be a 6LSA, a subset of 6LSA or a part of 6L= SA. When=20 a mutlicast packet arrives in a multicast tree 6LSR where the subnet is a p= art or=20 whole of 6SLA, the 6LSR binds the packet to a FEC which has mutlicast routi= ng as part=20 of the forwarding treatment attributes of the FEC. The packet is thus forw= arded to a=20 next-hop 6LSR through an interface determined by the FEC attributes related= to=20 mutlicast forwarding.=20 =20 8. =0D=20 Security Considerations=20 =20 The 6SLA allows security association. If the security association (SA) par= tners are=20 outside the 6SLA, then there is no effect on the 6SLA by the SA whether the= mode of=20 operation is in the transport mode or in the tunnel mode. =20 =20 In the transport mode of SA, only the packet payload is subject to encrypti= on or=20 authentication, so the IPv6 packet header features are not affected and the= 6LSA=20 being a transport mechanism that sets up 6LSPs and provides specific FEC-dr= iven=20 forwarding treatment, there is no impact on the 6LSA or impact on SA operat= ion by the=20 6SLA.=20 =20 In the tunnel mode of SA, the SA requires an outer wrapper IPv6 packet. Th= e sending=20 gateway wraps the whole IPv6 packet including the content. The receiving g= ateway=20 performs the checksum on the outer wrapper packet, unwraps the packet and t= hen=20 verifies the checksum of the inner packet through end-to-end SA. If the ou= ter=20 wrapper packet conveys the Flow Label value of the inner packet, then 6SLA = provides=20 the 6LSP transport based on the inner label value, otherwise the transport = indicates=20 the outer label value. Here also, there is no impact on the 6LSA based tra= nsport of=20 the secure packets or vice versa.=20 =20 The Authentication Header (AH) is used in IPv6 for authentication of indivi= dual=20 packets to prevent common Internet-based attacks such as IP address spoofin= g and=20 session hijacking. The computation of cryptographically secure checksum ov= er the=20 payload as well as some fields of the IPv6 and extension headers has to tak= e place=20 between the SA partners. This computation does not include the Flow Label = field in=20 the packet header. This maintains label transparency in the 6SLA. Authent= ication=20 can be either in the transport mode or in the tunnel mode.=20 =20 The 6SLA security considerations that apply to Encrypted Security Payload (= ESP)=20 header comprise encryption modes that are categorized as transport mode or = tunnel=20 mode. In the transport mode, no encryption of the Flow Label field is perf= ormed, so=20 the value is carried through the 6SLA. In the tunnel mode, the issues are = the same=20 as stated here above.=20 =0C9. =0D=20 Informative References=20 =20 a. Rosen, E. Viswanathan, A. and Callon, R., =93Multiprotocol Label Switch= ing=20 Architecture,=94 RFC 3031, January 2001=20 =20 b. J. Rahjahalme, et al, =93IPv6 Flow Label Specification,=94 RFC 3697, Ma= rch 2004=20 =20 c. Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)= =20 Specification", RFC 2460, December 1998.=20 =20 =20 Chakravorty Expires - December 2004 [Page 27= ]=20 =0Cdraft-ietf-chakravorty-6lsa-0.txt August= 2004=20 =20 =20 =20 d. Hinden, R. and Deering, S., "IPv6 Multicast Address Assignm= ents", RFC=20 2375, July 1998=20 =20 e. Awduche, D., et al, =93Requirements for Traffic Engineering Over MPLS= =92, RFC 2702,=20 September 1999=20 =20 f. Awduche, D., et al, =93Overview and Principles of Internet Traffic Engi= neering=94,=20 RFC 3272, May 2002=20 =20 g. Agarwal, P. and Akyol B., Time to Live (TTL) Processing in MPLS Network= s, RFC=20 3443, January 2003=20 =20 h. Hinden, R. and Deering, S., =93IPv6 Addressing Architecture=94, RFC 351= 3, April 2003=20 =20 10. =0D=20 Acknowledgements=20 =20 The author deeply appreciates significant editing contributions made by Kei= th Scott=20 (MITRE), implementation support provided by Don Chirieleison (MITRE) and va= luable=20 general advice and encouragement received from Jim Bound (HP). The author = also=20 gratefully acknowledges overall management support for implementation of th= is=20 protocol given by Jim Providakes (MITRE).=20 =20 11. =0D=20 Author=92s Addresses=20 =20 Question on this draft can be directed to =20 =20 Sham Chakravorty=20 MITRE Corporation=20 1575 Colshire Dr.=20 McLean, VA 22102=20 =20 Email: schakra@mitre.org=20 =20 12. Full Copyright Statement=20 =20 Copyright (C) The Internet Society (2003). All Rights Reserved.=20 =20 This document and translations of it may be copied and furnished to others,= and=20 derivative works that comment on or otherwise explain it or assist in its= =20 implementation may be prepared, copied, published and distributed, in whole= or in=20 part, without restriction of any kind, provided that the above copyright no= tice and=20 this paragraph are included on all such copies and derivative works. Howeve= r, this=20 document itself may not be modified in any way, such as by removing the cop= yright=20 notice or references to the Internet Society or other Internet organization= s, except=20 as needed for the purpose of developing Internet standards in which case th= e=20 procedures for copyrights defined in the Internet Standards process must be= followed,=20 or as required to translate it into languages other than English.=20 =20 The limited permissions granted above are perpetual and will not be revoked= by the=20 Internet Society or its successors or assignees. =20 =20 This document and the information contained herein is provided on an "AS IS= " basis=20 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS = ALL=20 =0CWARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANT= Y THAT THE=20 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED W= ARRANTIES=20 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Funding for the RF= C editor=20 function is currently provided by the Internet Society. =20 =20 =20 =20 =20 Chakravorty Expires - December 2004 [Page 28= ]=20 =0C ------------71E75CEBD4BBB-- From rtg-dir-bounces@ietf.org Thu Jun 17 20:34:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29497 for ; Thu, 17 Jun 2004 20:34: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 1Bb7LJ-0002k1-0W for rtg-dir-archive@ietf.org; Thu, 17 Jun 2004 20:34:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb7KH-0002Aw-00 for rtg-dir-archive@ietf.org; Thu, 17 Jun 2004 20:33:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bb7JT-0001hA-00 for rtg-dir-archive@ietf.org; Thu, 17 Jun 2004 20:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb709-000408-Tx; Thu, 17 Jun 2004 20:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb6uk-000231-8D for rtg-dir@megatron.ietf.org; Thu, 17 Jun 2004 20: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 UAA28123 for ; Thu, 17 Jun 2004 20:07: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 1Bb6ui-0001au-Mu for rtg-dir@ietf.org; Thu, 17 Jun 2004 20:07:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb6tn-0001DG-00 for rtg-dir@ietf.org; Thu, 17 Jun 2004 20:06:28 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Bb6sg-0000pt-00 for rtg-dir@ietf.org; Thu, 17 Jun 2004 20:05:18 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb6sg-0002LM-Ny for rtg-dir@ietf.org; Fri, 18 Jun 2004 00:05:18 +0000 Date: Thu, 17 Jun 2004 17:05:15 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <666642290.20040617170515@psg.com> To: rtg-dir@ietf.org In-Reply-To: <200406172229.SAA22241@ietf.org> References: <200406172229.SAA22241@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA28123 Subject: Fwd: PRELIMINARY Agenda and Package for June 24, 2004 Telechat X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org 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: quoted-printable Comments by next Wed, please. --=20 Alex http://www.psg.com/~zinin This is a forwarded message From: IESG Secretary To: iesg@ietf.org Cc: bfuller@foretec.com, amyk@foretec.com Date: Thursday, June 17, 2004, 3:29:57 PM Subject: PRELIMINARY Agenda and Package for June 24, 2004 Telechat =3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DOriginal message tex= t=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the June 24, 2004 IESG Teleconference This agenda was generated at 17:22:29 EDT, June 17, 2004 = =20 1. Administrivia = =20 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes 1.4 Review of Action Items 1.5 Review of Projects http://www.unreason.com/jfp/iesg-projects = =20 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-xmpp-e2e-08.txt End-to-End Object Encryption in the Extensible Messaging and Presence= =20 Protocol (XMPP) (Proposed Standard) - 1 of 7=20 Token: Scott Hollenbeck o draft-ietf-ospf-ospfv3-auth-04.txt Authentication/Confidentiality for OSPFv3 (Proposed Standard) - 2 of = 7=20 Note: Participant in PROTO Team pilot:. Working Group Chair Followup = of=20 DISCUSS Comments.=20 http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-discuss-= pilot-01.txt=20 Token: Bill Fenner o draft-ietf-aaa-diameter-cc-05.txt Diameter Credit-control Application (Proposed Standard) - 3 of 7=20 Note: GEN-ART review has some (minor) comments (resulting from review= =20 during IETF Last Call) that will be addressed by authors. They will d= o so=20 when IESG comments (if any) are available so that one revision can ad= dress=20 all comments at same time.=20 Token: Bert Wijnen o draft-ietf-ipsec-ikev2-14.txt Internet Key Exchange (IKEv2) Protocol (Proposed Standard) - 4 of 7=20 Token: Russ Housley o Two-document ballot: - 5 of 7 - draft-ietf-sip-parameter-registry-02.txt The Internet Assigned Number Authority (IANA) Header Field Paramet= er=20 Registry for the Session Initiation Protocol (SIP) (BCP)=20 Note: IANA reviewed (IESG list mail 20040602).=C3=E1=20 - draft-ietf-sip-uri-parameter-reg-02.txt The Internet Assigned Number Authority (IANA) Universal Resource=20 Identifier (URI) Parameter Registry for the Session Initiation Pro= tocol=20 (SIP) (BCP)=20 Token: Allison Mankin o draft-ietf-mboned-embeddedrp-05.txt Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Addr= ess=20 (Proposed Standard) - 6 of 7=20 Token: David Kessens o rfc2234.txt Augmented BNF for Syntax Specifications: ABNF (Draft Standard) - 7 of= 7=20 Token: Scott Hollenbeck 2.1.2 Returning Item o draft-ietf-mpls-in-ip-or-gre-07.txt Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) (Prop= osed=20 Standard) - 1 of 2=20 Note: to clear Steve's DISCUSS=20 Token: Alex Zinin o draft-ietf-ospf-scalability-08.txt Prioritized Treatment of Specific OSPF Packets and Congestion Avoidan= ce=20 (BCP) - 2 of 2=20 Note: Additional response to each evaluation comment in comment log=20 Token: Bill Fenner 2.2 Individual Submissions 2.2.1 New Item o draft-blunk-rpslng-05.txt Routing Policy Specification Language next generation (RPSLng) (Propo= sed=20 Standard) - 1 of 2=20 Token: Bert Wijnen o draft-phillips-langtags-03.txt Tags for Identifying Languages (BCP) - 2 of 2=20 Token: Ted Hardie 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-seamoby-ctp-10.txt Context Transfer Protocol (Experimental) - 1 of 6=20 Note: "Experimental" experimental=20 Token: Allison Mankin o draft-ietf-pana-threats-eval-06.txt Protocol for Carrying Authentication and Network Access Threat Analys= is and=20 Security Requirements (Informational) - 2 of 6=20 Token: Thomas Narten o draft-ietf-pana-requirements-08.txt Protocol for Carrying Authentication for Network Access (PANA)Require= ments=20 (Informational) - 3 of 6=20 Token: Thomas Narten o draft-ietf-seamoby-iana-02.txt Instructions for Seamoby Experimental Protocol IANA Allocations=20 (Experimental) - 4 of 6=20 Note: Supports CTP (new on this agenda), CARD (returning).=20 Token: Allison Mankin o draft-ietf-mboned-mroutesec-01.txt PIM-SM Multicast Routing Security Issues and Enhancements (Informatio= nal) -=20 5 of 6=20 Token: David Kessens o draft-ietf-v6ops-unmaneval-03.txt Evaluation of Transition Mechanisms for Unmanaged Networks (Informati= onal)=20 - 6 of 6=20 Token: David Kessens 3.1.2 Returning Item o draft-pillay-esnault-ospf-flooding-07.txt OSPF Refresh and Flooding Reduction in Stable Topologies (Information= al) -=20 1 of 1=20 Note: Already reviewed in 6/2003; please don't re-review unless=20 showstoppers - want to clear ops-dir comment (see document log, there= 's no=20 ballot).  IESG RED TEAM=20 Token: Bill Fenner 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item NONE 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item NONE 3.3.2 Returning Item o draft-dfncis-netnews-admin-sys-06.txt Netnews Administration System (NAS) (Experimental) - 1 of 1=20 Note: Re-review in light of new procedures for individual submissions= via=20 the RFC Editor.  This one has been in the IESG's hands for two y= ears!=20 Token: Scott Hollenbeck 3.3.3 For Action o draft-baker-slem-architecture-02.txt Cisco Support for Lawful Intercept In IP Networks (Informational) - 1= of 1=20 Note: Given our new policy, do we still want the IESG note per Ted's=20 comment?  Or just the new standard disclaimer?=20 Token: Steve Bellovin 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issue -------------------------------------------------------------------------= ----- From rtg-dir-bounces@ietf.org Mon Jun 21 19:06:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13179 for ; Mon, 21 Jun 2004 19:06: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 1BcXro-0006t6-7b for rtg-dir-archive@ietf.org; Mon, 21 Jun 2004 19:06:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcXqo-0006ZZ-00 for rtg-dir-archive@ietf.org; Mon, 21 Jun 2004 19:05:19 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BcXpv-00062k-00 for rtg-dir-archive@ietf.org; Mon, 21 Jun 2004 19:04:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcXeo-0001dl-S4; Mon, 21 Jun 2004 18:52:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcXSW-00069p-VT for rtg-dir@megatron.ietf.org; Mon, 21 Jun 2004 18:40: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 SAA11020 for ; Mon, 21 Jun 2004 18:40: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 1BcXSV-0006jg-F5 for rtg-dir@ietf.org; Mon, 21 Jun 2004 18:40:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcXRZ-0006S2-00 for rtg-dir@ietf.org; Mon, 21 Jun 2004 18:39:13 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1BcXQj-0006Ap-00 for rtg-dir@ietf.org; Mon, 21 Jun 2004 18:38:21 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BcXQj-000H1h-Mi; Mon, 21 Jun 2004 22:38:21 +0000 Date: Mon, 21 Jun 2004 15:38:21 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <437121611.20040621153821@psg.com> To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Loa Andersson , dimitri papadimitriou Subject: Review: draft-ietf-ccamp-gmpls-overlay-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org 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 I'm starting AD-review for this document. Dimitri, Loa, please review it for RTG-DIR. Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various transport technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model. Document is available at: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Fri Jun 25 21:15:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24574 for ; Fri, 25 Jun 2004 21:15: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 1Be1nF-0006HO-Np for rtg-dir-archive@ietf.org; Fri, 25 Jun 2004 21:15:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Be1mR-00060F-00 for rtg-dir-archive@ietf.org; Fri, 25 Jun 2004 21:14:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Be1lt-0005h4-00 for rtg-dir-archive@ietf.org; Fri, 25 Jun 2004 21:14:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Be1jG-0006iD-VU; Fri, 25 Jun 2004 21:11:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Be1cZ-0004lX-9z for rtg-dir@megatron.ietf.org; Fri, 25 Jun 2004 21:04: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 VAA24086 for ; Fri, 25 Jun 2004 21:04: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 1Be1cX-000336-M1 for rtg-dir@ietf.org; Fri, 25 Jun 2004 21:04:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Be1bh-0002le-00 for rtg-dir@ietf.org; Fri, 25 Jun 2004 21:03:50 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx with esmtp (Exim 4.12) id 1Be1b0-0002Tm-00 for rtg-dir@ietf.org; Fri, 25 Jun 2004 21:03:06 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i5Q1352j011473; Sat, 26 Jun 2004 03:03:05 +0200 Received: from alcatel.be ([138.203.118.2]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004062603030395:275 ; Sat, 26 Jun 2004 03:03:03 +0200 Message-ID: <40DCCBFA.2000902@alcatel.be> Date: Sat, 26 Jun 2004 03:06:02 +0200 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <437121611.20040621153821@psg.com> In-Reply-To: <437121611.20040621153821@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/26/2004 03:03:04, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/26/2004 03:03:05, Serialize complete at 06/26/2004 03:03:05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Cc: Loa Andersson , rtg-dir@ietf.org, dimitri papadimitriou Subject: Re: Review: draft-ietf-ccamp-gmpls-overlay-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org 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: 7bit hi alex, find here below my review of this document o) Technical Comments (minor): 1. Introduction mentions "However, one possible means is using a forwarding adjacency as described in [MPLS-HIER]." -> but forwarding adjacencies are by definitions related to the peer model (also, [MPLS-HIER] does not refer to this "hierarchical TE link" - see end Section 4 of [MPLS-HIER]) 2. Section 3.2: "If the route is not viable, then a PathErr message with an error code and value of 24,5 - "No route available toward destination" should be returned." -> "viability" should probably be further detailed 3. Section 3.3: "In order to support explicit label control and full identification of the egress link an ingress edge-node may include an ERO that consists of only the last hop." -> unclear why *only* the last hop can be included in such ERO (why this sentence does not only determine the behaviour at the last hop being the egress core-node) 4. Section 6.2: mapping 2 is not allowed (independently of the presence of the Path_State_Removed_Flag from the receiving PathErr) since PathErr propagation rule is disrupted as far as the proposed text reads o) Editorial Comments: 1. Spell out the acronyms in the document title (GMPLS, UNI, etc.) 2. in Abstract: "Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label Switched Paths (LSPs) in various transport technologies." -> transport technologies might not be the most appropriated in the IETF context - suggestion replace it by "switching" 3. Introduction 1): "The four boxes around the edge marked "Overlay Network" represent four islands of a single network overlaid network" -> not sure the last part of this sentence is not mispelled 4. Section 3) "If a core-node rejects a Path message due to the presence of an ERO it SHOULD return an PathErr message with an error code of "Unknown object class" toward the sender. This causes the path setup to fail." -> should point to the RFC 3209 section: "4.3.7. Non-support of the Explicit Route Object" as procedures are apparently equivalent 5. Section 5) " Core-nodes may send Notification messages to edge-nodes which have included the NOTIFY_REQUEST object." -> suggested: "Core-nodes MAY send Notify messages to edge-nodes which have included the NOTIFY_REQUEST object." 6. Section 5) "In either of the above cases, the a core-node SHOULD NOT send Notify messages to the edge-node. -> edit: "the a" 7. Section 5) "In this case, when NOTIFY messages are received, they MAY be selectively (based on local policy) forwarded to the edge- node." -> edit: NOTIFY -> Notify 8. Section 6.1) "An ingress core-node receiving a PathTear without having first seen an ADMIN_STATUS object informing it that the connection is about to be deleted MAY pause the PathTear and first send a Path message with an ADMIN_STATUS object to inform all downstream LSRs that the connection is about to be deleted." -> first time in this document that the term "LSR" appears 9. Update the Informative Reference section with latest version of the referenced document --- Alex Zinin wrote: > I'm starting AD-review for this document. > > Dimitri, Loa, please review it for RTG-DIR. > > Generalized Multiprotocol Label Switching (GMPLS) defines both > routing and signaling protocols for the creation of Label Switched > Paths (LSPs) in various transport technologies. These protocols can > be used to support a number of deployment scenarios. This memo > addresses the application of GMPLS to the overlay model. > > Document is available at: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-04.txt > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 From rtg-dir-bounces@ietf.org Wed Jun 30 17:21:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21236 for ; Wed, 30 Jun 2004 17:21: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 1BfmWb-0002s6-KP for rtg-dir-archive@ietf.org; Wed, 30 Jun 2004 17:21:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfmVc-0002SE-00 for rtg-dir-archive@ietf.org; Wed, 30 Jun 2004 17:20:48 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BfmUr-0001zP-00 for rtg-dir-archive@ietf.org; Wed, 30 Jun 2004 17:20:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfmFz-0002xb-M4; Wed, 30 Jun 2004 17:04:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfmEG-00020Q-Pn for rtg-dir@megatron.ietf.org; Wed, 30 Jun 2004 17:02: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 RAA18773 for ; Wed, 30 Jun 2004 17:02: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 1BfmEF-0003Xt-CG for rtg-dir@ietf.org; Wed, 30 Jun 2004 17:02:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfm6O-0001Xx-00 for rtg-dir@ietf.org; Wed, 30 Jun 2004 16:54:44 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BflwQ-00077E-00 for rtg-dir@ietf.org; Wed, 30 Jun 2004 16:44:26 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B6A0C7A3210; Wed, 30 Jun 2004 13:44:25 -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 20905-05; Wed, 30 Jun 2004 13:44:25 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.18]) by prattle.redback.com (Postfix) with SMTP id 02C7B7A320D; Wed, 30 Jun 2004 13:44:25 -0700 (PDT) Message-ID: <086c01c45ee3$04a64850$0202a8c0@aceeinspiron> From: "Acee Lindem" To: "Alex Zinin" References: <1710720649.20040615151124@psg.com> <40D0577A.7050707@psg.com> Date: Wed, 30 Jun 2004 16:44:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: draft-shen-ip-te-rsp-00.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org 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 I like it as well. However, I'm not completely unbiased. Thanks, Acee ----- Original Message ----- From: "dimitri papadimitriou" To: "Alex Zinin" Cc: Sent: Wednesday, June 16, 2004 10:21 AM Subject: Re: draft-shen-ip-te-rsp-00.txt > alex, i'm personally in favor in moving forward with this idea, specific details > concerning the proposed solution should be further discussed (e.g. bi- > directional tunnels, definition and processing of the newly proposed objects, > detail usage of mandatory RSVP objects, etc.) but overal the idea seems really > promising > > --- > > Alex Zinin wrote: > > > I like the idea a lot. > > Opinions? > > > From rtg-dir-bounces@ietf.org Wed Jul 21 08:49:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14189 for ; Wed, 21 Jul 2004 08:49:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnGXx-0002E9-Gp for rtg-dir-archive@ietf.org; Wed, 21 Jul 2004 08:50:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnGWe-0004nt-U5; Wed, 21 Jul 2004 08:48:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnGRr-0001qe-Jz for rtg-dir@megatron.ietf.org; Wed, 21 Jul 2004 08:43:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13707; Wed, 21 Jul 2004 08:43:48 -0400 (EDT) Received: from webmail.pi.se ([195.7.65.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnGSA-00028f-0s; Wed, 21 Jul 2004 08:44:11 -0400 Received: from webmail.pi.se (localhost [127.0.0.1]) by webmail.pi.se (8.12.8/8.11.1) with ESMTP id i6LCheDa014047; Wed, 21 Jul 2004 14:43:40 +0200 (CEST) (envelope-from loa@pi.se) Received: (from www-data@localhost) by webmail.pi.se (8.12.8/8.12.8/Submit) id i6LCheRX014046; Wed, 21 Jul 2004 14:43:40 +0200 (CEST) (envelope-from loa@pi.se) X-Authentication-Warning: webmail.pi.se: www-data set sender to loa@pi.se using -f Received: from 212.214.189.26 ([212.214.189.26]) by webmail.pi.se (Horde) with HTTP for ; Wed, 21 Jul 2004 14:43:40 +0200 Message-ID: <1090413820.0d00556816a19@webmail.pi.se> Date: Wed, 21 Jul 2004 14:43:40 +0200 From: Loa Andersson To: iesg-secretary@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 212.214.189.26 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: zinin@psg.com, rtg-dir@ietf.org, swallow@cisco.com Subject: draft-ietf-mpls-explicit-null-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit IESG and Alex, could you please start the review process for draft-ietf-mpls-explicit-null-01.txt to become an RFC on the standards track. There are known implementations of this draft. /Loa Loa Andersson +46 739 81 21 64 From rtg-dir-bounces@ietf.org Fri Jul 23 10:08:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25068 for ; Fri, 23 Jul 2004 10:08:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo0jR-0007GA-HR for rtg-dir-archive@ietf.org; Fri, 23 Jul 2004 10:09:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo0hh-0002Lw-Ac; Fri, 23 Jul 2004 10:07:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo0TV-0003ND-Gg for rtg-dir@megatron.ietf.org; Fri, 23 Jul 2004 09:52:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23349; Fri, 23 Jul 2004 09:51:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo0TU-0006wG-TM; Fri, 23 Jul 2004 09:52:40 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bo0Sg-000KwN-CU; Fri, 23 Jul 2004 13:51:46 +0000 Date: Fri, 23 Jul 2004 17:51:42 +0400 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <149805537.20040723175142@psg.com> To: rtg-chairs@ietf.org, rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Bill Fenner Subject: response delay X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Guys- I need a couple of days to get well. If you have something you need answered urgently, please work with Bill and cc me. Thanks. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Sat Jul 31 20:48:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26193 for ; Sat, 31 Jul 2004 20:48:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Br4Yj-0007t7-0M for rtg-dir-archive@ietf.org; Sat, 31 Jul 2004 20:50:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Br4RX-0003iW-7L; Sat, 31 Jul 2004 20:43:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Br4Cp-0000dl-Ib for rtg-dir@megatron.ietf.org; Sat, 31 Jul 2004 20:28:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25083 for ; Sat, 31 Jul 2004 20:28:01 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Br4FM-0007cy-Qh for rtg-dir@ietf.org; Sat, 31 Jul 2004 20:30:42 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Br4Cn-000ORn-9W for rtg-dir@ietf.org; Sun, 01 Aug 2004 00:28:01 +0000 Date: Sat, 31 Jul 2004 17:27:55 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <393379450.20040731172755@psg.com> To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: RTG-DIR Dinner X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Folks- Those in SD, please let me know what works better for you: 1) Sunday late night (9pm?) 2) Monday late night (after the RTGAREA meeting) -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Sun Aug 1 11:30:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06526 for ; Sun, 1 Aug 2004 11:30:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrIKP-0004iY-Tn for rtg-dir-archive@ietf.org; Sun, 01 Aug 2004 11:32:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrI5b-0003Q5-Qh; Sun, 01 Aug 2004 11:17:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrHzq-0000Dc-B8 for rtg-dir@megatron.ietf.org; Sun, 01 Aug 2004 11:11:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05495 for ; Sun, 1 Aug 2004 11:11:32 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrI2V-0004R2-Et for rtg-dir@ietf.org; Sun, 01 Aug 2004 11:14:20 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 1094D2D483C for ; Sun, 1 Aug 2004 11:11: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 19141-01-83 for ; Sun, 1 Aug 2004 11:11: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 D7B522D4827 for ; Sun, 1 Aug 2004 11:11:01 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Aug 2004 11:11:01 -0400 Message-ID: Thread-Topic: RTG-DIR Dinner Thread-Index: AcR3YTSX9O64duu9S82u0l2ckR9XIwAeHssQ From: "Susan Hares" To: "Alex Zinin" , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Subject: RE: RTG-DIR Dinner X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Monday late. I will not arrive until 10:00pm on Sunday. Sue -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com] Sent: Saturday, July 31, 2004 8:28 PM To: rtg-dir@ietf.org Subject: RTG-DIR Dinner Folks- =20 Those in SD, please let me know what works better for you: 1) Sunday late night (9pm?) 2) Monday late night (after the RTGAREA meeting) --=20 Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Sun Aug 1 18:21:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28551 for ; Sun, 1 Aug 2004 18:21:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrOkr-0001oy-M6 for rtg-dir-archive@ietf.org; Sun, 01 Aug 2004 18:24:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrOf3-0001ud-Gy; Sun, 01 Aug 2004 18:18:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrOVk-00034P-NK for rtg-dir@megatron.ietf.org; Sun, 01 Aug 2004 18:08:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27266 for ; Sun, 1 Aug 2004 18:08:54 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrOYP-0001g2-DG for rtg-dir@ietf.org; Sun, 01 Aug 2004 18:11:46 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BrOVc-0004ii-VQ for rtg-dir@ietf.org; Sun, 01 Aug 2004 22:08:49 +0000 Date: Sun, 1 Aug 2004 15:08:44 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <719381091.20040801150844@psg.com> To: rtg-dir@ietf.org In-Reply-To: <393379450.20040731172755@psg.com> References: <393379450.20040731172755@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: Re: RTG-DIR Dinner X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit OK, so far Monday night seems to work better for people. Let's meet 15m after the RTGAREA meeting ends in the hotel lobby. I don't anticipate the meeting to be long, so chances are we will meet before 10pm. -- Alex http://www.psg.com/~zinin Saturday, July 31, 2004, 5:27:55 PM, Alex Zinin wrote: > Folks- > Those in SD, please let me know what works better for you: > 1) Sunday late night (9pm?) > 2) Monday late night (after the RTGAREA meeting) From rtg-dir-bounces@ietf.org Thu Aug 5 20:45:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29970 for ; Thu, 5 Aug 2004 20:45:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BssvG-0000vm-MH for rtg-dir-archive@ietf.org; Thu, 05 Aug 2004 20:49:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bssnf-0000Y8-Sa; Thu, 05 Aug 2004 20:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkzOX-0004zd-8a for rtg-dir@megatron.ietf.org; Thu, 15 Jul 2004 02:07: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 CAA17595 for ; Thu, 15 Jul 2004 02: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 1BkzOU-0000jn-Nc for rtg-dir@ietf.org; Thu, 15 Jul 2004 02:06:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkzNm-0000PZ-00 for rtg-dir@ietf.org; Thu, 15 Jul 2004 02:06:22 -0400 Received: from smtp813.mail.sc5.yahoo.com ([66.163.170.83]) by ietf-mx with smtp (Exim 4.12) id 1BkzN5-00003w-00 for Rtg-dir@ietf.org; Thu, 15 Jul 2004 02:05:31 -0400 Received: from unknown (HELO RAKHILAPTOP) (vishal.sharma@sbcglobal.net@63.206.93.207 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 15 Jul 2004 06:05:27 -0000 From: "Vishal Sharma" To: Date: Wed, 14 Jul 2004 23:05:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C469F7.0AE49E50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 X-Mailman-Approved-At: Thu, 05 Aug 2004 20:41:34 -0400 Cc: Rtg-dir@ietf.org, Bert Wijnen , Kireeti Kompella , Adrian Farrel , Greg Bernstein , Eric Mannie Subject: Updated SDH/SONET GMPLS Control Framework: draft-ietf-ccamp-sdhsonet-control-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: v.sharma@ieee.org List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: aceaed67ecf223b6febbd7c5b72f7957 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C469F7.0AE49E50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello IETF draft submissions manager, Please find attached an updated version of the CCAMP WG draft titled "A Framework for GMPLS-based Control of SDH/SONET Networks," which has been revised in accordance with the latest feedback received from the Routing Area Directorate. Please note that the draft has also been updated to confirm to the latest format guidelines for IETF drafts. If you have any problems posting this, please let me know. Many thanks, -Vishal **************************************************************** Vishal Sharma, Ph.D. Metanoia, Inc. (Critical Systems Thinking) 888 Villa Street, Suite 200B, Mountain View, CA 94041-1261 Phone: +1 408-530-8313. Voice: +1 408-394-6321 Email: v.sharma@ieee.org. http://www.metanoia-inc.com **************************************************************** Title: Framework for GMPLS-based Control of SDH/SONET Networks Abstract: The suite of protocols that defines Multi-Protocol Label Switching (MPLS) is in the process of enhancement to generalize its applicability to the control of non-packet based switching, that is, optical switching. One area of prime consideration is to use these generalized MPLS (GMPLS) protocols in upgrading the control plane of optical transport networks. This document illustrates this process by describing those extensions to MPLS protocols that are directed towards controlling SDH/SONET networks. SDH/SONET networks make very good examples of this process since they possess a rich multiplex structure, a variety of protection/restoration options, are well defined, and are widely deployed. The document discusses extensions to MPLS routing protocols to disseminate information needed in transport path computation and network operations, together with the extensions to MPLS label distribution protocols needed for the provisioning of transport circuits. New capabilities that an MPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. Pages: 30 ------=_NextPart_000_0000_01C469F7.0AE49E50 Content-Type: text/plain; name="draft-ietf-ccamp-sdhsonet-control-03.txt" Content-Disposition: attachment; filename="draft-ietf-ccamp-sdhsonet-control-03.txt" Content-Transfer-Encoding: quoted-printable CCAMP Working Group G. Bernstein (Grotto Networking)=20 Internet Draft E. Mannie (InterAir Link)=20 Document: =20 Category: Informational =20 Expires January 2005 July 2004=20 =20 =20 Framework for GMPLS-based Control of SDH/SONET Networks=20 =20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026 [1].=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documents=20 at any time. It is inappropriate to use Internet- Drafts as=20 reference material or to cite them other than as "work in progress." = =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 The suite of protocols that defines Multi-Protocol Label Switching=20 (MPLS) is in the process of enhancement to generalize its=20 applicability to the control of non-packet based switching, that is,=20 optical switching. One area of prime consideration is to use these=20 generalized MPLS (GMPLS) protocols in upgrading the control plane of=20 optical transport networks. This document illustrates this process=20 by describing those extensions to MPLS protocols that are directed=20 towards controlling SDH/SONET networks. SDH/SONET networks make=20 very good examples of this process since they possess a rich=20 multiplex structure, a variety of protection/restoration options,=20 are well defined, and are widely deployed. The document discusses=20 extensions to MPLS routing protocols to disseminate information=20 needed in transport path computation and network operations,=20 together with the extensions to MPLS label distribution protocols=20 needed for the provisioning of transport circuits. New capabilities=20 that an MPLS control plane would bring to SDH/SONET networks, such=20 as new restoration methods and multi-layer circuit establishment,=20 are also discussed. =20 =20 =20 Bernstein/Mannie/Sharma Informational-January 2005 1=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 =20 1. Conventions used in this document................................2=20 2. Introduction.....................................................3=20 2.1. MPLS Overview..................................................3=20 2.2. SDH/SONET Overview.............................................4=20 2.3. The Current State of Circuit Establishment in SDH/SONET=20 Networks.............................................................7=20 2.3.1. Administrative Tasks.......................................7=20 2.3.2. Manual Operations..........................................7=20 2.3.3. Planning Tool Operation....................................7=20 2.3.4. Circuit Provisioning.......................................8=20 2.4. Centralized Approach versus Distributed Approach...............8=20 2.4.1. Topology Discovery and Resource Dissemination..............9=20 2.4.2. Path Computation (Route Determination).....................9=20 2.4.3. Connection Establishment (Provisioning)...................10=20 2.5. Why SDH/SONET will not Disappear Tomorrow.....................11=20 3. GMPLS Applied to SDH/SONET......................................12=20 3.1. Controlling the SDH/SONET Multiplex...........................12=20 3.2. SDH/SONET LSR and LSP Terminology.............................13=20 4. Decomposition of the MPLS Circuit-Switching Problem Space.......13=20 5. GMPLS Routing for SDH/SONET.....................................14=20 5.1. Switching Capabilities........................................15=20 5.1.1. Switching Granularity.....................................15=20 5.1.2. Signal Concatenation Capabilities.........................16=20 5.1.3. SDH/SONET Transparency....................................17=20 5.2. Protection....................................................18=20 5.3. Available Capacity Advertisement..............................21=20 5.4. Path Computation..............................................22=20 6. LSP Provisioning/Signaling for SDH/SONET........................22=20 6.1. What do we Label in SDH/SONET? Frames or Circuits?............23=20 6.2. Label Structure in SDH/SONET..................................24=20 6.3. Signaling Elements............................................24=20 7. Summary and Conclusions.........................................26=20 8. Security Considerations.........................................27=20 9. Acknowledgments.................................................27=20 10. Author's Addresses..............................................27=20 11. References......................................................27=20 11.1. Normative References........................................27=20 11.2. Informative References......................................28=20 12. Intellectual Property Considerations............................29=20 12.1. IPR Disclosure Acknowledgement..............................29=20 13. Full Copyright Statement........................................29=20 =20 =20 1. Conventions used in this document=20 =20 =20 =20 Bernstein/Mannie/Sharma Expires January 2005 2=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [2].=20 =20 =20 2. Introduction=20 =20 The CCAMP Working Group of the IETF is currently working on=20 extending MPLS [3] protocols to support multiple network layers and=20 new services. This extended MPLS, which was initially known as=20 Multi-Protocol Lambda Switching, is now better referred to as=20 Generalized MPLS (or GMPLS). =20 =20 The GMPLS effort is, in effect, extending IP/MPLS technology to=20 control and manage lower layers. Using the same framework and=20 similar signaling and routing protocols to control multiple layers=20 can not only reduce the overall complexity of designing, deploying=20 and maintaining networks, but can also make it possible to operate=20 two contiguous layers by using either an overlay model, a peer=20 model, or an integrated model. The benefits of using a peer or an=20 overlay model between the IP layer and its underlying layer(s) will=20 have to be clarified and evaluated in the future. In the mean time,=20 GMPLS could be used for controlling each layer independently. =20 =20 The goal of this work is to highlight how MPLS could be used to=20 dynamically establish, maintain, and tear down SDH/SONET circuits.=20 The objective of using these extended IP/MPLS protocols is to=20 provide at least the same kinds of SDH/SONET services as are=20 provided today, but using signaling instead of provisioning via=20 centralized management to establish those services. This will allow=20 operators to propose new services, and will allow clients to create=20 SDH/SONET paths on-demand, in real-time, through the provider=20 network. We first review the essential properties of SDH/SONET=20 networks and their operations, and we show how the label concept in=20 MPLS can be extended to the SDH/SONET case. We then look at=20 important information to be disseminated by a link state routing=20 protocol and look at the important signal attributes that need to be=20 conveyed by a label distribution protocol. Finally, we look at some=20 outstanding issues and future possibilities. =20 =20 2.1. MPLS Overview=20 =20 A major advantage of the MPLS architecture [3] for use as a general=20 network control plane is its clear separation between the forwarding=20 (or data) plane, the signaling (or connection control) plane, and=20 the routing (or topology discovery/resource status) plane. This=20 allows the work on MPLS extensions to focus on the forwarding and=20 signaling planes, while allowing well-known IP routing protocols to=20 be reused in the routing plane. This clear separation also allows=20 for MPLS to be used to control networks that do not have a packet- based forwarding plane. =20 =20 =20 Bernstein/Mannie/Sharma Expires January 2005 3=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 An MPLS network consists of MPLS nodes called Label Switch Routers=20 (LSRs) connected via circuits called Label Switched Paths (LSPs). An=20 LSP is unidirectional and could be of several different types such=20 as point-to-point, point-to-multipoint, and multipoint-to-point.=20 Border LSRs in an MPLS network act either as ingress or egress LSRs=20 depending on the direction of the traffic being forwarded.=20 =20 Each LSP is associated with a Fowarding Equivalence Class (FEC),=20 which may be thought of as a set of packets that receive identical=20 forwarding treatment at an LSR. The simplest example of an FEC might=20 be the set of destination addresses lying in a given address range.=20 All packets that have a destination address lying within this=20 address range are forwarded identically at each LSR configured with=20 that FEC.=20 =20 To establish an LSP, a signaling protocol (or label distribution=20 protocol) such as LDP/CR-LDP or RSVP-TE is required. Between two=20 adjacent LSRs, an LSP is locally identified by a short, fixed length=20 identifier called a label, which is only significant between those=20 two LSRs. The signaling protocol is responsible for the inter-node=20 communication that assigns and maintains these labels.=20 =20 When a packet enters an MPLS-based packet network, it is classified=20 according to its FEC and, possibly, additional rules, which together=20 determine the LSP along which the packet must be sent. For this=20 purpose, the ingress LSR attaches an appropriate label to the=20 packet, and forwards the packet to the next hop. The label may be=20 attached to a packet in different ways. For example, it may be in=20 the form of a header encapsulating the packet (the "shim" header) or=20 it may be written in the VPI/VCI field (or DLCI field) of the layer=20 2 encapsulation of the packet. In case of SDH/SONET networks, we=20 will see that a label is simply associated with a segment of a=20 circuit, and is mainly used in the signaling plane to identify this=20 segment (e.g. a time-slot) between two adjacent nodes.=20 =20 When a packet reaches a packet LSR, this LSR uses the label as an=20 index into a forwarding table to determine the next hop and the=20 corresponding outgoing label (and, possibly, the QoS treatment to be=20 given to the packet), writes the new label into the packet, and=20 forwards the packet to the next hop. When the packet reaches the=20 egress LSR, the label is removed and the packet is forwarded using=20 appropriate forwarding, such as normal IP forwarding. We will see=20 that for a SDH/SONET network these operations do not occur in quite=20 the same way.=20 =20 2.2. SDH/SONET Overview=20 =20 There are currently two different multiplexing technologies in use=20 in optical networks: wavelength division multiplexing (WDM) and time=20 division multiplexing (TDM). This work focuses on TDM technology. =20 =20 =20 =20 Bernstein/Mannie/Sharma Expires January 2005 4=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 SDH and SONET are two TDM standards widely used by operators to=20 transport and multiplex different tributary signals over optical=20 links, thus creating a multiplexing structure, which we call the=20 SDH/SONET multiplex. =20 =20 ITU-T (G.707) [4] includes both the European ETSI SDH hierarchy and=20 the USA ANSI SONET hierarchy [5]. The ETSI SDH and SONET standards=20 regarding frame structures and higher-order multiplexing are the=20 same. There are some regional differences in terminology, on the use=20 of some overhead bytes, and lower-order multiplexing. Interworking=20 between the two lower-order hierarchies is possible using gateways.=20 =20 The fundamental signal in SDH is the STM-1 that operates at a rate=20 of about 155 Mbps, while the fundamental signal in SONET is the STS- 1 that operates at a rate of about 51 Mbps. These two signals are=20 made of contiguous frames that consist of transport overhead=20 (header) and payload. To solve synchronization issues, the actual=20 data is not transported directly in the payload but rather in=20 another internal frame that is allowed to float over two successive=20 SDH/SONET payloads. This internal frame is named a Virtual Container=20 (VC) in SDH and a Synchronous Payload Envelope (SPE) in SONET.=20 =20 The SDH/SONET architecture identifies three different layers, each=20 of which corresponds to one level of communication between SDH/SONET=20 equipment. These are, starting with the lowest, the regenerator=20 section/section layer, the multiplex section/line layer, and (at the=20 top) the path layer. Each of these layers in turn has its own=20 overhead (header). The transport overhead of a SDH/SONET frame is=20 mainly sub-divided in two parts that contain the regenerator=20 section/section overhead and the multiplex section/line overhead. In=20 addition, a pointer (in the form of the H1, H2 and H3 bytes)=20 indicates the beginning of the VC/SPE in the payload of the overall=20 STM/STS frame.=20 =20 The VC/SPE itself is made up of a header (the path overhead) and a=20 payload. This payload can be further subdivided into sub-elements=20 (signals) in a fairly complex way. In the case of SDH, the STM-1=20 frame may contain either one VC-4 or three multiplexed VC-3s. The=20 SONET multiplex is a pure tree, while the SDH multiplex is not a=20 pure tree, since it contains a node that can be attached to two=20 parent nodes. The structure of the SDH/SONET multiplex is shown in=20 Figure 1. In addition, we show reference points in this figure that=20 are explained in later sections.=20 =20 =20 =20 xN x1=20 STM-N<----AUG<----AU-4<--VC4<------------------------------C-4 E4=20 ^ ^=20 Ix3 Ix3=20 I I x1=20 I -----TUG-3<----TU-3<---VC-3<---I=20 I ^ C-3 DS3/E3=20 =20 Bernstein/Mannie/Sharma Expires January 2005 5=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 STM-0<------------AU-3<---VC-3<-- I ---------------------I=20 ^ I=20 Ix7 Ix7=20 I I x1=20 -----TUG-2<---TU-2<---VC-2<---C-2 DS2/T2=20 ^ ^=20 I I x3=20 I I----TU-12<---VC-12<--C-12 E1=20 I=20 I x4=20 I-------TU-11<---VC-11<--C-11 DS1/T1=20 =20 =20 xN=20 STS-N<-------------------SPE<------------------------------DS3/T3=20 ^=20 Ix7=20 I x1=20 I---VT-Group<---VT-6<----SPE DS2/T2=20 ^ ^ ^=20 I I I x2=20 I I I-----VT-3<----SPE DS1C=20 I I=20 I I x3=20 I I--------VT-2<----SPE E1=20 I=20 I x4=20 I-----------VT-1.5<--SPE DS1/T1=20 =20 =20 =20 Figure 1. SDH and SONET multiplexing structure and typical PDH=20 payload signals. =20 =20 =20 The leaves of these multiplex structures are time slots (positions)=20 of different sizes that can contain tributary signals. These=20 tributary signals (e.g. E1, E3, etc) are mapped into the leaves=20 using standardized mapping rules. In general, a tributary signal=20 does not fill a time slot completely, and the mapping rules define=20 precisely how to fill it.=20 =20 What is important for the MPLS-based control of SDH/SONET circuits=20 is to identify the elements that can be switched from an input=20 multiplex on one interface to an output multiplex on another=20 interface. The only elements that can be switched are those that can=20 be re-aligned via a pointer, i.e. a VC-x in the case of SDH and a=20 SPE in the case of SONET.=20 =20 An STM-N/STS-N signal is formed from N x STM-1/STS-1 signals via=20 byte interleaving. The VCs/SPEs in the N interleaved frames are=20 independent and float according to their own clocking. To transport=20 tributary signals in excess of the basic STM-1/STS-1 signal rates,=20 =20 Bernstein/Mannie/Sharma Expires January 2005 6=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 the VCs/SPEs can be concatenated, i.e., glued together. In this case=20 their relationship with respect to each other is fixed in time and=20 hence this relieves, when possible, an end system of any inverse=20 multiplexing bonding processes. Different types of concatenations=20 are defined in SDH/SONET.=20 =20 For example, standard SONET concatenation allows the concatenation=20 of M x STS-1 signals within an STS-N signal with M <=3D N, and M =3D = 3,=20 12, 48, 192,...). The SPEs of these M x STS-1s can be concatenated=20 to form an STS-Mc. The STS-Mc notation is short hand for describing=20 an STS-M signal whose SPEs have been concatenated.=20 =20 =20 2.3. The Current State of Circuit Establishment in SDH/SONET Networks=20 =20 In present day SDH and SONET networks, the networks are primarily=20 statically configured. When a client of an operator requests a=20 point-to-point circuit, the request sets in motion a process that=20 can last for several weeks or more. This process is composed of a=20 chain of shorter administrative and technical tasks, some of which=20 can be fully automated, resulting in significant improvements in=20 provisioning time and in operational savings. In the best case, the=20 entire process can be fully automated allowing, for example,=20 customer premise equipment (CPE) to contact a SDH/SONET switch to=20 request a circuit. Currently, the provisioning process involves the=20 following tasks.=20 =20 2.3.1. Administrative Tasks=20 =20 The administrative tasks represent a significant part of the=20 provisioning time. Most of them can be automated using IT=20 applications, e.g., a client still has to fill a form to request a=20 circuit. This form can be filled via a Web-based application and can=20 be automatically processed by the operator. A further enhancement is=20 to allow the client's equipment to coordinate with the operator's=20 network directly and request the desired circuit. This could be=20 achieved through a signaling protocol at the interface between the=20 client equipment and an operator switch, i.e., at the UNI, where=20 GMPLS signaling [6], [7], [8] can be used.=20 =20 2.3.2. Manual Operations=20 =20 Another significant part of the time may be consumed by manual=20 operations that involve installing the right interface in the CPE=20 and installing the right cable or fiber between the CPE and the=20 operator switch. This time can be especially significant when a=20 client is in a different time zone than the operator's main office.=20 This first-time connection time is frequently accounted for in the=20 overall establishment time. =20 =20 2.3.3. Planning Tool Operation=20 =20 =20 Bernstein/Mannie/Sharma Expires January 2005 7=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 Another portion of the time is consumed by planning tools that run = simulations using heuristic algorithms to find an optimized=20 placement for the required circuits. These planning tools can=20 require a significant running time, sometimes on the order of days.=20 These simulations are, in general, executed for a set of demands for=20 circuits, i.e., a batch mode, to improve the optimality of network=20 resource usage and other parameters. Today, we do not really have a=20 means to reduce this simulation time. On the contrary, to support=20 fast, on-line, circuit establishment, this phase may be invoked more=20 frequently, i.e., we will not "batch up" as many connection=20 requests before we plan out the corresponding circuits. This means=20 that the network may need to be re-optimized periodically, implying=20 that the signaling should support re-optimization with minimum=20 impact to existing services. =20 =20 2.3.4. Circuit Provisioning=20 =20 Once the first three steps discussed above have been completed, the=20 operator must provision the circuits using the outputs of the=20 planning process. The time required for provisioning varies greatly.=20 It can be fairly short, on the order of a few minutes, if the=20 operators already have tools that help them to do the provisioning=20 over heterogeneous equipment. Otherwise, the process can take days. =20 Developing these tools for each new piece of equipment and each=20 vendor is a significant burden on the service provider. A=20 standardized interface for provisioning, such as GMPLS signaling,=20 could significantly reduce or eliminate this development burden. In=20 general, provisioning is a batched activity, i.e., a few times per=20 week an operator provisions a set of circuits. GMPLS will reduce=20 this provisioning time from a few minutes to a few seconds and could=20 help to transform this periodic process into a real-time process.=20 =20 When a circuit is provisioned, it is not delivered directly to a=20 client. Rather, the operator first tests its performance and=20 behavior and if successful, delivers the circuit to the client. This=20 testing phase lasts, in general, for up to 24 hours. The operator=20 installs test equipment at each end and uses pre-defined test=20 streams to verify performance. If successful, the circuit is=20 officially accepted by the client. To speed up the verification=20 (sometimes known as "proving") process, it would be necessary to=20 support some form of automated performance testing.=20 =20 2.4. Centralized Approach versus Distributed Approach=20 =20 Whether a centralized approach or a distributed approach will be=20 used to control SDH/SONET networks is an open question, since each=20 approach has its merits. The application of MPLS to SDH/SONET=20 networks does not preclude either model, although MPLS is itself a=20 distributed technology. =20 =20 The basic tradeoff between the centralized and distributed=20 approaches is that of complexity of the network elements versus that=20 of the network management system (NMS). Since adding functionality=20 =20 Bernstein/Mannie/Sharma Expires January 2005 8=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 to existing SDH/SONET network elements may not be possible, a=20 centralized approach may be needed in some cases. The main issue=20 facing centralized control via an NMS is one of scalability. For=20 instance, this approach may be limited in the number of network=20 elements that can be managed (e.g., one thousand). It is, therefore,=20 quite common for operators to deploy several NMS=92s in parallel at=20 the Network Management Layer, each managing a different zone. In=20 that case, however, a Service Management Layer must be built on the=20 top of several individual NMS=92s to take care of end-to-end = on-demand=20 services. On the other hand, in a complex and/or dense network,=20 restoration could be faster with a distributed approach than with a=20 centralized approach.=20 =20 Let's now look at how the major control plane functional components=20 are handled via the centralized and distributed approaches:=20 =20 2.4.1. Topology Discovery and Resource Dissemination=20 =20 Currently NMS's maintain a consistent view of all the networking=20 layers under their purview. This can include the physical topology,=20 such as information about fibers and ducts. Since most of this=20 information is entered manually, it remains error prone.=20 =20 A link state GMPLS routing protocol, on the other hand, could=20 perform automatic topology discovery and dissemination the topology=20 as well as resource status. This information would be available to=20 all nodes in the network, and hence also the NMS. Hence one can=20 look at a continuum of functionality between manually provisioned=20 topology information (of which there will always be some) and fully=20 automated discovery and dissemination as in a link state protocol.=20 Note that, unlike the IP datagram case, a link state routing=20 protocol applied to the SDH/SONET network does not have any service=20 impacting implications. This is because in the SDH/SONET case, the=20 circuit is source-routed (so there can be no loops), and no traffic=20 is transmitted until a circuit has been established, and an=20 acknowledgement received at the source.=20 =20 2.4.2. Path Computation (Route Determination)=20 =20 In the SDH/SONET case, unlike the IP datagram case, there is no need=20 for network elements to all perform the same path calculation [9]. =20 In addition, path determination is an area for vendors to provide a=20 potentially significant value addition in terms of network=20 efficiency, reliability, and service differentiation. In this sense,=20 a centralized approach to path computation may be easier to operate=20 and upgrade. For example, new features such as new types of path=20 diversity or new optimization algorithms can be introduced with a=20 simple NMS software upgrade. On the other hand, updating switches=20 with new path computation software is a more complicated task. In=20 addition, many of the algorithms can be fairly computationally=20 intensive and may be completely unsuitable for the embedded=20 processing environment available on most switches. In restoration=20 =20 Bernstein/Mannie/Sharma Expires January 2005 9=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 scenarios, the ability to perform a reasonably sophisticated level=20 of path computation on the network element can be particularly=20 useful for restoring traffic during major network faults.=20 =20 2.4.3. Connection Establishment (Provisioning)=20 =20 The actual setting up of circuits, i.e., a coupled collection of=20 cross connects across a network, can be done either via the NMS=20 setting up individual cross connects or via a "soft permanent LSP"=20 (SPLSP) type approach. In the SPLSP approach, the NMS may just kick=20 off the connection at the "ingress" switch with GMPLS signaling=20 setting up the connection from that point onward. Connection=20 establishment is the trickiest part to distribute, however, since=20 errors in the connection setup/tear down process are service=20 impacting. =20 =20 The table below compares the two approaches to connection=20 establishment.=20 =20 Distributed approach Centralized approach=20 =20 Packet-based control plane Management plane like TMN or=20 (like MPLS or PNNI) useful? SNMP =20 Do we really need it? Being Always needed! Already there,=20 added/specified by several proven and understood.=20 standardization bodies=20 =20 High survivability (e.g. in Potential single point(s) of=20 case of partition) failure=20 =20 Distributed load Bottleneck: #requests and=20 actions to/from NMS=20 =20 Individual local routing Centralized routing decision,=20 decision can be done per block of=20 requests=20 Routing scalable as for the Assumes a few big=20 Internet administrative domains=20 =20 Complex to change routing Very easy local upgrade (non-=20 protocol/algorithm intrusive)=20 =20 Requires enhanced routing Better consistency=20 protocol (traffic=20 engineering)=20 =20 Ideal for inter-domain Not inter-domain friendly=20 =20 Suitable for very dynamic For less dynamic demands=20 demands (longer lived)=20 =20 Probably faster to restore, Probably slower to restore,but=20 =20 Bernstein/Mannie/Sharma Expires January 2005 10=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 but more difficult to have could effect reliable=20 reliable restoration. restoration.=20 =20 High scalability Limited scalability: #nodes,=20 (hierarchical) links, circuits, messages=20 =20 Planning (optimization) Planning is a background=20 harder to achieve centralized activity=20 =20 Easier future integration=20 with other control plane=20 layers=20 Table 1. Qualitative comparison between centralized and distributed=20 approaches.=20 =20 =20 2.5. Why SDH/SONET will not Disappear Tomorrow=20 =20 As IP traffic becomes the dominant traffic transported over the=20 transport infrastructure, it is useful to compare the statistical=20 multiplexing of IP with the time division multiplexing of SDH and=20 SONET. =20 =20 Consider, for instance, a scenario where IP over WDM is used=20 everywhere and lambdas are optically switched. In such a case, a=20 carrier's carrier would sell dynamically controlled lambdas with=20 each customers building their own IP backbones over these lambdas.=20 =20 This simple model implies that a carrier would sell lambdas instead=20 of bandwidth. The carrier=92s goal will be to maximize the number of=20 wavelengths/lambdas per fiber, with each customer having to fully=20 support the cost for each end-to-end lambda whether or not the=20 wavelength is fully utilized. Although, in the near future, we may=20 have technology to support up to several hundred lambdas per fiber,=20 a world where lambdas are so cheap and abundant that every=20 individual customer buys them, from one point to any other point,=20 appears an unlikely scenario today.=20 =20 More realistically, there is still room for a multiplexing=20 technology that provides circuits with a lower granularity than a=20 wavelength. (Not everyone needs a minimum of 10 Gbps or 40 Gbps per=20 circuit, and IP does not yet support all telecom applications in=20 bulk efficiently.)=20 =20 SDH and SONET possess a rich multiplexing hierarchy that permits=20 fairly fine granularity and that provides a very cheap and simple=20 physical separation of the transported traffic between circuits,=20 i.e., QoS. Moreover, even IP datagrams cannot be transported=20 directly over a wavelength. A framing or encapsulation is always=20 required to delimit IP datagrams. The Total Length field of an IP=20 header cannot be trusted to find the start of a new datagram, since=20 it could be corrupted and would result in a loss of synchronization.=20 The typical framing used today for IP over DWDM is defined in=20 =20 Bernstein/Mannie/Sharma Expires January 2005 11=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 RFC1619/RFC2615 and known as POS (Packet Over SDH/SONET), i.e., IP=20 over PPP (in HDLC-like format) over SDH/SONET. SDH and SONET are=20 actually efficient encapsulations for IP. For instance, with an=20 average IP datagram length of 350 octets, an IP over GBE=20 encapsulation using an 8B/10B encoding results in 28% overhead, an=20 IP/ATM/SDH encapsulation results in 22% overhead and an IP/PPP/SDH=20 encapsulation results in only 6% overhead. =20 =20 Any encapsulation of IP over WDM should, in the data plane, at least=20 provide error monitoring capabilities (to detect signal=20 degradation); error correction capabilities, such as FEC (Forward=20 Error Correction) that are particularly needed for ultra long haul=20 transmission; sufficient timing information, to allow robust=20 synchronization (that is, to detect the beginning of a packet). In=20 the case where associated signaling is used (that is the control and=20 data plane topologies are congruent) the encapsulation should also=20 provide the capacity to transport signaling, routing and management=20 messages, in order to control the optical switches. Rather SDH and=20 SONET cover all these aspects natively, except FEC, which tends to=20 be supported in a proprietary way. (We note, however, that=20 associated signaling is not a requirement for the GMPLS-based=20 control of SDH/SONET networks. Rather, it is just one option. Non- associated signaling, as would happen with an out-of-band control=20 plane network is another equally valid option.)=20 =20 Since IP encapsulated in SDH/SONET is efficient and widely used, the=20 only real difference between an IP over WDM network and an IP over=20 SDH over WDM network is the layers at which the switching or=20 forwarding can take place. In the first case, it can take place at=20 the IP and optical layers. In the second case, it can take place at=20 the IP, SDH/SONET, and optical layers. =20 =20 Almost all transmission networks today are based on SDH or SONET. A=20 client is connected either directly through an SDH or SONET=20 interface or through a PDH interface, the PDH signal being=20 transported between the ingress and the egress interfaces over SDH=20 or SONET. What we are arguing here is that it makes sense to do=20 switching or forwarding at all these layers.=20 =20 =20 3. GMPLS Applied to SDH/SONET=20 =20 3.1. Controlling the SDH/SONET Multiplex=20 =20 Controlling the SDH/SONET multiplex implies deciding which of the=20 different switchable components of the SDH/SONET multiplex do we=20 wish to control using GMPLS. Essentially, every SDH/SONET element=20 that is referenced by a pointer can be switched. These component=20 signals are the VC-4, VC-3, VC-2, VC-12 and VC-11 in the SDH case;=20 and the VT and STS SPEs in the SONET case. The SPEs in SONET do not=20 have individual names, although they can be referred to simply as=20 VT-N SPEs. We will refer to them by identifying the structure that=20 contains them, namely STS-1, VT-6, VT-3, VT-2 and VT-1.5. =20 =20 Bernstein/Mannie/Sharma Expires January 2005 12=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 =20 The STS-1 SPE corresponds to a VC-3, a VT-6 SPE corresponds to a VC- = =20 2, a VT-2 SPE corresponds to a VC-12, and a VT-1.5 SPE corresponds = to a VC-11. The SONET VT-3 SPE has no correspondence in SDH, however = =20 SDH's VC-4 corresponds to SONET's STS-3c SPE. =20 =20 In addition, it is possible to concatenate some of the structures=20 that contain these elements to build larger elements. For instance,=20 SDH allows the concatenation of X contiguous AU-4s to build a VC-4- Xc and of m contiguous TU-2s to build a VC-2-mc. In that case, a VC- 4-Xc or a VC-2-mc can be switched and controlled by GMPLS. Note that=20 SDH also defines virtual (non-contiguous) concatenation of TU- 2s,=20 but in that case each constituent VC-2 is switched individually.=20 =20 3.2. SDH/SONET LSR and LSP Terminology=20 =20 Let a SDH or SONET Terminal Multiplexer (TM), Add-Drop Multiplexer = (ADM) or cross-connect (i.e. a switch) be called an SDH/SONET LSR. A = =20 SDH/SONET path or circuit between two SDH/SONET LSRs now becomes a = GMPLS LSP. An SDH/SONET LSP is a logical connection between the=20 point at which a tributary signal (client layer) is adapted into its=20 virtual container, and the point at which it is extracted from its=20 virtual container.=20 =20 To establish such an LSP, a signaling protocol is required to=20 configure the input interface, switch fabric, and output interface=20 of each SDH/SONET LSR along the path. An SDH/SONET LSP can be point-=20 to-point or point-to-multipoint, but not multipoint-to-point, since=20 no merging is possible with SDH/SONET signals.=20 =20 To facilitate the signaling and setup of SDH/SONET circuits, an=20 SDH/SONET LSR must, therefore, identify each possible signal=20 individually per interface, since each signal corresponds to a=20 potential LSP that can be established through the SDH/SONET LSR. It=20 turns out, however, that not all SDH signals correspond to an LSP=20 and therefore not all of them need be identified. In fact, only=20 those signals that can be switched need identification.=20 =20 4. Decomposition of the MPLS Circuit-Switching Problem Space=20 =20 Although those familiar with MPLS may be familiar with its=20 application in a variety of application areas, e.g., ATM, Frame=20 Relay, and so on, here we quickly review its decomposition when=20 applied to the optical switching problem space.=20 =20 (i) Information needed to compute paths must be made globally =20 available throughout the network. Since this is done via the link = state routing protocol, any information of this nature must either=20 be in the existing link state advertisements (LSAs) or the LSAs must=20 be supplemented to convey this information. For example, if it is=20 desirable to offer different levels of service in a network based on=20 whether a circuit is routed over SDH/SONET lines that are ring=20 protected versus being routed over those that are not ring protected=20 =20 Bernstein/Mannie/Sharma Expires January 2005 13=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 (differentiation based on reliability), the type of protection on a=20 SDH/SONET line would be an important topological parameter that=20 would have to be distributed via the link state routing protocol.=20 =20 (ii) Information that is only needed between two "adjacent" switches = =20 for the purposes of connection establishment is appropriate for =20 distribution via one of the label distribution protocols. In fact, =20 this information can be thought of as the "virtual" label. For=20 example, in SONET networks, when distributing information to=20 switches concerning an end-to-end STS-1 path traversing a network,=20 it is critical that adjacent switches agree on the multiplex entry=20 used by this STS-1 (but this information is only of local=20 significance between those two switches). Hence, the multiplex entry=20 number in this case can be used as a virtual label. Note that the=20 label is virtual, in that it is not appended to the payload in any=20 way, but it is still a label in the sense that it uniquely=20 identifies the signal locally on the link between the two switches.=20 =20 (iii) Information that all switches in the path need to know about a=20 circuit will also be distributed via the label distribution=20 protocol. Examples of such information include bandwidth, priority,=20 and preemption for instance.=20 =20 (iv) Information intended only for end systems of the connection.=20 Some of the payload type information in may fall into this category. = =20 5. GMPLS Routing for SDH/SONET=20 =20 Modern transport networks based on SDH/SONET excel at=20 interoperability in the performance monitoring (PM) and fault=20 management (FM) areas [10], [11]. They do not, however, inter- operate in the areas of topology discovery or resource status. =20 Although link state routing protocols, such as IS-IS and OSPF, have=20 been used for some time in the IP world to compute destination-based=20 next hops for routes (without routing loops), they are particularly=20 valuable for providing timely topology and network status=20 information in a distributed manner, i.e., at any network node. If=20 resource utilization information is disseminated along with the link=20 status (as was done in ATM's PNNI routing protocol) then a very=20 complete picture of network status is available to a network=20 operator for use in planning, provisioning and operations.=20 =20 The information needed to compute the path a connection will take=20 through a network is important to distribute via the routing=20 protocol. In the TDM case, this information includes, but is not=20 limited to: the available capacity of the network links, the=20 switching and termination capabilities of the nodes and interfaces,=20 and the protection properties of the link. This is what is being=20 proposed in the GMPLS extensions to IP routing protocols=20 [12],[13],[14].=20 =20 When applying routing to circuit switched networks it is useful to=20 compare and contrast this situation with the datagram routing case=20 =20 Bernstein/Mannie/Sharma Expires January 2005 14=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 [15]. In the case of routing datagrams, all routes on all nodes=20 must be calculated exactly the same to avoid loops and "black=20 holes". In circuit switching, this is not the case since routes are=20 established per circuit and are fixed for that circuit. Hence,=20 unlike the datagram case, routing is not service impacting in the=20 circuit switched case. This is helpful, because, to accommodate the=20 optical layer, routing protocols need to be supplemented with new=20 information, much more than the datagram case. This information is=20 also likely to be used in different ways for implementing different=20 user services. Due to the increase in information transferred in=20 the routing protocol, it may be useful to separate the relatively=20 static parameters concerning a link from those that may be subject=20 to frequent changes. The current GMPLS routing extensions =20 [12],[13],[14] do not make such a separation, however. =20 =20 Indeed, from the carriers' perspective, the up-to-date dissemination=20 of all link properties is essential and desired, and the use of a=20 link-state routing protocol to distribute this information provides=20 timely and efficient delivery. If GMPLS-based networks got to the=20 point that bandwidth updates happen very frequently, it makes sense,=20 from an efficiency point of view, to separate them out for update. =20 This situation is not yet seen in actual networks; however, if GMPLS=20 signaling is put into widespread use then the need could arise.=20 =20 =20 5.1. Switching Capabilities=20 =20 The main switching capabilities that characterize a SDH/SONET end=20 system and thus need to be advertised via the link state routing=20 protocol are: the switching granularity, supported forms of=20 concatenation, and the level of transparency.=20 =20 5.1.1. Switching Granularity=20 =20 From references [4],[5] and the overview section on SDH/SONET we see=20 that there are a number of different signals that compose the=20 SDH/SONET hierarchies. Those signals that are referenced via a=20 pointer, i.e., the VCs in SDH and the SPEs in SONET are those that=20 will actually be switched within a SDH/SONET network. These signals=20 are subdivided into lower order signals and higher order signals as=20 shown in Table 2.=20 =20 Table 2. SDH/SONET switched signal groupings.=20 =20 Signal Type SDH SONET=20 =20 Lower Order VC-11, VC-12, VC-2 VT-1.5 SPE, VT-2 SPE,=20 VT-3 SPE, VT-6 SPE=20 =20 Higher VC-3, VC-4 STS-1 SPE, STS-3c SPE=20 Order=20 =20 =20 Bernstein/Mannie/Sharma Expires January 2005 15=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 Manufacturers today differ in the types of switching capabilities=20 their systems support. Many manufacturers today switch signals=20 starting at VC-4 for SDH or STS-1 for SONET (i.e. the basic frame)=20 and above (see Section 5.1.2 on concatenation), but they do not=20 switch lower order signals. Some of them only allow the switching of=20 entire aggregates (concatenated or not) of signals such as 16 VC-4s,=20 i.e. a complete STM-16, and nothing finer. Some go down to the VC-3=20 level for SDH. Finally, some offer highly integrated switches that=20 switch at the VC-3/STS-1 level down to lower order signals such as=20 VC-12s. In order to cover the needs of all manufacturers and=20 operators, GMPLS signaling [6],[7],[8] covers both higher order and=20 lower order signals. =20 =20 5.1.2. Signal Concatenation Capabilities=20 =20 As stated in the SDH/SONET overview, to transport tributary signals = =20 with rates in excess of the basic STM-1/STS-1 signal, the VCs/SPEs=20 can be concatenated, i.e., glued together. Different types of=20 concatenations are defined: contiguous standard concatenation,=20 arbitrary concatenation, and virtual concatenation with different=20 rules concerning their size, placement, and binding.=20 =20 Standard SONET concatenation allows the concatenation of M x STS-1 = signals within an STS-N signal with M <=3D N, and M =3D 3, 12, 48, = 192,=20 ...). The SPEs of these M x STS-1s can be concatenated to form an=20 STS-Mc. The STS-Mc notation is short hand for describing an STS-M=20 signal whose SPEs have been concatenated. The multiplexing=20 procedures for SDH and SONET are given in references [4] and [5],=20 respectively. Constraints are imposed on the size of STS-Mc signals,=20 i.e., they must be a multiple of 3, and on their starting location=20 and interleaving. =20 =20 This has the following advantages: (a) restriction to multiples of 3=20 helps with SDH compatibility (there is no STS-1 equivalent signal in=20 SDH); (b) the restriction to multiples of 3 reduces the number of=20 connection types; (c) the restriction on the placement and=20 interleaving could allow more compact representation of the "label"; = =20 The major disadvantages of these restrictions are:=20 (a) Limited flexibility in bandwidth assignment (somewhat inhibits = finer grained traffic engineering). (b) The lack of flexibility in = starting time slots for STS-Mc signals and in their interleaving =20 (where the rest of the signal gets put in terms of STS-1 slot =20 numbers) leads to the requirement for re-grooming (due to bandwidth = =20 fragmentation).=20 =20 Due to these disadvantages some SONET framer manufacturers now=20 support "flexible" or arbitrary concatenation, i.e., no restrictions=20 on the size of an STS-Mc (as long as M <=3D N) and no constraints on=20 the STS-1 timeslots used to convey it, i.e., the signals can use any=20 combination of available time slots.=20 =20 =20 Bernstein/Mannie/Sharma Expires January 2005 16=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 Standard and flexible concatenations are network services, while=20 virtual concatenation is a SDH/SONET end-system service approved by=20 the Committee T1 of ANSI [5] and the ITU-T [4]. The essence of this=20 service is to have SDH/SONET end systems "glue" together the VCs or=20 SPEs of separate signals rather than requiring that he signals be=20 carried through the network as a single unit. In one example of=20 virtual concatenation, two end systems supporting this feature could=20 essentially "inverse multiplex" two STS-1s into a STS-1-2v for the=20 efficient transport of 100 Mbps Ethernet traffic. Note that this=20 inverse multiplexing process (or virtual concatenation) can be=20 significantly easier to implement with SDH/SONET signals rather than=20 packets, because timing and in-order delivery of frames is more=20 easily ensured with SDH/SONET signals than it is with packets, where=20 more sophisticated techniques are needed.=20 =20 Since virtual concatenation is provided by end systems, it is=20 compatible with existing SDH/SONET networks. Virtual concatenation=20 is defined for both higher order signals and low order signals. =20 Table 3 shows the nomenclature and capacity for several lower-order=20 virtually concatenated signals contained within different higher- order signals.=20 =20 Table 3 Capacity of Virtually Concatenated VTn-Xv (9/G.707)=20 =20 Carried In X Capacity In steps=20 of=20 =20 VT1.5/ STS-1/VC-3 1 to 28 1600kbit/s to 1600kbit/s=20 VC-11-Xv 44800kbit/s=20 =20 VT2/ STS-1/VC-3 1 to 21 2176kbit/s to 2176kbit/s=20 VC-12-Xv 45696kbit/s=20 =20 VT1.5/ STS-3c/VC-4 1 to 64 1600kbit/s to 1600kbit/s=20 VC-11-Xv 102400kbit/s=20 =20 VT2/ STS-3c/VC-4 1 to 63 2176kbit/s to 2176kbit/s=20 VC-12-Xv 137088kbit/s=20 =20 =20 5.1.3. SDH/SONET Transparency=20 =20 The purposed of SDH/SONET is to carry its payload signals in a=20 transparent manner. This can include some of the layers of SONET=20 itself. For example, situations where the path overhead can never be=20 touched, since it actually belongs to the client. This was another=20 reason for not coding an explicit label in the SDH/SONET path=20 overhead. It may be useful to transport, multiplex and/or switch=20 lower layers of the SONET signal transparently.=20 =20 As mentioned in the introduction, SONET overhead is broken into=20 three layers: Section, Line and Path. Each of these layers is=20 concerned with fault and performance monitoring. The Section=20 =20 Bernstein/Mannie/Sharma Expires January 2005 17=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 overhead is primarily concerned with framing, while the Line=20 overhead is primarily concerned with multiplexing and protection. To=20 perform pipe multiplexing (that is, multiplexing of 50 Mbps or 150=20 Mbps chunks), a SONET network element should be line terminating.=20 However, not all SONET multiplexers/switches perform SONET pointer=20 adjustments on all the STS-1s contained within a higher order SONET=20 signal passing through them. Alternatively, if they perform pointer=20 adjustments, they do not terminate the line overhead. For example, a=20 multiplexer may take four SONET STS-48 signals and multiplex them=20 onto an STS-192 without performing standard line pointer adjustments=20 on the individual STS-1s. This can be looked at as a service since=20 it may be desirable to pass SONET signals, like an STS-12 or STS-48,=20 with some level of transparency through a network and still take=20 advantage of TDM technology. Transparent multiplexing and switching=20 can also be viewed as a constraint, since some multiplexers and=20 switches may not switch with as fine a granularity as others. Table=20 4 summarizes the levels of SDH/SONET transparency.=20 =20 Table 4. SDH/SONET transparency types and their properties.=20 =20 Transparency Type Comments=20 =20 Path Layer (or Line Standard higher order SONET path=20 Terminating) switching. Line overhead is terminated =20 or modified.=20 =20 Line Level (or Section Preserves line overhead and switches =20 Terminating) the entire line multiplex as a whole. =20 Section overhead is terminated or =20 modified.=20 =20 Section layer Preserves all section overhead, =20 Basically does not modify/terminate=20 any of the SDH/SONET overhead bits.=20 =20 5.2. Protection=20 =20 SONET and SDH networks offer a variety of protection options at both=20 the SONET line (SDH multiplex section) and SDH/SONET path level=20 [10],[11]. Standardized SONET line level protection techniques=20 include: Linear 1+1 and linear 1:N automatic protection switching=20 (APS) and both two-fiber and four-fiber bi-directional line switched=20 rings (BLSRs). At the path layer, SONET offers uni-directional path=20 switched ring protection. Likewise, standardized SDH multiplex=20 section protection techniques include linear 1+1 and 1:N automatic p=20 protection switching and both two-fiber and four-fiber bi- directional MS-SPRings (Multiplex Section-Shared Protection Rings).=20 At the path layer, SDH offers SNCP (sub-network connection=20 protection) ring protection.=20 =20 Both ring and 1:N line protection also allow for "extra traffic" to=20 be carried over the protection line when that line is not being=20 used, i.e., when it is not carrying traffic for a failed working=20 =20 Bernstein/Mannie/Sharma Expires January 2005 18=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 line. These protection methods are summarized in Table 5. It should=20 be noted that these protection methods are completely separate from=20 any MPLS layer protection or restoration mechanisms.=20 =20 Table 5. Common SDH/SONET protection mechanisms.=20 =20 Protection Type Extra Comments=20 Traffic=20 Optionally=20 Supported=20 =20 1+1 No Requires no coordination=20 Unidirectional between the two ends of the=20 circuit. Dedicated=20 protection line.=20 =20 1+1 Bi- No Coordination via K byte=20 directional protocol. Lines must be=20 consistently configured.=20 Dedicated protection line.=20 =20 1:1 Yes Dedicated protection.=20 =20 1:N Yes One Protection line shared=20 by N working lines = =20 =20 4F-BLSR (4 Yes Dedicated protection, with=20 fiber bi- alternative ring path.=20 directional=20 line switched=20 ring)=20 =20 2F-BLSR (2 Yes Dedicated protection, with=20 fiber bi- alternative ring path=20 directional=20 line switched=20 ring)=20 =20 UPSR (uni- No Dedicated protection via=20 directional alternative ring path.=20 path switched Typically used in access=20 ring) networks.=20 =20 =20 It may be desirable to route some connections over lines that=20 support protection of a given type, while others may be routed over=20 unprotected lines, or as "extra traffic" over protection lines.=20 Also, to assist in the configuration of these various protection=20 methods it can be extremely valuable to advertise the link=20 protection attributes in the routing protocol, as is done in the=20 current GMPLS routing protocols. For example, suppose that a 1:N=20 protection group is being configured via two nodes. One must make=20 sure that the lines are "numbered the same" with respect to both=20 =20 Bernstein/Mannie/Sharma Expires January 2005 19=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 ends of the connection or else the APS (K1/K2 byte) protocol will=20 not correctly operate.=20 =20 Table 6. Parameters defining protection mechanisms.=20 =20 =20 Protection Comments=20 Related Link=20 Information=20 =20 =20 Protection Type Indicates which of the protection types=20 delineated in Table 5.=20 =20 Protection Indicates which of several protection=20 Group Id groups (linear or ring) that a node belongs=20 to. Must be unique for all groups that a=20 node participates in=20 =20 Working line Important in 1:N case and to differentiate=20 number between working and protection lines=20 =20 Protection line Used to indicate if the line is a=20 number protection line.=20 =20 Extra Traffic Yes or No=20 Supported=20 =20 Layer If this protection parameter is specific to=20 SONET then this parameter is unneeded,=20 otherwise it would indicate the signal=20 layer that the protection is applied.=20 =20 =20 An open issue concerning protection is the extent of information=20 regarding protection that must be disseminated. The contents of=20 Table 6 represent one extreme while a simple enumerated list of:=20 Extra-Traffic/Protection line, Unprotected, Shared (1:N)/Working=20 line, Dedicated (1:1, 1+1)/Working Line, Enhanced (Ring) /Working=20 Line, represents the other.=20 =20 There is also a potential implication for link bundling [16], [18]=20 that is, for each link, the routing protocol could advertise whether=20 that link is a working or protection link and possibly some=20 parameters from Table 6. A possible drawback of this scheme is that=20 the routing protocol would be burdened with advertising properties=20 even for those protection links in the network that could not, in=20 fact, be used for routing working traffic, e.g., dedicated=20 protection links. An alternative method would be to bundle the=20 working and protection links together, and advertise the bundle=20 instead. Now, for each bundled link, the protocol would have to=20 advertise the amount of bandwidth available on its working links, as=20 well as the amount of bandwidth available on those protection links=20 =20 Bernstein/Mannie/Sharma Expires January 2005 20=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 within the bundle that were capable of carrying "extra traffic."=20 This would reduce the amount of information to be advertised. An=20 issue here would be to decide which types of working and protection=20 links to bundle together. For instance, it might be preferable to=20 bundle working links (and their corresponding protection links) that=20 are "shared" protected separately from working links that are=20 "dedicated" protected.=20 =20 =20 5.3. Available Capacity Advertisement=20 =20 Each SDH/SONET LSR must maintain an internal table per interface=20 that indicates each signal in the multiplex structure that is=20 allocated at that interface. This internal table is the most=20 complete and accurate view of the link usage and available capacity.=20 =20 For use in path computation, this information needs to be advertised=20 in some way to all others SDH/SONET LSRs in the same domain. There=20 is a trade off to be reached concerning: the amount of detail in the=20 available capacity information to be reported via a link state=20 routing protocol, the frequency or conditions under which this=20 information is updated, the percentage of connection establishments=20 that are unsuccessful on their first attempt due to the granularity=20 of the advertised information, and the extent to which network=20 resources can be optimized. There are different levels of=20 summarization that are being considered today for the available=20 capacity information. At one extreme, all signals that are allocated=20 on an interface could be advertised, while at the other extreme, a=20 single aggregated value of the available bandwidth per link could be=20 advertised.=20 =20 Consider first the relatively simple structure of SONET and its most = =20 common current and planned usage. DS1s and DS3s are the signals most = =20 often carried within a SONET STS-1. Either a single DS3 occupies =20 the STS-1 or up to 28 DS1s (4 each within the 7 VT groups) are =20 carried within the STS-1. With a reasonable VT1.5 placement =20 algorithm within each node it may be possible to just report on =20 aggregate bandwidth usage in terms of number of whole STS-1s =20 (dedicated to DS3s) used and the number of STS-1s dedicated to =20 carrying DS1s allocated for this purpose. This way a network =20 optimization program could try to determine the optimal placement of = =20 DS3s and DS1s to minimize wasted bandwidth due to half-empty STS-1s = =20 at various places within the transport network. Similarly consider=20 the set of super rate SONET signals (STS-Nc). If the links between=20 the two switches support flexible concatenation then the reporting=20 is particularly straightforward since any of the STS-1s within an=20 STS-M can be used to comprise the transported STS- Nc. However, if=20 only standard concatenation is supported then reporting gets=20 trickier since there are constraints on where the STS-1s can be=20 placed. SDH has still more options and constraints, hence it is not=20 yet clear which is the best way to advertise bandwidth resource=20 availability/usage in SDH/SONET. At present, the GMPLS routing=20 protocol extensions define minimum and maximum values for available=20 =20 Bernstein/Mannie/Sharma Expires January 2005 21=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 bandwidth, which allows a remote node to make some deductions about=20 the amount of capacity available at a remote link and the types of=20 signals it can accommodate. However, due to the multiplexed nature=20 of the signals, the authors are of the opinion that reporting of=20 bandwidth particular to signal types rather than as a single=20 aggregate bit rate is probably very desirable. For more details on=20 why this is so, we refer the reader to ITU-T G.7715.1 [19] and to=20 Chapter 12 of [20].=20 =20 5.4. Path Computation=20 =20 Although a link state routing protocol can be used to obtain network = =20 topology and resource information, this does not imply the use of an = =20 "open shortest path first" route [9]. The path must be open in the=20 sense that the links must be capable of supporting the desired=20 signal type and that capacity must be available to carry the=20 signal. Other constraints may include hop count, total delay=20 (mostly propagation), and underlying protection. In addition, it may=20 be desirable to route traffic in order to optimize overall network=20 capacity, or reliability, or some combination of the two. Dikstra's=20 algorithm computes the shortest path with respect to link weights=20 for a single connection at a time. This can be much different than=20 the paths that would be selected in response to a request to set up=20 a batch of connections between a set of endpoints in order to=20 optimize network link utilization. One can think of this along the=20 lines of global or local optimization of the network in time. =20 =20 Due to the complexity of some of the connection routing algorithms=20 (high dimensionality, non-linear integer programming problems) and=20 various criteria by which one may optimize a network, it may not be = =20 possible or desirable to run these algorithms on network nodes. =20 However, it may still be desirable to have some basic path =20 computation ability running on the network nodes, particularly for=20 use during restoration situations. Such an approach is in line with=20 the use of MPLS for traffic engineering, but is much different than=20 typical OSPF or IS-IS usage where all nodes must run the same=20 routing algorithm. =20 =20 =20 6. LSP Provisioning/Signaling for SDH/SONET=20 =20 Traditionally, end-to-end circuit connections in SDH/SONET networks = have been set up via network management systems (NMSs), which issue = commands (usually under the control of a human operator) to the =20 various network elements involved in the circuit, via an equipment =20 vendor's element management system (EMS). Very little multi-vendor =20 interoperability has been achieved via management systems. Hence,=20 end-to-end circuits in a multi-vendor environment typically require = the use of multiple management systems and the infamous configuration=20 via "yellow sticky notes". As discussed in Section 3, a common=20 signaling protocol, such as RSVP with TE extensions or CR- LDP=20 appropriately extended for circuit switching applications, could=20 therefore help to solve these interoperability problems. In this=20 =20 Bernstein/Mannie/Sharma Expires January 2005 22=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 section, we examine the various components involved in the automated=20 provisioning of SDH/SONET LSPs.=20 =20 6.1. What do we Label in SDH/SONET? Frames or Circuits?=20 =20 MPLS was initially introduced to control asynchronous technologies = like IP, where a label was attached to each individual block of =20 data, such as an IP packet or a Frame Relay frame. SONET and SDH,=20 however, are synchronous technologies that define a multiplexing =20 structure (see Section 4), which we referred to as the SDH (or =20 SONET) multiplex. This multiplex involves a hierarchy of signals,=20 lower order signals embedded within successive higher order ones=20 (see Fig. 1). Thus, depending on its level in the hierarchy, each=20 signal consists of frames that repeat periodically, with a certain=20 number of byte time slots per frame.=20 =20 The question then arises: is it these frames that we label in GMPLS? = =20 It will be seen in what follows that each SONET or SDH "frame"=20 need not have its own label, nor is it necessary to switch frames =20 individually. Rather, the unit that is switched is a "flow"=20 comprised of a continuous sequence of time slots that appear at a=20 given position in a frame. That is, we switch an individual SONET or=20 SDH signal, and a label associated with each given signal.=20 =20 For instance, the payload of an SDH STM-1 frame does not fully=20 contain a complete unit of user data. In fact, the user data is=20 contained in a virtual container (VC) that is allowed to float over=20 two contiguous frames for synchronization purposes. The H1-H2-H3 Au- n pointer bytes in the SDH overhead indicates the beginning of the=20 VC in the payload. Thus, frames are now inter-related, since each=20 consecutive pair may share a common virtual container. From the=20 point of view of GMPLS, therefore, it is not the successive frames=20 that are treated independently or labeled, but rather the entire=20 user signal. An identical argument applies to SONET.=20 =20 Observe also that the GMPLS signaling used to control the SDH/SONET = =20 multiplex must honor its hierarchy. In other words, the SDH/SONET =20 layer should not be viewed as homogeneous and flat, because this =20 would limit the scope of the services that SDH/SONET can provide.=20 Instead, GMPLS tunnels should be used to dynamically and=20 hierarchically control the SDH/SONET multiplex. For example, one=20 unstructured VC-4 LSP may be established between two nodes, and=20 later lower order LSPs (e.g. VC-12) may be created within that=20 higher order LSP. This VC-4 LSP can, in fact, be established=20 between two non-adjacent internal nodes in an SDH network, and later=20 advertised by a routing protocol as a new (virtual) link called a=20 Forwarding Adjacency (FA) [17].=20 =20 A SDH/SONET-LSR will have to identify each possible signal=20 individually per interface to fulfill the GMPLS operations. In order=20 to stay transparent the LSR obviously should not touch the SDH/SONET=20 overheads; this is why an explicit label is not encoded in the=20 SDH/SONET overheads. Rather, a label is associated with each=20 =20 Bernstein/Mannie/Sharma Expires January 2005 23=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 individual signal. This approach is similar to the one considered=20 for lambda switching, except that it is more complex, since SONET=20 and SDH define a richer multiplexing structure. Therefore a label=20 is associated with each signal, and is locally unique for each=20 signal at each interface. This signal could, and will most probably,=20 occupy different time-slots at different interfaces.=20 =20 6.2. Label Structure in SDH/SONET=20 =20 The signaling protocol used to establish an SDH/SONET LSP must have = =20 specific information elements in it to map a label to the particular = =20 signal type that it represents, and to the position of that signal=20 in the SDH/SONET multiplex. As we will see shortly, with a =20 carefully chosen label structure, the label itself can be made to =20 function as this information element.=20 =20 In general, there are two ways to assign labels for signals between=20 neighboring SDH/SONET LSRs. One way is for the labels to be=20 allocated completely independently of any SDH/SONET semantics; e.g.=20 labels could just be unstructured 16 or 32 bit numbers. In that=20 case, in the absence of appropriate binding information, a label=20 gives no visible information about the flow that it represents. From=20 a management and debugging point of view, therefore, it becomes=20 difficult to match a label with the corresponding signal, since , as=20 we saw in Section 6.1, the label is not coded in the SDH/SONET=20 overhead of the signal.=20 =20 Another way is to use the well-defined and finite structure of the=20 SDH/SONET multiplexing tree to devise a signal numbering scheme that=20 makes use of the multiplex as a naming tree, and assigns each=20 multiplex entry a unique associated value. This allows the unique=20 identification of each multiplex entry (signal) in terms of its type=20 and position in the multiplex tree. By using this multiplex entry=20 value itself as the label, we automatically add SDH/SONET semantics=20 to the label! Thus, simply by examining the label, one can now=20 directly deduce the signal that it represents, as well as its=20 position in the SDH/SONET multiplex. We refer to this as =20 multiplex-based labeling. This is the idea that was incorporated in = =20 the GMPLS signaling specifications for SDH/SONET [18].=20 =20 6.3. Signaling Elements=20 =20 In the preceding sections, we defined the meaning of a SDH/SONET=20 label and specified its structure. A question that arises naturally=20 at this point is the following. In an LSP or connection setup=20 request, how do we specify the signal for which we want to establish=20 a path (and for which we desire a label)?=20 =20 Clearly, information that is required to completely specify the=20 desired signal and its characteristics must be transferred via the=20 label distribution protocol, so that the switches along the path can=20 be configured to correctly handle and switch the signal. This=20 =20 Bernstein/Mannie/Sharma Expires January 2005 24=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 information is specified in three parts [18], each of which refers=20 to a different network layer. =20 =20 1. GENERALIZED_LABEL REQUEST (as in [6], [7]), which contains three=20 parts: LSP Encoding Type, Switching Type, and G-PID.=20 =20 The first specifies the nature/type of the LSP or the desired=20 SDH/SONET channel, in terms of the particular signal (or collection=20 of signals) within the SDH/SONET multiplex that the LSP represents,=20 and is used by all the nodes along the path of the LSP. =20 =20 The second specifies certain link selection constraints, which=20 control, at each hop, the selection of the underlying link that is=20 used to transport this LSP. =20 =20 The third specifies the payload carried by the LSP or SDH/SONET=20 channel, in terms of the termination and adaptation functions=20 required at the end points, and is used by the source and=20 destination nodes of the LSP. =20 =20 2. SONET/SDH TRAFFIC_PARAMETERS (as in [17], Section 2.1) used as a=20 SENDER_TSPEC/FLOWSPEC, which contains 6 parts: Signal Type,=20 (Requested Contiguous Concatenation (RCC), Number of Contiguous=20 Components (NCC), Number of Virtual Components (NVC)), Multiplier=20 (MT), Transparency, and Profile.=20 =20 The Signal Type indicates the type of elementary signal comprising=20 the LSP, while the remaining fields indicate transforms that can be=20 applied to the basic signal to build the final signal that=20 corresponds to the LSP actually being requested. For instance (see=20 [18] for details):=20 =20 - Contiguous concatenation (by using the RCC and NCC=20 fields) can be optionally applied on the Elementary Signal,=20 resulting in a contiguously concatenated signal.=20 =20 - Then, virtual concatenation (by using the NVC field) can be=20 optionally applied on the Elementary Signal resulting in=20 a virtually concatenated signal.=20 =20 - Third, some transparency (by using the Transparency field)=20 can be optionally specified when requesting a frame as=20 signal rather than an SPE or VC based signal.=20 =20 - Fourth, a multiplication (by using the Multiplier field)=20 can be optionally applied either directly on the Elementary=20 Signal, or on the contiguously concatenated signal obtained=20 from the first phase, or on the virtually concatenated signal=20 obtained from the second phase, or on these signals combined=20 with some transparency.=20 =20 Transparency indicates precisely which fields in these overheads=20 must be delivered unmodified at the other end of the LSP. An ingress=20 =20 Bernstein/Mannie/Sharma Expires January 2005 25=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 LSR requesting transparency will pass these overhead fields that=20 must be delivered to the egress LSR without any change. From the=20 ingress and egress LSRs point of views, these fields must be seen as=20 unmodified.=20 =20 Transparency is not applied at the interfaces with the initiating=20 and terminating LSRs, but is only applied between intermediate LSRs.=20 =20 The transparency field is used to request an LSP that supports the=20 requested transparency type; it may also be used to setup the=20 transparency process to be applied at each intermediate LSR.=20 =20 Finally, the profile field is intended particular capabilities that=20 must be supported for the LSP, for example monitoring capabilities.=20 No standard profile is currently defined, however.=20 =20 3. UPSTREAM_LABEL for Bi-directional LSP's (as in [6], [7]).=20 =20 4. Local Link Selection e.g. IF_ID_RSVP_HOP Object (as in [7]).=20 =20 =20 7. Summary and Conclusions=20 =20 We provided a detailed account of the issues involved in applying=20 generalized MPLS-based control (GMPLS) to TDM networks.=20 =20 We began with a brief overview of MPLS and SDH/SONET networks,=20 discussing current circuit establishment in TDM networks, and=20 arguing why SDH/SONET technologies will not be "outdated" in the=20 foreseeable future. Next, we looked at IP/MPLS applied to SDH/SONET=20 networks, where we considered why such an application makes sense,=20 and reviewed some MPLS terminology as applied to TDM networks. =20 =20 We considered the two main areas of application of IP/MPLS methods=20 to TDM networks, namely routing and signaling, and discussed how=20 Generalized MPLS routing and signaling are used in the context of=20 TDM networks. We reviewed in detail the switching capabilities of=20 TDM equipment, and the requirement to learn about the protection=20 capabilities of underlying links, and how these influence the=20 available capacity advertisement in TDM networks. =20 =20 We focused briefly on path computation methods, pointing out that=20 these were not subject to standardization. We then examined optical=20 path provisioning or signaling, considering the issue of what=20 constitutes an appropriate label for TDM circuits and how this label=20 should be structured, and we focused on the importance of=20 hierarchical label allocation in a TDM network. Finally, we reviewed=20 the signaling elements involved when setting up an TDM circuit,=20 focusing on the nature of the LSP, the type of payload it carries,=20 and the characteristics of the links that the LSP wishes to use at=20 each hop along its path for achieving a certain reliability. =20 =20 =20 Bernstein/Mannie/Sharma Expires January 2005 26=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 8. Security Considerations=20 =20 This draft raises no new security issues in the MPLS specifications.=20 =20 =20 9. Acknowledgments=20 =20 We acknowledge all the participants of the MPLS and CCAMP WGs, whose=20 constant enquiry about GMPLS issues in TDM networks motivated the=20 writing of this document, and whose questions helped shape its=20 contents. Also, thanks to Kireeti Kompella for his careful reading=20 of the last version of this draft, and for his helpful comments and=20 feedback, and to Dimitri Papadimitriou for his review on behalf of=20 the Routing Area Directorate, which provided many useful inputs to=20 help update the document to confirm to the standards evolutions=20 since this document passed last call.=20 =20 =20 10.Author's Addresses=20 =20 Greg Bernstein=20 Grotto Networking=20 Phone: +1 510 573-2237=20 E-mail: gregb@grotto-networking.com=20 =20 Eric Mannie=20 InterAir Link =20 Phone: +32 2 790 34 25 =20 E-mail: eric_mannie@hotmail.com=20 =20 Vishal Sharma=20 Metanoia, Inc.=20 888 Villa Street, Suite 200B=20 Mountain View, CA 94041=20 Phone: +1 408 530 8313=20 Email: v.sharma@ieee.org=20 =20 =20 11.References =20 =20 11.1. Normative References=20 =20 [1] Bradner, S., "The Internet Standards Process -- Revision 3",=20 BCP 9, RFC 2026, October 1996.=20 =20 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement=20 Levels", BCP 14, RFC 2119, March 1997.=20 =20 [3] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol=20 Label Switching Architecture", RFC 3031, January 2001.=20 =20 =20 Bernstein/Mannie/Sharma Expires January 2005 27=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 [4] G.707, Network Node Interface for the Synchronous Digital=20 Hierarchy (SDH), International Telecommunication Union, March=20 1996.=20 =20 [5] ANSI T1.105-1995, Synchronous Optical Network (SONET) Basic=20 Description including Multiplex Structure, Rates, and Formats,=20 American National Standards Institute.=20 =20 [6] Berger, L. (Editor), "Generalized MPLS -=0D = - Signaling Functional=20 Description," RFC 3471, January 2003.=20 =20 [7] Berger, L. (Editor), "Generalized MPLS Signaling -=0D = - RSVP-TE=20 Extensions," RFC 3473, January 2003.=20 =20 [8] Berger, L. (Editor), "Generalized MPLS Signaling -=0D = - CR-LDP=20 Extensions," RFC 3473, January 2003.=20 =20 [9] Bernstein, G., Yates, J., Saha, D., "IP-Centric Control and=20 Management of Optical Transport Networks," IEEE Communications=20 Mag., Vol. 40, Issue 10, October 2000.=20 =20 [10] ANSI T1.105.01-1995, Synchronous Optical Network (SONET)=20 Automatic Protection Switching, American National Standards=20 Institute.=20 =20 [11] G.841, Types and Characteristics of SDH Network Protection=20 Architectures, ITU-T, July 1995.=20 =20 11.2. Informative References=20 =20 [12] Kompella, K., et al, "Routing Extensions in Support of=20 Generalized MPLS," Internet Draft, Work-in-Progress, draft- ietf-ccamp-gmpls-routing-09.txt, October 2003.=20 =20 [13] Kompella, K., et al, "OSPF Extensions in Support of Generalized=20 MPLS," Internet Draft, Work-in-Progress, draft-ietf-ccamp- ospf-extensions-12.txt, October 2003.=20 =20 [14] Kompella, K., et al, "IS-IS Extensions in Support of=20 Generalized MPLS," Internet Draft, Work-in-Progress, draft- ietf-isis-gmpls-extensions-16.txt, August 2002.=20 =20 [15] Bernstein, G., Sharma, V., Ong, L., "Inter-domain Optical=20 Routing, " OSA J. of Optical Networking, vol. 1, no. 2, pp. 80- 92.=20 =20 [16] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in=20 MPLS Traffic Engineering", Internet Draft, Work-in-Progress,=20 draft-ietf-mpls-bundle-04.txt, July 2002.=20 =20 [17] Kompella, K., Rekhter, Y., "LSP Hierarchy with Generalized=20 MPLS-TE", Internet Draft, Work-in-Progress, draft-ietf-mpls- lsp-hierarchy-08.txt, September 2002.=20 =20 Bernstein/Mannie/Sharma Expires January 2005 28=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 =20 [18] Mannie, E. (Editor), "GMPLS Extensions for SONET and SDH=20 Control", Internet Draft, Work-in-Progress, draft-ietf-ccamp- gmpls-sonet-sdh-08.txt, February 2003.=20 =20 [19] G.7715.1, ASON Routing Architecture and Requirements for Link- State Protocols, International Telecommunications Union,=20 February 2004.=20 =20 [20] Bernstein, G., Rajagopalan, R., and Saha, D., "Optical Network=20 Control: Protocols, Architectures, and Standards," Addison- Wesley, July 2003.=20 =20 12.Intellectual Property Considerations=20 =20 =20 The IETF takes no position regarding the validity or scope of any=20 Intellectual Property Rights or other rights that might be claimed=20 to pertain to the implementation or use of the technology described=20 in this document or the extent to which any license under such=20 rights might or might not be available; nor does it represent that=20 it has made any independent effort to identify any such rights.=20 Information on the procedures with respect to rights in RFC=20 documents can be found in BCP 78 and BCP 79.=20 =20 Copies of IPR disclosures made to the IETF Secretariat and any=20 assurances of licenses to be made available, or the result of an=20 attempt made to obtain a general license or permission for the use=20 of such proprietary rights by implementers or users of this=20 specification can be obtained from the IETF on-line IPR repository=20 at http://www.ietf.org/ipr.=20 =20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights that may cover technology that may be required to implement=20 this standard. Please address the information to the IETF at ietf- ipr@ietf.org.=20 =20 =20 12.1. IPR Disclosure Acknowledgement=20 =20 By submitting this Internet-Draft, I certify that any applicable=20 patent or other IPR claims of which I am aware have been disclosed,=20 and any of which I become aware will be disclosed, in accordance=20 with RFC 3668.=20 =20 13.Full Copyright Statement=20 =20 "Copyright (C) The Internet Society (2004). This document is=20 subject=20 to the rights, licenses and restrictions contained in BCP 78, and=20 except as set forth therein, the authors retain all their rights."=20 =20 Bernstein/Mannie/Sharma Expires January 2005 29=20 GMPLS based Control of SDH/SONET July 2004=20 =20 =20 =20 "This document and the information contained herein are provided on=20 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE=20 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE=20 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR=20 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE Of=20 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."=20 =20 =20 =20 Bernstein/Mannie/Sharma Expires January 2005 30=20 ------=_NextPart_000_0000_01C469F7.0AE49E50-- From rtg-dir-bounces@ietf.org Wed Aug 11 06:59:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20483 for ; Wed, 11 Aug 2004 06:59:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuquC-0003dg-I5 for rtg-dir-archive@ietf.org; Wed, 11 Aug 2004 07:04:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuqmR-0001fE-Qr; Wed, 11 Aug 2004 06:56:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buqiv-0000yF-8D for rtg-dir@megatron.ietf.org; Wed, 11 Aug 2004 06:52:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20247; Wed, 11 Aug 2004 06:52:46 -0400 (EDT) Received: from webmail.pi.se ([195.7.65.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buqnd-0003Xl-KV; Wed, 11 Aug 2004 06:57:43 -0400 Received: from webmail.pi.se (localhost [127.0.0.1]) by webmail.pi.se (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i7BApJ6p025864; Wed, 11 Aug 2004 12:51:19 +0200 Received: (from www-data@localhost) by webmail.pi.se (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i7BApImv025861; Wed, 11 Aug 2004 12:51:18 +0200 X-Authentication-Warning: webmail.pi.se: www-data set sender to loa@pi.se using -f Received: from gw.imc.kth.se (gw.imc.kth.se [193.10.152.67]) by webmail.pi.se (Horde) with HTTP for ; Wed, 11 Aug 2004 12:51:18 +0200 Message-ID: <1092221478.084be6c3d6895@webmail.pi.se> Date: Wed, 11 Aug 2004 12:51:18 +0200 From: Loa Andersson To: iesg-secretary@ietf.org, zinin@psg.com MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 193.10.152.67 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: swallow@cisco.com, rtg-dir@ietf.org Subject: draft-iett-mpls-rsvpte-attributes for PS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Alex, the draft-ietf-mpls-rsvpte-attributes-04.txt it a product of the MPLS WG, and has been stalled for some time, due to lack of implementations. Now the authros hs stated that there are at least one known implmentation. We therefore request that this draft is published as a PS RFC on the Standards Track. /Loa Loa Andersson +46 739 81 21 64 From rtg-dir-bounces@ietf.org Sat Aug 21 08:55:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11735 for ; Sat, 21 Aug 2004 08:55:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByVVv-00077p-C1 for rtg-dir-archive@ietf.org; Sat, 21 Aug 2004 09:02:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByV7r-0004Pg-OD; Sat, 21 Aug 2004 08:37:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ByUo9-0001QH-7r; Sat, 21 Aug 2004 08:17:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09904; Sat, 21 Aug 2004 08:17:04 -0400 (EDT) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ByUun-0006Qo-J2; Sat, 21 Aug 2004 08:24:10 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id 255FF1974E9; Sat, 21 Aug 2004 08:12:47 -0400 (EDT) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i7LCGW313893; Sat, 21 Aug 2004 05:16:32 -0700 (PDT) Message-Id: <200408211216.i7LCGW313893@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-chairs@ietf.org, rtg-dir@ietf.org Date: Sat, 21 Aug 2004 05:16:29 -0700 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: Bill is on vacation until August 30 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Howdy all, It's that time again - gotta shed the stress of everyday life and just go sit on the beach for a week. Alex will be back from his vacation on Monday, so if you need something from me while I'm out that can't wait, he may be able to help you. Bill From rtg-dir-bounces@ietf.org Mon Aug 23 22:39:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09586 for ; Mon, 23 Aug 2004 22:39:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzRDg-0005jX-UR for rtg-dir-archive@ietf.org; Mon, 23 Aug 2004 22:39:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzQjo-0002S2-6f; Mon, 23 Aug 2004 22:08:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BzQMy-0006bL-3H; Mon, 23 Aug 2004 21:45:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06226; Mon, 23 Aug 2004 21:43:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BzQLp-0004i3-Ek; Mon, 23 Aug 2004 21:43:54 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BzQLN-0003r1-FG; Tue, 24 Aug 2004 01:43:25 +0000 Date: Mon, 23 Aug 2004 18:43:20 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <23893175.20040823184320@psg.com> To: rtg-chairs@ietf.org, rtg-dir@ietf.org, iesg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: Back online, catching up. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Guys, I'm back from Russia. Will be catching up on e-mail during this week. If something needs my immediate attention, please send me a unicast and prefix the subject with "URG:". Thanks. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Fri Aug 27 16:35:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07550 for ; Fri, 27 Aug 2004 16:35:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0nSX-0003uJ-1U for rtg-dir-archive@ietf.org; Fri, 27 Aug 2004 16:36:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0mpZ-0005O7-Dl; Fri, 27 Aug 2004 15:56:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0mkZ-0002Wc-Cc for rtg-dir@megatron.ietf.org; Fri, 27 Aug 2004 15:51:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00102 for ; Fri, 27 Aug 2004 15:51:00 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0mll-0001IS-VT for rtg-dir@ietf.org; Fri, 27 Aug 2004 15:52:18 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0mkW-00016c-Hj; Fri, 27 Aug 2004 19:51:00 +0000 Date: Fri, 27 Aug 2004 12:50:59 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1555437345.20040827125059@psg.com> To: Adrian Farrel , Kireeti Kompella , "Dimitri.Papadimitriou" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7bit Cc: Bill Fenner , rtg-dir@ietf.org Subject: AD-review comments on draft-ietf-ccamp-gmpls-g709 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: 7bit Adrian, Kireeti, Dimitri- Please find comments below. I'd like to understand the answer to the meta question before sending this to the WG. Thanks. Alex Meta: this draft talks about the signaling component, what about the routing part of the story? Ed: please use the new ID boilerplates > 3.1.1 LSP Encoding Type ... > > Therefore, the current "Digital Wrapper" code-point defined in > [RFC3471] can be replaced by two separate code-points: What does "replaced" mean here? > - code-point for the G.709 Digital Path layer > - code-point for the non-standard Digital Wrapper layer > > > In the same way, two separate code-points can replace the current > defined "Lambda" code-point: > - code-point for the G.709 Optical Channel layer > - code-point for the non-standard Lambda layer (also referred to > as Lambda layer which includes the pre-OTN Optical Channel > layer) ditto > Consequently, the following additional code-points for the LSP > Encoding Type are defined: > > > Value Type > ----- ---- > 12 G.709 ODUk (Digital Path) > 13 G.709 Optical Channel > > > Moreover, the code-point for the G.709 Optical Channel (OCh) layer > will indicate the capability of an end-system to use the G.709 non- > associated overhead (naOH) i.e. the OTM Overhead Signal (OOS) > multiplexed into the OTM-n.m interface signal. Given we're talking about label request parameters here, how could a value in the requested LSP type indicate a capability? > 3.1.2 Switching Type ... > Moreover, in a strict layered G.709 network, when a downstream node > receives a Generalized Label Request including one of these values > for the Switching Type field, this value SHOULD be ignored. What about other values? Should the field be ignored all together? > 4.1 ODUk Label Space ... > 1. t1 (1-bit): > - t1=1 indicates an ODU1 signal. > - t1 is not significant for the other ODUk signal types (t1=0). "not significant" meaning it should be set to 0? > > 2. t2 (3-bit): > - t2=1 indicates an ODU2 signal that is not further sub- > divided. > - t2=2->5 indicates the tributary slot (t2th-2) used by the > ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). > - t2 is not significant for an ODU3 (t2=0). ditto > > 3. t3 (6-bit): > - t3=1 indicates an ODU3 signal that is not further sub- > > > D.Papadimitriou (Editor) et al. - Expires September 2004 10 > draft-ietf-ccamp-gmpls-g709-07.txt March 2004 > > > > divided. > - t3=2->17 indicates the tributary slot (t3th-1) used by the > ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). > - t3=18->33 indicates the tributary slot (t3th-17) used by the > ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). Ed: value ranges would be easier to read if put as "[n..m]" > > Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required > to identify the 4 tributary slots used by the ODU2; these tributary > time slots have to be allocated in ascending order. The section should define the behavior of the receiver for the cases where e.g. both t1 and t2 are !=0. > > 4.2 Label Distribution Rules > This section below talks about lists of labels and sets of labels, however it does not clarify how those are encoded. > In case of ODUk in OTUk mapping, only one of label can appear in the > Generalized Label. > > > In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered > list of the labels in the multiplex is given (this list can be > restricted to only one label when NMC = 1). Each label indicates a > component (ODUj tributary slot) of the multiplexed signal. The order > of the labels must reflect the order of the ODUj into the multiplex > (not the physical order of tributary slots). > > > In case of ODUk virtual concatenation, the explicit ordered list of > all labels in the concatenation is given. Each label indicates a > component of the virtually concatenated signal. The order of the > labels must reflect the order of the ODUk to concatenate (not the > physical order of time-slots). This representation limits virtual > concatenation to remain within a single (component) link. In case of > multiplexed virtually concatenated signals, the first set of labels > indicates the components (ODUj tributary slots) of the first > virtually concatenated signal, the second set of labels indicates > the components (ODUj tributary slots) of the second virtually > concatenated signal, and so on. > > > In case of multiplication (i.e. when using the MT field), the > explicit ordered list of all labels taking part in the composed > > > D.Papadimitriou (Editor) et al. - Expires September 2004 11 > draft-ietf-ccamp-gmpls-g709-07.txt March 2004 > > > > signal is given. The above representation limits multiplication to > remain within a single (component) link. In case of multiplication > of multiplexed/virtually concatenated signals, the first set of > labels indicates the components of the first multiplexed/virtually > concatenated signal, the second set of labels indicates components > of the second multiplexed/virtually concatenated signal, and so on. > 8. IANA Considerations > > > Two values have to be defined by IANA for this document: > > > Two RSVP C-Types in registry: > > > http://www.iana.org/assignments/rsvp-parameters > > > - A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5 > (Suggested value, TBA) - see Section 6. > > > - A G.709 FLOWSPEC object: Class = 9, C-Type = 5 > (Suggested value, TBA) - see Section 6. > > > IANA is also requested to track the code-point spaces extended > and/or updated by this document. That is: > - LSP Encoding Type > - Generalized PID (G-PID) What does the last para mean to IANA? Is this a request to create new registries? If so, more info needs to be given, e.g.: - name of the registry - format - allocation policy - initial values From rtg-dir-bounces@ietf.org Fri Aug 27 16:56:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10034 for ; Fri, 27 Aug 2004 16:56:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0nmh-0004iY-NU for rtg-dir-archive@ietf.org; Fri, 27 Aug 2004 16:57:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0nT8-0007PB-9d; Fri, 27 Aug 2004 16:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0nBD-00026I-Q6 for rtg-dir@megatron.ietf.org; Fri, 27 Aug 2004 16:18:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03586 for ; Fri, 27 Aug 2004 16:18:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0nCO-0002at-P1 for rtg-dir@ietf.org; Fri, 27 Aug 2004 16:19:51 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0nB9-00056q-LH; Fri, 27 Aug 2004 20:18:31 +0000 Date: Fri, 27 Aug 2004 13:18:30 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1818831285.20040827131830@psg.com> To: Adrian Farrel , Kireeti Kompella , MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Bill Fenner , rtg-dir@ietf.org Subject: AD-review comments on draft-ietf-ccamp-gmpls-egress-control X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Adrian, Kireeti, Lou- Just a couple of small comments. Feel free to fwd to the WG. Ed: please use the new ID boilerplates. > Abstract > > This note clarifies the procedures for the control of the label used > on a output/downstream interface of the egress node of a Label > Switched Path (LSP). Such control is also known as "Egress Control". > Support for Egress Control is implicit in Generalized Multi-Protocol > Label Switching (GMPLS) Signaling. This note does not modify GMPLS > signaling mechanisms and procedures and should be viewed as an > informative clarification of GMPLS Signaling - Resource ReserVation > Protocol-Traffic Engineering (RSVP-TE) Extensions. Given that the doc goes STD track, I suggest that the last sentence is changed to say "This note is a clarification update to the specification of GMPLS Signaling..." > Author's Note > > This draft is targeted for publication as a BCP. This one should be removed for the same reason. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Fri Aug 27 17:13:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11341 for ; Fri, 27 Aug 2004 17:13:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0o3I-00059k-RG for rtg-dir-archive@ietf.org; Fri, 27 Aug 2004 17:14:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0nvJ-0003eR-OT; Fri, 27 Aug 2004 17:06:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0noA-0001M1-9w for rtg-dir@megatron.ietf.org; Fri, 27 Aug 2004 16:58:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10440 for ; Fri, 27 Aug 2004 16:58:47 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0npM-0004q3-Ng for rtg-dir@ietf.org; Fri, 27 Aug 2004 17:00:05 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0no8-000Ans-0U for rtg-dir@ietf.org; Fri, 27 Aug 2004 20:58:48 +0000 Date: Fri, 27 Aug 2004 13:58:47 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1810410594.20040827135847@psg.com> To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Subject: RTG-Dir reviews X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Guys- Here's the summary of what we chatted about at the rtg-dir bar meeting in SD. We need a better/easier process for document review. In particular, we need an agreed upon simple algo for assigning the reviewers to the documents, and a tool to track the assignments. We agreed that: 1. A skills matrix for rtg-dir members would be maintained. Each person would have a list of protocols/areas of expertise he/she is particularly good at. I put together the first version of it. Please take a look and send me an e-mail with corrections or if I forgot to put you in the table. http://psg.com/~zinin/ietf/rtg-dir/rtg-dir-skills.html 2. The reviewer assignment algo would be as follows: 1st reviewer is chosen based on the skill set. (if more than one match is found, take the person who hasn't reviewed any doc for longest time) 2nd reviewer is assigned using round-robin (skipping the 1st reviewer, of course) 3. Mark and Bill are going to help us with the tool, using RT. 4. All rtg-dir members commit to pick up the assignments or inform that they are not able to do the review in time I will use a standard subject line to make it easier, e.g.: Subject: review assignment: draft-whoever-what-ever-365.txt: acee, dmm Anything else I forgot? -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Fri Aug 27 18:25:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16473 for ; Fri, 27 Aug 2004 18:25:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0pBB-0006Tx-PX for rtg-dir-archive@ietf.org; Fri, 27 Aug 2004 18:26:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0p6U-0005pI-8v; Fri, 27 Aug 2004 18:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0p2y-0003TJ-T3 for rtg-dir@megatron.ietf.org; Fri, 27 Aug 2004 18:18:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15927 for ; Fri, 27 Aug 2004 18:18:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0p4A-0006L2-36 for rtg-dir@ietf.org; Fri, 27 Aug 2004 18:19:29 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0p2u-000M6v-DS for rtg-dir@ietf.org; Fri, 27 Aug 2004 22:18:08 +0000 Date: Fri, 27 Aug 2004 15:18:07 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1538021461.20040827151807@psg.com> To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: review assignment: draft-ietf-mpls-explicit-null-01.txt: danny, mjh X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit skill-specific: danny round-robin: mark http://www.ietf.org/internet-drafts/draft-ietf-mpls-explicit-null-01.txt > Removing a Restriction on the use of MPLS Explicit NULL > Abstract > > The label stack encoding for MPLS (Multi-protocol Label Switching) > defines a reserved label value known as "IPv4 Explicit NULL" and a > reserved label value known as "IPv6 Explicit NULL". Previously, > these labels were only legal when they occurred at the bottom of the > MPLS label stack. This restriction is now removed, so that these > label values may legally occur anywhere in the stack. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Fri Aug 27 18:32:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16792 for ; Fri, 27 Aug 2004 18:32:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0pHs-0006aC-Jz for rtg-dir-archive@ietf.org; Fri, 27 Aug 2004 18:33:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0pBp-0007Wo-RD; Fri, 27 Aug 2004 18:27:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0p7S-0005yP-Ej for rtg-dir@megatron.ietf.org; Fri, 27 Aug 2004 18:22:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16285 for ; Fri, 27 Aug 2004 18:22:47 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0p8g-0006Qu-O4 for rtg-dir@ietf.org; Fri, 27 Aug 2004 18:24:07 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C0p7R-000Mjl-8l for rtg-dir@ietf.org; Fri, 27 Aug 2004 22:22:49 +0000 Date: Fri, 27 Aug 2004 15:22:48 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <93463290.20040827152248@psg.com> To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: review assignment: draft-ietf-mpls-rsvpte-attributes-04.txt: rcallon; mshand X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit skill-specific: Ross (Dimitri skipped as co-author, Loa as co-chair) round-robin: Mike http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvpte-attributes-04.txt > Encoding of Attributes for Multiprotocol Label Switching (MPLS) > Label Switched Path (LSP) Establishment Using RSVP-TE > Abstract > > Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may > be established using the Resource Reservation Protocol Traffic > Engineering extensions (RSVP-TE). This protocol includes an object > (the SESSION_ATTRIBUTE object) which carries a flags field used to > indicate options and attributes of the LSP. That flags field has > eight bits allowing for eight options to be set. Recent proposals in > many documents that extend RSVP-TE have suggested uses for each of > the previously unused bits. > > This document defines a new object for RSVP-TE messages that allows > the signaling of further attribute bits and also the carriage of > arbitrary attribute parameters to make RSVP-TE easily extensible to > support new requirements. Additionally, this document defines a way > to record the attributes applied to the LSP on a hop-by-hop basis. > > The object mechanisms defined in this document are equally applicable > to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to > GMPLS non-PSC LSPs. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Sat Aug 28 04:33:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01658 for ; Sat, 28 Aug 2004 04:33:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0yfi-0008LJ-4E for rtg-dir-archive@ietf.org; Sat, 28 Aug 2004 04:34:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ydC-0006jG-SX; Sat, 28 Aug 2004 04:32:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0ybg-0006H9-9j for rtg-dir@megatron.ietf.org; Sat, 28 Aug 2004 04:30:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01575 for ; Sat, 28 Aug 2004 04:30:38 -0400 (EDT) Message-Id: <200408280830.EAA01575@ietf.org> Received: from ip503c7142.speed.planet.nl ([80.60.113.66]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C0ycq-0008IF-9t for rtg-dir@ietf.org; Sat, 28 Aug 2004 04:32:02 -0400 Date: Sat, 28 Aug 2004 02:25:23 -0700 From: "Nichol Ripple" To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 3.9 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Subject: Best deal of the month X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.7 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable And, indeed, unless this shoal had a machine in its stoma= ch, how could it change its position with such astonishing rapidity?=20



Cìálís - Super V1agrã at only 3$ per dosê= ;








no msg
And, indeed, unless this shoal had a machine in its stomach, how could it = change its position with such astonishing rapidity?=20. No tax or duty sha= ll be laid on articles exported from any state; It is no rare thing to mee= t in the middle of the ocean whales so sound asleep that they can be succe= ssfully attacked, and Ned Land had harpooned more than one during its slee= p: But what good would it have been at such a distance! My swollen lips co= uld utter no sounds.=20 From rtg-dir-bounces@ietf.org Sat Aug 28 07:25:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09489 for ; Sat, 28 Aug 2004 07:25:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C11Lv-00028R-8U for rtg-dir-archive@ietf.org; Sat, 28 Aug 2004 07:26:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C11Jc-0003Vu-98; Sat, 28 Aug 2004 07:24:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C11Ir-0003Ly-5E for rtg-dir@megatron.ietf.org; Sat, 28 Aug 2004 07:23:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09419 for ; Sat, 28 Aug 2004 07:23:24 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C11KC-00026z-38 for rtg-dir@ietf.org; Sat, 28 Aug 2004 07:24:48 -0400 Received: from du-069-0282.access.clara.net ([217.158.145.28] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.34) id 1C11Ij-000IBU-EJ; Sat, 28 Aug 2004 12:23:19 +0100 Message-ID: <24a101c48cf1$6fa185c0$11849ed9@Puppy> From: "Adrian Farrel" To: "Alex Zinin" , "Kireeti Kompella" , "Dimitri.Papadimitriou" References: <1555437345.20040827125059@psg.com> Date: Sat, 28 Aug 2004 12:18:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit Cc: Bill Fenner , rtg-dir@ietf.org Subject: Re: AD-review comments on draft-ietf-ccamp-gmpls-g709 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7bit Thanks Alex, Some comments in-line. Dimitri will probably want to comment, too. A couple of editorial nits. - Please run the IDnits script over the draft to clean it up. - Please insert page break characters. Cheers, Adrian > Meta: this draft talks about the signaling component, what about > the routing part of the story? No different to any G-PID or encoding type. That is, end-point capabilities are not currently advertised in GMPLS routing. Some people see this as a failing, others say that since you are attempting to open an end-to-end connection, you are presumably trying to contact a known (called) party and it would be usual to have either: - some understanding of the capablities of the person you are trying to reach or - limited capablities, yourself. Anyway, this draft is simply extending the list of encodings and G-PIDs to cover G.709. Endocings and G-PIDs are signaled quantites that are not advertised. > Ed: please use the new ID boilerplates > > > 3.1.1 LSP Encoding Type > ... > > > > Therefore, the current "Digital Wrapper" code-point defined in > > [RFC3471] can be replaced by two separate code-points: > > What does "replaced" mean here? Good question. Presume that we can't obsolete "Digital Wrapper" without some care. So we need text to describe how it is handled. > > - code-point for the G.709 Digital Path layer > > - code-point for the non-standard Digital Wrapper layer > > > > In the same way, two separate code-points can replace the current > > defined "Lambda" code-point: > > - code-point for the G.709 Optical Channel layer > > - code-point for the non-standard Lambda layer (also referred to > > as Lambda layer which includes the pre-OTN Optical Channel > > layer) > > ditto > > > Consequently, the following additional code-points for the LSP > > Encoding Type are defined: > > > > Value Type > > ----- ---- > > 12 G.709 ODUk (Digital Path) > > 13 G.709 Optical Channel > > > > Moreover, the code-point for the G.709 Optical Channel (OCh) layer > > will indicate the capability of an end-system to use the G.709 non- > > associated overhead (naOH) i.e. the OTM Overhead Signal (OOS) > > multiplexed into the OTM-n.m interface signal. > > Given we're talking about label request parameters here, how could a value > in the requested LSP type indicate a capability? "Requested capability" > > 3.1.2 Switching Type > ... > > Moreover, in a strict layered G.709 network, when a downstream node > > receives a Generalized Label Request including one of these values > > for the Switching Type field, this value SHOULD be ignored. > > What about other values? Should the field be ignored all together? > > > 4.1 ODUk Label Space > ... > > 1. t1 (1-bit): > > - t1=1 indicates an ODU1 signal. > > - t1 is not significant for the other ODUk signal types (t1=0). > > "not significant" meaning it should be set to 0? > > > 2. t2 (3-bit): > > - t2=1 indicates an ODU2 signal that is not further sub- > > divided. > > - t2=2->5 indicates the tributary slot (t2th-2) used by the > > ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). > > - t2 is not significant for an ODU3 (t2=0). > > ditto > > > 3. t3 (6-bit): > > - t3=1 indicates an ODU3 signal that is not further sub- > > > > divided. > > - t3=2->17 indicates the tributary slot (t3th-1) used by the > > ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). > > - t3=18->33 indicates the tributary slot (t3th-17) used by the > > ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). > > Ed: value ranges would be easier to read if put as "[n..m]" > > > Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required > > to identify the 4 tributary slots used by the ODU2; these tributary > > time slots have to be allocated in ascending order. > > The section should define the behavior of the receiver for the cases > where e.g. both t1 and t2 are !=0. > > > 4.2 Label Distribution Rules > > This section below talks about lists of labels and sets of labels, however > it does not clarify how those are encoded. Yup. There is precedent and "common knowledge" for how concatenated labels are encoded, but I think Alex is right that this draft should re-state the point for clarity and consistency. > > In case of ODUk in OTUk mapping, only one of label can appear in the > > Generalized Label. > > > > In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered > > list of the labels in the multiplex is given (this list can be > > restricted to only one label when NMC = 1). Each label indicates a > > component (ODUj tributary slot) of the multiplexed signal. The order > > of the labels must reflect the order of the ODUj into the multiplex > > (not the physical order of tributary slots). > > > > In case of ODUk virtual concatenation, the explicit ordered list of > > all labels in the concatenation is given. Each label indicates a > > component of the virtually concatenated signal. The order of the > > labels must reflect the order of the ODUk to concatenate (not the > > physical order of time-slots). This representation limits virtual > > concatenation to remain within a single (component) link. In case of > > multiplexed virtually concatenated signals, the first set of labels > > indicates the components (ODUj tributary slots) of the first > > virtually concatenated signal, the second set of labels indicates > > the components (ODUj tributary slots) of the second virtually > > concatenated signal, and so on. > > > > In case of multiplication (i.e. when using the MT field), the > > explicit ordered list of all labels taking part in the composed > > signal is given. The above representation limits multiplication to > > remain within a single (component) link. In case of multiplication > > of multiplexed/virtually concatenated signals, the first set of > > labels indicates the components of the first multiplexed/virtually > > concatenated signal, the second set of labels indicates components > > of the second multiplexed/virtually concatenated signal, and so on. > > > > 8. IANA Considerations > > > > Two values have to be defined by IANA for this document: > > > > Two RSVP C-Types in registry: > > > > http://www.iana.org/assignments/rsvp-parameters > > > > - A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5 > > (Suggested value, TBA) - see Section 6. > > > > - A G.709 FLOWSPEC object: Class = 9, C-Type = 5 > > (Suggested value, TBA) - see Section 6. > > > > IANA is also requested to track the code-point spaces extended > > and/or updated by this document. That is: > > - LSP Encoding Type > > - Generalized PID (G-PID) > > What does the last para mean to IANA? Is this a request to create > new registries? If so, more info needs to be given, e.g.: > > - name of the registry > - format > - allocation policy > - initial values Hmmm. Probably my fault since I asked for this. Encodigng type and G-PID would, indeed, be two new registries. Primarily they are defined in RFC3471, but this draft introduces some new values and the values should be tracked and monitored. So, yes, this is a request for two new registries. The info provided to IANA should also point at all existing definitions. From rtg-dir-bounces@ietf.org Sat Aug 28 11:03:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20330 for ; Sat, 28 Aug 2004 11:03:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C14l3-0005Fv-Ul for rtg-dir-archive@ietf.org; Sat, 28 Aug 2004 11:04:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C14di-0002a2-20; Sat, 28 Aug 2004 10:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C14da-0002R7-ID for rtg-dir@megatron.ietf.org; Sat, 28 Aug 2004 10:57:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20119 for ; Sat, 28 Aug 2004 10:57:00 -0400 (EDT) Received: from webmail.movaz.com ([65.205.166.188] helo=jera.movaz.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C14et-00058s-QM for rtg-dir@ietf.org; Sat, 28 Aug 2004 10:58:28 -0400 Received: from lb.movaz.com (movaz-hw.atlanta.movaz.com [172.16.8.183]) by jera.movaz.com (Postfix) with ESMTP id 4341DC6A; Sat, 28 Aug 2004 10:56:21 -0400 (EDT) Message-Id: <6.1.2.0.2.20040828105235.0437a590@mo-ex1> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 28 Aug 2004 10:56:23 -0400 To: "Alex Zinin" From: Lou Berger In-Reply-To: <1818831285.20040827131830@psg.com> References: <1818831285.20040827131830@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Kireeti Kompella , Adrian Farrel , Bill Fenner , "Berger, Lou" , rtg-dir@ietf.org Subject: Re: AD-review comments on draft-ietf-ccamp-gmpls-egress-control X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Alex, Thanks for the feed back. See below for responses. At 04:18 PM 8/27/2004 -0400, Alex Zinin wrote: >Adrian, Kireeti, Lou- > >Just a couple of small comments. Feel free to fwd to the WG. > >Ed: please use the new ID boilerplates. sure. > > Abstract > > > > This note clarifies the procedures for the control of the label used > > on a output/downstream interface of the egress node of a Label > > Switched Path (LSP). Such control is also known as "Egress Control". > > Support for Egress Control is implicit in Generalized Multi-Protocol > > Label Switching (GMPLS) Signaling. This note does not modify GMPLS > > signaling mechanisms and procedures and should be viewed as an > > informative clarification of GMPLS Signaling - Resource ReserVation > > Protocol-Traffic Engineering (RSVP-TE) Extensions. > >Given that the doc goes STD track, I suggest that the last sentence is >changed to say "This note is a clarification update to the specification >of GMPLS Signaling..." sure. Although, I think BCP is appropriate given that this is just saying "this is what the rfc says"... > > Author's Note > > > > This draft is targeted for publication as a BCP. > >This one should be removed for the same reason. done. >-- >Alex >http://www.psg.com/~zinin Thanks again, Lou From rtg-dir-bounces@ietf.org Sat Aug 28 12:28:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25523 for ; Sat, 28 Aug 2004 12:28:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C165X-0006pr-VS for rtg-dir-archive@ietf.org; Sat, 28 Aug 2004 12:30:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C162P-0000ZV-LH; Sat, 28 Aug 2004 12:26:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C15zj-0008Tq-Nf for rtg-dir@megatron.ietf.org; Sat, 28 Aug 2004 12:24:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25103 for ; Sat, 28 Aug 2004 12:23:57 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1617-0006jE-DS for rtg-dir@ietf.org; Sat, 28 Aug 2004 12:25:25 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C15zU-00079K-QD; Sat, 28 Aug 2004 16:23:45 +0000 Message-ID: <4130B1B7.1010306@psg.com> Date: Sat, 28 Aug 2004 18:24:23 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel References: <1555437345.20040827125059@psg.com> <24a101c48cf1$6fa185c0$11849ed9@Puppy> In-Reply-To: <24a101c48cf1$6fa185c0$11849ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , Kireeti Kompella , Bill Fenner , rtg-dir@ietf.org, "Dimitri.Papadimitriou" Subject: Re: AD-review comments on draft-ietf-ccamp-gmpls-g709 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Content-Transfer-Encoding: 7bit alex, adrian, Adrian Farrel wrote: > Thanks Alex, > > Some comments in-line. Dimitri will probably want to comment, too. thanks for the input, here below a bunch of additional comments > A couple of editorial nits. > - Please run the IDnits script over the draft to clean it up. > - Please insert page break characters. > > Cheers, > Adrian > > >>Meta: this draft talks about the signaling component, what about >> the routing part of the story? > > > No different to any G-PID or encoding type. That is, end-point capabilities are not > currently advertised in GMPLS routing. Some people see this as a failing, others say that > since you are attempting to open an end-to-end connection, you are presumably trying to > contact a known (called) party and it would be usual to have either: > - some understanding of the capablities of the person you are trying to reach > or > - limited capablities, yourself. > > Anyway, this draft is simply extending the list of encodings and G-PIDs to cover G.709. > Endocings and G-PIDs are signaled quantites that are not advertised. as for sdh/sonet a couple of technology specific extensions where initiated early 2000 and took a more stable form end of 2002, that would have taken one of the following form: add. sub-TLV or extension of the technology specific part of the ISC sub-TLV descriptor for intra-domain TE and that would have included specific end-point capabilities, however since so far they've never been considered as working group item (stayed at the individual submission level) note: G-PIDs are not advertized but encodings are as part of the ISC sub-TLV >>Ed: please use the new ID boilerplates >> >> >>>3.1.1 LSP Encoding Type >> >>... >> >>> Therefore, the current "Digital Wrapper" code-point defined in >>> [RFC3471] can be replaced by two separate code-points: >> >>What does "replaced" mean here? > > > Good question. Presume that we can't obsolete "Digital Wrapper" without some care. So we > need text to describe how it is handled. here the issue is a timing problem, as G.709 was issued by the time RFC 3471 went out, combined with a formulation problem, as we can safely assume that the digital wrappers that were already available by that time were not fully G.709 compliant -> so it would be better to speak about a rename of the existing RFC 3471 value and add-on of a new value >>> - code-point for the G.709 Digital Path layer >>> - code-point for the non-standard Digital Wrapper layer >>> >>> In the same way, two separate code-points can replace the current >>> defined "Lambda" code-point: >>> - code-point for the G.709 Optical Channel layer >>> - code-point for the non-standard Lambda layer (also referred to >>> as Lambda layer which includes the pre-OTN Optical Channel >>> layer) >> >>ditto >> >> >>> Consequently, the following additional code-points for the LSP >>> Encoding Type are defined: >>> >>> Value Type >>> ----- ---- >>> 12 G.709 ODUk (Digital Path) >>> 13 G.709 Optical Channel >>> >>> Moreover, the code-point for the G.709 Optical Channel (OCh) layer >>> will indicate the capability of an end-system to use the G.709 non- >>> associated overhead (naOH) i.e. the OTM Overhead Signal (OOS) >>> multiplexed into the OTM-n.m interface signal. >> >>Given we're talking about label request parameters here, how could a value >>in the requested LSP type indicate a capability? > > > "Requested capability" it is part of the "data plane" assignment to dedicate a channel multiplexed into the bearier signal for the non-associated overhead transport, so it is as indicated by adrian part of the "request" >>>3.1.2 Switching Type >> >>... >> >>> Moreover, in a strict layered G.709 network, when a downstream node >>> receives a Generalized Label Request including one of these values >>> for the Switching Type field, this value SHOULD be ignored. >> >>What about other values? Should the field be ignored all together? the "field" SHOULD be ignored, if not (and in this case, thus simply used as an indication of the LSP class), the value of this field MUST be either of type TDM or LSC depending of the Signal Type value >>>4.1 ODUk Label Space >> >>... >> >>> 1. t1 (1-bit): >>> - t1=1 indicates an ODU1 signal. >>> - t1 is not significant for the other ODUk signal types (t1=0). >> >>"not significant" meaning it should be set to 0? true, in this case "t1 SHOULD be set to 0" >>> 2. t2 (3-bit): >>> - t2=1 indicates an ODU2 signal that is not further sub- >>> divided. >>> - t2=2->5 indicates the tributary slot (t2th-2) used by the >>> ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). >>> - t2 is not significant for an ODU3 (t2=0). >> >>ditto true, in this case "t2 SHOULD be set to 0" >>> 3. t3 (6-bit): >>> - t3=1 indicates an ODU3 signal that is not further sub- >>> >>> divided. >>> - t3=2->17 indicates the tributary slot (t3th-1) used by the >>> ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). >>> - t3=18->33 indicates the tributary slot (t3th-17) used by the >>> ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). >> >>Ed: value ranges would be easier to read if put as "[n..m]" ok >>> Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required >>> to identify the 4 tributary slots used by the ODU2; these tributary >>> time slots have to be allocated in ascending order. >> >>The section should define the behavior of the receiver for the cases >>where e.g. both t1 and t2 are !=0. >> >> >>>4.2 Label Distribution Rules >> >>This section below talks about lists of labels and sets of labels, however >>it does not clarify how those are encoded. > > > Yup. There is precedent and "common knowledge" for how concatenated labels are encoded, > but I think Alex is right that this draft should re-state the point for clarity and > consistency. see below >>> In case of ODUk in OTUk mapping, only one of label can appear in the >>> Generalized Label. add "The unique is encoded as single 32 bit label value (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2)" >>> In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered >>> list of the labels in the multiplex is given (this list can be >>> restricted to only one label when NMC = 1). Each label indicates a >>> component (ODUj tributary slot) of the multiplexed signal. The order >>> of the labels must reflect the order of the ODUj into the multiplex >>> (not the physical order of tributary slots). add "This ordered list of labels is encoded a sequence of 32 bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2)" >>> In case of ODUk virtual concatenation, the explicit ordered list of >>> all labels in the concatenation is given. Each label indicates a >>> component of the virtually concatenated signal. The order of the >>> labels must reflect the order of the ODUk to concatenate (not the >>> physical order of time-slots). This representation limits virtual >>> concatenation to remain within a single (component) link. In case of >>> multiplexed virtually concatenated signals, the first set of labels >>> indicates the components (ODUj tributary slots) of the first >>> virtually concatenated signal, the second set of labels indicates >>> the components (ODUj tributary slots) of the second virtually >>> concatenated signal, and so on. ditto >>> In case of multiplication (i.e. when using the MT field), the >>> explicit ordered list of all labels taking part in the composed >>> signal is given. The above representation limits multiplication to >>> remain within a single (component) link. In case of multiplication >>> of multiplexed/virtually concatenated signals, the first set of >>> labels indicates the components of the first multiplexed/virtually >>> concatenated signal, the second set of labels indicates components >>> of the second multiplexed/virtually concatenated signal, and so on. ditto >>>8. IANA Considerations >>> >>> Two values have to be defined by IANA for this document: >>> >>> Two RSVP C-Types in registry: >>> >>> http://www.iana.org/assignments/rsvp-parameters >>> >>> - A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5 >>> (Suggested value, TBA) - see Section 6. >>> >>> - A G.709 FLOWSPEC object: Class = 9, C-Type = 5 >>> (Suggested value, TBA) - see Section 6. >>> >>> IANA is also requested to track the code-point spaces extended >>> and/or updated by this document. That is: >>> - LSP Encoding Type >>> - Generalized PID (G-PID) >> >>What does the last para mean to IANA? Is this a request to create >>new registries? If so, more info needs to be given, e.g.: >> >> - name of the registry >> - format >> - allocation policy >> - initial values > > > Hmmm. Probably my fault since I asked for this. > Encodigng type and G-PID would, indeed, be two new registries. Primarily they are defined > in RFC3471, but this draft introduces some new values and the values should be tracked and > monitored. > > So, yes, this is a request for two new registries. The info provided to IANA should also > point at all existing definitions. in this case, i would also then suggest to create an entry for the switching type values the document will include the required information for each of them thanks, - dimitri. From rtg-dir-bounces@ietf.org Sun Aug 29 05:53:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27613 for ; Sun, 29 Aug 2004 05:53:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1MOY-0007Zt-Kh for rtg-dir-archive@ietf.org; Sun, 29 Aug 2004 05:54:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1MLX-000784-O8; Sun, 29 Aug 2004 05:51:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1MHg-0006PA-H6 for rtg-dir@megatron.ietf.org; Sun, 29 Aug 2004 05:47:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27078 for ; Sun, 29 Aug 2004 05:47:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1MJE-0007Qi-13 for rtg-dir@ietf.org; Sun, 29 Aug 2004 05:49:12 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1MHU-000DqC-VV; Sun, 29 Aug 2004 09:47:25 +0000 Message-ID: <4131A654.8090004@psg.com> Date: Sun, 29 Aug 2004 11:48:04 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <1810410594.20040827135847@psg.com> In-Reply-To: <1810410594.20040827135847@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: RTG-Dir reviews X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit hi alex, i think the below reproduce our rtg-dir mtg discussions note: concerning the skipping rules (point 2) exercising the process has shown (see lsp-attributes document review) that there are additional exceptions e.g. co-author and chairmanship thanks, - dimitri. Alex Zinin wrote: > Guys- > > Here's the summary of what we chatted about at the rtg-dir bar meeting in SD. > > We need a better/easier process for document review. In particular, we need an > agreed upon simple algo for assigning the reviewers to the documents, and a > tool to track the assignments. We agreed that: > > 1. A skills matrix for rtg-dir members would be maintained. Each person would > have a list of protocols/areas of expertise he/she is particularly good at. > > I put together the first version of it. Please take a look and send me an > e-mail with corrections or if I forgot to put you in the table. > > http://psg.com/~zinin/ietf/rtg-dir/rtg-dir-skills.html > > 2. The reviewer assignment algo would be as follows: > > 1st reviewer is chosen based on the skill set. (if more than one match is > found, take the person who hasn't reviewed any doc for longest time) > > 2nd reviewer is assigned using round-robin (skipping the 1st reviewer, > of course) > > 3. Mark and Bill are going to help us with the tool, using RT. > > 4. All rtg-dir members commit to pick up the assignments or inform that > they are not able to do the review in time > > I will use a standard subject line to make it easier, e.g.: > > Subject: review assignment: draft-whoever-what-ever-365.txt: acee, dmm > > Anything else I forgot? > From rtg-dir-bounces@ietf.org Mon Aug 30 14:19:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14440 for ; Mon, 30 Aug 2004 14:19:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1qmJ-0001z2-R8 for rtg-dir-archive@ietf.org; Mon, 30 Aug 2004 14:21:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1qjm-0004Wc-9Q; Mon, 30 Aug 2004 14:18:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1qcx-0003j2-UC for rtg-dir@megatron.ietf.org; Mon, 30 Aug 2004 14:11:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14036; Mon, 30 Aug 2004 14:11:31 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1qeh-0001pV-2N; Mon, 30 Aug 2004 14:13:26 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C1qcq-000K2H-M0; Mon, 30 Aug 2004 18:11:28 +0000 Date: Mon, 30 Aug 2004 11:02:28 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <751365668.20040830110228@psg.com> To: rtg-dir@ietf.org, rtg-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: O&M section in RTG documents? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Folks- Two people--Loa and Adrian--have recently mentioned the idea of requiring a mandatory "Operations and Management Considerations" section in the routing area documents. Such section would explain management considerations, such as required changes to MIBs, as well as expected operational impact and required techniques/actions/additional protocols. Opinions appreciated. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Mon Aug 30 17:13:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03153 for ; Mon, 30 Aug 2004 17:13:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1tVF-0008Dh-Iy for rtg-dir-archive@ietf.org; Mon, 30 Aug 2004 17:15:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1tD4-0003mG-5u; Mon, 30 Aug 2004 16:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1saS-0002Ug-2U for rtg-dir@megatron.ietf.org; Mon, 30 Aug 2004 16:17:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23783 for ; Mon, 30 Aug 2004 16:17:05 -0400 (EDT) Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1scG-0004yV-SW for rtg-dir@ietf.org; Mon, 30 Aug 2004 16:19:02 -0400 Received: from [205.168.100.50] (dhcp1.tcb.net [205.168.100.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 5D0F7642D4; Mon, 30 Aug 2004 14:17:03 -0600 (MDT) In-Reply-To: <4131A654.8090004@psg.com> References: <1810410594.20040827135847@psg.com> <4131A654.8090004@psg.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7B8A620B-FAC1-11D8-B68A-000393D54EA6@arbor.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Mon, 30 Aug 2004 14:16:31 -0600 To: Alex Zinin X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: RTG-Dir reviews X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit On Aug 29, 2004, at 3:48 AM, dimitri papadimitriou wrote: >> 4. All rtg-dir members commit to pick up the assignments or inform >> that >> they are not able to do the review in time Make sense. One question.. How is "in time" conveyed to the reviewer? -danny From rtg-dir-bounces@ietf.org Mon Aug 30 17:13:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03190 for ; Mon, 30 Aug 2004 17:13:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1tVL-0008E0-PZ for rtg-dir-archive@ietf.org; Mon, 30 Aug 2004 17:15:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1tD6-0003nJ-AP; Mon, 30 Aug 2004 16:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1sb3-0002tS-DA for rtg-dir@megatron.ietf.org; Mon, 30 Aug 2004 16:17:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23818 for ; Mon, 30 Aug 2004 16:17:43 -0400 (EDT) Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1scr-000504-58 for rtg-dir@ietf.org; Mon, 30 Aug 2004 16:19:39 -0400 Received: from [205.168.100.50] (dhcp1.tcb.net [205.168.100.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 91AEF642D4; Mon, 30 Aug 2004 14:17:44 -0600 (MDT) In-Reply-To: <1538021461.20040827151807@psg.com> References: <1538021461.20040827151807@psg.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <948EBAF0-FAC1-11D8-B68A-000393D54EA6@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Mon, 30 Aug 2004 14:17:13 -0600 To: Alex Zinin X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: review assignment: draft-ietf-mpls-explicit-null-01.txt: danny, mjh X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 4:18 PM, Alex Zinin wrote: > > skill-specific: danny Ack! -danny From rtg-dir-bounces@ietf.org Tue Aug 31 07:01:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06382 for ; Tue, 31 Aug 2004 07:01:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C26Pu-0008N1-GD for rtg-dir-archive@ietf.org; Tue, 31 Aug 2004 07:03:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C26Mv-0007zD-Qi; Tue, 31 Aug 2004 07:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C26HA-0007RB-0f for rtg-dir@megatron.ietf.org; Tue, 31 Aug 2004 06:54:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05738 for ; Tue, 31 Aug 2004 06:54:05 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C26J6-00088u-I5 for rtg-dir@ietf.org; Tue, 31 Aug 2004 06:56:10 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Aug 2004 13:07:00 +0200 X-BrightmailFiltered: true Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7VArVTO014774; Tue, 31 Aug 2004 12:53:32 +0200 (MEST) Received: from mshand-w2k02.cisco.com (dhcp-rea-gp250-64-103-65-143.cisco.com [64.103.65.143]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA25120; Tue, 31 Aug 2004 11:53:31 +0100 (BST) Message-Id: <4.3.2.7.2.20040831115319.022c8268@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Aug 2004 11:53:39 +0100 To: Alex Zinin From: mike shand In-Reply-To: <93463290.20040827152248@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rtg-dir@ietf.org Subject: Re: review assignment: draft-ietf-mpls-rsvpte-attributes-04.txt: rcallon; mshand X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 At 15:22 27/08/2004 -0700, Alex Zinin wrote: >skill-specific: Ross (Dimitri skipped as co-author, Loa as co-chair) >round-robin: Mike OK. Mike >http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvpte-attributes-04.txt > > > Encoding of Attributes for Multiprotocol Label Switching (MPLS) > > Label Switched Path (LSP) Establishment Using RSVP-TE > > > Abstract > > > > Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may > > be established using the Resource Reservation Protocol Traffic > > Engineering extensions (RSVP-TE). This protocol includes an object > > (the SESSION_ATTRIBUTE object) which carries a flags field used to > > indicate options and attributes of the LSP. That flags field has > > eight bits allowing for eight options to be set. Recent proposals in > > many documents that extend RSVP-TE have suggested uses for each of > > the previously unused bits. > > > > This document defines a new object for RSVP-TE messages that allows > > the signaling of further attribute bits and also the carriage of > > arbitrary attribute parameters to make RSVP-TE easily extensible to > > support new requirements. Additionally, this document defines a way > > to record the attributes applied to the LSP on a hop-by-hop basis. > > > > The object mechanisms defined in this document are equally applicable > > to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to > > GMPLS non-PSC LSPs. > >-- >Alex >http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Tue Aug 31 17:14:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03345 for ; Tue, 31 Aug 2004 17:14:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2G02-0000Bk-3h for rtg-dir-archive@ietf.org; Tue, 31 Aug 2004 17:17:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2FeZ-0007mk-5P; Tue, 31 Aug 2004 16:54:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2FX4-0004yh-8y for rtg-dir@megatron.ietf.org; Tue, 31 Aug 2004 16:47:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00731; Tue, 31 Aug 2004 16:44:04 -0400 (EDT) From: Mukesh.Gupta@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2FW8-0007jy-1z; Tue, 31 Aug 2004 16:46:13 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i7VKi0111550; Tue, 31 Aug 2004 23:44:00 +0300 (EET DST) X-Scanned: Tue, 31 Aug 2004 23:43:39 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i7VKhd9l018769; Tue, 31 Aug 2004 23:43:39 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00RzML6d; Tue, 31 Aug 2004 23:43:38 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 i7VKhaS14905; Tue, 31 Aug 2004 23:43:36 +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); Tue, 31 Aug 2004 15:43:04 -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 Date: Tue, 31 Aug 2004 15:43:03 -0500 Message-ID: <8D260779A766FB4A9C1739A476F84FA4026AB3D5@daebe009.americas.nokia.com> Thread-Topic: O&M section in RTG documents? Thread-Index: AcSOwZ/sSVGUqXemQTq9Ctl4WJMt9gA2VeQg To: , , X-OriginalArrivalTime: 31 Aug 2004 20:43:04.0638 (UTC) FILETIME=[1D3BD5E0:01C48F9B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Subject: RE: O&M section in RTG documents? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Sounds like a good idea to me. > -----Original Message----- > From: ext Alex Zinin [mailto:zinin@psg.com] > Sent: Monday, August 30, 2004 11:02 AM > To: rtg-dir@ietf.org; rtg-chairs@ietf.org > Subject: O&M section in RTG documents? >=20 >=20 > Folks- >=20 > Two people--Loa and Adrian--have recently mentioned the idea=20 > of requiring a > mandatory "Operations and Management Considerations" section=20 > in the routing > area documents. Such section would explain management=20 > considerations, such as > required changes to MIBs, as well as expected operational=20 > impact and required > techniques/actions/additional protocols. >=20 > Opinions appreciated. > =20 > --=20 > Alex > http://www.psg.com/~zinin >=20 >=20 From rtg-dir-bounces@ietf.org Tue Aug 31 18:48:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09634 for ; Tue, 31 Aug 2004 18:48:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2HSU-0001pr-8b for rtg-dir-archive@ietf.org; Tue, 31 Aug 2004 18:50:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HL1-0003Kf-5O; Tue, 31 Aug 2004 18:42:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HK5-0002oD-Uu for rtg-dir@megatron.ietf.org; Tue, 31 Aug 2004 18:41:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09063; Tue, 31 Aug 2004 18:39:09 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2HJW-0001gI-QS; Tue, 31 Aug 2004 18:41:20 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 678E42D497B; Tue, 31 Aug 2004 18:38: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 48063-01-65; Tue, 31 Aug 2004 18:38: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 301672D4977; Tue, 31 Aug 2004 18:38:33 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Aug 2004 18:38:32 -0400 Message-ID: Thread-Topic: O&M section in RTG documents? Thread-Index: AcSOwZ/sSVGUqXemQTq9Ctl4WJMt9gA2VeQgAAQQlLA= From: "Susan Hares" To: , , , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Subject: RE: O&M section in RTG documents? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable I think this is a good idea. Sue -----Original Message----- From: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] Sent: Tuesday, August 31, 2004 4:43 PM To: zinin@psg.com; rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: RE: O&M section in RTG documents? Sounds like a good idea to me. > -----Original Message----- > From: ext Alex Zinin [mailto:zinin@psg.com] > Sent: Monday, August 30, 2004 11:02 AM > To: rtg-dir@ietf.org; rtg-chairs@ietf.org > Subject: O&M section in RTG documents? >=20 >=20 > Folks- >=20 > Two people--Loa and Adrian--have recently mentioned the idea=20 > of requiring a > mandatory "Operations and Management Considerations" section=20 > in the routing > area documents. Such section would explain management=20 > considerations, such as > required changes to MIBs, as well as expected operational=20 > impact and required > techniques/actions/additional protocols. >=20 > Opinions appreciated. > =20 > --=20 > Alex > http://www.psg.com/~zinin >=20 >=20 From rtg-dir-bounces@ietf.org Tue Aug 31 18:58:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10069 for ; Tue, 31 Aug 2004 18:58:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2HcI-0001wz-HD for rtg-dir-archive@ietf.org; Tue, 31 Aug 2004 19:00:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HWb-0005i8-88; Tue, 31 Aug 2004 18:54:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HVC-0005T0-E4 for rtg-dir@megatron.ietf.org; Tue, 31 Aug 2004 18:53:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09931; Tue, 31 Aug 2004 18:53:18 -0400 (EDT) Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2HXE-0001sv-LI; Tue, 31 Aug 2004 18:55:29 -0400 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i7VMqj0g099534; Tue, 31 Aug 2004 15:52:45 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i7VMqjmv099531; Tue, 31 Aug 2004 15:52:45 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Tue, 31 Aug 2004 15:52:45 -0700 (PDT) From: Kireeti Kompella To: Alex Zinin In-Reply-To: Message-ID: <20040831154254.D98991@kummer.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: RE: O&M section in RTG documents? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Tue, 31 Aug 2004, Susan Hares wrote: > I think this is a good idea. I'm generally in favor, but I will reserve judgment until I see a "Guidelines for Writing an O&M Considerations Section" to assess the value of this, and the burden it imposes. If this goes forward, such a guideline is a MUST. You can't have a mandatory section and not have guidelines -- let's not repeat what happened with Security Considerations: "This document does not introduce any new security concerns." The other thing is, for non-routing documents, an O&M section may still be a good idea. So, while this might be out of scope for the rtg-dir, an optional O&M section for other docs should be vetted IETF-wide. Kireeti. ------- From rtg-dir-bounces@ietf.org Tue Aug 31 18:59:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10134 for ; Tue, 31 Aug 2004 18:59:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2HdU-0001yg-Sq for rtg-dir-archive@ietf.org; Tue, 31 Aug 2004 19:01:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HaV-0006BU-CP; Tue, 31 Aug 2004 18:58:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HXl-0005jJ-4C for rtg-dir@megatron.ietf.org; Tue, 31 Aug 2004 18:56:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09991 for ; Tue, 31 Aug 2004 18:55:58 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2HZo-0001vO-HT for rtg-dir@ietf.org; Tue, 31 Aug 2004 18:58:09 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2HXi-0005wf-Tq; Tue, 31 Aug 2004 22:55:58 +0000 Date: Tue, 31 Aug 2004 15:55:58 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <110262735.20040831155558@psg.com> To: Danny McPherson In-Reply-To: <7B8A620B-FAC1-11D8-B68A-000393D54EA6@arbor.net> References: <1810410594.20040827135847@psg.com> <4131A654.8090004@psg.com> <7B8A620B-FAC1-11D8-B68A-000393D54EA6@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: RTG-Dir reviews X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Monday, August 30, 2004, 1:16:31 PM, Danny McPherson wrote: ... > Make sense. One question.. How is "in time" conveyed to the > reviewer? How about the default review time of one week (if this is what you mean)? Alex From rtg-dir-bounces@ietf.org Tue Aug 31 19:02:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10328 for ; Tue, 31 Aug 2004 19:02:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2HgM-00021e-DL for rtg-dir-archive@ietf.org; Tue, 31 Aug 2004 19:04:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HcO-0006cF-GB; Tue, 31 Aug 2004 19:00:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HbK-0006Kp-BC for rtg-dir@megatron.ietf.org; Tue, 31 Aug 2004 18:59:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10008; Tue, 31 Aug 2004 18:56:48 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Had-0001vY-0W; Tue, 31 Aug 2004 18:58:59 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 99B142D4842; Tue, 31 Aug 2004 18:56: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 51341-01-3; Tue, 31 Aug 2004 18:56: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 62D102D482B; Tue, 31 Aug 2004 18:56:19 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Aug 2004 18:56:19 -0400 Message-ID: Thread-Topic: O&M section in RTG documents? Thread-Index: AcSPrXdOJKaGX8nqR72wN+zUiwK+6wAADzqQ From: "Susan Hares" To: "Kireeti Kompella" , "Alex Zinin" X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: RE: O&M section in RTG documents? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Good pont Kireeti! Sue -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net] Sent: Tuesday, August 31, 2004 6:53 PM To: Alex Zinin Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: RE: O&M section in RTG documents? On Tue, 31 Aug 2004, Susan Hares wrote: > I think this is a good idea. I'm generally in favor, but I will reserve judgment until I see a "Guidelines for Writing an O&M Considerations Section" to assess the value of this, and the burden it imposes. If this goes forward, such a guideline is a MUST. You can't have a mandatory section and not have guidelines -- let's not repeat what happened with Security Considerations: "This document does not introduce any new security concerns." The other thing is, for non-routing documents, an O&M section may still be a good idea. So, while this might be out of scope for the rtg-dir, an optional O&M section for other docs should be vetted IETF-wide. Kireeti. ------- From rtg-dir-bounces@ietf.org Tue Aug 31 19:13:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10924 for ; Tue, 31 Aug 2004 19:13:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2HrA-0002B7-G4 for rtg-dir-archive@ietf.org; Tue, 31 Aug 2004 19:16:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HhK-0007L3-Af; Tue, 31 Aug 2004 19:05:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Hgm-00078d-D5 for rtg-dir@megatron.ietf.org; Tue, 31 Aug 2004 19:05:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10415 for ; Tue, 31 Aug 2004 19:05:17 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Hip-000234-Mq for rtg-dir@ietf.org; Tue, 31 Aug 2004 19:07:29 -0400 Received: from phys-bur1-2 ([129.148.13.16]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i7VN5H35000500 for ; Tue, 31 Aug 2004 16:05:17 -0700 (PDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I3C000012PLON@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for rtg-dir@ietf.org; Tue, 31 Aug 2004 19:05:17 -0400 (EDT) Received: from sun.com (vpn-129-147-152-40.Central.Sun.COM [129.147.152.40]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0I3C001CU2SSSL@bur-mail2.east.sun.com>; Tue, 31 Aug 2004 19:05:17 -0400 (EDT) Date: Tue, 31 Aug 2004 16:05:15 -0700 From: Radia Perlman In-reply-to: <1810410594.20040827135847@psg.com> To: Alex Zinin Message-id: <4135042B.6000701@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 References: <1810410594.20040827135847@psg.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT Cc: rtg-dir@ietf.org Subject: Re: RTG-Dir reviews X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7BIT Definitely it's helpful having a standard subject line, but then people do replies to it, so I can imagine my not noticing for a few days that I've been assigned something. Could you make the subject line include the names of the assigned reviewers, as in: rtg-dir assignment: Radia, Danny, draft-mumble-mumble Thanks, Radia > > I will use a standard subject line to make it easier, e.g.: > > Subject: review assignment: draft-whoever-what-ever-365.txt: acee, dmm > > Anything else I forgot? > > > From rtg-dir-bounces@ietf.org Tue Aug 31 19:15:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11036 for ; Tue, 31 Aug 2004 19:15:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Ht3-0002DB-7j for rtg-dir-archive@ietf.org; Tue, 31 Aug 2004 19:18:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HpE-0000Nu-P9; Tue, 31 Aug 2004 19:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HlO-00080t-FL for rtg-dir@megatron.ietf.org; Tue, 31 Aug 2004 19:10:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10457; Tue, 31 Aug 2004 19:05:58 -0400 (EDT) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2HjU-00023D-5z; Tue, 31 Aug 2004 19:08:09 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 6F3B9A7BB1; Tue, 31 Aug 2004 19:05:28 -0400 (EDT) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i7VN5SZ28048; Tue, 31 Aug 2004 16:05:28 -0700 (PDT) Message-Id: <200408312305.i7VN5SZ28048@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: kireeti@juniper.net References: <20040831154254.D98991@kummer.juniper.net> Date: Tue, 31 Aug 2004 16:05:27 -0700 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: RE: O&M section in RTG documents? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Kireeti says: >I will reserve judgment until I see a >"Guidelines for Writing an O&M Considerations Section" to assess the >value of this, and the burden it imposes. I think I agree here. There's been a lot of confusion about what's needed in security considerations, and even with RFC3552 it sometimes seems to come down to "Write what you think it should say, then have it on an IESG telechat to find out what the security ADs think it should say". I like the concept, especially if it improves followthrough on addressing any problems that might be identified, but I am wary of accomplishing anything just by adding a required section - the work to fill it in won't just materialize and in some instances we're having enough trouble just getting the protocol portion done... Bill From rtg-dir-bounces@ietf.org Tue Aug 31 19:20:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11306 for ; Tue, 31 Aug 2004 19:20:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Hy1-0002Ha-Rb for rtg-dir-archive@ietf.org; Tue, 31 Aug 2004 19:23:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Hs9-00010q-L9; Tue, 31 Aug 2004 19:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Hpk-0000OJ-AD for rtg-dir@megatron.ietf.org; Tue, 31 Aug 2004 19:14:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10949 for ; Tue, 31 Aug 2004 19:14:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Hro-0002BV-If for rtg-dir@ietf.org; Tue, 31 Aug 2004 19:16:45 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2Hph-00095X-P7; Tue, 31 Aug 2004 23:14:33 +0000 Date: Tue, 31 Aug 2004 16:14:33 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1317443531.20040831161433@psg.com> To: dimitri papadimitriou In-Reply-To: <4130B1B7.1010306@psg.com> References: <1555437345.20040827125059@psg.com> <24a101c48cf1$6fa185c0$11849ed9@Puppy> <4130B1B7.1010306@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Adrian Farrel , Bill Fenner , rtg-dir@ietf.org, "Dimitri.Papadimitriou" Subject: Re: AD-review comments on draft-ietf-ccamp-gmpls-g709 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Dimitri, Adrian- >>>Meta: this draft talks about the signaling component, what about >>> the routing part of the story? >> >> >> No different to any G-PID or encoding type. That is, end-point capabilities are not >> currently advertised in GMPLS routing. Some people see this as a failing, others say that >> since you are attempting to open an end-to-end connection, you are presumably trying to >> contact a known (called) party and it would be usual to have either: >> - some understanding of the capablities of the person you are trying to reach >> or >> - limited capablities, yourself. >> >> Anyway, this draft is simply extending the list of encodings and G-PIDs to cover G.709. >> Endocings and G-PIDs are signaled quantites that are not advertised. > as for sdh/sonet a couple of technology specific extensions where > initiated early 2000 and took a more stable form end of 2002, that would > have taken one of the following form: add. sub-TLV or extension of the > technology specific part of the ISC sub-TLV descriptor for intra-domain > TE and that would have included specific end-point capabilities, > however since so far they've never been considered as working group item > (stayed at the individual submission level) > note: G-PIDs are not advertized but encodings are as part of the ISC sub-TLV To make sure we have the bottom line right: is the routing part a required piece for the implementations of gmpls-g709 to interoperate? >>>>3.1.1 LSP Encoding Type >>>> Therefore, the current "Digital Wrapper" code-point defined in >>>> [RFC3471] can be replaced by two separate code-points: >>> >>>What does "replaced" mean here? >> >> Good question. Presume that we can't obsolete "Digital Wrapper" without some care. So we >> need text to describe how it is handled. > here the issue is a timing problem, as G.709 was issued by the time RFC > 3471 went out, combined with a formulation problem, as we can safely > assume that the digital wrappers that were already available by that > time were not fully G.709 compliant -> so it would be better to speak > about a rename of the existing RFC 3471 value and add-on of a new value The question here is whether the original "Digital Wrapper" code point has been used or not, and how safe it is change the semantics vs defining a new value for g.709. >>>>3.1.2 Switching Type >>>> Moreover, in a strict layered G.709 network, when a downstream node >>>> receives a Generalized Label Request including one of these values >>>> for the Switching Type field, this value SHOULD be ignored. >>> >>>What about other values? Should the field be ignored all together? > the "field" SHOULD be ignored, if not (and in this case, thus simply > used as an indication of the LSP class), the value of this field MUST be > either of type TDM or LSC depending of the Signal Type value Well, you guys need to pick whether you're going to ask the implementor to ignore the field, or to check it for a specific value. In the latter case, you also need to specify what to do if the check fails. >>>> In case of ODUk in OTUk mapping, only one of label can appear in the >>>> Generalized Label. > add "The unique is encoded as single 32 bit label value (as defined in > Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2)" >>>> In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered >>>> list of the labels in the multiplex is given (this list can be >>>> restricted to only one label when NMC = 1). Each label indicates a >>>> component (ODUj tributary slot) of the multiplexed signal. The order >>>> of the labels must reflect the order of the ODUj into the multiplex >>>> (not the physical order of tributary slots). > add "This ordered list of labels is encoded a sequence of 32 bit label > values (as defined in Section 4.1) of the GENERALIZED_LABEL object > (Class-Num = 16, C-Type = 2)" >>>> In case of ODUk virtual concatenation, the explicit ordered list of >>>> all labels in the concatenation is given. Each label indicates a >>>> component of the virtually concatenated signal. The order of the >>>> labels must reflect the order of the ODUk to concatenate (not the >>>> physical order of time-slots). This representation limits virtual >>>> concatenation to remain within a single (component) link. In case of >>>> multiplexed virtually concatenated signals, the first set of labels >>>> indicates the components (ODUj tributary slots) of the first >>>> virtually concatenated signal, the second set of labels indicates >>>> the components (ODUj tributary slots) of the second virtually >>>> concatenated signal, and so on. > ditto >>>> In case of multiplication (i.e. when using the MT field), the >>>> explicit ordered list of all labels taking part in the composed >>>> signal is given. The above representation limits multiplication to >>>> remain within a single (component) link. In case of multiplication >>>> of multiplexed/virtually concatenated signals, the first set of >>>> labels indicates the components of the first multiplexed/virtually >>>> concatenated signal, the second set of labels indicates components >>>> of the second multiplexed/virtually concatenated signal, and so on. > ditto Pardon if I sound ignorant... Are both sets (the first and the second) encoded together in the same GEN_LABEL object? How does one tell "the first set of labels" from "the second"? >>>What does the last para mean to IANA? Is this a request to create >>>new registries? If so, more info needs to be given, e.g.: >>> >>> - name of the registry >>> - format >>> - allocation policy >>> - initial values >> >> >> Hmmm. Probably my fault since I asked for this. >> Encodigng type and G-PID would, indeed, be two new registries. Primarily they are defined >> in RFC3471, but this draft introduces some new values and the values should be tracked and >> monitored. >> >> So, yes, this is a request for two new registries. The info provided to IANA should also >> point at all existing definitions. > in this case, i would also then suggest to create an entry for the > switching type values the document will include the required information > for each of them As long as we provide proper instructions to IANA--I'm fine. Thanks. Alex From rtg-dir-bounces@ietf.org Tue Aug 31 19:25:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11732 for ; Tue, 31 Aug 2004 19:25:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2I2n-0002Mv-Je for rtg-dir-archive@ietf.org; Tue, 31 Aug 2004 19:28:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Hvv-0001h4-Ug; Tue, 31 Aug 2004 19:20:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Hrz-0000zm-G5 for rtg-dir@megatron.ietf.org; Tue, 31 Aug 2004 19:16:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11118 for ; Tue, 31 Aug 2004 19:16:52 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Hu3-0002E7-0c for rtg-dir@ietf.org; Tue, 31 Aug 2004 19:19:04 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2Hrw-0009RM-1I; Tue, 31 Aug 2004 23:16:52 +0000 Date: Tue, 31 Aug 2004 16:16:51 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1268588325.20040831161651@psg.com> To: Lou Berger In-Reply-To: <6.1.2.0.2.20040828105235.0437a590@mo-ex1> References: <1818831285.20040827131830@psg.com> <6.1.2.0.2.20040828105235.0437a590@mo-ex1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Adrian Farrel , Bill Fenner , rtg-dir@ietf.org Subject: Re: AD-review comments on draft-ietf-ccamp-gmpls-egress-control X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Thanks, Lou. IETF LC requested. -- Alex http://www.psg.com/~zinin Saturday, August 28, 2004, 7:56:23 AM, Lou Berger wrote: > Alex, > Thanks for the feed back. See below for responses. > At 04:18 PM 8/27/2004 -0400, Alex Zinin wrote: >>Adrian, Kireeti, Lou- >> >>Just a couple of small comments. Feel free to fwd to the WG. >> >>Ed: please use the new ID boilerplates. > sure. >> > Abstract >> > >> > This note clarifies the procedures for the control of the label used >> > on a output/downstream interface of the egress node of a Label >> > Switched Path (LSP). Such control is also known as "Egress Control". >> > Support for Egress Control is implicit in Generalized Multi-Protocol >> > Label Switching (GMPLS) Signaling. This note does not modify GMPLS >> > signaling mechanisms and procedures and should be viewed as an >> > informative clarification of GMPLS Signaling - Resource ReserVation >> > Protocol-Traffic Engineering (RSVP-TE) Extensions. >> >>Given that the doc goes STD track, I suggest that the last sentence is >>changed to say "This note is a clarification update to the specification >>of GMPLS Signaling..." > sure. Although, I think BCP is appropriate given that this is just saying > "this is what the rfc says"... >> > Author's Note >> > >> > This draft is targeted for publication as a BCP. >> >>This one should be removed for the same reason. > done. >>-- >>Alex >>http://www.psg.com/~zinin > Thanks again, > Lou From rtg-dir-bounces@ietf.org Tue Aug 31 19:34:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12230 for ; Tue, 31 Aug 2004 19:34:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2IAp-0002V9-LT for rtg-dir-archive@ietf.org; Tue, 31 Aug 2004 19:36:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2I0k-0002dS-0N; Tue, 31 Aug 2004 19:25:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2HvB-0001X3-IX for rtg-dir@megatron.ietf.org; Tue, 31 Aug 2004 19:20:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11282; Tue, 31 Aug 2004 19:20:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2HxD-0002H1-Uu; Tue, 31 Aug 2004 19:22:21 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2Hv7-000A5u-VR; Tue, 31 Aug 2004 23:20:10 +0000 Date: Tue, 31 Aug 2004 16:20:10 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1018839778.20040831162010@psg.com> To: Bill Fenner In-Reply-To: <200408312305.i7VN5SZ28048@windsor.research.att.com> References: <20040831154254.D98991@kummer.juniper.net> <200408312305.i7VN5SZ28048@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: kireeti@juniper.net, rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: O&M section in RTG documents? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Makes sense. So, in the spirit of IETF :), how about Loa and Adrian come up with an individual draft, containing the guidelines for the O&M section. This should give some meat for the discussion. -- Alex http://www.psg.com/~zinin Tuesday, August 31, 2004, 4:05:27 PM, Bill Fenner wrote: > Kireeti says: >>I will reserve judgment until I see a >>"Guidelines for Writing an O&M Considerations Section" to assess the >>value of this, and the burden it imposes. > I think I agree here. There's been a lot of confusion about what's > needed in security considerations, and even with RFC3552 it sometimes > seems to come down to "Write what you think it should say, then have > it on an IESG telechat to find out what the security ADs think it should > say". > I like the concept, especially if it improves followthrough on > addressing any problems that might be identified, but I am wary > of accomplishing anything just by adding a required section - the > work to fill it in won't just materialize and in some instances > we're having enough trouble just getting the protocol portion > done... > Bill From rtg-dir-bounces@ietf.org Tue Aug 31 19:34:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12335 for ; Tue, 31 Aug 2004 19:34:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2IBM-0002WI-PC for rtg-dir-archive@ietf.org; Tue, 31 Aug 2004 19:36:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2I4Z-0003PT-IM; Tue, 31 Aug 2004 19:29:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Hxx-0002Gq-6e for rtg-dir@megatron.ietf.org; Tue, 31 Aug 2004 19:23:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11441 for ; Tue, 31 Aug 2004 19:23:02 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2I00-0002JY-RC for rtg-dir@ietf.org; Tue, 31 Aug 2004 19:25:14 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2Hxv-000AhX-5a; Tue, 31 Aug 2004 23:23:03 +0000 Date: Tue, 31 Aug 2004 16:23:03 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1801143621.20040831162303@psg.com> To: Radia Perlman In-Reply-To: <4135042B.6000701@sun.com> References: <1810410594.20040827135847@psg.com> <4135042B.6000701@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: RTG-Dir reviews X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Radia- The name were there, just at the end of the line :) In fact, I also thought they should be moved to the beginning when I saw the subject line truncated by the column width in my client. Will change. Another thing I could do is cc specific addresses of the assignees, if that will help. (I, for example, change the color of the messages where my address is included explicitly, so it draws my attention.) Alex Tuesday, August 31, 2004, 4:05:15 PM, Radia Perlman wrote: > Definitely it's helpful having a standard subject line, but then people > do replies > to it, so I can imagine my not noticing for a few days that I've been > assigned > something. > Could you make the subject line include the names of the assigned reviewers, > as in: > rtg-dir assignment: Radia, Danny, draft-mumble-mumble > Thanks, > Radia >> >> I will use a standard subject line to make it easier, e.g.: >> >> Subject: review assignment: draft-whoever-what-ever-365.txt: acee, dmm >> >> Anything else I forgot? >> >> >> From rtg-dir-bounces@ietf.org Wed Sep 1 00:37:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04863 for ; Wed, 1 Sep 2004 00:37:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2MuI-0008Lk-4U for rtg-dir-archive@ietf.org; Wed, 01 Sep 2004 00:39:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Mq3-0004Tj-Jf; Wed, 01 Sep 2004 00:35:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Mp5-00048B-Gv for rtg-dir@megatron.ietf.org; Wed, 01 Sep 2004 00:34:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04504 for ; Wed, 1 Sep 2004 00:34:13 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Mr7-0008Gx-Ox for rtg-dir@ietf.org; Wed, 01 Sep 2004 00:36:27 -0400 Received: from phys-bur1-2 ([129.148.13.16]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i814Y8il012601 for ; Tue, 31 Aug 2004 22:34:09 -0600 (MDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I3C00501HHHSG@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for rtg-dir@ietf.org; Wed, 01 Sep 2004 00:34:08 -0400 (EDT) Received: from sun.com (vpn-129-147-152-40.Central.Sun.COM [129.147.152.40]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0I3C00GN0I0V0Q@bur-mail2.east.sun.com>; Wed, 01 Sep 2004 00:34:08 -0400 (EDT) Date: Tue, 31 Aug 2004 21:34:06 -0700 From: Radia Perlman In-reply-to: <1801143621.20040831162303@psg.com> To: Alex Zinin Message-id: <4135513E.209@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 References: <1810410594.20040827135847@psg.com> <4135042B.6000701@sun.com> <1801143621.20040831162303@psg.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7BIT Cc: rtg-dir@ietf.org Subject: Re: RTG-Dir reviews X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7BIT I have a stupid email reading client and it wouldn't help to also CC me specifically. But having my name "in lights" so to speak, near the beginning of the subject line, would definitely catch my attention. I also don't think it's necessary to have the name of the internet draft in the subject line, but it would be nice to have the complete URL in the body of the message so it can just be clicked on. So I'd vote for a subject line of: rtg-dir review: name1, name2 and the convention being that the 1st name would be the subject expert and the 2nd would be the round robin. And the name of the internet draft could be at the end if people think it would be helpful. Thanks, Radia Alex Zinin wrote: >Radia- > > The name were there, just at the end of the line :) In fact, I also thought > they should be moved to the beginning when I saw the subject line truncated > by the column width in my client. Will change. > > Another thing I could do is cc specific addresses of the assignees, if that > will help. (I, for example, change the color of the messages where my address > is included explicitly, so it draws my attention.) > >Alex > > >Tuesday, August 31, 2004, 4:05:15 PM, Radia Perlman wrote: > > >>Definitely it's helpful having a standard subject line, but then people >>do replies >>to it, so I can imagine my not noticing for a few days that I've been >>assigned >>something. >> >> > > > >>Could you make the subject line include the names of the assigned reviewers, >>as in: >> >> > > > >>rtg-dir assignment: Radia, Danny, draft-mumble-mumble >> >> > > > >>Thanks, >> >> > > > >>Radia >> >> > > > >>> I will use a standard subject line to make it easier, e.g.: >>> >>> Subject: review assignment: draft-whoever-what-ever-365.txt: acee, dmm >>> >>>Anything else I forgot? >>> >>> >>> >>> >>> > > > > > From rtg-dir-bounces@ietf.org Wed Sep 1 02:49:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12274 for ; Wed, 1 Sep 2004 02:49:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Oxl-00025k-AG for rtg-dir-archive@ietf.org; Wed, 01 Sep 2004 02:51:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2OrL-0003Kd-L9; Wed, 01 Sep 2004 02:44:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Onz-0002gZ-Hw for rtg-dir@megatron.ietf.org; Wed, 01 Sep 2004 02:41:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11184; Wed, 1 Sep 2004 02:39:18 -0400 (EDT) Received: from av7-2-sn1.fre.skanova.net ([81.228.11.114]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2OoE-0001qg-FZ; Wed, 01 Sep 2004 02:41:31 -0400 Received: by av7-2-sn1.fre.skanova.net (Postfix, from userid 502) id 27B2937EEA; Wed, 1 Sep 2004 08:38:45 +0200 (CEST) Received: from smtp3-2-sn1.fre.skanova.net (smtp3-2-sn1.fre.skanova.net [81.228.11.164]) by av7-2-sn1.fre.skanova.net (Postfix) with ESMTP id 1A3DF37E68; Wed, 1 Sep 2004 08:38:45 +0200 (CEST) Received: from [127.0.0.1] (h60n2fls307o1033.telia.com [81.226.61.60]) by smtp3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 79ADD37E46; Wed, 1 Sep 2004 08:38:44 +0200 (CEST) Message-ID: <41356E6D.5030003@pi.se> Date: Wed, 01 Sep 2004 08:38:37 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <20040831154254.D98991@kummer.juniper.net> <200408312305.i7VN5SZ28048@windsor.research.att.com> <1018839778.20040831162010@psg.com> In-Reply-To: <1018839778.20040831162010@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Bill Fenner , kireeti@juniper.net, rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Re: O&M section in RTG documents? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit All, should have seen coming and ran for cover int time :). Will discuss with Adrian. /Loa Alex Zinin wrote: > Makes sense. > > So, in the spirit of IETF :), how about Loa and Adrian come up with an > individual draft, containing the guidelines for the O&M section. This > should give some meat for the discussion. > From rtg-dir-bounces@ietf.org Wed Sep 1 12:38:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06304 for ; Wed, 1 Sep 2004 12:38:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2YAV-0002kG-JL for rtg-dir-archive@ietf.org; Wed, 01 Sep 2004 12:41:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XMo-0005xN-2a; Wed, 01 Sep 2004 11:49:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VHK-0004bp-Ns for rtg-dir@megatron.ietf.org; Wed, 01 Sep 2004 09:35:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05536; Wed, 1 Sep 2004 09:33:24 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2UsB-0005E3-NF; Wed, 01 Sep 2004 09:10:00 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 36B332D482C; Wed, 1 Sep 2004 09:07: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 01674-04-45; Wed, 1 Sep 2004 09:07:12 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0FDF42D4824; Wed, 1 Sep 2004 09:07:12 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i81D6ub03389; Wed, 1 Sep 2004 09:06:56 -0400 (EDT) Date: Wed, 1 Sep 2004 09:06:56 -0400 From: Jeffrey Haas To: Bill Fenner Message-ID: <20040901130656.GA591@nexthop.com> References: <20040831154254.D98991@kummer.juniper.net> <200408312305.i7VN5SZ28048@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408312305.i7VN5SZ28048@windsor.research.att.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: kireeti@juniper.net, rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: O&M section in RTG documents? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 On Tue, Aug 31, 2004 at 04:05:27PM -0700, Bill Fenner wrote: > I think I agree here. There's been a lot of confusion about what's > needed in security considerations, and even with RFC3552 it sometimes > seems to come down to "Write what you think it should say, then have > it on an IESG telechat to find out what the security ADs think it should > say". Having such a thing is, I think, a nice idea. Just to make sure I'm understanding the proposal, you're suggesting O&M not strictly as "when you do your MIB, this is what should go in there" but also a section on expected operational considerations in a live network? Regarding the MIB portion, many protocol elements that should go into MIBs are reasonably obvious although I understand that configurability is still somewhat controversial. What would be nice for MIB authors is a document that has recommendations on how to go about representing various elements of protocol data structurally in the MIB. As a specific example, much of the lack of progress on the BGP MIBv2 has been because I seem to continually stump the IDR MIB doctors (two of them now) in trying to represent elements in the BGP "routing table" (specifically the RIBs). Also, a MIB author's FAQ on writing MIBs would be handy. I've also hit cases where I represent something that is "structurally sound" in SMIv2 but it is suggested that I change things because "it looks weird". Another item of concern that crosses both the operational and the SNMP concerns for an O&M section is when one should put elements in a MIB that aren't specifically related to the protocol. I had received a request from Tom Nadeau to take a last look at the l3vpn MIB since there were interaction considerations with BGP. While the l3vpn MIB contained most of the protocol elements that I would want to represent, it also contained "high water marks" and a pointer to policy elements that weren't specifically part of the protocol. Certainly these things are useful, but I'm not certain that they belong as part of the MIB. Thus, if we're going to write such a thing, we should also suggest things that do NOT belong. > I like the concept, especially if it improves followthrough on > addressing any problems that might be identified, but I am wary > of accomplishing anything just by adding a required section - the > work to fill it in won't just materialize and in some instances > we're having enough trouble just getting the protocol portion > done... I would tend to agree. I still consider myself an amateur at writing MIBs, but given some of my conversations with other people it sounds like I almost should list MIBs as a "skill" in my rtg-dir profile. This doesn't mean I'm qualified to say what's good or bad O&M practice from a MIB doctor's point of view, but I can at least review them from the level of protocol practice->MIB. > Bill -- Jeff Haas NextHop Technologies From rtg-dir-bounces@ietf.org Wed Sep 1 12:45:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07495 for ; Wed, 1 Sep 2004 12:45:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2YGa-0003gD-Pm for rtg-dir-archive@ietf.org; Wed, 01 Sep 2004 12:47:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XN1-0006CY-DT; Wed, 01 Sep 2004 11:49:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VIf-00058l-UB for rtg-dir@megatron.ietf.org; Wed, 01 Sep 2004 09:37:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08603 for ; Wed, 1 Sep 2004 09:37:16 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Rmd-0003KQ-UA for rtg-dir@ietf.org; Wed, 01 Sep 2004 05:52:04 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2Rk1-000Dhm-Tz; Wed, 01 Sep 2004 09:49:22 +0000 Message-ID: <41359B48.2060509@psg.com> Date: Wed, 01 Sep 2004 11:50:00 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <1555437345.20040827125059@psg.com> <24a101c48cf1$6fa185c0$11849ed9@Puppy> <4130B1B7.1010306@psg.com> <1317443531.20040831161433@psg.com> In-Reply-To: <1317443531.20040831161433@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Adrian Farrel , Bill Fenner , "Dimitri.Papadimitriou" , rtg-dir@ietf.org Subject: Re: AD-review comments on draft-ietf-ccamp-gmpls-g709 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit hi alex, adrian - see in-line: >>>>Meta: this draft talks about the signaling component, what about >>>> the routing part of the story? >>> >>> >>>No different to any G-PID or encoding type. That is, end-point capabilities are not >>>currently advertised in GMPLS routing. Some people see this as a failing, others say that >>>since you are attempting to open an end-to-end connection, you are presumably trying to >>>contact a known (called) party and it would be usual to have either: >>>- some understanding of the capablities of the person you are trying to reach >>>or >>>- limited capablities, yourself. >>> >>>Anyway, this draft is simply extending the list of encodings and G-PIDs to cover G.709. >>>Endocings and G-PIDs are signaled quantites that are not advertised. > >>as for sdh/sonet a couple of technology specific extensions where >>initiated early 2000 and took a more stable form end of 2002, that would >>have taken one of the following form: add. sub-TLV or extension of the >>technology specific part of the ISC sub-TLV descriptor for intra-domain >>TE and that would have included specific end-point capabilities, >>however since so far they've never been considered as working group item >>(stayed at the individual submission level) > >>note: G-PIDs are not advertized but encodings are as part of the ISC sub-TLV > > To make sure we have the bottom line right: is the routing part a required > piece for the implementations of gmpls-g709 to interoperate? there is no additional TE routing information exchange strictly *required* from what has been already provided in GMPLS routing to interoperate (also one can make use of signaling part without any TE routing exchange as long as the corresponding information is made available by other means) >>>>>3.1.1 LSP Encoding Type >>>>> Therefore, the current "Digital Wrapper" code-point defined in >>>>> [RFC3471] can be replaced by two separate code-points: >>>> >>>>What does "replaced" mean here? >>> >>>Good question. Presume that we can't obsolete "Digital Wrapper" without some care. So we >>>need text to describe how it is handled. > >>here the issue is a timing problem, as G.709 was issued by the time RFC >>3471 went out, combined with a formulation problem, as we can safely >>assume that the digital wrappers that were already available by that >>time were not fully G.709 compliant -> so it would be better to speak >>about a rename of the existing RFC 3471 value and add-on of a new value > > The question here is whether the original "Digital Wrapper" code point > has been used or not, and how safe it is change the semantics vs defining > a new value for g.709. it has been already used for proprietary implementations of the wrapper layer, this is why a new value has been proposed to not jeopardize them >>>>>3.1.2 Switching Type >>>>> Moreover, in a strict layered G.709 network, when a downstream node >>>>> receives a Generalized Label Request including one of these values >>>>> for the Switching Type field, this value SHOULD be ignored. >>>> >>>>What about other values? Should the field be ignored all together? > >>the "field" SHOULD be ignored, if not (and in this case, thus simply >>used as an indication of the LSP class), the value of this field MUST be >>either of type TDM or LSC depending of the Signal Type value > > Well, you guys need to pick whether you're going to ask the implementor > to ignore the field, or to check it for a specific value. In the latter > case, you also need to specify what to do if the check fails. in trying to address the discussion point, i would suggest the following text for this section (in compliance with RFC 3473 - note: it is impossible for a given implementation to encompass all the different pieces of processing that have been devised over years for this field) so picking up the following is the most straightforward: "The Switching Type indicates the type of switching that should be performed at the termination of a particular link (see [GMPLS-RTG]). Here, no additional Switching Type values are to be considered in order to accommodate G.709 switching types since an ODUk switching (and so LSPs) belongs to the TDM class while an OCh switching (and so LSPs) to the Lambda class (i.e. LSC). Intermediate and egress nodes MUST verify that the value indicated in the Switching Type field is supported on the corresponding incoming interface. If the requested value can not be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication." >>>>> In case of ODUk in OTUk mapping, only one of label can appear in the >>>>> Generalized Label. > >>add "The unique is encoded as single 32 bit label value (as defined in >>Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2)" > >>>>> In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered >>>>> list of the labels in the multiplex is given (this list can be >>>>> restricted to only one label when NMC = 1). Each label indicates a >>>>> component (ODUj tributary slot) of the multiplexed signal. The order >>>>> of the labels must reflect the order of the ODUj into the multiplex >>>>> (not the physical order of tributary slots). > >>add "This ordered list of labels is encoded a sequence of 32 bit label >>values (as defined in Section 4.1) of the GENERALIZED_LABEL object >>(Class-Num = 16, C-Type = 2)" > >>>>> In case of ODUk virtual concatenation, the explicit ordered list of >>>>> all labels in the concatenation is given. Each label indicates a >>>>> component of the virtually concatenated signal. The order of the >>>>> labels must reflect the order of the ODUk to concatenate (not the >>>>> physical order of time-slots). This representation limits virtual >>>>> concatenation to remain within a single (component) link. In case of >>>>> multiplexed virtually concatenated signals, the first set of labels >>>>> indicates the components (ODUj tributary slots) of the first >>>>> virtually concatenated signal, the second set of labels indicates >>>>> the components (ODUj tributary slots) of the second virtually >>>>> concatenated signal, and so on. > >>ditto add "This ordered list of labels is encoded a sequence of 32 bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of ODUk virtual concatenation, the number of label values is determined by the NVC value. Multiplexed ODUk virtual concatenation additionally uses the NMC value to determine the number of labels per set (equal in size)." >>>>> In case of multiplication (i.e. when using the MT field), the >>>>> explicit ordered list of all labels taking part in the composed >>>>> signal is given. The above representation limits multiplication to >>>>> remain within a single (component) link. In case of multiplication >>>>> of multiplexed/virtually concatenated signals, the first set of >>>>> labels indicates the components of the first multiplexed/virtually >>>>> concatenated signal, the second set of labels indicates components >>>>> of the second multiplexed/virtually concatenated signal, and so on. > >>ditto > > Pardon if I sound ignorant... Are both sets (the first and the second) encoded > together in the same GEN_LABEL object? How does one tell "the first set of > labels" from "the second"? alex, sensible question does also apply to the previous case add "This ordered list of labels is encoded a sequence of 32 bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of multiplication of (equal) ODUk virtual concatenated signals, the number of label values per signal is determined by the NVC value. Multiplication of (equal) multiplexed ODUk virtual concatenation additionally uses the NMC value to determine the number of labels per set (equal in size)." >>>>What does the last para mean to IANA? Is this a request to create >>>>new registries? If so, more info needs to be given, e.g.: >>>> >>>>- name of the registry >>>>- format >>>>- allocation policy >>>>- initial values >>> >>> >>>Hmmm. Probably my fault since I asked for this. >>>Encodigng type and G-PID would, indeed, be two new registries. Primarily they are defined >>>in RFC3471, but this draft introduces some new values and the values should be tracked and >>>monitored. >>> >>>So, yes, this is a request for two new registries. The info provided to IANA should also >>>point at all existing definitions. > >>in this case, i would also then suggest to create an entry for the >>switching type values the document will include the required information >>for each of them > > As long as we provide proper instructions to IANA--I'm fine. ok - will do so in the updated version thanks, - dimitri. > Thanks. > > Alex From rtg-dir-bounces@ietf.org Wed Sep 1 12:54:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09602 for ; Wed, 1 Sep 2004 12:54:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2YPr-0004i9-D1 for rtg-dir-archive@ietf.org; Wed, 01 Sep 2004 12:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XP2-00085U-8Q; Wed, 01 Sep 2004 11:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VST-0001jc-7o for rtg-dir@megatron.ietf.org; Wed, 01 Sep 2004 09:47:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07407; Wed, 1 Sep 2004 09:35:46 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2T1x-0005G8-QR; Wed, 01 Sep 2004 07:11:58 -0400 Received: from du-069-0086.access.clara.net ([217.158.132.86] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.34) id 1C2Sz9-000PJS-E1; Wed, 01 Sep 2004 12:09:03 +0100 Message-ID: <029101c49014$1a024ac0$b6849ed9@Puppy> From: "Adrian Farrel" To: "Loa Andersson" , "Alex Zinin" References: <20040831154254.D98991@kummer.juniper.net> <200408312305.i7VN5SZ28048@windsor.research.att.com> <1018839778.20040831162010@psg.com> <41356E6D.5030003@pi.se> Date: Wed, 1 Sep 2004 11:53:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Bill Fenner , kireeti@juniper.net, rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Re: O&M section in RTG documents? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Tush! I thought the idea for a draft came from Kireeti! Loa and I will examine our process list and current CPU drain and see what we can achieve. A ----- Original Message ----- From: "Loa Andersson" To: "Alex Zinin" Cc: "Bill Fenner" ; ; ; Sent: Wednesday, September 01, 2004 7:38 AM Subject: Re: O&M section in RTG documents? > All, > > should have seen coming and ran for cover int time :). > Will discuss with Adrian. > > /Loa > > Alex Zinin wrote: > > > Makes sense. > > > > So, in the spirit of IETF :), how about Loa and Adrian come up with an > > individual draft, containing the guidelines for the O&M section. This > > should give some meat for the discussion. > > > > From rtg-dir-bounces@ietf.org Wed Sep 1 13:17:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12238 for ; Wed, 1 Sep 2004 13:17:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2YmH-0006Ob-O0 for rtg-dir-archive@ietf.org; Wed, 01 Sep 2004 13:20:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Xa4-00033M-Ae; Wed, 01 Sep 2004 12:03:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2WmL-0003H8-0Z for rtg-dir@megatron.ietf.org; Wed, 01 Sep 2004 11:12:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25256; Wed, 1 Sep 2004 11:11:57 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2WoT-000533-Kq; Wed, 01 Sep 2004 11:14:18 -0400 Received: from du-069-0033.access.clara.net ([217.158.132.33] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.34) id 1C2WmB-000By1-Da; Wed, 01 Sep 2004 16:11:56 +0100 Message-ID: <032001c49036$0a33d7e0$b6849ed9@Puppy> From: "Adrian Farrel" To: "Jeffrey Haas" , "Bill Fenner" References: <20040831154254.D98991@kummer.juniper.net> <200408312305.i7VN5SZ28048@windsor.research.att.com> <20040901130656.GA591@nexthop.com> Date: Wed, 1 Sep 2004 15:27:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: kireeti@juniper.net, rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: O&M section in RTG documents? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Jeffrey, > On Tue, Aug 31, 2004 at 04:05:27PM -0700, Bill Fenner wrote: > > I think I agree here. There's been a lot of confusion about what's > > needed in security considerations, and even with RFC3552 it sometimes > > seems to come down to "Write what you think it should say, then have > > it on an IESG telechat to find out what the security ADs think it should > > say". > > Having such a thing is, I think, a nice idea. Just to make sure I'm > understanding the proposal, you're suggesting O&M not strictly as > "when you do your MIB, this is what should go in there" but also > a section on expected operational considerations in a live network? Absolutely. Concerns include what you need to do to manage your proposals. For modifications.extensions to existing work, this would clearly discuss the impact on existing schemes. While MIBs are an important aspect, I think the thing that has driven the comments from both Loa and me is the fact that MPLS OAM (e.g. LSP liveness and correctness testing) has been retro-fitted to the protocol architecture. Should have been thought about up front. > Regarding the MIB portion, many protocol elements that should go into > MIBs are reasonably obvious although I understand that configurability > is still somewhat controversial. > > What would be nice for MIB authors is a document that has recommendations > on how to go about representing various elements of protocol data > structurally in the MIB. As a specific example, much of the lack of > progress on the BGP MIBv2 has been because I seem to continually stump > the IDR MIB doctors (two of them now) in trying to represent elements > in the BGP "routing table" (specifically the RIBs). Agree with you, but I don't think this proposed draft is the same one as you are proposing. > Also, a MIB author's FAQ on writing MIBs would be handy. I've also > hit cases where I represent something that is "structurally sound" > in SMIv2 but it is suggested that I change things because "it looks weird". > > Another item of concern that crosses both the operational and the SNMP > concerns for an O&M section is when one should put elements in a MIB > that aren't specifically related to the protocol. I had received > a request from Tom Nadeau to take a last look at the l3vpn MIB since > there were interaction considerations with BGP. While the l3vpn > MIB contained most of the protocol elements that I would want to > represent, it also contained "high water marks" and a pointer to > policy elements that weren't specifically part of the protocol. > > Certainly these things are useful, but I'm not certain that they > belong as part of the MIB. Thus, if we're going to write such a thing, > we should also suggest things that do NOT belong. There are essential, desirable, nice, useful and bad. Something external to the actual protocol elements, but which is fundamental to the coherent operation of a network of protocol elements may be considered not bad. > > I like the concept, especially if it improves followthrough on > > addressing any problems that might be identified, but I am wary > > of accomplishing anything just by adding a required section - the > > work to fill it in won't just materialize and in some instances > > we're having enough trouble just getting the protocol portion > > done... > > I would tend to agree. I still consider myself an amateur at writing > MIBs, but given some of my conversations with other people it sounds > like I almost should list MIBs as a "skill" in my rtg-dir profile. > This doesn't mean I'm qualified to say what's good or bad O&M practice > from a MIB doctor's point of view, but I can at least review them > from the level of protocol practice->MIB. Oh good! Can you take a look at the GMPLS MIBs? No-one else seems to want to ;-) Adrian From rtg-dir-bounces@ietf.org Wed Sep 1 13:24:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12945 for ; Wed, 1 Sep 2004 13:24:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Ysp-00078s-Ce for rtg-dir-archive@ietf.org; Wed, 01 Sep 2004 13:26:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Xo6-0001M2-80; Wed, 01 Sep 2004 12:17:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XGZ-0001ac-Q8 for rtg-dir@megatron.ietf.org; Wed, 01 Sep 2004 11:43:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29455; Wed, 1 Sep 2004 11:40:27 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2XG3-0006oy-0e; Wed, 01 Sep 2004 11:42:48 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5A28A2D4857; Wed, 1 Sep 2004 11:39: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 13927-01-94; Wed, 1 Sep 2004 11:39:57 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 340962D4842; Wed, 1 Sep 2004 11:39:57 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i81Fdo804198; Wed, 1 Sep 2004 11:39:50 -0400 (EDT) Date: Wed, 1 Sep 2004 11:39:50 -0400 From: Jeffrey Haas To: Adrian Farrel Message-ID: <20040901153950.GG591@nexthop.com> References: <20040831154254.D98991@kummer.juniper.net> <200408312305.i7VN5SZ28048@windsor.research.att.com> <20040901130656.GA591@nexthop.com> <032001c49036$0a33d7e0$b6849ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <032001c49036$0a33d7e0$b6849ed9@Puppy> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: O&M section in RTG documents? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 On Wed, Sep 01, 2004 at 03:27:26PM +0100, Adrian Farrel wrote: > Agree with you, but I don't think this proposed draft is the same one as you are > proposing. Excellent. Does anyone have a suggestion as to the appropriate forum to take up the MIB specific issues? As for the OAM considerations, I think one of our biggest challenges will be demarcing where operational elements goes from "bits on the wire" to specific implementations. The MPLS OAM (lsp-ping, etc.) are good elements of OAM on the wire. But... > > Certainly these things are useful, but I'm not certain that they > > belong as part of the MIB. Thus, if we're going to write such a thing, > > we should also suggest things that do NOT belong. > > There are essential, desirable, nice, useful and bad. Something external to the actual > protocol elements, but which is fundamental to the coherent operation of a network of > protocol elements may be considered not bad. "not bad" may include things that aren't "on the wire". To refer back to my original example, the high water marks within the l3vpn MIB are *very* useful, however they inherently suggest to an implementor that these are protocol elements. Should an implementation have these things? If yes, then make sure they're in the base specification or at least an OAM considerations document for that protocol. So, I think we're saying the same thing: Make sure that when things have operational significance that they are included in the appropriate place. This may mean MIB objects or this may mean an OAM consideration. I somewhat wonder if the applicability document may be the appropriate place for this. > > I would tend to agree. I still consider myself an amateur at writing > > MIBs, but given some of my conversations with other people it sounds > > like I almost should list MIBs as a "skill" in my rtg-dir profile. > > This doesn't mean I'm qualified to say what's good or bad O&M practice > > from a MIB doctor's point of view, but I can at least review them > > from the level of protocol practice->MIB. > > Oh good! > Can you take a look at the GMPLS MIBs? No-one else seems to want to ;-) Um. I really stuck my foot in that. :-) Feel free to continue this part of the conversation off-line. > Adrian -- Jeff Haas NextHop Technologies From rtg-dir-bounces@ietf.org Wed Sep 1 13:52:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15313 for ; Wed, 1 Sep 2004 13:52:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2ZKE-00012f-D3 for rtg-dir-archive@ietf.org; Wed, 01 Sep 2004 13:55:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2YWQ-0004BX-55; Wed, 01 Sep 2004 13:03:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XWm-0005FK-FE for rtg-dir@megatron.ietf.org; Wed, 01 Sep 2004 12:00:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03003 for ; Wed, 1 Sep 2004 12:00:01 -0400 (EDT) Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2XYy-00084C-Mf for rtg-dir@ietf.org; Wed, 01 Sep 2004 12:02:22 -0400 Received: from [205.168.100.50] (dhcp1.tcb.net [205.168.100.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id C603464379; Wed, 1 Sep 2004 10:00:05 -0600 (MDT) In-Reply-To: <110262735.20040831155558@psg.com> References: <1810410594.20040827135847@psg.com> <4131A654.8090004@psg.com> <7B8A620B-FAC1-11D8-B68A-000393D54EA6@arbor.net> <110262735.20040831155558@psg.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Wed, 1 Sep 2004 09:59:30 -0600 To: Alex Zinin X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: RTG-Dir reviews X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit On Aug 31, 2004, at 4:55 PM, Alex Zinin wrote: > > How about the default review time of one week (if this is what you > mean)? Yep, that's what I meant. One week does seem a tad bit tight. How about two weeks? :-) -danny From rtg-dir-bounces@ietf.org Wed Sep 1 14:36:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19774 for ; Wed, 1 Sep 2004 14:36:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2a09-0004un-83 for rtg-dir-archive@ietf.org; Wed, 01 Sep 2004 14:38:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Zmv-0000YD-JM; Wed, 01 Sep 2004 14:24:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ZK4-0008G6-Ix for rtg-dir@megatron.ietf.org; Wed, 01 Sep 2004 13:55:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15648 for ; Wed, 1 Sep 2004 13:55:00 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2ZMH-0001Ii-KK for rtg-dir@ietf.org; Wed, 01 Sep 2004 13:57:22 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id DAF142D486D; Wed, 1 Sep 2004 13:54: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 25330-02-38; Wed, 1 Sep 2004 13:54:31 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A038D2D4866; Wed, 1 Sep 2004 13:54:31 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i81HsOC05835; Wed, 1 Sep 2004 13:54:24 -0400 (EDT) Date: Wed, 1 Sep 2004 13:54:24 -0400 From: Jeffrey Haas To: Danny McPherson Message-ID: <20040901175424.GJ591@nexthop.com> References: <1810410594.20040827135847@psg.com> <4131A654.8090004@psg.com> <7B8A620B-FAC1-11D8-B68A-000393D54EA6@arbor.net> <110262735.20040831155558@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Alex Zinin , rtg-dir@ietf.org Subject: Re: RTG-Dir reviews X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On Wed, Sep 01, 2004 at 09:59:30AM -0600, Danny McPherson wrote: > Yep, that's what I meant. One week does seem a > tad bit tight. How about two weeks? :-) I would tend to agree. > -danny -- Jeff Haas NextHop Technologies From rtg-dir-bounces@ietf.org Wed Sep 1 15:05:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21963 for ; Wed, 1 Sep 2004 15:05:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2aSY-0007C3-5w for rtg-dir-archive@ietf.org; Wed, 01 Sep 2004 15:07:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2aOY-0001ec-Ro; Wed, 01 Sep 2004 15:03:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Zyy-0006na-Rk for rtg-dir@megatron.ietf.org; Wed, 01 Sep 2004 14:37:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19847 for ; Wed, 1 Sep 2004 14:37:16 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2a1C-0004vL-M6 for rtg-dir@ietf.org; Wed, 01 Sep 2004 14:39:39 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id AB3302D4842 for ; Wed, 1 Sep 2004 14:36: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 28050-02-53 for ; Wed, 1 Sep 2004 14:36: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 6FFAF2D48B5 for ; Wed, 1 Sep 2004 14:36:48 -0400 (EDT) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Sep 2004 14:36:48 -0400 Message-ID: Thread-Topic: RTG-Dir reviews Thread-Index: AcSQUpO+iVrlHrAXTP6M8f5GGoQv4AAAAjHQ From: "Susan Hares" To: "Jeffrey Haas" , "Danny McPherson" X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: Alex Zinin , rtg-dir@ietf.org Subject: RE: RTG-Dir reviews X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable 1 week is a bit tight. sue -----Original Message----- From: Jeffrey Haas=20 Sent: Wednesday, September 01, 2004 1:54 PM To: Danny McPherson Cc: Alex Zinin; rtg-dir@ietf.org Subject: Re: RTG-Dir reviews On Wed, Sep 01, 2004 at 09:59:30AM -0600, Danny McPherson wrote: > Yep, that's what I meant. One week does seem a > tad bit tight. How about two weeks? :-) I would tend to agree. > -danny --=20 Jeff Haas=20 NextHop Technologies From rtg-dir-bounces@ietf.org Wed Sep 1 20:11:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18725 for ; Wed, 1 Sep 2004 20:11:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2fEU-0007xK-3u for rtg-dir-archive@ietf.org; Wed, 01 Sep 2004 20:13:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2enZ-0003Uw-Qn; Wed, 01 Sep 2004 19:45:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ecP-0004DO-Ir for rtg-dir@megatron.ietf.org; Wed, 01 Sep 2004 19:34:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16866 for ; Wed, 1 Sep 2004 19:34:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2eeg-0005E4-8N for rtg-dir@ietf.org; Wed, 01 Sep 2004 19:36:43 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2ecB-0005w4-Mb; Wed, 01 Sep 2004 23:34:08 +0000 Message-ID: <41365C95.6090609@psg.com> Date: Thu, 02 Sep 2004 01:34:45 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Susan Hares References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, Jeffrey Haas , Danny McPherson Subject: Re: RTG-Dir reviews X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit i would suggest within a default period of 7 working days (with exceptions to 10 working days) - dimitri. Susan Hares wrote: > 1 week is a bit tight. > > sue > > -----Original Message----- > From: Jeffrey Haas > Sent: Wednesday, September 01, 2004 1:54 PM > To: Danny McPherson > Cc: Alex Zinin; rtg-dir@ietf.org > Subject: Re: RTG-Dir reviews > > > On Wed, Sep 01, 2004 at 09:59:30AM -0600, Danny McPherson wrote: > >>Yep, that's what I meant. One week does seem a >>tad bit tight. How about two weeks? :-) > > > I would tend to agree. > > >>-danny > > From rtg-dir-bounces@ietf.org Fri Sep 3 19:32:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24163 for ; Fri, 3 Sep 2004 19:32:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3Na2-0003lY-6h for rtg-dir-archive@ietf.org; Fri, 03 Sep 2004 19:34:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3NTJ-00068y-84; Fri, 03 Sep 2004 19:27:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3NOe-0004n5-M3 for rtg-dir@megatron.ietf.org; Fri, 03 Sep 2004 19:23:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23692 for ; Fri, 3 Sep 2004 19:23:05 -0400 (EDT) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3NRM-0003aa-07 for rtg-dir@ietf.org; Fri, 03 Sep 2004 19:25:56 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 4FD8C3DCC8C; Fri, 3 Sep 2004 16:22:31 -0700 (PDT) In-Reply-To: <20040901175424.GJ591@nexthop.com> References: <1810410594.20040827135847@psg.com> <4131A654.8090004@psg.com> <7B8A620B-FAC1-11D8-B68A-000393D54EA6@arbor.net> <110262735.20040831155558@psg.com> <20040901175424.GJ591@nexthop.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <209927C2-FE00-11D8-91C8-00039303E9E2@rawdofmt.org> Content-Transfer-Encoding: 7bit From: Christian Hopps Date: Fri, 3 Sep 2004 16:22:30 -0700 To: Jeffrey Haas X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, Danny McPherson Subject: Re: RTG-Dir reviews X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit On Sep 1, 2004, at 10:54 AM, Jeffrey Haas wrote: > On Wed, Sep 01, 2004 at 09:59:30AM -0600, Danny McPherson wrote: >> Yep, that's what I meant. One week does seem a >> tad bit tight. How about two weeks? :-) > > I would tend to agree. As would I. Chris. > >> -danny > > -- > Jeff Haas > NextHop Technologies From rtg-dir-bounces@ietf.org Fri Sep 3 21:16:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28626 for ; Fri, 3 Sep 2004 21:16:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3PCg-0005OC-H3 for rtg-dir-archive@ietf.org; Fri, 03 Sep 2004 21:18:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3P9X-0007hB-8m; Fri, 03 Sep 2004 21:15:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3P5X-0006rR-I4 for rtg-dir@megatron.ietf.org; Fri, 03 Sep 2004 21:11:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28298 for ; Fri, 3 Sep 2004 21:11:29 -0400 (EDT) Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3P8E-0005HE-NG for rtg-dir@ietf.org; Fri, 03 Sep 2004 21:14:20 -0400 Received: from [205.168.100.50] (dhcp1.tcb.net [205.168.100.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 47FAD6450F; Fri, 3 Sep 2004 19:11:28 -0600 (MDT) In-Reply-To: <1538021461.20040827151807@psg.com> References: <1538021461.20040827151807@psg.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44126D82-FE0F-11D8-ACF0-000393D54EA6@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Fri, 3 Sep 2004 19:10:52 -0600 To: Alex Zinin X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: review assignment: draft-ietf-mpls-explicit-null-01.txt: danny, mjh X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit On Aug 27, 2004, at 4:18 PM, Alex Zinin wrote: > > skill-specific: danny > round-robin: mark > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-explicit-null > -01.txt I just (re)read this document and it looks fine to me. I believe the general utility makes sense and it does remove over-restrictive text that was specified in RFC 3032. I also don't recall much concern on the mailing list about this, and a terse review of the discussions of this document suggests all outstanding comments have been addressed by Eric. The one comment that I have is that existing implementations may interpret an Explicit NULL at a position other than the bottom of the stack as illegal and invoke some error handling or discard process. The draft states that some implementations simply transmit the illegal packet today and others "covert it to a legal packet" (by stripping the Explicit NULL, thereby introducing the requirement for this document). As such, it may be of value to mention deployment considerations explicitly somewhere in the document. -danny From rtg-dir-bounces@ietf.org Wed Sep 8 06:06:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26750 for ; Wed, 8 Sep 2004 06:06:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4zOd-0005B9-R7 for rtg-dir-archive@ietf.org; Wed, 08 Sep 2004 06:09:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4zIB-00010J-68; Wed, 08 Sep 2004 06:03:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4zHM-0000rO-OW for rtg-dir@megatron.ietf.org; Wed, 08 Sep 2004 06:02:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26470 for ; Wed, 8 Sep 2004 06:02:14 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4zKw-00056e-I9 for rtg-dir@ietf.org; Wed, 08 Sep 2004 06:06:01 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 08 Sep 2004 12:07:49 +0200 X-BrightmailFiltered: true Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i88A1a2P001244 for ; Wed, 8 Sep 2004 12:01:37 +0200 (MEST) Received: from mshand-w2k02.cisco.com (dhcp-rea-gp250-64-103-65-143.cisco.com [64.103.65.143]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA03754 for ; Wed, 8 Sep 2004 11:01:36 +0100 (BST) Message-Id: <4.3.2.7.2.20040908110108.02a43a58@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Sep 2004 11:01:37 +0100 To: rtg-dir@ietf.org From: mike shand Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: draft-ietf-mpls-rsvpte-attributes-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb I'm conducting a "routing directorate" review of the above draft and I have a couple of questions regarding the format of the TLVs. 1) In section 3, under length, it says that the padding to take the value field up to a 4 byte boundary is NOT included in the length. However in section 3.1 para 3 it says that the length field is always a multiple of 4 bytes regardless of the number of bits set. I'm having difficulty reconciling those two statements. 2) The TLV defined above in section 3 is of the normal design in that the length is the length of the value field only and does not include the type and length fields. However, the TLV defined 7.2 has a different form where the length includes the type and length fields. Is there some rationale why the same protocol uses both types of encoding? And one final question. In section 9 it says in paras 5 and 7 that LSRs SHOULD be prepared to receive this object in any order.... should that be a MUST, or is SHOULD acceptable? It would appear to be non-optional. A couple of typos I spotted. section 6 Inheritance rules. End of first para. "belongs to the same switching capability class THAN the triggering LSP". section 7.3.1 Subobject presence rules, last para nearest to the STOP of the stack) Thanks. Mike From rtg-dir-bounces@ietf.org Wed Sep 8 10:05:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13099 for ; Wed, 8 Sep 2004 10:05:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C538f-0001Dr-Vw for rtg-dir-archive@ietf.org; Wed, 08 Sep 2004 10:09:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C532Y-0008H3-6w; Wed, 08 Sep 2004 10:03:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5316-0006nX-RE for rtg-dir@megatron.ietf.org; Wed, 08 Sep 2004 10:01:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12689 for ; Wed, 8 Sep 2004 10:01:42 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C534j-00018k-FQ for rtg-dir@ietf.org; Wed, 08 Sep 2004 10:05:32 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 08 Sep 2004 16:07:22 +0200 X-BrightmailFiltered: true Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i88E172P011644 for ; Wed, 8 Sep 2004 16:01:08 +0200 (MEST) Received: from mshand-w2k02.cisco.com (dhcp-rea-gp250-64-103-65-143.cisco.com [64.103.65.143]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA10922 for ; Wed, 8 Sep 2004 15:01:07 +0100 (BST) Message-Id: <4.3.2.7.2.20040908150039.02a959b0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Sep 2004 15:01:07 +0100 To: rtg-dir@ietf.org From: mike shand Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: Fwd: Re: draft-ietf-mpls-rsvpte-attributes-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a >X-BrightmailFiltered: true >Reply-To: "Adrian Farrel" >From: "Adrian Farrel" >To: "mike shand" >Cc: , , , > >Subject: Re: draft-ietf-mpls-rsvpte-attributes-04.txt >Date: Wed, 8 Sep 2004 14:40:48 +0100 >X-Mailer: Microsoft Outlook Express 6.00.2800.1158 >X-PMX-Version: 4.7.0.111621 >X-from-outside-Cisco: 128.107.250.142 > >Hi Mike, > >Thanks for the review. > > > I'm conducting a "routing directorate" review of the above draft and I > > have a couple of questions regarding the format of the TLVs. > > > > 1) In section 3, under length, it says that the padding to take the value > > field up to a 4 byte boundary is NOT included in the length. > > However in section 3.1 para 3 it says that the length field is always a > > multiple of 4 bytes regardless of the number of bits set. > > > > I'm having difficulty reconciling those two statements. > >You are not the first to ask this question and I wonder what to do to stop >it being asked >again. > >The value field in section 3.1 para 3 is always a multiple of four bytes. >It is NEVER >padded. (It never needs to be padded.) >Bits are either defined or undefined, but never pads. >Thus the length field is always a multiple of 4 and always reflects >exactly the length of >the value field. > >Other TLVs may have value fields that are not a multiple of four bytes. In >these cases (as >described in section 3): >- the length field reflects exactly the length of the value field >- padding is added to round the value field up to a four byte boundary. > >We would certainly welcome your input on how to make this more clear. > > > 2) The TLV defined above in section 3 is of the normal design in that the > > length is the length of the value field only and does not include the type > > and length fields. However, the TLV defined 7.2 has a different form where > > the length includes the type and length fields. > > > > Is there some rationale why the same protocol uses both types of encoding? > >As you say, the TLV definition in section 3 is "normal". Thus it is the >prefered way to >define TLVs for the new object. > >The "TLV" in section 7.2 is not actually a TLV but is a sub-object >according to the >definitions and format in RFC3209. We have no scope to play with this >definition (not >withstanding the fact that it is abnormal). > > > And one final question. In section 9 it says in paras 5 and 7 that LSRs > > SHOULD be prepared to receive this object in any order.... > > > > should that be a MUST, or is SHOULD acceptable? It would appear to be > > non-optional. > >Good catch. > > > A couple of typos I spotted. > > > > section 6 Inheritance rules. End of first para. > > > > "belongs to the same switching capability class THAN the triggering LSP". > >yup > > > section 7.3.1 Subobject presence rules, last para > > > > nearest to the STOP of the stack) > >yup > >Thanks, Mike. > >I'll hold the last three changes ready for the next rev. >Any advice about clarifying the first two points would be welcomed. > >Cheers, >Adrian From rtg-dir-bounces@ietf.org Wed Sep 8 17:33:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23539 for ; Wed, 8 Sep 2004 17:33:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5A7h-0003eU-TQ for rtg-dir-archive@ietf.org; Wed, 08 Sep 2004 17:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C59jy-0008Kc-F3; Wed, 08 Sep 2004 17:12:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C59Ma-0001DV-7v for rtg-dir@megatron.ietf.org; Wed, 08 Sep 2004 16:48:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19517 for ; Wed, 8 Sep 2004 16:48:17 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C59QH-0002N9-Tx for rtg-dir@ietf.org; Wed, 08 Sep 2004 16:52: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 i88KllBm029298; Wed, 8 Sep 2004 13:47:47 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.28.5.11]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i88Klke74998; Wed, 8 Sep 2004 13:47:46 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20040908153928.0341d4c0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 08 Sep 2004 16:36:08 -0400 To: Alex Zinin From: Ross Callon In-Reply-To: <93463290.20040827152248@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: rtg-dir@ietf.org Subject: Re: review assignment: draft-ietf-mpls-rsvpte-attributes-04.txt: rcallon; mshand X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a At 03:22 PM 8/27/2004 -0700, Alex Zinin wrote: >skill-specific: Ross (Dimitri skipped as co-author, Loa as co-chair) Looking this over, I think that it is pretty good. Its purpose is to correct a deficiency in RSVP signalling formats which is, in my opinion, a rather unfortunate deficiency. Specifically, the flags field in the SESSION_ATTRIBUTE object is simply not large enough (8 bits). This is therefore solving a fairly basic issue in the RSVP packet formats. The problem is solved with a reasonable consideration for compatibility with older (not-yet-updated) systems. The approach here allows general TLV-based items to be added to the packet format, which seems like a good general way to solve the problem (for example, if they instead just made the field twice as large, we might run into the same problem all over again in a few years). Defines both end-to-end (intermediate hops may ignore) and hop-by-hop (all hops should interpret and process) types of RSVP objects (again, a useful distinction). Is useful in applications such as inter-domain MPLS TE signaling. Ross >round-robin: Mike > >http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvpte-attributes-04.txt > > > Encoding of Attributes for Multiprotocol Label Switching (MPLS) > > Label Switched Path (LSP) Establishment Using RSVP-TE > > > Abstract > > > > Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may > > be established using the Resource Reservation Protocol Traffic > > Engineering extensions (RSVP-TE). This protocol includes an object > > (the SESSION_ATTRIBUTE object) which carries a flags field used to > > indicate options and attributes of the LSP. That flags field has > > eight bits allowing for eight options to be set. Recent proposals in > > many documents that extend RSVP-TE have suggested uses for each of > > the previously unused bits. > > > > This document defines a new object for RSVP-TE messages that allows > > the signaling of further attribute bits and also the carriage of > > arbitrary attribute parameters to make RSVP-TE easily extensible to > > support new requirements. Additionally, this document defines a way > > to record the attributes applied to the LSP on a hop-by-hop basis. > > > > The object mechanisms defined in this document are equally applicable > > to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to > > GMPLS non-PSC LSPs. > >-- >Alex >http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Sun Sep 12 08:26:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12139 for ; Sun, 12 Sep 2004 08:26:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6TVG-00008i-Lb for rtg-dir-archive@ietf.org; Sun, 12 Sep 2004 08:30:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6TNz-0002ct-Jg; Sun, 12 Sep 2004 08:23:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6TKh-00022X-2L for rtg-dir@megatron.ietf.org; Sun, 12 Sep 2004 08:19:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11822 for ; Sun, 12 Sep 2004 08:19:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6TPA-0008UD-PW for rtg-dir@ietf.org; Sun, 12 Sep 2004 08:24:29 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C6TKT-000C8c-IF; Sun, 12 Sep 2004 12:19:38 +0000 Message-ID: <41443ED1.9010007@psg.com> Date: Sun, 12 Sep 2004 14:19:29 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <1555437345.20040827125059@psg.com> <24a101c48cf1$6fa185c0$11849ed9@Puppy> <4130B1B7.1010306@psg.com> <1317443531.20040831161433@psg.com> In-Reply-To: <1317443531.20040831161433@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Adrian Farrel , Bill Fenner , "Dimitri.Papadimitriou" , rtg-dir@ietf.org Subject: Re: AD-review comments on draft-ietf-ccamp-gmpls-g709 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: 7bit hi alex, adrian, would it be possible to know whether the below responses address the review comments so that i can issue a new version of this document (and move forward) ? thanks, - dimitri. ----- hi alex, adrian - see in-line: >>>>Meta: this draft talks about the signaling component, what about >>>> the routing part of the story? >>> >>> >>>No different to any G-PID or encoding type. That is, end-point capabilities are not >>>currently advertised in GMPLS routing. Some people see this as a failing, others say that >>>since you are attempting to open an end-to-end connection, you are presumably trying to >>>contact a known (called) party and it would be usual to have either: >>>- some understanding of the capablities of the person you are trying to reach >>>or >>>- limited capablities, yourself. >>> >>>Anyway, this draft is simply extending the list of encodings and G-PIDs to cover G.709. >>>Endocings and G-PIDs are signaled quantites that are not advertised. > >>as for sdh/sonet a couple of technology specific extensions where >>initiated early 2000 and took a more stable form end of 2002, that would >>have taken one of the following form: add. sub-TLV or extension of the >>technology specific part of the ISC sub-TLV descriptor for intra-domain >>TE and that would have included specific end-point capabilities, >>however since so far they've never been considered as working group item >>(stayed at the individual submission level) > >>note: G-PIDs are not advertized but encodings are as part of the ISC sub-TLV > > To make sure we have the bottom line right: is the routing part a required > piece for the implementations of gmpls-g709 to interoperate? there is no additional TE routing information exchange strictly *required* from what has been already provided in GMPLS routing to interoperate (also one can make use of signaling part without any TE routing exchange as long as the corresponding information is made available by other means) >>>>>3.1.1 LSP Encoding Type >>>>> Therefore, the current "Digital Wrapper" code-point defined in >>>>> [RFC3471] can be replaced by two separate code-points: >>>> >>>>What does "replaced" mean here? >>> >>>Good question. Presume that we can't obsolete "Digital Wrapper" without some care. So we >>>need text to describe how it is handled. > >>here the issue is a timing problem, as G.709 was issued by the time RFC >>3471 went out, combined with a formulation problem, as we can safely >>assume that the digital wrappers that were already available by that >>time were not fully G.709 compliant -> so it would be better to speak >>about a rename of the existing RFC 3471 value and add-on of a new value > > The question here is whether the original "Digital Wrapper" code point > has been used or not, and how safe it is change the semantics vs defining > a new value for g.709. it has been already used for proprietary implementations of the wrapper layer, this is why a new value has been proposed to not jeopardize them >>>>>3.1.2 Switching Type >>>>> Moreover, in a strict layered G.709 network, when a downstream node >>>>> receives a Generalized Label Request including one of these values >>>>> for the Switching Type field, this value SHOULD be ignored. >>>> >>>>What about other values? Should the field be ignored all together? > >>the "field" SHOULD be ignored, if not (and in this case, thus simply >>used as an indication of the LSP class), the value of this field MUST be >>either of type TDM or LSC depending of the Signal Type value > > Well, you guys need to pick whether you're going to ask the implementor > to ignore the field, or to check it for a specific value. In the latter > case, you also need to specify what to do if the check fails. in trying to address the discussion point, i would suggest the following text for this section (in compliance with RFC 3473 - note: it is impossible for a given implementation to encompass all the different pieces of processing that have been devised over years for this field) so picking up the following is the most straightforward: "The Switching Type indicates the type of switching that should be performed at the termination of a particular link (see [GMPLS-RTG]). Here, no additional Switching Type values are to be considered in order to accommodate G.709 switching types since an ODUk switching (and so LSPs) belongs to the TDM class while an OCh switching (and so LSPs) to the Lambda class (i.e. LSC). Intermediate and egress nodes MUST verify that the value indicated in the Switching Type field is supported on the corresponding incoming interface. If the requested value can not be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication." >>>>> In case of ODUk in OTUk mapping, only one of label can appear in the >>>>> Generalized Label. > >>add "The unique is encoded as single 32 bit label value (as defined in >>Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2)" > >>>>> In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered >>>>> list of the labels in the multiplex is given (this list can be >>>>> restricted to only one label when NMC = 1). Each label indicates a >>>>> component (ODUj tributary slot) of the multiplexed signal. The order >>>>> of the labels must reflect the order of the ODUj into the multiplex >>>>> (not the physical order of tributary slots). > >>add "This ordered list of labels is encoded a sequence of 32 bit label >>values (as defined in Section 4.1) of the GENERALIZED_LABEL object >>(Class-Num = 16, C-Type = 2)" > >>>>> In case of ODUk virtual concatenation, the explicit ordered list of >>>>> all labels in the concatenation is given. Each label indicates a >>>>> component of the virtually concatenated signal. The order of the >>>>> labels must reflect the order of the ODUk to concatenate (not the >>>>> physical order of time-slots). This representation limits virtual >>>>> concatenation to remain within a single (component) link. In case of >>>>> multiplexed virtually concatenated signals, the first set of labels >>>>> indicates the components (ODUj tributary slots) of the first >>>>> virtually concatenated signal, the second set of labels indicates >>>>> the components (ODUj tributary slots) of the second virtually >>>>> concatenated signal, and so on. > >>ditto add "This ordered list of labels is encoded a sequence of 32 bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of ODUk virtual concatenation, the number of label values is determined by the NVC value. Multiplexed ODUk virtual concatenation additionally uses the NMC value to determine the number of labels per set (equal in size)." >>>>> In case of multiplication (i.e. when using the MT field), the >>>>> explicit ordered list of all labels taking part in the composed >>>>> signal is given. The above representation limits multiplication to >>>>> remain within a single (component) link. In case of multiplication >>>>> of multiplexed/virtually concatenated signals, the first set of >>>>> labels indicates the components of the first multiplexed/virtually >>>>> concatenated signal, the second set of labels indicates components >>>>> of the second multiplexed/virtually concatenated signal, and so on. > >>ditto > > Pardon if I sound ignorant... Are both sets (the first and the second) encoded > together in the same GEN_LABEL object? How does one tell "the first set of > labels" from "the second"? alex, sensible question does also apply to the previous case add "This ordered list of labels is encoded a sequence of 32 bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of multiplication of (equal) ODUk virtual concatenated signals, the number of label values per signal is determined by the NVC value. Multiplication of (equal) multiplexed ODUk virtual concatenation additionally uses the NMC value to determine the number of labels per set (equal in size)." >>>>What does the last para mean to IANA? Is this a request to create >>>>new registries? If so, more info needs to be given, e.g.: >>>> >>>>- name of the registry >>>>- format >>>>- allocation policy >>>>- initial values >>> >>> >>>Hmmm. Probably my fault since I asked for this. >>>Encodigng type and G-PID would, indeed, be two new registries. Primarily they are defined >>>in RFC3471, but this draft introduces some new values and the values should be tracked and >>>monitored. >>> >>>So, yes, this is a request for two new registries. The info provided to IANA should also >>>point at all existing definitions. > >>in this case, i would also then suggest to create an entry for the >>switching type values the document will include the required information >>for each of them > > As long as we provide proper instructions to IANA--I'm fine. ok - will do so in the updated version thanks, - dimitri. > Thanks. > > Alex From rtg-dir-bounces@ietf.org Sat Sep 18 09:45:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19580 for ; Sat, 18 Sep 2004 09:45:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8fbz-0000oR-AZ for rtg-dir-archive@ietf.org; Sat, 18 Sep 2004 09:51:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8fSW-0005PB-51; Sat, 18 Sep 2004 09:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8fKe-0004D0-Qi for rtg-dir@megatron.ietf.org; Sat, 18 Sep 2004 09:33:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18865 for ; Sat, 18 Sep 2004 09:32:40 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8fPg-0000aI-2q for rtg-dir@ietf.org; Sat, 18 Sep 2004 09:38:29 -0400 Received: from du-069-0432.access.clara.net ([217.158.145.178] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.34) id 1C8fIg-000Psh-BU; Sat, 18 Sep 2004 14:30:52 +0100 Message-ID: <010001c49d83$c0c4b510$42919ed9@Puppy> From: "Adrian Farrel" To: , , "Alex Zinin" References: <1555437345.20040827125059@psg.com> <24a101c48cf1$6fa185c0$11849ed9@Puppy> <4130B1B7.1010306@psg.com> <1317443531.20040831161433@psg.com> <41443ED1.9010007@psg.com> Date: Sat, 18 Sep 2004 13:47:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 1.2 (+) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Bill Fenner , "Dimitri.Papadimitriou" , rtg-dir@ietf.org Subject: Re: AD-review comments on draft-ietf-ccamp-gmpls-g709 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: 7bit Dimitri, > hi alex, adrian, would it be possible to know whether the below > responses address the review comments so that i can issue a new version > of this document (and move forward) ? Small comments in line. Thanks for pushing on with this. Please make your updates and re-publish. Cheers, Adrian > >>>>Meta: this draft talks about the signaling component, what about > >>>> the routing part of the story? > >>> > >>>No different to any G-PID or encoding type. That is, end-point capabilities are not > >>>currently advertised in GMPLS routing. Some people see this as a failing, others say that > >>>since you are attempting to open an end-to-end connection, you are presumably trying to > >>>contact a known (called) party and it would be usual to have either: > >>>- some understanding of the capablities of the person you are trying to reach > >>>or > >>>- limited capablities, yourself. > >>> > >>>Anyway, this draft is simply extending the list of encodings and G-PIDs to cover G.709. > >>>Endocings and G-PIDs are signaled quantites that are not advertised. > > > >>as for sdh/sonet a couple of technology specific extensions where > >>initiated early 2000 and took a more stable form end of 2002, that would > >>have taken one of the following form: add. sub-TLV or extension of the > >>technology specific part of the ISC sub-TLV descriptor for intra-domain > >>TE and that would have included specific end-point capabilities, > >>however since so far they've never been considered as working group item > >>(stayed at the individual submission level) > > > >>note: G-PIDs are not advertized but encodings are as part of the ISC sub-TLV > > > > To make sure we have the bottom line right: is the routing part a required > > piece for the implementations of gmpls-g709 to interoperate? > > there is no additional TE routing information exchange strictly > *required* from what has been already provided in GMPLS routing to > interoperate (also one can make use of signaling part without any TE > routing exchange as long as the corresponding information is made > available by other means) I think we can say something slightly stronger. GMPLS-G.709 implementations will successfully interoperate without further additions to GMPLS routing. The issue of end-point capabilities is related, but not a dependency. Further, the issue of end-point capablities extends across the whole of GMPLS, and is not limited to G.709. Thus, this draft brings G.709 up to the same level as many other GMPLS-related technologies. > >>>>>3.1.1 LSP Encoding Type > >>>>> Therefore, the current "Digital Wrapper" code-point defined in > >>>>> [RFC3471] can be replaced by two separate code-points: > >>>> > >>>>What does "replaced" mean here? > >>> > >>>Good question. Presume that we can't obsolete "Digital Wrapper" without some care. So we > >>>need text to describe how it is handled. > > > >>here the issue is a timing problem, as G.709 was issued by the time RFC > >>3471 went out, combined with a formulation problem, as we can safely > >>assume that the digital wrappers that were already available by that > >>time were not fully G.709 compliant -> so it would be better to speak > >>about a rename of the existing RFC 3471 value and add-on of a new value > > > > The question here is whether the original "Digital Wrapper" code point > > has been used or not, and how safe it is change the semantics vs defining > > a new value for g.709. > > it has been already used for proprietary implementations of the wrapper > layer, this is why a new value has been proposed to not jeopardize them Good. OK, please don't say "replace". Instead, please use text that describes the behavior with all three values. - Never generate old value. - What to do when receiving old value. > >>>>>3.1.2 Switching Type > >>>>> Moreover, in a strict layered G.709 network, when a downstream node > >>>>> receives a Generalized Label Request including one of these values > >>>>> for the Switching Type field, this value SHOULD be ignored. > >>>> > >>>>What about other values? Should the field be ignored all together? > > > >>the "field" SHOULD be ignored, if not (and in this case, thus simply > >>used as an indication of the LSP class), the value of this field MUST be > >>either of type TDM or LSC depending of the Signal Type value > > > > Well, you guys need to pick whether you're going to ask the implementor > > to ignore the field, or to check it for a specific value. In the latter > > case, you also need to specify what to do if the check fails. > > in trying to address the discussion point, i would suggest the following > text for this section (in compliance with RFC 3473 - note: it is > impossible for a given implementation to encompass all the different > pieces of processing that have been devised over years for this field) > so picking up the following is the most straightforward: > > "The Switching Type indicates the type of switching that should be > performed at the termination of a particular link (see [GMPLS-RTG]). > > Here, no additional Switching Type values are to be considered in order > to accommodate G.709 switching types since an ODUk switching (and so > LSPs) belongs to the TDM class while an OCh switching (and so LSPs) > to the Lambda class (i.e. LSC). > > Intermediate and egress nodes MUST verify that the value indicated in > the Switching Type field is supported on the corresponding incoming > interface. If the requested value can not be supported, the node MUST > generate a PathErr message with a "Routing problem/Switching Type" > indication." That looks good. > >>>>> In case of ODUk in OTUk mapping, only one of label can appear in the > >>>>> Generalized Label. > > > >>add "The unique is encoded as single 32 bit label value (as defined in > >>Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2)" > > > >>>>> In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered > >>>>> list of the labels in the multiplex is given (this list can be > >>>>> restricted to only one label when NMC = 1). Each label indicates a > >>>>> component (ODUj tributary slot) of the multiplexed signal. The order > >>>>> of the labels must reflect the order of the ODUj into the multiplex > >>>>> (not the physical order of tributary slots). > > > >>add "This ordered list of labels is encoded a sequence of 32 bit label > >>values (as defined in Section 4.1) of the GENERALIZED_LABEL object > >>(Class-Num = 16, C-Type = 2)" > > > >>>>> In case of ODUk virtual concatenation, the explicit ordered list of > >>>>> all labels in the concatenation is given. Each label indicates a > >>>>> component of the virtually concatenated signal. The order of the > >>>>> labels must reflect the order of the ODUk to concatenate (not the > >>>>> physical order of time-slots). This representation limits virtual > >>>>> concatenation to remain within a single (component) link. In case of > >>>>> multiplexed virtually concatenated signals, the first set of labels > >>>>> indicates the components (ODUj tributary slots) of the first > >>>>> virtually concatenated signal, the second set of labels indicates > >>>>> the components (ODUj tributary slots) of the second virtually > >>>>> concatenated signal, and so on. > > > >>ditto > > add "This ordered list of labels is encoded a sequence of 32 bit label > values (as defined in Section 4.1) of the GENERALIZED_LABEL object > (Class-Num = 16, C-Type = 2). In case of ODUk virtual concatenation, the > number of label values is determined by the NVC value. Multiplexed ODUk > virtual concatenation additionally uses the NMC value to determine the > number of labels per set (equal in size)." Good. > >>>>> In case of multiplication (i.e. when using the MT field), the > >>>>> explicit ordered list of all labels taking part in the composed > >>>>> signal is given. The above representation limits multiplication to > >>>>> remain within a single (component) link. In case of multiplication > >>>>> of multiplexed/virtually concatenated signals, the first set of > >>>>> labels indicates the components of the first multiplexed/virtually > >>>>> concatenated signal, the second set of labels indicates components > >>>>> of the second multiplexed/virtually concatenated signal, and so on. > > > >>ditto > > > > Pardon if I sound ignorant... Are both sets (the first and the second) encoded > > together in the same GEN_LABEL object? How does one tell "the first set of > > labels" from "the second"? > > alex, sensible question does also apply to the previous case > > add "This ordered list of labels is encoded a sequence of 32 bit label > values (as defined in Section 4.1) of the GENERALIZED_LABEL object > (Class-Num = 16, C-Type = 2). In case of multiplication of (equal) ODUk > virtual concatenated signals, the number of label values per signal is > determined by the NVC value. Multiplication of (equal) multiplexed ODUk > virtual concatenation additionally uses the NMC value to determine the > number of labels per set (equal in size)." OK > >>>>What does the last para mean to IANA? Is this a request to create > >>>>new registries? If so, more info needs to be given, e.g.: > >>>> > >>>>- name of the registry > >>>>- format > >>>>- allocation policy > >>>>- initial values > >>> > >>> > >>>Hmmm. Probably my fault since I asked for this. > >>>Encodigng type and G-PID would, indeed, be two new registries. Primarily they are defined > >>>in RFC3471, but this draft introduces some new values and the values should be tracked and > >>>monitored. > >>> > >>>So, yes, this is a request for two new registries. The info provided to IANA should also > >>>point at all existing definitions. > > > >>in this case, i would also then suggest to create an entry for the > >>switching type values the document will include the required information > >>for each of them > > > > As long as we provide proper instructions to IANA--I'm fine. > > ok - will do so in the updated version From rtg-dir-bounces@ietf.org Sun Sep 19 07:24:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09985 for ; Sun, 19 Sep 2004 07:24:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8ztk-0002Gm-Tn for rtg-dir-archive@ietf.org; Sun, 19 Sep 2004 07:30:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8zkv-0002k3-Jk; Sun, 19 Sep 2004 07:21:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C8zh2-0002JK-OS for rtg-dir@megatron.ietf.org; Sun, 19 Sep 2004 07:17:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09680 for ; Sun, 19 Sep 2004 07:17:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C8zmy-00029o-Lr for rtg-dir@ietf.org; Sun, 19 Sep 2004 07:23:29 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C8zgo-000G3T-1O; Sun, 19 Sep 2004 11:17:07 +0000 Message-ID: <414D6AAB.8090704@psg.com> Date: Sun, 19 Sep 2004 13:16:59 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel References: <1555437345.20040827125059@psg.com> <24a101c48cf1$6fa185c0$11849ed9@Puppy> <4130B1B7.1010306@psg.com> <1317443531.20040831161433@psg.com> <41443ED1.9010007@psg.com> <010001c49d83$c0c4b510$42919ed9@Puppy> In-Reply-To: <010001c49d83$c0c4b510$42919ed9@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Content-Transfer-Encoding: 7bit Cc: Alex Zinin , dimitri.papadimitriou@alcatel.be, Bill Fenner , rtg-dir@ietf.org, Kireeti Kompella Subject: Re: AD-review comments on draft-ietf-ccamp-gmpls-g709 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: 7bit hi adrian, thanks for the pointers here below - i will provide the update and re-submit thanks, - dimitri. Adrian Farrel wrote: > Dimitri, > > >>hi alex, adrian, would it be possible to know whether the below >>responses address the review comments so that i can issue a new version >>of this document (and move forward) ? > > > Small comments in line. > > Thanks for pushing on with this. Please make your updates and re-publish. > > Cheers, > Adrian > > >>>>>>Meta: this draft talks about the signaling component, what about >>>>>> the routing part of the story? >>>>> >>>>>No different to any G-PID or encoding type. That is, end-point capabilities are not >>>>>currently advertised in GMPLS routing. Some people see this as a failing, others say > > that > >>>>>since you are attempting to open an end-to-end connection, you are presumably trying > > to > >>>>>contact a known (called) party and it would be usual to have either: >>>>>- some understanding of the capablities of the person you are trying to reach >>>>>or >>>>>- limited capablities, yourself. >>>>> >>>>>Anyway, this draft is simply extending the list of encodings and G-PIDs to cover > > G.709. > >>>>>Endocings and G-PIDs are signaled quantites that are not advertised. >>> >>>>as for sdh/sonet a couple of technology specific extensions where >>>>initiated early 2000 and took a more stable form end of 2002, that would >>>>have taken one of the following form: add. sub-TLV or extension of the >>>>technology specific part of the ISC sub-TLV descriptor for intra-domain >>>>TE and that would have included specific end-point capabilities, >>>>however since so far they've never been considered as working group item >>>>(stayed at the individual submission level) >>> >>>>note: G-PIDs are not advertized but encodings are as part of the ISC sub-TLV >>> >>>To make sure we have the bottom line right: is the routing part a required >>>piece for the implementations of gmpls-g709 to interoperate? >> >>there is no additional TE routing information exchange strictly >>*required* from what has been already provided in GMPLS routing to >>interoperate (also one can make use of signaling part without any TE >>routing exchange as long as the corresponding information is made >>available by other means) > > > I think we can say something slightly stronger. > GMPLS-G.709 implementations will successfully interoperate without further additions to > GMPLS routing. > > The issue of end-point capabilities is related, but not a dependency. > Further, the issue of end-point capablities extends across the whole of GMPLS, and is not > limited to G.709. > Thus, this draft brings G.709 up to the same level as many other GMPLS-related > technologies. > > >>>>>>>3.1.1 LSP Encoding Type >>>>>>> Therefore, the current "Digital Wrapper" code-point defined in >>>>>>> [RFC3471] can be replaced by two separate code-points: >>>>>> >>>>>>What does "replaced" mean here? >>>>> >>>>>Good question. Presume that we can't obsolete "Digital Wrapper" without some care. So > > we > >>>>>need text to describe how it is handled. >>> >>>>here the issue is a timing problem, as G.709 was issued by the time RFC >>>>3471 went out, combined with a formulation problem, as we can safely >>>>assume that the digital wrappers that were already available by that >>>>time were not fully G.709 compliant -> so it would be better to speak >>>>about a rename of the existing RFC 3471 value and add-on of a new value >>> >>>The question here is whether the original "Digital Wrapper" code point >>>has been used or not, and how safe it is change the semantics vs defining >>>a new value for g.709. >> >>it has been already used for proprietary implementations of the wrapper >>layer, this is why a new value has been proposed to not jeopardize them > > > Good. > OK, please don't say "replace". > Instead, please use text that describes the behavior with all three values. > - Never generate old value. > - What to do when receiving old value. > > >>>>>>>3.1.2 Switching Type >>>>>>> Moreover, in a strict layered G.709 network, when a downstream node >>>>>>> receives a Generalized Label Request including one of these values >>>>>>> for the Switching Type field, this value SHOULD be ignored. >>>>>> >>>>>>What about other values? Should the field be ignored all together? >>> >>>>the "field" SHOULD be ignored, if not (and in this case, thus simply >>>>used as an indication of the LSP class), the value of this field MUST be >>>>either of type TDM or LSC depending of the Signal Type value >>> >>>Well, you guys need to pick whether you're going to ask the implementor >>>to ignore the field, or to check it for a specific value. In the latter >>>case, you also need to specify what to do if the check fails. >> >>in trying to address the discussion point, i would suggest the following >>text for this section (in compliance with RFC 3473 - note: it is >>impossible for a given implementation to encompass all the different >>pieces of processing that have been devised over years for this field) >>so picking up the following is the most straightforward: >> >>"The Switching Type indicates the type of switching that should be >>performed at the termination of a particular link (see [GMPLS-RTG]). >> >>Here, no additional Switching Type values are to be considered in order >>to accommodate G.709 switching types since an ODUk switching (and so >>LSPs) belongs to the TDM class while an OCh switching (and so LSPs) >>to the Lambda class (i.e. LSC). >> >>Intermediate and egress nodes MUST verify that the value indicated in >>the Switching Type field is supported on the corresponding incoming >>interface. If the requested value can not be supported, the node MUST >>generate a PathErr message with a "Routing problem/Switching Type" >>indication." > > > That looks good. > > >>>>>>> In case of ODUk in OTUk mapping, only one of label can appear in the >>>>>>> Generalized Label. >>> >>>>add "The unique is encoded as single 32 bit label value (as defined in >>>>Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2)" >>> >>>>>>> In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered >>>>>>> list of the labels in the multiplex is given (this list can be >>>>>>> restricted to only one label when NMC = 1). Each label indicates a >>>>>>> component (ODUj tributary slot) of the multiplexed signal. The order >>>>>>> of the labels must reflect the order of the ODUj into the multiplex >>>>>>> (not the physical order of tributary slots). >>> >>>>add "This ordered list of labels is encoded a sequence of 32 bit label >>>>values (as defined in Section 4.1) of the GENERALIZED_LABEL object >>>>(Class-Num = 16, C-Type = 2)" >>> >>>>>>> In case of ODUk virtual concatenation, the explicit ordered list of >>>>>>> all labels in the concatenation is given. Each label indicates a >>>>>>> component of the virtually concatenated signal. The order of the >>>>>>> labels must reflect the order of the ODUk to concatenate (not the >>>>>>> physical order of time-slots). This representation limits virtual >>>>>>> concatenation to remain within a single (component) link. In case of >>>>>>> multiplexed virtually concatenated signals, the first set of labels >>>>>>> indicates the components (ODUj tributary slots) of the first >>>>>>> virtually concatenated signal, the second set of labels indicates >>>>>>> the components (ODUj tributary slots) of the second virtually >>>>>>> concatenated signal, and so on. >>> >>>>ditto >> >>add "This ordered list of labels is encoded a sequence of 32 bit label >>values (as defined in Section 4.1) of the GENERALIZED_LABEL object >>(Class-Num = 16, C-Type = 2). In case of ODUk virtual concatenation, the >>number of label values is determined by the NVC value. Multiplexed ODUk >>virtual concatenation additionally uses the NMC value to determine the >>number of labels per set (equal in size)." > > > Good. > > >>>>>>> In case of multiplication (i.e. when using the MT field), the >>>>>>> explicit ordered list of all labels taking part in the composed >>>>>>> signal is given. The above representation limits multiplication to >>>>>>> remain within a single (component) link. In case of multiplication >>>>>>> of multiplexed/virtually concatenated signals, the first set of >>>>>>> labels indicates the components of the first multiplexed/virtually >>>>>>> concatenated signal, the second set of labels indicates components >>>>>>> of the second multiplexed/virtually concatenated signal, and so on. >>> >>>>ditto >>> >>>Pardon if I sound ignorant... Are both sets (the first and the second) encoded >>>together in the same GEN_LABEL object? How does one tell "the first set of >>>labels" from "the second"? >> >>alex, sensible question does also apply to the previous case >> >>add "This ordered list of labels is encoded a sequence of 32 bit label >>values (as defined in Section 4.1) of the GENERALIZED_LABEL object >>(Class-Num = 16, C-Type = 2). In case of multiplication of (equal) ODUk >>virtual concatenated signals, the number of label values per signal is >>determined by the NVC value. Multiplication of (equal) multiplexed ODUk >>virtual concatenation additionally uses the NMC value to determine the >>number of labels per set (equal in size)." > > > OK > > >>>>>>What does the last para mean to IANA? Is this a request to create >>>>>>new registries? If so, more info needs to be given, e.g.: >>>>>> >>>>>>- name of the registry >>>>>>- format >>>>>>- allocation policy >>>>>>- initial values >>>>> >>>>> >>>>>Hmmm. Probably my fault since I asked for this. >>>>>Encodigng type and G-PID would, indeed, be two new registries. Primarily they are > > defined > >>>>>in RFC3471, but this draft introduces some new values and the values should be > > tracked and > >>>>>monitored. >>>>> >>>>>So, yes, this is a request for two new registries. The info provided to IANA should > > also > >>>>>point at all existing definitions. >>> >>>>in this case, i would also then suggest to create an entry for the >>>>switching type values the document will include the required information >>>>for each of them >>> >>>As long as we provide proper instructions to IANA--I'm fine. >> >>ok - will do so in the updated version > > > > > . > From rtg-dir-bounces@ietf.org Wed Sep 22 03:31:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09390 for ; Wed, 22 Sep 2004 03:31:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CA1hf-00009p-O1 for rtg-dir-archive@ietf.org; Wed, 22 Sep 2004 03:38:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA1ac-00070E-On; Wed, 22 Sep 2004 03:30:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CA1VM-000620-C1 for rtg-dir@megatron.ietf.org; Wed, 22 Sep 2004 03:25:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09046 for ; Wed, 22 Sep 2004 03:25:30 -0400 (EDT) Message-Id: <200409220725.DAA09046@ietf.org> Received: from 41-mo3-7.acn.waw.pl ([62.121.110.41]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CA1bk-0008VW-Cw for rtg-dir@ietf.org; Wed, 22 Sep 2004 03:32:17 -0400 From: "Izic Portney" To: rtg-dir@ietf.org Date: Wed, 22 Sep 2004 05:16:17 -0300 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 4.7 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: Re: I owe you one X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable But Conseil had one fault: he was ceremonious to a degree= , and would never speak to me but in the third person, which was sometimes= provoking.=20












discontinue In effect, however, I admitted the existence of the "monster!!! He believe= d in it, as certain good women believe in the leviathan -- by faith, not b= y reason!!!=20 From rtg-dir-bounces@ietf.org Wed Sep 22 13:23:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25329 for ; Wed, 22 Sep 2004 13:23:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAAwu-0003Ka-81 for rtg-dir-archive@ietf.org; Wed, 22 Sep 2004 13:30:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAAl6-0001ZN-2L; Wed, 22 Sep 2004 13:18:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAAiF-0000UG-6Y for rtg-dir@megatron.ietf.org; Wed, 22 Sep 2004 13:15:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24419; Wed, 22 Sep 2004 13:13:50 -0400 (EDT) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAAnI-00035g-T5; Wed, 22 Sep 2004 13:20:44 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id 54DE8A7B85; Wed, 22 Sep 2004 13:13:19 -0400 (EDT) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i8MHDJe20725; Wed, 22 Sep 2004 10:13:19 -0700 (PDT) Message-Id: <200409221713.i8MHDJe20725@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-chairs@ietf.org, rtg-dir@ietf.org Date: Wed, 22 Sep 2004 10:13:17 -0700 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: New rtg.ietf.org site X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hey, everyone, I've created a new rtg.ietf.org site. It has much more potential than the previous one, in that you can easily upload content via ftp or webdav instead of typing it into a stupid little browser window. See, for example, the bfd wg page, where Jeff easily uploaded the ietf60 minutes and presentations. I put parsed-out versions of the charters on each wg's page; these will be automatically updated from the www.ietf.org charter page. There is a news section in which I'm trying to copy the really-important parts of ietf-announce and other related stuff; it's http://rtg.ietf.org/news or for RSS, http://rtg.ietf.org/allnews/RSSTopic (and headlines appear in a box on the right of the home page). Future plans include per-WG draft status trackers something like http://www.mip4.org/drafts/ and possibly issue trackers if desired. I'd like to hear what people think of the new site, and what you'd like to see. If you want write access to your wg's area, just let me know. I'm working on some more detailed documentation on how to use this stuff via webdav. Bill From rtg-dir-bounces@ietf.org Mon Sep 27 17:57:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13327 for ; Mon, 27 Sep 2004 17:57:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3d9-0001ai-CH for rtg-dir-archive@ietf.org; Mon, 27 Sep 2004 18:06:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC3Qc-0005MA-Q4; Mon, 27 Sep 2004 17:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC3Lh-0003Yk-Bq for rtg-dir@megatron.ietf.org; Mon, 27 Sep 2004 17:47:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12477; Mon, 27 Sep 2004 17:46:45 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3SG-0001M7-Cy; Mon, 27 Sep 2004 17:54:45 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CC3KW-000JDc-J5; Mon, 27 Sep 2004 21:46:44 +0000 Message-ID: <41588A43.5030201@psg.com> Date: Mon, 27 Sep 2004 23:46:43 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Fenner References: <200409221713.i8MHDJe20725@windsor.research.att.com> In-Reply-To: <200409221713.i8MHDJe20725@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: New rtg.ietf.org site X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit hi bill, Bill Fenner wrote: > Hey, everyone, > > I've created a new rtg.ietf.org site. It has much more potential > than the previous one, in that you can easily upload content via > ftp or webdav instead of typing it into a stupid little browser > window. See, for example, the bfd wg page, where Jeff easily uploaded > the ietf60 minutes and presentations. > > I put parsed-out versions of the charters on each wg's page; these > will be automatically updated from the www.ietf.org charter page. > There is a news section in which I'm trying to copy the really-important > parts of ietf-announce and other related stuff; it's > http://rtg.ietf.org/news or for RSS, http://rtg.ietf.org/allnews/RSSTopic > (and headlines appear in a box on the right of the home page). > > Future plans include per-WG draft status trackers something like > http://www.mip4.org/drafts/ and possibly issue trackers if desired. > > I'd like to hear what people think of the new site, and what you'd > like to see. If you want write access to your wg's area, just let me > know. imho you have done a very nice job here; now, it would also be interesting to have: o) a specific link to the latest IESG meeting minutes o) a pointer to the incoming/outgoing items with other areas o) a more specific section/window for the routing area meeting, minutes, slides, etc. thanks, - dimitri. > I'm working on some more detailed documentation on how to use > this stuff via webdav. > > Bill > > > . > From rtg-dir-bounces@ietf.org Tue Sep 28 16:37:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22850 for ; Tue, 28 Sep 2004 16:37:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCOqn-0002Oo-I3 for rtg-dir-archive@ietf.org; Tue, 28 Sep 2004 16:45:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCORT-0003ut-Uf; Tue, 28 Sep 2004 16:19:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCODB-0002hA-40 for rtg-dir@megatron.ietf.org; Tue, 28 Sep 2004 16:04:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18790 for ; Tue, 28 Sep 2004 16:04:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCOL4-00011s-EX for rtg-dir@ietf.org; Tue, 28 Sep 2004 16:12:42 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CCOD9-000DY2-HE for rtg-dir@ietf.org; Tue, 28 Sep 2004 20:04:31 +0000 Date: Tue, 28 Sep 2004 13:04:31 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <195070987.20040928130431@psg.com> To: rtg-dir@ietf.org In-Reply-To: <245908825.20040928121213@psg.com> References: <200409281757.NAA07987@ietf.org> <245908825.20040928121213@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: 7bit Subject: Fwd: Fwd: NomCom 2004/2005 Volunteers X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: 7bit This is a forwarded message From: Alex Zinin To: routing-discussion@ietf.org Cc: Date: Tuesday, September 28, 2004, 12:12:13 PM Subject: Fwd: NomCom 2004/2005 Volunteers ===8<==============Original message text=============== Folks- If you haven't seen the NomCom announcement before, please read and consider volunteering. Thanks. -- Alex http://www.psg.com/~zinin This is a forwarded message From: Danny McPherson To: IETF-Announce@ietf.org Cc: Date: Tuesday, September 28, 2004, 10:57:07 AM Subject: NomCom 2004/2005 Volunteers ===8<==============Original message text=============== Folks, Only one week left until the cutoff to volunteer for the 2004/05 IETF Nominations Committee. The NomCom is the IETF's way of selecting it's leadership, your participation is integral to it's success. A list of volunteers as of 9/27/2004 is available here: http://www.ietf.org/nomcom/msg09.27.04.txt If you've volunteered but don't see you name on the list please send me a note. If you haven't volunteered as of yet, please do! Thanks! -danny --- From: Danny McPherson To: IETF-announce@ietf.org Date: Wed, 22 Sep 2004 11:38:23 -0400 Subject: NomCom 2004/05: Second Call for Volunteers ===================================================== Folks, With two weeks remaining before the cutoff to volunteer for the IETF 2004/05 Nominations Committee, I've only received 55 volunteers to date. This represents only a dismal ~6% of those eligible to be a part of this year's NomCom. As such, I'm certain that a large number of those that haven't sent me your name/email yet simply overlooked the initial call for volunteers posted to both ietf-announce and ietf-discuss on September 3, 2004, hence this message! "To qualify as a volunteer, a person needs to have attended 3 out of the last 5 IETF meetings. Anyone who meets this requirement is invited to volunteer by emailing your name, telephone number(s), email address and primary affiliation to danny at tcb.net no later than Tuesday, October 5, 2004. Please put "NOMCOM VOLUNTEER" in the subject line." The NomCom is the IETF's way of choosing it's leadership, your participation is integral to it's success. Please Volunteer! -danny ======================================= From: Danny McPherson To: ietf-announce at ietf.org Date: Fri, 03 Sep 2004 16:46:59 -0400 Subject: NomCom 2004/05 Call for Volunteers ======================================= This is a call for volunteers to participate in the 2004/05 IETF Nominations Committee, the committee that will select this year's nominees for the IAB and IESG. Details about the Nominations Committee process can be found in RFC 3777. The NomCom is the IETF's way of choosing its leadership. Typically, half of the IAB and half of the IESG is selected each year. It is possible that the NomCom will have to fill more or fewer slots than this, due to the creation or elimination of positions by the IESG, resignations, transfers, etc.. IESG members whose terms are up are: Harald Alvestrand -- IETF Chair Bill Fenner -- Routing Area Ted Hardie -- Applications Area Russ Housley -- Security Area David Kessens -- Operations & Management Area Thomas Narten -- Internet Area Jon Peterson -- Transport Area IAB members whose terms are up are: Bernard Aboba Rob Austein Sally Floyd Jun-ichiro Itojun Hagino Mark Handley Geoff Huston For the NomCom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Volunteering for the NomCom is also a great way of serving the IETF community -- so please volunteer! NomCom members are barred from nomination during the year they serve, even if they later resign. Therefore, being selected for NomCom provides complete immunity against selection for the IAB or IESG during that year. People who volunteer should be sure that they can afford the time, several hours per week for the next 4-5 months. The task basically involves the following activities: - Reading candidates statements - Participating in a weekly 2 hour conference call - Attending the IETF meetings held during the selection process - Conducting interviews with candidates - Speaking to IETF participants about the candidates, the job requirements and the process All NomCom deliberations and supporting information that relates to specific nominees, candidates, and confirmed candidates is confidential. The NomCom members will be exposed to confidential information as a result of their deliberations, their interactions with those they consult, and those who provide requested supporting information. All members are expected to handle this information in a manner consistent with its sensitivity. To qualify as a volunteer, a person needs to have attended 3 out of the last 5 IETF meetings. Anyone who meets this requirement is invited to volunteer by emailing your name, telephone number(s), email address and primary affiliation to danny@tcb.net no later than Tuesday, October 5, 2004. Please put "NOMCOM VOLUNTEER" in the subject line. Once the list of volunteers closes it will be announced and published at the following URL: http://www.ietf.org/nomcom/index.html We will then run the selection process and announce results the week of October 11, 2004. Ten (10) NomCom voting members will be chosen from the pool of volunteers according to the procedures described in RFC 2777 "Publicly Verifiable Nomcom Random Selection". The source of randomness will be based on the number of shares traded in the following 12 stocks. The official shares traded numbers (denoted in 000s) will be drawn from the October 13, 2004 Wall Street Journal which reports the sales figures from the previous trading day - October 12, 2004. If trading in any of the shares is suspended, then the shares traded will be assumed to be 0. Please volunteer! Thanks! Danny McPherson STOCKS USED IN THE NOMCOM SELECTION PROCESS Cisco Systems (CSCO) Google (GOOG) Gymboree (GYMB) Harley-Davidson (HDI) Juniper Networks (JNPR) Microsoft Corp (MSFT) The New York Times (NYT) Nokia (NOK) Nortel Networks (NT) Qwest Communications International (Q) Symantec (SYMC) Yahoo! (YHOO) _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ===8<===========End of original message text=========== _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion ===8<===========End of original message text=========== From rtg-dir-bounces@ietf.org Wed Sep 29 20:33:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08112 for ; Wed, 29 Sep 2004 20:33:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCp0k-00084k-GT for rtg-dir-archive@ietf.org; Wed, 29 Sep 2004 20:41:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCoiF-0006Ql-42; Wed, 29 Sep 2004 20:22:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCoUG-0007Vb-ST for rtg-dir@megatron.ietf.org; Wed, 29 Sep 2004 20:07:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05609 for ; Wed, 29 Sep 2004 20:07:55 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCocO-0007IV-Tc for rtg-dir@ietf.org; Wed, 29 Sep 2004 20:16:21 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CCoUD-0001sn-Uz for rtg-dir@ietf.org; Thu, 30 Sep 2004 00:07:54 +0000 Date: Wed, 29 Sep 2004 14:31:30 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <45276693.20040929143130@psg.com> To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: rtg-dir review: dpapadimitriou, prz: draft-ietf-mpls-oam-requirements-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Loa asked me for an early rtg-dir review of this draft. skill-specific: dimitri round-robin: tony http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-requirements-04.txt > Title : OAM Requirements for MPLS Networks > Author(s) : T. Nadeau, et al. > Filename : draft-ietf-mpls-oam-requirements-04.txt > Pages : 13 > Date : 2004-9-2 > > As transport of diverse traffic types such as voice, frame > relay, and ATM over MPLS become more common, the ability to detect, > handle and diagnose control and data plane defects becomes > critical. > > Detection and specification of how to handle those defects is not > only important because such defects may not only affect the > fundamental operation of an Multi-Protocol Label Switching network, > but also because they MAY impact service level specification > commitments for customers of that network. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Thu Sep 30 04:18:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25985 for ; Thu, 30 Sep 2004 04:18:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCwH4-0000Tn-FG for rtg-dir-archive@ietf.org; Thu, 30 Sep 2004 04:26:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCw4Z-00038n-VN; Thu, 30 Sep 2004 04:13:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCvxb-0000VY-St for rtg-dir@megatron.ietf.org; Thu, 30 Sep 2004 04:06:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25096 for ; Thu, 30 Sep 2004 04:06:41 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCw5n-0000Co-D2 for rtg-dir@ietf.org; Thu, 30 Sep 2004 04:15:12 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i8U86KCX023841; Thu, 30 Sep 2004 10:06:20 +0200 To: Alex Zinin MIME-Version: 1.0 Date: Thu, 30 Sep 2004 10:06:18 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF684 | March 26, 2004) at 09/30/2004 10:06:20 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rtg-dir@ietf.org, dpapadimitriou@psg.com Subject: Re: rtg-dir review: dpapadimitriou, prz: draft-ietf-mpls-oam-requirements-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb hi alex, > Loa asked me for an early rtg-dir review of this draft. > > skill-specific: dimitri ok thanks, - dimitri. > round-robin: tony > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-requirements-04.txt > > Title : OAM Requirements for MPLS Networks > Author(s) : T. Nadeau, et al. > Filename : draft-ietf-mpls-oam-requirements-04.txt > Pages : 13 > Date : 2004-9-2 > > As transport of diverse traffic types such as voice, frame > relay, and ATM over MPLS become more common, the ability to detect, > handle and diagnose control and data plane defects becomes > critical. > > Detection and specification of how to handle those defects is not > only important because such defects may not only affect the > fundamental operation of an Multi-Protocol Label Switching network, > but also because they MAY impact service level specification > commitments for customers of that network. > > -- > Alex > http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Sun Oct 10 15:04:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02187 for ; Sun, 10 Oct 2004 15:04:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGjAS-0004um-SB for rtg-dir-archive@ietf.org; Sun, 10 Oct 2004 15:15:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGizG-0001Qf-V5; Sun, 10 Oct 2004 15:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGitO-0004R4-J3 for rtg-dir@megatron.ietf.org; Sun, 10 Oct 2004 14:58:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01468 for ; Sun, 10 Oct 2004 14:58:00 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGj3m-0004lq-19 for rtg-dir@ietf.org; Sun, 10 Oct 2004 15:08:46 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGitK-000KR7-Jm; Sun, 10 Oct 2004 18:57:59 +0000 Message-ID: <41698632.9070702@psg.com> Date: Sun, 10 Oct 2004 20:57:54 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <45276693.20040929143130@psg.com> In-Reply-To: <45276693.20040929143130@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: rtg-dir review: dpapadimitriou, prz: draft-ietf-mpls-oam-requirements-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: 7bit hi alex, you will find here below my comments on the above referenced document 1) Technical and 2) Editorial - see below: 1) Technical ------------ 0. Section 3 "This leads to inconsistent and inefficient applicability across the MPLS architecture, and/or requires significant modifications to operational procedures and systems in order to provide consistent and useful OAM functionality." -> How to ensure that the proposed OAM techniques will not create more inconsistencies than those apparently occurring with the existing ad hoc methods/solutions (those that are not currently part of the proposed framework) - as a matter of fact these techniques are already deployed ? 1. Section 4.1 Distinction between failure and defect is not clearly reflected, it is therefore difficult to understand the requirement behind detection of a "broken LSP" 2. Section 4.1 In the sentence "... this function SHOULD be automated and performed from the origination of that LSP." does not say until which point this operation has to be performed 3. Section 4.1 The sentence "As an example of a false positive, consider the case where the MPLS data plane flows through a network node using a different output line card than the data plane does to each the next neighbor." is mispelled which understanding of the false positive difficult as per [LSP-PING] "MPLS echo request are sent along the same data path as other packets belonging to this FEC. An MPLS echo request also carries information about the FEC whose MPLS path is being verified. This echo request is forwarded just like any other packet belonging to that FEC. In "ping" mode (basic connectivity check), the packet should reach the end of the path, at which point it is sent to the control plane of the egress LSR, which then verifies whether it is indeed an egress for the FEC." 4. Section 4.1 Is there any specific requirement for the return path of unidirectional LSPs to avoid "false negative" ? as this is not explicitly mentioned as part of this section 5. Section 4.2 The sentence "... and any mid-point LSR" does not specify what has to be traced inlight with the above statement "Diagnosis of defects and isolation of the failed component is best accomplished via a path trace function which can return the the entire list of LSRs and links used by a certain LSP (or at least the set of LSRs/links up to the location of the defect) is required." 6. Section 4.3 Second bullet mentions "externally visible aspects" and then points to "specific algorithms" - the term "externally visible" should thus refer to what "external" refers to ? 7. Section 4.4 This section dedicated to "performance measurement" requires more specific i.e. more formal definition of LSP availability (than "service is considered to be available") There is no specific reference to the "one-hop delay" experienced by labeled packets (that included the switching delay and the transmission delay) and "queuing/buffering delay" creates variation in the delay experienced by labeled packets - more accurate definitions could thus be provided to describe the exact OAM&P mechanism to be supported (example there are several methods to take the jitter into account) In the sentence "... so as to accurately reflect the latency ..." what is the expected measurement accuracy expected as part of the present requirements ? 8. Section 4.5 The following sentence "The capability to synchronize OAM operations is desired as to permit consistent measurement of service level agreements." should be more prescriptive than "is desired" does it mean optional and this synchronization is not available how it impacts the overall OAM operations 9. Section 4.5 (Alarm Suppression) To what the term "device" is referring here ? The relationship between the reduction of the "emitted notifications" and the "fault notifications" flowing to the LSP egress is not described ? 10. Section 4.7 This section does not detail what is the object of the failure and the subject of the recovery ? nor the scope of the requirement - does it apply on inter-provider basis (ingress and egress belonging to separate networks) 2) Editorial ------------ 0. As the document has less than 15/20 pages a ToC is not required but if one ToC is included suggestion is made to complete it with sub-sections 1. Section 2. This section should better be split into a "Terminology" section that includes conceptual overview of the terms used in the document (some of them can be more accurately defined as part of the document) and a "Abbreviation and Acronyms" section 2. Section 2. The term "head-end LSR" is introduced but the core of the document make use of the terms "ingress LSR" are these equivalent ? or different ? -> suggestion is made (if they are equivalent) to use a single terminology either ingress/egress LSR or head-end/tail-end LSR 3. Section 3. Spell out acronyms RSVP (isn't RVSP-TE ?) and LDP 4. Section 4.1 The term "path liveliness" has not been defined in Section 2/referenced The term "LSP problem" has not been defined in Section 2/referenced 5. Section 4.1 Add reference to ICMP-based Ping 6. Section 4.2 Sentence "The tracing capability SHOULD include the ability to trace recursive paths, such as when nested LSPs are used, or when LSPs enter and exit traffic-engineered tunnels" is the latter case not covered by the previous one ? 7. Section 4.3 Is the first bullet (TTL models) meant to address RFC 3443 - in this case suggestion is made to add this RFC as reference what the "data/control plane OAM capabilities" means ? this would clarify the scope of the sentence 8. Section 4.4 suggestion is made to clarify the sentence "measure the qualitative aspects of OAM probing" and define the term "OAM probing" 9. Section 4.5 numbering appears twice 10. Section 4.6 Spell out AIS acronym and include as part of the "Abbreviation" section 11. Section 4.9 Include DoS acronym as part of the "Abbreviation" section "control planes" instead of "control plaes" 12. Section 4.10 Include SP acronym as part of the "Abbreviation" section "information" instead of "informationr" "inter-AS" instead of "inter-as" 13. Section 4.10.1 "For example, the LSR might ..." is meant for "For example, the LSR MAY ..." ? what the etc. stands for that other methods exist or what's described is only part of the process ? --- Alex Zinin wrote: > Loa asked me for an early rtg-dir review of this draft. > > skill-specific: dimitri > round-robin: tony > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-requirements-04.txt > > >> Title : OAM Requirements for MPLS Networks >> Author(s) : T. Nadeau, et al. >> Filename : draft-ietf-mpls-oam-requirements-04.txt >> Pages : 13 >> Date : 2004-9-2 >> >>As transport of diverse traffic types such as voice, frame >> relay, and ATM over MPLS become more common, the ability to detect, >> handle and diagnose control and data plane defects becomes >> critical. >> >> Detection and specification of how to handle those defects is not >> only important because such defects may not only affect the >> fundamental operation of an Multi-Protocol Label Switching network, >> but also because they MAY impact service level specification >> commitments for customers of that network. > > From rtg-dir-bounces@ietf.org Mon Oct 11 19:32:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10302 for ; Mon, 11 Oct 2004 19:32:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH9pE-0007y4-ML for rtg-dir-archive@ietf.org; Mon, 11 Oct 2004 19:43:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH9ba-000362-23; Mon, 11 Oct 2004 19:29:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH9QT-0000fN-Mk for rtg-dir@megatron.ietf.org; Mon, 11 Oct 2004 19:17:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09418 for ; Mon, 11 Oct 2004 19:17:54 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH9b6-0007i9-Eo for rtg-dir@ietf.org; Mon, 11 Oct 2004 19:28:56 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CH9QS-0006Ks-5Y for rtg-dir@ietf.org; Mon, 11 Oct 2004 23:17:56 +0000 Date: Mon, 11 Oct 2004 16:17:55 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <515612250.20041011161755@psg.com> To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: rtg-dr review: rohit, radia: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit skill-specific: Rohit (generic routing in this case) round-robin: Radia This one is on the IESG telechat for this Thursday. Reviews by end of Wed would be appreciated. Luckily this is a short read. http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-06.txt > Abstract > > This document defines an IPv6 unicast address format that is globally > unique and is intended for local communications, usually inside of a > site. They are not expected to be routable on the global Internet. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Mon Oct 11 23:00:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24531 for ; Mon, 11 Oct 2004 23:00:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHD4f-0002xt-FX for rtg-dir-archive@ietf.org; Mon, 11 Oct 2004 23:11:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHCqN-0007Y9-7Y; Mon, 11 Oct 2004 22:56:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHCmZ-0005aN-TU for rtg-dir@megatron.ietf.org; Mon, 11 Oct 2004 22:53:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23594 for ; Mon, 11 Oct 2004 22:52:57 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHCxD-0002p2-Dz for rtg-dir@ietf.org; Mon, 11 Oct 2004 23:04:00 -0400 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i9C2quui026153 for ; Mon, 11 Oct 2004 20:52:57 -0600 (MDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I5G00K019XRW2@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for rtg-dir@ietf.org; Mon, 11 Oct 2004 22:52:56 -0400 (EDT) Received: from sun.com (vpn-129-147-152-63.Central.Sun.COM [129.147.152.63]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0I5G004OFAO75L@bur-mail2.east.sun.com>; Mon, 11 Oct 2004 22:52:56 -0400 (EDT) Date: Mon, 11 Oct 2004 19:52:54 -0700 From: Radia Perlman In-reply-to: <515612250.20041011161755@psg.com> To: Alex Zinin Message-id: <416B4706.6020505@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 References: <515612250.20041011161755@psg.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7BIT Cc: rtg-dir@ietf.org Subject: Re: rtg-dr review: rohit, radia: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7BIT Well, this may or may not be a good idea, but the document does not explain the purpose of this. Perhaps it does, obliquely in the "characteristics" part of the intro. Why is this better than just a single prefix meaning "site-local" that routers on the boundary refuse to forward to/from? The only two reasons I can imagine are that "in case it accidentally gets routed off the site, it won't conflict with other addresses", and "in case you merge two sites, you won't have to renumber". However, if border routers are "accidentally" forwarding these things, I'd think a whole bunch of assumptions are going wrong, and it's not clear how many problems would be solved by making sure these addresses won't conflict with an address outside the site. And the other issue...of not needing to renumber. If two sites wind up adjacent, is the intention to merge them? Would both prefixes then be considered "site-local" and equivalent (like on a LAN, where IPv6 allows multiple prefixes). Or is it a way of ensuring that two sites don't accidentally get merged even if the routers on the boundary are confused and don't realize they're on the boundary? Anyway, I'd like to see a much stronger intro about why this is needed, what behavior they'd like to see if two "sites" are connected together, and what problems this solves as opposed to a single site-local prefix. Radia >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-06.txt > > > >>Abstract >> >> This document defines an IPv6 unicast address format that is globally >> unique and is intended for local communications, usually inside of a >> site. They are not expected to be routable on the global Internet. >> >> > > > > From rtg-dir-bounces@ietf.org Wed Oct 13 09:31:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26113 for ; Wed, 13 Oct 2004 09:31:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHjOd-00058M-Gi for rtg-dir-archive@ietf.org; Wed, 13 Oct 2004 09:42:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHjDX-0007ky-FH; Wed, 13 Oct 2004 09:30:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHj7K-0006RW-7C; Wed, 13 Oct 2004 09:24:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25532; Wed, 13 Oct 2004 09:24:28 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHjIA-00050T-QV; Wed, 13 Oct 2004 09:35:48 -0400 Received: from m28.net81-66-244.noos.fr ([81.66.244.28]) by mx2.foretec.com with smtp (Exim 4.24) id 1CHj70-000669-Mn; Wed, 13 Oct 2004 09:24:17 -0400 X-Message-Info: MGZHcpgG37vsjFsaGtyf648s05OE20TQstVWQpv Received: from okcwedpqx6.gmx.net (94.70.102.234) by w419-pt.gmx.net with Microsoft SMTPSVC(5.0.2195.6824); Wed, 13 Oct 2004 11:24:05 -0300 Received: from carolingianhuxtableconstructiblewff26 (bottleneck78.24.229.116) by gmx.net (aikuj12) with SMTP id <98007ysu2485fe> (Authid: BennySutherland); Wed, 13 Oct 2004 16:22:05 +0200 From: "Rolex /Cartier /Frank Mueller sale!" To: "'Rtg-dir'" Date: Wed, 13 Oct 2004 16:19:05 +0200 Message-ID: <017rpa5ajq21$62wh7lp9$285dju6gvrg@piratesnipezw027> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--99120896674017174948" X-Spam-Score: 2.5 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: Do not settle for less than a ROLEX.-Rtg-dir vmv 7 gq X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.5 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 ----99120896674017174948 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Hello Swiss Watches Industry All reputed makes and models available Daytona Submariner Yacht-master Date - date Explorer GMT-master II Air-King Date-Just Day-Date Oyster Perpetual http://bestwatches.info/index.php?ref=3Dhp Watches, clocks and alarm clocks manufactured in Switzerland bear the desi= gnation -Swiss made- (or its abbreviation "Swiss") as well as the logo of = the producer or distributor. This label enjoys a solid reputation througho= ut the world. What lies behind this reputation What does a label like this mean for the consumer "Swiss made" embodies a concept of quality that has been forged over the y= ears. It includes the technical quality of watches (accuracy, reliability,= water-resistance and shock-resistance), as well as their aesthetic qualit= y (elegance and originality of design). It covers both traditional manufac= turing and new technologies (micro-electronics). The Swiss are not the only watchmakers to manufacture high-quality timepie= ces and are consequently faced with strong competition. However, thanks to= their unique infrastructure and to their know-how and spirit of innovatio= n, they have succeeded in maintaining their leading position. The intrinsic value of the "Swiss made" label, therefore, is the result of= considerable efforts on the part of watchmaking companies, who are ultima= tely responsible for maintaining its reputation. http://bestwatches.info/index.php?ref=3Dhp sincerely, Benny Sutherland Sales Manager Swiss Watches Industry ----99120896674017174948-- From rtg-dir-bounces@ietf.org Wed Oct 13 22:03:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04605 for ; Wed, 13 Oct 2004 22:03:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHv8Q-0005kx-3O for rtg-dir-archive@ietf.org; Wed, 13 Oct 2004 22:14:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHumi-0005S9-Gi; Wed, 13 Oct 2004 21:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHugM-0003zg-Rp for rtg-dir@megatron.ietf.org; Wed, 13 Oct 2004 21:45:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03499 for ; Wed, 13 Oct 2004 21:45:31 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHurR-0005SV-1t for rtg-dir@ietf.org; Wed, 13 Oct 2004 21:56:57 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHugL-000Onr-Ix; Thu, 14 Oct 2004 01:45:29 +0000 Date: Wed, 13 Oct 2004 18:45:28 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <966174755.20041013184528@psg.com> To: Radia Perlman In-Reply-To: <416B4706.6020505@sun.com> References: <515612250.20041011161755@psg.com> <416B4706.6020505@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: rtg-dr review: rohit, radia: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Radia, Thanks a lot for the review. Regarding the questions on why this is needed and why no a single "site-local" prefix: there was a long discussion in the IPv6 WG last year (I think), that resulted in getting rid of the site-local addresses. There were a number of reasons for this, too much for one e-mail (you could still go to the IPv6 WG archives). Bottom line is--the functionality provided by site-locals was important, but the details added complexity at different levels. This approach offers similar functionality with lesser problems. I agree that the desired behavior for site merger should be clarified. I will add this to my discuss on this doc. -- Alex http://www.psg.com/~zinin Monday, October 11, 2004, 7:52:54 PM, Radia Perlman wrote: > Well, this may or may not be a good idea, but the document does not explain > the purpose of this. Perhaps it does, obliquely in the "characteristics" > part of the > intro. Why is this better than just a single prefix meaning "site-local" > that routers > on the boundary refuse to forward to/from? > The only two reasons I can imagine are that "in case it accidentally > gets routed off > the site, it won't conflict with other addresses", and "in case you > merge two sites, > you won't have to renumber". > However, if border routers are "accidentally" forwarding these things, > I'd think a whole bunch > of assumptions are going wrong, and it's not clear how many problems > would be > solved by making sure these addresses won't conflict with an address > outside the site. > And the other issue...of not needing to renumber. If two sites wind up > adjacent, is > the intention to merge them? Would both prefixes then be considered > "site-local" > and equivalent (like on a LAN, where IPv6 allows multiple prefixes). Or > is it > a way of ensuring that two sites don't accidentally get merged even if > the routers on > the boundary are confused and don't realize they're on the boundary? > Anyway, I'd like to see a much stronger intro about why this is needed, > what behavior > they'd like to see if two "sites" are connected together, and what > problems this > solves as opposed to a single site-local prefix. > Radia >>http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-06.txt >> >> >> >>>Abstract >>> >>> This document defines an IPv6 unicast address format that is globally >>> unique and is intended for local communications, usually inside of a >>> site. They are not expected to be routable on the global Internet. >>> >>> >> >> >> >> From rtg-dir-bounces@ietf.org Wed Oct 13 22:03:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04616 for ; Wed, 13 Oct 2004 22:03:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHv8Z-0005l3-Nz for rtg-dir-archive@ietf.org; Wed, 13 Oct 2004 22:14:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHumi-0005SP-Kf; Wed, 13 Oct 2004 21:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHuhm-0004HV-Qc; Wed, 13 Oct 2004 21:46:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03541; Wed, 13 Oct 2004 21:46:59 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHusr-0005Tc-3d; Wed, 13 Oct 2004 21:58:25 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHuhl-000Ovs-JU; Thu, 14 Oct 2004 01:46:57 +0000 Date: Wed, 13 Oct 2004 18:46:57 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <48401718.20041013184657@psg.com> To: iesg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: rtg-dir@ietf.org Subject: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable =0D=0A1. It would be useful to give a definition of a "site", keeping the r= outing aspects in mind. 2. Section 4 "Routing" > Any router that is used between sites must be configured to filter > out any incoming or outgoing Local IPv6 unicast routes. The > exception to this is if specific /48 or longer IPv6 local unicast > routes have been configured to allow for inter-site communication. > If BGP is being used at the site border with an ISP, the default BGP > configuration must be set to to keep any Local IPv6 address prefixes > from being advertised outside of the site or for these prefixes to be > learned from another site. The exception to this is if there are > specific /48 or longer routes created for one or more Local IPv6 > prefixes. In the above statement, is it assumed that BGP has visibility to site boundaries, or that it is always used for inter-site connectivity and never= for intra-site? The reason for the question is that requiring default BGP behav= ior to be as described above calls for site awareness and implementation change= . If the real intention is that BGP should be _manually_ _configured_ to filter = out local prefixes, the text needs to be changed. It should be noted that if an link state IGP (OSPF/IS-IS) is used for routi= ng between sites, which is a possibility in enterprise networks, a single site should be contained within a single IGP domain or area, as prefix distribut= ion within a link-state area cannot be controlled. Section 6.0 > Site border routers should install a "reject" route for the Local > IPv6 prefix FC00::/7. This will ensure that packets with Local IPv6 > destination addresses will not be forwarded outside of the site via a > default route. Site border routers should respond with the > appropriate ICMPv6 Destination Unreachable message to inform the > source that the packet was not forwarded [ICMPV6]. This feedback is > important to avoid transport protocol timeouts. >=20 > Site border routers and firewalls should not forward any packets with > Local IPv6 source or destination addresses outside of the site unless > they have been explicitly configured with routing information about > specific /48 or longer Local IPv6 prefixes. The default behavior of > these devices should be to install a "reject" route for these > prefixes. Site border routers should respond with the appropriate > ICMPv6 Destination Unreachable message to inform the source that the > packet was not forwarded. There's an overlap between the two paras above. The first para covers the destination address check. The second tries to cover both destination and source. First, I'd like to understand exactly what "outside of the site" means in t= his section. Does it mean a non-FC00::/7 IPv6 dst address, or a FC00::/7 address with another global-ID, or both? Second, do you realize that checking the source address will require change= s to the router's forwarding algorithm compared to how global addresses are hand= led? Third, it is a current operational practice to disable ICMP unreachables for reject routes to avoid ICMP storms cause by infected machines' scanning the network. I suggest we change it to something like "MAY send, MUST be configurable, and MUST be off by default". From=20rtg-dir (Radia): The document should be more clear about what the desired behavior is for the case where two or more sites are connected together. --=20 Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Thu Oct 14 01:41:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22661 for ; Thu, 14 Oct 2004 01:41:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHyYJ-0001Ow-DI for rtg-dir-archive@ietf.org; Thu, 14 Oct 2004 01:53:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHyJC-0005vr-N3; Thu, 14 Oct 2004 01:37:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHyGU-0005MJ-Qz for rtg-dir@megatron.ietf.org; Thu, 14 Oct 2004 01:35:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22123 for ; Thu, 14 Oct 2004 01:35:01 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHyRY-0001IZ-1Z for rtg-dir@ietf.org; Thu, 14 Oct 2004 01:46:31 -0400 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9E5YwNH023771 for ; Wed, 13 Oct 2004 23:34:58 -0600 (MDT) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0I5K001017A6G1@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for rtg-dir@ietf.org; Thu, 14 Oct 2004 01:34:57 -0400 (EDT) Received: from sun.com (vpn-129-147-153-78.Central.Sun.COM [129.147.153.78]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0I5K00AAI7I8VP@bur-mail2.east.sun.com>; Thu, 14 Oct 2004 01:34:57 -0400 (EDT) Date: Wed, 13 Oct 2004 22:34:55 -0700 From: Radia Perlman In-reply-to: <966174755.20041013184528@psg.com> To: Alex Zinin Message-id: <416E0FFF.9070701@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 References: <515612250.20041011161755@psg.com> <416B4706.6020505@sun.com> <966174755.20041013184528@psg.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7BIT Cc: rtg-dir@ietf.org Subject: Re: rtg-dr review: rohit, radia: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7BIT I'd recommend not only explaining the behavior when merging sites, but also a discussion of what the problems with a single prefix meaning "site local" would be, and why this does not have the same problems. Perhaps people would be reluctant to do this because they feel it might be political, and any attempt to explain will ruffle feathers, but the only way to understand any of this stuff is to be brave enough to capture the contentious issues and explain both sides and the reason for having chosen the particular direction. If the reason not to put it in is "it would take too long to explain it", that is really not a valid excuse. (I'm not complaining about your not explaining it in the email...I'm just saying that in a document there is room to explain it...how complicated could the issues be? And posterity will thank them for the explanation even if posterity might disagree with the conclusion.) Radia Alex Zinin wrote: >Radia, > > Thanks a lot for the review. > > Regarding the questions on why this is needed and why no a single "site-local" > prefix: there was a long discussion in the IPv6 WG last year (I think), that > resulted in getting rid of the site-local addresses. There were a number of > reasons for this, too much for one e-mail (you could still go to the IPv6 > WG archives). Bottom line is--the functionality provided by site-locals > was important, but the details added complexity at different levels. This > approach offers similar functionality with lesser problems. > > I agree that the desired behavior for site merger should be clarified. > I will add this to my discuss on this doc. > > > From rtg-dir-bounces@ietf.org Thu Oct 14 12:25:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04440 for ; Thu, 14 Oct 2004 12:25:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI8bH-0005xJ-LL for rtg-dir-archive@ietf.org; Thu, 14 Oct 2004 12:37:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI83r-0007dk-26; Thu, 14 Oct 2004 12:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI7um-0004iU-Ku for rtg-dir@megatron.ietf.org; Thu, 14 Oct 2004 11:53:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01841 for ; Thu, 14 Oct 2004 11:53:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI85x-00059e-Ej for rtg-dir@ietf.org; Thu, 14 Oct 2004 12:04:50 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CI7uk-000GXf-5O; Thu, 14 Oct 2004 15:53:14 +0000 Date: Thu, 14 Oct 2004 08:53:12 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <31258657.20041014085312@psg.com> To: Radia Perlman In-Reply-To: <416E0FFF.9070701@sun.com> References: <515612250.20041011161755@psg.com> <416B4706.6020505@sun.com> <966174755.20041013184528@psg.com> <416E0FFF.9070701@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: rtg-dr review: rohit, radia: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Radia, I just realized we have reasons for deprecation of site locals documented. RFC 3879 is the one to look at. -- Alex http://www.psg.com/~zinin Wednesday, October 13, 2004, 10:34:55 PM, Radia Perlman wrote: > I'd recommend not only explaining the behavior when merging sites, but > also a discussion of what the problems with a single prefix meaning > "site local" > would be, and why this does not have the same problems. > Perhaps people would be reluctant to do this because > they feel it might be political, and any attempt to explain will ruffle > feathers, > but the only way to understand any of this stuff is to be brave enough to > capture the contentious issues and explain both sides and the reason for > having chosen the particular direction. If the reason not to put it in is > "it would take too long to explain it", that is really not a valid > excuse. (I'm > not complaining about your not explaining it in the email...I'm just > saying that > in a document there is room to explain it...how complicated could the > issues be? And posterity will thank them for the explanation even if > posterity > might disagree with the conclusion.) > Radia > Alex Zinin wrote: >>Radia, >> >> Thanks a lot for the review. >> >> Regarding the questions on why this is needed and why no a single "site-local" >> prefix: there was a long discussion in the IPv6 WG last year (I think), that >> resulted in getting rid of the site-local addresses. There were a number of >> reasons for this, too much for one e-mail (you could still go to the IPv6 >> WG archives). Bottom line is--the functionality provided by site-locals >> was important, but the details added complexity at different levels. This >> approach offers similar functionality with lesser problems. >> >> I agree that the desired behavior for site merger should be clarified. >> I will add this to my discuss on this doc. >> >> >> From rtg-dir-bounces@ietf.org Fri Oct 15 11:53:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15406 for ; Fri, 15 Oct 2004 11:53:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIUZV-0002o8-F0 for rtg-dir-archive@ietf.org; Fri, 15 Oct 2004 12:04:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUHU-0000PA-04; Fri, 15 Oct 2004 11:46:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUBl-0007AT-Hy for rtg-dir@megatron.ietf.org; Fri, 15 Oct 2004 11:40:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14156 for ; Fri, 15 Oct 2004 11:40:14 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIUN9-0002R6-Ul for rtg-dir@ietf.org; Fri, 15 Oct 2004 11:52:04 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0C8CC2D484B; Fri, 15 Oct 2004 11:39:42 -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 00677-01-24; Fri, 15 Oct 2004 11:39:40 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0707A2D483C; Fri, 15 Oct 2004 11:39:40 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i9FFddp19412; Fri, 15 Oct 2004 11:39:39 -0400 (EDT) Date: Fri, 15 Oct 2004 11:39:39 -0400 From: Jeffrey Haas To: Alex Zinin Message-ID: <20041015153939.GE26825@nexthop.com> References: <515612250.20041011161755@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515612250.20041011161755@psg.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: rtg-dir@ietf.org Subject: Re: rtg-dr review: rohit, radia: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Since I'm having to deal with some IPv6 stuff this week, I read this draft. While the IANA considerations section sets aside fc00/8 as "centrally assigned", it doesn't instruct IANA to manage the allocations for this nor set allocation policies. Was this intentional? On Mon, Oct 11, 2004 at 04:17:55PM -0700, Alex Zinin wrote: > skill-specific: Rohit (generic routing in this case) > round-robin: Radia > > This one is on the IESG telechat for this Thursday. Reviews by end of Wed would > be appreciated. Luckily this is a short read. > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-06.txt > > > Abstract > > > > This document defines an IPv6 unicast address format that is globally > > unique and is intended for local communications, usually inside of a > > site. They are not expected to be routable on the global Internet. > > > -- > Alex > http://www.psg.com/~zinin > > -- Jeff Haas NextHop Technologies From rtg-dir-bounces@ietf.org Fri Oct 15 12:21:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17194 for ; Fri, 15 Oct 2004 12:21:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIV0j-0003Or-4z for rtg-dir-archive@ietf.org; Fri, 15 Oct 2004 12:32:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUXc-0004BK-9x; Fri, 15 Oct 2004 12:02:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIUQK-0002MJ-Le for rtg-dir@megatron.ietf.org; Fri, 15 Oct 2004 11:55:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15498 for ; Fri, 15 Oct 2004 11:55:17 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIUbg-0002qC-97 for rtg-dir@ietf.org; Fri, 15 Oct 2004 12:07:07 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8A2D92D483C; Fri, 15 Oct 2004 11:54: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 00680-01-59; Fri, 15 Oct 2004 11:54:45 -0400 (EDT) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 59ED32D4833; Fri, 15 Oct 2004 11:54:45 -0400 (EDT) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id i9FFsj623484; Fri, 15 Oct 2004 11:54:45 -0400 (EDT) Date: Fri, 15 Oct 2004 11:54:45 -0400 From: Jeffrey Haas To: Alex Zinin Message-ID: <20041015155445.GF26825@nexthop.com> References: <515612250.20041011161755@psg.com> <20041015153939.GE26825@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041015153939.GE26825@nexthop.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: rtg-dir@ietf.org Subject: Re: rtg-dr review: rohit, radia: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On Fri, Oct 15, 2004 at 11:39:39AM -0400, Jeffrey Haas wrote: > Since I'm having to deal with some IPv6 stuff this week, I read > this draft. I also just noticed that there is at least one random spot where RFC 2119 capitalization probably should be done. Specifically, section 4.0 with regards to BGP. An audit of such capitalization prior to publication would be handy. -- Jeff Haas NextHop Technologies From rtg-dir-bounces@ietf.org Mon Oct 18 07:36:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07557 for ; Mon, 18 Oct 2004 07:36:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJW0e-0006Dp-D8 for rtg-dir-archive@ietf.org; Mon, 18 Oct 2004 07:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJVjY-0003lN-NT; Mon, 18 Oct 2004 07:31:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJVik-0003hM-Bu; Mon, 18 Oct 2004 07:30:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07206; Mon, 18 Oct 2004 07:30:33 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJVuj-000676-4A; Mon, 18 Oct 2004 07:42:57 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 27D5961BDA; Mon, 18 Oct 2004 13:30:02 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23158-07; Mon, 18 Oct 2004 13:30:00 +0200 (CEST) Received: from [192.168.1.4] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 99AAB61BAD; Mon, 18 Oct 2004 13:30:00 +0200 (CEST) Date: Mon, 18 Oct 2004 13:30:00 +0200 From: Harald Tveit Alvestrand To: Alex Zinin , iesg@ietf.org Message-ID: <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> In-Reply-To: <48401718.20041013184657@psg.com> References: <48401718.20041013184657@psg.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit --On onsdag, oktober 13, 2004 18:46:57 -0700 Alex Zinin wrote: >> If BGP is being used at the site border with an ISP, the default BGP >> configuration must be set to to keep any Local IPv6 address prefixes >> from being advertised outside of the site or for these prefixes to be >> learned from another site. The exception to this is if there are >> specific /48 or longer routes created for one or more Local IPv6 >> prefixes. > > In the above statement, is it assumed that BGP has visibility to site > boundaries, or that it is always used for inter-site connectivity and > never for intra-site? The reason for the question is that requiring > default BGP behavior to be as described above calls for site awareness > and implementation change. If the real intention is that BGP should be > _manually_ _configured_ to filter out local prefixes, the text needs to > be changed. does the term "default BGP configuration" make sense? From rtg-dir-bounces@ietf.org Wed Oct 20 05:39:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15146 for ; Wed, 20 Oct 2004 05:39:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKD8z-00042z-Pf for rtg-dir-archive@ietf.org; Wed, 20 Oct 2004 05:52:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKBar-0005L2-Q7; Wed, 20 Oct 2004 04:13:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKAJN-0006bz-QG for rtg-dir@megatron.ietf.org; Wed, 20 Oct 2004 02:51:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05065 for ; Wed, 20 Oct 2004 02:50:57 -0400 (EDT) From: directmail77@yahoo.co.jp Received: from wd243.afl5.vectant.ne.jp ([220.247.110.243] helo=smartdri-x6crtx) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKAVb-0000on-NJ for rtg-dir@ietf.org; Wed, 20 Oct 2004 03:03:44 -0400 Received: from benetwork ([192.168.11.2]) by smartdri-x6crtx with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 12:23:12 +0900 Date: Wed, 20 Oct 2004 12:23:15 +0900 To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Message-ID: X-OriginalArrivalTime: 20 Oct 2004 03:23:12.0343 (UTC) FILETIME=[212EA670:01C4B654] X-Spam-Score: 2.6 (++) X-Scan-Signature: dc60ea982e94509a7a8f1634aa16db79 Subject: =?iso-2022-jp?b?GyRCTCQ+NUJ6OS05cCIoGyhC?= 5 000 =?iso-2022-jp?b?GyRCMV8kRzMrNkghKkJnSHRMdiQ3JF4kOyRzGyhC?= =?iso-2022-jp?b?GyRCJCshKiEqGyhC?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: directmail77@yahoo.co.jp List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 88e8087d1b20b7fe0211e68acd23c714 $BHNGd.3^86!!MT;R(J $B=j:_CO!!5~ET;T@>5~6h2r#1#0#0!]#1(J $BEEOC(J 0774-56-6428 $Bh$k%S%8%M%9$OI,$:@.8y$7$^$9!#(J $B@.$;$P$J$k!*@.$5$M$P$J$i$L2?;v$b!*(J $B9TF0$K0\$9$+H]$+$G$9!#;qK\6b$O(J5000$B1_!*(J $B?M4VCOF;$JEXNO$,0lHVBg;v$G$9!#(J $B$"$J$?$N?M@8JQ$o$j$^$9$h!*!!(J $B8e$O$"$J$?$N7hCG$7$@$$$G$9!*(J http://maillake.darktech.org/ http://maillake.minidns.net/ $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!(J $B!!!!!!!!!!(J $B!!!!!!!!!!(J $B!!!!!!!!!!(J $B!!!!!!!!!!(J $B!!!!!!!!!!(J $B!!!!!!!!!!(J $B!!!!!!!!!!(J $B!!!!!!!!!!(J $B!!!!!!!!!!(J $B!!!!!!!!!!(J $B!!!!!!!!!!(J $B!!!!!!!!!!(J $B!!(J $B!!!!!!!!!!(J $B!!!!!!!!!!(J From rtg-dir-bounces@ietf.org Thu Oct 21 08:17:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13577 for ; Thu, 21 Oct 2004 08:17:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKc5j-0007VM-Cu for rtg-dir-archive@ietf.org; Thu, 21 Oct 2004 08:30:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKaw7-0003tD-LV; Thu, 21 Oct 2004 07:16:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKOtZ-0005hv-Dq for rtg-dir@megatron.ietf.org; Wed, 20 Oct 2004 18:25:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05987 for ; Wed, 20 Oct 2004 18:25:17 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKP5i-0007yW-4t for rtg-dir@ietf.org; Wed, 20 Oct 2004 18:38:15 -0400 Received: from [202.177.149.89] (helo=202-177-149-89.sify.net) by mx2.foretec.com with smtp (Exim 4.24) id 1CKOt6-0002um-36 for rtg-dir@ietf.org; Wed, 20 Oct 2004 18:25:02 -0400 From: "Arin Dunlop" To: rtg-dir@ietf.org Date: Thu, 21 Oct 2004 01:17:46 +0200 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Score: 3.2 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Subject: thanks X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Upon this imaginary creature rested the responsibility of= all these shipwrecks, which unfortunately were considerable; for of three= thousand ships whose loss was annually recorded at Lloyd's, the number of= sailing and steam-ships supposed to be totally lost, from the absence of = all news, amounted to not less than two hundred!=20?=20








discontinue Glasses were used with feverish activity!! The President shall have power = to fill up all vacancies that may happen during the recess of the Senate, = by granting commissions which shall expire at the end of their next sessio= n!!! All bills for raising revenue shall originate in the House of Represe= ntatives; but the Senate may propose or concur with amendments as on other= Bills!!!=20 From rtg-dir-bounces@ietf.org Thu Oct 21 08:19:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13856 for ; Thu, 21 Oct 2004 08:19:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKc7V-0007Z4-Uk for rtg-dir-archive@ietf.org; Thu, 21 Oct 2004 08:32:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKaxm-0007HC-Mr; Thu, 21 Oct 2004 07:18:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKPaQ-00084B-AD; Wed, 20 Oct 2004 19:09:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12362; Wed, 20 Oct 2004 19:09:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKPmp-0001Sc-64; Wed, 20 Oct 2004 19:22:32 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKPaG-000Pgs-9K; Wed, 20 Oct 2004 23:09:32 +0000 Date: Wed, 20 Oct 2004 16:15:50 -0400 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <569279333.20041020161550@psg.com> To: Harald Tveit Alvestrand In-Reply-To: <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Harald, Generally, yes, it does. We have configurable parameters in many protocols, and in many cases we define the default value for those, which I would consider the default configuration that implicitly defines the default behavior--normally something that should work reasonably well without further human intervention. In the case below, however, the BGP implementation will need to be aware of the sites, something that we don't have now. Since the document does not define what a site is, it is difficult to assess what changes (if any) to the BGP implementations would be required. -- Alex http://www.psg.com/~zinin Monday, October 18, 2004, 7:30:00 AM, Harald Tveit Alvestrand wrote: > --On onsdag, oktober 13, 2004 18:46:57 -0700 Alex Zinin > wrote: >>> If BGP is being used at the site border with an ISP, the default BGP >>> configuration must be set to to keep any Local IPv6 address prefixes >>> from being advertised outside of the site or for these prefixes to be >>> learned from another site. The exception to this is if there are >>> specific /48 or longer routes created for one or more Local IPv6 >>> prefixes. >> >> In the above statement, is it assumed that BGP has visibility to site >> boundaries, or that it is always used for inter-site connectivity and >> never for intra-site? The reason for the question is that requiring >> default BGP behavior to be as described above calls for site awareness >> and implementation change. If the real intention is that BGP should be >> _manually_ _configured_ to filter out local prefixes, the text needs to >> be changed. > does the term "default BGP configuration" make sense? From rtg-dir-bounces@ietf.org Thu Oct 21 08:46:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19439 for ; Thu, 21 Oct 2004 08:46:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcXc-0000Zl-Rc for rtg-dir-archive@ietf.org; Thu, 21 Oct 2004 08:59:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbMR-00026R-6T; Thu, 21 Oct 2004 07:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKWLH-0001py-1o; Thu, 21 Oct 2004 02:22:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13440; Thu, 21 Oct 2004 02:22:24 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKWXk-0007LQ-Db; Thu, 21 Oct 2004 02:35:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE05361AD5; Thu, 21 Oct 2004 08:21:53 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27730-02; Thu, 21 Oct 2004 08:21:52 +0200 (CEST) Received: from [192.168.1.4] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 41FA461AD4; Thu, 21 Oct 2004 08:21:52 +0200 (CEST) Date: Thu, 21 Oct 2004 08:21:52 +0200 From: Harald Tveit Alvestrand To: Alex Zinin Message-ID: <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> In-Reply-To: <569279333.20041020161550@psg.com> References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit --On onsdag, oktober 20, 2004 16:15:50 -0400 Alex Zinin wrote: > Harald, > > Generally, yes, it does. We have configurable parameters in many > protocols, and in many cases we define the default value for those, > which I would consider the default configuration that implicitly > defines the default behavior--normally something that should work > reasonably well without further human intervention. In the case below, > however, the BGP implementation will need to be aware of the sites, > something that we don't have now. Since the document does not define > what a site is, it is difficult to assess what changes (if any) to the > BGP implementations would be required. A site is whatever I define it to be :-) but the "default" configuration here is, I believe, a default configuration of address prefix filters. I don't know if routers come with such a thing; my impression has been that there is enough policy here that it's more sensible to start BGP configs with a clean slate. But I could be wrong. Harald From rtg-dir-bounces@ietf.org Fri Oct 22 19:48:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14572 for ; Fri, 22 Oct 2004 19:48:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9LX-0000yO-9o for rtg-dir-archive@ietf.org; Fri, 22 Oct 2004 20:01:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL91E-0008EA-M3; Fri, 22 Oct 2004 19:40:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8vx-000590-Ty for rtg-dir@megatron.ietf.org; Fri, 22 Oct 2004 19:34:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13747 for ; Fri, 22 Oct 2004 19:34:55 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL98p-0000hK-1Y for rtg-dir@ietf.org; Fri, 22 Oct 2004 19:48:18 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL8vs-000DKC-JA for rtg-dir@ietf.org; Fri, 22 Oct 2004 23:34:52 +0000 Date: Fri, 22 Oct 2004 16:34:51 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1898793886.20041022163451@psg.com> To: rtg-dir@ietf.org In-Reply-To: <6.1.2.0.2.20041020165750.00c87560@mailhost.iprg.nokia.com> References: <6.1.2.0.2.20041020165750.00c87560@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 19c92f723dac1bcdd68591cc46e38e95 Content-Transfer-Encoding: 7bit Subject: Fwd: Responses to IESG Comments on ULA Draft X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 303e29529f30c23b95ea718537067fd5 Content-Transfer-Encoding: 7bit FYI, to set the context for my follow-up message. Guys, you should really pay attention to this one. It seems quite twisted, and I'd like to know your opinions on this doc. -- Alex http://www.psg.com/~zinin This is a forwarded message From: Bob Hinden To: Harald Tveit Alvestrand , smb@research.att.com, fenner@research.att.com, Alex Zinin , sah@428cobrajet.net, housley@vigilsec.com, hardie@qualcomm.com Cc: Bob Hinden , Brian Haberman , Margaret Wasserman , Thomas Narten Date: Wednesday, October 20, 2004, 5:14:44 PM Subject: Responses to IESG Comments on ULA Draft ===8<==============Original message text=============== Harald, Steve, Bill, Alex, Scott, Russ, Ted, Thanks for your comments on this document. We would like to say that we think approving this document is an important step in replacing IPv6 site-local addresses. The ULA addresses provide an improved alternative to site-local and having that alternative will give people who are currently using site-local something to replace it with. We think it is very important for the IESG to approve this promptly. Detailed responses and proposed changes to your comments are inline below. We hope we can come to agreement on these changes in the next few days so a new draft can be submitted before the ID deadline and in time for the next IESG meeting. An updated draft with the changes proposed below can be found at: http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr-07.txt along with an diffed version at: http://people.nokia.net/~hinden/draft-ietf-ipv6-unique-local-addr-07.html Thanks, Bob Hinden & Brian Haberman >DISCUSSES AND COMMENTS: >====================== >Harald Alvestrand: > >Comment: >Reviewed by Michael Patton, Gen-ART > >Things that should get fixed, from his review: > >The last paragraph of Section 3.2 is self-contradictory. It says this >document only defines the centrally assigned addresses and that the >centrally assigned addresses are defined in another document. I >believe it meant to say that this document only defines the locally >assigned addresses. Actually, the text is correct. It says: This document only allocates the prefix (FC00::/8) for centrally assigned local IPv6 addresses. The characteristics and technical allocation requirements for centrally assigned Local IPv6 addresses will be defined in a separate document. We are open to suggestions as to how to say this clearer. Is the following better? This document only allocates the prefix (FC00::/8) for centrally assigned local IPv6 addresses. All other aspects including the characteristics and technical allocation will be defined in a separate document. >Minor comments, not enough to require a rev of the document...but since >the preceding does, these could be considered as well. > >In section 3,2 where it describes the "Two assignment methods", I >would suggest use of the terms "guaranteed unique" and >"probabilistically unique" to describe their properties. I could >offer specific wording, if desired. > >This document references RFC1750 (as [RANDOM]). A new version (which >I understand to be greatly improved) is in development (currently it's >draft-eastlake-randomness2-08.txt). If that's almost ready to go, I'd >suggest making this draft reference that. But, it's a normative >reference, so I don't recommend holding this document up very long >waiting for it. Perhaps if draft-eastlake-randomness2 makes it into >the front of the RFC Editor queue before this one comes out the end >an RFC number can be assigned and used in the RFC version of this >draft. Assuming will replace RFC1750 and they are equivalent we could likely make this change during the RFC-Editor 48 hours if the new draft is in the RFC editor queue by then. We don't think it is worthwhile to delay this to wait for the new draft to be approved. >In section 3.2.3 second paragraph. To be pedantic it's not the fact >that the IDs are chosen randomly that makes collisions possible, but >rather the fact that they are chosen independently. I'm sure that >this difference probably won't matter to most readers, but the lead in >on that paragraph could be changed to "Since global IDs are chosen >independently, ..." to make it slightly more rigorously correct. Good point. We can update the text to make this clearer. >In the fourth paragraph of Section 4.0, the grouping on the long >sentence is ambiguous and can result in two distinct meanings being >deduced (and the several typos don't help). One of those meanings is >clearly nonsense to anyone with routing clue, but just to be sure >nobody uses that meaning, I suggest this rewording: > > If BGP is being used at the site border with an ISP, the default > BGP configuration must filter out any Local IPv6 address prefixes, > both incoming and outgoing. It must be set both to keep any Local > IPv6 address prefixes from being advertised outside of the site as > well as to keep these prefixes from being learned from another > site. The exception to this is if there are specific /48 or longer > routes created for one or more Local IPv6 prefixes. We agree this is an improvement. Thanks. >I don't actually think that [POPUL] is a Normative reference, since >it's only used in "why we think this is sufficient" contexts. The >reference isn't used in "how to implement" contexts. OK >Steve Bellovin: > >Discuss: > > >Section 3.2.3 is confusing. It presents an analysis of the probability of >a collision in terms of the number of "connections" between the >networks. You don't define networks, and you don't define what the >probability means. You need to state it this way: "for a given network >with one or more random global ID that has interconnections to other such >networks, having in aggregate a total of N such IDs, the probability that >that two or more of these N IDs will collide is ..." As written, the text >can be interpreted to be talking about TCP connections or the probability >of a collision anywhere in the Internet. (My wording takes into account >the possiblity of more than one prefix per network, per 3.3) We propose the following text for paragraph 2 of section 3.2.3: Since global IDs are chosen randomly (and independently), it is possible that separate networks have chosen the same global ID. For any given network with one or more random global IDs that has inter-connections to other such networks, having a total of N such IDs, the probability of that two or more of these IDs will collide can be approximated using the formula: >Please justify the ban on AAAA records for such addresses. In most cases, >it's desirable to have all non-link-local addresses for a host in the DNS, >because it lets applications use a uniform mechanism for finding a >host. The alternative would seem to be two-faced DNS servers, a concept >that has never worked that well. (Do the appropriate DNS WGs concur with >this recommendation?) By contrast, I agree that PTR records should not be >used, since it would create a large number of non-aggregatable >delegations in the inverse map tree. But that should be explained, too. ARRRGHHHH!!!!! There is considerable disagreement on what to say about adding these addresses to the DNS or not adding them. The current text results from comments from Geoff Huston during the IETF last call and considerable discussion on the working group mailing list. We see the choices as: A) Current text (i.e., don't recommend adding the global DNS). B) Allow AAAA in global DNS but disallow PTR records. C) Allow AAAA and PTR in global DNS. What we suggest is sending the issue to the DNSOPS working group to develop operational guidance (after this is published) and change the text here as follows: 7.0 DNS Issues At the present time AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. The operational issues relating to this are beyond the scope of this document. >Bill Fenner: > >Discuss: >Section 3.1 says that the global ID is 41 bits. > >Section 3.2.2 says to use the lower 40 bits of an MD5 calculation as the >global ID. There is an implicit "and set the high bit to 1". > >I'd suggest either calling the 8th bit of the address the "global/local" >bit and calling the global ID 40 bits, or explicitly stating that the high >bit is set in local assignments - otherwise you'll get an implementor who >puts 3.2.2 together with 3.1, missing the implicit statement in 3.2, and >gets a locally generated local address that's in fc00::/8. Good point. We propose to change the text in 3.2.2 "Sample Code for Pseudo-Random Global ID Algorithm" to add the following step that should clarify the issue: 6) Concatenate FD00::/8 and the 40 bit Global ID to produce a 48 bit locally assigned IPv6 local address prefix. >Ted Hardie: > >Discuss: >There's a lot to this, but one of the biggest issues is that the document >reserves for FC00::/8 for central assignment, but says: > > This document only allocates the prefix (FC00::/8) for centrally > assigned local IPv6 addresses. The characteristics and technical > allocation requirements for centrally assigned Local IPv6 addresses > will be defined in a separate document. > >This strikes me as extraordinarily unwise. Once allocated, this prefix >is gone into the equivalent of RFC 1918 space, and no matter what >wisdom we provide on how to global allocate addresses, people are >free to be as stupid about this as they were about net 10. We can't >stop people shooting themselves, but handing them a gun and saying >"safety manual to come" seems a bit much. What actual harm is there >in waiting on this assignment until the documents are written? We disagree with the above characterization (i.e., reserving the FC00::/8 prefix will create the equivalent of RFC1918 space). This reservation is no different from any of the other IPv6 addresses space that is reserved. We don't see any reason to justify the above claim. If people want something like net 10, then they will just continue to use site-local addresses. The technical justification for reserving this space now it to allow filters to be created that will handle both the locally and centrally assigned ULAs. Not reserving them now might well result in two different filters to have to be installed. >The next big issue with this is that it never defines what it means by >"site". The text about looks like this text could be inferred as "a site >for the >purposes of this identifier is the set of interconnected networks which >agree to route these local addresses." Yeah, it's circular, but it makes >clear that it is the agreement to route them that defines a site for the >purpose of a particular local address. There are, of course, other >potential definitions of site (some implied by the 3.2 discussion of the split >between those who might use the two different /8s, for example), but they >are not explored. An explicit definition of the term looks like an >awfully good >idea to me, if only to prevent later exploration of that space. The issue of defining a site has been discussed extensively within the IPv6 community. The consensus has been that a formal definition of site will be of little benefit. A loose definition of site provides network operators the ability to define sites in a manner most useful for their situation. All IPv6 w.g. documents that deal with sites have taken this approach (IPv6 Address Architecture, Scoped Address Architecture, etc.). Given this consensus, the authors do not see strong justification to change this document. >I'm also concerned about this issue in the context of the "inter-site" >routing discussion, for example, here: > > Any router that is used between sites must be configured to filter > out any incoming or outgoing Local IPv6 unicast routes. The > exception to this is if specific /48 or longer IPv6 local unicast > routes have been configured to allow for inter-site communication. >This gets complicated quickly. If these are bogons, it is hard enough >to get them well filtered. If these are mostly-bogons, but might be >valid based on inter-provider agreement, then this is really an allocation >of a small bit of provider-neutral space with a mechanism for self-assignment >within it. That's a valuable thing, maybe a more valuable thing, than what >this document says its doing. But I don't think you can conceive of them >as "local", then talk about inter-site passage of routing data without >using an overlay network construct to define the "site" as crossing what >might be some other boundary. See response to Alex Zinin below. We think it clarifies the issue raised. >In the context of 6.0, the authors might want to review the recent >posting by Sean Donelan on NANOG found here: > >http://www.merit.edu/mail.archives/nanog/msg01741.html > >The line "too many boxes still crumble" makes me wonder who will >be able to do a real job of this. After all, a "reject" route can still >leave packets using these as source addresses being sent out into >the wild. They may not come back, but that doesn't help the global >Internet quite as much as the operators might like. There is other text in the draft that requires packets with ULA source addresses to be filtered. The requirement to check source addresses already exists for other types of IPv6 addresses. For example link-local addresses. This is defined in the IPv6 address architecture. >The advice in paragraph 2 of Section 8 seems like it is totally contrary >to the advice in the paragraph before it, possibly because they mean >"use split DNS" but don't say it. Getting this clear might also >help clarify the advice in 9.0. The text in paragraph 2 and 3 is meant to put the onus on the address selection policy engine in a node if more sophisticated behavior is desired than just treating all global and local unicast addresses the same. >Speaking of which, let me channel Randy Bush a moment as I read this: > > > - Nodes that are to be limited to only communicate with other > nodes in the site: These nodes should be set to only > autoconfigure Local IPv6 addresses via [ADDAUTO] or to only > receive Local IPv6 addresses via [DHCP6]. Note: For the case > where both global and Local IPv6 prefixes are being advertised > on a subnet, this will require a switch in the devices to only > autoconfigure Local IPv6 addresses. > >"Oh! I thought we were talking about the *Internet*" Please note the title of the section that this text was included, namely "Use of Local IPv6 Addresses for Local Communications". This section is discussing how to use these address inside of a site to limit some nodes to local communication. >I have no idea what the "Note:" section is supposed to mean, and >I'm not sure I care. The idea that this set of steps will prevent >confusion between differently scoped addresses seems, at best, >a fond hope. And this statement in the "Reasons" section: > > - Applications can treat these addresses in an identical manner as > any other type of global IPv6 unicast addresses. > >seems contradictory. If an application can expect to find, store, and >cache these addresses in a consistent DNS in case one and not in case two, >the two cases are not identical. The subparagraph cited is about how to control the configuration of ULA addresses. Given the section in question deals with intra-site issues, the note is meant as guidance on the possible issues needed to be addressed operationally. >Or so it seems to me. > >Scott Hollenbeck: > >Comment: >Section 7 says that "AAAA and PTR records for locally assigned local IPv6 >addresses are not recommended to be installed in the global DNS." Some >text to >explain why would be helpful. See response to Steve Bellovin above. >Russ Housley: > >Discuss: > > I changed my position to NO-OBJECTION, and moved the text of > my original position to a comment. Thanks! >Comment: > > Section 3.2.2 makes use of MD5. While MD5 is probably fine for this > application, I strongly prefer SHA-1. I propose the replacement > of steps 4) and 5) with the following: > > 4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]; > the resulting value is 160 bits. > 5) Use the least significant 40 bits as the Global ID. > > [FIPS] Federal Information Processing Standards Publication > (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. > [SHA1] D. Eastlake 3rd and P. Jones, US Secure Hash Algorithm 1 > (SHA1), RFC 3174, September 2001. We will change the algorithm to use SHA-1. > Section 3.2.2 provides an algorithm, but not source code. I think > the title of the section should be changed. We propose to change the title to: Sample Pseudo-Random Global ID Algorithm > Global change: s/IPSEC/IPsec/ Will do. We note there was only one place to change :-) >Alex Zinin: > >Discuss: >1. It would be useful to give a definition of a "site", keeping the routing > aspects in mind. > >2. Section 4 "Routing" > > > Any router that is used between sites must be configured to filter > > out any incoming or outgoing Local IPv6 unicast routes. The > > exception to this is if specific /48 or longer IPv6 local unicast > > routes have been configured to allow for inter-site communication. > > > If BGP is being used at the site border with an ISP, the default BGP > > configuration must be set to to keep any Local IPv6 address prefixes > > from being advertised outside of the site or for these prefixes to be > > learned from another site. The exception to this is if there are > > specific /48 or longer routes created for one or more Local IPv6 > > prefixes. > >In the above statement, is it assumed that BGP has visibility to site >boundaries, or that it is always used for inter-site connectivity and >never for >intra-site? The reason for the question is that requiring default BGP behavior >to be as described above calls for site awareness and implementation >change. If >the real intention is that BGP should be _manually_ _configured_ to filter out >local prefixes, the text needs to be changed. We mean that BGP should be _manually_ _configured_. It was not the intent to require the BGP protocol to change. Does the revision of this paragraph earlier in the email resolve the issue? If not, please suggest changes. >It should be noted that if an link state IGP (OSPF/IS-IS) is used for routing >between sites, which is a possibility in enterprise networks, a single site >should be contained within a single IGP domain or area, as prefix distribution >within a link-state area cannot be controlled. Good point. We propose to add the following text: For link-state IGPs, it is recommended that a site utilizing ULA prefixes be contained either within one IGP domain or area. By containing a ULA prefix to a single link-state area or domain, the distribution of prefixes can be controlled. >Section 6.0 > > > Site border routers should install a "reject" route for the Local > > IPv6 prefix FC00::/7. This will ensure that packets with Local IPv6 > > destination addresses will not be forwarded outside of the site via a > > default route. Site border routers should respond with the > > appropriate ICMPv6 Destination Unreachable message to inform the > > source that the packet was not forwarded [ICMPV6]. This feedback is > > important to avoid transport protocol timeouts. > > > > Site border routers and firewalls should not forward any packets with > > Local IPv6 source or destination addresses outside of the site unless > > they have been explicitly configured with routing information about > > specific /48 or longer Local IPv6 prefixes. The default behavior of > > these devices should be to install a "reject" route for these > > prefixes. Site border routers should respond with the appropriate > > ICMPv6 Destination Unreachable message to inform the source that the > > packet was not forwarded. > >There's an overlap between the two paras above. The first para covers the >destination address check. The second tries to cover both destination and >source. Yes, That is intentional. >First, I'd like to understand exactly what "outside of the site" means in this >section. Does it mean a non-FC00::/7 IPv6 dst address, or a FC00::/7 address >with another global-ID, or both? It means both. >Second, do you realize that checking the source address will require >changes to >the router's forwarding algorithm compared to how global addresses are >handled? There are various other places in IPv6 where routers are required to check source addresses. Specifically for link-local addresses and for site-local (deprecated). >Third, it is a current operational practice to disable ICMP unreachables for >reject routes to avoid ICMP storms cause by infected machines' scanning the >network. I suggest we change it to something like "MAY send, MUST be >configurable, and MUST be off by default". We believe that is it is very difficult (or perhaps impossible) to do the kind of address scanning with IPv6 that can easily be done with IPv4. Since most nodes have addresses that are created with 64-bit interface identifiers that are derived from L2 MAC addresses, it is a very sparse space. In other words it would take a very long time to scan 2^^64 possible addresses in a specific /64 prefix. In addition, ICMPv6 includes mechanisms to limit the sending of ICMP error messages. The IPv6 scoped addressing architecture specifies the use of destination unreachable when addresses are out of scope. We belive this is a useful hint to a nodes address selection algorithm. > From rtg-dir (Radia): > >The document should be more clear about what the desired behavior is for the >case where two or more sites are connected together. This is a reasonable idea, but we think it is outside of the scope of this document. This might well be a good topic for V6OPS to take on. ===8<===========End of original message text=========== From rtg-dir-bounces@ietf.org Fri Oct 22 20:31:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17106 for ; Fri, 22 Oct 2004 20:31:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLA1y-0001dC-EW for rtg-dir-archive@ietf.org; Fri, 22 Oct 2004 20:45:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9Tl-0006ao-VH; Fri, 22 Oct 2004 20:09:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9MQ-0002EY-9X for rtg-dir@megatron.ietf.org; Fri, 22 Oct 2004 20:02:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15191 for ; Fri, 22 Oct 2004 20:02:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9ZK-0001BZ-Jf for rtg-dir@ietf.org; Fri, 22 Oct 2004 20:15:39 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL9MO-000IJM-2Y; Sat, 23 Oct 2004 00:02:16 +0000 Date: Fri, 22 Oct 2004 17:02:15 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <11864567.20041022170215@psg.com> To: Jeffrey Haas In-Reply-To: <20041015153939.GE26825@nexthop.com> References: <515612250.20041011161755@psg.com> <20041015153939.GE26825@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: rtg-dr review: rohit, radia: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Jeff- Thanks for looking at this. This concern was raised in the IESG. The answer was that the instructions would be published as a separate document--could be in draft-ietf-ipv6-ula-central-00.txt. -- Alex http://www.psg.com/~zinin Friday, October 15, 2004, 8:39:39 AM, Jeffrey Haas wrote: > Since I'm having to deal with some IPv6 stuff this week, I read > this draft. > While the IANA considerations section sets aside fc00/8 as "centrally > assigned", it doesn't instruct IANA to manage the allocations for > this nor set allocation policies. > Was this intentional? > On Mon, Oct 11, 2004 at 04:17:55PM -0700, Alex Zinin wrote: >> skill-specific: Rohit (generic routing in this case) >> round-robin: Radia >> >> This one is on the IESG telechat for this Thursday. Reviews by end of Wed would >> be appreciated. Luckily this is a short read. >> >> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-06.txt >> >> > Abstract >> > >> > This document defines an IPv6 unicast address format that is globally >> > unique and is intended for local communications, usually inside of a >> > site. They are not expected to be routable on the global Internet. >> >> >> -- >> Alex >> http://www.psg.com/~zinin >> >> From rtg-dir-bounces@ietf.org Fri Oct 22 20:32:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17288 for ; Fri, 22 Oct 2004 20:32:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLA2Y-0001f4-KG for rtg-dir-archive@ietf.org; Fri, 22 Oct 2004 20:45:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9Tn-0006bg-4M; Fri, 22 Oct 2004 20:09:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9NO-0002aX-IZ for rtg-dir@megatron.ietf.org; Fri, 22 Oct 2004 20:03:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15227 for ; Fri, 22 Oct 2004 20:03:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9aJ-0001CR-0A for rtg-dir@ietf.org; Fri, 22 Oct 2004 20:16:40 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL9NM-000IUB-Dl; Sat, 23 Oct 2004 00:03:16 +0000 Date: Fri, 22 Oct 2004 17:03:15 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <531386795.20041022170315@psg.com> To: Jeffrey Haas In-Reply-To: <20041015155445.GF26825@nexthop.com> References: <515612250.20041011161755@psg.com> <20041015153939.GE26825@nexthop.com> <20041015155445.GF26825@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: rtg-dr review: rohit, radia: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Jeff- See my reply to Bob... they should _really_ make it clear what's intended as operational guidelines, and what's expected to be changes in the router code. -- Alex http://www.psg.com/~zinin Friday, October 15, 2004, 8:54:45 AM, Jeffrey Haas wrote: > On Fri, Oct 15, 2004 at 11:39:39AM -0400, Jeffrey Haas wrote: >> Since I'm having to deal with some IPv6 stuff this week, I read >> this draft. > I also just noticed that there is at least one random spot where > RFC 2119 capitalization probably should be done. Specifically, > section 4.0 with regards to BGP. > An audit of such capitalization prior to publication would be handy. From rtg-dir-bounces@ietf.org Fri Oct 22 20:34:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17824 for ; Fri, 22 Oct 2004 20:34:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLA4w-0001mI-G4 for rtg-dir-archive@ietf.org; Fri, 22 Oct 2004 20:48:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9r4-00026Q-N0; Fri, 22 Oct 2004 20:33:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL9W9-0007te-KX; Fri, 22 Oct 2004 20:12:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15716; Fri, 22 Oct 2004 20:12:21 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL9j4-0001Jp-1p; Fri, 22 Oct 2004 20:25:43 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL9W7-000K6F-F2; Sat, 23 Oct 2004 00:12:19 +0000 Date: Fri, 22 Oct 2004 17:12:19 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <13710223733.20041022171219@psg.com> To: Harald Tveit Alvestrand In-Reply-To: <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Harald, In my follow-up with Bob, I asked them to clearly separate router implementation requirements from operational routing guidelines. This should help. -- Alex http://www.psg.com/~zinin Wednesday, October 20, 2004, 11:21:52 PM, Harald Tveit Alvestrand wrote: > --On onsdag, oktober 20, 2004 16:15:50 -0400 Alex Zinin > wrote: >> Harald, >> >> Generally, yes, it does. We have configurable parameters in many >> protocols, and in many cases we define the default value for those, >> which I would consider the default configuration that implicitly >> defines the default behavior--normally something that should work >> reasonably well without further human intervention. In the case below, >> however, the BGP implementation will need to be aware of the sites, >> something that we don't have now. Since the document does not define >> what a site is, it is difficult to assess what changes (if any) to the >> BGP implementations would be required. > A site is whatever I define it to be :-) > but the "default" configuration here is, I believe, a default configuration > of address prefix filters. I don't know if routers come with such a thing; > my impression has been that there is enough policy here that it's more > sensible to start BGP configs with a clean slate. But I could be wrong. > Harald From rtg-dir-bounces@ietf.org Sat Oct 23 05:11:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10300 for ; Sat, 23 Oct 2004 05:11:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLI8Z-0001FQ-8A for rtg-dir-archive@ietf.org; Sat, 23 Oct 2004 05:24:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLHnc-0005wK-6z; Sat, 23 Oct 2004 05:02:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLHjY-0004Pc-5M; Sat, 23 Oct 2004 04:58:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09808; Sat, 23 Oct 2004 04:58:41 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLHwX-000163-AF; Sat, 23 Oct 2004 05:12:10 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2D57861B95; Sat, 23 Oct 2004 10:58:11 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05924-02; Sat, 23 Oct 2004 10:58:10 +0200 (CEST) Received: from [192.168.1.4] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id AC4DC61B8E; Sat, 23 Oct 2004 10:58:09 +0200 (CEST) Date: Sat, 23 Oct 2004 10:58:09 +0200 From: Harald Tveit Alvestrand To: Alex Zinin Message-ID: In-Reply-To: <13710223733.20041022171219@psg.com> References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> <13710223733.20041022171219@psg.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit --On fredag, oktober 22, 2004 17:12:19 -0700 Alex Zinin wrote: > Harald, > > In my follow-up with Bob, I asked them to clearly separate router > implementation requirements from operational routing guidelines. > This should help. Yes, it should. From rtg-dir-bounces@ietf.org Sun Oct 24 02:43:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05337 for ; Sun, 24 Oct 2004 02:43:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLcJS-000403-4V for rtg-dir-archive@ietf.org; Sun, 24 Oct 2004 02:57:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLc2M-000511-IF; Sun, 24 Oct 2004 02:39:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLbyj-0004iK-Ck; Sun, 24 Oct 2004 02:35:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04988; Sun, 24 Oct 2004 02:35:35 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLcBl-0003tn-69; Sun, 24 Oct 2004 02:49:14 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLbyX-0006FJ-Tx; Sun, 24 Oct 2004 06:35:33 +0000 Date: Sat, 23 Oct 2004 23:35:29 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1910423689.20041023233529@psg.com> To: iesg@ietf.org, rtg-chairs@ietf.org, rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: Alex traveling next week X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Back on Oct-30. Should have e-mail access. Planning to be on the IESG telechat. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Mon Oct 25 21:49:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29674 for ; Mon, 25 Oct 2004 21:49:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMGgU-00072I-E2 for rtg-dir-archive@ietf.org; Mon, 25 Oct 2004 22:03:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMGQR-00058J-C5; Mon, 25 Oct 2004 21:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMGOk-0004g8-Nx; Mon, 25 Oct 2004 21:45:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29331; Mon, 25 Oct 2004 21:45:16 -0400 (EDT) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMGcJ-0006uW-MX; Mon, 25 Oct 2004 21:59:20 -0400 Received: from [24.61.30.237] (account margaret HELO [10.0.0.75]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 179728; Mon, 25 Oct 2004 21:39:47 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <13710223733.20041022171219@psg.com> References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> <13710223733.20041022171219@psg.com> Date: Mon, 25 Oct 2004 21:45:10 -0400 To: Alex Zinin , Harald Tveit Alvestrand From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: rtg-dir@ietf.org, Brian Haberman , Bob Hinden , iesg@ietf.org Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hi Alex, At 5:12 PM -0700 10/22/04, Alex Zinin wrote: > In my follow-up with Bob, I asked them to clearly separate router > implementation requirements from operational routing guidelines. > This should help. If I understand what you are asking for, I don't think that this is a good thing to do... The line between routing implementation and routing operation is not well-defined, and where the line is drawn differs based on the type of router and its intended use. For example, it would make sense for a home gateway to include filtering for the ULA address prefix to/from its external port, because home gateways have a well-defined external port, and they generally include a fairly conservative default configuration. However, it would make sense for a router intended for internal enterprise networks _not_ to include a filter for these addresses. While a router intended for enterprise-edge deployment (if there is such a specialized device) could contain a default configuration that filters local addresses at the edge. It is my understanding that carrier-class routers come with very little (if any) default routing configuration and pretty much everything is left to policy. So, I don't think that a hard line exists today between router implementation requirements and operational guidelines, and I don't think that it makes sense to introduce one in this document. Thoughts? Margaret From rtg-dir-bounces@ietf.org Tue Oct 26 10:14:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08177 for ; Tue, 26 Oct 2004 10:14:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSJV-0003sr-7A for rtg-dir-archive@ietf.org; Tue, 26 Oct 2004 10:28:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMS36-0000Ga-UW; Tue, 26 Oct 2004 10:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMS1w-0008CA-Rd; Tue, 26 Oct 2004 10:10:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07726; Tue, 26 Oct 2004 10:10:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSFc-0003on-HN; Tue, 26 Oct 2004 10:24:40 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMS1t-000DSG-98; Tue, 26 Oct 2004 14:10:30 +0000 Date: Tue, 26 Oct 2004 18:10:19 +0400 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <29562923.20041026181019@psg.com> To: Margaret Wasserman In-Reply-To: References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> <13710223733.20041022171219@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: Harald Tveit Alvestrand , Brian Haberman , Bob Hinden , iesg@ietf.org, rtg-dir@ietf.org Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Margaret, Such a hard line does exist and the spec needs to be very clear about what goes where. The implementation requirements define pieces of code that need to be changed or added on _every_ router when ULA support is added. Operational ones define how those pieces or assumed to be already implemented functionality are expected to be configured and used. In your example, a home gateway is a special case of a router with a lot of things configured by default. Every vendor is free to choose the default configuration based on the expected deployment scenarios. This does not change where the line goes. -- Alex http://www.psg.com/~zinin Tuesday, October 26, 2004, 5:45:10 AM, Margaret Wasserman wrote: > Hi Alex, > At 5:12 PM -0700 10/22/04, Alex Zinin wrote: >> In my follow-up with Bob, I asked them to clearly separate router >> implementation requirements from operational routing guidelines. >> This should help. > If I understand what you are asking for, I don't think that this is a > good thing to do... > The line between routing implementation and routing operation is not > well-defined, and where the line is drawn differs based on the type > of router and its intended use. > For example, it would make sense for a home gateway to include > filtering for the ULA address prefix to/from its external port, > because home gateways have a well-defined external port, and they > generally include a fairly conservative default configuration. > However, it would make sense for a router intended for internal > enterprise networks _not_ to include a filter for these addresses. > While a router intended for enterprise-edge deployment (if there is > such a specialized device) could contain a default configuration that > filters local addresses at the edge. It is my understanding that > carrier-class routers come with very little (if any) default routing > configuration and pretty much everything is left to policy. > So, I don't think that a hard line exists today between router > implementation requirements and operational guidelines, and I don't > think that it makes sense to introduce one in this document. > Thoughts? > Margaret From rtg-dir-bounces@ietf.org Tue Oct 26 11:06:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12198 for ; Tue, 26 Oct 2004 11:06:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMT84-0004t2-Gp for rtg-dir-archive@ietf.org; Tue, 26 Oct 2004 11:20:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSlW-0001UK-3c; Tue, 26 Oct 2004 10:57:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMSgu-0007xw-9L; Tue, 26 Oct 2004 10:52:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11132; Tue, 26 Oct 2004 10:52:50 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMSuZ-0004aK-Al; Tue, 26 Oct 2004 11:07:00 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i9QEP4V06912; Tue, 26 Oct 2004 07:25:04 -0700 X-mProtect: <200410261425> Nokia Silicon Valley Messaging Protection Received: from dunira-pool151126.europe.nokia.com (172.25.151.126, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd9IceoA; Tue, 26 Oct 2004 07:25:02 PDT Message-Id: <6.1.2.0.2.20041026072503.060ee120@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 26 Oct 2004 07:51:53 -0700 To: Alex Zinin From: Bob Hinden In-Reply-To: <29562923.20041026181019@psg.com> References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> <13710223733.20041022171219@psg.com> <29562923.20041026181019@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Harald Tveit Alvestrand , Brian Haberman , Bob Hinden , iesg@ietf.org, rtg-dir@ietf.org, Margaret Wasserman Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Alex, At 07:10 AM 10/26/2004, Alex Zinin wrote: >Margaret, > > Such a hard line does exist and the spec needs to be very clear about what > goes where. Could you explain this view? I don't understand this "hard line". > The implementation requirements define pieces of code that need to be > changed > or added on _every_ router when ULA support is added. Operational ones > define > how those pieces or assumed to be already implemented functionality are > expected to be configured and used. I don't think any code is required in an IPv6 router to be implemented to support ULA addresses. Everything in the ULA specification can be done via configuration. [I am assuming the router has the ability to configure source address filters]. Of course, a router vendor could decide to build special support in the code (e.g., to make it easy to turn on ULA filtering on a set of interfaces), or perhaps to add it to an ASIC forwarding engine to get the best filtering performance. But I don't see it as being required and these implementation decisions are a vendor decision. > In your example, a home gateway is a special case of a router with a lot of > things configured by default. Every vendor is free to choose the default > configuration based on the expected deployment scenarios. This does not > change > where the line goes. Please define the line. I don't understand the distinction you are making. Thanks, Bob From rtg-dir-bounces@ietf.org Tue Oct 26 13:40:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27664 for ; Tue, 26 Oct 2004 13:40:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVXJ-0000Wn-LU for rtg-dir-archive@ietf.org; Tue, 26 Oct 2004 13:55:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVDm-0002dI-SI; Tue, 26 Oct 2004 13:34:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMV2y-000823-Oj; Tue, 26 Oct 2004 13:23:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26040; Tue, 26 Oct 2004 13:23:45 -0400 (EDT) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVGf-0008VC-48; Tue, 26 Oct 2004 13:37:58 -0400 Received: from [10.0.0.75] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 180198; Tue, 26 Oct 2004 13:18:07 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <29562923.20041026181019@psg.com> References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> <13710223733.20041022171219@psg.com> <29562923.20041026181019@psg.com> Date: Tue, 26 Oct 2004 13:21:38 -0400 To: Alex Zinin From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Harald Tveit Alvestrand , Brian Haberman , Bob Hinden , iesg@ietf.org, rtg-dir@ietf.org Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi Alex, At 6:10 PM +0400 10/26/04, Alex Zinin wrote: > Such a hard line does exist and the spec needs to be very clear about what > goes where. > > The implementation requirements define pieces of code that need to >be changed > or added on _every_ router when ULA support is added. Operational >ones define > how those pieces or assumed to be already implemented functionality are > expected to be configured and used. If this is the line, then the answer is that ULAs do not introduce any requirements for router implementations. Unlike the previous site-local addresses that required that (at least some) routers be able to be configured as site border routers (SBRs) and required that SBRs maintain separate routing information for multiple overlapping site-local prefixes, ULAs do not introduce any implementation requirements for routers (even the ones on organizational/site boundaries) and will work fine with IPv6 routers that are already deployed. There are some operational requirements for organizations that use these things. They need to decide how far they want the routing information for each local prefix to propagate and should filter routes for these addresses and the packets that are addresses to/from these addresses at those borders. > In your example, a home gateway is a special case of a router with a lot of > things configured by default. Every vendor is free to choose the default > configuration based on the expected deployment scenarios. This >does not change > where the line goes. Makes sense. Sorry for misunderstanding your previous message. Margaret From rtg-dir-bounces@ietf.org Thu Oct 28 07:40:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03240 for ; Thu, 28 Oct 2004 07:40:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN8rw-00075t-6c for rtg-dir-archive@ietf.org; Thu, 28 Oct 2004 07:55:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN8bC-0000jw-Jl; Thu, 28 Oct 2004 07:37:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN8Zm-0008Da-8Y for rtg-dir@megatron.ietf.org; Thu, 28 Oct 2004 07:36:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02669 for ; Thu, 28 Oct 2004 07:36:17 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN8np-000704-7J for rtg-dir@ietf.org; Thu, 28 Oct 2004 07:50:50 -0400 Received: from 83-134-126-184.leuven.goplus.fastdsl.tiscali.be ([83.134.126.184]) by mx2.foretec.com with smtp (Exim 4.24) id 1CN8Zf-0000Vm-0a for rtg-dir@ietf.org; Thu, 28 Oct 2004 07:36:14 -0400 Date: Thu, 28 Oct 2004 15:34:27 +0300 From: "Kazel Gonzalos" To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Score: 4.2 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: Re: please X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.2 (++++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable The collision of the frigate with the cetacean had occurr= ed about eleven o'clock in the evening before!!!=20














discontinue The 3rd of July we were at the opening of the Straits of Magellan, level w= ith Cape Vierges. seen the animal three weeks before in the North Pacific = Ocean!!! We were not a hundred feet from the burning focus, the light of w= hich increased and dazzled our eyes.=20 From rtg-dir-bounces@ietf.org Mon Nov 1 12:32:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06950 for ; Mon, 1 Nov 2004 12:32:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COgHe-00059l-NH for rtg-dir-archive@ietf.org; Mon, 01 Nov 2004 12:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfgS-00027N-08; Mon, 01 Nov 2004 12:09:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLaem-0002vI-Vd for rtg-dir@megatron.ietf.org; Sun, 24 Oct 2004 01:11:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17158 for ; Sun, 24 Oct 2004 01:11:03 -0400 (EDT) Resent-Date: Sun, 24 Oct 2004 01:11:03 -0400 (EDT) Resent-Message-Id: <200410240511.BAA17158@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLarx-0002rq-Ep for rtg-dir@ietf.org; Sun, 24 Oct 2004 01:24:41 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLaeb-000Hpl-L0; Sun, 24 Oct 2004 05:10:54 +0000 Date: Sat, 23 Oct 2004 22:10:49 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <494705102.20041023221049@psg.com> To: Bob Hinden Resent-from: Alex Zinin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 01 Nov 2004 12:09:31 -0500 Cc: hardie@qualcomm.com, Harald Tveit Alvestrand , sah@428cobrajet.net, Thomas Narten , rtg-dir@ietf.org, fenner@research.att.com, Margaret Wasserman , housley@vigilsec.com, Brian Haberman , smb@research.att.com Subject: Re: Responses to IESG Comments on ULA Draft X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7bit [resending with correct rtg-dir alias] Bob, et al- Inline below. > Harald, Steve, Bill, Alex, Scott, Russ, Ted, > Thanks for your comments on this document. > We would like to say that we think approving this document is an important > step in replacing IPv6 site-local addresses. The ULA addresses provide an > improved alternative to site-local and having that alternative will give > people who are currently using site-local something to replace it with. We > think it is very important for the IESG to approve this promptly. I appreciate the sense of urgency. I think we should also agree that this document is significant enough to make sure that it has been reviewed properly by the relevant parts of the community (which is what I consider to be one of the functions of the IESG). Depending on where our discussion goes, it may be necessary to bring this document for further review in the RTG area. I'm cc'ing RTG-DIR for that purpose too. >>Alex Zinin: I read through your answers below, and then reread routing-related parts of the document. I think the source of possible confusion is the fact that implementation requirements and operational guidelines are not properly identified and are mixed together. This is why I'm having a problem understanding whether you mean something should be done by the routers automatically or you expect routers to be configured to do that. I think this section needs to be rewritten with this distinction in mind, probably separating the two aspects in subsections. >>Discuss: >>1. It would be useful to give a definition of a "site", keeping the routing >> aspects in mind. >> >>2. Section 4 "Routing" >> >> > Any router that is used between sites must be configured to filter >> > out any incoming or outgoing Local IPv6 unicast routes. The >> > exception to this is if specific /48 or longer IPv6 local unicast >> > routes have been configured to allow for inter-site communication. >> >> > If BGP is being used at the site border with an ISP, the default BGP >> > configuration must be set to to keep any Local IPv6 address prefixes >> > from being advertised outside of the site or for these prefixes to be >> > learned from another site. The exception to this is if there are >> > specific /48 or longer routes created for one or more Local IPv6 >> > prefixes. >> >>In the above statement, is it assumed that BGP has visibility to site >>boundaries, or that it is always used for inter-site connectivity and >>never for >>intra-site? The reason for the question is that requiring default BGP behavior >>to be as described above calls for site awareness and implementation >>change. If >>the real intention is that BGP should be _manually_ _configured_ to filter out >>local prefixes, the text needs to be changed. > We mean that BGP should be _manually_ _configured_. It was not the intent > to require the BGP protocol to change. Does the revision of this paragraph > earlier in the email resolve the issue? If not, please suggest changes. Here's Ted's proposed text: > If BGP is being used at the site border with an ISP, the default > BGP configuration must filter out any Local IPv6 address prefixes, > both incoming and outgoing. It must be set both to keep any Local > IPv6 address prefixes from being advertised outside of the site as > well as to keep these prefixes from being learned from another > site. The exception to this is if there are specific /48 or longer > routes created for one or more Local IPv6 prefixes. I don't think this change alone is enough. I would prefer to see operational routing guidelines separated out and this part moved there. I also would like to understand what the exception described in the last sentence really means. >>It should be noted that if an link state IGP (OSPF/IS-IS) is used for routing >>between sites, which is a possibility in enterprise networks, a single site >>should be contained within a single IGP domain or area, as prefix distribution >>within a link-state area cannot be controlled. > Good point. We propose to add the following text: > For link-state IGPs, it is recommended that a site utilizing ULA > prefixes be contained either within one IGP domain or area. By > containing a ULA prefix to a single link-state area or domain, the > distribution of prefixes can be controlled. This would be good to put in the operational guidelines subsection. >>Section 6.0 >> >> > Site border routers should install a "reject" route for the Local >> > IPv6 prefix FC00::/7. This will ensure that packets with Local IPv6 >> > destination addresses will not be forwarded outside of the site via a >> > default route. Site border routers should respond with the >> > appropriate ICMPv6 Destination Unreachable message to inform the >> > source that the packet was not forwarded [ICMPV6]. This feedback is >> > important to avoid transport protocol timeouts. >> > >> > Site border routers and firewalls should not forward any packets with >> > Local IPv6 source or destination addresses outside of the site unless >> > they have been explicitly configured with routing information about >> > specific /48 or longer Local IPv6 prefixes. The default behavior of >> > these devices should be to install a "reject" route for these >> > prefixes. Site border routers should respond with the appropriate >> > ICMPv6 Destination Unreachable message to inform the source that the >> > packet was not forwarded. >> >>There's an overlap between the two paras above. The first para covers the >>destination address check. The second tries to cover both destination and >>source. > Yes, That is intentional. >>First, I'd like to understand exactly what "outside of the site" means in this >>section. Does it mean a non-FC00::/7 IPv6 dst address, or a FC00::/7 address >>with another global-ID, or both? > It means both. >>Second, do you realize that checking the source address will require >>changes to >>the router's forwarding algorithm compared to how global addresses are >>handled? > There are various other places in IPv6 where routers are required to check > source addresses. Specifically for link-local addresses and for site-local > (deprecated). I would argue that the link-local case is quite different from what you describe above, and the check for site-locals was one piece of complexity that we wanted to avoid. On the whole thing above though, you should be very specific on what you would like to be implemented in the router code (i.e. done automatically) and what you expect/recommend to be configured by default using e.g. static routes and ACLs. Depending on the answer certain things may become [un]feasible and/or some additional details will have to be specified. >>Third, it is a current operational practice to disable ICMP unreachables for >>reject routes to avoid ICMP storms cause by infected machines' scanning the >>network. I suggest we change it to something like "MAY send, MUST be >>configurable, and MUST be off by default". > We believe that is it is very difficult (or perhaps impossible) to do the > kind of address scanning with IPv6 that can easily be done with > IPv4. Since most nodes have addresses that are created with 64-bit > interface identifiers that are derived from L2 MAC addresses, it is a very > sparse space. In other words it would take a very long time to scan 2^^64 > possible addresses in a specific /64 prefix. This makes it harder (impossible) to find another host that can be infected, but doesn't prevent using routers as "icmp generators", since one needs to hit an address that does NOT exist for an unreachable to be sent. > In addition, ICMPv6 includes mechanisms to limit the sending of ICMP error > messages. we have this in IPv4 implementations too, yet the problem is there > The IPv6 scoped addressing architecture specifies the use of destination > unreachable when addresses are out of scope. We belive this is a useful > hint to a nodes address selection algorithm. I overlooked this in the arch draft, unfortunately--mere human :) >> From rtg-dir (Radia): >> >>The document should be more clear about what the desired behavior is for the >>case where two or more sites are connected together. > This is a reasonable idea, but we think it is outside of the scope of this > document. This might well be a good topic for V6OPS to take on. Well, this does affect evaluation of the proposed mechanisms, though. In other words, we can't assess whether proposed mechanism & operational practices are correct or advisable unless we know what you're trying to achieve. Alex From rtg-dir-bounces@ietf.org Mon Nov 1 13:44:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16907 for ; Mon, 1 Nov 2004 13:44:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhP6-00081Y-Fj for rtg-dir-archive@ietf.org; Mon, 01 Nov 2004 13:59:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COgp5-0007ns-Nl; Mon, 01 Nov 2004 13:22:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COgXz-0004v1-Fa; Mon, 01 Nov 2004 13:04:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10911; Mon, 1 Nov 2004 13:04:49 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COgmt-0006DL-DG; Mon, 01 Nov 2004 13:20:18 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COgXt-0003EJ-Nk; Mon, 01 Nov 2004 18:04:45 +0000 Date: Sat, 30 Oct 2004 09:43:35 +0400 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <484857974.20041030094335@psg.com> To: Margaret Wasserman In-Reply-To: References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> <13710223733.20041022171219@psg.com> <29562923.20041026181019@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Harald Tveit Alvestrand , Brian Haberman , Bob Hinden , iesg@ietf.org, rtg-dir@ietf.org Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Margaret, Yes, this makes sense to me. As I asked in my message to Bob, can we change the text in the draft accordingly? Thanks. -- Alex http://www.psg.com/~zinin Tuesday, October 26, 2004, 9:21:38 PM, Margaret Wasserman wrote: > Hi Alex, > At 6:10 PM +0400 10/26/04, Alex Zinin wrote: >> Such a hard line does exist and the spec needs to be very clear about what >> goes where. >> >> The implementation requirements define pieces of code that need to >>be changed >> or added on _every_ router when ULA support is added. Operational >>ones define >> how those pieces or assumed to be already implemented functionality are >> expected to be configured and used. > If this is the line, then the answer is that ULAs do not introduce > any requirements for router implementations. > Unlike the previous site-local addresses that required that (at least > some) routers be able to be configured as site border routers (SBRs) > and required that SBRs maintain separate routing information for > multiple overlapping site-local prefixes, ULAs do not introduce any > implementation requirements for routers (even the ones on > organizational/site boundaries) and will work fine with IPv6 routers > that are already deployed. > There are some operational requirements for organizations that use > these things. They need to decide how far they want the routing > information for each local prefix to propagate and should filter > routes for these addresses and the packets that are addresses to/from > these addresses at those borders. >> In your example, a home gateway is a special case of a router with a lot of >> things configured by default. Every vendor is free to choose the default >> configuration based on the expected deployment scenarios. This >>does not change >> where the line goes. > Makes sense. Sorry for misunderstanding your previous message. > Margaret From rtg-dir-bounces@ietf.org Mon Nov 1 13:44:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16941 for ; Mon, 1 Nov 2004 13:44:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhPO-00082N-NP for rtg-dir-archive@ietf.org; Mon, 01 Nov 2004 14:00:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COgp6-0007o6-3v; Mon, 01 Nov 2004 13:22:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COgY0-0004v3-B1; Mon, 01 Nov 2004 13:04:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10914; Mon, 1 Nov 2004 13:04:50 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COgmu-0006DP-89; Mon, 01 Nov 2004 13:20:19 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COgXt-0003EJ-0a; Mon, 01 Nov 2004 18:04:45 +0000 Date: Sat, 30 Oct 2004 09:42:07 +0400 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <61800948.20041030094207@psg.com> To: Bob Hinden In-Reply-To: <6.1.2.0.2.20041026072503.060ee120@mailhost.iprg.nokia.com> References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> <13710223733.20041022171219@psg.com> <29562923.20041026181019@psg.com> <6.1.2.0.2.20041026072503.060ee120@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Harald Tveit Alvestrand , Brian Haberman , iesg@ietf.org, rtg-dir@ietf.org Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Bob, >> Such a hard line does exist and the spec needs to be very clear about what >> goes where. > Could you explain this view? I don't understand this "hard line". Sure. As I tried to explain, if all routers are supposed to do something automatically once a ULA is configured without any additional configuration from the administrator, such functionality would fall into router implementation requirements category. For instance, if you wanted the site border routers to automatically start filtering out packets using ULAs and crossing the site border as part of the standard forwarding function (as described in the addressing architecture document, for example), we would need to go several steps further and think about what exactly a site is, and how routers are supposed to know when a packet is leaving a site (e.g. per-interface site knowledge, with checks during pkt fwd'ing). The same is applicable to the routing part--if you wanted site border routers to automatically filter out routes between sites, we would need to think about the same sort of things as above, how they work together, and how that works with routing protocols. Operational requirements give guidelines to administrator about how to configure routers when the technology is deployed. For instance, we could suggest that "site border routers should be configured with access lists (packet filters) disallowing packets that use ULAs as the source or destination addresses to cross the boundary of a site". >> The implementation requirements define pieces of code that need to be >> changed >> or added on _every_ router when ULA support is added. Operational ones >> define >> how those pieces or assumed to be already implemented functionality are >> expected to be configured and used. > I don't think any code is required in an IPv6 router to be implemented to > support ULA addresses. Everything in the ULA specification can be done via > configuration. [I am assuming the router has the ability to configure > source address filters]. Can we change the text to be clearer that normal routing and forwarding functionality is not changed and that these are configuration/operational guidelines? > Of course, a router vendor could decide to build > special support in the code (e.g., to make it easy to turn on ULA filtering > on a set of interfaces), or perhaps to add it to an ASIC forwarding engine > to get the best filtering performance. But I don't see it as being > required and these implementation decisions are a vendor decision. Of course. Alex From rtg-dir-bounces@ietf.org Mon Nov 1 15:17:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25932 for ; Mon, 1 Nov 2004 15:17:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COiqz-0001nB-It for rtg-dir-archive@ietf.org; Mon, 01 Nov 2004 15:32:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COiAu-0003qt-Li; Mon, 01 Nov 2004 14:49:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COi1K-0006oj-2v; Mon, 01 Nov 2004 14:39:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21495; Mon, 1 Nov 2004 14:39:11 -0500 (EST) Received: from mail.thingmagic.com ([207.31.248.245] helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COiGI-0000pI-1e; Mon, 01 Nov 2004 14:54:42 -0500 Received: from [10.0.0.75] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 184225; Mon, 01 Nov 2004 14:33:31 -0500 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <484857974.20041030094335@psg.com> References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> <13710223733.20041022171219@psg.com> <29562923.20041026181019@psg.com> <484857974.20041030094335@psg.com> Date: Mon, 1 Nov 2004 14:36:45 -0500 To: Alex Zinin From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Harald Tveit Alvestrand , Brian Haberman , Bob Hinden , iesg@ietf.org, rtg-dir@ietf.org Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Yes, I think that we could change the text to make this clearer. I'll let Bob make specific suggestions. Margaret At 9:43 AM +0400 10/30/04, Alex Zinin wrote: >Margaret, > > Yes, this makes sense to me. As I asked in my message to Bob, can we change > the text in the draft accordingly? > > Thanks. > >-- >Alex >http://www.psg.com/~zinin > >Tuesday, October 26, 2004, 9:21:38 PM, Margaret Wasserman wrote: > >> Hi Alex, > >> At 6:10 PM +0400 10/26/04, Alex Zinin wrote: >>> Such a hard line does exist and the spec needs to be very clear >>>about what >>> goes where. >>> >>> The implementation requirements define pieces of code that need to >>>be changed >>> or added on _every_ router when ULA support is added. Operational >>>ones define >>> how those pieces or assumed to be already implemented functionality are >>> expected to be configured and used. > >> If this is the line, then the answer is that ULAs do not introduce >> any requirements for router implementations. > >> Unlike the previous site-local addresses that required that (at least >> some) routers be able to be configured as site border routers (SBRs) >> and required that SBRs maintain separate routing information for >> multiple overlapping site-local prefixes, ULAs do not introduce any >> implementation requirements for routers (even the ones on >> organizational/site boundaries) and will work fine with IPv6 routers >> that are already deployed. > >> There are some operational requirements for organizations that use >> these things. They need to decide how far they want the routing >> information for each local prefix to propagate and should filter >> routes for these addresses and the packets that are addresses to/from >> these addresses at those borders. > >>> In your example, a home gateway is a special case of a router >>>with a lot of >>> things configured by default. Every vendor is free to choose the default >>> configuration based on the expected deployment scenarios. This >>>does not change >>> where the line goes. > >> Makes sense. Sorry for misunderstanding your previous message. > >> Margaret From rtg-dir-bounces@ietf.org Mon Nov 1 18:15:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19159 for ; Mon, 1 Nov 2004 18:15:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COlda-00086d-MW for rtg-dir-archive@ietf.org; Mon, 01 Nov 2004 18:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COlAi-0001RW-2C; Mon, 01 Nov 2004 18:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COkit-00058r-HP; Mon, 01 Nov 2004 17:32:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14087; Mon, 1 Nov 2004 17:32:21 -0500 (EST) Received: from rhhe7-148.2wcm.comporium.net ([204.116.8.148]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1COkxp-0006p1-34; Mon, 01 Nov 2004 17:47:52 -0500 X-Message-Info: 263lmTWtuFHC8VdJQI36T210VFKfBZTqdELQbnVhhp9JXK Received: from btinternet.com (75.33.32.30) by kad1-o162.btinternet.com with Microsoft SMTPSVC(1.3.3755.5884); Tue, 02 Nov 2004 02:30:22 +0400 Received: from btinternet.com (btinternet.com 15.212.0.7) by btinternet.com (8.12.10/8.12.9) with ESMTP id mwj3VVBNHCD017 for ; Mon, 01 Nov 2004 20:32:22 -0200 (EST) (envelope-from owmwyzco@greenapple.com) Received: from OAC30089943754061 (modemcable7.7922-320.ftj.btinternet.com 97.46.36.80) (authenticated bits=0) by btinternet.com (8.12.10/8.12.9) with ESMTP id o9JTB5o976 for ; Mon, 01 Nov 2004 19:33:22 -0300 (EST) (envelope-from owmwyzco@greenapple.com) Message-ID: <2xu593tp85$x4hxa08m008$77riw9sg52@QH5941406264> From: "Affordable pharmaceuticals.." To: Date: Tue, 02 Nov 2004 02:32:22 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--26438757926048416" X-Spam-Score: 4.6 (++++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Subject: DiscountV1agkra X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 ----26438757926048416 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Hello, SAVE YOUR HEALTH & YOUR MONEY =93How we Save You 20% or more on Reliable Medication?=94 http://www.dkabsaodofk.info/30/ If you need high quality medication and would love to save on outrageous r= etail pricing, then CanadianPharmacy is for you. Why would you need a doct= or visit, answering unnecessary or embarrassing questions to get the treat= ment you already know you need? You don=92t =96 and shopping online saves you from this formality that ends up costing you= a lot of money. However, you should know that our online shop is never a = substitute for a doctor consultation, if you=92re not sure what medication= you need, consult a physician first. But if you already know what you need, why pay more? Shopping with Canadia= nPharmacy allows you to get high quality medication and save money on reta= il, without compromising your health and safety. That=92s a kind of trust = and reliability that few other online pharmacies can match =96 if any at a= ll. http://www.dkabsaodofk.info/30/ Would you trust your health with a shady offshore company to save a couple= of extra bucks? Of course not, but thousands just like you are doing exac= tly that. CanadianPharmacy allows you to safely shop at incredible discounts =96 we = don=92t pay retail thanks to our distributors, and neither should you. Com= bined with the cheaper Canadian Currency, this means you save big =96 real= ly big =96 on medication. And best of all, your order reaches you in just 5 to 7 business days, inst= ead of waiting weeks for your Doctor appointment and prescription. Big Savings without Big Risks http://www.dkabsaodofk.info/30/ Finally, you have access to the medication you need without being cheated = out of your money by the Pharmaceutical industry=92s artificial high prici= ng. Be smart and use the Internet=92s competitive edge to get a great deal= on medication from a trusted pharmacy close to home. Regards Bennie Doherty http://www.dkabsaodofk.info/30/ =93I am feeling great and losing inches thanks to meridia =96 and I can=92= t believe how much this is saving me compared to what I spent when I bough= t my first bottle retail. Thanks=94 Walter G.,v Baron, Wi Not Interested? http://www.dbajoweor.info/bye/30/ ------------------------------------------- plunk africa wastage lebensraum rothschild divulge burgeon exorcise bulkhe= ad yardstick foulmouth cholinesterase craftspeople seoul sora helene smirk= cohosh sixteen tuscan apocrypha pompeii knudsen typewrite herpes forsook = insignificant tacoma bushel advocacy ascend duel pee philology emeritus bl= ight mimicked brigadier cool credulity couldn't dazzle accompany sharecrop= payoff spectrometer astronomy memento tolstoy babe alpert symphonic dross= layup haze dioxide shadowy ellwood traumatic polysaccharide champaign mcc= lure bassinet bogus niacin volvo aquarius familism algaecide bran clone barricade merrill elude athlete midshipman corpus discrete rena= ult serbia mantel kola bladdernut bungalow bed soapstone suppression nutme= g emerald transalpine tulle abstractor geology cupboard paddock ruben tild= e brucellosis shaffer minstrel inspect continuous halstead axes tweeze top= coat decorous courtesy ergative ascension pollard byrne stenography goat c= rocus kodak blackberry desire bichromate playboy siena esther interpolate = alcohol barrington chartroom hemolytic durer wolcott noisy eyeful abalone = jimmie lucian muff nosebag luke reef o's distributor desiderata cutler per= vade cried irreversible algiers sandburg agatha aileen immobile configuration sikorsky sri everyday clan obey myocardium a= rmour slate hough xylem tilde funny bleat hawthorne bat compellable prostr= ate underling cyprian careful for moulton ligature incur morrissey blest s= erviceable ben current rostrum phosphor abeyant transmitted perth conseque= ntial protestation smythe arboretum exportation yourselves inalienable har= ness leathery christoph dryad alabaster brassy diffident melodramatic impa= sse wyner nearby butternut scimitar coniferous crew barrymore reconcile au= tocratic crosscut ghostly stead usher acuity amphibious bricklay ga boggin= g flatworm pestle hal d'art eyewitness decennial chromatograph arizona can= tabrigian digest interject demultiplex cosgrove posthumous begonia emilio = pony burnside aryl greene incondensable mane prothonotary trilobite typhoi= d confute ama barr semantic lomb hieronymus dead conspiratorial leitmotiv = montclair thrall bart parole spear ferry onto temptation elaine haitian hi= nes irremovable absorption canis improbable cucumber formic diva abstinent= butler pamphlet striven della alkane daniel braggart storey treason corri= dor trodden ----26438757926048416-- From rtg-dir-bounces@ietf.org Tue Nov 2 20:50:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13579 for ; Tue, 2 Nov 2004 20:50:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPAXZ-0005MM-EP for rtg-dir-archive@ietf.org; Tue, 02 Nov 2004 21:06:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPAE8-0006Fl-5s; Tue, 02 Nov 2004 20:46:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPA7d-0002yn-Cw for rtg-dir@megatron.ietf.org; Tue, 02 Nov 2004 20:39:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12925 for ; Tue, 2 Nov 2004 20:39:35 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPAMq-00057c-TC for rtg-dir@ietf.org; Tue, 02 Nov 2004 20:55:21 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPA7b-00044a-CE; Wed, 03 Nov 2004 01:39:35 +0000 Date: Tue, 2 Nov 2004 17:39:33 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <542324576.20041102173933@psg.com> To: dimitri papadimitriou , Loa Andersson In-Reply-To: <41698632.9070702@psg.com> References: <45276693.20040929143130@psg.com> <41698632.9070702@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: rtg-dir review: dpapadimitriou, prz: draft-ietf-mpls-oam-requirements-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: 7bit Thanks a lot Dimitri! -- Alex http://www.psg.com/~zinin Sunday, October 10, 2004, 10:57:54 AM, dimitri papadimitriou wrote: > hi alex, you will find here below my comments on the above referenced > document 1) Technical and 2) Editorial - see below: > 1) Technical > ------------ > 0. Section 3 > "This leads to inconsistent and inefficient applicability across the > MPLS architecture, and/or requires significant modifications to > operational procedures and systems in order to provide consistent > and useful OAM functionality." ->> How to ensure that the proposed OAM techniques will not create more > inconsistencies than those apparently occurring with the existing ad hoc > methods/solutions (those that are not currently part of the proposed > framework) - as a matter of fact these techniques are already deployed ? > 1. Section 4.1 > Distinction between failure and defect is not clearly reflected, it is > therefore difficult to understand the requirement behind detection of a > "broken LSP" > 2. Section 4.1 > In the sentence "... this function SHOULD be automated and performed > from the origination of that LSP." does not say until which point this > operation has to be performed > 3. Section 4.1 > The sentence "As an example of a false positive, consider the case where > the MPLS data plane flows through a network node using a different > output line card than the data plane does to each the next neighbor." is > mispelled which understanding of the false positive difficult as per > [LSP-PING] "MPLS echo request are sent along the same data path as other > packets belonging to this FEC. An MPLS echo request also carries > information about the FEC whose MPLS path is being verified. This echo > request is forwarded just like any other packet belonging to that FEC. > In "ping" mode (basic connectivity check), the packet should reach the > end of the path, at which point it is sent to the control plane of the > egress LSR, which then verifies whether it is indeed an egress for the FEC." > 4. Section 4.1 > Is there any specific requirement for the return path of unidirectional > LSPs to avoid "false negative" ? as this is not explicitly mentioned as > part of this section > 5. Section 4.2 > The sentence "... and any mid-point LSR" does not specify what has to be > traced inlight with the above statement "Diagnosis of defects and > isolation of the failed component is best accomplished via a path trace > function which can return the the entire list of LSRs and links used by > a certain LSP (or at least the set of LSRs/links up to the location of > the defect) is required." > 6. Section 4.3 > Second bullet mentions "externally visible aspects" and then points to > "specific algorithms" - the term "externally visible" should thus refer > to what "external" refers to ? > 7. Section 4.4 > This section dedicated to "performance measurement" requires more > specific i.e. more formal definition of LSP availability (than "service > is considered to be available") > There is no specific reference to the "one-hop delay" experienced by > labeled packets (that included the switching delay and the transmission > delay) and "queuing/buffering delay" creates variation in the delay > experienced by labeled packets - more accurate definitions could thus be > provided to describe the exact OAM&P mechanism to be supported (example > there are several methods to take the jitter into account) > In the sentence "... so as to accurately reflect the latency ..." what > is the expected measurement accuracy expected as part of the present > requirements ? > 8. Section 4.5 > The following sentence "The capability to synchronize OAM operations is > desired as to permit consistent measurement of service level > agreements." should be more prescriptive than "is desired" does it mean > optional and this synchronization is not available how it impacts the > overall OAM operations > 9. Section 4.5 (Alarm Suppression) > To what the term "device" is referring here ? The relationship between > the reduction of the "emitted notifications" and the "fault > notifications" flowing to the LSP egress is not described ? > 10. Section 4.7 > This section does not detail what is the object of the failure and the > subject of the recovery ? nor the scope of the requirement - does it > apply on inter-provider basis (ingress and egress belonging to separate > networks) > 2) Editorial > ------------ > 0. As the document has less than 15/20 pages a ToC is not required but > if one ToC is included suggestion is made to complete it with sub-sections > 1. Section 2. > This section should better be split into a "Terminology" section that > includes conceptual overview of the terms used in the document (some > of them can be more accurately defined as part of the document) and a > "Abbreviation and Acronyms" section > 2. Section 2. > The term "head-end LSR" is introduced but the core of the document make > use of the terms "ingress LSR" are these equivalent ? or different ? ->> suggestion is made (if they are equivalent) to use a single > terminology either ingress/egress LSR or head-end/tail-end LSR > 3. Section 3. > Spell out acronyms RSVP (isn't RVSP-TE ?) and LDP > 4. Section 4.1 > The term "path liveliness" has not been defined in Section 2/referenced > The term "LSP problem" has not been defined in Section 2/referenced > 5. Section 4.1 > Add reference to ICMP-based Ping > 6. Section 4.2 > Sentence "The tracing capability SHOULD include the ability to trace > recursive paths, such as when nested LSPs are used, or when LSPs enter > and exit traffic-engineered tunnels" is the latter case not covered by > the previous one ? > 7. Section 4.3 > Is the first bullet (TTL models) meant to address RFC 3443 - in this > case suggestion is made to add this RFC as reference > what the "data/control plane OAM capabilities" means ? this would > clarify the scope of the sentence > 8. Section 4.4 > suggestion is made to clarify the sentence "measure the qualitative > aspects of OAM probing" and define the term "OAM probing" > 9. Section 4.5 numbering appears twice > 10. Section 4.6 > Spell out AIS acronym and include as part of the "Abbreviation" section > 11. Section 4.9 > Include DoS acronym as part of the "Abbreviation" section > "control planes" instead of "control plaes" > 12. Section 4.10 > Include SP acronym as part of the "Abbreviation" section > "information" instead of "informationr" > "inter-AS" instead of "inter-as" > 13. Section 4.10.1 > "For example, the LSR might ..." is meant for "For example, the LSR MAY > ..." ? > what the etc. stands for that other methods exist or what's described is > only part of the process ? > --- > Alex Zinin wrote: >> Loa asked me for an early rtg-dir review of this draft. >> >> skill-specific: dimitri >> round-robin: tony >> >> http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-requirements-04.txt >> >> >>> Title : OAM Requirements for MPLS Networks >>> Author(s) : T. Nadeau, et al. >>> Filename : draft-ietf-mpls-oam-requirements-04.txt >>> Pages : 13 >>> Date : 2004-9-2 >>> >>>As transport of diverse traffic types such as voice, frame >>> relay, and ATM over MPLS become more common, the ability to detect, >>> handle and diagnose control and data plane defects becomes >>> critical. >>> >>> Detection and specification of how to handle those defects is not >>> only important because such defects may not only affect the >>> fundamental operation of an Multi-Protocol Label Switching network, >>> but also because they MAY impact service level specification >>> commitments for customers of that network. >> >> From rtg-dir-bounces@ietf.org Fri Nov 5 04:00:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17681 for ; Fri, 5 Nov 2004 04:00:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0Cs-0005K3-81 for rtg-dir-archive@ietf.org; Fri, 05 Nov 2004 04:16:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPzrz-0001Fk-Tz; Fri, 05 Nov 2004 03:54:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPzqJ-00010r-As; Fri, 05 Nov 2004 03:53:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17184; Fri, 5 Nov 2004 03:53:09 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ060-0005BY-NV; Fri, 05 Nov 2004 04:09:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iA58Ox214644; Fri, 5 Nov 2004 00:24:59 -0800 X-mProtect: <200411050824> Nokia Silicon Valley Messaging Protection Received: from dadhcp-172019069085.americas.nokia.com (172.19.69.85, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdcPBEcN; Thu, 04 Nov 2004 16:43:02 PST Message-Id: <6.1.2.0.2.20041104161903.020ba7a0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 04 Nov 2004 17:10:22 -0800 To: Alex Zinin From: Bob Hinden In-Reply-To: <61800948.20041030094207@psg.com> References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> <13710223733.20041022171219@psg.com> <29562923.20041026181019@psg.com> <6.1.2.0.2.20041026072503.060ee120@mailhost.iprg.nokia.com> <61800948.20041030094207@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Harald Tveit Alvestrand , Brian Haberman , Bob Hinden , iesg@ietf.org, rtg-dir@ietf.org, Margaret Wasserman Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Alex, >Sure. As I tried to explain, if all routers are supposed to do something >automatically once a ULA is configured without any additional >configuration from >the administrator, such functionality would fall into router implementation >requirements category. For instance, if you wanted the site border routers to >automatically start filtering out packets using ULAs and crossing the site >border as part of the standard forwarding function (as described in the >addressing architecture document, for example), we would need to go several >steps further and think about what exactly a site is, and how routers are >supposed to know when a packet is leaving a site (e.g. per-interface site >knowledge, with checks during pkt fwd'ing). The same is applicable to the >routing part--if you wanted site border routers to automatically filter out >routes between sites, we would need to think about the same sort of things as >above, how they work together, and how that works with routing protocols. OK that makes sense. Since ULAs do not require code changes, I think we can change the text to make it clearer that we are describing operational guidelines. Had we defined ULAs to, for example, not use longest match prefix lookups, then there would be a big impact on router functionality. But, of course, we didn't do that :-) >Operational requirements give guidelines to administrator about how to >configure >routers when the technology is deployed. For instance, we could suggest that >"site border routers should be configured with access lists (packet filters) >disallowing packets that use ULAs as the source or destination addresses to >cross the boundary of a site". > > >> The implementation requirements define pieces of code that need to be > >> changed > >> or added on _every_ router when ULA support is added. Operational ones > >> define > >> how those pieces or assumed to be already implemented functionality are > >> expected to be configured and used. > > > I don't think any code is required in an IPv6 router to be implemented to > > support ULA addresses. Everything in the ULA specification can be done > via > > configuration. [I am assuming the router has the ability to configure > > source address filters]. > >Can we change the text to be clearer that normal routing and forwarding >functionality is not changed and that these are configuration/operational >guidelines? Yes, that is very doable. How about the following: Adding a new section 4, titled "Operational Guidelines" and then make current sections 4-10 be subsections. For example: 4.0 Operational Guidelines 4.1 Routing.........................................................7 4.2 Renumbering and Site Merging....................................8 4.3 Site Border Router and Firewall Packet Filtering................8 4.4 DNS Issues......................................................9 4.5 Application and Higher Level Protocol Issues....................9 4.6 Use of Local IPv6 Addresses for Local Communications............9 4.7 Use of Local IPv6 Addresses with VPNs..........................10 Then add the following text between 4.0 and 4.1: The guidelines in this section do not require any change to the normal routing and forwarding functionality in an IPv6 host or router. These are configuration and operational usage guidelines. In addition, I think there are few places in the text in these sections where "should be configured" could be added to make this clearer. > > Of course, a router vendor could decide to build > > special support in the code (e.g., to make it easy to turn on ULA > filtering > > on a set of interfaces), or perhaps to add it to an ASIC forwarding engine > > to get the best filtering performance. But I don't see it as being > > required and these implementation decisions are a vendor decision. > >Of course. Please let us know what you think. Bob From rtg-dir-bounces@ietf.org Sat Nov 6 04:13:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24421 for ; Sat, 6 Nov 2004 04:13:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQMdR-0002cU-K0 for rtg-dir-archive@ietf.org; Sat, 06 Nov 2004 04:13:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQMPF-0008TP-Hm; Sat, 06 Nov 2004 03:58:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQMKb-0007ca-SU; Sat, 06 Nov 2004 03:53:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23268; Sat, 6 Nov 2004 03:53:55 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQMKh-0002Ae-H7; Sat, 06 Nov 2004 03:54:03 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CQMKS-000MYE-Vf; Sat, 06 Nov 2004 08:53:49 +0000 Date: Sat, 6 Nov 2004 00:53:44 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1610636556.20041106005344@psg.com> To: Bob Hinden In-Reply-To: <6.1.2.0.2.20041104161903.020ba7a0@mailhost.iprg.nokia.com> References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> <13710223733.20041022171219@psg.com> <29562923.20041026181019@psg.com> <6.1.2.0.2.20041026072503.060ee120@mailhost.iprg.nokia.com> <61800948.20041030094207@psg.com> <6.1.2.0.2.20041104161903.020ba7a0@mailhost.iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Harald Tveit Alvestrand , Brian Haberman , iesg@ietf.org, rtg-dir@ietf.org Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Bob, I think we're completely in sync. Changes you suggest below would address my concerns. Thanks! -- Alex http://www.psg.com/~zinin Thursday, November 4, 2004, 5:10:22 PM, Bob Hinden wrote: > Alex, >>Sure. As I tried to explain, if all routers are supposed to do something >>automatically once a ULA is configured without any additional >>configuration from >>the administrator, such functionality would fall into router implementation >>requirements category. For instance, if you wanted the site border routers to >>automatically start filtering out packets using ULAs and crossing the site >>border as part of the standard forwarding function (as described in the >>addressing architecture document, for example), we would need to go several >>steps further and think about what exactly a site is, and how routers are >>supposed to know when a packet is leaving a site (e.g. per-interface site >>knowledge, with checks during pkt fwd'ing). The same is applicable to the >>routing part--if you wanted site border routers to automatically filter out >>routes between sites, we would need to think about the same sort of things as >>above, how they work together, and how that works with routing protocols. > OK that makes sense. Since ULAs do not require code changes, I think we > can change the text to make it clearer that we are describing operational > guidelines. > Had we defined ULAs to, for example, not use longest match prefix lookups, > then there would be a big impact on router functionality. But, of course, > we didn't do that :-) >>Operational requirements give guidelines to administrator about how to >>configure >>routers when the technology is deployed. For instance, we could suggest that >>"site border routers should be configured with access lists (packet filters) >>disallowing packets that use ULAs as the source or destination addresses to >>cross the boundary of a site". >> >> >> The implementation requirements define pieces of code that need to be >> >> changed >> >> or added on _every_ router when ULA support is added. Operational ones >> >> define >> >> how those pieces or assumed to be already implemented functionality are >> >> expected to be configured and used. >> >> > I don't think any code is required in an IPv6 router to be implemented to >> > support ULA addresses. Everything in the ULA specification can be done >> via >> > configuration. [I am assuming the router has the ability to configure >> > source address filters]. >> >>Can we change the text to be clearer that normal routing and forwarding >>functionality is not changed and that these are configuration/operational >>guidelines? > Yes, that is very doable. How about the following: > Adding a new section 4, titled "Operational Guidelines" and then make > current sections 4-10 be subsections. For example: > 4.0 Operational Guidelines > 4.1 Routing.........................................................7 > 4.2 Renumbering and Site Merging....................................8 > 4.3 Site Border Router and Firewall Packet Filtering................8 > 4.4 DNS Issues......................................................9 > 4.5 Application and Higher Level Protocol Issues....................9 > 4.6 Use of Local IPv6 Addresses for Local Communications............9 > 4.7 Use of Local IPv6 Addresses with VPNs..........................10 > Then add the following text between 4.0 and 4.1: > The guidelines in this section do not require any change to the > normal routing and forwarding functionality in an IPv6 host or > router. These > are configuration and operational usage guidelines. > In addition, I think there are few places in the text in these sections > where "should be configured" could be added to make this clearer. >> > Of course, a router vendor could decide to build >> > special support in the code (e.g., to make it easy to turn on ULA >> filtering >> > on a set of interfaces), or perhaps to add it to an ASIC forwarding engine >> > to get the best filtering performance. But I don't see it as being >> > required and these implementation decisions are a vendor decision. >> >>Of course. > Please let us know what you think. > Bob From rtg-dir-bounces@ietf.org Sun Nov 7 10:55:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28809 for ; Sun, 7 Nov 2004 10:55:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpOS-0005iB-I0 for rtg-dir-archive@ietf.org; Sun, 07 Nov 2004 10:55:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpI3-0007Nx-Ih; Sun, 07 Nov 2004 10:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQpFz-0006so-Ak; Sun, 07 Nov 2004 10:47:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28183; Sun, 7 Nov 2004 10:47:04 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQpGL-0005VI-FJ; Sun, 07 Nov 2004 10:47:29 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iA7FIo308808; Sun, 7 Nov 2004 07:18:50 -0800 X-mProtect: <200411071518> Nokia Silicon Valley Messaging Protection Received: from danira-pool048194.americas.nokia.com (10.241.48.194, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdek5wuG; Sun, 07 Nov 2004 07:18:47 PST Message-Id: <6.1.2.0.2.20041107074356.050ea768@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 07 Nov 2004 07:45:52 -0800 To: Alex Zinin From: Bob Hinden In-Reply-To: <1610636556.20041106005344@psg.com> References: <48401718.20041013184657@psg.com> <310BF70DE4EFE19809BDFD6F@askvoll.hjemme.alvestrand.no> <569279333.20041020161550@psg.com> <503160063FDFB49D0E6E96B9@askvoll.hjemme.alvestrand.no> <13710223733.20041022171219@psg.com> <29562923.20041026181019@psg.com> <6.1.2.0.2.20041026072503.060ee120@mailhost.iprg.nokia.com> <61800948.20041030094207@psg.com> <6.1.2.0.2.20041104161903.020ba7a0@mailhost.iprg.nokia.com> <1610636556.20041106005344@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Harald Tveit Alvestrand , Brian Haberman , Bob Hinden , iesg@ietf.org, rtg-dir@ietf.org, Margaret Wasserman Subject: Re: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Alex, At 12:53 AM 11/06/2004, Alex Zinin wrote: >Bob, > > I think we're completely in sync. Changes you suggest below would address > my concerns. Great! I will update the draft once the window opens again. Bob > Thanks! > >-- >Alex >http://www.psg.com/~zinin > >Thursday, November 4, 2004, 5:10:22 PM, Bob Hinden wrote: > > Alex, > > >>Sure. As I tried to explain, if all routers are supposed to do something > >>automatically once a ULA is configured without any additional > >>configuration from > >>the administrator, such functionality would fall into router implementation > >>requirements category. For instance, if you wanted the site border > routers to > >>automatically start filtering out packets using ULAs and crossing the site > >>border as part of the standard forwarding function (as described in the > >>addressing architecture document, for example), we would need to go several > >>steps further and think about what exactly a site is, and how routers are > >>supposed to know when a packet is leaving a site (e.g. per-interface site > >>knowledge, with checks during pkt fwd'ing). The same is applicable to the > >>routing part--if you wanted site border routers to automatically filter out > >>routes between sites, we would need to think about the same sort of > things as > >>above, how they work together, and how that works with routing protocols. > > > OK that makes sense. Since ULAs do not require code changes, I think we > > can change the text to make it clearer that we are describing operational > > guidelines. > > > Had we defined ULAs to, for example, not use longest match prefix lookups, > > then there would be a big impact on router functionality. But, of course, > > we didn't do that :-) > > >>Operational requirements give guidelines to administrator about how to > >>configure > >>routers when the technology is deployed. For instance, we could suggest > that > >>"site border routers should be configured with access lists (packet > filters) > >>disallowing packets that use ULAs as the source or destination addresses to > >>cross the boundary of a site". > >> > >> >> The implementation requirements define pieces of code that need to be > >> >> changed > >> >> or added on _every_ router when ULA support is added. Operational > ones > >> >> define > >> >> how those pieces or assumed to be already implemented > functionality are > >> >> expected to be configured and used. > >> > >> > I don't think any code is required in an IPv6 router to be > implemented to > >> > support ULA addresses. Everything in the ULA specification can be done > >> via > >> > configuration. [I am assuming the router has the ability to configure > >> > source address filters]. > >> > >>Can we change the text to be clearer that normal routing and forwarding > >>functionality is not changed and that these are configuration/operational > >>guidelines? > > > Yes, that is very doable. How about the following: > > > Adding a new section 4, titled "Operational Guidelines" and then make > > current sections 4-10 be subsections. For example: > > > 4.0 Operational Guidelines > > 4.1 Routing.........................................................7 > > 4.2 Renumbering and Site Merging....................................8 > > 4.3 Site Border Router and Firewall Packet Filtering................8 > > 4.4 DNS Issues......................................................9 > > 4.5 Application and Higher Level Protocol Issues....................9 > > 4.6 Use of Local IPv6 Addresses for Local Communications............9 > > 4.7 Use of Local IPv6 Addresses with VPNs..........................10 > > > Then add the following text between 4.0 and 4.1: > > > The guidelines in this section do not require any change to the > > normal routing and forwarding functionality in an IPv6 host or > > router. These > > are configuration and operational usage guidelines. > > > In addition, I think there are few places in the text in these sections > > where "should be configured" could be added to make this clearer. > > >> > Of course, a router vendor could decide to build > >> > special support in the code (e.g., to make it easy to turn on ULA > >> filtering > >> > on a set of interfaces), or perhaps to add it to an ASIC forwarding > engine > >> > to get the best filtering performance. But I don't see it as being > >> > required and these implementation decisions are a vendor decision. > >> > >>Of course. > > > Please let us know what you think. > > > Bob From rtg-dir-bounces@ietf.org Sun Nov 7 11:59:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04564 for ; Sun, 7 Nov 2004 11:59:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQqOg-00078t-1g for rtg-dir-archive@ietf.org; Sun, 07 Nov 2004 12:00:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqNj-00021t-S2; Sun, 07 Nov 2004 11:59:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqMU-0001u5-Tj for rtg-dir@megatron.ietf.org; Sun, 07 Nov 2004 11:57:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04440 for ; Sun, 7 Nov 2004 11:57:51 -0500 (EST) Message-Id: <200411071657.LAA04440@ietf.org> Received: from 32.248.39-62.rev.gaoland.net ([62.39.248.32]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CQqMq-00076p-FB for rtg-dir@ietf.org; Sun, 07 Nov 2004 11:58:17 -0500 Date: Sun, 07 Nov 2004 18:53:12 +0200 From: "Jamey Markel" To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Subject: why not? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.2 (++++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable He believed in it, as certain good women believe in the l= eviathan -- by faith, not by reason!!!=20






Cïålîs definetely b= etter then Vî@grå
..can last for 2 days
..You can have alcohol with Çíãlìs
..improves sexual performances twice better then Vîágr@
= ..it costs much cheaper than Pfizër Vïãgrà
Get CÏÃLIS (SUPÊR VÌÀGR&Ati= lde;) here








Discontinue During some lulls of the wind and sea, I fancied I heard several times vag= ue sounds, a sort of fugitive harmony produced by words of command. I am p= ortraying this hardy companion as I really knew him. They examined the sea= with the most careful attention!!=20 From rtg-dir-bounces@ietf.org Sun Nov 7 12:00:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04649 for ; Sun, 7 Nov 2004 12:00:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQqPE-0007A0-ON for rtg-dir-archive@ietf.org; Sun, 07 Nov 2004 12:00:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqNj-00021x-V2; Sun, 07 Nov 2004 11:59:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqMU-0001u6-Ti for rtg-dir@megatron.ietf.org; Sun, 07 Nov 2004 11:57:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04443 for ; Sun, 7 Nov 2004 11:57:51 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQqMh-00076e-6K for rtg-dir@ietf.org; Sun, 07 Nov 2004 11:58:17 -0500 Received: from 103.red-81-43-40.pooles.rima-tde.net ([81.43.40.103]) by mx2.foretec.com with smtp (Exim 4.24) id 1CQqM5-0007Av-T0 for rtg-dir@ietf.org; Sun, 07 Nov 2004 11:57:37 -0500 Date: Sun, 07 Nov 2004 18:53:12 +0200 From: "Jamey Markel" To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Score: 2.6 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Subject: why not? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable He believed in it, as certain good women believe in the l= eviathan -- by faith, not by reason!!!=20






Cïålîs definetely b= etter then Vî@grå
..can last for 2 days
..You can have alcohol with Çíãlìs
..improves sexual performances twice better then Vîágr@
= ..it costs much cheaper than Pfizër Vïãgrà
Get CÏÃLIS (SUPÊR VÌÀGR&Ati= lde;) here








Discontinue During some lulls of the wind and sea, I fancied I heard several times vag= ue sounds, a sort of fugitive harmony produced by words of command. I am p= ortraying this hardy companion as I really knew him. They examined the sea= with the most careful attention!!=20 From rtg-dir-bounces@ietf.org Sun Nov 7 12:26:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06453 for ; Sun, 7 Nov 2004 12:26:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQqom-0007gJ-MO for rtg-dir-archive@ietf.org; Sun, 07 Nov 2004 12:27:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqfk-0006Ej-1r; Sun, 07 Nov 2004 12:17:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqWi-0003VT-Lh for rtg-dir@megatron.ietf.org; Sun, 07 Nov 2004 12:08:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05130 for ; Sun, 7 Nov 2004 12:08:25 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQqX5-0007IQ-Lm for rtg-dir@ietf.org; Sun, 07 Nov 2004 12:08:51 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CQqWg-0000in-Lo for rtg-dir@ietf.org; Sun, 07 Nov 2004 17:08:26 +0000 Message-ID: <418E568C.3000104@psg.com> Date: Sun, 07 Nov 2004 18:08:28 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rtg-dir@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: get together at dc ? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit hi all, do some of the routing directorate member think about having a get together meeting before or after the rtgarea wg meeting or at some point in time during this meeting ? thanks, - dimitri. From rtg-dir-bounces@ietf.org Sun Nov 7 13:30:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10747 for ; Sun, 7 Nov 2004 13:30:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQroF-0000Ok-3g for rtg-dir-archive@ietf.org; Sun, 07 Nov 2004 13:30:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQrmC-0002Fy-8w; Sun, 07 Nov 2004 13:28:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQrkd-0001sC-GW for rtg-dir@megatron.ietf.org; Sun, 07 Nov 2004 13:26:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10548 for ; Sun, 7 Nov 2004 13:26:52 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQrkx-0000KV-R1 for rtg-dir@ietf.org; Sun, 07 Nov 2004 13:27:19 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-green.research.att.com (Postfix) with ESMTP id CC9E7A7B02; Sun, 7 Nov 2004 13:26:20 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id iA7IQKn16037; Sun, 7 Nov 2004 10:26:20 -0800 (PST) Message-Id: <200411071826.iA7IQKn16037@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Date: Sun, 7 Nov 2004 10:26:19 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: rtg-dir@ietf.org Subject: Re: get together at dc ? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Sigh. I had sent this email last week and didn't notice that I had put the wrong address on it. ----- Begin forwarded message: Subject: rtg-dir gettogether after reception Date: Thu, 4 Nov 2004 17:32:34 -0800 To: rtg-dir@rtg.ietf.org Let's try to get together after the Sunday night reception, at 7:00. We can try to find a place to eat and chat. Bill ----- End forwarded message: From rtg-dir-bounces@ietf.org Wed Nov 10 14:08:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14347 for ; Wed, 10 Nov 2004 14:08:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxqz-0002DY-BS for rtg-dir-archive@ietf.org; Wed, 10 Nov 2004 14:10:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxdV-0007w9-GB; Wed, 10 Nov 2004 13:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxZb-0006tq-Gr for rtg-dir@megatron.ietf.org; Wed, 10 Nov 2004 13:52:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12343 for ; Wed, 10 Nov 2004 13:52:02 -0500 (EST) Received: from mail.compurex.com ([206.165.217.179] helo=w2003server.pdc.compurex.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxab-0001hj-Mk for rtg-dir@ietf.org; Wed, 10 Nov 2004 13:53:06 -0500 Received: from AMANDASAVINI ([10.0.0.74]) by w2003server.pdc.compurex.com with Microsoft SMTPSVC(6.0.3790.80); Wed, 10 Nov 2004 12:37:38 -0500 From: Compurex Systemse To: rtg-dir@ietf.org Message-Id: <20041110123930.650733@compurex.com> Date: Wed, 10 Nov 2004 12:39:30 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary.11111111.11111111" X-OriginalArrivalTime: 10 Nov 2004 17:37:38.0625 (UTC) FILETIME=[F8F13B10:01C4C74B] X-Spam-Score: 4.3 (++++) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Subject: Cisco Specials 11/10/2004 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.3 (++++) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc --Boundary.11111111.11111111 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Compurex Systems 35 Eastman Street South Easton MA 02375 800-426-5499 508-230-3700 fax 508-238-8250 Cisco Specials All in stock and ready to ship Hello rtg-dir@ietf.org, 4WS-X4148-RJ$1,275 WS-X6408A-GBIC$4,000 10WS-C3550-24-SMI (New Sealed)$1,800 NPE 400 (NOB)$3,400 QtyWS-G5486$100 QtyWS-G5484$75 WSX4014$6,000 QtyWIC-1T$85 Cisco3640 3600 Series 4 Slot Router List Price $6000Sale Price $1,200 Refurbished WS-C6509-1300AC Cisco 6509 Catalyst Switch with 1300 AC Power Supply (includes fan tray) WS-X6K-S1A-MSFC2 Catalyst 6000 Supervisor Engine 1-A, 2GE, plus MSFC-2 and PFC WS-X6148-GE-TX (x2) Catalyst 6500 48-port 10/100/1000 GE Mod., RJ-45 WS-X6416-GBIC Catalyst 6000 16 - Port Gig-Ethernet Mod. (Req. GIBIC's) WS-G5484 (x16) 1000 Base-SX Short Wavelength GBIC (multimode only) List Price $86,485Sale Price $36,000 Refurbished Cisco3745 3700 Series, 4 Slot, Dual FE, Multiservice Access Router NM-1GE 1 Port GE Network Module MN-32A 32 Port Asynchronous Module List Price $21,100Sale Price $10,550 Refurbished WS-C3550-12T 10-10/100/1000 ports + 2 GBIC ports:EM List Price $9,995Sale Price $5,400 New in Box This Weeks Specials Call Sales at 508-230-3700 or 800-426-5499 Email sales@compurex.com Compurex Systems Buy Sell Rent Lease Trade-Up HP Compaq Digital Sun Cisco Extreme Nortel and More Your Single Source for IT Solutions Since 1987 For more, visit www.compurex.com. | To click here to unsubscribe mailto:dead@compurex.com?Subject=Unsubscribe-000003NzY3NgAA This message is sent in compliance with the new e-mail bill: Section 301, Paragraph(a)(2)(c) of s. 1618 --Boundary.11111111.11111111 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Email Template

Compurex Systems

35 Eastman Street      South Easton MA 02375      800-426-5499      508-230-3700       fax 508-238-8250

Cisco Specials

All in stock and ready to ship

Hello rtg-dir@ietf.org,

 

4 WS-X4148-RJ $1,275
WS-X6408A-GBIC $4,000
10 WS-C3550-24-SMI (New Sealed) $1,800
NPE 400 (NOB) $3,400
Qty WS-G5486 $100
Qty WS-G5484 $75
WSX4014 $6,000
Qty WIC-1T $85

Cisco3640 3600 Series 4 Slot Router

List Price $6000

Sale Price

$1,200

Refurbished

 

 

 

 

 

WS-C6509-1300AC Cisco 6509 Catalyst Switch with 1300 AC Power Supply (includes fan tray)

WS-X6K-S1A-MSFC2 Catalyst 6000 Supervisor Engine   1-A, 2GE, plus MSFC-2 and PFC

WS-X6148-GE-TX (x2) Catalyst 6500 48-port 10/100/1000 GE Mod., RJ-45

WS-X6416-GBIC Catalyst 6000 16 - Port Gig-Ethernet Mod. (Req. GIBIC's)

WS-G5484 (x16) 1000 Base-SX Short Wavelength GBIC (multimode only)

List Price $86,485

Sale Price

$36,000

Refurbished

Cisco3745 3700 Series, 4 Slot, Dual FE, Multiservice Access Router

NM-1GE  1 Port GE Network Module

MN-32A  32 Port Asynchronous Module

List Price $21,100

Sale Price

$10,550

Refurbished

WS-C3550-12T 10-10/100/1000 ports + 2 GBIC ports:EM

List Price $9,995

Sale Price

$5,400

New in Box

 

 

 

 

 

This Weeks Specials

 

Call Sales at

508-230-3700

or

800-426-5499

Email

sales@compurex.com

 

 

Compurex Systems

Buy Sell Rent Lease Trade-Up

HP Compaq Digital Sun Cisco

Extreme Nortel and More

Your Single Source for IT Solutions Since 1987

 

For more, visit www.compurex.com. | To click here to unsubscribe

This message is sent in compliance with the new e-mail bill: Section 301, Paragraph(a)(2)(c) of s. 1618

--Boundary.11111111.11111111-- From rtg-dir-bounces@ietf.org Mon Nov 15 13:25:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17520 for ; Mon, 15 Nov 2004 13:25:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTlZK-0004bK-Gm for rtg-dir-archive@ietf.org; Mon, 15 Nov 2004 13:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTlVa-0007AC-FM; Mon, 15 Nov 2004 13:23:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTlTB-0006s6-RZ; Mon, 15 Nov 2004 13:20:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16450; Mon, 15 Nov 2004 13:13:34 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTlOC-0004Lw-Nk; Mon, 15 Nov 2004 13:15:45 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTlM7-0004kE-No; Mon, 15 Nov 2004 18:13:35 +0000 Date: Mon, 15 Nov 2004 10:13:35 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1192638955.20041115101335@psg.com> To: rtg-chairs@ietf.org, rtg-dir@ietf.org, iesg@ietf.org, nomcom04@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: Alex mostly off-line Mon-Wed X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit I'll be catching up with my family these three days, and plan on NOT reading e-mail regularly. No e-mail will be lost, though, and I will get back to it later this week. I do plan to be on the NomCom call on Tue and IESG telechat on Thursday. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Sun Nov 28 18:33:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26680 for ; Sun, 28 Nov 2004 18:33:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYYd5-0008Hx-Lf for rtg-dir-archive@ietf.org; Sun, 28 Nov 2004 18:38:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYYVX-0005zi-FQ; Sun, 28 Nov 2004 18:31:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYYPg-0004to-F9 for rtg-dir@megatron.ietf.org; Sun, 28 Nov 2004 18:25:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25971 for ; Sun, 28 Nov 2004 18:25:01 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYYUI-00088L-GZ for rtg-dir@ietf.org; Sun, 28 Nov 2004 18:30:01 -0500 Received: from [83.144.143.252] (helo=PAULO-MP3) by mx2.foretec.com with smtp (Exim 4.24) id 1CYYPU-0006GX-5D for rtg-dir@ietf.org; Sun, 28 Nov 2004 18:24:52 -0500 Date: Sun, 28 Nov 2004 16:22:46 -0700 From: "Kinny Ikard" To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Score: 2.3 (++) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Subject: Fwd: Best deal of the month X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable To borrow money on the credit of the United States;=20!!!= =20



Looking for not expensive high-quality software?
We might have just what you need.

Windows XP= Professional 2002 ............. $50
Adobe Photos= hop 7.0 ...................... $60
Microsoft Of= fice XP Professional 2002 .... $60
Corel Draw= Graphics Suite 11 ............. $60

and lots mo= re...

TOP quality software:

Special Offer #1:
Windows XP Pro= fessional+Microsoft Office XP Professional =3D only $80
Special Offer #2:
Adobe - Photos= hop 7, Premiere 7, Illustrator 10 =3D only $120
Special Offer #3:
Macromedia Dr= eamwaver MX 2004 + Flash MX 2004 =3D only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage
Enter Here






?q9svYHquR.xPIqqfeFzfo">Discontinue What passes in those remote depths -- what beings live, or can live, twelv= e or fifteen miles beneath the surface of the waters -- what is the organi= sation of these animals, we can scarcely conjecture!! Editors of scientifi= c journals, quarrelling with believers in the supernatural, spilled seas o= f ink during this memorable campaign, some even drawing blood; for from th= e sea-serpent they came to direct personalities. At seventeen minutes past= four in the afternoon, whilst the passengers were assembled at lunch in t= he great saloon, a slight shock was felt on the hull of the Scotia, on her= quarter, a little aft of the port-paddle?=20 From rtg-dir-bounces@ietf.org Tue Nov 30 20:15:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09242 for ; Tue, 30 Nov 2004 20:15:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZJAX-00011D-Fm for rtg-dir-archive@ietf.org; Tue, 30 Nov 2004 20:20:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZJ1S-0003Ti-8q; Tue, 30 Nov 2004 20:11:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIzh-0002E5-Od for rtg-dir@megatron.ietf.org; Tue, 30 Nov 2004 20:09:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08770 for ; Tue, 30 Nov 2004 20:09:19 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZJ4u-0000s2-TS for rtg-dir@ietf.org; Tue, 30 Nov 2004 20:14:45 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZIzf-0005vb-TU; Wed, 01 Dec 2004 01:09:19 +0000 Date: Tue, 30 Nov 2004 17:09:18 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1142189783.20041130170918@psg.com> To: mike shand In-Reply-To: <4.3.2.7.2.20040908150039.02a959b0@jaws.cisco.com> References: <4.3.2.7.2.20040908150039.02a959b0@jaws.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: George Swallow , rtg-dir@ietf.org, Loa Andersson , Adrian Farrel Subject: Re: Fwd: Re: draft-ietf-mpls-rsvpte-attributes-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Mike, Adrian- Have these comments been addressed? I still see -04 in the tracker. -- Alex http://www.psg.com/~zinin Wednesday, September 8, 2004, 6:01:07 AM, mike shand wrote: >>X-BrightmailFiltered: true >>Reply-To: "Adrian Farrel" >>From: "Adrian Farrel" >>To: "mike shand" >>Cc: , , , >> >>Subject: Re: draft-ietf-mpls-rsvpte-attributes-04.txt >>Date: Wed, 8 Sep 2004 14:40:48 +0100 >>X-Mailer: Microsoft Outlook Express 6.00.2800.1158 >>X-PMX-Version: 4.7.0.111621 >>X-from-outside-Cisco: 128.107.250.142 >> >>Hi Mike, >> >>Thanks for the review. >> >> > I'm conducting a "routing directorate" review of the above draft and I >> > have a couple of questions regarding the format of the TLVs. >> > >> > 1) In section 3, under length, it says that the padding to take the value >> > field up to a 4 byte boundary is NOT included in the length. >> > However in section 3.1 para 3 it says that the length field is always a >> > multiple of 4 bytes regardless of the number of bits set. >> > >> > I'm having difficulty reconciling those two statements. >> >>You are not the first to ask this question and I wonder what to do to stop >>it being asked >>again. >> >>The value field in section 3.1 para 3 is always a multiple of four bytes. >>It is NEVER >>padded. (It never needs to be padded.) >>Bits are either defined or undefined, but never pads. >>Thus the length field is always a multiple of 4 and always reflects >>exactly the length of >>the value field. >> >>Other TLVs may have value fields that are not a multiple of four bytes. In >>these cases (as >>described in section 3): >>- the length field reflects exactly the length of the value field >>- padding is added to round the value field up to a four byte boundary. >> >>We would certainly welcome your input on how to make this more clear. >> >> > 2) The TLV defined above in section 3 is of the normal design in that the >> > length is the length of the value field only and does not include the type >> > and length fields. However, the TLV defined 7.2 has a different form where >> > the length includes the type and length fields. >> > >> > Is there some rationale why the same protocol uses both types of encoding? >> >>As you say, the TLV definition in section 3 is "normal". Thus it is the >>prefered way to >>define TLVs for the new object. >> >>The "TLV" in section 7.2 is not actually a TLV but is a sub-object >>according to the >>definitions and format in RFC3209. We have no scope to play with this >>definition (not >>withstanding the fact that it is abnormal). >> >> > And one final question. In section 9 it says in paras 5 and 7 that LSRs >> > SHOULD be prepared to receive this object in any order.... >> > >> > should that be a MUST, or is SHOULD acceptable? It would appear to be >> > non-optional. >> >>Good catch. >> >> > A couple of typos I spotted. >> > >> > section 6 Inheritance rules. End of first para. >> > >> > "belongs to the same switching capability class THAN the triggering LSP". >> >>yup >> >> > section 7.3.1 Subobject presence rules, last para >> > >> > nearest to the STOP of the stack) >> >>yup >> >>Thanks, Mike. >> >>I'll hold the last three changes ready for the next rev. >>Any advice about clarifying the first two points would be welcomed. >> >>Cheers, >>Adrian From rtg-dir-bounces@ietf.org Wed Dec 1 04:25:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06253 for ; Wed, 1 Dec 2004 04:25:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZQp3-0003SM-Gn for rtg-dir-archive@ietf.org; Wed, 01 Dec 2004 04:30:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZQho-00038j-K6; Wed, 01 Dec 2004 04:23:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZQYr-00019g-EI for rtg-dir@megatron.ietf.org; Wed, 01 Dec 2004 04:14:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04961 for ; Wed, 1 Dec 2004 04:14:07 -0500 (EST) Received: from oceanus.uk.clara.net ([80.168.70.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZQe8-00039i-4G for rtg-dir@ietf.org; Wed, 01 Dec 2004 04:19:37 -0500 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1CZQYi-0000Sd-HD; Wed, 01 Dec 2004 09:14:00 +0000 From: "Adrian Farrel" To: zinin@psg.com, mshand@cisco.com Date: Wed, 01 Dec 2004 09:14:00 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.204.167 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: loa@pi.se, rtg-dir@ietf.org, swallow@cisco.com, adrian@olddog.co.uk Subject: Re: Fwd: Re: draft-ietf-mpls-rsvpte-attributes-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Alex, IMHO the comments are addressed, although Mike may want to come back with a suggested change. There were three typos that came out of his review. I can re-spin the draft for them, but I did not plan to make the changes until IETF review or even authors 48 hours. Last I heard about the draft was Loa asking me about implementations. A From rtg-dir-bounces@ietf.org Wed Dec 1 07:27:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21670 for ; Wed, 1 Dec 2004 07:27:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZTfb-0007CN-4D for rtg-dir-archive@ietf.org; Wed, 01 Dec 2004 07:33:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZSIJ-0007En-G1; Wed, 01 Dec 2004 06:05:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZR9B-00084r-FG for rtg-dir@megatron.ietf.org; Wed, 01 Dec 2004 04:51:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08431 for ; Wed, 1 Dec 2004 04:51:39 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZRES-000454-KK for rtg-dir@ietf.org; Wed, 01 Dec 2004 04:57:09 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2004 11:01:58 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB19p2Cu010474; Wed, 1 Dec 2004 10:51:03 +0100 (MET) Received: from mshand-w2k02.cisco.com (ams-clip-vpn-dhcp4452.cisco.com [10.61.81.99]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA08601; Wed, 1 Dec 2004 09:51:01 GMT Message-Id: <4.3.2.7.2.20041201094848.024174a8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Dec 2004 09:49:57 +0000 To: adrian@olddog.co.uk From: mike shand In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: zinin@psg.com, rtg-dir@ietf.org, adrian@olddog.co.uk, swallow@cisco.com, loa@pi.se Subject: Re: Fwd: Re: draft-ietf-mpls-rsvpte-attributes-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 At 09:14 01/12/2004 +0000, Adrian Farrel wrote: >Alex, >IMHO the comments are addressed, although Mike may want to come back with >a suggested change. >There were three typos that came out of his review. I can re-spin the >draft for them, but I did not plan to make the changes until IETF review >or even authors 48 hours. >Last I heard about the draft was Loa asking me about implementations. >A Yes I think Adrian addressed my comments. It could perhaps do with some wordsmithing to make it clearer, but I don't have any good suggestions. With Adrian's explanation it now makes perfect sense. Mike From rtg-dir-bounces@ietf.org Wed Dec 1 14:36:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15945 for ; Wed, 1 Dec 2004 14:36:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZaMX-0001rt-J6 for rtg-dir-archive@ietf.org; Wed, 01 Dec 2004 14:42:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZZX8-0007vV-4W; Wed, 01 Dec 2004 13:48:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZYv8-0008VC-54 for rtg-dir@megatron.ietf.org; Wed, 01 Dec 2004 13:09:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05247 for ; Wed, 1 Dec 2004 13:09:39 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZZ0U-00079E-2C for rtg-dir@ietf.org; Wed, 01 Dec 2004 13:15:15 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZYv5-0004XG-Gt; Wed, 01 Dec 2004 18:09:39 +0000 Date: Wed, 1 Dec 2004 10:09:38 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1583966266.20041201100938@psg.com> To: mike shand In-Reply-To: <4.3.2.7.2.20041201094848.024174a8@jaws.cisco.com> References: <4.3.2.7.2.20041201094848.024174a8@jaws.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: loa@pi.se, adrian@olddog.co.uk, swallow@cisco.com, rtg-dir@ietf.org Subject: Re: Fwd: Re: draft-ietf-mpls-rsvpte-attributes-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Mike, Adrian- Got it. Thanks, guys! -- Alex http://www.psg.com/~zinin Wednesday, December 1, 2004, 1:49:57 AM, mike shand wrote: > At 09:14 01/12/2004 +0000, Adrian Farrel wrote: >>Alex, >>IMHO the comments are addressed, although Mike may want to come back with >>a suggested change. >>There were three typos that came out of his review. I can re-spin the >>draft for them, but I did not plan to make the changes until IETF review >>or even authors 48 hours. >>Last I heard about the draft was Loa asking me about implementations. >>A > Yes I think Adrian addressed my comments. It could perhaps do with some > wordsmithing to make it clearer, but I don't have any good suggestions. > With Adrian's explanation it now makes perfect sense. > Mike From rtg-dir-bounces@ietf.org Wed Dec 1 20:30:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20118 for ; Wed, 1 Dec 2004 20:30:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZfso-00031j-62 for rtg-dir-archive@ietf.org; Wed, 01 Dec 2004 20:35:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZfeh-0004F5-9X; Wed, 01 Dec 2004 20:21:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZfSX-0007Nf-Uq for rtg-dir@megatron.ietf.org; Wed, 01 Dec 2004 20:08:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18764 for ; Wed, 1 Dec 2004 20:08:35 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZfXy-0002a0-9G for rtg-dir@ietf.org; Wed, 01 Dec 2004 20:14:14 -0500 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-green.research.att.com (Postfix) with ESMTP id 84FDEA7ADC for ; Wed, 1 Dec 2004 20:08:06 -0500 (EST) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id iB217vmm069632 for ; Wed, 1 Dec 2004 17:07:57 -0800 (PST) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id iB217vkA069631 for rtg-dir@ietf.org; Wed, 1 Dec 2004 17:07:57 -0800 (PST) (envelope-from fenner) Date: Wed, 1 Dec 2004 17:07:57 -0800 (PST) Message-Id: <200412020107.iB217vkA069631@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Subject: IESG agenda for 2004-12-02 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2004-12-02). Updated 18:24:36 EDT, December 1, 2004 ------------------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date INT OSPF as the Provider/Customer Edge Protocol for BGP/ MPLS IP VPNs (Proposed Standard) - 1 of 4 draft-ietf-l3vpn-ospf-2547-02.txt [Open Web Ballot] Note: 2004-11-24: Ready for full IESG review. Also, depends on draft-ietf-idr-bgp-ext-communities-07.txt to set up IANA registry that is populated by this document (see comment from IANA in log). Token: Thomas Narten INT Multicast Router Discovery (Proposed Standard) - 2 of 4 draft-ietf-magma-mrdisc-03.txt [Open Web Ballot] Token: Margaret Wasserman GEN May 11 Two-Document ballot: [Open Web Ballot] - 3 of 4 IAB Processes for management of liaison relationships (BCP) - 3 of 4 draft-iab-liaison-mgt-02.txt Procedure for Handling Liaison Statements Between Standards Bodies (BCP) draft-baker-liaison-statements-02.txt Note: See also draft-iab-liaison-mgt Token: Harald Alvestrand GEN RTP Payload for Text Conversation (Proposed Standard) - 4 of 4 draft-ietf-avt-rfc2793bis-09.txt [Open Web Ballot] Note: text/red is in revision to be text payload types only RFC Editor Note will change IANA Considerations to note text/t140 is an update, not new Token: Allison Mankin 2.1.2 Returning Item Area Date RTG Eight-Document ballot: [Open Web Ballot] - 1 of 5 A Border Gateway Protocol 4 (BGP-4) (Draft Standard) - 1 of 5 draft-ietf-idr-bgp4-26.txt Note: Back on the agenda to resolve remaining DISCUSS'es BGP 4 Implementation Report (Informational) draft-ietf-idr-bgp-implementation-02.txt Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) (Proposed Standard) draft-ietf-idr-bgp4-mib-15.txt BGP Security Vulnerabilities Analysis (Informational) draft-ietf-idr-bgp-vuln-01.txt BGP-4 Protocol Analysis (Informational) draft-ietf-idr-bgp-analysis-06.txt Experience with the BGP-4 Protocol (Informational) draft-ietf-idr-bgp4-experience-protocol-05.txt BGP MIB V1 implementation survey (Informational) draft-ietf-idr-bgp-mibagent-survey-02.txt Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification (Informational) draft-iesg-tcpmd5app-01.txt Token: Alex Zinin INT Simple Network Time Protocol Configuration Option for DHCPv6 (Proposed Standard) - 2 of 5 draft-ietf-dhc-dhcpv6-opt-sntp-01.txt [Open Web Ballot] Note: Back on the agenda for re-review by Thomas. Thomas does this address your discuss? Token: Margaret Wasserman INT Unique Local IPv6 Unicast Addresses (Proposed Standard) - 3 of 5 draft-ietf-ipv6-unique-local-addr-08.txt [Open Web Ballot] Note: Ted, Bill and Alex, could you please check if your concerns have been addressed? If not, please let me know what issues remain. Thanks. Question for all: What should we do regarding possible ARIN issues with this document? Token: Margaret Wasserman INT IP Tunnel MIB (Proposed Standard) - 4 of 5 draft-ietf-ipv6-inet-tunnel-mib-03.txt [Open Web Ballot] Note: Back on agenda to check if IANA issues have been addressed. Michelle and Bert, are there any further concerns? Token: Margaret Wasserman INT Management Information Base for the User Datagram Protocol (UDP) (Proposed Standard) - 5 of 5 draft-ietf-ipv6-rfc2013-update-04.txt [Open Web Ballot] Note: Authors have responded to IANA questions. Michelle and Bert, are there any remaining issues? Token: Margaret Wasserman 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date INT Detecting Network Attachment in IPv6 Goals (Informational) - 1 of 3 draft-ietf-dna-goals-03.txt [Open Web Ballot] Token: Margaret Wasserman OPS Threats relating to IPv6 multihoming solutions (Informational) - 2 of 3 draft-ietf-multi6-multihoming-threats-02.txt [Open Web Ballot] Token: David Kessens OPS IPv6 Multicast Deployment Issues (Informational) - 3 of 3 draft-ietf-mboned-ipv6-multicast-issues-01.txt [Open Web Ballot] Token: David Kessens 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date Extensible Authentication Protocol Method for 3rd INT Generation Authentication and Key Agreement (EAP-AKA) (Informational) - 1 of 4 draft-arkko-pppext-eap-aka-14.txt [Open Web Ballot] Note: 2004-11-23: Ready for full IESG review (when -14 appears). Note: needed by 3GPP; document has been reviewed by EAP WG for conformance with EAP, but security properties have not (and will not) be reviewed. Document has been submitted a independent submission to RFC Editor, but 3GPP (via liaison discussions) has requested that the document be reviewed by IETF for conformance with EAP. Token: Thomas Narten Extensible Authentication Protocol Method for GSM INT Subscriber Identity Modules (EAP-SIM) (Informational) - 2 of 4 draft-haverinen-pppext-eap-sim-15.txt [Open Web Ballot] Note: 2004-11-23: Ready for full IESG review (when -15 appears). Note: needed by 3GPP; document has been reviewed by EAP WG for conformance with EAP, but security properties have not (and will not) be reviewed. Document has been submitted a independent submission to RFC Editor, but 3GPP (via liaison discussions) has requested that the document be reviewed by IETF for conformance with EAP. Token: Thomas Narten The 'info' URI Scheme for Information Assets with APP Identifiers in Public Namespaces (Informational) - 3 of 4 draft-vandesompel-info-uri-02.txt [Open Web Ballot] Token: Ted Hardie GEN Using Universal Content Identifier as Uniform Resource Names (Informational) - 4 of 4 draft-sangug-uci-urn-00.txt [Open Web Ballot] Token: Ted Hardie 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item Area Date TSV Session Initiation Protocol (SIP)-H.323 Interworking Requirements (Informational) - 1 of 1 draft-agrawal-sip-h323-interworking-reqs-07.txt [Open Web Ballot] Token: Jon Peterson 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issues From rtg-dir-bounces@ietf.org Thu Dec 2 17:30:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07606 for ; Thu, 2 Dec 2004 17:30:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZzZ7-0000wj-Pg for rtg-dir-archive@ietf.org; Thu, 02 Dec 2004 17:36:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZuzl-0007uB-1H; Thu, 02 Dec 2004 12:43:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZstF-0003yR-37 for rtg-dir@megatron.ietf.org; Thu, 02 Dec 2004 10:29:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28932 for ; Thu, 2 Dec 2004 10:29:02 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZsym-0006EU-Cv for rtg-dir@ietf.org; Thu, 02 Dec 2004 10:34:49 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id 2BB69197354 for ; Thu, 2 Dec 2004 10:17:14 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id iB2FSWg27139; Thu, 2 Dec 2004 07:28:32 -0800 (PST) Message-Id: <200412021528.iB2FSWg27139@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-dir@ietf.org Date: Thu, 2 Dec 2004 07:28:31 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: Re: IESG agenda for 2004-12-02 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea I now have a cron job that sends these the Monday before the telechat, when the agenda is basically finalized. Bill From rtg-dir-bounces@ietf.org Thu Dec 2 20:19:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24094 for ; Thu, 2 Dec 2004 20:19:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca2CI-0004yK-DR for rtg-dir-archive@ietf.org; Thu, 02 Dec 2004 20:25:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0OG-0003Xj-8o; Thu, 02 Dec 2004 18:29:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZwIj-0008RF-VG for rtg-dir@megatron.ietf.org; Thu, 02 Dec 2004 14:07:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18995 for ; Thu, 2 Dec 2004 14:07:36 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZwOH-0004Nm-Il for rtg-dir@ietf.org; Thu, 02 Dec 2004 14:13:24 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZwIU-0002Jb-Ge; Thu, 02 Dec 2004 19:07:22 +0000 Date: Thu, 2 Dec 2004 11:07:20 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <31742008.20041202110720@psg.com> To: Acee Lindem , Rohit Dube , rtg-dir@ietf.org In-Reply-To: <1519182984.20041201235531@psg.com> References: <1519182984.20041201235531@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Content-Transfer-Encoding: 7bit Subject: NOT GOOD: Fwd: DISCUSS: draft-ietf-l3vpn-ospf-2547 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: f0ea5880a0890be2408609376fa519aa Content-Transfer-Encoding: 7bit Guys- Supposedly this document has been LC'ed in the OSPF WG, and reviewed in RTG-DIR, yet I find an _awful_ lot of issues when it comes to the IESG :( These should definitely have been caught by these reviews, that's why we refer these docs to the experts... I'll stop grumbling now and ask this question--how do we make sure something like this does not happen again? -- Alex http://www.psg.com/~zinin This is a forwarded message From: Alex Zinin To: iesg@ietf.org Cc: Date: Wednesday, December 1, 2004, 11:55:31 PM Subject: DISCUSS: draft-ietf-l3vpn-ospf-2547 ===8<==============Original message text=============== I have so many comments here, I'm not even sure I'm finished reviewing this doc. DISCUSS: > 4.1. Overview > Every PE attached to a particular OSPF network MUST function as an > OSPF area 0 router. What does this mean, really? Does it mean that all interfaces should be treated as belonging to area 0? Hopefully not. That it is a backbone- connected ABR? If so, in what cases, in particular? This statement is rather confusing. > This allows it to distribute inter-area routes to > the CE via Type 3 LSAs. The CE router might or might not be an area > 0 router, and the PE/CE link might or might not be an area 0 link. > 4.2. Details > > 4.2.1. General > > If a PE and a CE are communicating via OSPF, the PE MUST create, and > MUST flood to the CE, a type 1 LSA advertising its link to the CE. > The PE MUST have an OSPF router id which is valid (i.e., unique) > within the OSPF domain. The PE MUST also be configured to know which > OSPF area the link is in. What is the point of specifying this? "Communicate via OSPF" implies it all. > Whether or not the PE-CE link is an area 0 link, the PE MUST function > as an OSPF area 0 router. Same question as above. > That is, the link state topology from a > site will NOT be passed along by the PE. Not sassed along where? What if the PE has a Sham Link with another PE? > Each OSPF domain MUST be associated with a Domain Identifier. This > MUST be configurable, and the default value (if none is configured) > SHOULD be NULL. More precisely, each VRF associated with an OSPF > instance will either be configured with one or more Domain > Identifiers, or else will use NULL as its Domain Identifier. if > 1, does it mean there's more than one OSPF instance associated? > If a particular OSPF domain has the NULL Domain Identifier, care must > be taken to avoid having routes from that OSPF domain and routes from > another OSPF domain imported into the same VRF. why? The OSPF Domain ID notion is used, the rules are given, however, the concept is not explained. I.e, is the goal to be able to tell whether it should look like one OSPF domain to the customer or multiple? Please provide some description. > The value of the VPN Route Tag is arbitrary, but must be distinct > from any OSPF Route Tag being used within the OSPF domain. Its value > MUST therefore be configurable. If the Autonomous System number is > two bytes long, the default value SHOULD be an automatically computed > tag based on the Autonomous System number of the VPN backbone: which "the Autonomous System" is meant here? > 4.2.2. Handling LSAs from the CE > > This section specifies the way in which a PE router handles the OSPF > LSAs it receives from a CE router. > > When a PE router receives, from a CE router, any LSA with the DN bit > [OSPF-DN] set, the information from that LSA MUST NOT be used by the > SPF ("Shortest Path First") computation. If a Type 5 LSA is received > from the CE, and if it has an OSPF route tag value equal to the VPN > Route Tag (see section 4.2.1), then the information from that LSA > MUST NOT be used by the SPF computation. Strictly speaking, type-3's and type-5s are not part of "SPF" per se. a more generic term like "route calculation" would be better. > Otherwise, the PE must examine the corresponding VRF. For every Does this mean the VRF's routing table? > address prefix which appears there, the PE must create a VPN-IPv4 > route in BGP. Should that rather be "for each route installed by the corresponding OSPF process"? Otherwise, one could pick up static routes, for example. > Each such route will have some of the following > Extended Community attributes: > - OSPF Route Type Extended Communities Attribute. This attribute > MUST be present. It is encoded with a two-byte type field, and > its type is 0306. To ensure backwards compatibility, the type > 8000 SHOULD be accepted as well, and treated as if it were type > 0306. The remaining six bytes of the Attribute are encodes as > follows: and is it left as a reverse-engineering exercise for the reader to figure out the exact order of these fields? > * OSPF Route Type: 1 byte, encoded as follows: > > ** 1 or 2 for intra-area routes (depending on whether the > route came from a type 1 or a type 2 LSA -- however this > difference is not significant to the procedures > specified herein) > > ** 3 for summary routes this should be "inter-area" routes > ** 5 for external routes (area number must be 0) > > ** 7 for NSSA routes. Processing of NSSA routes hasn't been defined in this spec, btw. > - OSPF Router Id Extended Communities Attribute. This OPTIONAL > attribute specifies the OSPF Router Id of the system that is > identified in the BGP Next Hop attribute. More precisely, it > specifies the Router Id of the particular VRF from which this > route was exported. The last sentence says "Router Id". Is it still the OSPF Router ID? If so, isn't that possible that more than one OSPF process is associated with a given VRF? If so how a VRF can have "the Router ID"? > This attribute is encoded with a two-byte > type field, and its type is 0107, with the router id itself > carried in the first 4 bytes of the value field. The type 8001 > SHOULD be accepted as well, to ensure backwards compatibility, > and should be treated as if it were 0107. > Routes which a PE receives in type 4 LSAs MUST be ignored. Sorry, but they can't ignore them. Otherwise, they won't be able to calculate AS-external routes. > 4.2.3.1. Intra-Area Routes > A sham link can be thought of as a relation between two VRFs. If two > VRFs are to be connected by a sham link, each VRF must be associated > with a "Sham Link Endpoint Address", a /32 address which is treated should be either "a 32-bit IPv4 address" or "a /32 IPv4 prefix" > as an address of the PE router containing that VRF. The Sham Link > Endpoint Address associated with a VRF MUST be configurable, and it > MAY default to the VRF's router id. What is the "VRF's router id"? > The Sham Link Endpoint Address > is an address in the VPN's address space, not the SP's address space. > 4.2.3.2. Creating Sham Links ... > IF a VRF is configured for auto-configuration of sham links, it MUST > distribute, via BGP, a VPN-IP route corresponding to the Sham Link > Endpoint Address. This route MUST have the OSPF Route Type Extended > Community attribute, with the OSPF Route Type field set to "Sham Link > Endpoint Address". What about other fields? > When a PE receives such a route, with a Route Target value that > allows the route to be imported into a particular VRF, then if The document should explicitly make it clear that this /32 must be installed in the VRF routing table, since this is crucial for sham link operation. Question: if the customer misconfigured one of their routers and a PE receives a route to the same /32 from another PE as, say, an OSPF internal route, how should these two types of routes compare? > - that route has an OSPF Domain Identifier Extended Communities > attribute which is identical to one of the VRF's Domain > Identifiers, or the route has no OSPF Domain Identifier Extended > Communities attribute and the VRF has a NULL Domain Identifier, > AND > > - that route has an OSPF area number which matches that of the VRF, A VRF may have more than one are per each OSPF process > then if the local VRF is configured for auto-configuration of sham > links, a sham link is created from the local VRF to the VRF > identified by the sham link endpoint address. > 4.2.3.3. Treatment of Sham Links This section misses a very important part--sending and receiving OSPF packets over sham links. Supposedly that would be very similar to OSPF virtual links. > The sham link is an unnumbered point-to-point intra-area link, and is > advertised by means of a type 1 LSA. OSPF uses two types of link records in type-1 LSAs: type-1 for physical p2p links, and type-4 for virtual links. The spec needs to be more specific (heh) which one is used. Another really important piece that is missing is next-hop calculation for routes through Sham Links by the PEs. And yet another missing piece is what happens with the routes calculated with next-hops through the sham links. More specifically, should they be preferred over the BGP ones or not (I assume the PEs continue announcing OSPF routes in BGP even when a sham link gets established, right?), and how do the packets get across the MPLS backbone (i.e., how is the MPLS stack gets constructed.) > 4.2.4. VPN-IP routes received via BGP > > This section describes how the PE router handles VPN-IP routes > received via BGP. Would be useful if this section said explicitly that VPN-IP routes received via BGP are installed in the VRF's routing table and how (e.g. as BGP routes). > 4.2.4.1. Routes from Different Domains > To determine how to process an a received VPN-IP route, it is > necessary to compare the OSPF Domain Identifier Extended Communities > attribute carried by the route (if any) with the OSPF Domain > Identifier Extended Communities attribute(s) with which the VRF has > been configured (if any). Previously the text suggested that VRFs are confidered with OSPF Domain IDs, not extended communities. > In general, when two such attributes are > compared, all eight bytes must be compared. Thus two OSPF Domain > Identifier Extended Communities attributes are regarded as equal if > and only if one of the following three conditions holds: > > 1. They are identical in all eight bytes. > > 2. They are identical in their lower order six bytes (value > field), but one attribute has two high order bytes (type field) > of 0005 and the other has two high order bytes (type field) of > 8005. (This condition is for backwards compatibility.) > > 3. The lower order six bytes (value field) of both attributes > consist entirely of zeroes. In this case, the two attributes > are considered to be identical irrespective of their type > fields, and they are regarded as representing the NULL Domain > Identifier. Given the question above, how applicable is this text? > If one of the following three conditions holds, a VPN-IP route > received via BGP is regarded as being from a different domain than > the VRF into which the route is being installed. > > 1. The VRF has a non-NULL OSPF Domain Identifier, but either > > a) the route has no OSPF Domain Identifier Extended > Communities attribute, or > > b) the route has an OSPF Domain Identifier Extended > Communities attribute whose value field consists of all > zeroes > > 2. the route has an OSPF Domain Identifier Extended Communities > attribute whose value field does not consist of all zeroes, and > the VRF is configured with the NULL Domain Identifier (or with > any encoding of the NULL Domain Identifier as specified above) Why would a VRF be configured with "encoding" of a domain id, rather than simply its value? > If any of these three conditions holds, the route is distributed to > the CE in a type 5 LSA. However, in reality, the route will be distributed to an OSPF process, that may cover one or more CEs. This brings a question: if a VRF is configured with more than one OSPF PE-CE process, should the received BGP route be distributed to all OSPF processes by default? Another important detail here is that the PE must _originate_ that type-5 LSA, i.e. create an LSA with itself listed as the originating router. > The VPN Route Tag (see section 4.2.1) MUST > be placed in the LSA. By default, a type 2 metric value is included > in the LSA, and by default, its value is taken from the MED attribute > of the VPN-IP route. If the MED is not present, a default metric > value is used. What about the DN bit? What about the forwarding address? > 4.2.4.2. Other External Routes > > If the route has an OSPF route type of external route, it MUST be > advertised to the CE in a type 5 LSA. Same comment about announcing to a CE, and LSA origination. Same question about distribution to multiple OSPF processes. > The VPN Route Tag (see section > 4.2.1) MUST be placed in the LSA. So, is there no way to preserve the original route tag that the customer may have set at the actual ASBR for redistribution control purposes? > By default, the MED, if present, > is converted to a type 1 or type 2 metric, as determined by the > external route property of the VPN-IPv4 route. Did you mean the "Options" field in the OSPF Route Type attribute here? > If no MED is present, > a default type 2 metric value is used. What about the DN bit? What about the forwarding address? > Note that this way of handling AS-external routes makes every PE > appear to be an ASBR attached to all the AS-external routes. In a > multihomed site, this can result in a number of type 5 LSAs > containing the same information. > 4.2.4.3. Summary Routes > > If the conditions of the previous two sections do not hold, then the > route should be treated as if it had been received in an OSPF type 3 > LSA. Hmmm.. How about NSSA and Sham link routes? -- Alex ===8<===========End of original message text=========== From rtg-dir-bounces@ietf.org Thu Dec 2 20:57:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26288 for ; Thu, 2 Dec 2004 20:57:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca2n9-0005g2-38 for rtg-dir-archive@ietf.org; Thu, 02 Dec 2004 21:03:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca0On-0003lT-0Q; Thu, 02 Dec 2004 18:30:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZwkf-0004qH-8a for rtg-dir@megatron.ietf.org; Thu, 02 Dec 2004 14:36:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20753 for ; Thu, 2 Dec 2004 14:36:27 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZwqE-0004vh-Ob for rtg-dir@ietf.org; Thu, 02 Dec 2004 14:42:16 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 02 Dec 2004 14:44:37 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iB2JZrNV017906; Thu, 2 Dec 2004 14:35:53 -0500 (EST) Received: from [64.102.48.185] (dhcp-64-102-48-185.cisco.com [64.102.48.185]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BDT05287; Thu, 2 Dec 2004 11:35:52 -0800 (PST) Message-ID: <41AF6E98.8030301@cisco.com> Date: Thu, 02 Dec 2004 14:35:52 -0500 From: Acee Lindem User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <1519182984.20041201235531@psg.com> <31742008.20041202110720@psg.com> In-Reply-To: <31742008.20041202110720@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: NOT GOOD: Fwd: DISCUSS: draft-ietf-l3vpn-ospf-2547 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Alex Zinin wrote: >Guys- > > Supposedly this document has been LC'ed in the OSPF WG, and reviewed in > RTG-DIR, yet I find an _awful_ lot of issues when it comes to the IESG :( > These should definitely have been caught by these reviews, that's why we > refer these docs to the experts... > > I'll stop grumbling now and ask this question--how do we make sure > something like this does not happen again? > > > Alex, Not to deflect the issue but I noticed you explicitly sent this E-mail to Rohit and I. Note that this document is a product of the l3vpn WG - not the OSPF wg. Ok - now back to solutions. Thanks, Acee From rtg-dir-bounces@ietf.org Wed Dec 8 12:33:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16793 for ; Wed, 8 Dec 2004 12:33:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc5ns-0002wX-An for rtg-dir-archive@ietf.org; Wed, 08 Dec 2004 12:40:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc5VK-0001iX-Dc; Wed, 08 Dec 2004 12:21:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc5Go-0004Mt-7k for rtg-dir@megatron.ietf.org; Wed, 08 Dec 2004 12:06:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14733 for ; Wed, 8 Dec 2004 12:06:27 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc5Nc-0002L5-JW for rtg-dir@ietf.org; Wed, 08 Dec 2004 12:13:32 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Cc5Gj-00073w-2r; Wed, 08 Dec 2004 17:06:25 +0000 Message-ID: <41B7348F.7070004@psg.com> Date: Wed, 08 Dec 2004 18:06:23 +0100 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <1519182984.20041201235531@psg.com> <31742008.20041202110720@psg.com> In-Reply-To: <31742008.20041202110720@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Acee Lindem Subject: Re: NOT GOOD: Fwd: DISCUSS: draft-ietf-l3vpn-ospf-2547 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit alex: my 2 cents here... Alex Zinin wrote: > Guys- > > Supposedly this document has been LC'ed in the OSPF WG, and reviewed in > RTG-DIR, yet I find an _awful_ lot of issues when it comes to the IESG :( > These should definitely have been caught by these reviews, that's why we > refer these docs to the experts... > > I'll stop grumbling now and ask this question--how do we make sure > something like this does not happen again? the question is how to avoid false positive, so the following ideas might be considered in addition to the one already in place as i don't think they would create any additional overhead (assuming as part of point 2 that two sub-sequent reviews would be easier than a single one) 1. keep track on documents that impact routing area protocols that are on WG last call, the webpage maintained by bill is a good way to achieve it - this could be a trigger for people listed in even if a formal review as not been assigned 2. when i-d becomes a wg doc. in a wg outside the routing area provide some follow-up (this can be achieved when the document becomes a wg i-d) i don't think this can necessarily happen spontaneously, so... a more deliberate approach would be advisable here if idea is to keep as objective to achieve efficient/fast progress. It could be possible to ask for reviews of document external to the routing area when they involve routing area protocols (when their status change from individual to wg i-d). At the end this could also be complementary to the revision of the document when close to be finalized and then have to raise flags when implementations are already more progressed thanks, - dimitri. From rtg-dir-bounces@ietf.org Fri Dec 10 11:36:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27856 for ; Fri, 10 Dec 2004 11:36:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccnrn-0008VR-G3 for rtg-dir-archive@ietf.org; Fri, 10 Dec 2004 11:43:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccnej-0006gC-4C; Fri, 10 Dec 2004 11:30:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcnRz-0003js-5V; Fri, 10 Dec 2004 11:16:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26660; Fri, 10 Dec 2004 11:16:56 -0500 (EST) Message-Id: <200412101616.LAA26660@ietf.org> Received: from anice-151-1-33-197.w83-197.abo.wanadoo.fr ([83.197.129.197]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CcnZ3-000874-QW; Fri, 10 Dec 2004 11:24:26 -0500 FCC: mailbox://fmbktyvvymwedj@hotmail.com/Sent X-Identity-Key: id1 Date: Sat, 11 Dec 2004 13:12:55 -0300 From: Henrietta Hudson X-Accept-Language: en-us, en MIME-Version: 1.0 To: rtg-dir@ietf.org Content-Type: multipart/related; boundary="------------040603040504080404020007" X-Spam-Score: 4.5 (++++) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: Re [15]: X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.3 (+++++) X-Spam-Flag: YES X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 This is a multi-part message in MIME format. --------------040603040504080404020007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

In fact did you fear cat in 1842

AOL Don't worry

--------------040603040504080404020007 Content-Type: image/gif; name="pang.GIF" Content-ID: Content-Disposition: inline; filename="pang.GIF" Content-Transfer-Encoding: base64 R0lGODlhJQKcAPOsAAgEAIAAAMDAwMDcwECggGCggGDAgIDAgIDAwKDAwP/78P8AAAAA/////wAAAAAAACH5BAQAAAAALAAAAAAjApwAAAT/sMlJq7046827/2AojmRpnmiqrmzrvvAJxHRt33iu73zv/ziAcEgs Ao/IpHLJbDqfrBl0Sq1ar9istiLder/gsHgM7pLP6LR6zRaZfYu4fCSvZ+rxCj5P2U/2gHYWgQsXhIeF HIGDgIp+GoiCfZGNGIQflZiLlpRzHZ2JjnicoJ4NpaGTmUpvPXsCmoiMdbB/r6pytai1EpR6qHG8d4DC p8Skh8i+tsDFxrIbl5+RhqXO1aDRm7/Nvda40kmtPLfTy+Cpx960ut/r1My7onjFgdfZs/jP8vHww+r/ zvWLdC1fJ0j2DIJqt3BguCPjdpTTpu9dMIe8JvLbhygjsAUF/9FdFAlSITSS0D6WtCjQ5EhlLTciRBWQ nkuCLDs6TIgkoo6JNQ8OZPiI40qjOpEmy0kp5M50PJ8ulUoIlkqP7m7ygYmTKtCgTbFt88qTH802Ir6K zSWgrQCA5aqyxMrWrV23c+1OvPuWHl+nTI/KFXkXoFG+6hD75cu0cFFuwWyurdt21au/ds1RrqyWY99c FhSzY3wYM97SbjujnQmaIlvIL+OWlXxY80sJpCcD5ho7al7YR2sDL6gaNbfMBj/fRneaGXLhJtR2pkc7 aMjizCvkXm07uO57owYGtup3aPetILDX/IxVefDLk7MThklcdXOF7lNhxHB/Loqvhs31GP991p2nH3ck qKeaRtTRMgpQpQAXXne7raXcO+4JsyBtH9VHC30VWkhea8yFSJYp8zQEW1ueubYcSqsohSKC6VWnG4EC OqjjhyfeJhRrL9qm3IggVbchjzJW5SGJw8GIH0tPSgWjej2+Jt+AUU52iIYt0eiid1k2mWMuDSKZ5Ff5 xRhmLJGBtqOPNpoXmD3XxemfVPVIBqCRg51pp5ZbOiObmWtOaWOaWHqJY4E39jMkkRly2ck1iErSaAg2 uRlMhvJlaY1TRzK55Yp0eQdhn1l9GaiIjgIJZpWU+qMoo7SKOSdRe06agV5qyonphwnxSaivCwEWKpy+ nWopdEmWmlT/iquGmaivWhXH67Sz3llrp83eOpxpIea3ZJApEgmsmccKtlivtrY7apXvCQvXYph5cFma vPVZ6FDgeiButosG9R2MuNpIZaLpmghOwSwaPGGJxGKrrULacYbkR8BV/O/ECXKIJcYBtwvTpQBzy5WE eRLjLJPMnjwfyWyuNOhyMRqmLMsii2TSyl3ltDO1HaPrsEwmF20SyiVXa2mHLklanqETdgOzvTzObKrU E7PLsYQ9Mw01gxW56vSMXu87ZyZYJ3220MU2TZKg7uwy7qvl3hmn3CZrjZ3XKulXNtEho61SyF+3hrfa PaZMEHg3D7tR24QLGQ+LLSptJdAtY841/50MY5ZrU5T7+WfOVoPkuZ3FPT6pwqupCHXoKCuOs0ygi03H xST+WTvp0x68+9Zbr765b9siBXzmyK8tr5KID2+nxYuBBffdqTZQaX9mu0hXqSFBP9rUxmdPgfeUQTxy aIg+B2+F0y0ucPZEXw9787iBqz762/GXf/13XWD//tarVwcAOED1GfB+/vuLBgioQPxhb4ENdOD8JNi9 CCbwfw+8YAYxuAEAEpB/GKSUAOlHwhKa8IQoTKEKV8jCFrrwhTCMoQxnSMMa2vCGOMyhDnfIwx768IdA DKIQh0jEIhrxiEhMohKXyMQmOvGJUIyiFKdIxSpa8YpYHEMAtsjFCv9s8QJfbAAXxxgADYTRAl2kABnL qMY1slECbkzjBNwIxjeicY1zjGMdMRBHNspRjXCkYxsFqcc7jnEDePQiGRXJxzAWMpCE7CMkE6lISk7y jJf84x03OUhNYjKPYhRkIxfZxj3m8ZCZPCUYM/lHS4YSlS1o5Rk/GchalnKUdXyjLHVpx1CaspKMDCYw b0nLRhoTl2i0pSqVyUlQ3pKZg3zmLpc5zE/OspfHfCYisUnNVzrzm8385jShWUtrcpOZmCzmNbVpTm76 8Zzo5KU2VUDLdXKynufU5CvlKUx8hhOc0IQlQH1JUA4Us6DJrCc57flLcfbyoOYc6DWxiUp/IjT/AxY1 KDwzmtFwppOi/GRkR+fJUGI+1I7WvKgYyQlQR540lvl8pylHOseLltGlx6QpTUf5UjPCU5hA9WJAWYrT bDrUAwdlKUFv+tClglSpQVWpUefpzJ3Gc6C2VCdT/9nSkJp0m0K1KVSTmtQVQFSm93zqKj/q1Jyqlapl rSpKfyrVhlK1pugkKlrtWlB98vWuS0XoF4v6VY1ydapYbWtUC6tUwpbSqinFqkt/GlnBjvWsdEXBWfUa 0I0qE62btak73+rTq/rUlYl9pFf3alJKRrSTlI1tTj+bVbU+Eq6irCQpQ/tajLKWt6MVrW8tqdVTFheQ ed2nQEkJWxgAd6a5/02mYh3bWuZG9aNyZGs80xjX1HpWnJytq3L9qlzEAtaRtU2vNDOr0u42NqasZK9A 60rdckY3qCXtqiebCl7xGhek5DXBc9OaWLz6kp8DFu9OS5pf9Rr2r3AMJmvl6tsCd9PCvAUlgnPrXqse lr57de9C4SvVwXqVr/UF8VzDWlWoGhKZZiXxcbXLR+NSGLrnJa1DXRtc/+YYoxIOL1lXDNYPvzfCk7yx ebkq4tAS2MK4deseaYziCV+WpEH28WJdTAKO9ri30jVte0983OtaucEphjBZN3nmE5OUyN7t51vhrNgl mxmpG51zT4t8Z86Cuc8z3rNYRXplxnJ5BOPsrP9E88lOXs7VzQt+rZd72mQSr/LFonXzosE5ZDgnms5p PvSY8TzcaI74wcOE5JtPbVcq95XOg65mntcL2BSgdrywJmppYSvorg4XliMVpSQNudtCjvadrhx2mW+t W3zOV7b+HTZu7+vjZPe4wjzVKnPLzGtnP9u6rs1lfB293/lm8dzoTre6183udrv73fCOt7znTe962/ve +M63vvfN7377+98AD7jAB07wght8igE+uMJfKO0OUNvGmFakAPp4Wxg7nNnETvh/MdvwXOZZ2+a+cKpx rXFoHegZpEh5PLDxgZAn+dcJD7k+KW7iTj86WzTPbMebW8licHHiOR8jYH7/jueHd7usNM+4G4e+xYL8 3OcVP2VIiD5uEQPqQDh7BuNKNYsQWfe/To/6fw0JdYrDgupk5wXaafR0u7h8n3eRudB7LnFY8KXt/Tvt boTudvLy3S1yb3rfA1D2fm3z2LD7e1vMvXa6QzLuJc+HY9CD8nx0nXvHKXrTM+4MxQMd5IR3vNRNo+q0 D5J1Ymi89fwueNFLvZ1QD3voQ6B6058+l/NrPN+1M3upl0D1um/97YePe9+PL/KqmJ+oaEao5RfJb+Ti vPR7Xniyw971xcd+7dFSe8YLf+SP37zxAznBx4tg+6MXN/XVn37/YZ/2sBfG09lv/lGqXfzEF0X5UcSy /zalTFJ9AYBFB3QSF3yEdw0z13T490rVd3jrl38Isn0GKHuFt0vy13tkd34LmH0ZCIHjx4Att4HwN1EY CIIcaIIcCHwi+A8e0h6/EICZ5xz8F309t4AKuIESiIM3+GgNeFrk1nkryH1B6E3tR38giH+NV371BwLo x4BTh11KSIRLqFElqIGzN39FGHEo2IFbOIUzEYUzCH2fkXwC2Bt0k4HXtHg2+H1aeIS9N4EXd4Vs6IXc gX5o14RrR3RIOIQnOIB694d0SHxvx4W/V3O5x4d3OISJWIVNmHxf6By20DDqcjUlYYZet3nih4lrWIX5 p4dvqIOcKG5Y+H6rYYd7GP+KU0h1E6UwjdiHpDh+eLiJJZdzTLiDQIiKKGiKn1iCo0gRoGKJkegNLuiI xgCJcXh2LoWMGBiLy5iJjlZ2O/dzOYiLa6CL94eLeeiMtdCKHkiFTsGM1/iNoMhsOceKu/eKS2iNHzh3 VHOGWjcJHtEOw2iMI5F12XeDLJKN2LiJ2yiHvEhztziHHxiBiniK4tiM/hiIw4V64AiIXfh+n4daePdB Hld+DamQudhHGYQNvxgvoVCPW7EpMegJ9tiBZNSPCHmQF5iQXTiReddJUciNaKCOGLmFiaiM5kiNrtiN sIiIQQh47DiQhRiKF/mQPbl0rFOS7wiJIimMS0mMxjD/Ipe4i5SjjyopiKEHhyG4jzqZBjRplOu4hzhZ i12JjmCZjj6pkxFplmRJgQ75lW03iKTQkWUYL1LZdcGolFhJlTyZimLZknxIiIJZhwUZOkVpk0xVljVp fw6Zgmk5lSuJeoy5k0f5hHz5crFAly8YlfAYldPDJU95ePJnmPzYmNkImIp5lqpZjUFogAsZmW30eTnJ kIEZYL1omwI5mYu5lZb5mkJZmZ30Kye3DsqXB8jCmXgZiXo5kLBparjXnOSnlX64kLMyjT2ofeOYmjLZ lwopna4XWylJTwVJlKBof+HIljGYnAsjO1u3ItOpm90JitD4j9oZmBvJBt0nkH7V/4uoGZjoOZht+Hi3 +Jw5doDc2ZanRaDdaJUBShEcOT0vgjrMt5w1qYKId53KhaGimUIGaKDEplu3OJ+zaYV7V26c+G3jCKL/ eYw+qKIBepsiKJeQARlLAqH7N6E0yJ0WelIxmp0a2pgNWooA2T0aOUE7OqIj2HEReZJKuKR/12xICaUY R50LVKSyF6ULiny4oSQ1Knlz6aUsSqW8F0fYc6RS+nW/maZtYKUlyqTwOUlISpYaqXQe6oP8OQFqyKQB SaYjWCFYuitrVKatqaU5EYVa154cCabeCKTdpoRmenRBqaP+qQak9wEWhD8aFAL3uSv2o0GbiqcUCUIb +T8i8P+pomqo4/OSmKo/qEpBuzGqUfhACMSpgHGfl6oxmaoxlbqqtLpwvvqrwBqswjqsxFqsxnqs/EYA yrqsyoqszipFzNoAzDqtzfqs1ppE1Cqt1Jqt19qtQzStErCt3Oqt5OpD0yoA4kqtklmu7IpC55qu59qq 7TqvKgSv4jqrQjABRBAC+aqv+0qvALsF9qquCPSvUuATF3Cw+rqwAduwWDCwzKqqDWAGM6CwHkCxEtAF COuwHJsEEKusqtqvFNCvG8uwIyuyJduxKusDEBuyHJCyPqGxKzuzTvAXy0oaIqsBJZuyE0uzPqsEIVQL PNuzFkCyE2sECfuzSsuy94qz/Ir/sUebsSOLATm7tFYbAx+LF1Wbs0grtUTrtVBLtVc7ti/wsdXaChb7 tW9QtT0btlQ7tGQbtxhgtsyKtlOrtnebsG6bAXArt34brnS7rBXrtVMrs4Qrtia7AX37t2QbuBGbrxGB slELAkO7uIy7tPCKrvYqAGz7tiOws197uaI7AZs7sPI6uW6wsZ07uozbtG5hui9ruSers6xbu9pKsP2T uU6xuk8bubbLutv6ujd7u/fKt7L7tv8aur/rt65LAJpLAIDbtEV7vDqbvNS7vAHbvMS7ucXAuyhgvdjb usHbFtBLt6HjvSogueErt7obvS0rDJB7vcibuOt7te3rvtzL/wVDEAUVq771O7YDi6dZOz+DuwJFYLhZ oAD/C2+wS7rvm7QGzLbyywMHMAALzG4tW63b27Qoi75PC8FaoADKasEXjG4ZrMGmy7ka68GUOw4TzAMD sKwknAMMUMM2XAE1nAE2fMMWsMM5TAE/3MMMoAFBjMNDPAE+7MNInMRHLMRM3MRG/MRFvMQ7/AFTHMVM fAFV7MRKzMVCvAE87MQYkMRanMVcTMZMS7A3u6wOrLuc669oe8BwLMcZ68LJewUJwKwzTANS3MRXTMVh LAF9vMRlDMZQDMRQPMiC/MRlzMiNLMVY3MUc8MeAjMZY/MiSDMhfTMSBTMVnvMWIbMahLP/KPNC0awyy sJDCb1zHcdy1B7y/day3sJwFCDCte+wCnRzGlEzIUdzLi7zJnDzGiXzIwLzIxLzLk0zMnhzKHYDMyHzJ xdwAuQzKv8zJV0zN0jzF0+zLvLwEzeu8N0u+3LvKR9vK1vvKK4zOd4wFBkCtt6wCnYzE3SzM3IzD85zN zazM+HzP0bzPiFwClBzP2azP/6zDBG3E1VzQCv3L2nzQ+KzN/jzQjbzQCV3RHiu94Ay94jzO6Ty9rozO c6zOL6wDIrytCdACz2zR0ZzSEc3SEb3Qz3zNx+zQwVzI9GzINZ3MKi3TCB3IMT3ERZzDQU3QQ73SNL0D mcs/1jPA5Dz/yyHdwa/81CBNAgowAFZ91Vid1Vq91Vzd1XksriedAi790xRt0Pxs1jat0gi91mVtxcpM 1jmd1jj90nTd0BVN1kUdxHBd14fs0jlgr6Bqvm2xth59zlHNyiJ9vF/tuIztuGFtAmPt0EWdz2pt0Ips zKLM05GcyWjN1jfd2ZjM2ZPNz3Yt0ZXNyz+c2n4s2att1I7cAwHM2G5B2Pr70YddzoldAovd2LxttgoM 0EdN154d2cJtzZBcyZJc2puNzZ/d1s591siNzaNt0Zrtz3Ct2gm918od3QKNA6bruHZB2ydr23SM2yKt 272d3gOLAL8N3B6w18X9ySAQ0MNsyJbs/9kh8MfwLdf9LNcNfd/zjN05Dcp6zdrczd8Xrd4RO9tcUNhO rbiJzcIYMAAGUOEWfuEYnuEavuEcXgDpyt5iHdzwHdlA7df0/dyY3d3xrdP9jeIrntLVPdDMfddHrN26 3NoDDuDQDQQKHq+D3eC1vc7VG+Ff0M7UCuLwLOIGvuNsreL4HeBLXtl+3d/73eKnzd3Trd99XeJzTeNM bt31beU83uPOO9u3LdUfEOESzgS1PK1IzgIsvd9xPsxHfeJfvt1fHtfPDeMHzeev/dIx/tBR3tJh7t9b LuZjrt53MdXjLeTGS+RaEMPM+uYoHdB3vuX6jOPLrOdQ3uXGjOic/v/pYuzpiG7ngI7nMk7qw63lhS7q ef4Dir7oZ47YDz7kuZ0Fkq6slP4C06zpze3qri7Tgw7Tw27ar/7rzJzsqu7ipi7sZT3jKP7f9czXrV6z jf0X6uzga67mI20DJU0Aux4Dlz3IAD7ub+3MmU7nmX3u6q7jCD7KnG3ZZmzun83qZ+3kLz7TpKzWN/7n R2AX74vt3D7wBF/eVtDO4V4D+07u8b7w6U7U6Q7vyf3wWF7nNO3uwuzIiozuUi7g0y7m9D3jIZ/i8Q4E QWsat67tBZ/yVYAACV/C63by4T3rtL7yBX8FCtDeME9vGMToQW7zNr9CfTz0RF/0Rn/0SJ/0Sr+g9Ezf 9E7/9FAf9VJ/2Veg5sgL9EC/87Vr9VeP9Tev9aPL9RDu9dwO9uTa7TWf7SRA9l1r9taK9uYN6em78m7f rXDv9fwr93XvrHfP9rX+uee998/a937f9oBP84JPrIRf+Abfu4af+IrvAoyv9ofv6JAfrIs/+Y+f5pt/ +cCa+Zr/9xfb+Z7vq3Bf+ol/+qiPvV+/+q7vBq8f+7I/+zYQAQAh/nBocWdodW1lYXlsbmxmZHhmaXJj YXRtbGV5cXN2a3BhbXN2Ym12eHJsbGl2ZmVka2ppZ2F2eXgAO3== --------------040603040504080404020007-- From rtg-dir-bounces@ietf.org Mon Dec 13 07:05:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27776 for ; Mon, 13 Dec 2004 07:05:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdp5J-0003MT-Dn for rtg-dir-archive@ietf.org; Mon, 13 Dec 2004 07:13:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdowW-0004h8-IJ; Mon, 13 Dec 2004 07:04:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdosn-0003jJ-Sn for rtg-dir@megatron.ietf.org; Mon, 13 Dec 2004 07:00:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27454 for ; Mon, 13 Dec 2004 07:00:51 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdp0X-0003F3-Jd for rtg-dir@ietf.org; Mon, 13 Dec 2004 07:08:58 -0500 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-green.research.att.com (Postfix) with ESMTP id 6598CA7B00 for ; Mon, 13 Dec 2004 07:00:18 -0500 (EST) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id iBDC0Hmm003736 for ; Mon, 13 Dec 2004 04:00:17 -0800 (PST) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id iBDC0HcX003735 for rtg-dir@ietf.org; Mon, 13 Dec 2004 04:00:17 -0800 (PST) (envelope-from fenner) Date: Mon, 13 Dec 2004 04:00:17 -0800 (PST) Message-Id: <200412131200.iBDC0HcX003735@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Subject: IESG agenda for 2004-12-16 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2004-12-16). Updated 2:25:51 EDT, December 13, 2004 ------------------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date TSV RTP payload Format for H.264 Video (Proposed Standard) - 1 of 2 draft-ietf-avt-rtp-h264-11.txt [Open Web Ballot] Note: Last Call and ietf-types review ending day before telechat. Token: Allison Mankin A Negative Acknowledgement Mechanism for TSV Signaling Compression (Proposed Standard) - 2 of 2 draft-ietf-rohc-sigcomp-nack-02.txt [Open Web Ballot] Note: Last Call ending shortly before tlechat Token: Allison Mankin 2.1.2 Returning Item Area Date INT Transmission of IP over InfiniBand (Proposed Standard) - 1 of 1 draft-ietf-ipoib-ip-over-infiniband-08.txt [Open Web Ballot] Note: On agenda to check if Ted's, David's and Thomas' issues have been addressed. Token: Margaret Wasserman 2.2 Individual Submissions 2.2.1 New Item Area Date SEC Algorithms for Internet Key Exchange version 1 (IKEv1) (Proposed Standard) - 1 of 2 draft-hoffman-ikev1-algorithms-02.txt [Open Web Ballot] Token: Russ Housley SEC Using CMS to Protect Firmware Packages (Proposed Standard) - 2 of 2 draft-housley-cms-fw-wrap-09.txt [Open Web Ballot] Token: Sam Hartman 2.2.2 Returning Item Area Date APP A UUID URN Namespace (Proposed Standard) - 1 of 1 draft-mealling-uuid-urn-04.txt [Open Web Ballot] Token: Ted Hardie 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date SUB Framework for GMPLS-based Control of SDH/SONET Networks (Informational) - 1 of 2 draft-ietf-ccamp-sdhsonet-control-04.txt Note: Participant in PROTO Team pilot: Workgroup Chair Followup of AD Evaluation Comments http://www.ietf.org/internet-drafts/ draft-ietf-proto-ad-comments-pilot-00.txt Token: Alex Zinin IAB and IESG Recommendation for IETF GEN Administrative Restructuring (Informational) - 2 of 2 draft-iab-iesg-adminrest-rec-00.txt [Open Web Ballot] Token: Harald Alvestrand 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date APP The 'tag' URI scheme (Informational) - 1 of 3 draft-kindberg-tag-uri-06.txt [Open Web Ballot] Token: Ted Hardie The 'info' URI Scheme for Information Assets with APP Identifiers in Public Namespaces (Informational) - 2 of 3 draft-vandesompel-info-uri-02.txt [Open Web Ballot] Token: Ted Hardie APP Synchronization operations for disconnected IMAP4 clients (Informational) - 3 of 3 draft-melnikov-imap-disc-06.txt Token: Ted Hardie 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item NONE 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review Area Date RTG Dec 8 Path Computation Element (pce) - 1 of 1 Token: Alex 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review Area Date OPS Dec 9 IPv6 Operations (v6ops) - 1 of 2 Token: David RTG Dec 8 Mobile Ad-hoc Networks (manet) - 2 of 2 Token: Alex 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issues From rtg-dir-bounces@ietf.org Fri Dec 17 13:23:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17517 for ; Fri, 17 Dec 2004 13:23:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfMuE-0006Xl-Kd for rtg-dir-archive@ietf.org; Fri, 17 Dec 2004 13:32:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfMeu-0001xb-F5; Fri, 17 Dec 2004 13:16:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfMXO-0007zX-2Q; Fri, 17 Dec 2004 13:09:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16272; Fri, 17 Dec 2004 13:09:04 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfMg0-00064N-9M; Fri, 17 Dec 2004 13:18:05 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CfMXI-0009qh-54; Fri, 17 Dec 2004 18:09:04 +0000 Date: Fri, 17 Dec 2004 10:09:03 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <62105905.20041217100903@psg.com> To: iesg@ietf.org, rtg-chairs@ietf.org, rtg-dir@ietf.org, nomcom04@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: Alex will be off-line till Dec 24th X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit I will be on vacation out of town till Dec 24th. I will try to make it to the NomCom calls. I should have no connectivity, but will do some e-mail once I'm back. Alex From rtg-dir-bounces@ietf.org Fri Dec 24 02:20:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22781 for ; Fri, 24 Dec 2004 02:20:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Chjuo-0004PZ-7j for rtg-dir-archive@ietf.org; Fri, 24 Dec 2004 02:31:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChjiV-000103-G2; Fri, 24 Dec 2004 02:18:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Chjh2-0008Ra-4T for rtg-dir@megatron.ietf.org; Fri, 24 Dec 2004 02:16:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21459 for ; Fri, 24 Dec 2004 02:16:54 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Chjr4-0004Ka-6u for rtg-dir@ietf.org; Fri, 24 Dec 2004 02:27:18 -0500 Received: from cc614362-a.groni1.gr.home.nl ([82.73.114.210]) by mx2.foretec.com with smtp (Exim 4.24) id 1Chjgz-0003zm-Ei for rtg-dir@ietf.org; Fri, 24 Dec 2004 02:16:55 -0500 Date: Fri, 24 Dec 2004 03:16:42 -0400 From: "Shasteen Blakemore" To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: X-Spam-Score: 4.7 (++++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Subject: Fwd: I owe you one X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.7 (++++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable We gasped for breath Stupefaction more than fear made us = dumb and motionless!!=20



=
Image not loading? read below:
The Fleshlight Sex Toy is a portable, conceala= ble, sturdy MALE masturbation device that our customers describe as "Awesome= ", "Amazing", and "Ingenious".
Cleverly disguised as an ordinary flashlight, it's easy to store= and transport without drawing attention.
Available in a variety of styles =96 Mouth, Anus, Vagina and Non= -Descript =96
And offering a variety of special sensations =96 Original, Super= Tight, Super Ribbed, and Wonder Wave=96
The Fleshlight Sex Toy presents our clients with a multitude of = erotic experiences, fantasies and sensations to elevate orgasms to a ne= w peak of intense sexual pleasure. - ENTER IN HERE -







Discontinue No money shall be drawn from the treasury, but in consequence of appropria= tions made by law; and a regular statement and account of receipts and exp= enditures of all public money shall be published from time to time!! The o= cean was watched with renewed attention!!! The person having the greatest = number of votes shall be the President, if such number be a majority of th= e whole number of electors appointed; and if there be more than one who ha= ve such majority, and have an equal number of votes, then the House of Rep= resentatives shall immediately choose by ballot one of them for President;= and if no person have a majority, then from the five highest on the list = the said House shall in like manner choose the President:=20 From rtg-dir-bounces@ietf.org Tue Dec 28 00:23:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10019 for ; Tue, 28 Dec 2004 00:23:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjA0m-0006y3-AB for rtg-dir-archive@ietf.org; Tue, 28 Dec 2004 00:35:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj9mQ-0001eX-Ng; Tue, 28 Dec 2004 00:20:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj9jN-0007vR-Eo for rtg-dir@megatron.ietf.org; Tue, 28 Dec 2004 00:17:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09350 for ; Tue, 28 Dec 2004 00:17:10 -0500 (EST) Received: from ppp-104-120.i29.net ([12.28.104.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj9to-0006lI-49 for rtg-dir@ietf.org; Tue, 28 Dec 2004 00:28:26 -0500 Received: from guadalupano.com (guadalupano-com.mr.outblaze.com [205.158.62.181]) by ppp-104-120.i29.net with esmtp id 42013CD704 for ; Mon, 27 Dec 2004 23:23:24 -0600 Message-ID: <001001c4ec9d$4748f3f7$c71d780f@guadalupano.com> From: "Tiebreaker H. Claudette" To: Rtg Date: Mon, 27 Dec 2004 23:23:24 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_94F8BBFD.86586D7D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-GMX-Antivirus: 0 (no virus found) X-Spam-Score: 2.6 (++) X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Subject: =?windows-1251?b?z+7s7vn8IOIg7+7o8erlIOvz9/jl6SDw4OHu8vsg6Ovo?= =?windows-1251?b?IPHu8vDz5O3o6u7iISAgKODv8OXr/yDoIO/w7u/g5ODl8iDi?= =?windows-1251?b?IO3g9+Dr5Sku?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.6 (++) X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 This is a multi-part message in MIME format. ------=_NextPart_000_0012_94F8BBFD.86586D7D Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_001_0013_94F8BBFD.86586D7D" ------=_NextPart_001_0013_94F8BBFD.86586D7D Content-Type: multipart/alternative; boundary="----=_NextPart_002_0014_94F8BBFD.86586D7D" ------=_NextPart_002_0014_94F8BBFD.86586D7D Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable =e2=e8=f2=fc =e3=ed=e5=e7=e4=e0 =e8 =e2=fb=e2=ee=e4=e8=f2=fc =e4=e5=f2=e5= =e9; ------=_NextPart_002_0014_94F8BBFD.86586D7D Content-Type: text/html; charset=windows-1251 Content-Transfer-Encoding: quoted-printable
3d=
 
=ed=e0=e9=e4=e5=f2=e5 =ed=e0=f1=f2=ee=ff=f9=e8=e9 =e7= =e0=f0=ff=e4=2e
------=_NextPart_002_0014_94F8BBFD.86586D7D-- ------=_NextPart_001_0013_94F8BBFD.86586D7D Content-Type: image/gif; name="producer.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="producer.gif" Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhmwINAcQAAP///8zMzJmZmWZmZgAA/wAAAP//zP//mf//Zv//M///AP/M///MzP/M mf/MZv/MM//MAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAACbAg0BAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum89oZmHNZqeLa1b8Ta/b73h0e5/3zVV/fYKDhIWG PIGHOoknjIqPkJGSdY4lAmsCJpcDmSJ7bp6fBSMBlwWcoZ8AgX+la6gjAgN8JwGzAyW2AwFr ugEkvr0Du5aYJH+moqujIrPMe7DLx8wArqedIrK0JaLUAKbYy96g2cYjf+jUlZPs7e3rzW24 IrZtnd3nytWfmfiszLz2dErWppY8Ut160UtY4Fc8NvOkfWMoMeAzfqGmLRRYTpUJfNWcvcrX cCNAkafy/6nMyNKdy5eSPnFyOHFgyZr7LmpsKXGWw4A7ec7xuTEUTUdEV9nMZOrXpaUTSz4t Z9PhUJoSWQ6b04rrOGZJgS476m0ly03x7hUQ0KkeM7QAZqk1mw6m3buFEjqcdawT349fzWal x/Zf0MHVCoO9ibjRvL9ZU8ZVp+7xuLm2uAVeJZbVPMPAFMcj22gz5FWf1/o1Fe9YarqUIWLF S7v2mERTxdFyBHrwH5S9dRd8ONzicBTD67JULhGkbM0aLzXnmGobcID6oK8E3etZ583M0+2Z bbu8eSyMvHrkvdn321MBfgUHuSl+VrfkSnuF3VK584ZraZdRgOo9Jxwo9clHDf9+7O3E3SgN 8TKdg5Txt1BE52WoYRTpLYbCaYIxN2GI7Y3YEi9zmQCZZCtW1lp/liE3yiVY/cOLgidK9mBQ KPJE4ouevMYJWz2N81p/FQq24ZJMHoFbgDjtM89U3wX14F7zgXeTM+dE5MhUuVGpUJgBBuQU lLnx8lqPJMKy33ZaYumij0K9Zxlmw/RjZ1pIWihlk4AGKkRCJABX6EHuiYPhHATll2VHtNCo JEkKVeeRpdtMdhyjjP1zU4FspHiWPpLSmShxkkljZlYoeckQqJUKKuusN4giAFbWEEOKM9gY 9kqN1IAjVp1BCcvVomXtCh8ww5jZLLO7CKMrYb+uxKb/e65aGk1vxj6DbGk8CgvnieJiqg80 5NGq7rrsgrsCPO26G++89NYLb2P1ypvvvvwCeu+9+QLc78AEu/NvsgULXPDCDDfs8MMQRyzx xBRXbPHFGGes8cYcd+zxvsRk1oM2I31cK8Imp8zuLT4Al67KLigM88wQX0szDTLfPDA04Uxz aVTh/NbKJr0GazSUMqqSapCR6dRnLOa0xCVgE2GY2CvYyDJZz0BTWlCDVD/kNShCo+xKNB0V rfSMqS6N2tg/svrmRFAjLRzaOevMr636WSePVdiVbQ6ni0GUAj6l7qPnuE9rWnJF+eWTjK7G DU7ysqgS4w/CYFs09puen4AS/zatKrj25GfSdO2lO+bkNGuOY863qXo/3BXnm8Ell1ZTi+m0 rmS+zF1EkvqXpETB887enaMVhRrzVfMZt4A7bXX8iNaf4Hs50NcJfaqJH9969j05pDuUt09a u+1G6jtU+6oC6CHVWgOplIw7Scd0042/31dGNwLb/kghmrF0yX5L81S18BWHAF5vPw4UHcJO k8ASSUZ/b1uInyYUQWnUbzKuEUq21jcxjLjPacthm4l8hqyfHWYOPWITUar0tP/QTYBy242W XviV8TBQhSLaj3RwOL1TsSSGSCsFbNYDxItUkEL2OAwJ2fe3ExJLGgRCoUaQBpKwSa0hpaoc Co3HxP/74ZBTu8ARCBl3xRzhokFZjFsc4uhFHtrRLD5JHJGQVEY6zrFoUDQQvqa4sK5Y7YoU TM2NigSuUoHocO1B0WnqMzflPNIoJTnjkUaFkBgdsIhzxN0ig3iRUU7wlCEEZUQk6Y1pkRKT aoyDI+FnSPURMmELOuOethaKYYwqE1ViU5rcVkRnHDKFFhpmanz5Q8sATk4Xal70eDk9NTVz kw9i5pfKhEbpeU+aDyFepx54EW3qRJgsQl8uUXbLhs2OeoJrW6XieaRZHoeFh1mVu15FDUOl AnClmVzd/Ga4EbQKnp9Qo2Y+BaHHTYehH0JU7Kz2D4ECY54UeRBEkbclib7/M2/tXBfP8GcW a9wqHyMMSdRgCKVcpWuBPloHrC7lUpSqTxhrwYopouWNclErpwg10PJUAtPppDQXvAoNJmZj I7mQRzybo9AIWdoWn47UliHN6hOsOQWQngceXP2hVsdKm6RIwavmgYdZiUjWtsYkamdlp6wq ESop0s6teC3E7qqA1vJUYq95DaxgB0vYwhr2sIhNrGIXy9jGOvaxkI2sZCdL2cpa9rKYzaxm N8vZznr2s6ANrWhHS9rSmva0qE2talfL2ta69rWwja1sZ0vb2tr2trjNrW53y1u8Zqe3N3ML 13hbFrkCt2NKPO5HuKFcmp20ucdg7irc08PqkoRS/6nw2QaX64mF9vAc4O1udmsYXp+pI7zn 5d94pyve9MZGRS56k3w9VNMD0Wk/K3rje+xGAm2kCBm78wg4+JNf7wKYiyj0r1ZGUd9p6IKA C2wIYL+x17VRT7zsXah2hTNddJR3U+gNcXuh2rcSXxfD6RXHdnWz3oZuuDovTppxuYveZ6BY xO29cYYzbOMRY5W9yXIvjoXs4+WU98M6dpp/hlzkHu94Ir/o0XyjkpH6PVdHSg6yTiQlZbbF hzFQ+/LiYEcjNiEjQgyNsixLYrMR3WiRHuSUmD04JasccqlosrNR4PzmcSopPfdlMop7nGIn E5krOU70k3lMY0PrGMg1nv/UOCIN6SQj+XBHloN0iczoHTsZx5um9CC7y7lMV7rT7hXfolEt 4koG2dLNefQ5mJLJLGsKk8BwCzIbI19a4+gvxARRHKb2SKHtzxiwC1Didg1sIfnPwd6Iz9Qc tEpdN8eT8vzzq3nd6EszetKdrjSiCy3rcodb0Kce47ZhnW50yzXFLShukkHs6UEj2ryWInWH AYGyeybn0rvZ93lxB1UbQ0jfB4cxhwWu8EXzBcvJAaN6sNHlXVfRviCE+Ny0bY37xoZsOYXd w+9s6+l0HDF1XcjitEPVEU2Zj8sCdMKjK91wkxvcHzc4kMG9c/b43Lo2zzfD181qRXM6U4DJ mbz/ix7qVoOa0+A9+LtXffRHfxrh326EoO8t9XajmtDmfoo6U6jfAf235A3E8i/H3mz4aqbs awxKsQEkFrFz7U1tXwbchQ2hs4dN7YzMYN7Vm5IOYdjU5LZ6vYMe632ze92QfzyosU70qjMe 3oAwdeZpznV0i9vIlBZy1zG96EM72uiUp3m3v57j0Ss59KjPBRsAOp2Vr7k1nfF7BkE3ewCi mWvF0+/Kg98S4o9FfiZ5qtP6DLjhZ7Ls+uPLsCQnQwaz9Ms/QTNplgN3B60+8Y0/PPhf//nY qz7yO1c8q0evetZ7ffybXzXpQ+wpc0WGqIfH4onLj5xM+zvhhNJiiiZ///T2fkYHgFu3fxpm cbXme8CUJ3M0VUKlbkkyYNozOA2YNoJhgfonHvsULHmSDwplgWn3gJzQIdeiC7DTNbEQgksU c+i3gOv1bUt3IKdneeRwT9iVdIHhRKzjYafmfx5WfzaogFrWV+3Xf0loFzPmBSyjBU/ohMTU VU1IBv3mf1+laUu4hT0wYzWIF1XIBWaFBWMohmDGV2EoBleYf2kYE1qoeXCICCLVhuiBOXU4 LVxQVFaAhFqgZbNCh9AViII4iIRYiIZ4iGUwcxxDADvAiCLgiDEAiTUgiSVAiTAAiIjYLpGj MZYIiZaoAp4IAJ9IA6MIA6X4hpmYiknQiSNwiv+V2IqP2Ig44Irxp4q18X/wJ4D5N1584GL7 V2i8gXiO8nMxloPXQ16t910uwIgE4IjNyIzNGIvRGIuwKI3TKIrXCI3VqI3Y6InZKIrg+Ijf eI0kwIzhGI6YaIuGgIMA12oxmCQ36HlFdn7mxo7zaHigJ1/mhgLT6IzViI3U+IrUGIoD6Y/h 2I8BSZAIeY7OaJDl6JCOmI7qSAiY53UGyG2rV3qSt2noV5FQN2+SBo+gZ5EroJD/SJDleJIq yZADuY0raZItGZAriY4TeYvDeG9fRzaOt4XjB3I+KXOll4PCCITmpXOKmHoMl5OJsIkwyZIy mZAzCZExeZCt+IxS6ZT/KBmVu1iTLmGPTLcdNEaPsfeRLPd9iDd5Gsl+Ued4nTeAy+iSUPmU TjmXV1mX//iScHmOWil/XMkOpqd+qbaLPZloOHl63ldzhtmOY5mU0eV6hAZ2W3kCTemNT5mV KNmQMTmZeWmXcnmZfWmTvmIuHriPjhJ1PWh1wSiYN2liMyiUQUiYlkaELaCQmAmO3ziXACmO oXibtFmVnqmbvvmbuhmRn+kxEqkIxxmJPUCLM8CcxRlSybmOs2iV1Fmd1nmd2Jmd2rmd3Nmd 2Pmcxqkh0fkCzkmey1me4Jme6rme7Nme7vme8Bmf8jmf9Fmf9nmf+Jmf+rmf/Nmf/vmfABqg /wI6oARaoAZ6oAiaoAq6oAzaoA76oBAaoRI6oRTKg5vYJDoIM0eZBxvKhBeqaeMpUjUXKCEa MR9qBydqMCdTorTyhf5SoVTAohSzdL6oizwmmypmob/4YUTpRFq3lbhomi+Gi++1kTnKXLLp mkcaHqkZlElaYz2ZeB7Jo6Vmb95WpOolg0tqmj75ozeqjDoEdB3ZpB83pPfnlonZbWHqpVjq Na2pk4g5g+jBkYtZpyS5keRXflPKQIAJmRbpp/EYfn7YbocmaoXJXYBWp4F6kVzXkWdppzh4 jEz3mFdqluaXi1fHf+/Yp3ZKmFOnfhppfmJZdNuWpnvYdBeZqnE4qf9NtlxVynlVKqWPKqus mn7nZqSweY+mqkX1qG+Iipbkl6ihOqruBpKBRnpj5G3K6pag6qdrSZqLR6uqKm6fynjDaqrW 6qy+equnynkJOGJwyoV4ypZ1xGJISnWASaU+6K0LF3AAmKGpZow7CGmOuYlq2XDmupQ/mamu t5Nuiq9Cl68A92/3SnU6OXM5p6MK96q0uik8V2o4p5g9VyCtx5eXOpSgwqaK6bDEegU0+q2v Oawa6378aq1g+avjerEhG5ghK5bsBKhI+W4lu5jSyq+Ueq29CqnAypiPaqvgN7Jkma00u6zb +qcpy5aZmnSVGqcWK7QG+LMeS6epuqi7unX/MKung7qpimqYV8uyuwqzhVqxCKiagumOuXqo JDuSG+uogpqABfuXbZuz1NqsG+t03Cp+S+uV7xqZGbmnd0q3jLqPMRpqSbqmRkimO2qlIBmD 9vemp5mvwFizCiikv9ijQGhoiOtdW7S4qCm5TKt/nztHooml2vqmRju5qPml7QdyUCqlMvU5 h+u6bXm3ynqhkauEvBivspuIMiCjXTWiYeC7h4h5wou7GEOHxQsFLgoGyUuIxIsEzSsoyGsy 0QtdfAij2Ju92ru93Nu93vsE1fu9Dxq+4tug5PtZ7uq5R7q++6q5lRuSxiimSiu371hwiWux t5uRMlaMGbukStpQ/5GTv70Ism1qu+o6pKu5gwSXbwVIus4Lez5LwKDqsobKtqTKtHsqrFSr eMZlebD6LukKuHCLrnGbtjrLreq7wbk6qg27qIFoj2hLllCbsyJipKWLZLEKsT3LtU3rwaKm hNLKk7BGlB9MwhF8whXprzxcq/yneS3Mbi/sthPrgzarpPimwDxrw+BqQejaoQj7ff4mB/9W th3Krl95ZBE3hHfbr2o6xUKnuzpcrOZ6eQ3HsEL5ruEaxWPZtWEJpEBLf/6qxXc6cPukdX6b tGUssVkLwnTct8aaxLN7fnzcqYZsxnprty3rusx6vp7ltfkowSa7tkhJwUP8rIv3d8Z7yf9F +8dki795m7c3iK2zC4xILI9o/Moqq8KXd7WFKHopjKOlyYOb28Sd2x91vJS4u4b368D0i7q0 W4SOu7p4nIuhywqKXMzObG8OW6YndrkJrM1XSsTDyyTpWLzhu7y28bzlK663WAPmbATo3M5s uM7sfBdedb06g8/0vM/83M/+/M8AHdACPdAEXdAGfdAIndAKvdAM3dAO/dAQHdESPdEUXdEW fdEYndEavdEc3dEebYgZaqJNK1rCNQbEcExkUA8obRsnHW/1XEj6HFnJVQa+8AajNFy2UdMx wMkC/VwWg0EEo4wdJtRfQ6UMfKb0StTf3MDuJs7za6Nci6NEu9T/23zFkUpXPTpvVPxkMivO RziaCyvBhssN9RAOHEhh6pTGoFBTFrZCHPRzIGg3CiYT8YV0brZTs3FJfnLWCqZSrJsVHHhx 1VNcy4fXA1KjgW19VWjNrfqVeUrLc9t4quzBNxu013zEU4uoNajCDWu2KPytS8zV8Xd1Fhy2 jErNIghnZXYTq217JXdlKfVy47KCW4Qd2FcOc8ZRaubaf/cWeuYauaEZavYetw1lPQJsr619 uxYdJHcWvx1Kug1na5aGsQqymM3CjZ3ZqLrEebqqbIu2Zvyjr7vdIQy3SSzFgOvdk1faTPbE E8x9L5JOLFdy1WBthMer+MUbe+ct9tMf/77m1iYibfqa29NAa/Mj34fCgPG9JsTUHR9ICtYG 3c+mdtMWM1i8xZ/GxqGLdbVKpHXcjmN7xcDbrjuJuThZybhj1XK81UkZ0pD71wHLzV0t45bK qhHLmAk735gSU2iHHSvXNGqtOaU0fSrncrwqN7t35B5RcRQCGLeSbDqEVBGXQmp9huIwXEvu Ry4GK3umdEeLxjesydo92QO7yT0rjOIXw/zGt5xdt419yLHpxDg82jfG3qhH2I+9qnn3SHyn 4CZiPPDtFd2HECu354NaE2PHaz1eAsgNGB3E52VhC7wdeNRGNfxl5MgE3XFnU//Crvro2Lws kpI9yZFN2Z8sqv94OrN5XpakrOal/OazGqihTcjz52h2HoRrCN4VyXy4nUHE12sLlhMWIl9w ZwyMoD/Xp9rPlyMY5XHBTuR9dnd0J2e+vuzmtGvGt3FVlrX0tR+anu109C7DmNRmGs4Pi9QG p9ShOccBmL9zrKX/22gIm7n8+6eVlOpYPeaMLbCqSWI4m7u3LN61Wwl8DVckqBPZFhInKD5Z Vi1eoVCimQ0uqIF1Ao/cTg8QmCxnjX9nJtfItlGkslKCpBJtBjoZH/EUb0D6XL1NyNOF5fJ9 vCRENwNR2AcwH7VE0PKvdfMvnc4xHwNliAc8z1dw4NLvGdN/aIcfvfRM3/ROz9AlnTH/LQ2a FBsig5Kixon1MzPTG6PTtPGFkJm8Q68uPEdCPj2RYL/CPzD2LTpWEpZEhh0P07LxRsFMKT8Z ukI4gFR8cMVGlEI5ce8/9TU3fT1lRP7U//q/jSqny2xz8a7Oq1uxtZ7NdyzU/D7UPqa75W7v BNdvChS7NZvVzSqsJAXk/Kvr/m5gsSviHxrvW3qpoh+5Hazc3/DbI4fbcFbg6FTctx9nxa0Q dUf70YGPjPLcM1Jnx/Y6vxdnWwYPkOzmYb/DZwvDQpjHop7MzSzZbq6n2d3mJTzV22/q2m3C om271+/943/ZnV22ZwvKMIytlU4P9r0/g7cd2EZRzpb8Br7g/1QDAkNRAKU5AkExmEEgksCo mumLyjEu1jkAl1DAHjFYjPV0shqpeXomiU6jj4qcGpHQLFMa1G7By6gVKh5fx9x0ld1VK9vb sLceh1O55T3eegfjqJ1c/eXR9bG5HSYe8YkxuhX2vTHKGR7pxKgIVH0FfI0EDn6BhjIVfOaY thUIBAjghK6evoqWopZssra28MbKZiahwma62ErNvpWSCmsB1512Yf0BCjY6e90NzspCS54V Aoo6ZY6vPi9NoZ8eW++ta09z50Wm35Jd2qt3u6t+8/PD960RmoCLsPmZB+ccQHvLipjgIYMF qyQUJUKMdfFMEIpCdHhEJTIGRkwsjv9pZPZLBqeKLkvmOJlJJkR6BBEJIjcH2hNCNvFg49hT 2TtvP5UNtDN0qE80Zp764XPzEUFtUPU4dRQmjlCE0hxSVYpToNGxZKySdWjWWayrwcxCVGEs FQ8VJEVShPVpBTJXvADonVhChIqQKVDpyiEXR2C+wjihfFt3JazBJOyqjNFYJuRMnWsWnKqy aFZ3ld5KKt0vKNGsYV2/TgoXIVeuUNtGLR27rGu3+HQfbZraEFWda39WAp42+emdY2WHRW3G dj4ixFqmGDCAWMQVqQCPwE7rb4nrNUQMSMU4/KgmSMwj2/soVPpc2rn70PVi+8pO8GewIp9z PoATDTUHcaT/kFruoVMPJoEYlFOB9GDBjoXbMJPTIQs+RAp0GCLTjioZElKOQV5xA0xDFIKT zG0ggoIgQyVOuBBbb9mYEYTTOYiUOr5NApqQQ4ImIpFHIpmkkksymVGTT0IpZDU1CRWllVf+ hqWWW2bpVZNVcqklmGGSWaaZYo55ppprSskmm1M66aaccc5Z503ERZmmnW3u2aefZBr5p6CD EspkoIVeeSiibio6pJ6LPrqopJNSWqmll2Kaqaabctqpp5+CGqqoo5Jaqqmnopqqqquy2qqr r8oZIax2ujirrVAGlGutMeqI4k6R3hrsrMAKu6UixSLLJ1Zqmcbshj06m6y0w04b/2uW1Vb7 GrPF0akVnsRiGy6n7l3Iqz80gvhMJBDO2OuNF6rLI7vAMvhLiymWuM27+tq0TocjknhvuYns yOIoo2XRDZgnosRThdzeidQcFYpbsam4MRect5PIFiSQynGM3IAh9rgbUEA6WNuAGXfSsLfU KUfwwTgeK5bHDH7bGsA8SayxxT+TyrLJqvkcc89nLXLnNM5FWnJZx35IWsFpUdKUzpSEfFzL Kh8VJ7Qta+hluSM7XR3QZ2tK8Dm8UTN1g1d5vDFaYT+7K5XPPr0Vvz4rsTTJ7PQdbYL9Ibei U8YZZ2OCRee8lNkU95O1iuCiXXmfyTGddNZa+2oz5hNLPv/yJWX3DLXIp+O2Gsr68Ix0yqsj nlrNIMO5rYZRQD7l61db3jukq8v9TtmY1zz8hngKr2znzWoltOap18i1TiY3x/lTsRc9tOmO 24676tl/77v4kiZTvttge4i3ueLMB485Yi+PwtzmEtfOuvn+y9DH97LV22rvI6hu1StZrSYH I8DtzR+9otL7VKQ6yo0vgpWrnaEkGC4KqgmCFtwgB5+EQSVpsIOj+qAIS2hCaTXqhCpcIQtb 6MIXwjCGMpwhDWtowxviMIc63CEPe+jDHwIxiEIcIhGLaMQjIjGJSlwiE5voxCdCMYpSnCIV q2jFK2Ixi1rcIhe76MUvgjGMYhz/IxnLaMYzojGNalwjG9voxjfCMY5ynCMd62jHO+Ixj3oU ot326Mc/Emp2gBwkIa3Fu0IiMpHGcpS84CW983GMXQdTJCWxOCbnSe10sCncJCvpySmmyW/M Y50mpTedTn4ylU4MpeIQeMAGNWQfa0ucKmu5xA+KUnYcWg7MmBI5WwJziIK83Sb9JzSYBQ5y wVwmHwN1o/7lcn37K9hwmGnNJIaQVtfcJjY9lU1ugnOFKQwnOctpznOiM53qXCc72+nOd8Iz nvKcJz3rucPibYWA0CslyoTDNF1JZxeu3BnLFLi1rtmznjjSXDH9ZzTU0YxrpXsR7V52m3/M LEMJVahG/xHa0HAw9DQRzc1E+7U5tCRlnwcNzUbtSct7PCRxIKUoTn6EOMF9bGfncsuM2iIP n4IlWi2FZ+pCijDgsI9vtsHeKHUpSqxxLqWkLOpQ40nV5wRUNYuT3FLBglLgIZOiKsXY9bxq tqqyE58UQqoitjq5sZKmqekKIPoIxM/nBA+tesXSN3vX172i9a8TBCxhDSXYwiI2sYpdLGMb 69jHzvOwrVLmkAigJcuWALNK0uyTONsDz0IWjJT9WR9BA1rNgta0JrBsapvU2iS9NrRbHO0K T7taJKE2s5e1Umxlm0WK6SqjFjXYTskFo4LKSqcKqlc5isBazBIgugCILnSnm//b2+qWuquV bnav+9zMcte6uWXtdsebWvJe17dMbOtaEQZXS0RyuMVU60Mh6Q7uVle34NXvZ7GbXujmF8D6 /e9+p8tfARv4s/lNsHpvCbqFCPe9V90cWKv5y49GjMELJnB/D4zdBHvXwxr2L4kH/OEPp7fB SDRg84IqS6DOTZ8D+am29ibTgaJYxCPu8I53HGIflxe/JQbxiXXcWxX/EE4g3cfLeqm+Y2oy c7khXY57nGIjV/nHP2ZwlodsWx0juYgFqgdTMVpR9x41oPR9pFKJsGXULhjMHBYykU0s4jeD GcthNiL/VhRWrSm3J9C8hd9mZ74zp4/HCBZyeDdcg0ZWN9q6Xi6weKtcafBGmr/iPfKehXkt Ri1JsnXiNGzJROpOd5GEayKWqHlL3VfDOtaynjWta23rW+M617FG9SBZTapTHwnYRAovr4tt 7GMjO9nKXvYbQwAAOw== ------=_NextPart_001_0013_94F8BBFD.86586D7D-- ------=_NextPart_000_0012_94F8BBFD.86586D7D-- From rtg-dir-bounces@ietf.org Sun Jan 2 17:42:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11135 for ; Sun, 2 Jan 2005 17:42:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClEd8-00044X-1Z for rtg-dir-archive@ietf.org; Sun, 02 Jan 2005 17:55:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClEP0-0002vy-52; Sun, 02 Jan 2005 17:40:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClEMg-00022q-VI; Sun, 02 Jan 2005 17:38:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10756; Sun, 2 Jan 2005 17:38:20 -0500 (EST) Received: from ppp-70-243-160-99.dsl.snantx.swbell.net ([70.243.160.99]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1ClEYi-0003z7-Oa; Sun, 02 Jan 2005 17:50:49 -0500 X-Message-Info: WYEHUhfEXE069wknEC469EqCX04VctjO230IO6H34kvf527CLZ Received: (from rnj61beret@localhost) by ti36-cold65.s510vs.excite.com (1.59.50/7.73.22) id t917AE5ryx6; Sun, 02 Jan 2005 17:34:52 -0500 GMT X-Authentication-Warning: jy46-debt90.ami52ml.excite.com: c89tompkins set sender to sdzogc@attbi.com using -z MIME-Version: 1.0 Date: Sun, 02 Jan 2005 16:39:52 -0600 From: fleshlight is new To: rtg-dir@ietf.org Message-Id: Content-Type: multipart/alternative; boundary="--2970625906856123" X-Spam-Score: 1.9 (+) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: enhance your sexual abilites-axgir X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 ----2970625906856123 Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Fleshlight The Ultimate Male Sex Toy http://www.evolution-x.info/fl/?har The Fleshlight is a portable, concealable, sturdy male masturbation device= that our customers describe as "Awesome", "Amazing", and "Ingenious". Fleshlights are available in a wide variety of colors, scents and orifices= Accessories for the Fleshlight include the Wonder Wave Insert, the Super T= ight Insert and Super Ribbed Insert for alternate sensations. Wide range of inserts, colors and flavours Get it now! http://www.evolution-x.info/fl/?har The patented gel insert, made from our Real Feel Super Skin=AE, gives a fe= eling that is amazingly life like. Cleverly disguised as an ordinary flashlight, it's easy to store and trans= port without drawing attention. Available in a variety of styles =96 Mouth, Anus, Vagina and Non-Descript = =96 and offering a variety of special sensations =96 Original, Super Tight, Su= per Ribbed, and Wonder Wave=96 the Fleshlight Toy presents our clients with a multitude of erotic experie= nces, fantasies and sensations to elevate orgasms to a new peak of intense sexual pleasure. Check here to order this amazing sex toy http://www.evolution-x.info/fl/?har testimonials =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Name: Uriel Comments: I've been masturbating since the age of 12 and NOTHING compares = to the chocolate butt fleshlight, i just dim the lights, close my eyes, an= d feel like im with Queen Latifah. Name: Robert Comments: Thanks, You have made christmas better. My wife is in the Air Fo= rce flying C-17's in and out of Baghdad. She well be there over christmas = ,and well not be home till the end of January. She told me not to wear mys= elf out before she gets home . Thanks, again. Name: Whitehall, OH Comments: Quite possibly the best anal sex I've ever had. Especially when = you consider no danger of Aids or unsightly poop on your penis. And lets f= ace it, no guilt or shame for destroying some poor girl's pooper. A great,= great product. As you can probably tell I purchased the butt model, ultra= tight and I have to say it was worth every hard earned penny. I'm current= ly in a relationship and my girlfriend and I have plans to bring the flesh= light into our lovemaking sessions along with her vibrator. A safe, sexy f= oursome with just the two of us. Thanks Fleshlight! Name: 2Pumpblow Comments: I have tried other toys for boys but the fleshlight is the best = thing since Adam gave up a rib. I have had my fleshlight for about a week = and I have to say, great job guys. I would vote "Best product of the year"= award. The first day I couldn't believe my cock. I couldn't stop. If any = of you guys are thinking about price, stop, just think of what it costs to= go out on a Friday night. The fleshlight is the best thing you can do for= yourself. --------------------------------------------------- To stop future notice: http://www.evolution-x.info/fl/?har/s.php toad vale sightseeing fleeing aerodynamic. aile chartres anywhere july catabolic. antiperspirant flora chalcocite escherichia concessionaire. gogh il madras emit deadhead. ideologue condolence euphorbia bowen woolworth. spermatophyte troop flag alundum beat. absorbent tampon age bronchial barometer. prejudicial holloway oscillate transient contention. manual istanbul default dunce dubious. vaunt minute fissure seismology leila. admiral beautify devonshire envy vampire. churchwomen guitar sketchy cataclysm polariton. andrea argument honda brocade exam. rum plumbate dobbin enquire booth. born strand cheney delineate hummel. rill bichromate dispersal calendrical trounce. sdzogc@attbi.com ----2970625906856123-- From rtg-dir-bounces@ietf.org Mon Jan 3 07:15:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22109 for ; Mon, 3 Jan 2005 07:15:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClRJz-0002V1-EW for rtg-dir-archive@ietf.org; Mon, 03 Jan 2005 07:28:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClQy1-0008Ou-LN; Mon, 03 Jan 2005 07:05:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ClQwp-00080W-Uj for rtg-dir@megatron.ietf.org; Mon, 03 Jan 2005 07:04:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21613 for ; Mon, 3 Jan 2005 07:04:29 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClR8z-0002Kv-4v for rtg-dir@ietf.org; Mon, 03 Jan 2005 07:17:05 -0500 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-blue.research.att.com (Postfix) with ESMTP id CA9F519735F for ; Mon, 3 Jan 2005 06:50:21 -0500 (EST) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j03C02mm080594 for ; Mon, 3 Jan 2005 04:00:02 -0800 (PST) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j03C02Qp080593 for rtg-dir@ietf.org; Mon, 3 Jan 2005 04:00:02 -0800 (PST) (envelope-from fenner) Date: Mon, 3 Jan 2005 04:00:02 -0800 (PST) Message-Id: <200501031200.j03C02Qp080593@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Subject: IESG agenda for 2005-01-06 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-01-06). Updated 2:25:28 EDT, January 3, 2005 ------------------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date Generalized MPLS (GMPLS) Signaling Extensions for RTG G.709 Optical Transport Networks Control (Proposed Standard) - 1 of 5 draft-ietf-ccamp-gmpls-g709-08.txt [Open Web Ballot] Note: Participant in PROTO Team Pilot: Workgroup Chair Followup of AD Evaluation Comments http://www.ietf.org/internet-drafts/ draft-ietf-proto-ad-comments-pilot-00.txt Token: Alex Zinin RTG Three-Document ballot: [Open Web Ballot] - 2 of 5 Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification (Proposed Standard) - 2 of 5 draft-ietf-ccamp-gmpls-recovery-functional-03.txt Note: Target Category is PS, not INFO as the doc says Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) (Informational) draft-ietf-ccamp-gmpls-recovery-terminology-05.txt Note: Target Category is INFO, not PS as the doc says Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) (Informational) draft-ietf-ccamp-gmpls-recovery-analysis-04.txt Token: Alex Zinin Generalize Multiprotocol Label Switching(GMPLS) RTG User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model (Proposed Standard) - 3 of 5 draft-ietf-ccamp-gmpls-overlay-05.txt [Open Web Ballot] Token: Alex Zinin SEC Security Architecture for the Internet Protocol (Proposed Standard) - 4 of 5 draft-ietf-ipsec-rfc2401bis-05.txt [Open Web Ballot] Token: Russ Housley APP Three-Document ballot: [Open Web Ballot] - 5 of 5 LDAP:String Representation of Distinguished Names (Proposed Standard) - 5 of 5 draft-ietf-ldapbis-dn-15.txt LDAP: String Representation of Search Filters (Proposed Standard) draft-ietf-ldapbis-filter-09.txt LDAP: Directory Information Models (Proposed Standard) draft-ietf-ldapbis-models-12.txt Token: Ted Hardie 2.1.2 Returning Item Area Date APP Full-mode Fax Profile for Internet Mail: FFPIM (Proposed Standard) - 1 of 6 draft-ietf-fax-ffpim-08.txt [Open Web Ballot] Note: Returning because there aren't enough positive ballots for approval. All old discusses have been cleared. NOTE: doc has been updated to -08 from -07 since the document was placed on the agenda. Token: Scott Hollenbeck SUB Dec 30 Four-Document ballot: [Open Web Ballot] - 2 of 6 Protocol extensions for support of Differentiated-Service-aware MPLS Traffic Engineering (Proposed Standard) - 2 of 6 draft-ietf-tewg-diff-te-proto-08.txt Note: Back on Agenda to see if we can get the DISCUSSes cleared. Thomas and Alex ?? Maximum Allocation Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering (Experimental) draft-ietf-tewg-diff-te-mam-04.txt Max Allocation with Reservation Bandwidth Constraint Model for MPLS/DiffServ TE & Performance Comparisons (Experimental) draft-ietf-tewg-diff-te-mar-06.txt Russian Dolls Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering (Experimental) draft-ietf-tewg-diff-te-russian-07.txt Token: Bert Wijnen RTG Authentication/Confidentiality for OSPFv3 (Proposed Standard) - 3 of 6 draft-ietf-ospf-ospfv3-auth-06.txt [Open Web Ballot] Note: Participant in PROTO Team pilot: Working Group Chair Followup of DISCUSS Comments http://www.ietf.org/internet-drafts/ draft-ietf-proto-wgchair-discuss-pilot-01.txt Token: Bill Fenner SEC Sep 26 IP Authentication Header (Proposed Standard) - 4 of 6 draft-ietf-ipsec-rfc2402bis-10.txt [Open Web Ballot] Token: Russ Housley SEC Aug 4 Extended Sequence Number Addendum to IPsec DOI for ISAKMP (Proposed Standard) - 5 of 6 draft-ietf-ipsec-esn-addendum-03.txt [Open Web Ballot] Token: Russ Housley SEC Sep 26 IP Encapsulating Security Payload (ESP) (Proposed Standard) - 6 of 6 draft-ietf-ipsec-esp-v3-09.txt [Open Web Ballot] Token: Russ Housley 2.2 Individual Submissions 2.2.1 New Item Area Date INT Teredo: Tunneling IPv6 over UDP through NATs (Proposed Standard) - 1 of 1 draft-huitema-v6ops-teredo-03.txt [Open Web Ballot] Token: Margaret Wasserman 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date APP Goals for Internet Messaging to Support Diverse Service Environments (Informational) - 1 of 1 draft-ietf-lemonade-goals-05.txt [Open Web Ballot] Token: Ted Hardie 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item NONE 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item NONE 3.3.2 Returning Item Area Date INT Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI (Informational) - 1 of 1 draft-mills-sntp-v4-00.txt Note: 2004-11-24: Successful NTP BOF in Washington DC. This document will be taken over by the WG. Plan was (IIRC) to publish this document essentially as is as an informational (snapshot) and use the document as the basis for a Standards Track document on NTP. Token: Thomas Narten 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval Area Date RTG Dec 8 Path Computation Element (pce) - 1 of 1 Token: Alex 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval Area Date RTG Dec 8 Mobile Ad-hoc Networks (manet) - 1 of 1 Token: Alex 5. Agenda Working Group News 6. IAB News We can use 7. Management Issues From rtg-dir-bounces@ietf.org Wed Jan 12 11:45:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27728 for ; Wed, 12 Jan 2005 11:44:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ColqG-0001sp-NG for rtg-dir-archive@ietf.org; Wed, 12 Jan 2005 11:59:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Colb7-0006Ov-Hf; Wed, 12 Jan 2005 11:43:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cola0-0005w4-DM; Wed, 12 Jan 2005 11:42:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27495; Wed, 12 Jan 2005 11:42:37 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Colnw-0001ne-Hp; Wed, 12 Jan 2005 11:57:11 -0500 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id 7953B197354; Wed, 12 Jan 2005 11:27:46 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id j0CGg4Q02274; Wed, 12 Jan 2005 08:42:04 -0800 (PST) Message-Id: <200501121642.j0CGg4Q02274@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: iesg@ietf.org, rtg-chairs@ietf.org, tools-team@ietf.org, rtg-dir@ietf.org, proto@ietf.org Date: Wed, 12 Jan 2005 08:42:03 -0800 From: Bill Fenner Versions: dmail (solaris) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: Bill's availability for the next few days & weeks X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fenner@research.att.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Dear friends, We are going to have a baby quite soon; I expect to be pretty much out of contact for January 12 - 17 (induction is scheduled for tonight), and then will be on paternity leave after that. During my leave I will still be spending time on IETF matters; I'm planning one day a week but since it's our first baby I have no idea what to expect and am playing everything by ear. If you need me while we're in the hospital over the next few days, send a short email to fenner@tmomail.net and I will try to respond. After that, I'll have access to my normal email but an irregular schedule, and the @tmomail.net address will not work. I will probably be checking billfenner@mac.com more often than my work/IETF email, so if there's something you need from me try me there. Thanks for your understanding during this exciting new time in my life! Bill From rtg-dir-bounces@ietf.org Mon Jan 17 07:15:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28969 for ; Mon, 17 Jan 2005 07:15:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqW2P-0002ZI-7f for rtg-dir-archive@ietf.org; Mon, 17 Jan 2005 07:31:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqVlo-0006FL-43; Mon, 17 Jan 2005 07:14:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqVhC-0005qn-4s for rtg-dir@megatron.ietf.org; Mon, 17 Jan 2005 07:09:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28721 for ; Mon, 17 Jan 2005 07:09:18 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqVwF-0002Sy-1M for rtg-dir@ietf.org; Mon, 17 Jan 2005 07:24:55 -0500 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-green.research.att.com (Postfix) with ESMTP id 09168A7BCF for ; Mon, 17 Jan 2005 07:08:49 -0500 (EST) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j0HC03mm019970 for ; Mon, 17 Jan 2005 04:00:03 -0800 (PST) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j0HC0389019969 for rtg-dir@ietf.org; Mon, 17 Jan 2005 04:00:03 -0800 (PST) (envelope-from fenner) Date: Mon, 17 Jan 2005 04:00:03 -0800 (PST) Message-Id: <200501171200.j0HC0389019969@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Subject: IESG agenda for 2005-01-20 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-01-20). Updated 2:31:1 EDT, January 17, 2005 ------------------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date Internet Control Message Protocol (ICMPv6)for the INT Internet Protocol Version 6 (IPv6) Specification (Draft Standard) - 1 of 7 draft-ietf-ipngwg-icmp-v3-06.txt [Open Web Ballot] Token: Margaret Wasserman SEC Addition of Camellia Ciphersuites to Transport Layer Security (TLS) (Proposed Standard) - 2 of 7 draft-ietf-tls-camellia-06.txt [Open Web Ballot] Token: Russ Housley TSV RTP Payload Format for Uncompressed Video (Proposed Standard) - 3 of 7 draft-ietf-avt-uncomp-video-06.txt [Open Web Ballot] Note: - Magnus.Westerlund@Ericsson.com is WG Chair Shepherd - The writeup has an RFC Editor note with revisions of the Media Type (so it doesn't imply video/raw will also be a file format in future) - this rev was aired on types list. - i-d was not rev'd after Feb. I was holding during long congestion control debate. MUST it have updated ipr boilerplate?? Token: Allison Mankin RTG Three-Document ballot: [Open Web Ballot] - 4 of 7 Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification (Proposed Standard) - 4 of 7 draft-ietf-ccamp-gmpls-recovery-functional-03.txt Note: Target Category is PS, not INFO as the doc says Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) (Informational) draft-ietf-ccamp-gmpls-recovery-terminology-05.txt Note: Target Category is INFO, not PS as the doc says Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) (Informational) draft-ietf-ccamp-gmpls-recovery-analysis-04.txt Token: Alex Zinin SEC GSAKMP (Proposed Standard) - 5 of 7 draft-ietf-msec-gsakmp-sec-07.txt [Open Web Ballot] Token: Russ Housley APP Two-Document ballot: [Open Web Ballot] - 6 of 7 Functional Description of Event Notification Filtering (Proposed Standard) - 6 of 7 draft-ietf-simple-event-filter-funct-04.txt An Extensible Markup Language (XML) Based Format for Event Notification Filtering (Proposed Standard) draft-ietf-simple-filter-format-04.txt Token: Ted Hardie APP LDAP: Uniform Resource Locator (Proposed Standard) - 7 of 7 draft-ietf-ldapbis-url-09.txt [Open Web Ballot] Token: Ted Hardie 2.1.2 Returning Item Area Date APP SMTP and MIME Extensions For Content Conversion (Proposed Standard) - 1 of 1 draft-ietf-fax-esmtp-conneg-12.txt [Open Web Ballot] Note: Returning to (hopefully) clear the last discuss and to secure the additional ballots needed for approval. Token: Scott Hollenbeck 2.2 Individual Submissions 2.2.1 New Item Area Date GEN Structure of the IETF Administrative Support Activity (IASA) (BCP) - 1 of 1 draft-ietf-iasa-bcp-04.txt [Open Web Ballot] Note: This document is still under discussion on the IETF list. A revision (-04) is expected on Friday, Jan 14. I (Harald) am putting it before the IESG on Jan 20 to make sure formal IESG processing does not cause delay that is not warranted. I will hold a DISCUSS on the document until it is clear that the IETF discussion is finished. Token: Harald Alvestrand 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date F-RTO: An Algorithm for Detecting Spurious TSV Retransmission Timeouts with TCP and SCTP (Experimental) - 1 of 8 draft-ietf-tcpm-frto-02.txt [Open Web Ballot] Token: Jon Peterson TSV Requirements for Internet Media Guides (Informational) - 2 of 8 draft-ietf-mmusic-img-req-07.txt [Open Web Ballot] Token: Jon Peterson TSV A Framework for the Usage of Internet Media Guides (Informational) - 3 of 8 draft-ietf-mmusic-img-framework-08.txt [Open Web Ballot] Token: Jon Peterson APP Goals for Internet Messaging to Support Diverse Service Environments (Informational) - 4 of 8 draft-ietf-lemonade-goals-05.txt [Open Web Ballot] Token: Ted Hardie OPS IPv4 Multihoming Motivation, Practices and Limitations (Informational) - 5 of 8 draft-ietf-multi6-v4-multihoming-03.txt [Open Web Ballot] Token: David Kessens OPS Architectural Approaches to Multi-Homing for IPv6 (Informational) - 6 of 8 draft-ietf-multi6-architecture-03.txt [Open Web Ballot] Token: David Kessens OPS Things MULTI6 Developers should think about (Informational) - 7 of 8 draft-ietf-multi6-things-to-think-about-01.txt [Open Web Ballot] Token: David Kessens INT Host Identity Protocol Architecture (Informational) - 8 of 8 draft-ietf-hip-arch-02.txt [Open Web Ballot] Token: Margaret Wasserman 3.1.2 Returning Item Area Date INT State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator (Informational) - 1 of 1 draft-ietf-eap-statemachine-06.txt [Open Web Ballot] Note: Went back to the WG to address late issues raised while in RFC Editor queue that resulted in substantive changes. Back on IESG agenda to be checked before being sent to the RFC Editor (again). Token: Margaret Wasserman 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date APP Simple New Mail Notification (Informational) - 1 of 3 draft-gellens-notify-mail-01.txt [Open Web Ballot] Token: Scott Hollenbeck APP A URN Namespace for the TV-Anytime Forum (Informational) - 2 of 3 draft-kameyama-tv-anytime-urn-02.txt [Open Web Ballot] Note: Reviewed by the URN Nid list some time ago, but expired before it was seen by IESG. Recently re-issued. Token: Ted Hardie INT Proposed changes to the format of the IANA IPv6 Registry (Informational) - 3 of 3 draft-huston-ip6-iana-registry-04.txt [Open Web Ballot] Note: Has been reviewed by the IPv6 and v6ops WG (there were minor comments). Token: Thomas Narten 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item NONE 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review Area Date TSV Jan 3 Emergency Context Resolution with Internet Technologies (ecrit) - 1 of 1 Token: Jon 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issues From rtg-dir-bounces@ietf.org Wed Jan 19 13:14:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07594 for ; Wed, 19 Jan 2005 13:14:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrKb1-0001Jt-Ou for rtg-dir-archive@ietf.org; Wed, 19 Jan 2005 13:30:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrKG5-0005XX-SQ; Wed, 19 Jan 2005 13:08:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrK3w-0003M9-9M; Wed, 19 Jan 2005 12:56:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06046; Wed, 19 Jan 2005 12:56:09 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrKJQ-0000s5-Tj; Wed, 19 Jan 2005 13:12:14 -0500 Received: from 53.65.97-84.rev.gaoland.net ([84.97.65.53]) by mx2.foretec.com with smtp (Exim 4.24) id 1CrK3h-0001cP-Hu; Wed, 19 Jan 2005 12:55:58 -0500 FCC: mailbox://vlkyzmmc@yahoo.com/Sent X-Identity-Key: id1 Date: Wed, 19 Jan 2005 20:48:58 +0300 From: Mariano Forrest X-Accept-Language: en-us, en MIME-Version: 1.0 To: rtg-dir@ietf.org Content-Type: multipart/related; boundary="------------000809030205030408010006" Message-Id: X-Spam-Score: 3.0 (+++) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Subject: re[7] X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 This is a multi-part message in MIME format. --------------000809030205030408010006 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

would you like I see eye to eye in 1813 I wonder what if...

Free Games So-so

--------------000809030205030408010006 Content-Type: image/gif; name="acclamation.GIF" Content-ID: Content-Disposition: inline; filename="acclamation.GIF" Content-Transfer-Encoding: base64 R0lGODlhOwIJAvM4AAgEAMDAwMDcwICAgP/78KCgpP8AAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAQAAAAALAAAAAAsAvsBAAT/EMlJq7046827/2AojmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgs Go/IpHLJbDqf0Kh0Sq1ar9isdsvter/g8AtAJlfK5lR5ts60R284Gho31bf3ZV4s2TfRaQiAACp+JYQT hoYbixqDK4gskX2BJ40dk0KXRJtFmSKdRo+Uc2qVphShOqocpyiukrAhsj6sP7a3n7O0TGuBZrgWwRdx wzTGZ7ygypbMjM45yNHQQ8bSPL6RwJWjpMmE2bKlGKNt44LcgM+T3cLd7eZv8Orf8vTomeeY26d14Xv+ 0gXMJy6NPnzF+imEpi+eq3mIDiIkp+geKWX/vmkceGxbInC//wZpW4gQosVU9ETaG9nOHcuTH1OKjDmz 5MtzKi+GvNlJ5c6NML2hjJhTaEyKRXWu1KiUV1Kf7GraxCl1qi6bNIM2XToUH1MZ4bzG+8p1XEKiV73S XKv2rBuDAt+OZGrWIUq6cdUeFdqTq16+GH8a9Wu0HluSg/NWRMt2Ijq8O1kWtouULK26krvqvbZOLD9i mPdy/Aswr2i4aUEz/lCa8um0MmEjdruP4OrXnQHbLvxX8956mTeb/toWMXDerotHvUr7N3HlkJ3HGIt6 6D170h1W9d2bcsvKWFstjB0duPaHs6m5LI/bUcjs1bnLP3tdsNWCsndnTQ4d6Xbno62n2f9o2NVA3W2l uEWYcv9Nlh5PTkUmEYDePWiYcO9YSAKBGroHUnC6PQffSw5+aN13vM0XWYgDXuYTeMjhx15iJhqIWnzN eQZif7WpeNt+crnkB2H8JZejUjH+uIt+HKbmzYJFytjicl0d6WGQU2appWqsDdfbiEkexVlu5JGm0GNg msmcl/zJ56Z0vtHWJHdDxtdeijCyeKd7aIbZnZR7DmTclyX6KWeHPBKqpoiGDuqRDefp2RBV9iVK3JyL gmflbyspaeSKmQboWp32Yaakf/phSCKXW056R5utdpigcZ+emqaijqnaWEk3+NXpSRZBdSKpdkraIKfH lljOgxKa6iz/shnmV5WwvHo4XrAvsgrtd3kkpVp9qWYr6rTJgoviVgKRO2ZuGFrnp5itOekYpkheCaS9 h30WJ300CjpiqutJpE6n4q3Z7RytXRqltB64qnB1AV7kX8G2BfahLgMPWsW6fIQhLw4cdyxyCyFP8/HI KINWjXopt8wGy6JM6PLMH2kiM804w6DVEzfn7HMtJf8stMRDF2300UgnrfTSTDft9NNQRy311FRXbfXV WGet9dZcd+31118YYADYZJdtNg9in612x2K37fbbKbidS890lPz22BncrYHee8stAtx9ty3XyWv/fPfh aZ/gdgA9JCsF3X8jjjcFkk8+QeUXSP6B/+YWcH5h4U1XzncJi2PjeBSQgyC65atTLnoFr3MQ++WYfw76 0qsDTkLpO6SO+phwp6177rTPjkDrGyAvgfJE34572wFEL330bzO+O/Smw/wH8IIfj7ffunvfffjD+718 93mbL/7k5KPfvNECv6rVQZRe3DBM9KN3o06bY5+5/7ALn+vEZr0Bus+ACBxcUM6FsE0wMFJC2pUEA5i4 xHXugOs7nwWLxz4MYpCCltMgBy8YQt+lLH7p4pb8UngJar0vRbPix84MWEAQ1nB9o+PgDRH3PwLqUIGu +o+3gJg/GQZxgrnq4fdCOEIQapCJ5lPfEwMHxfF50H0mPKG/9tOSIv8uZ4boOhKwmnW6J97wiQaoIfPW p0bPJXBxZ+QiC7tYRqhca4j1s50Sx7ZBD0hRiU1MIAb+CL4rbjCLKDsi/7LiLtuBkZGQTCK2mhXJ9OUu jQWsnvTa50MzbtKQaWQjxYT0xVLejz6lvEkjX0i3w0WOiT00IOv+KMta4tCWLyyaIpP4Pi+ucpSfq98X K8nLPYqujQREZijNWLzoDfCMiHPmOj7hSyROzJG7lOQWqZhDKsrugMTjJg/ROM5c6pJW8ZpgHmtjsOCE RVkRTN4lpclGaKKPd7wLpCwxyU49NiZ1EzJVPFmpMXHSUpCWrKLxjOlKcja0ZksTqDlzVc2JDjT/mD8h 0grltbrp0VCJ1sNn7uyZz2n6s3kATWcu1/nPULiRhLB0IkMFOFP1rVF7iSTYRCX6y5TiZ1XvZKk1afjJ D5b0h6LEoeTiCMdTVuyaxYQqRvU3zFUispwy9SY3M9iB4IGSjwfEaU5BFFCd9tSBKn1SRsdz0UEC8JY2 BCkzlRpNmPbRWielKFp/qk5+WYZwrpsiTL95V8LG1LCIvQvTGpguqFY0qt+S6jt15M9WvhWuSI1rUuE4 vc7adZnAtCZPTRrZlfrVXYj0nmAR6tbCJvaVh9VnnyIqw19adaO2HZxk9UXZ3Fq2k7hMqmZFClzDHrSt ZQVVaKdKzdNW6RKF/1ytdFsbWyked7pRBOcHnzbZvjb2RLnVbWWD2FyqGpakxSUk9EIKwOsS1b2mNe9Q 26pN+Zqzu1qtoPvg697ybZeDHbxndv/bNCEKE7z1sigpEczgRfq2EUdFY3Crl9n2yTXC9J3kd9lpSu9W 1TyEk5vw9qu8cDqUk7Os3YmlmNqWzc+OpPSWCe2IMfJmGMKXzSxdNalj5jWVq3iNMR3VQ+Pxbvg4/VPx jv2r5IXaVMlLvmuLtUgsFOVEqBze2cFqbN+ExhGzK+anjqMszR9Pl75hRLO1VNjl5LKsyeG8JAhpal2s ApiWUx6rxRYRmw+D4FxwItRjqftlMCMgAHeTnv9m94nJTF4Ww/N9oPYkXV4/NzjJX+WcnOccU/Vet5vh PVqen+bRDHi2Ap39cqlRnWoLrHoCrxb1MFzrvCmMuta47pJYVZtrKzyy18CWw6xjG+wjlLHYyJ5m0JId s1szG9iAfnYXfi3tajvY2tjOtra3ze1ue/vb4A63uMdN7nKb+9zoTrfQjjvgFL+U3Oy24gbXqO7b0RSz T17ouO8NuHxDud6go6W/Gf3QcgtcwPM2McD/7EKlHTzhEKd31Jb9WkH6W98GWgZg7bDr7TUcaQ93N2sN LTWKy7Ow7R75vV+mcUh1vBcwZlqd+zjwwVrN5CcPYc3PDGSXbxxXJHu5Hrr/DHLt0pzEKCdwgYVugpmL XLY8BwvMcA70LGx5wd+SFpf1+lPCRRu7Rn96cAPm5vKqykVXh6wp0GL2Lb0J7BFXOZ41hkoIIXlK7eTy CvmQdi4KuWJjnAmb6ZatwFHQ5mFeeZpBzPj7gPiOzs564GcU6OIdHqGXhCWlILMsDQsTf0OGCN/bLOPS F/4+pv+6WakL9Yu/+/F1j32mwphKai/J9H9llMXDTnBQb8udK5LK6WOOLgpRSQxFbumquL585m+r8u9i /ZldX/DdLt+541Ku812w+VtFDJBwd/frf7+ndin/+maFUqW+kPxGEUSCoTH+rU6Z89Yj3c5Ycrv5iQl/ //X/vEe5ty/rB34913MY91cDKIAq4iNpomVMlwQ0BiExhC8KKH+051TMgHAEWIAM13bEJygOIyB/onVD 5Cb+V4EnZ3lZxYH0FxbxUil8hk7iYmD/Vzd6d4FA13c58iuqV4KDFXIjp2sC8oFUBS7a8n3DUi76M38L wnqeJnZLQlkgGH94woA46Hip0DEJk4MRsnWFAi0aVyxOaFT3dwhLWHVVJoY0onuoRyoi+H34lVAcuHNR 6IIptIbQ9y57hRNaKCWLkQz9B4OmoQpIGEvbRYdRSHkiKF67VIivcIYjCBQhNmKwhIgM1yePoodscnxg 2IHs0Ic3+IU8NVo7OBxu+P92h3eIZbghp9UccKhc3ZeHZrhhozUVSSY+GwhfClRJ2Xdb61eKnvKAThCB SThHxgiMdOKD59dVvmeASrdmJjFJi8iD0oiKHDd8H1ctfuR7lqhrEuKLqlR8TIh7negx7bcVjwd7D+Mj YJSN1HVY3YiBoCd66liMAFN1rFiC2Wh7EpaLz0iBX+JCnidGkFd7XuIFxHd3CrmQXwhDPqWGeySHUCeE kDWPqLKLi4iPwrZTsMIKKxeP9PcmZcJLFmmCZZeRC8cFVHdONZiSLgk0LVk1kfeSNNkRMTlx/FiTOtk7 wkhbM7mTQBkLNwk1PxmURnmUSJmUSrmUTNmUTvmUUBn/lVI5lVRZlVa5dNqiWGOgHVhDDR03lHKwMm9h hpTQJQ1TCCvZB3ySC0GXlRDFfYzVky7mdTEJlmFpM2PJimV5P6zxiGkZIUAgl2dyJjoTFVvjlS0pl32J lxRBlnBglhzHk2sJNHAJiIS5lVrZlXR5CLUglo2pl4+5mI45DZPZOHaZmY9xmQp2Vg03KYJmPySJLdoE iI0ZQ5U2MWxFm9emMndhmzcmSVgHjb25ZSCRlwm2FnCBXMH5luJ1nDWDQgCjjLX1nJQ0nLDQQJfGEOmg lr+3GH1WFE+xQI/QedFSH7opZOFhFemIjm/pOJCXnqknM0oofNuhjGiCjctSjER0/55/55zs+Z+zZUSo woNYCKDq2RSoOZnvsZcMOlvukJnbyZwJWI7JqZW+Mhf5VyAB+n6JAaFEwZ/MiYeYaJjliJoFoZsaBX0V KqGZEaENaqIcypsNinbIAqMM2oXt6aIzKoinAaJ8eaMY6qBC+qIjaqHNRaTnqaMoGqML+pk7SqRNupfo AVGI+aAsCqVBiqS7FqVFmqAhaqS0yaVDygwnuqTGKaVHSqVZaqVqKh42+qIr+og5mqPSmaYbKkdxKqN3 eneXORZnGqFTCqdslyG7qadPqqbh6aP8aJ5g6qVYqqFoiqd6JxtOOqeVep+nN5tniqkYKagheiNgmYll eYxrwv+mLkotgeGhcvSpJAqYVyqkXAqqjGqLl7qnaJqojuqe9GmmjjqihKpYZPSCgcqmlmqospo/Psqq jyqbjUqneSaqqUmiP9qsXVqrSdqqGqqa0EqsgGqnhJmqajasewquXxqu2cqkMWqldaGs1Xp7yTqsLhKm H0MVpcmpt/WmDnqdwQCtokpk3iqtrvqn2MqrrEqu4/qv8voMm/qlOpqnxDqkhsqu+bqm8Tqx7Cqml5ir CHupDquua8qfeaqt6JqsELsPFiuylPqqhwoYCvuqg5iuarey7dqnUVogqpmgDZulkDqmMMuiFAuwFWuK LSqtrwmyKSuzRuuzwPqx+yKxZnL/rT3aqwAoIvZ5oDKLqwK7tLuKs/KSs6uqnwBKRvXqtWHbswg6oDtr jHmJnzIBtpJntl+LpJ5atlqbd2lbetdangmRiLr3a8jKsPRamqc6K3MrtVf7VJF1LXlrsLY6sQFBsu1I uBaLWkfbtsj5oQzJkGQqP5uquBZYGpqKYLH6VHdouKCjmBAIcKd5lY+zutujbqjLuhBYlH8Au7I7l7Gr B+jmurfbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAbvdI7vdRbvdZ7vdibvdq7vdzbvd77veAb vuI7vuRbvuZ7vuibvuq7vuzbvu77vvAbv/I7v/Rbv/Z7v/ib/7/6u7/827/++78AHMACPMAE7AUDIAED cMAIkMAIrMAMvMAOHMENPMEQTMEPfMESXMEajMEWnMEcvMEeHMIdPMIgPMIDQAA0IMIlvMIf3MIq7MIk DMMs/MI0HMM1XMInHLwKrG07DAM9jG0/fLsovG1DHANFnG1H3LtBXG1LzAJN/GxPbJVJbG1T3AJVLG1X fJVRnGxbjAJdXGxfLJVZzGxjnAJljGxnPJVhDGxrTAJtnGtv7JRpHGxzXAJ13Gt3/JRxTAxms8cg4Me9 EpoB8wo1AMhKmccR2zWIHAKLTAVMewSNvJSGnAh9PAOTTAdZ2ASXfJSRnMlk08kdAMqYTP/JTSDKR7nF xQmnYJiWWbDJGoDKjkvJBmGvSTLLABKg8cSJFZrKulyyHuDKQTnGxcCd3KkNpCwIVGPKGiDMtozMalkW EUHMxlzM0+zM5qClnlzNxpytsix0yhyUsHzMzmzNfMi7IgPMGBDOxCylZ3DMg+rO4nyj8CwM2WwWpJwP kGSX6LyTZfyJ8wwbVvPNGNDP9WzN7SzN6zzP45yaCo0x2czHxXzQC53QdqzDjODJ4xzNfGzOHbPPFqDO Bh3RDy3S09jQCo3R1TzS+EzR+hy8BJ3J/qzN8fw0An0B/azR5JzQMp3RM83TmHjS4rzT5AwOEj3NdlnT OhnFj3sncdj/NB5dAbAcF0YYVKVrF5+BX4wFH8h8obYiAk9Nk0j9NWFNAS99DBLtM2P9kl/dNWuNwBed cRidM22dkmnNNXWNAMzM0cuJ1ha9bXM911oD2AB311pz14SdNYddb4KNNX/NbYutbol9NYbNbZGdbo9t NY3t1y7NBog9A3et1yNT2eh22VWT2YWZNaR9bkgN2i4z2Y5gCZ0NvB7N2i1j2uQA24y92eyyGeHRy7l7 Ba59TSBIzy8LpNtM20Mg2uemzjhdIxkt06wsBbYN0T5d3cCK0Nh93MhNBKltbmWtriidz04T3LeNoj1t 1PZMzdfcMsptbiD9nOvszxM930gz3fQM/9/YXdQU7dPU5DLdXW7fnd3hzdLj7dlvbd0Acc/UjdM9zQft XW7MTc3xHdL87TT23c5E/dOvTdLoneEUjjL/TW5nvBSMCs3bXQXkzZvZUKhU/X5De+JC8ODkFuJQc+Gi ud+ordvaluKzcNZ23dc8bMnNEN3nrONIbOBEDOTZZuNQbOTYxuPVJuPjRuNPw+TMRuXhFuB2UDVQzpli reQPi2tWvgtgg+XgpuW11uUbAjZSLm7vLeZCDgll7uT3rcqee9zrSDNq/szBuNC/LTJtHm4R/tzNfc+r sdMMXttxDiOIbtQ5DrwvLd9CPenizdcygObN/OEw7gWBDm7hLOkmnf/fKV2uIL7o5Y3fMR3XU2Pm3xbp I+3n3BDq1N3aSO4GKg3Tqi41nf5tgw7q+03pIr3p3G3qs465Q03SmE3nTQsv7yyFpfLnSrDnJD4XRBvQ YK4GPr7qxG5trO5tq53tul7rRy7bW0nkXDDmyNbt3bbrS7Pnycbu3abuSYPuYKzsWCzuT37tTLzt+w7p lI3vVKzvbCjIJNPg0s3vuX7qXm408p7kG07fd9mWvgwF0n4y0E7r5P7wkqAzBh8FY+51ZNPwO37gGz8G HU/xAA/uCq/IAk80vBzrg4gnL9+m+U0aEw8EH++rbcFg8nCf9W3v7vwLhq7Rjg7xfgrs1d3VReD/7s2M 9NCNsZb+uyBdY/9M3A/v9EHf85qM8EEt6kDt8wkv10A/4b1Z9QOP9V5f50vA9A/t67D+4RCfM/Du2CTv 9kWP66eO9tZ98kOQ8/As3zaP7HGPMyI/7rbe9RpO4UR/+EnPF7Iu7CTA9hPu9jCd6JC/9i0/EdPeWxWy G5MFDGoFfJcfAuj+KngnGUbI8GP/7imP23zPNHOv2bIfA7Ot8jW++mjc+kN+8WEQ+0E++z5M9/7u8Eb8 7xn/+7Qv/L/r+0bj7rl//Ct/41+vNPTe45xgBYWf7ws7mlHj/GTO8tA/6wQ/+lVQ/X/mNdkf8Bo//sms +wu/NcwPxBcN8z8C/5tPn7kjU/q7bJhkRcuDAQEIACRnxdJmjeffwgrkSvNEU2RQW/eFY3mma/tGCfXq yK6n/IAjXvBnxCWVNN3y1EQZg1IPcVS1TKdYjW+bIUmpV/KR64xB0Wt22/22sVLIL9FbNpfHQng/3pdr KcKis+PJ4wspPFlE3BPz8TMJlKy0vMTM2QHDQyLk1OPayyQtUWs7Nbmoq+tRFQWjaBUBDbV1LDXN3eXt /ZsDbQyufYz19MWkbFMuGXMeboa1PU5spDvE9WVG5u7uTeUolnZlHaf2rgRHUyf8CrPLzh78DG8dbS/P ZUfn73/brgfJmIdVWmQVPGgQm79/gHYUtHLtyP8hEBWLIKS48Aq2MB8kXjtnCSBDkiVv7MvlKaRJHCiT uGSZKNzMkjBj3sRZYeQulTmd7FQC9OZKPkSRCfWZtGY/j0aVurBpIyrJSKo8spz6VOvRrV1TIL0B1qtP sWPNYsp61mRaGWzVMnT7Vi6asnMZ1p2B1y4/vXv9Sv37NO6LwYF5FTacGEUBSU5fRbt1ti8MxjNWOn6M qA/mS5MVfzaBWBBngnNI+xSdIq3GNRdBY0j9WnHlJJdrED2d07ML2jFyy7hn4zev3bJBp7ZNA7ff2E+U +wl+G7Vx6jN6v1rY8aIzjQdncjRHy/vAfsVVXLdqDfzGc3dCZQe/PYtBYrT/SpmvHnjfu2nSZsETYh6K rMiCDP4066a50Dbpz0D6qnFQlHyAeEaeB4dbQsH85kKPJjwUIeidkKwJLzJ7DMEQDvwWe2HAWEqsBUYK XfwQEhqj62xDHVVjUA9ZIgMws3jECbCTD/nRkAOXVpFwSKvqM1ImlYiEUqZLktzRrA5jzCe4/6J00sQo U5RkxRO2LJFIHMM0UEh6pBznviznzACleYboIo8vQYTxEVYmJNMNLGFj0EUtZGzzFjXPcCdPRc8gZVA6 tUKTvYEgAlC770Aq0KKELK0CvkDdMNOESjv91CJUPyVv1RADejXIjATydJdSJ/XKzsbQoGbUTCRFAFhc /2EQdlicTvUVGCd6TepWDk41tsxoddyPNV6ttUzU6eAodlpNvK0OWnBJ7UPccdlw9tyYulWXUG7bvRJe 0MyVN4l0MaC33rD0TYxdeIH1t92A+d0lX4LzKvfghhTea9BkcfIV4GUZdpdiuQyGAdtx760AY0Ye3pBj iw97A+RKcjM52D5iS5m6gUeuxOMWk0KZXDhkdvNgkWEupVpWIwFavPjE2PTjKYt+9aogu1Dovd8kfsgo gUKdUtP8XuY5YWVdSXSirh/8+s40Y220SAfLVkRsGERGFlLIuAMUyNd2zhqtHo+G82wazUYQwrFjLK3B R2eAerQeCQyzqavr1lKQAP9/zJtrD/n2ErLBRThaHBKPdIFtw5eLqE/OjaOb8XQc1zyzL4Wh8sjNiwIz dUQJW/nuQmV0j1rTvYIWcjwXjafrvmVvcAt3Uo8b4ZsLBf3Qy+OUrfTda3c8abBrLXBpoVltFXFXvaA1 VUxrrQoq6qOAqFeENsBece1lw3p6NHDe3fNSeppTevkF3Z/w8zPBX5bi178k0M909ruf0vJHwKQMcFqF Y2ALHBhBGhiQcQik4FcyeJMJGguCG1wQCE1iwbphUIQc0N8Ja9DBYX1wZrtjoQpZJEMUao2GGEjhDYml w4rx734P5CE6SJg1E16iZWbJYRBVAJOheS97IZLPpFz/iLROiCqKCpSiErvRu7MRCHiSO+JTikge5yXu TcNKohadszUwSih3eJvTFLnkOs0pLYy5UiMy2vam1inKd1ka4xwfJw/LoTGPvtAVH6EXq75tSI6Mel7u 3EanGGqRi2zqYxkBacOPDW5v/bmjVtJ4yDq5YFauWpr7VBXH/2Fnaqt03xM15khS8mKI1ZsknQKZSzZa yVujrKXKdgU4XD1ydL0M5VwqqcRbjqZ8uNrlEzOGxXYBs5bLZOW7gohNHjZzZNEEoTVJyc0dGROE5Lyh Ny0Gzg2K85DopKU2eQhPGarzhdJhQzJlAE5mGTF6wdRHTmZpFmN2R5/VoacK7Qkd/8PwM2c8c2ceE/pQ uZizn6abqAjb5ppWcXQ8U2Okh4DWRCfS55ki4aQruURSWdknaKDyS0TV6DMvig58l+tnhSgEDczx8nTy 7GTiBES15F3xLxkF4R6HRzzhQfGiNS3k6xxlq5RGlY7+seqLnjcXmWoxkZphkuCaekwfSU6QQDrot97w VbOGVU9ZZd/s3oLUDSr1izodqy+/xjnWQTKtk6jq5JL3VsHi1Kdj6aoSv1pHfMCOTdC40z1OJDe7AVV1 /iGe87gjV7XQNYOVIp98MsK0V2qrGeuLojS3h0o5LS9qZEvf+mS5WtTK1i6J3aZiW+nPaHmWggtVGDtL Ni3czv9Tt5a1xEnLCdBSAFdngVVhcXXoW8WYc4PUZaBzCSZcCkr3htg1jHUzCN7+eSxQfyULdA97QeZG KoFARK5WI0je/Wm3l5NyaHfb+6uUwHethyMgfeXXOztSraWjPcZ4Quqdj1rxepq1rbRcGwXxpM163AOX d2m4WC/eSJqazF4dr/c3TFb2v6bpIp+CBy4BT8+ui1Qx3yA5n1GAxMPyrbFebfYGpbbRsOrSsAw5jFbI 9bWwkZOxOXwnWffGV5BU+tEfx9Xi3RFYqngVxpiElGVGfnGqKJ0wI3ia4yjDK8gqZGucNEuTqkRWzVVK MOIutN41WFR0gRtoMfeLCWTZ0bb/noIPhEwbYo4UWlMIhodyl6HeLtdWquc68wn3M7k2pCyAS3GypPd8 CdBSOp9uuDRJuBvBSIvQTtTMZ56Vg2q47FbIm7aEffU1agaW+pzHPbFxYS0JWdeL1gS09XVx7UNd75rR FGbImliSX+B8GjTBHm+2ko1eYlf7tNE29rHFnGzEHpvaW/s2mLOda99QZSx29oay8ThuHqO4p6wFH0ip OFtEO+0mzBaanLuX6PHBLZbZsU9MoE3BIZuRa14aKnsW4VG1tTrTYt1sXoF347DtiSRUNt2LfwypWFYJ qrGDcXm8DfKtivTOYA25qNlN7ssaCY7vRrbXJrtxTLP8bXBm/9SIKHfyFWNl5W7QeJGeataWYxnnZPVG fl9XOewcPXh9NMnA58u8WaynbNGpkNrmTNl+oLutmTojJxbu5jJ/Held/3kbCLxTjp8ypBdeVaBNGuG7 MPqm9WC7ohNcZIbLl7UCTzsbRBPuhrkazYFfgwUJv5df90/qDByMquUlXoIjfn5KbPz+Hh/gYaOi85a/ Qa/llXn5bb5/GK+o4TUNeiWI3szazqDp97cadCze5nX+POsrCBzbNxT2+tV9SywjP8pPPfihH/70SK/8 45/EmQaGKcADDavQ2sPtObFumwvhZ+hLHn7Nt4HGB/HSV54RbRE/+NlFHuaWH/zGHVE/6f/Av0IAE5bk ZnfsY3Vcc2sXUssn7z1/QL266TGIOzrW2b4vk4jASS/28z+zWbqUC5n5Y4L6MzoS85s8+aM4Iyafe7gM xD8voyQKtA7bsT/hYao/KSl6sDiVc0CT26vG6rlNIsE0eL64mz5+I5p9q7HUUrSLU723u764+h7v+4wB zBrXq6bfI7UatMHc+kBhc8IXkL2YcoggqsLpEYDcQ4MthMIpbAElBDImrDUwdAEvLDY3QMPpMsMwxDwy BLY2VIE1pKjpARY6NKXWaCE5TAHQCsC5gUMjfAhD4sMTwENPYyjdgYNDrD8c+EN0QEKeKcBhmsAXbMQb eMSkK0RD3AT/khopWOKU+YinN2DEjlot6EulPdzEEuizFLO/u4q/wGC2NdOThGskHcnC3SnF/0ORjVOl 5VpEC2w7zJKkbFrFDOixmQPAB5Q/S3QbPyEkZsTFY+SAXYTADnyp4QFGUhTGGDxBOvs+asQXE9y5vDkQ 46nEdgO34skscAREcawAa5QlQ3OqFwnFgAtHbnytImQw2Yo3PYNHBFCnUIM0OHS8gEQAeUw+dxzBYPxC cbSnjltCZxShXDQdhaw8h0xDahTDgqTIcEJIjDQ+fdzIY+zIjTFIzQvJGhRJhIygS0quk4m6lLwnRISm lewGQVy1/GhJJdBJl5SNk7wvUGPIZKDJ/2YrSuqwSMbpSUrcjKQci6Z8DqgEyteAyU8MCB8MuHuEFb/j qBlhmvcRN6CLmtQKS3wwnkzkC5xEH8Fpx5PKJKy6szeSC2s8P7CDuRiryjmByQ6jSxo7JhvhwLOCxXok BeESTJ5Tt/xYyrqRR6JZnbDzJWUbzBIDk7l4TGzEHarcy7+4JLwyRZu8RddxOijrBXbissdazOpozKzJ zN9ZJNB0OgzcOg30OLOwy1BZxgnpzCz5zH6zsdJSH3njwb3LOwz7QRWxO1U6pfaZO7Xshtbkmdesyf3L IKnsTQLEpTzsQJT8yHZiy9M6DYm8IezMTkl8w++MvfAEP/M8z5ERyv9fOsr6Yc/mc8/3pJj4JK75PKD6 PL77xE+F0c9oWT76DEgA3TMEDVB+GVBjKdD+PFCWXNC6Sk915CHphBkFbS8NnVB4aVBCtFAdwtCREYAB IAACGAATRVEVTdETbdEVdVEWldEYpVEYtdEXxdEZhdEBEAABKIAC6NEfDVIg9VEiFdIiHdIkRdIlPdIm NdInVVInjVIo7YMSrdEcvVIdxdIb1dIuzVIa5VEmhVIxndIyJdMzlVI0HVMp7dA2ddM3hdM4ldM5pdM6 tdM7xdM81dM95dM+9dM/BdRAFdRBJdRCNdRDRdREVdRFZdRGddRHhdRIldRJpdRKtdRLxdRM1dT/TeXU TvXUTwXVUBXVUSXVUjXVU0XVVFXVVWXUpkhO3utOJ8qPn2wM6ERVV2W129jBoNoRWoUOWz1Vg/KVXX2S LPHVzQBWU2WNYyWGy0hWUmDWknlWUrUWK8I7LErMYoWi9FjWH8xBQ8A7raK7rLzW8nHVcu3WdDVOVuWG ahXMeCNPwNRWXA1OQ4vXknrX0RLXe8VVY/g3evVXbD1Xpxopdm3X9iDW63smjdFXOYOjQnO3fGPA6fNW kPpHl7rHu5tHr5zWUXVXWf1KWcVHPFtXbDGotnTYa8NYkfU7zHm5cMXXmN1KYjVYnkBYkAWxbnW3k5XX gL1XQmNAkg3XWWLY/5ft2ZUdWRr715r1hY+dWZmF2WLlWaXNV70rI56lWNxwVpgF2KC1MKPpV5ZlWiO6 2adF2qhV2an1V7FtS4gdWrwh2q3d14ZFWpPV2rHlBZ3FWaht2bdVWalFmYL1230dRByD25fL2sHFW38Q Vo71Wr3lVbc9W3o0jW9V2JCNXLr92lR6WIvlysW12a4lWM1V18wdWBSx11xFW6qtV8zlVsEl2bCFWtll 3b4F3ZOhXXJtWXct220VT3V1DN4dzgYzJWrKQeZ83OB83dW9XQaK1ubF0+eFXjr92eklVNW13uzV3u3l 3u713u8F3/DthgMg3/I9gBMg3xdIX/Q13/UtAf/3NYHyTQH4jd/zxYD2xV/zrYD8xd/65d/2nd//1V// HeAWoF/2vV/7JWD5fV8FRgABLmAXyF8UOGAOcF8IrmAJ7t8F5l8O/l//pWAMdmAVmOAGJuERzoAS9uAI fgMINmENXmEGTmEUTmAanuETnmER3l8dtmARtuEdxuAG/uAT/mEgTuAYpl/49WH1FeD6xWEgduEYiOIc nuIaDmIhDuErJuIOvuEARmIa1mI3YOEHTuIi7mIqxuIz7mEzJuMn3mEYyGAjVmMliGMoXmM2ruM2PuI1 FmIHruM8Zt8yPuA8vuAilmEDPmQ53uNA7mEaSF9AfmMZSGQyVmIzHuREHuP/DJ5kJ9hkRdZjROZjRl7k HIZhLx5lNxblSOZkQ47jTj7lF1ZlT27kV55jDf5hTLZkBSZkSHblQ95lP2ZjJ4bkT2biWwZmVKbkLJ5l EGYDV1bkYa7kXNZlFHbmWl5mYkZmJ6blG2jlXw5gYz5maz7jPw5mUv5mcV5kQFbnXUbnUR5mUq7mWC7l EN5md/bmesbmJeDlaWbidk7nEY5nfCbmd15nf56Bbp5nBFboU2Zneb7mhKZngS5kUM5mbc5nWL5oN95n Sc5liQ5nVCbnZn5ngf7nclbjgPZogybpSl4DTd5nVo5ohiZomIbjl05ph8boha5pisZpjQ7mkU7mfjbl /6AmYnwGaogWap4+6k9G6ZvuaYtO5Yy2AZfe6aGu5Usu55Cu6nluaKmW5ZxO6qgGahmO56NG6a6eaaM2 6a2W4qzm54O23zGu6JM2aXIG6LVG6qcG64d2aKwGYJ3e65hW6o7W67LG68IuY47m68D+5r+GaotO66du aram7Jhe6keW68au4iWG4ia+Y8+ubL1ebHOu4b0GbbVu661Gax6e6y0+7c4eYpnm6bbmYiqe4sjO6MkO 7dke6svW38n2YWDW4jC27dgOa5UWbWyu4F92bK8eadxe7de26uIuZOmG7dq+6K6uAewObpIuaeNGA99O at+u7t2258ru5cOea9wW7P/srmtfpunj7m3CzmfgtuHaxur2rmjtxoEIXm3VBu+WVm9ofmuOFm7zjmX2 ruelnm7vTm6yXm68hvAGp/CF/m/GfmzLBmNjpm3szvD+nuj5BnBS2OjkTvCfLvDSzmu63m2qDu/7tunB 1umCRmzatmWndvEbl/EP9+rP9vDRBmzIpu+AnvBMWOcUt+ojp2Uip+8eF+dNZnD99m4C/+oT3/Egb20W F3FmXvFldukNN2+tlm9Y1u4SN3GRbnIqV3HB/nLexmgFJ20HD/N7hmGEXnMLj+9iLuo7D2WpPmsa9/NL 1vOoBnIux3OQpnMnF+Nu/mhkTu9GL3TRZukxf+Uox3L/Po9zULZzTD9vKd9zQ5dsSI/0TO9zMXdw/kZu Trfy6X70UW9hv3b1+oZ1dK7mMn9vR1fvCrfiOzbwTed0+Nb1xub1Ph52SX/vWTf2WEd1Of/1SddvFs7k XNdn6Q7jCA9wuw72gebsRO9uBL/uzP70D69i5871caduaJfmmn5tbg9uFL90195gpz53KJf2VW7ueQf2 QM7sRI/0aL5iQKdk4s5y6p5qU/dxMPf0YgZ3gsfwM7fiTgb4dnd3HrdluV7260548dX4jef4jqchiQf5 kBf5kSf5kjf5k0f5lFf5lWf5lnf5l4f5mIf5F5f5mrf5m8f5nNf5nef5nvf5n1d5FY8X+qEn+qI3+qNH +qRX+qVn+sCIAAAh/nBocWdodW1lYXlsbmxmZHhmaXJjdnNjeGdnYndrZm5xZHV4d2ZuZm96dnNydGtq cGxraGp1Y2Z1d29oenZwaGpianlvdmRsbmJmcmt2YmVtADt= --------------000809030205030408010006-- From rtg-dir-bounces@ietf.org Sun Jan 23 08:55:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14473 for ; Sun, 23 Jan 2005 08:55:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsiT5-00031c-LV for rtg-dir-archive@ietf.org; Sun, 23 Jan 2005 09:11:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsiBz-0006zt-HE; Sun, 23 Jan 2005 08:54:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csi8M-0006fV-Mz; Sun, 23 Jan 2005 08:50:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14266; Sun, 23 Jan 2005 08:50:29 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsiOe-0002ws-My; Sun, 23 Jan 2005 09:07:22 -0500 Received: from alille-152-1-18-176.w83-192.abo.wanadoo.fr ([83.192.120.176]) by mx2.foretec.com with smtp (Exim 4.24) id 1Csi7m-0007LS-5L; Sun, 23 Jan 2005 08:49:55 -0500 FCC: mailbox://qpyeiftkaot@yahoo.com/Sent X-Identity-Key: id1 Date: Sun, 23 Jan 2005 08:40:33 -0500 From: Sheila Roth X-Accept-Language: en-us, en MIME-Version: 1.0 To: rtg-dir@ietf.org Content-Type: multipart/related; boundary="------------080605020807040304050000" Message-Id: X-Spam-Score: 3.0 (+++) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Subject: re [10] X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 This is a multi-part message in MIME format. --------------080605020807040304050000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

So-so So-so On the whole Great.

Those who say in 1989

--------------080605020807040304050000 Content-Type: image/gif; name="beman.GIF" Content-ID: Content-Disposition: inline; filename="beman.GIF" Content-Transfer-Encoding: base64 R0lGODlhiQLqAfAJAAkFAP///yH5BAQAABAALAAAAAB/AuMBAAL/jI+py+0Po5y02ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qDQDA9gsOi8dkRbdbTqvX7Pbu fHbL5/S6vQKH3/f8vj+cl/c3SFhoOBQYeLjI2OiIkpj4OElZadkQGXm5ydk5qMml6DlKWkoGeiBpusra +oSKoAom6yAaI5hii6cXgCuT+cqb4ZtDPCz8SZugnMVs5rxiTAI7gSvtkonGdC1BbcO9G0fovazbbP5M rgL+kW1hjQyTra3E/gBcHI9hP6dezh8MXax56cSl4mUQnsGCXnrRG6gPIj6JDx2KMyZQDzGB/wfdUWz4 z4tCbSAtLvwYjmTFjg2vCUu4kKM5XwjZAWzjj+FKKhpPUgwVExZBky1rXvQIlCPRpCWJBj0KU9nQiQyZ ssToUZBKqf5GOjO68yU9sFhp0dwqM2KdnAugRem50+rSq2fdeZU7DyTSkEWfyrrLtC6+vT/nOhWbVdVe wlcDoyPbNipLx35tjTwc8aYatgzcBhTps7FhwHdJQ54LmK9c1KdNQ0UL+nVTvK1ry47jGnZk2asnG5bY cXLuvrot0g6rVg5nTEqdwJ0tWjDx6VaHHy/u8jRr3tuxQ05d2Hr36bhtF1c9HgI3o0mvU09vfndcN8tr Nd9Wfr5N89TF+//PrN1/3FkHXnT8uReYgQMCuGBoKMm31IHpYaYXWPJBR59nDql3XxJaOfibTqKUJuFw XyU3oYkjfjcUel4pJiFlZJ3Y4Hy9hRThbSsmpkuHmonBFoqOTYEYhh8WCQqJNb73YkYoCggbjLzldaF7 UnpX2ZXkiNcZOM/FRt6Og5nl2Y+zlJmThkcU2WV+UY05ZYn80WgjlGES2GJ4M4rJJDJUUhgal1Uyh0ah YMqoY5NNpWljGoxSJeJbb7ZpKJKE6mYnghGklmmIerqJYVUTDgqel0IqeJ5O9hm6oXaiXhhPV42e4lZe dXZIRJ6fjiUnqJp26qKlKfaKqauo9rlkb8D/7vreoJe2euiwyQaaVqhlyGqrtWoiwpim0hab7LfNMnvs r8SCOW654nq7rqftqrrql1jO219c1fYDTbZKbQuEraQKi2e4y6rbrp2SFGjuklqSOyrD653qVMQJ02tS e+4al2G1+j5s5ht/BvsmsuBSXDCD53XKqV3GTtzsVH6e+y936HEor7oCWtwxrU5urA6/PUgHq2Uwoxzj R0ILXPSXDdPFp7K+/jYwy87eI2zJNVbsbs5E0snzlrj+XDVfPU6kJJwkA3rpTGQHCCnI+bbYLcGIGu2g oIiGCjTTWVYN6s6znvNY1/5GikTesGKst8M8no1ZvNJQVSqZMmNLjVBF/1MmIt6XA6p5yGKvZLlkFFJq rRbeCK5v0IWHXZVPak/+tN247ltWqhLr/fKTbd9+d7oJHp42u3cHfyPvD4qG9cXFnxk46ql/7godcWOz e/SLVO5814Rbj9PX0XjPPR/YZy849OGfj771oZOPuvnpvw8/J+Oz377R8d+PfyNB0j+46vn/D8A9MAp3 5OsG+AKIwARWYX+LYt8FfKbAyJjgbxwqAQU9cMEuqS+DHvNRRei3jwO+4IOlYwMHd9GBE1ajhCBQ4UAk uCYWzsCFOFjOSUAYQq19rxzSKwkNNwWdW73QgPYZ4jpkeBAjsuCH+FlCfW7owGPoMBcN7KESRYCcIv8m kYjMueIJOPgQJobwWkjsoGagWEANQLAFJIRIKJbhm2fAMXkbeuOz6pgKi0HrX4ijI6+CoxKMZecofRSk yYrSRyG9DHGsigUfYfLGp+BxN6tZJCSDEskwNlKOjvRjhSiVST1Cqy80SyEEK7NCiFFtihOsIhfsOJYt 2ksvsPykHWEYyFfWcStaBEotb/nHXfJSmL00ZB6J2cXgIFM/iPTlMmmpQWXmkpDC1BwPZVmhZlKzmr8s pBG1actJXpORzTRkOdtyyxyaaW/IqR4F1nhEZuSyF8A0Ei01Wc9oIpOewWwUPkOJzST+s5/a8mE4A5rM fAaTk9185jFhmM99blL/nFdc6D73iNA//hOioBmiRcdp0Xl+VJ8PhCc75VWfVapyia5kzTHflseBHtR+ eETXPEmqUYMqVKc1PSdDe2qgYub0YR61pUgTClSJdnSLOD3oTSc6zU9ulKFLbSgzmSpTrBYURDTL2Um1 Z0pWYtGVIhUJU6lGz0mWlaQv9Gk6IQrUrALUqm5VIkEbCtecArGoCG2VUI1aTqiWbqFynatDDSvEc65V nyEN7Ez5WlIROrN3zwvrSql4zbU+VoOKdSxbBfrW0I4zrjzVa19v+tO7XjS1UmVhYTX714y21oucbGw6 BUtXtRY0ra+1ZkRzK1q8plKHX+VZCyU7DbJ2drSx/00qiGbpRX/y9LDcrK5qmyrb4N4WsHtN6kWl+01w yraET3UsOD3rXFI2l6C+1e1vR9rX4V42HQQEazuQO1aQbhJ0usORG2+FST2V0rux2m8jCctM9BpnmJQk sO42Wt4BqxbBVS2IG0VZKYH2FpCDbSAJK6xf/753q2mVL1eBmE0cHlesHrKDGL9QxhC8+KdnVeNgdSbW RKXxvixe01pivBl5AJmLzB3jPcaQ0l7yr8c0hfGQFzjfzTxZnVOuII3feaoZFyHJtaDbjlcc5QiKecxf hCeKl6xl93UPs3C1xImxTAMwVrnG4zCzAdE8Z8elOQhChIQ95ZfnIlMPhVcuJv+U32ziPX8uisllcpzn rOg20xmpkXZOoGm73RHI2ZSzwKCdE83oRofZYxuotKApSulLb03G7UU1Bzb9alULIdBcpnKoLYhfGy/1 wGhcXj2HimINGxTEwsbRkXhlWh66DrWziaUuJ+tN+t4Ra84uMVV9JRgNQ1vZ/AX2LyWZxU4u8tt/7nUm 1SvKZ0vR0XrO3vfYbWWonFa4tT2vdnU5zKjaE724HS+hbmtVXEKTt3U1w73vetRoBnKq+p70heVKzXzb m6PArW6bgFlL9UYV06B+t4qpCO9Uj7jeaMXnVJOZbFebfLZajS9rSa7uthZK4HBGOXdxU8SUIzjT6+Vu N3X//udXbtjVLc9sOA3s8I57/NZ+DnlezQuwDrv35MHStsNX/qHwwqO5Lo15sYcN35kJfOs47+LBpguj U/M87T9neXBjOXTw/nqxo3xJqT9ta3ezMdcrhCyqN55znVI9u4gNumF5/vfdEt6vnOVnfPsM+SCa1axm bzbaJV/otWO+7VbX7szdm160ct7Bide101X65aWb+qx0hyx4V85xwGP07YK3fHglbVfxRvLf5HzrVYm+ WmdydaKID/epC3t7pYJegssNvZJ1v3PjvwPvptf7CPne3W1SVPYKn3jkI8rgf/wW8dsnsfPv/V2f/r7P pQf+ahlu+8xrn7+Lb7jI01vw/6LL/rqWHTWP63cL2FdKzIYYFndt3rYqs4dsKhcbIKNMXcdZH+Zd3Sd+ ldJhxMZ6YoF+yMZgnqNbV7Vs27R/2QR8H+ZhwRdivoR0c5d/7SZr62Zcj3Z6mcdq4gNkL0hmmOAo1Adm lSWD/ldzfmaD75CDuUBGAvh/2ZIPTjeDD3gHsFaEuIZjQChq/XMDPBiFWZg+tQZySqgDWOhp6EcJq6eF PYSErLYxPACGy2dtMEcKe0aGZehEa1iFTXh3jsZwWhSHVgBdSWdkcvhjZ1hmODhW8EZYoreHUIZdxwWI T0iHOxhyJLFLwEFvo0SJNfVQNUYcyWdhD5hhF8eBN0J2mv/kbZDUiC72iEgmiB41iaPXTq4YWBSnfKIF OhlHixqne6wFfbiYi6dohnYodneYiEyDa5O3az5nfP2WYYZXYa13cAqWgec3WslGd6jli8qRil6GaGdm h9nYVox3GJUIdOfWhlgFeiPVTs44dSuyiHUngj53jYHIbjGog6g3PTAYhzP3ee2XjM2ISJNndppHZ/Q3 i7nXfi93eCPnfvEIiT1WPryXNlZYfXsoOvy4ebNnXSAokKFFkOoIe/J3eQfJfwyJL/jFdL7GOffIjcP4 UR15kdxnjdPIb9JHXeGmfbSXfAQ5gSTpiCLEP8CTOQ+ZaCw1kDVxi1rVRu5nghW4byT/uIL0xYEkKG0U Vo0tyJNS9jV4ZnhBY332SIhEMmtfeZWlwBla+YpceZJNJj58JpZjSZZvY5ZnGZRpGY5+MIzTt41uCUBe E5cmaHl96T96KZhidjp96ZeLhmdqNpiLiUDzA5h0oY0/qZaMSZl7KTmGGSb1JZlDUpmdGUDr85hJgpmT 6ZmlGT+ogJl9Y4FxSZqm6ZpbeJmpKZu5Q4WvaZuXAJqzKZvEeJu9+T6oqZu6yZu+SZznA5zBOZqcWZxy mJeN+RfI+Zh1eYWm0oXddpdOGEd+yGMQgpKtJHlRglR1KJVc+ZnPCZ2JqZzT2YCd6J2JFJOD+Jce1pbp Rm3v6Z3x/6mC6TiIwpdgF5Y/x3meKuaNd7htdNRo/DmfXcWe9FmI+NmcmhaCvLigEOqU/emf+AOgAeo8 w7mE2/aJxYigM4RGWAefqvGgDeqAhfShFMphnSN+lnk0GiqUAxpr6EaO7WlOnXOi3FgYN1qMpGiBEUmh QCqhMteWkuEmF1qgp2meMpqG6fmFK2qALOoXE9qgYAdY87kRFiJiVfgpKmqjhdiiHxqCzhmjTvoxNNp/ 8RdtSRifw9Z0CLiAP9paKQan8Fmnv6N1IJqjk1WmZiodaJqh1xlZnoSdaGig9ZmglsioPXWk6yml7CGE hCRv49amazqeFXmo/6klgnqmhFqovf+npCu2pHCBWZRKgGL5iVJaMTs6fcYkb6K6qWHVYOT0lxEkmp76 qYtKqwg6oJraomymEHOTXMdBSa5KaMNqq8QqptK2rC+qQLmqq1EJqjnEYbWKqKXKqhBqrHJZg9txrBSJ LH5KfEtao7UKrMi6QbsqoxzaLwvoraSqrWHKreAar/dlrFOZj+O6rPfaq9CartXKCIOqoe76rriIrfL6 jikmhiXlieV6qXf3sFU1KQvpsORapP56rs6qqeoaPgQLnQZ7sEZ5cVdKpG9arKQDkYxYss1TaRbKdgn7 r/4ZMh6LPiArnFC6nDurhTibmiLLs0Gbgz4bnWoqtEf7hk26mzr/i7RNS5hKa5hA67RTC6hIwppMS7VZ W57sumRSq7Vfi6FQu5nSCbZlu7WBGmpGa7Zrqz+x2ZVqy7Zxewi5KZRkK7d3Cz90+6RYi7d9yz16a4Vw 67eD2weAuxirSLiJO7duSxiCq7iPK48FpiuOC7mVi42v45gCa7mbe4S147may7mhCyRc8bm8KrqnuwaO qZioy7qApjbb07qx67r2QLmya7tORjvAeLu7CwhcA7q8C7xSkLmmG7zFiwUEa7zJ+wh7q7zNu7gf47zR WwjQK73V+wcqab3ZW5K6q73d2wSI673huzW/K77l+wPka77pq77ry77t677vC7/xm7S3ypQu/7qykWWz nlZl+Su/ejmiJxgToyrASiei+4u+/ZtAqDSrpHifDLp3Bky8CJyFCjyvA6y/FvxuuibBQoukc9o3vvpw aBEOJfusDiy5F/o6Gxy0HSyVH4w2vgo+dTOnOUqbBQhtoaPCK8xLsWpOlyipbBJsCWWKPSxNHszAE5vD PJsfwRqi2Bmr5qZSCXgkNxx+OgKtMpvEt7nE+dnCR1zEYfpmisQqq2o2fOKX35nFy7nFC2bEd/rFHipd fzPGFFvGTZI5c5TGxfm5b+zEEneC01ZyHTXDzmphMuwneazGknvEkhTCYAxg8jUaiyzJm4XBiGybntvI SvrEEkjCZ5adPP9MxCXMyBFryZVpMo0cfkQMxYh5gX08NkdDs5JTyr15yhPryEW6wO6Esdw5oaNsPPw7 y8EszMNMzMVszMeMzMmszMvMzM3szM8MzdEszdNMzdW8tn9ao6aGrLqMo/JKyta8vKucdx80sykBvgPm zcAMzvJ4xfg7NuWMZdycK4O8zriZOwTqG/m7zZz8vfRcz5UAyz2agP+lrK4MqfzczhEKSqD8rGucqO0B rP88hgZmp2I8S5JqyzvSzq5MN9oIx12sKB5trhLdtgedqbPSPJo8wzZ8qXkCyhULxa/xoqPM0iQ90d6H 0KTTsZwc0/5MQCicygwtOqss1D5t0wO7w0H/TUEB/dFNTa4uOJdO3dO3LCUAe8BH3c95CqYxhtFb7dRc PNBbXdWZHMtUrdEojNUATa1fTchNLNUI7dAc68sJrdQgvdEcnYlpXdJfasG0ScV/LM4QC9RuHMpuvcte zcezqtd7jTwRzco2CsS2Kp+tPNh/nc8VW9iGjdnqvNiqKJ+445Ue+MKj3Z2IjTk/zawM3Tio/c2dLUDd Fox6tqBTDBzYfL9ivdBE2tAX3ZQl7NqJHMF3/dvKy9l4OdzSy72dfNzJW5sbu9zPDd3RLd3TTd3Vbd3X jd0HaqUMWmCrhMWp9BPbeGJ5WdzZXWeTzU7HM97WqcEJIt5xDN7mva6A/z3JfifHOe3cxh3W6Czfq/DK ZP3UO6ncnL3PlB3E/W0KspzYomqfdP3ZBE1KY62nbAzbl6jYCG7P62nZ7omMSLTTu8rFGO2zZb2lwY3h SOaEjEzTWRffHI6xf+zi4iTTG17Y5X3iPVnZMY4zZVSRKl7hOs7XSKzjNn7jgZjjc11UKL2iPCLXhJ2r Vn0nRl3km+DLLw2CtLvkcNLkJG7Yuy0UU+7fXlzjF42CEN7XP+7jdzrVI+11YO66Ry7mrkdeJ7zgh63Z db3gRO7mqEjfar5+VukpPIzNaX7ZgzzUcb7nGb5oHc1RgP445rnlGb0nK/7fid4J1MLbzwcxzyXOvv9d pRSeqCPa1pb+tF1K6qeO6qmu6qvO6q3u6q8O67Eu67NO67Vu67eO67mu67vO673u678O7MEu7MNO7MVu 7MeO7Mmu7MvO7M3u7M8O7dEu7dNO7dVOlKlr4o9mBFdtsdrZSkFoz1h5diaU7eFZr/OcsoRGZHh5ohl0 lzoJBffd3GrYUjs4uu/KcTSIr333h1DYXUck3IYWpf/e7Wr3qizr7aZT7r+w8Ot+QfsK7uru71YWT5WM ezXkWtMV8Tb2rcVm4Z9+Z52nSrzGzypUHnFEph2O2yEfigQNUH594UFlbgCxcEtZkCfvwNc22P9o845a e2y+skR9MpdEr2EdqYL/zVwt72WfTMct46o8rfJ+d2QG2OAPi3FlroeAF3EdPpPZN4JurfWAnnuxiPX1 Bo2zKHEN+1TC9Y6waPX7MIlhxPalhW5gZIv4R/DUxYZl5UN4VfVsdV0R1rBSH3YpWH6DH42B3/Xnp+Qy 93gKtoLuHpJGx+8jqXwfabFEpZOLpYwajwdxv3lJKY0uxPmeD/j+6HtOVXBVebH6JzReK2Cwz4JRifiZ FrOlD34eZKQkS1fHNsQU72A3mfUud/m1R/OdhfM5yY7IV/BwJIm6XXzsmO+iwn/3zW1SP4GpyvdhJvr2 +fcwN3iiZ5G1v46NnvvnD+4QO3SxJ0MQtouVD4+n/4X6JzRhxGb5GGmNJr971X90F5nwBBAgDDXZ8zQ5 H0SxYZxX1d35OIosR2kTzWgzKbVtXbSTrbua8dt+1HCRCoJ0ngtxBzzRXL0XSIj76X5Tae3IdDax15xv SGJBw8/iZFhWMsFi5NftlSdX5KQ1eoqV8+eSrG/LioqPaOvPDq2Qrs5CbQkmEvKNy5ER6NFGkFKRbW2w sY0usvCxKE/Ss09PrQdUjDWWbc+sdiZV9IDTMzfxrjVx6vDUsItD15EMmThLU3d3KRmr2ZQrS3pH6LpK efgYbNkS7/n4w/tbVGH7nJuG+1odnP1ZGRPY/d1X3Zgq7ntszzRh4QhRi4ZsHv85Rc7MleMVryE2PxMp VrR4ESMKi+cydvR46WNIkSNJljTZ5GRKlStZtnT58iQ0RDBpRqt5E2fOlTJ19vT5E2jQkvSEkiRaFGlS pUuZNnX6FGpUqVOpVrV69SPHplqrEpzpjyXXimKRkt3IE+tLszF3OVmr8y1NekTjluW36WtYtBfr+uxL TOlftXvZggQpGCbiwZ3ShiKUdydPs2QVd6wM2bDQyxg3821LqbPK0CkBEZ7K0a1pzpJVw7nVurBeW0xH U6w98VBqqAgFLlRirps7z50IKgTkpgtwsBCSjRjT3EiY4sERJS8NT/i+e/968wDoat317t7FTbPm/HqO o8//LXmvh4/883BH49WxDr36pGK58aBb056B6RwqKqJ26ptvkf/O8u2TVmDBRBbGDJADwUkycC8bY1y5 Yjuv1PMFlVSWYQ+5CEvLUMNXLoSwFyQC0ojFQdLDMB3XVoxIQRhxiRCNOWqg8McYU8ysJlpCnOUueFQE TBUlHQwlkDdS6KVJmwIMZruvjrTyRAuNoJK8vLY8KMscoRySS32Q5PELI7F86Ewv4/wQzjWZY0zGTKTj 5yc313tTmu8qHK7KuZ5cKB8PfdBuIDnpAtRQ5AykZTZKFRS0HbwCNYXSVVZ5YkQ0GbFUoijhdNNOK/EB hj5EyyS1nEP/RLHRK1v1yw7w/1J1xjHbikFvJikTtFGLSyzdksQGX/NRTzFBbFbXMMGKlswMedHtv1qv hZTPT7/s1EXQhvVmR0/DtRZNEZu9cilUKy0zs8l+lZY4fwxctpovrf2N22WzXdfeZ3+BIwpNCZ6X2Yei nVRNfYG0KU8tAJXQTm9rGWdgPJOTRd2Mk7WrvYW1VXWOx6p0DduRe+XV0UVClTPgfVmMmZUUqymYE1hH eTUNijlOEsBqf4aYz2/vrbNcaHYEU+NtH26ww3P7JLFV3nZGMFSLMYtSwPw+vlVh4wRGcZ/6flHUanOx w89sq7mLdV+09wtovA/Dy1m+bj8OeT92OZx7YIAYVKjEr/8J9429w8v2uui0WWW3a+2IfOo2l2BrDPPM Nfeo8s09N6nzli7/nPTSSw/d9NT9APsq1FV/HXa4Ro+d9tptvx333HXfffXZKSPMddpmrzM2zxVNK3je sxq+SEP3JjZVf89IPjDmJxeJ+kpWa935tVPvPLTsl/d5LKkznt763fDGPn2TM0KdP8y7pNz67OPqi/r5 CXWaZMxUN5hz7ZPe9hbTK+6Rr131EyBuRoe/BaKPOFzT0hF487IB2cI6gMvGjShoH0R90G/kYJ3gshM0 iYWLbugR14oGRELWlSdu3Rkh1nKFsDsprkI4YpIK4WOfDPKwh+4RWyxyOJceSSpoj5P/nAkRxzOGaENp b5nR0prmMKbNIjvIepIFyXe0tu3Jg4syUxb7JSR7Nc2C8TtQuoY1LSVi0Ecc6p8B05gvqMmRaYOKYYIC McENlsyKActSxNikI9jMj4oV04cXeSChWgkOaLO5osyeJ7NC8g9nJhLWhApVw5VFbZJVBKQqalSy3znS SctJ1iqxM7Ix4WJKGNwYm3SGSVGxLJCS7B0qLVlFUgFHbuZ7ZAcj+a5ZofJRjoFi0Wz5qGMeDIUi9CRk GMYoO5rymlOKVKlsuEN0GfFdRpNY9I4FynQIiz5eMRcCPWYzxdUoNcdzXwyJl7ToVQdhw5zQBWDGS116 y2D2VOXN/zZpLHWaz28DpSe1aDbKYh1slFxBpPfC6S56ufKWbWSB//zjMFxSrJray+UYvTlJkZ2PpOP0 Erh61ktRnoqZAW0jRAtJLV3pzKLhpBJDLzaxOOQrkVqZKPTECSyjYvNkWnyoLpkDK1AwNKTKbFhKB2jS gmJ0jv9aqU+15lI6EU2qgAQPwNKkKpXVUXt1nCmxXhlFmDp0SV+lKpBKQU+UFoiN7BxVP5+6wjUCSI0O nSsd2Zgy8/BtVW60JA4BNta5UUc8LfUnRCi4Qg+lc4gGJZPj3lM48ySqo9uqZdiwltDFQW+oEkEijWwF wqu9LY9dxcZ7lIOOdwpHG9EZ6wU9q/88377OgbuBHU8J9FvjHld5waXccAsaGOQ+F7q0U+5WHggypgJF fNHV7na5213vxq4yxLUM8Hx3ze+SbB4EJGB2g0Ku6souMtIVoHjfR97xXk+kuzOsARl4X6KCVybsHcpe TvnfAOIkvM0NiUTLi1/9BtivVe1vfR08vqS4V33UfG+FFzQ1oyjYwhCksIEfPE/i6dXE5eOwf62bX+Fp OL6i2fCE2UbZEtr0oDirIXXOhjdRnTaWnBRBjqHpWheKB59knM4PNclk3roNVHUbyIugWMLE1hhUf+Qk YMODMqoRechp4LHZSrREuLX2gmHuLThA+GVB0eqE7NMkYOE6rrr/sllZdj0iLPkYJLzW7J935iIhMWZI xD7NtnklM1hjS1dEK9RGYBSjkCWrQ0BrdY2Kjutaz/Y0S1+akB1V89AOfeArsuym07zoPcDlVVK3GiFz zqX+vizrrbJTnzlq66xt2LFVh/JkRAozP3sqNKeNCdMJjeslPZpKkrZarsZmpb5kO+FtlpOLKv01tE1L itseU5+xTthIf+lse+SYcE7NLKLLuSleg7TPyVRhuteH0itD8t56qyg4uR2pbbJ13fCeN1ohvU54y/vX pVyvgn0dQW13m9VlnJNAN0psTI92naYCeFhJ/WiNf/Sj1F5rTnGt72IHaJ8dx6mqbVlWjuZZ/6emZTa3 Fb7yhzOSUFDt809ZPu02QHsYvmYpl/UcaWhFMrANhfnSL47QkAOdoA9nqsF9iSM+v/WoLR/VZ2iGrW8q Xes1bVhOcd5hmhL8pGAatKIVrsii57pFHL+XbDUFdXPaGtU8jWres8lwO0Z16Z82Y0/Japi0ez2UKvpz sHcm8GQvO79Vc7PM4RxEElIycmbG7TqCiFR47o2xGtctOmvLZYN0rfRqy208payn0i4Ty/65LWzHYZDN M+7MMLQb7E+bZcGv/cxLclvpofPEllb51omZMYptJ+DzlpS7zn9+8+Sy/AxPn7rPlz729SJP0lg/gd7n fk5eiNzyjx/96f9X//rZ3/6Xm0xeEOZdZ7afYvW6X/nL0f/+P1ebX3o551QDNcDP1D6seE4MvhaMAC/s gSqHvrKKxBCswWTsWhxPxSLwMKZKvaSoATWQ/+wt+xSwdhzQ+h6QXphPfkBsxCbN2HxlxRBPMarNxUQQ AvtntKpHzuRLdEpQBR3u/TTHBF1wn4JAiPbkM37MtXqPm8hs9vjGeSyPmNbtcC4v3xYta4yPtXKL5zQo yA7LDIgstICo84Csg3AvzcoQPyYP3NBQ92Zw0lqvyfjlsbYwCRlkp6jBk7TwyUCP3gpsG7Dp7x6NnCLs r55t3H5G0titr8iIgwyPtjgt0Yhoi47wj4T/D+5IQbO+CI/UBQoSDvgWjf+q4BA5sdQc8e7C5tIKURPb JN4KzjRiLXEay63GqN0gTdlmkeoypefg5Xzy7pM6TrHu0OICyxd/sdFqbmJ0ceZa6RQxjA7X5Uj6rZuO jZnkCqtEjpdqieogqBl4RGvW0BZhMINm75noBvjIjhebLfjqTc9kyt1aywO5pqtYSmzK0enE7Bz5bQ6l EQSvC9+w0Qv48cT8hBzHptx6sRugjKZGqhK60fPOjtNqMeYqye36MZOyDudqMZEQsh+BreK2LAOBURwz cbKEBscWkl92pfA+8COhcUgE0gZZTqSQjeYksgVhRixK6yEPD6jGZiIp/6rqbvLrMDIdNRIS1THakm9w Qs6u9MckexCgfMpCdM4Tf8wZs0wVmw4gk5Iad+nUuGpeQK65bpDjdvKqIFFlpM28YM4pf07iLMYoBQsp 2/KczjIU2c6gVpIVzarShCnqJFElQY0QX4phWrGUNiEdu27KFiufpEZu7knEmi0xHccUpzESaUVcuowJ pfD44DADBykWM7Mpj0f1rJI0kwQPLQsL1xG9WOkTlyg9jowxOe8DdQ3MHoeRHhPdSO/2jGaRxMxVYAsr lRD/irP96m+HFnAEldM4m9M57S8EQbI4kfM5qxP9zo9AmnA6mdM6u9M7vxM8JZDFcjAy98cAwxM90/8T d4KwBoWwPM3uPNVTPucTCD3wPUMM+twzPumTP/vzNOwzP8cTOr1ywPzTQA8UdJBsDGETDfXw4DQIzVir 95AvyeTBDtlGIdUjDSvriC409HYMQUPUuIrRTF6E6fxJi5To6p4tLHmRFB3J0bQMFWNrLUXURv+nMV0q LjeuqKqSKKWFuHxuqGyuqUyThfjHR1fsRpc0BVcFmMTS1k5u25KRGYswSKu0xxQSlyor24KsJIW0GplU TE0HLmfx7fwKHbcSTImKVw5y65CG2PTO4pRuTZV0TO+UKhYx8pAw7aY0MGFN/nyw8faSLylN/zaqIXfR 1fCUUZuUJMORU8bSnF7/c0WvUhCRkYlAkClPbtfkslE/lX4i68qWEhEJ8UPFsC6xDTFZZczMLEOJJtsq cwynEAlB1Vb5kzqF61Z3lVcFVPt6FViDlUCnL1eF1ViPFVmTVVmXlVmb1VmfFVqjVVqnlVqr1VqvFVuz VVu3lVu71Vu/9Tux8zWKVXQCSDC0E1zTFVf+zVfI9fsc6FzFT13ntXm65yzclS3gVYHwlV61tQ+D4wqV 8FakCUJpFd1aqIIYxYd2E4n+lYYQll/79VpPdVO4FLP+7Qnt0GEftvi6B5yibMkkL2Pt1fSAU2JP9iYo 1poqdpk2ljddlkLrcWSDCWYT0plm9jt4C2V3tvsK//ZfIVaGmpBg8ZFBke9PBtAci7Y3frZsmJZnn1bG FHRCOdZjTdaDZBZos7ZirYHHsDb2LpYMuRNq51VlDTZoSRZdE3ZDUy9gY0WezFZrw/Zj1bY9x9Zu29Vn U6hjV3Vcv8hoqfayPjYJmZZw25ayxPZuT9Zpp/Zv2xZdFXa2vPZofSwzE1JpHWJxBfdxE5dzmSFja8xj 3ZZjufaxapZtic9JRdccb5ZdB1ZeOxd2SVdlWVYgLhbCAtd1cdZmV3V1S1dmNXd2Y1d4GYhmo0xgg7dC g9N4vdZtx1VUl/dhg3dzh5d68zRiU/Z6q1d7y0dcm09wtxd8U3B6l3N8w9d8qf/rdW+ne8+XfdvXfd8X fuNXfueXfuvXfu8Xf/NXf/eXf/vXf/8XgANYdi5j+Zj3Dxb0P/0vfZNXgP2zfJ23Z2OPcRFXARX4fha4 gbvzgbk2gokTQzGYAS24gUA4g5/TaTdWdJ2X9EL2a/UxZ0GWg+G2OYbWhGhYeTH3iTw4dy33DOumhM/r hK/wd3nXbG23hScXeNnVSYMYU0iWdlW3dnG3dT8XZiO3grL3h7FrdG14aN+WikN3cb7Nhb9YiaH4dC0W jK1piGmIZjGWjPHxZ282i7GPiTl0tfDJZAsXdffQcUc33844jA03jgHXixv3bLn0cuV4jrVvi69YhhlY hff/tnKh8ElnyJBxuLbqWI0N947XGGv1+PRIeJEfLGaF2I+NV3b7mPUoGY4t+ZAxOY8buYkNGJUDGW2v uIcdmYJHGX3HI3PHmIN9SJIl+JFpWZiHeYZV2ZdxGZKNjJM/qI4xhZejS5M1L24lJZYv2YMnGGitlpUl 2Y6Zd5CVOZhtOZMd2VUdFoGnmXyn2F4lt/ycuGqRGWSttmaT15OZWZzl+Y1TOWSNeJOdWWrZOXec+InV uHnxuIgnl5gZem2/N5fN2Jwfem77eWFFtqJbNpp0doMJuv8K8oUhN/fwuGHJmaTl9oY7mYW5WJCZeVQl OJkdC0KtuYYH2qNvGqdzWqd3/5qne9qnfxqog1qoh5qoi9qojxqpk1qpl5qpm9qpnxqqo1qqPZeHzTWb lWadK3iXa3l1phpPH9mq6XlwRbl36m98O9qr1dOY6+ucV1lnP8ysFxit0xo90/ilx/mqsVk53smd7Vhu XzZrTvqY33FlR7ppsZiureJzl9ie126PC9uu+Vl3VctV7Dqg8Vl3TZmNyTqxGRmib5lCe0iMkXiMry10 u/iiI3ux2+y0S9tlO9s7Pxu1F/eaO8+hQRk4DRqV9zm0RZuQlxmYYBs8R3tpT1msbdu4uanKVnu3W1q3 31q5o9ihhTu2izemffi4+bj1THu5mdu3z7iMP5i7pXutqf+7OYkblqG7vIv5tx96kymXns+6vVG6mc37 vNtYcn53tUC6a527sd9MaE36cvd7vgdchmnbvreLv0nblRuat1v5wc15kicaio95niFXsiEruRMcugIc oyGawuvZvQ8ar6Gbwhe6kMn7SVlWu0ecw6PP+8DGhlmbd138sAFZnZt7j7ETbnOcsrmZvl9cyIecyIvc yI8cyZNcyZecyZvcyZ8cyqNcyqecyqvcyq8cy7Ncy7ecy7vcy78czMNczMeczMvczM8czdNczdeczdvc zd8czuNczueczuvczu8cz/Ncz/ecz/vcz/8c0ANd0Aed0Avd0A8d0XlWruOZx9d3iVP/G9LLOsbPD8St LNHrM329+7kvG33Ce9MLm6qJ25UX/NKNp3st+8LNGC1SnXZXGGlXm9XfW8RLvTE+/Y95L503/IZtt3Yr OyFwndfXUbMRm9brWV6ROPeC/cexOdl9fGsLAth9HNk5vdjR19jdS4ibnY0Nm9lVS9lVl6q1Pdqzndqr PfwuGtqJ1tul/XG//dsP99d7fd233Zor3dw1gz+OXb/nHdfxVt5znco2193Zndxf+t5DmHS5l94BHpHD nd//Hd5ZY+HfvbJh+ODPfWEVvqp5PbwtXvNYHbXTXdwhPqW5/eIHGNUfOInH3bK7vd5hPbhF/uFNXqQN /uRRXrcd/z1QRnXg9X3h3/sRX7fn+z11Pf7me6Jqnzfnd/jflf2dk37kwbnCh57kd97lj7698r2Sn5fn CX7rIdzr+3Kz0Xnml52maR7ryU/rwb7ou37i8xluqL7VZ7nhGZ7b7V3n0777Ep7aRz3qo5vR337YWTfk 7X7ZKX2u9X7AjvDVZfrvz37Xw37uo0jwid7eIV/x65XvZd7j5T6Sy15pbR30Kb7ROTvzq0/oX8jzMf/x nR7qN3/1a/7qTz/84j3jR1/gK7/qzb7zJR/tf5/2tdjnYX7pRZ+xdxPvpzfWQb7lWT/4p2b4y3jTjd/X ZTrwhUrTiT/7Tf/5e/Z2t9/DN/jyOyEe+H090o/f8btf/def/dvf/d8f/uNf/uef/uvf/qW6AAAAIf5w aHFnaHVtZWF5bG5sZmR4ZmlyY3ZzY3hnZ2J3a2ZucWR1eHdmbmZvenZzcnRranByZXBnZ3hycG5ydnlz dXR3anBiaGhleXNwdnBiZnhxamNtamt1dXhlb3NkbnRpc2N5emtlbmZ5dmNzdHVpZnRxaHhja3NvbwA7 --------------080605020807040304050000-- From rtg-dir-bounces@ietf.org Mon Jan 24 12:32:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04076 for ; Mon, 24 Jan 2005 12:32:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8L4-0004e0-Qu for rtg-dir-archive@ietf.org; Mon, 24 Jan 2005 12:49:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7ur-0000fn-Pt; Mon, 24 Jan 2005 12:22:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7lw-0004Wq-O5; Mon, 24 Jan 2005 12:13:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02570; Mon, 24 Jan 2005 12:13:01 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct82S-0003qT-UD; Mon, 24 Jan 2005 12:30:10 -0500 Received: from adsl-97-195-192-81.adsl.iam.net.ma ([81.192.195.97]) by mx2.foretec.com with smtp (Exim 4.24) id 1Ct7ln-0000g7-2O; Mon, 24 Jan 2005 12:12:58 -0500 FCC: mailbox://nlqtjcozxb@yahoo.com/Sent X-Identity-Key: id1 Date: Mon, 24 Jan 2005 22:03:36 +0500 From: Christoper Lynch X-Accept-Language: en-us, en MIME-Version: 1.0 To: rtg-dir@ietf.org Content-Type: multipart/related; boundary="------------030206090209010602090007" Message-Id: X-Spam-Score: 3.0 (+++) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Subject: re[18]: X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 This is a multi-part message in MIME format. --------------030206090209010602090007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Howard Stern in 1940 Moon Landing in 1835

The Death Penalty help me

--------------030206090209010602090007 Content-Type: image/gif; name="crumple.GIF" Content-ID: Content-Disposition: inline; filename="crumple.GIF" Content-Transfer-Encoding: base64 R0lGODlhkALwAfCjAAkHAP///yH5BAQAABAALAAAAAB/AuMBAAL/jI+py+0Po5y02ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qDQDA9gsOi8dkRbdbTqvX7Pbu fHbL5/S6vQKH3/f8vj+cl/c3SFhoOBQYeLjI2OiIkpj4OElZadkQGXm5ydk5qMml6DlKWkoGeiBpusra +oSKoAom6yAaI5hii6cXgCuT+cqb4ZtDPCz8SZugnMVs5rxiTAI7gSvtkonGdC1BbcO9G0fovazbbP5M rgL+kW1hjQyTra3E/gBcHI9hP6dezh8MXax56cSl4mUQnsGCXnrRG6gPIj6JDx2KMyZQDzGB/wfdUWz4 z4tCbSAtLvwYjmTFjg2vCUu4kKM5XwjZAWzjj+FKKhpPUgwVExZBky1rXvQIlCPRpCWJBj0KU9nQiQyZ ssToUZBKqf5GOjO68yU9sFhp0dwqM2KdnAugRem50+rSq2fdeZU7DyTSkEWfyrrLtC6+vT/nOhWbVdVe wlcDoyPbNipLx35tjTwc8aYatgzcBhTps7FhwHdJQ54LmK9c1KdNQ0UL+nVTvK1ry47jGnZk2asnG5bY cXLuvrot0g6rVg5nTEqdwJ0tWjDx6VaHHy/u8jRr3tuxQ05d2Hr36bhtF1c9HgI3o0mvU09vfndcN8tr Nd9Wfr5N89TF+//PrN1/3FkHXnT8uReYgQMCuGBoKMm31IHpYaYXWPJBR59nDql3XxJaOfibTqKUJuFw XyU3oYkjfjcUel4pJiFlZJ3Y4Hy9hRThbSsmpkuHmonBFoqOTYEYhh8WCQqJNb73YkYoCggbjLzldaF7 UnpX2ZXkiNcZOM/FRt6Og5nl2Y+zlJmThkcU2WV+UY05ZYn80WgjlGES2GJ4M4rJJDJUUhgal1Uyh0ah YMqoY5NNpWljGoxSJeJbb7ZpKJKE6mYnghGklmmIerqJYVUTDgqel0IqeJ5O9hm6oXaiXhhPV42e4lZe dXZIRJ6fjiUnqJp26qKlKfaKqauo9rlkb8D/7vreoJe2euiwyQaaVqhlyGqrtWoiwpim0hab7LfNMnvs r8SCOW654nq7rqftqrrql1jO219c1fYDTbZKbQuEraQKi2e4y6rbrp2SFGjuklqSOyrD653qVMQJ02tS e+4al2G1+j5s5ht/BvsmsuBSXDCD53XKqV3GTtzsVH6e+y936HEor7oCWtwxrU5urA6/PUgHq2Uwoxzj R0ILXPSXDdPFp7K+/jYwy87eI2zJNVbsbs5E0snzlrj+XDVfPU6kJJwkA3rpTGQHCCnI+bbYLcGIGu2g oIiGCjTTWVYN6s6znvNY1/5GikTesGKst8M8no1ZvNJQVSqZMmNLjVBF/1MmIt6XA6p5yGKvZLlkFFJq rRbeCK5v0IWHXZVPak/+tN247ltWqhLr/fKTbd9+d7oJHp42u3cHfyPvD4qG9cXFnxk46ql/7godcWOz e/SLVO5814Rbj9PX0XjPPR/YZy849OGfj771oZOPuvnpvw8/J+Oz377R8d+PfyNB0j+46vn/D8A9MAp3 5OsG+AKIwARWYX+LYt8FfKbAyJjgbxwqAQU9cMEuqS+DHvNRRei3jwO+4IOlYwMHd9GBE1ajhCBQ4UAk uCYWzsCFOFjOSUAYQq19rxzSKwkNNwWdW73QgPYZ4jpkeBAjsuCH+FlCfW7owGPoMBcN7KESRYCcIv8m kYjMueIJOPgQJobwWkjsoGagWEANQLAFJIRIKJbhm2fAMXkbeuOz6pgKi0HrX4ijI6+CoxKMZecofRSk yYrSRyG9DHGsigUfYfLGp+BxN6tZJCSDEskwNlKOjvRjhSiVST1Cqy80SyEEK7NCiFFtihOsIhfsOJYt 2ksvsPykHWEYyFfWcStaBEotb/nHXfJSmL00ZB6J2cXgIFM/iPTlMmmpQWXmkpDC1BwPZVmhZlKzmr8s pBG1actJXpORzTRkOdtyyxyaaW/IqR4F1nhEZuSyF8A0Ei01Wc9oIpOewWwUPkOJzST+s5/a8mE4A5rM fAaTk9185jFhmM99blL/nFdc6D73iNA//hOioBmiRcdp0Xl+VJ8PhCc75VWfVapyia5kzTHflseBHtR+ eETXPEmqUYMqVKc1PSdDe2qgYub0YR61pUgTClSJdnSLOD3oTSc6zU9ulKFLbSgzmSpTrBYURDTL2Um1 Z0pWYtGVIhUJU6lGz0mWlaQv9Gk6IQrUrALUqm5VIkEbCtecArGoCG2VUI1aTqiWbqFynatDDSvEc65V nyEN7Ez5WlIROrN3zwvrSql4zbU+VoOKdSxbBfrW0I4zrjzVa19v+tO7XjS1UmVhYTX714y21oucbGw6 BUtXtRY0ra+1ZkRzK1q8plKHX+VZCyU7DbJ2drSx/00qiGbpRX/y9LDcrK5qmyrb4N4WsHtN6kWl+01w yraET3UsOD3rXFI2l6C+1e1vR9rX4V42HQQEazuQO1aQbhJ0usORG2+FST2V0rux2m8jCctM9BpnmJQk sO42Wt4BqxbBVS2IG0VZKYH2FpCDbSAJK6xf/753q2mVL1eBmE0cHlesHrKDGL9QxhC8+KdnVeNgdSbW RKXxvixe01pivBl5AJmLzB3jPcaQ0l7yr8c0hfGQFzjfzTxZnVOuII3feaoZFyHJtaDbjlcc5QiKecxf hCeKl6xl93UPs3C1xImxTAMwVrnG4zCzAdE8Z8elOQhChIQ95ZfnIlMPhVcuJv+U32ziPX8uisllcpzn rOg20xmpkXZOoGm73RHI2ZSzwKCdE83oRofZYxuotKApSulLb03G7UU1Bzb9alULIdBcpnKoLYhfGy/1 wGhcXj2HimINGxTEwsbRkXhlWh66DrWziaUuJ+tN+t4Ra84uMVV9JRgNQ1vZ/AX2LyWZxU4u8tt/7nUm 1SvKZ0vR0XrO3vfYbWWonFa4tT2vdnU5zKjaE724HS+hbmtVXEKTt3U1w73vetRoBnKq+p70heVKzXzb m6PArW6bgFlL9UYV06B+t4qpCO9Uj7jeaMXnVJOZbFebfLZajS9rSa7uthZK4HBGOXdxU8SUIzjT6+Vu N3X//udXbtjVLc9sOA3s8I57/NZ+DnlezQuwDrv35MHStsNX/qHwwqO5Lo15sYcN35kJfOs47+LBpguj U/M87T9neXBjOXTw/nqxo3xJqT9ta3ezMdcrhCyqN55znVI9u4gNumF5/vfdEt6vnOVnfPsM+SCa1axm bzbaJV/otWO+7VbX7szdm160ct7Bide101X65aWb+qx0hyx4V85xwGP07YK3fHglbVfxRvLf5HzrVYm+ WmdydaKID/epC3t7pYJegssNvZJ1v3PjvwPvptf7CPne3W1SVPYKn3jkI8rgf/wW8dsnsfPv/V2f/r7P pQf+ahlu+8xrn7+Lb7jI01vw/6LL/rqWHTWP63cL2FdKzIYYFndt3rYqs4dsKhcbIKNMXcdZH+Zd3Sd+ ldJhxMZ6YoF+yMZgnqNbV7Vs27R/2QR8H+ZhwRdivoR0c5d/7SZr62Zcj3Z6mcdq4gNkL0hmmOAo1Adm lSWD/ldzfmaD75CDuUBGAvh/2ZIPTjeDD3gHsFaEuIZjQChq/XMDPBiFWZg+tQZySqgDWOhp6EcJq6eF PYSErLYxPACGy2dtMEcKe0aGZehEa1iFTXh3jsZwWhSHVgBdSWdkcvhjZ1hmODhW8EZYoreHUIZdxwWI T0iHOxhyJLFLwEFvo0SJNfVQNUYcyWdhD5hhF8eBN0J2mv/kbZDUiC72iEgmiB41iaPXTq4YWBSnfKIF OhlHixqne6wFfbiYi6dohnYodneYiEyDa5O3az5nfP2WYYZXYa13cAqWgec3WslGd6jli8qRil6GaGdm h9nYVox3GJUIdOfWhlgFeiPVTs44dSuyiHUngj53jYHIbjGog6g3PTAYhzP3ee2XjM2ISJNndppHZ/Q3 i7nXfi93eCPnfvEIiT1WPryXNlZYfXsoOvy4ebNnXSAokKFFkOoIe/J3eQfJfwyJL/jFdL7GOffIjcP4 UR15kdxnjdPIb9JHXeGmfbSXfAQ5gSTpiCLEP8CTOQ+ZaCw1kDVxi1rVRu5nghW4byT/uIL0xYEkKG0U Vo0tyJNS9jV4ZnhBY332SIhEMmtfeZWlwBla+YpceZJNJj58JpZjSZZvY5ZnGZRpGY5+MIzTt41uCUBe E5cmaHl96T96KZhidjp96ZeLhmdqNpiLiUDzA5h0oY0/qZaMSZl7KTmGGSb1JZlDUpmdGUDr85hJgpmT 6ZmlGT+ogJl9Y4FxSZqm6ZpbeJmpKZu5Q4WvaZuXAJqzKZvEeJu9+T6oqZu6yZu+SZznA5zBOZqcWZxy mJeN+RfI+Zh1eYWm0oXddpdOGEd+yGMQgpKtJHlRglR1KJVc+ZnPCZ2JqZzT2YCd6J2JFJOD+Jce1pbp Rm3v6Z3x/6mC6TiIwpdgF5Y/x3meKuaNd7htdNRo/DmfXcWe9FmI+NmcmhaCvLigEOqU/emf+AOgAeo8 w7mE2/aJxYigM4RGWAefqvGgDeqAhfShFMphnSN+lnk0GiqUAxpr6EaO7WlOnXOi3FgYN1qMpGiBEUmh QCqhMteWkuEmF1qgp2meMpqG6fmFK2qALOoXE9qgYAdY87kRFiJiVfgpKmqjhdiiHxqCzhmjTvoxNNp/ 8RdtSRifw9Z0CLiAP9paKQan8Fmnv6N1IJqjk1WmZiodaJqh1xlZnoSdaGig9ZmglsioPXWk6yml7CGE hCRv49amazqeFXmo/6klgnqmhFqovf+npCu2pHCBWZRKgGL5iVJaMTs6fcYkb6K6qWHVYOT0lxEkmp76 qYtKqwg6oJraomymEHOTXMdBSa5KaMNqq8QqptK2rC+qQLmqq1EJqjnEYbWKqKXKqhBqrHJZg9txrBSJ LH5KfEtao7UKrMi6QbsqoxzaLwvoraSqrWHKreAar/dlrFOZj+O6rPfaq9CartXKCIOqoe76rriIrfL6 jikmhiXlieV6qXf3sFU1KQvpsORapP56rs6qqeoaPgQLnQZ7sEZ5cVdKpG9arKQDkYxYss1TaRbKdgn7 r/4ZMh6LPiArnFC6nDurhTibmiLLs0Gbgz4bnWoqtEf7hk26mzr/i7RNS5hKa5hA67RTC6hIwppMS7VZ W57sumRSq7Vfi6FQu5nSCbZlu7WBGmpGa7Zrqz+x2ZVqy7Zxewi5KZRkK7d3Cz90+6RYi7d9yz16a4Vw 67eD2weAuxirSLiJO7duSxiCq7iPK48FpiuOC7mVi42v45gCa7mbe4S147may7mhCyRc8bm8KrqnuwaO qZioy7qApjbb07qx67r2QLmya7tORjvAeLu7CwhcA7q8C7xSkLmmG7zFiwUEa7zJ+wh7q7zNu7gf47zR WwjQK73V+wcqab3ZW5K6q73d2wSI673huzW/K77l+wPka77pq77ry77t677vC7/xm7S3ypQu/7qykWWz nlZl+Su/ejmiJxgToyrASiei+4u+/ZtAqDSrpHifDLp3Bky8CJyFCjyvA6y/FvxuuibBQoukc9o3vvpw aBEOJfusDiy5F/o6Gxy0HSyVH4w2vgo+dTOnOUqbBQhtoaPCK8xLsWpOlyipbBJsCWWKPSxNHszAE5vD PJsfwRqi2Bmr5qZSCXgkNxx+OgKtMpvEt7nE+dnCR1zEYfpmisQqq2o2fOKX35nFy7nFC2bEd/rFHipd fzPGFFvGTZI5c5TGxfm5b+zEEneC01ZyHTXDzmphMuwneazGknvEkhTCYAxg8jUaiyzJm4XBiGybntvI SvrEEkjCZ5adPP9MxCXMyBFryZVpMo0cfkQMxYh5gX08NkdDs5JTyr15yhPryEW6wO6Esdw5oaNsPPw7 y8EszMNMzMVszMeMzMmszMvMzM3szM8MzdEszdNMzdW8tn9ao6aGrLqMo/JKyta8vKucdx80sykBvgPm zcAMzvJ4xfg7NuWMZdycK4O8zriZOwTqG/m7zZz8vfRcz5UAyz2agP+lrK4MqfzczhEKSqD8rGucqO0B rP88hgZmp2I8S5JqyzvSzq5MN9oIx12sKB5trhLdtgedqbPSPJo8wzZ8qXkCyhULxa/xoqPM0iQ90d6H 0KTTsZwc0/5MQCicygwtOqss1D5t0wO7w0H/TUEB/dFNTa4uOJdO3dO3LCUAe8BH3c95CqYxhtFb7dRc PNBbXdWZHMtUrdEojNUATa1fTchNLNUI7dAc68sJrdQgvdEcnYlpXdJfasG0ScV/LM4QC9RuHMpuvcte zcezqtd7jTwRzco2CsS2Kp+tPNh/nc8VW9iGjdnqvNiqKJ+445Ue+MKj3Z2IjTk/zawM3Tio/c2dLUDd Fox6tqBTDBzYfL9ivdBE2tAX3ZQl7NqJHMF3/dvKy9l4OdzSy72dfNzJW5sbu9zPDd3RLd3TTd3Vbd3X jd0HaqUMWmCrhMWp9BPbeGJ5WdzZXWeTzU7HM97WqcEJIt5xDN7mva6A/z3JfifHOe3cxh3W6Czfq/DK ZP3UO6ncnL3PlB3E/W0KspzYomqfdP3ZBE1KY62nbAzbl6jYCG7P62nZ7omMSLTTu8rFGO2zZb2lwY3h SOaEjEzTWRffHI6xf+zi4iTTG17Y5X3iPVnZMY4zZVSRKl7hOs7XSKzjNn7jgZjjc11UKL2iPCLXhJ2r Vn0nRl3km+DLLw2CtLvkcNLkJG7Yuy0UU+7fXlzjF42CEN7XP+7jdzrVI+11YO66Ry7mrkdeJ7zgh63Z db3gRO7mqEjfar5+VukpPIzNaX7ZgzzUcb7nGb5oHc1RgP445rnlGb0nK/7fid4J1MLbzwcxzyXOvv9d pRSeqCPa1pb+tF1K6qeO6qmu6qvO6q3u6q8O67Eu67NO67Vu67eO67mu67vO673u678O7MEu7MNO7MVu 7MeO7Mmu7MvO7M3u7M8O7dEu7dNO7dVOlKlr4o9mBFdtsdrZSkFoz1h5diaU7eFZr/OcsoRGZHh5ohl0 lzoJBffd3GrYUjs4uu/KcTSIr333h1DYXUck3IYWpf/e7Wr3qizr7aZT7r+w8Ot+QfsK7uru71YWT5WM ezXkWtMV8Tb2rcVm4Z9+Z52nSrzGzypUHnFEph2O2yEfigQNUH594UFlbgCxcEtZkCfvwNc22P9o845a e2y+skR9MpdEr2EdqYL/zVwt72WfTMct46o8rfJ+d2QG2OAPi3FlroeAF3EdPpPZN4JurfWAnnuxiPX1 Bo2zKHEN+1TC9Y6waPX7MIlhxPalhW5gZIv4R/DUxYZl5UN4VfVsdV0R1rBSH3YpWH6DH42B3/Xnp+Qy 93gKtoLuHpJGx+8jqXwfabFEpZOLpYwajwdxv3lJKY0uxPmeD/j+6HtOVXBVebH6JzReK2Cwz4JRifiZ FrOlD34eZKQkS1fHNsQU72A3mfUud/m1R/OdhfM5yY7IV/BwJIm6XXzsmO+iwn/3zW1SP4GpyvdhJvr2 +fcwN3iiZ5G1v46NnvvnD+4QO3SxJ0MQtouVD4+n/4X6JzRhxGb5GGmNJr971X90F5nwBBAgDDXZ8zQ5 H0SxYZxX1d35OIosR2kTzWgzKbVtXbSTrbua8dt+1HCRCoJ0ngtxBzzRXL0XSIj76X5Tae3IdDax15xv SGJBw8/iZFhWMsFi5NftlSdX5KQ1eoqV8+eSrG/LioqPaOvPDq2Qrs5CbQkmEvKNy5ER6NFGkFKRbW2w sY0usvCxKE/Ss09PrQdUjDWWbc+sdiZV9IDTMzfxrjVx6vDUsItD15EMmThLU3d3KRmr2ZQrS3pH6LpK efgYbNkS7/n4w/tbVGH7nJuG+1odnP1ZGRPY/d1X3Zgq7ntszzRh4QhRi4ZsHv85Rc7MleMVryE2PxMp VrR4ESMKi+cydvR46WNIkSNJljTZ5GRKlStZtnT58iQ0RDBpRqt5E2fOlTJ19vT5E2jQkvSEkiRaFGlS pUuZNnX6FGpUqVOpVrV69SPHplqrEpzpjyXXimKRkt3IE+tLszF3OVmr8y1NekTjluW36WtYtBfr+uxL TOlftXvZggQpGCbiwZ3ShiKUdydPs2QVd6wM2bDQyxg3821LqbPK0CkBEZ7K0a1pzpJVw7nVurBeW0xH U6w98VBqqAgFLlRirps7z50IKgTkpgtwsBCSjRjT3EiY4sERJS8NT/i+e/968wDoat317t7FTbPm/HqO o8//LXmvh4/883BH49WxDr36pGK58aBb056B6RwqKqJ26ptvkf/O8u2TVmDBRBbGDJADwUkycC8bY1y5 Yjuv1PMFlVSWYQ+5CEvLUMNXLoSwFyQC0ojFQdLDMB3XVoxIQRhxiRCNOWqg8McYU8ysJlpCnOUueFQE TBUlHQwlkDdS6KVJmwIMZruvjrTyRAuNoJK8vLY8KMscoRySS32Q5PELI7F86Ewv4/wQzjWZY0zGTKTj 5yc313tTmu8qHK7KuZ5cKB8PfdBuIDnpAtRQ5AykZTZKFRS0HbwCNYXSVVZ5YkQ0GbFUoijhdNNOK/EB hj5EyyS1nEP/RLHRK1v1yw7w/1J1xjHbikFvJikTtFGLSyzdksQGX/NRTzFBbFbXMMGKlswMedHtv1qv hZTPT7/s1EXQhvVmR0/DtRZNEZu9cilUKy0zs8l+lZY4fwxctpovrf2N22WzXdfeZ3+BIwpNCZ6X2Yei nVRNfYG0KU8tAJXQTm9rGWdgPJOTRd2Mk7WrvYW1VXWOx6p0DduRe+XV0UVClTPgfVmMmZUUqymYE1hH eTUNijlOEsBqf4aYz2/vrbNcaHYEU+NtH26ww3P7JLFV3nZGMFSLMYtSwPw+vlVh4wRGcZ/6flHUanOx w89sq7mLdV+09wtovA/Dy1m+bj8OeT92OZx7YIAYVKjEr/8J9429w8v2uui0WWW3a+2IfOo2l2BrDPPM Nfeo8s09N6nzli7/nPTSSw/d9NT9APsq1FV/HXa4Ro+d9tptvx333HXfffXZKSPMddpmrzM2zxVNK3je sxq+SEP3JjZVf89IPjDmJxeJ+kpWa935tVPvPLTsl/d5LKkznt763fDGPn2TM0KdP8y7pNz67OPqi/r5 CXWaZMxUN5hz7ZPe9hbTK+6Rr131EyBuRoe/BaKPOFzT0hF487IB2cI6gMvGjShoH0R90G/kYJ3gshM0 iYWLbugR14oGRELWlSdu3Rkh1nKFsDsprkI4YpIK4WOfDPKwh+4RWyxyOJceSSpoj5P/nAkRxzOGaENp b5nR0prmMKbNIjvIepIFyXe0tu3Jg4syUxb7JSR7Nc2C8TtQuoY1LSVi0Ecc6p8B05gvqMmRaYOKYYIC McENlsyKActSxNikI9jMj4oV04cXeSChWgkOaLO5osyeJ7NC8g9nJhLWhApVw5VFbZJVBKQqalSy3znS SctJ1iqxM7Ix4WJKGNwYm3SGSVGxLJCS7B0qLVlFUgFHbuZ7ZAcj+a5ZofJRjoFi0Wz5qGMeDIUi9CRk GMYoO5rymlOKVKlsuEN0GfFdRpNY9I4FynQIiz5eMRcCPWYzxdUoNcdzXwyJl7ToVQdhw5zQBWDGS116 y2D2VOXN/zZpLHWaz28DpSe1aDbKYh1slFxBpPfC6S56ufKWbWSB//zjMFxSrJray+UYvTlJkZ2PpOP0 Erh61ktRnoqZAW0jRAtJLV3pzKLhpBJDLzaxOOQrkVqZKPTECSyjYvNkWnyoLpkDK1AwNKTKbFhKB2jS gmJ0jv9aqU+15lI6EU2qgAQPwNKkKpXVUXt1nCmxXhlFmDp0SV+lKpBKQU+UFoiN7BxVP5+6wjUCSI0O nSsd2Zgy8/BtVW60JA4BNta5UUc8LfUnRCi4Qg+lc4gGJZPj3lM48ySqo9uqZdiwltDFQW+oEkEijWwF wqu9LY9dxcZ7lIOOdwpHG9EZ6wU9q/88377OgbuBHU8J9FvjHld5waXccAsaGOQ+F7q0U+5WHggypgJF fNHV7na5213vxq4yxLUM8Hx3ze+SbB4EJGB2g0Ku6souMtIVoHjfR97xXk+kuzOsARl4X6KCVybsHcpe TvnfAOIkvM0NiUTLi1/9BtivVe1vfR08vqS4V33UfG+FFzQ1oyjYwhCksIEfPE/i6dXE5eOwf62bX+Fp OL6i2fCE2UbZEtr0oDirIXXOhjdRnTaWnBRBjqHpWheKB59knM4PNclk3roNVHUbyIugWMLE1hhUf+Qk YMODMqoRechp4LHZSrREuLX2gmHuLThA+GVB0eqE7NMkYOE6rrr/sllZdj0iLPkYJLzW7J935iIhMWZI xD7NtnklM1hjS1dEK9RGYBSjkCWrQ0BrdY2Kjutaz/Y0S1+akB1V89AOfeArsuym07zoPcDlVVK3GiFz zqX+vizrrbJTnzlq66xt2LFVh/JkRAozP3sqNKeNCdMJjeslPZpKkrZarsZmpb5kO+FtlpOLKv01tE1L itseU5+xTthIf+lse+SYcE7NLKLLuSleg7TPyVRhuteH0itD8t56qyg4uR2pbbJ13fCeN1ohvU54y/vX pVyvgn0dQW13m9VlnJNAN0psTI92naYCeFhJ/WiNf/Sj1F5rTnGt72IHaJ8dx6mqbVlWjuZZ/6emZTa3 Fb7yhzOSUFDt809ZPu02QHsYvmYpl/UcaWhFMrANhfnSL47QkAOdoA9nqsF9iSM+v/WoLR/VZ2iGrW8q Xes1bVhOcd5hmhL8pGAatKIVrsii57pFHL+XbDUFdXPaGtU8jWres8lwO0Z16Z82Y0/Japi0ez2UKvpz sHcm8GQvO79Vc7PM4RxEElIycmbG7TqCiFR47o2xGtctOmvLZYN0rfRqy208payn0i4Ty/65LWzHYZDN M+7MMLQb7E+bZcGv/cxLclvpofPEllb51omZMYptJ+DzlpS7zn9+8+Sy/AxPn7rPlz729SJP0lg/gd7n fk5eiNzyjx/96f9X//rZ3/6Xm0xeEOZdZ7afYvW6X/nL0f/+P1ebX3o551QDNcDP1D6seE4MvhaMAC/s gSqHvrKKxBCswWTsWhxPxSLwMKZKvaSoATWQ/+wt+xSwdhzQ+h6QXphPfkBsxCbN2HxlxRBPMarNxUQQ AvtntKpHzuRLdEpQBR3u/TTHBF1wn4JAiPbkM37MtXqPm8hs9vjGeSyPmNbtcC4v3xYta4yPtXKL5zQo yA7LDIgstICo84Csg3AvzcoQPyYP3NBQ92Zw0lqvyfjlsbYwCRlkp6jBk7TwyUCP3gpsG7Dp7x6NnCLs r55t3H5G0titr8iIgwyPtjgt0Yhoi47wj4T/D+5IQbO+CI/UBQoSDvgWjf+q4BA5sdQc8e7C5tIKURPb JN4KzjRiLXEay63GqN0gTdlmkeoypefg5Xzy7pM6TrHu0OICyxd/sdFqbmJ0ceZa6RQxjA7X5Uj6rZuO jZnkCqtEjpdqieogqBl4RGvW0BZhMINm75noBvjIjhebLfjqTc9kyt1aywO5pqtYSmzK0enE7Bz5bQ6l EQSvC9+w0Qv48cT8hBzHptx6sRugjKZGqhK60fPOjtNqMeYqye36MZOyDudqMZEQsh+BreK2LAOBURwz cbKEBscWkl92pfA+8COhcUgE0gZZTqSQjeYksgVhRixK6yEPD6jGZiIp/6rqbvLrMDIdNRIS1THakm9w Qs6u9MckexCgfMpCdM4Tf8wZs0wVmw4gk5Iad+nUuGpeQK65bpDjdvKqIFFlpM28YM4pf07iLMYoBQsp 2/KczjIU2c6gVpIVzarShCnqJFElQY0QX4phWrGUNiEdu27KFiufpEZu7knEmi0xHccUpzESaUVcuowJ pfD44DADBykWM7Mpj0f1rJI0kwQPLQsL1xG9WOkTlyg9jowxOe8DdQ3MHoeRHhPdSO/2jGaRxMxVYAsr lRD/irP96m+HFnAEldM4m9M57S8EQbI4kfM5qxP9zo9AmnA6mdM6u9M7vxM8JZDFcjAy98cAwxM90/8T d4KwBoWwPM3uPNVTPucTCD3wPUMM+twzPumTP/vzNOwzP8cTOr1ywPzTQA8UdJBsDGETDfXw4DQIzVir 95AvyeTBDtlGIdUjDSvriC409HYMQUPUuIrRTF6E6fxJi5To6p4tLHmRFB3J0bQMFWNrLUXURv+nMV0q LjeuqKqSKKWFuHxuqGyuqUyThfjHR1fsRpc0BVcFmMTS1k5u25KRGYswSKu0xxQSlyor24KsJIW0GplU TE0HLmfx7fwKHbcSTImKVw5y65CG2PTO4pRuTZV0TO+UKhYx8pAw7aY0MGFN/nyw8faSLylN/zaqIXfR 1fCUUZuUJMORU8bSnF7/c0WvUhCRkYlAkClPbtfkslE/lX4i68qWEhEJ8UPFsC6xDTFZZczMLEOJJtsq cwynEAlB1Vb5kzqF61Z3lVcFVPt6FViDlUCnL1eF1ViPFVmTVVmXlVmb1VmfFVqjVVqnlVqr1VqvFVuz VVu3lVu71Vu/9Tux8zWKVXQCSDC0E1zTFVf+zVfI9fsc6FzFT13ntXm65yzclS3gVYHwlV61tQ+D4wqV 8FakCUJpFd1aqIIYxYd2E4n+lYYQll/79VpPdVO4FLP+7Qnt0GEftvi6B5yibMkkL2Pt1fSAU2JP9iYo 1poqdpk2ljddlkLrcWSDCWYT0plm9jt4C2V3tvsK//ZfIVaGmpBg8ZFBke9PBtAci7Y3frZsmJZnn1bG FHRCOdZjTdaDZBZos7ZirYHHsDb2LpYMuRNq51VlDTZoSRZdE3ZDUy9gY0WezFZrw/Zj1bY9x9Zu29Vn U6hjV3Vcv8hoqfayPjYJmZZw25ayxPZuT9Zpp/Zv2xZdFXa2vPZofSwzE1JpHWJxBfdxE5dzmSFja8xj 3ZZjufaxapZtic9JRdccb5ZdB1ZeOxd2SVdlWVYgLhbCAtd1cdZmV3V1S1dmNXd2Y1d4GYhmo0xgg7dC g9N4vdZtx1VUl/dhg3dzh5d68zRiU/Z6q1d7y0dcm09wtxd8U3B6l3N8w9d8qf/rdW+ne8+XfdvXfd8X fuNXfueXfuvXfu8Xf/NXf/eXf/vXf/8XgANYdi5j+Zj3Dxb0P/0vfZNXgP2zfJ23Z2OPcRFXARX4fha4 gbvzgbk2gokTQzGYAS24gUA4g5/TaTdWdJ2X9EL2a/UxZ0GWg+G2OYbWhGhYeTH3iTw4dy33DOumhM/r hK/wd3nXbG23hScXeNnVSYMYU0iWdlW3dnG3dT8XZiO3grL3h7FrdG14aN+WikN3cb7Nhb9YiaH4dC0W jK1piGmIZjGWjPHxZ282i7GPiTl0tfDJZAsXdffQcUc33844jA03jgHXixv3bLn0cuV4jrVvi69YhhlY hff/tnKh8ElnyJBxuLbqWI0N947XGGv1+PRIeJEfLGaF2I+NV3b7mPUoGY4t+ZAxOY8buYkNGJUDGW2v uIcdmYJHGX3HI3PHmIN9SJIl+JFpWZiHeYZV2ZdxGZKNjJM/qI4xhZejS5M1L24lJZYv2YMnGGitlpUl 2Y6Zd5CVOZhtOZMd2VUdFoGnmXyn2F4lt/ycuGqRGWSttmaT15OZWZzl+Y1TOWSNeJOdWWrZOXec+InV uHnxuIgnl5gZem2/N5fN2Jwfem77eWFFtqJbNpp0doMJuv8K8oUhN/fwuGHJmaTl9oY7mYW5WJCZeVQl OJkdC0KtuYYH2qNvGqdzWqd3/5qne9qnfxqog1qoh5qoi9qojxqpk1qpl5qpm9qpnxqqo1qqPZeHzTWb lWadK3iXa3l1phpPH9mq6XlwRbl36m98O9qr1dOY6+ucV1lnP8ysFxit0xo90/ilx/mqsVk53smd7Vhu XzZrTvqY33FlR7ppsZiureJzl9ie126PC9uu+Vl3VctV7Dqg8Vl3TZmNyTqxGRmib5lCe0iMkXiMry10 u/iiI3ux2+y0S9tlO9s7Pxu1F/eaO8+hQRk4DRqV9zm0RZuQlxmYYBs8R3tpT1msbdu4uanKVnu3W1q3 31q5o9ihhTu2izemffi4+bj1THu5mdu3z7iMP5i7pXutqf+7OYkblqG7vIv5tx96kymXns+6vVG6mc37 vNtYcn53tUC6a527sd9MaE36cvd7vgdchmnbvreLv0nblRuat1v5wc15kicaio95niFXsiEruRMcugIc oyGawuvZvQ8ar6Gbwhe6kMn7SVlWu0ecw6PP+8DGhlmbd138sAFZnZt7j7ETbnOcsrmZvl9cyIecyIvc yI8cyZNcyZecyZvcyZ8cyqNcyqecyqvcyq8cy7Ncy7ecy7vcy78czMNczMeczMvczM8czdNczdeczdvc zd8czuNczueczuvczu8cz/Ncz/ecz/vcz/8c0ANd0Aed0Avd0A8d0XlWruOZx9d3iVP/G9LLOsbPD8St LNHrM329+7kvG33Ce9MLm6qJ25UX/NKNp3st+8LNGC1SnXZXGGlXm9XfW8RLvTE+/Y95L503/IZtt3Yr OyFwndfXUbMRm9brWV6ROPeC/cexOdl9fGsLAth9HNk5vdjR19jdS4ibnY0Nm9lVS9lVl6q1Pdqzndqr PfwuGtqJ1tul/XG//dsP99d7fd233Zor3dw1gz+OXb/nHdfxVt5znco2193Zndxf+t5DmHS5l94BHpHD nd//Hd5ZY+HfvbJh+ODPfWEVvqp5PbwtXvNYHbXTXdwhPqW5/eIHGNUfOInH3bK7vd5hPbhF/uFNXqQN /uRRXrcd/z1QRnXg9X3h3/sRX7fn+z11Pf7me6Jqnzfnd/jflf2dk37kwbnCh57kd97lj7698r2Sn5fn CX7rIdzr+3Kz0Xnml52maR7ryU/rwb7ou37i8xluqL7VZ7nhGZ7b7V3n0777Ep7aRz3qo5vR337YWTfk 7X7ZKX2u9X7AjvDVZfrvz37Xw37uo0jwid7eIV/x65XvZd7j5T6Sy15pbR30Kb7ROTvzq0/oX8jzMf/x nR7qN3/1a/7qTz/84j3jR1/gK7/qzb7zJR/tf5/2tdjnYX7pRZ+xdxPvpzfWQb7lWT/4p2b4y3jTjd/X ZTrwhUrTiT/7Tf/5e/Z2t9/DN/jyOyEe+H090o/f8btf/def/dvf/d8f/uNf/uef/uvf/qW6AAAAIf5w aHFnaHVtZWF5bG5sZmR4ZmlyY3ZzY3hnZ2J3a2ZucWR1eHdmbmZvenZzcnRranByZXBnZ3hycG5ydnlz Y2dnb2V3dnJ4Ynd5c3pibHFncHdqcGx0amZycWNvY3F4eWx1dHRsd2h0ADt= --------------030206090209010602090007-- From rtg-dir-bounces@ietf.org Mon Jan 24 17:13:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08332 for ; Mon, 24 Jan 2005 17:13:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCji-0001aW-A4 for rtg-dir-archive@ietf.org; Mon, 24 Jan 2005 17:31:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCIf-00027q-V0; Mon, 24 Jan 2005 17:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCDW-0006yb-HI for rtg-dir@megatron.ietf.org; Mon, 24 Jan 2005 16:57:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06215 for ; Mon, 24 Jan 2005 16:57:47 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCU4-0000kq-Kt for rtg-dir@ietf.org; Mon, 24 Jan 2005 17:14:59 -0500 Received: from pool-129-44-176-136.bos.east.verizon.net ([129.44.176.136]) by mx2.foretec.com with smtp (Exim 4.24) id 1CtCDS-0002Ls-4i for rtg-dir@ietf.org; Mon, 24 Jan 2005 16:57:46 -0500 FCC: mailbox://ygwmcvydlz@yahoo.com/Sent X-Identity-Key: id1 Date: Tue, 25 Jan 2005 00:57:41 +0300 From: Delbert Valentine X-Accept-Language: en-us, en MIME-Version: 1.0 To: rtg-dir@ietf.org Content-Type: multipart/related; boundary="------------080101090009040607000009" Message-Id: X-Spam-Score: 4.9 (++++) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Subject: re[5] X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 This is a multi-part message in MIME format. --------------080101090009040607000009 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Windows Me XFL Cheerleaders Survivor Baseball

Sterling Marlin fine

--------------080101090009040607000009 Content-Type: image/gif; name="convene.GIF" Content-ID: Content-Disposition: inline; filename="convene.GIF" Content-Transfer-Encoding: base64 R0lGODlhjQLtAfBcAAcHAP///yH5BAQAABAALAAAAAB/AuMBAAL/jI+py+0Po5y02ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qDQDA9gsOi8dkRbdbTqvX7Pbu fHbL5/S6vQKH3/f8vj+cl/c3SFhoOBQYeLjI2OiIkpj4OElZadkQGXm5ydk5qMml6DlKWkoGeiBpusra +oSKoAom6yAaI5hii6cXgCuT+cqb4ZtDPCz8SZugnMVs5rxiTAI7gSvtkonGdC1BbcO9G0fovazbbP5M rgL+kW1hjQyTra3E/gBcHI9hP6dezh8MXax56cSl4mUQnsGCXnrRG6gPIj6JDx2KMyZQDzGB/wfdUWz4 z4tCbSAtLvwYjmTFjg2vCUu4kKM5XwjZAWzjj+FKKhpPUgwVExZBky1rXvQIlCPRpCWJBj0KU9nQiQyZ ssToUZBKqf5GOjO68yU9sFhp0dwqM2KdnAugRem50+rSq2fdeZU7DyTSkEWfyrrLtC6+vT/nOhWbVdVe wlcDoyPbNipLx35tjTwc8aYatgzcBhTps7FhwHdJQ54LmK9c1KdNQ0UL+nVTvK1ry47jGnZk2asnG5bY cXLuvrot0g6rVg5nTEqdwJ0tWjDx6VaHHy/u8jRr3tuxQ05d2Hr36bhtF1c9HgI3o0mvU09vfndcN8tr Nd9Wfr5N89TF+//PrN1/3FkHXnT8uReYgQMCuGBoKMm31IHpYaYXWPJBR59nDql3XxJaOfibTqKUJuFw XyU3oYkjfjcUel4pJiFlZJ3Y4Hy9hRThbSsmpkuHmonBFoqOTYEYhh8WCQqJNb73YkYoCggbjLzldaF7 UnpX2ZXkiNcZOM/FRt6Og5nl2Y+zlJmThkcU2WV+UY05ZYn80WgjlGES2GJ4M4rJJDJUUhgal1Uyh0ah YMqoY5NNpWljGoxSJeJbb7ZpKJKE6mYnghGklmmIerqJYVUTDgqel0IqeJ5O9hm6oXaiXhhPV42e4lZe dXZIRJ6fjiUnqJp26qKlKfaKqauo9rlkb8D/7vreoJe2euiwyQaaVqhlyGqrtWoiwpim0hab7LfNMnvs r8SCOW654nq7rqftqrrql1jO219c1fYDTbZKbQuEraQKi2e4y6rbrp2SFGjuklqSOyrD653qVMQJ02tS e+4al2G1+j5s5ht/BvsmsuBSXDCD53XKqV3GTtzsVH6e+y936HEor7oCWtwxrU5urA6/PUgHq2Uwoxzj R0ILXPSXDdPFp7K+/jYwy87eI2zJNVbsbs5E0snzlrj+XDVfPU6kJJwkA3rpTGQHCCnI+bbYLcGIGu2g oIiGCjTTWVYN6s6znvNY1/5GikTesGKst8M8no1ZvNJQVSqZMmNLjVBF/1MmIt6XA6p5yGKvZLlkFFJq rRbeCK5v0IWHXZVPak/+tN247ltWqhLr/fKTbd9+d7oJHp42u3cHfyPvD4qG9cXFnxk46ql/7godcWOz e/SLVO5814Rbj9PX0XjPPR/YZy849OGfj771oZOPuvnpvw8/J+Oz377R8d+PfyNB0j+46vn/D8A9MAp3 5OsG+AKIwARWYX+LYt8FfKbAyJjgbxwqAQU9cMEuqS+DHvNRRei3jwO+4IOlYwMHd9GBE1ajhCBQ4UAk uCYWzsCFOFjOSUAYQq19rxzSKwkNNwWdW73QgPYZ4jpkeBAjsuCH+FlCfW7owGPoMBcN7KESRYCcIv8m kYjMueIJOPgQJobwWkjsoGagWEANQLAFJIRIKJbhm2fAMXkbeuOz6pgKi0HrX4ijI6+CoxKMZecofRSk yYrSRyG9DHGsigUfYfLGp+BxN6tZJCSDEskwNlKOjvRjhSiVST1Cqy80SyEEK7NCiFFtihOsIhfsOJYt 2ksvsPykHWEYyFfWcStaBEotb/nHXfJSmL00ZB6J2cXgIFM/iPTlMmmpQWXmkpDC1BwPZVmhZlKzmr8s pBG1actJXpORzTRkOdtyyxyaaW/IqR4F1nhEZuSyF8A0Ei01Wc9oIpOewWwUPkOJzST+s5/a8mE4A5rM fAaTk9185jFhmM99blL/nFdc6D73iNA//hOioBmiRcdp0Xl+VJ8PhCc75VWfVapyia5kzTHflseBHtR+ eETXPEmqUYMqVKc1PSdDe2qgYub0YR61pUgTClSJdnSLOD3oTSc6zU9ulKFLbSgzmSpTrBYURDTL2Um1 Z0pWYtGVIhUJU6lGz0mWlaQv9Gk6IQrUrALUqm5VIkEbCtecArGoCG2VUI1aTqiWbqFynatDDSvEc65V nyEN7Ez5WlIROrN3zwvrSql4zbU+VoOKdSxbBfrW0I4zrjzVa19v+tO7XjS1UmVhYTX714y21oucbGw6 BUtXtRY0ra+1ZkRzK1q8plKHX+VZCyU7DbJ2drSx/00qiGbpRX/y9LDcrK5qmyrb4N4WsHtN6kWl+01w yraET3UsOD3rXFI2l6C+1e1vR9rX4V42HQQEazuQO1aQbhJ0usORG2+FST2V0rux2m8jCctM9BpnmJQk sO42Wt4BqxbBVS2IG0VZKYH2FpCDbSAJK6xf/753q2mVL1eBmE0cHlesHrKDGL9QxhC8+KdnVeNgdSbW RKXxvixe01pivBl5AJmLzB3jPcaQ0l7yr8c0hfGQFzjfzTxZnVOuII3feaoZFyHJtaDbjlcc5QiKecxf hCeKl6xl93UPs3C1xImxTAMwVrnG4zCzAdE8Z8elOQhChIQ95ZfnIlMPhVcuJv+U32ziPX8uisllcpzn rOg20xmpkXZOoGm73RHI2ZSzwKCdE83oRofZYxuotKApSulLb03G7UU1Bzb9alULIdBcpnKoLYhfGy/1 wGhcXj2HimINGxTEwsbRkXhlWh66DrWziaUuJ+tN+t4Ra84uMVV9JRgNQ1vZ/AX2LyWZxU4u8tt/7nUm 1SvKZ0vR0XrO3vfYbWWonFa4tT2vdnU5zKjaE724HS+hbmtVXEKTt3U1w73vetRoBnKq+p70heVKzXzb m6PArW6bgFlL9UYV06B+t4qpCO9Uj7jeaMXnVJOZbFebfLZajS9rSa7uthZK4HBGOXdxU8SUIzjT6+Vu N3X//udXbtjVLc9sOA3s8I57/NZ+DnlezQuwDrv35MHStsNX/qHwwqO5Lo15sYcN35kJfOs47+LBpguj U/M87T9neXBjOXTw/nqxo3xJqT9ta3ezMdcrhCyqN55znVI9u4gNumF5/vfdEt6vnOVnfPsM+SCa1axm bzbaJV/otWO+7VbX7szdm160ct7Bide101X65aWb+qx0hyx4V85xwGP07YK3fHglbVfxRvLf5HzrVYm+ WmdydaKID/epC3t7pYJegssNvZJ1v3PjvwPvptf7CPne3W1SVPYKn3jkI8rgf/wW8dsnsfPv/V2f/r7P pQf+ahlu+8xrn7+Lb7jI01vw/6LL/rqWHTWP63cL2FdKzIYYFndt3rYqs4dsKhcbIKNMXcdZH+Zd3Sd+ ldJhxMZ6YoF+yMZgnqNbV7Vs27R/2QR8H+ZhwRdivoR0c5d/7SZr62Zcj3Z6mcdq4gNkL0hmmOAo1Adm lSWD/ldzfmaD75CDuUBGAvh/2ZIPTjeDD3gHsFaEuIZjQChq/XMDPBiFWZg+tQZySqgDWOhp6EcJq6eF PYSErLYxPACGy2dtMEcKe0aGZehEa1iFTXh3jsZwWhSHVgBdSWdkcvhjZ1hmODhW8EZYoreHUIZdxwWI T0iHOxhyJLFLwEFvo0SJNfVQNUYcyWdhD5hhF8eBN0J2mv/kbZDUiC72iEgmiB41iaPXTq4YWBSnfKIF OhlHixqne6wFfbiYi6dohnYodneYiEyDa5O3az5nfP2WYYZXYa13cAqWgec3WslGd6jli8qRil6GaGdm h9nYVox3GJUIdOfWhlgFeiPVTs44dSuyiHUngj53jYHIbjGog6g3PTAYhzP3ee2XjM2ISJNndppHZ/Q3 i7nXfi93eCPnfvEIiT1WPryXNlZYfXsoOvy4ebNnXSAokKFFkOoIe/J3eQfJfwyJL/jFdL7GOffIjcP4 UR15kdxnjdPIb9JHXeGmfbSXfAQ5gSTpiCLEP8CTOQ+ZaCw1kDVxi1rVRu5nghW4byT/uIL0xYEkKG0U Vo0tyJNS9jV4ZnhBY332SIhEMmtfeZWlwBla+YpceZJNJj58JpZjSZZvY5ZnGZRpGY5+MIzTt41uCUBe E5cmaHl96T96KZhidjp96ZeLhmdqNpiLiUDzA5h0oY0/qZaMSZl7KTmGGSb1JZlDUpmdGUDr85hJgpmT 6ZmlGT+ogJl9Y4FxSZqm6ZpbeJmpKZu5Q4WvaZuXAJqzKZvEeJu9+T6oqZu6yZu+SZznA5zBOZqcWZxy mJeN+RfI+Zh1eYWm0oXddpdOGEd+yGMQgpKtJHlRglR1KJVc+ZnPCZ2JqZzT2YCd6J2JFJOD+Jce1pbp Rm3v6Z3x/6mC6TiIwpdgF5Y/x3meKuaNd7htdNRo/DmfXcWe9FmI+NmcmhaCvLigEOqU/emf+AOgAeo8 w7mE2/aJxYigM4RGWAefqvGgDeqAhfShFMphnSN+lnk0GiqUAxpr6EaO7WlOnXOi3FgYN1qMpGiBEUmh QCqhMteWkuEmF1qgp2meMpqG6fmFK2qALOoXE9qgYAdY87kRFiJiVfgpKmqjhdiiHxqCzhmjTvoxNNp/ 8RdtSRifw9Z0CLiAP9paKQan8Fmnv6N1IJqjk1WmZiodaJqh1xlZnoSdaGig9ZmglsioPXWk6yml7CGE hCRv49amazqeFXmo/6klgnqmhFqovf+npCu2pHCBWZRKgGL5iVJaMTs6fcYkb6K6qWHVYOT0lxEkmp76 qYtKqwg6oJraomymEHOTXMdBSa5KaMNqq8QqptK2rC+qQLmqq1EJqjnEYbWKqKXKqhBqrHJZg9txrBSJ LH5KfEtao7UKrMi6QbsqoxzaLwvoraSqrWHKreAar/dlrFOZj+O6rPfaq9CartXKCIOqoe76rriIrfL6 jikmhiXlieV6qXf3sFU1KQvpsORapP56rs6qqeoaPgQLnQZ7sEZ5cVdKpG9arKQDkYxYss1TaRbKdgn7 r/4ZMh6LPiArnFC6nDurhTibmiLLs0Gbgz4bnWoqtEf7hk26mzr/i7RNS5hKa5hA67RTC6hIwppMS7VZ W57sumRSq7Vfi6FQu5nSCbZlu7WBGmpGa7Zrqz+x2ZVqy7Zxewi5KZRkK7d3Cz90+6RYi7d9yz16a4Vw 67eD2weAuxirSLiJO7duSxiCq7iPK48FpiuOC7mVi42v45gCa7mbe4S147may7mhCyRc8bm8KrqnuwaO qZioy7qApjbb07qx67r2QLmya7tORjvAeLu7CwhcA7q8C7xSkLmmG7zFiwUEa7zJ+wh7q7zNu7gf47zR WwjQK73V+wcqab3ZW5K6q73d2wSI673huzW/K77l+wPka77pq77ry77t677vC7/xm7S3ypQu/7qykWWz nlZl+Su/ejmiJxgToyrASiei+4u+/ZtAqDSrpHifDLp3Bky8CJyFCjyvA6y/FvxuuibBQoukc9o3vvpw aBEOJfusDiy5F/o6Gxy0HSyVH4w2vgo+dTOnOUqbBQhtoaPCK8xLsWpOlyipbBJsCWWKPSxNHszAE5vD PJsfwRqi2Bmr5qZSCXgkNxx+OgKtMpvEt7nE+dnCR1zEYfpmisQqq2o2fOKX35nFy7nFC2bEd/rFHipd fzPGFFvGTZI5c5TGxfm5b+zEEneC01ZyHTXDzmphMuwneazGknvEkhTCYAxg8jUaiyzJm4XBiGybntvI SvrEEkjCZ5adPP9MxCXMyBFryZVpMo0cfkQMxYh5gX08NkdDs5JTyr15yhPryEW6wO6Esdw5oaNsPPw7 y8EszMNMzMVszMeMzMmszMvMzM3szM8MzdEszdNMzdW8tn9ao6aGrLqMo/JKyta8vKucdx80sykBvgPm zcAMzvJ4xfg7NuWMZdycK4O8zriZOwTqG/m7zZz8vfRcz5UAyz2agP+lrK4MqfzczhEKSqD8rGucqO0B rP88hgZmp2I8S5JqyzvSzq5MN9oIx12sKB5trhLdtgedqbPSPJo8wzZ8qXkCyhULxa/xoqPM0iQ90d6H 0KTTsZwc0/5MQCicygwtOqss1D5t0wO7w0H/TUEB/dFNTa4uOJdO3dO3LCUAe8BH3c95CqYxhtFb7dRc PNBbXdWZHMtUrdEojNUATa1fTchNLNUI7dAc68sJrdQgvdEcnYlpXdJfasG0ScV/LM4QC9RuHMpuvcte zcezqtd7jTwRzco2CsS2Kp+tPNh/nc8VW9iGjdnqvNiqKJ+445Ue+MKj3Z2IjTk/zawM3Tio/c2dLUDd Fox6tqBTDBzYfL9ivdBE2tAX3ZQl7NqJHMF3/dvKy9l4OdzSy72dfNzJW5sbu9zPDd3RLd3TTd3Vbd3X jd0HaqUMWmCrhMWp9BPbeGJ5WdzZXWeTzU7HM97WqcEJIt5xDN7mva6A/z3JfifHOe3cxh3W6Czfq/DK ZP3UO6ncnL3PlB3E/W0KspzYomqfdP3ZBE1KY62nbAzbl6jYCG7P62nZ7omMSLTTu8rFGO2zZb2lwY3h SOaEjEzTWRffHI6xf+zi4iTTG17Y5X3iPVnZMY4zZVSRKl7hOs7XSKzjNn7jgZjjc11UKL2iPCLXhJ2r Vn0nRl3km+DLLw2CtLvkcNLkJG7Yuy0UU+7fXlzjF42CEN7XP+7jdzrVI+11YO66Ry7mrkdeJ7zgh63Z db3gRO7mqEjfar5+VukpPIzNaX7ZgzzUcb7nGb5oHc1RgP445rnlGb0nK/7fid4J1MLbzwcxzyXOvv9d pRSeqCPa1pb+tF1K6qeO6qmu6qvO6q3u6q8O67Eu67NO67Vu67eO67mu67vO673u678O7MEu7MNO7MVu 7MeO7Mmu7MvO7M3u7M8O7dEu7dNO7dVOlKlr4o9mBFdtsdrZSkFoz1h5diaU7eFZr/OcsoRGZHh5ohl0 lzoJBffd3GrYUjs4uu/KcTSIr333h1DYXUck3IYWpf/e7Wr3qizr7aZT7r+w8Ot+QfsK7uru71YWT5WM ezXkWtMV8Tb2rcVm4Z9+Z52nSrzGzypUHnFEph2O2yEfigQNUH594UFlbgCxcEtZkCfvwNc22P9o845a e2y+skR9MpdEr2EdqYL/zVwt72WfTMct46o8rfJ+d2QG2OAPi3FlroeAF3EdPpPZN4JurfWAnnuxiPX1 Bo2zKHEN+1TC9Y6waPX7MIlhxPalhW5gZIv4R/DUxYZl5UN4VfVsdV0R1rBSH3YpWH6DH42B3/Xnp+Qy 93gKtoLuHpJGx+8jqXwfabFEpZOLpYwajwdxv3lJKY0uxPmeD/j+6HtOVXBVebH6JzReK2Cwz4JRifiZ FrOlD34eZKQkS1fHNsQU72A3mfUud/m1R/OdhfM5yY7IV/BwJIm6XXzsmO+iwn/3zW1SP4GpyvdhJvr2 +fcwN3iiZ5G1v46NnvvnD+4QO3SxJ0MQtouVD4+n/4X6JzRhxGb5GGmNJr971X90F5nwBBAgDDXZ8zQ5 H0SxYZxX1d35OIosR2kTzWgzKbVtXbSTrbua8dt+1HCRCoJ0ngtxBzzRXL0XSIj76X5Tae3IdDax15xv SGJBw8/iZFhWMsFi5NftlSdX5KQ1eoqV8+eSrG/LioqPaOvPDq2Qrs5CbQkmEvKNy5ER6NFGkFKRbW2w sY0usvCxKE/Ss09PrQdUjDWWbc+sdiZV9IDTMzfxrjVx6vDUsItD15EMmThLU3d3KRmr2ZQrS3pH6LpK efgYbNkS7/n4w/tbVGH7nJuG+1odnP1ZGRPY/d1X3Zgq7ntszzRh4QhRi4ZsHv85Rc7MleMVryE2PxMp VrR4ESMKi+cydvR46WNIkSNJljTZ5GRKlStZtnT58iQ0RDBpRqt5E2fOlTJ19vT5E2jQkvSEkiRaFGlS pUuZNnX6FGpUqVOpVrV69SPHplqrEpzpjyXXimKRkt3IE+tLszF3OVmr8y1NekTjluW36WtYtBfr+uxL TOlftXvZggQpGCbiwZ3ShiKUdydPs2QVd6wM2bDQyxg3821LqbPK0CkBEZ7K0a1pzpJVw7nVurBeW0xH U6w98VBqqAgFLlRirps7z50IKgTkpgtwsBCSjRjT3EiY4sERJS8NT/i+e/968wDoat317t7FTbPm/HqO o8//LXmvh4/883BH49WxDr36pGK58aBb056B6RwqKqJ26ptvkf/O8u2TVmDBRBbGDJADwUkycC8bY1y5 Yjuv1PMFlVSWYQ+5CEvLUMNXLoSwFyQC0ojFQdLDMB3XVoxIQRhxiRCNOWqg8McYU8ysJlpCnOUueFQE TBUlHQwlkDdS6KVJmwIMZruvjrTyRAuNoJK8vLY8KMscoRySS32Q5PELI7F86Ewv4/wQzjWZY0zGTKTj 5yc313tTmu8qHK7KuZ5cKB8PfdBuIDnpAtRQ5AykZTZKFRS0HbwCNYXSVVZ5YkQ0GbFUoijhdNNOK/EB hj5EyyS1nEP/RLHRK1v1yw7w/1J1xjHbikFvJikTtFGLSyzdksQGX/NRTzFBbFbXMMGKlswMedHtv1qv hZTPT7/s1EXQhvVmR0/DtRZNEZu9cilUKy0zs8l+lZY4fwxctpovrf2N22WzXdfeZ3+BIwpNCZ6X2Yei nVRNfYG0KU8tAJXQTm9rGWdgPJOTRd2Mk7WrvYW1VXWOx6p0DduRe+XV0UVClTPgfVmMmZUUqymYE1hH eTUNijlOEsBqf4aYz2/vrbNcaHYEU+NtH26ww3P7JLFV3nZGMFSLMYtSwPw+vlVh4wRGcZ/6flHUanOx w89sq7mLdV+09wtovA/Dy1m+bj8OeT92OZx7YIAYVKjEr/8J9429w8v2uui0WWW3a+2IfOo2l2BrDPPM Nfeo8s09N6nzli7/nPTSSw/d9NT9APsq1FV/HXa4Ro+d9tptvx333HXfffXZKSPMddpmrzM2zxVNK3je sxq+SEP3JjZVf89IPjDmJxeJ+kpWa935tVPvPLTsl/d5LKkznt763fDGPn2TM0KdP8y7pNz67OPqi/r5 CXWaZMxUN5hz7ZPe9hbTK+6Rr131EyBuRoe/BaKPOFzT0hF487IB2cI6gMvGjShoH0R90G/kYJ3gshM0 iYWLbugR14oGRELWlSdu3Rkh1nKFsDsprkI4YpIK4WOfDPKwh+4RWyxyOJceSSpoj5P/nAkRxzOGaENp b5nR0prmMKbNIjvIepIFyXe0tu3Jg4syUxb7JSR7Nc2C8TtQuoY1LSVi0Ecc6p8B05gvqMmRaYOKYYIC McENlsyKActSxNikI9jMj4oV04cXeSChWgkOaLO5osyeJ7NC8g9nJhLWhApVw5VFbZJVBKQqalSy3znS SctJ1iqxM7Ix4WJKGNwYm3SGSVGxLJCS7B0qLVlFUgFHbuZ7ZAcj+a5ZofJRjoFi0Wz5qGMeDIUi9CRk GMYoO5rymlOKVKlsuEN0GfFdRpNY9I4FynQIiz5eMRcCPWYzxdUoNcdzXwyJl7ToVQdhw5zQBWDGS116 y2D2VOXN/zZpLHWaz28DpSe1aDbKYh1slFxBpPfC6S56ufKWbWSB//zjMFxSrJray+UYvTlJkZ2PpOP0 Erh61ktRnoqZAW0jRAtJLV3pzKLhpBJDLzaxOOQrkVqZKPTECSyjYvNkWnyoLpkDK1AwNKTKbFhKB2jS gmJ0jv9aqU+15lI6EU2qgAQPwNKkKpXVUXt1nCmxXhlFmDp0SV+lKpBKQU+UFoiN7BxVP5+6wjUCSI0O nSsd2Zgy8/BtVW60JA4BNta5UUc8LfUnRCi4Qg+lc4gGJZPj3lM48ySqo9uqZdiwltDFQW+oEkEijWwF wqu9LY9dxcZ7lIOOdwpHG9EZ6wU9q/88377OgbuBHU8J9FvjHld5waXccAsaGOQ+F7q0U+5WHggypgJF fNHV7na5213vxq4yxLUM8Hx3ze+SbB4EJGB2g0Ku6souMtIVoHjfR97xXk+kuzOsARl4X6KCVybsHcpe TvnfAOIkvM0NiUTLi1/9BtivVe1vfR08vqS4V33UfG+FFzQ1oyjYwhCksIEfPE/i6dXE5eOwf62bX+Fp OL6i2fCE2UbZEtr0oDirIXXOhjdRnTaWnBRBjqHpWheKB59knM4PNclk3roNVHUbyIugWMLE1hhUf+Qk YMODMqoRechp4LHZSrREuLX2gmHuLThA+GVB0eqE7NMkYOE6rrr/sllZdj0iLPkYJLzW7J935iIhMWZI xD7NtnklM1hjS1dEK9RGYBSjkCWrQ0BrdY2Kjutaz/Y0S1+akB1V89AOfeArsuym07zoPcDlVVK3GiFz zqX+vizrrbJTnzlq66xt2LFVh/JkRAozP3sqNKeNCdMJjeslPZpKkrZarsZmpb5kO+FtlpOLKv01tE1L itseU5+xTthIf+lse+SYcE7NLKLLuSleg7TPyVRhuteH0itD8t56qyg4uR2pbbJ13fCeN1ohvU54y/vX pVyvgn0dQW13m9VlnJNAN0psTI92naYCeFhJ/WiNf/Sj1F5rTnGt72IHaJ8dx6mqbVlWjuZZ/6emZTa3 Fb7yhzOSUFDt809ZPu02QHsYvmYpl/UcaWhFMrANhfnSL47QkAOdoA9nqsF9iSM+v/WoLR/VZ2iGrW8q Xes1bVhOcd5hmhL8pGAatKIVrsii57pFHL+XbDUFdXPaGtU8jWres8lwO0Z16Z82Y0/Japi0ez2UKvpz sHcm8GQvO79Vc7PM4RxEElIycmbG7TqCiFR47o2xGtctOmvLZYN0rfRqy208payn0i4Ty/65LWzHYZDN M+7MMLQb7E+bZcGv/cxLclvpofPEllb51omZMYptJ+DzlpS7zn9+8+Sy/AxPn7rPlz729SJP0lg/gd7n fk5eiNzyjx/96f9X//rZ3/6Xm0xeEOZdZ7afYvW6X/nL0f/+P1ebX3o551QDNcDP1D6seE4MvhaMAC/s gSqHvrKKxBCswWTsWhxPxSLwMKZKvaSoATWQ/+wt+xSwdhzQ+h6QXphPfkBsxCbN2HxlxRBPMarNxUQQ AvtntKpHzuRLdEpQBR3u/TTHBF1wn4JAiPbkM37MtXqPm8hs9vjGeSyPmNbtcC4v3xYta4yPtXKL5zQo yA7LDIgstICo84Csg3AvzcoQPyYP3NBQ92Zw0lqvyfjlsbYwCRlkp6jBk7TwyUCP3gpsG7Dp7x6NnCLs r55t3H5G0titr8iIgwyPtjgt0Yhoi47wj4T/D+5IQbO+CI/UBQoSDvgWjf+q4BA5sdQc8e7C5tIKURPb JN4KzjRiLXEay63GqN0gTdlmkeoypefg5Xzy7pM6TrHu0OICyxd/sdFqbmJ0ceZa6RQxjA7X5Uj6rZuO jZnkCqtEjpdqieogqBl4RGvW0BZhMINm75noBvjIjhebLfjqTc9kyt1aywO5pqtYSmzK0enE7Bz5bQ6l EQSvC9+w0Qv48cT8hBzHptx6sRugjKZGqhK60fPOjtNqMeYqye36MZOyDudqMZEQsh+BreK2LAOBURwz cbKEBscWkl92pfA+8COhcUgE0gZZTqSQjeYksgVhRixK6yEPD6jGZiIp/6rqbvLrMDIdNRIS1THakm9w Qs6u9MckexCgfMpCdM4Tf8wZs0wVmw4gk5Iad+nUuGpeQK65bpDjdvKqIFFlpM28YM4pf07iLMYoBQsp 2/KczjIU2c6gVpIVzarShCnqJFElQY0QX4phWrGUNiEdu27KFiufpEZu7knEmi0xHccUpzESaUVcuowJ pfD44DADBykWM7Mpj0f1rJI0kwQPLQsL1xG9WOkTlyg9jowxOe8DdQ3MHoeRHhPdSO/2jGaRxMxVYAsr lRD/irP96m+HFnAEldM4m9M57S8EQbI4kfM5qxP9zo9AmnA6mdM6u9M7vxM8JZDFcjAy98cAwxM90/8T d4KwBoWwPM3uPNVTPucTCD3wPUMM+twzPumTP/vzNOwzP8cTOr1ywPzTQA8UdJBsDGETDfXw4DQIzVir 95AvyeTBDtlGIdUjDSvriC409HYMQUPUuIrRTF6E6fxJi5To6p4tLHmRFB3J0bQMFWNrLUXURv+nMV0q LjeuqKqSKKWFuHxuqGyuqUyThfjHR1fsRpc0BVcFmMTS1k5u25KRGYswSKu0xxQSlyor24KsJIW0GplU TE0HLmfx7fwKHbcSTImKVw5y65CG2PTO4pRuTZV0TO+UKhYx8pAw7aY0MGFN/nyw8faSLylN/zaqIXfR 1fCUUZuUJMORU8bSnF7/c0WvUhCRkYlAkClPbtfkslE/lX4i68qWEhEJ8UPFsC6xDTFZZczMLEOJJtsq cwynEAlB1Vb5kzqF61Z3lVcFVPt6FViDlUCnL1eF1ViPFVmTVVmXlVmb1VmfFVqjVVqnlVqr1VqvFVuz VVu3lVu71Vu/9Tux8zWKVXQCSDC0E1zTFVf+zVfI9fsc6FzFT13ntXm65yzclS3gVYHwlV61tQ+D4wqV 8FakCUJpFd1aqIIYxYd2E4n+lYYQll/79VpPdVO4FLP+7Qnt0GEftvi6B5yibMkkL2Pt1fSAU2JP9iYo 1poqdpk2ljddlkLrcWSDCWYT0plm9jt4C2V3tvsK//ZfIVaGmpBg8ZFBke9PBtAci7Y3frZsmJZnn1bG FHRCOdZjTdaDZBZos7ZirYHHsDb2LpYMuRNq51VlDTZoSRZdE3ZDUy9gY0WezFZrw/Zj1bY9x9Zu29Vn U6hjV3Vcv8hoqfayPjYJmZZw25ayxPZuT9Zpp/Zv2xZdFXa2vPZofSwzE1JpHWJxBfdxE5dzmSFja8xj 3ZZjufaxapZtic9JRdccb5ZdB1ZeOxd2SVdlWVYgLhbCAtd1cdZmV3V1S1dmNXd2Y1d4GYhmo0xgg7dC g9N4vdZtx1VUl/dhg3dzh5d68zRiU/Z6q1d7y0dcm09wtxd8U3B6l3N8w9d8qf/rdW+ne8+XfdvXfd8X fuNXfueXfuvXfu8Xf/NXf/eXf/vXf/8XgANYdi5j+Zj3Dxb0P/0vfZNXgP2zfJ23Z2OPcRFXARX4fha4 gbvzgbk2gokTQzGYAS24gUA4g5/TaTdWdJ2X9EL2a/UxZ0GWg+G2OYbWhGhYeTH3iTw4dy33DOumhM/r hK/wd3nXbG23hScXeNnVSYMYU0iWdlW3dnG3dT8XZiO3grL3h7FrdG14aN+WikN3cb7Nhb9YiaH4dC0W jK1piGmIZjGWjPHxZ282i7GPiTl0tfDJZAsXdffQcUc33844jA03jgHXixv3bLn0cuV4jrVvi69YhhlY hff/tnKh8ElnyJBxuLbqWI0N947XGGv1+PRIeJEfLGaF2I+NV3b7mPUoGY4t+ZAxOY8buYkNGJUDGW2v uIcdmYJHGX3HI3PHmIN9SJIl+JFpWZiHeYZV2ZdxGZKNjJM/qI4xhZejS5M1L24lJZYv2YMnGGitlpUl 2Y6Zd5CVOZhtOZMd2VUdFoGnmXyn2F4lt/ycuGqRGWSttmaT15OZWZzl+Y1TOWSNeJOdWWrZOXec+InV uHnxuIgnl5gZem2/N5fN2Jwfem77eWFFtqJbNpp0doMJuv8K8oUhN/fwuGHJmaTl9oY7mYW5WJCZeVQl OJkdC0KtuYYH2qNvGqdzWqd3/5qne9qnfxqog1qoh5qoi9qojxqpk1qpl5qpm9qpnxqqo1qqPZeHzTWb lWadK3iXa3l1phpPH9mq6XlwRbl36m98O9qr1dOY6+ucV1lnP8ysFxit0xo90/ilx/mqsVk53smd7Vhu XzZrTvqY33FlR7ppsZiureJzl9ie126PC9uu+Vl3VctV7Dqg8Vl3TZmNyTqxGRmib5lCe0iMkXiMry10 u/iiI3ux2+y0S9tlO9s7Pxu1F/eaO8+hQRk4DRqV9zm0RZuQlxmYYBs8R3tpT1msbdu4uanKVnu3W1q3 31q5o9ihhTu2izemffi4+bj1THu5mdu3z7iMP5i7pXutqf+7OYkblqG7vIv5tx96kymXns+6vVG6mc37 vNtYcn53tUC6a527sd9MaE36cvd7vgdchmnbvreLv0nblRuat1v5wc15kicaio95niFXsiEruRMcugIc oyGawuvZvQ8ar6Gbwhe6kMn7SVlWu0ecw6PP+8DGhlmbd138sAFZnZt7j7ETbnOcsrmZvl9cyIecyIvc yI8cyZNcyZecyZvcyZ8cyqNcyqecyqvcyq8cy7Ncy7ecy7vcy78czMNczMeczMvczM8czdNczdeczdvc zd8czuNczueczuvczu8cz/Ncz/ecz/vcz/8c0ANd0Aed0Avd0A8d0XlWruOZx9d3iVP/G9LLOsbPD8St LNHrM329+7kvG33Ce9MLm6qJ25UX/NKNp3st+8LNGC1SnXZXGGlXm9XfW8RLvTE+/Y95L503/IZtt3Yr OyFwndfXUbMRm9brWV6ROPeC/cexOdl9fGsLAth9HNk5vdjR19jdS4ibnY0Nm9lVS9lVl6q1Pdqzndqr PfwuGtqJ1tul/XG//dsP99d7fd233Zor3dw1gz+OXb/nHdfxVt5znco2193Zndxf+t5DmHS5l94BHpHD nd//Hd5ZY+HfvbJh+ODPfWEVvqp5PbwtXvNYHbXTXdwhPqW5/eIHGNUfOInH3bK7vd5hPbhF/uFNXqQN /uRRXrcd/z1QRnXg9X3h3/sRX7fn+z11Pf7me6Jqnzfnd/jflf2dk37kwbnCh57kd97lj7698r2Sn5fn CX7rIdzr+3Kz0Xnml52maR7ryU/rwb7ou37i8xluqL7VZ7nhGZ7b7V3n0777Ep7aRz3qo5vR337YWTfk 7X7ZKX2u9X7AjvDVZfrvz37Xw37uo0jwid7eIV/x65XvZd7j5T6Sy15pbR30Kb7ROTvzq0/oX8jzMf/x nR7qN3/1a/7qTz/84j3jR1/gK7/qzb7zJR/tf5/2tdjnYX7pRZ+xdxPvpzfWQb7lWT/4p2b4y3jTjd/X ZTrwhUrTiT/7Tf/5e/Z2t9/DN/jyOyEe+H090o/f8btf/def/dvf/d8f/uNf/uef/uvf/qW6AAAAIf5w aHFnaHVtZWF5bG5sZmR4ZmlyY3ZzY3hnZ2J3a2ZucWR1eHdmbmZvenZzcnRranByZXBnZ3hycG5ydnlz bm5xeGFyZ2Z4dnVxam95cnZldXFubmFtZWV4YmFlYmNpc3ZtbWgAO2== --------------080101090009040607000009-- From rtg-dir-bounces@ietf.org Mon Jan 31 07:19:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20473 for ; Mon, 31 Jan 2005 07:19:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvaoJ-0001NL-SF for rtg-dir-archive@ietf.org; Mon, 31 Jan 2005 07:37:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvaVO-0005vk-LF; Mon, 31 Jan 2005 07:18:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvaRX-0005K0-EC for rtg-dir@megatron.ietf.org; Mon, 31 Jan 2005 07:14:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19951 for ; Mon, 31 Jan 2005 07:14:08 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvajR-0001FH-SU for rtg-dir@ietf.org; Mon, 31 Jan 2005 07:32:44 -0500 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-blue.research.att.com (Postfix) with ESMTP id 255F81974DD for ; Mon, 31 Jan 2005 06:57:57 -0500 (EST) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j0VC01mm010274 for ; Mon, 31 Jan 2005 04:00:02 -0800 (PST) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j0VC01qG010273 for rtg-dir@ietf.org; Mon, 31 Jan 2005 04:00:01 -0800 (PST) (envelope-from fenner) Date: Mon, 31 Jan 2005 04:00:01 -0800 (PST) Message-Id: <200501311200.j0VC01qG010273@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Subject: IESG agenda for 2005-02-03 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-02-03). Updated 2:31:9 EDT, January 31, 2005 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date OPS Jan 27 COPS Over TLS (Proposed Standard) - 1 of 5 draft-ietf-rap-cops-tls-10.txt [Open Web Ballot] Note: IESG: This document is in IETF Last Call, but the I (Bert) wants to get    IESG review comments at Feb 3 telechat, so I can try and finsih this    before I go absent for a while. IESG: Pls also note that I already have a set of RFC-Editor notes that need    to be applied to the document. Token: Bert Wijnen TSV IP Performance Metrics (IPPM) metrics registry (BCP) - 2 of 5 draft-ietf-ippm-metrics-registry-08.txt [Open Web Ballot] Token: Allison Mankin Data Over Cable System Interface Specification OPS Jan 27 Quality of Service Management Information Base (DOCSIS-QOS MIB) (Proposed Standard) - 3 of 5 draft-ietf-ipcdn-qos-mib-11.txt [Open Web Ballot] Token: Bert Wijnen OPS Jan 27 Two-Document ballot: [Open Web Ballot] - 4 of 5 Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding (Proposed Standard) - 4 of 5 draft-ietf-adslmib-vdsl-ext-mcm-06.txt Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding (Proposed Standard) draft-ietf-adslmib-vdsl-ext-scm-08.txt Token: Bert Wijnen OPS The Network Access Identifier (Proposed Standard) - 5 of 5 draft-ietf-radext-rfc2486bis-03.txt [Open Web Ballot] Token: David Kessens 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item Area Date SEC Randomness Requirements for Security (BCP) - 1 of 2 draft-eastlake-randomness2-10.txt [Open Web Ballot] Token: Russ Housley GEN Structure of the IETF Administrative Support Activity (IASA) (BCP) - 2 of 2 draft-ietf-iasa-bcp-05.txt [Open Web Ballot] Note: This document is still under discussion on the IETF list. A (hopefully) final revision (-06) is expected on Tuesday, Feb 1. That version is expected to have new text on appeals, but otherwise only minor edits. Token: Harald Alvestrand 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date Guidelines for Authors of Extensions to the TSV Session Initiation Protocol (SIP) (Informational) - 1 of 5 draft-ietf-sip-guidelines-08.txt Token: Allison Mankin INT Mobile IPv6 Fast Handovers for 802.11 Networks (Informational) - 2 of 5 draft-ietf-mipshop-80211fh-03.txt [Open Web Ballot] Token: Thomas Narten Requirements for End-to-middle Security for TSV the Session Initiation Protocol (SIP) (Informational) - 3 of 5 draft-ietf-sipping-e2m-sec-reqs-05.txt Token: Allison Mankin OPS Architectural Approaches to Multi-Homing for IPv6 (Informational) - 4 of 5 draft-ietf-multi6-architecture-03.txt [Open Web Ballot] Token: David Kessens INT Host Identity Protocol Architecture (Informational) - 5 of 5 draft-ietf-hip-arch-02.txt [Open Web Ballot] Token: Margaret Wasserman 3.1.2 Returning Item Area Date APP XML Voucher: Generic Voucher Language (Informational) - 1 of 2 draft-ietf-trade-voucher-lang-07.txt [Open Web Ballot] Note: All old discusses have been cleared. Returning for the additional approvals needed for publication. This is one of the last two documents needed to finish the work of the TRADE working group. Token: Scott Hollenbeck APP Voucher Trading System Application Programming Interface (VTS-API) (Informational) - 2 of 2 draft-ietf-trade-voucher-vtsapi-06.txt [Open Web Ballot] Note: This is one of the last two documents needed to finish the work of the TRADE working group. Token: Scott Hollenbeck 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date APP Three-Document ballot: [Open Web Ballot] - 1 of 2 SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message (Experimental) - 1 of 2 draft-katz-submitter-00.txt Note: Sent to dea-dir Sender ID: Authenticating E-Mail (Experimental) draft-lyon-senderid-core-00.txt Note: Sent to dea-dir Purported Responsible Address in E-Mail Messages (Experimental) draft-lyon-senderid-pra-00.txt Note: Sent to dea-dir Token: Ted Hardie APP Sender Policy Framework: Authorizing Use of Domains in E-MAIL (Experimental) - 2 of 2 draft-schlitt-spf-classic-00.txt [Open Web Ballot] Note: Sent to dea-dir for review Token: Ted Hardie 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item Area Date MAC-Forced Forwarding: A Method for Traffic INT Separation on an Ethernet Access Network (Informational) - 1 of 1 draft-melsen-mac-forced-fwd-03.txt [Open Web Ballot] Token: Thomas Narten 3.3.2 Returning Item NONE 3.3.3 For Action Area Date OPS Mar 19 A Suggested Scheme for DNS Resolution of Networks and Gateways (Informational) - 1 of 3 draft-warnicke-network-dns-resolution-05.txt Note: RFC-Editor is reviewing (External Party) Token: Harald Alvestrand GEN National and Local Characters for DNS Top Level Domain (TLD) Names (Informational) - 2 of 3 draft-klensin-idn-tld-04.txt Token: Harald Alvestrand GEN A Model of IPv6/IPv4 Dual Stack Internet Access Service (Informational) - 3 of 3 draft-shirasaki-dualstack-service-04.txt Token: Harald Alvestrand 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review Area Date INT Jan 20 Network Time Protocol (ntp) - 1 of 2 Token: Thomas INT Jan 19 IPv6 over IEEE 802.15.4 (lowpan) - 2 of 2 Token: Thomas 4.1.2 Proposed for Approval Area Date TSV Jan 3 Emergency Context Resolution with Internet Technologies (ecrit) - 1 of 1 Token: Jon 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review Area Date INT Jan 20 DNS Extensions (dnsext) - 1 of 2 Token: Thomas INT Jan 19 Mobility for IPv4 (mip4) - 2 of 2 Token: Thomas 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issues From rtg-dir-bounces@ietf.org Mon Feb 14 05:30:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12306 for ; Mon, 14 Feb 2005 05:30:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0dpX-00067Z-U3 for rtg-dir-archive@ietf.org; Mon, 14 Feb 2005 05:51:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0dPY-0002eR-On; Mon, 14 Feb 2005 05:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0dOH-0002WQ-Ty for rtg-dir@megatron.ietf.org; Mon, 14 Feb 2005 05:23:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11767 for ; Mon, 14 Feb 2005 05:23:38 -0500 (EST) Message-Id: <200502141023.FAA11767@ietf.org> Received: from [201.138.90.33] (helo=fttinc.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D0dj3-00060r-Ur for rtg-dir@ietf.org; Mon, 14 Feb 2005 05:45:11 -0500 From: "Tahvo Conroy" To: "Wolfram Gomes" Date: Mon, 14 Feb 2005 05:12:08 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_0543B1C3.D652D2BA" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.4 (+++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: Valuable Pharmmacy X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.1 (++++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. ------=_NextPart_000_0013_0543B1C3.D652D2BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Welcome to the best online ST0RE With each purchase you get: >Top quality medicationn. >Low prices. >Reputable manufacturers. >Secure pay system. >Discreet packaging. >Home delivery. >Total confidentiality. >24 toll-free customer service hotline. Have a nice day. ------=_NextPart_000_0013_0543B1C3.D652D2BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,  Welcome = to the best=20 online ST0RE
 
Vi ra  al Xa x  cod
ag (109$ / 30p) = Ci is (324$ /=20 90p)  na (299$ / 90p) = Vi in (178$ /=20 90p)
 
With each purchase you get:
 
>Top quality medicationn.
>Low=20 prices.
>Reputable manufacturers.
>Secure pay=20 system.
>Discreet packaging.
>Home delivery.
>Total=20 confidentiality.
>24 toll-free customer service = hotline.
 
Have a nice day.
------=_NextPart_000_0013_0543B1C3.D652D2BA-- From rtg-dir-bounces@ietf.org Mon Feb 14 07:11:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23502 for ; Mon, 14 Feb 2005 07:11:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0fPE-0008Nf-0Q for rtg-dir-archive@ietf.org; Mon, 14 Feb 2005 07:32:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0eyV-0004HV-FP; Mon, 14 Feb 2005 07:05:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0evI-0003yk-Fn for rtg-dir@megatron.ietf.org; Mon, 14 Feb 2005 07:01:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22608 for ; Mon, 14 Feb 2005 07:01:49 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0fG7-0008Aw-QG for rtg-dir@ietf.org; Mon, 14 Feb 2005 07:23:24 -0500 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-blue.research.att.com (Postfix) with ESMTP id E1B3C1974DF for ; Mon, 14 Feb 2005 06:44:38 -0500 (EST) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j1EC02wn026385 for ; Mon, 14 Feb 2005 04:00:02 -0800 (PST) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j1EC02rx026384 for rtg-dir@ietf.org; Mon, 14 Feb 2005 04:00:02 -0800 (PST) (envelope-from fenner) Date: Mon, 14 Feb 2005 04:00:02 -0800 (PST) Message-Id: <200502141200.j1EC02rx026384@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Subject: IESG agenda for 2005-02-17 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-02-17). Updated 2:27:15 EDT, February 14, 2005 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date APP Internet FAX Gateway Functions (Proposed Standard) - 1 of 7 draft-ietf-fax-gateway-protocol-12.txt [Open Text Ballot] Token: Scott Hollenbeck RTG BGP Extended Communities Attribute (Proposed Standard) - 2 of 7 draft-ietf-idr-bgp-ext-communities-08.txt [Open Web Ballot] Token: Bill Fenner Key Management Extensions for Session TSV Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) (Proposed Standard) - 3 of 7 draft-ietf-mmusic-kmgmt-ext-13.txt [Open Web Ballot] Token: Jon Peterson Session Description Protocol Security TSV Descriptions for Media Streams (Proposed Standard) - 4 of 7 draft-ietf-mmusic-sdescriptions-09.txt [Open Web Ballot] Token: Jon Peterson RObust Header Compression (ROHC):Context TSV Replication for ROHC Profiles (Proposed Standard) - 5 of 7 draft-ietf-rohc-context-replication-06.txt [Open Web Ballot] Token: Allison Mankin The Extensible Markup Language (XML) APP Configuration Access Protocol (XCAP) (Proposed Standard) - 6 of 7 draft-ietf-simple-xcap-06.txt [Open Web Ballot] Token: Ted Hardie Extensible Markup Language (XML) Formats for APP Representing Resource Lists (Proposed Standard) - 7 of 7 draft-ietf-simple-xcap-list-usage-05.txt [Open Web Ballot] Token: Ted Hardie 2.1.2 Returning Item Area Date The Stream Control Transmission Protocol TSV (SCTP) as a Transport for the Session Initiation Protocol (SIP) (Proposed Standard) - 1 of 1 draft-ietf-sip-sctp-06.txt [Open Text Ballot] Token: Allison Mankin 2.1.3 For Action Area Date TSV Requirements for ROHC IP/TCP Header Compression (Informational) - 1 of 1 draft-ietf-rohc-tcp-requirements-08.txt Token: Allison Mankin 2.2 Individual Submissions 2.2.1 New Item Area Date Addition of SEED Ciphersuites to Transport SEC Layer Security (TLS) (Proposed Standard) - 1 of 3 draft-lee-tls-seed-01.txt [Open Web Ballot] Token: Russ Housley APP The Standard Hexdump Format (Proposed Standard) - 2 of 3 draft-strombergson-shf-05.txt [Open Web Ballot] Note: Needs revision to handle last call comments Token: Ted Hardie SEC Guidelines for Cryptographic Key Management (BCP) - 3 of 3 draft-bellovin-mandate-keymgmt-03.txt [Open Web Ballot] Token: Sam Hartman 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date Mobile IP version 6 Route Optimization INT Security Design Background (Informational) - 1 of 3 draft-ietf-mip6-ro-sec-02.txt [Open Web Ballot] Note: 2005-02-08: ready for full IESG review Token: Thomas Narten TSV TCP/IP Field Behavior (Informational) - 2 of 3 draft-ietf-rohc-tcp-field-behavior-04.txt Note: Sent to tcpm wg for their look Token: Allison Mankin INT Framework for L3VPN Operations and Management (Informational) - 3 of 3 draft-ietf-l3vpn-mgt-fwk-03.txt [Open Web Ballot] Note: 2005-02-09: only minor comments, will put before the full IESG. Token: Thomas Narten 3.1.2 Returning Item Area Date APP Guideline of optional services for Internet FAX Gateway (Informational) - 1 of 1 draft-ietf-fax-gateway-options-08.txt [Open Web Ballot] Token: Scott Hollenbeck 3.1.3 For Action Area Date TSV Requirements for ROHC IP/TCP Header Compression (Informational) - 1 of 1 draft-ietf-rohc-tcp-requirements-08.txt Token: Allison Mankin 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date TSV SIP Telephony Device Requirements and Configuration (Informational) - 1 of 4 draft-sinnreich-sipdev-req-05.txt [Open Web Ballot] Note: RFC-Editor note forthcoming to respond to a few last-minute comments. Token: Jon Peterson APP The APPLICATION/MBOX Media-Type (Informational) - 2 of 4 draft-hall-mime-app-mbox-04.txt [Open Web Ballot] Token: Scott Hollenbeck APP Three-Document ballot: [Open Web Ballot] - 3 of 4 SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message (Experimental) - 3 of 4 draft-katz-submitter-00.txt Note: Sent to dea-dir Sender ID: Authenticating E-Mail (Experimental) draft-lyon-senderid-core-00.txt Note: Sent to dea-dir Purported Responsible Address in E-Mail Messages (Experimental) draft-lyon-senderid-pra-00.txt Note: Sent to dea-dir Token: Ted Hardie APP Sender Policy Framework: Authorizing Use of Domains in E-MAIL (Experimental) - 4 of 4 draft-schlitt-spf-classic-00.txt [Open Web Ballot] Note: Sent to dea-dir for review Token: Ted Hardie 3.2.2 Returning Item Area Date APP The 'tag' URI scheme (Informational) - 1 of 1 draft-kindberg-tag-uri-07.txt [Open Web Ballot] Token: Ted Hardie 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item Area Date GEN LDAP Content Synchronization Operation (Experimental) - 1 of 2 draft-zeilenga-ldup-sync-06.txt Note: Via RFC-Editor Token: Ted Hardie MAC-Forced Forwarding: A Method for Traffic INT Separation on an Ethernet Access Network (Informational) - 2 of 2 draft-melsen-mac-forced-fwd-03.txt [Open Web Ballot] Token: Thomas Narten 3.3.2 Returning Item Area Date INT Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks (Informational) - 1 of 4 draft-carroll-dynmobileip-cdma-04.txt [Open Web Ballot] Note: 2005-02-08: IESG: this document violates a MUST NOT in radius, one that is not insignificant. I.e., it relates to security aspects/assumptions underlying radius. So, it 'extends and embraces' an IETF protocol in a way that warrants IETF review/acceptance. Token: Thomas Narten TSV Two-Document ballot: [Open Web Ballot] - 2 of 4 Reliable Multicast Transport Building Block: Tree Auto-Configuration (Informational) - 2 of 4 draft-sjkoh-rmt-bb-tree-config-03.txt Note: There is a note of concern from an RMT WG Chair in the ballot comments: these documents retain all the RMT WG boilerplate. History: they were not handled by the WG because the authors stopped work on them (stopped doing any updates, did not appear for over a year), so their work item was dropped by consensus. Reliable Multicast Transport Building Block:Tree based ACK (TRACK) Mechanisms (Informational) draft-chiu-rmt-bb-track-03.txt Note: Note sent to RMT Chairs reminding them of these and suggesting reminder to WG (to avoid surprise). IESG ex-WG note to be put on. Token: Allison Mankin INT National and Local Characters for DNS Top Level Domain (TLD) Names (Informational) - 3 of 4 draft-klensin-idn-tld-04.txt [Open Web Ballot] Note: 2005-02-10: I've reviewed this and do not believe it conflicts with any IETF work. I think is fine to be published as an Independent Submission Token: Thomas Narten INT A Model of IPv6/IPv4 Dual Stack Internet Access Service (Informational) - 4 of 4 draft-shirasaki-dualstack-service-04.txt [Open Web Ballot] Note: 2005-02-09: This seems fine to have the RFC Editor publish as an independent submission. Token: Thomas Narten 3.3.3 For Action Area Date GEN Peer-to-Peer communication across Middleboxes (Informational) - 1 of 1 draft-ford-midcom-p2p-03.txt Note: Author has informed me that they are no longer persuing this draft. Token: Jon Peterson 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review Area Date APP Feb 8 Language Tag Registry Update (ltru) - 1 of 2 Token: Ted INT Feb 10 Transparent Interconnection of Lots of Links (trill) - 2 of 2 Token: Margaret 4.1.2 Proposed for Approval Area Date INT Jan 20 Network Time Protocol (ntp) - 1 of 2 Token: Thomas INT Jan 19 IPv6 over IEEE 802.15.4 (lowpan) - 2 of 2 Token: Thomas 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issues From rtg-dir-bounces@ietf.org Wed Feb 16 04:50:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19128 for ; Wed, 16 Feb 2005 04:50:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1MAh-0006cr-PT for rtg-dir-archive@ietf.org; Wed, 16 Feb 2005 05:12:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Ljj-00032J-FZ; Wed, 16 Feb 2005 04:44:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Lis-0002mm-Vz for rtg-dir@megatron.ietf.org; Wed, 16 Feb 2005 04:43:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18495 for ; Wed, 16 Feb 2005 04:43:51 -0500 (EST) Message-Id: <200502160943.EAA18495@ietf.org> Received: from [211.109.246.172] (helo=fuocofisso.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1M44-0006TE-CC for rtg-dir@ietf.org; Wed, 16 Feb 2005 05:05:50 -0500 From: "Mahalia Cartwright" To: "Solange Reece" Date: Wed, 16 Feb 2005 04:48:43 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_0C9BBB22.A84EABC2" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: Great Phaarrmacy you need X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is a multi-part message in MIME format. ------=_NextPart_000_0004_0C9BBB22.A84EABC2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_0004_0C9BBB22.A84EABC2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,  Welcome = to the best=20 online ST0RE
 
Vi ra  al Xa x  cod
ag (109$ / 30p) = Ci is (324$ /=20 90p)  na (299$ / 90p) = Vi in (178$ /=20 90p)
 
With each purchase you get:
 
>Top quality medicationn.
>Low=20 prices.
>Reputable manufacturers.
>Secure pay=20 system.
>Discreet packaging.
>Home delivery.
>Total=20 confidentiality.
>24 toll-free customer service = hotline.
 
Have a nice day.
------=_NextPart_000_0004_0C9BBB22.A84EABC2-- From rtg-dir-bounces@ietf.org Thu Feb 17 12:43:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03518 for ; Thu, 17 Feb 2005 12:43:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1q2G-0006oz-LL for rtg-dir-archive@ietf.org; Thu, 17 Feb 2005 13:05:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nO3-0003xZ-4y; Thu, 17 Feb 2005 10:16:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nAA-0006sv-7b for rtg-dir@megatron.ietf.org; Thu, 17 Feb 2005 10:01:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02113 for ; Thu, 17 Feb 2005 10:01:52 -0500 (EST) Received: from legolas.muc.aspiria.de ([195.190.133.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1nVd-0005cq-D2 for rtg-dir@ietf.org; Thu, 17 Feb 2005 10:24:05 -0500 Received: from legolas.muc.aspiria.de (localhost [127.0.0.1]) by legolas.muc.aspiria.de (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j1HF1uhL024647 for ; Thu, 17 Feb 2005 16:01:56 +0100 Received: (from wwwrun@localhost) by legolas.muc.aspiria.de (8.12.10/8.12.10/Submit) id j1HF1uTW024646; Thu, 17 Feb 2005 16:01:56 +0100 Date: Thu, 17 Feb 2005 16:01:56 +0100 Message-Id: <200502171501.j1HF1uTW024646@legolas.muc.aspiria.de> To: rtg-dir@ietf.org From: Washington Mutual Bank MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit X-Spam-Score: 2.4 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 8bit Subject: Unauthorized Access To Your Washington Mutual Internet Banking account X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 8bit ` Dear Washington Mutual customer

Dear Washington Mutual customer,

We recently reviewed your account, and suspect that your Washington Mutual Internet Banking account may have been accessed by an unauthorized third party.
Protecting the security of your account and of the Washington Mutual network is our primary concern. Therefore, as a preventative measure, we have temporarily limited access to sensitive account features.

To restore your account access , please take the following steps to ensure that your account has not been compromised:

1. Login to your Washington Mutual Internet Banking account. In case you are not enrolled yet for Internet Banking, you will have to use your Social Security Number as both your Personal ID and Password and fill in the required information, including your name and account number.

2. Review your recent account history for any unauthorized withdrawals or deposits, and check your account profile to make sure no changes have been made. If any unauthorized activity has taken place on your account, report to Washington Mutual staff immediately.

To get started, please click the link below:

https://login.personal.wamu.com/logon/logon.asp?dd=1

We apologize for any inconvenience this may cause, and appreciate your assistance in helping us maintain the integrity of the entire Washington Mutual system. Thank your for your prompt attention to this matter.

Sincerely,

The Washington Mutual Team.

Please do not reply to this email. Mails sent to thi address cannot be answered. For assistance, log in to your Washington Mutual account and choose the "Help" link in the header of any page.

From rtg-dir-bounces@ietf.org Sat Feb 19 15:50:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06611 for ; Sat, 19 Feb 2005 15:50:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2bui-0001Wf-Q8 for rtg-dir-archive@ietf.org; Sat, 19 Feb 2005 16:13:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2a74-0003uN-Jw; Sat, 19 Feb 2005 14:17:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2YTo-0004b9-Ki for rtg-dir@megatron.ietf.org; Sat, 19 Feb 2005 12:33:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23856 for ; Sat, 19 Feb 2005 12:32:52 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2YpI-0005FP-Cp for rtg-dir@ietf.org; Sat, 19 Feb 2005 12:55:34 -0500 Received: from [221.147.202.14] (helo=221.147.202.14) by mx2.foretec.com with smtp (Exim 4.24) id 1D2YTM-0000F4-KW for rtg-dir@ietf.org; Sat, 19 Feb 2005 12:32:54 -0500 Message-ID: <6cd001c516a6$32ddbaed$039511ff@about.com> From: "Paul A. Davis" To: rtg-dir@ietf.org Date: Sat, 19 Feb 2005 17:15:49 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_1B3C49F3.937AF92E" 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-Score: 4.7 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: Cialis - LOW price! X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.7 (++++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_0000_1B3C49F3.937AF92E Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_AD361333.78D218AA" ------=_NextPart_001_0001_AD361333.78D218AA Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Rock hard erections Long effects duration No prescription needed 2 popular medicines: Cialis - http://www.triamed.biz/sv/ Viagra - http://www.triamed.biz/vt/ Discreet packaging _________________________________________________________________________ To change your mail details, go here: http://www.triamed.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_AD361333.78D218AA Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit

Full & stable erections
Long effects
No prescription needed

2 popular medicines:
CIALIS - http://www.triamed.biz/sv/
VIAGRA - http://www.triamed.biz/vt/

Directly from the manufacturer!


_________________________________________________________________________
To be taken off future campaigns, go here: http://www.triamed.biz/uns.htm
_________________________________________________________________________

------=_NextPart_001_0001_AD361333.78D218AA-- ------=_NextPart_000_0000_1B3C49F3.937AF92E-- From rtg-dir-bounces@ietf.org Wed Feb 23 17:09:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26772 for ; Wed, 23 Feb 2005 17:09:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D454W-0004Rk-Jn for rtg-dir-archive@ietf.org; Wed, 23 Feb 2005 17:33:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lIe-0001W1-Dc; Tue, 22 Feb 2005 20:26:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lIc-0001VM-Ny for rtg-dir@megatron.ietf.org; Tue, 22 Feb 2005 20:26:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21743 for ; Tue, 22 Feb 2005 20:26:38 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3lf6-0001Ge-Ns for rtg-dir@ietf.org; Tue, 22 Feb 2005 20:50:01 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 7A21C1974E8 for ; Tue, 22 Feb 2005 20:08:49 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j1N1Q7Pe021933; Tue, 22 Feb 2005 17:26:07 -0800 Message-Id: <200502230126.j1N1Q7Pe021933@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-dir@ietf.org Date: Tue, 22 Feb 2005 17:26:07 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: Getting (re)organized - routing (directorate) secretary? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fenner@research.att.com, zinin@psg.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Howdy, y'all! We've kind of fallen behind on the assigning reviews like we decided to do in San Diego - so as good managers, we've decided the best thing to do is delegate! We're looking for a volunteer to coordinate reviewers and documents and put them together. The plan as I remember it is that the directorate would review: - All routing area documents during their WG last call - Selected relevant documents from other areas during IETF Last Call or in time for an IESG Telechat. We would try to get two reviewers per document: - One round-robin - One with expertise in the topic Is anyone here interested in helping to coordinate the job of assigning (and nagging) reviewers within this context? I'm willing to help with tools on rtg.ietf.org (we had discussed using RT; I'm looking into Roundup since it may integrate better into the existing password system on the web site...) If you're interested in volunteering, please let Alex and I know. Thanks, Bill From rtg-dir-bounces@ietf.org Wed Feb 23 17:10:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26819 for ; Wed, 23 Feb 2005 17:10:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D454h-0004SW-E0 for rtg-dir-archive@ietf.org; Wed, 23 Feb 2005 17:33:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lQw-0002AT-P5; Tue, 22 Feb 2005 20:35:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lQv-0002A1-0C for rtg-dir@megatron.ietf.org; Tue, 22 Feb 2005 20:35:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22134; Tue, 22 Feb 2005 20:32:39 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3lkw-0001OD-Th; Tue, 22 Feb 2005 20:56:03 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 7328B1974E8; Tue, 22 Feb 2005 20:14:51 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j1N1WANu022352; Tue, 22 Feb 2005 17:32:10 -0800 Message-Id: <200502230132.j1N1WANu022352@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-chairs@ietf.org, rtg-dir@ietf.org Date: Tue, 22 Feb 2005 17:32:10 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: Looking at the direction of the Routing Area X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Folks, Would you be interested in a get together (perhaps Tuesday lunchtime) in Minneapolis to talk about the direction of the routing area? Are we covering the right important topics? Are our policies working for or against us? Are we coordinating with the right external bodies? What is our worst failing? Thanks, Bill From rtg-dir-bounces@ietf.org Wed Feb 23 17:10:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26897 for ; Wed, 23 Feb 2005 17:10:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D454w-0004Tb-OP for rtg-dir-archive@ietf.org; Wed, 23 Feb 2005 17:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3m96-0007H7-9b; Tue, 22 Feb 2005 21:21:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3m95-0007Gm-89 for rtg-dir@megatron.ietf.org; Tue, 22 Feb 2005 21:20:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25975 for ; Tue, 22 Feb 2005 21:20:48 -0500 (EST) Message-Id: <200502230220.VAA25975@ietf.org> Received: from [211.238.193.77] (helo=joeykarson.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3mVX-0002RC-8H for rtg-dir@ietf.org; Tue, 22 Feb 2005 21:44:12 -0500 From: "Eden Doty" To: "Travis Berger" Date: Tue, 22 Feb 2005 21:37:26 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_017676DE.95D9D989" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: Re: Good Pharmaccy X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.0 (++++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. ------=_NextPart_000_0013_017676DE.95D9D989 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_0013_017676DE.95D9D989 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello. Welcome=20 to our online ST0RE.
 
Vi in $178(90p.) a a $209(100p.) ana al
cod  Vi gr  X x $299(90p.) Ci is $324(90p.)
 
With each purchase you = get:
>> Home delivery.
>> Total = confidentiality.
>> FDA Approved = drugs.
 
Have a nice = day.
------=_NextPart_000_0013_017676DE.95D9D989-- From rtg-dir-bounces@ietf.org Fri Feb 25 06:32:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02068 for ; Fri, 25 Feb 2005 06:32:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4dhc-0006Qx-UK for rtg-dir-archive@ietf.org; Fri, 25 Feb 2005 06:32:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4dhA-0001gE-MO; Fri, 25 Feb 2005 06:31:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4dh9-0001g3-Ig for rtg-dir@megatron.ietf.org; Fri, 25 Feb 2005 06:31:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02043 for ; Fri, 25 Feb 2005 06:31:40 -0500 (EST) Received: from [222.107.119.84] (helo=222.107.119.84) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4dhF-0006Qa-FN for rtg-dir@ietf.org; Fri, 25 Feb 2005 06:31:51 -0500 Message-ID: From: "Jennifer A. Clark" To: rtg-dir@ietf.org Date: Fri, 25 Feb 2005 11:22:49 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_6E11AB0D.14D66967" 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-Score: 1.2 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: Adobe Acrobat 6.0 - very low price X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0000_6E11AB0D.14D66967 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_A12E508F.1F3B8365" ------=_NextPart_001_0001_A12E508F.1F3B8365 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get all the software imaginable for unbelievably low prices! We sell software 2-6 times cheaper than retail price. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Visit us at: http://www.mxsoft.biz Regards, Jennifer Clark _____________________________________________________ To stop further mailings, go: http://www.mxsoft.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_A12E508F.1F3B8365 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Get access to all the software possible for less!
We sell software 2-6 times cheaper than retail price.

Just a few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$59.95 Corel Draw Graphics Suite 11

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... To visit us go:

http://www.mxsoft.biz

Best,
Jennifer A. Clark


_____________________________________________________
To stop further mailings, go here: http://www.mxsoft.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_A12E508F.1F3B8365-- ------=_NextPart_000_0000_6E11AB0D.14D66967-- From rtg-dir-bounces@ietf.org Sat Feb 26 22:54:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23741 for ; Sat, 26 Feb 2005 22:54:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5FW7-0008JL-NG for rtg-dir-archive@ietf.org; Sat, 26 Feb 2005 22:54:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5FVb-0003Zo-L3; Sat, 26 Feb 2005 22:54:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5FVa-0003Zf-B2 for rtg-dir@megatron.ietf.org; Sat, 26 Feb 2005 22:54:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23731 for ; Sat, 26 Feb 2005 22:54:10 -0500 (EST) Message-Id: <200502270354.WAA23731@ietf.org> Received: from adsl-tplus-16-117.intnet.mu ([202.123.16.117] helo=gblsolutions.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5FVv-0008J4-Oa for rtg-dir@ietf.org; Sat, 26 Feb 2005 22:54:42 -0500 From: "Geltrude Lamb" To: "Torquil Parris" Date: Sat, 26 Feb 2005 22:27:07 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_06278564.6C84EBB5" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.8 (+++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: OKT Medicationss X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.5 (++++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0008_06278564.6C84EBB5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, was a new city treasurer, a new assessor of taxes, and a new mayo and suspending with astonishing rapidity; and a knowledge of all Cowperwood, eyeing the fat sheriff from his position, understood kindling eyes, his almost formless yet bud-like mouth, and wonder For on Tuesday afternoon at two-thirty he issued a call for a not want any outsider to interfere. As a matter of fact the forgetful of the times he had looked at her in an interested controlled by her affections and deeply in love, is no more capab Have a nice day. ------=_NextPart_000_0008_06278564.6C84EBB5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello, Visit our Amazing=20 Online SH0P!
 
NOW SPEC  OFF  Cia ls) Vi ra $200(120 = pil itra $300(50 = pil
IAL ER: lis $300(150 pil ag ls) Lev ls)
And MANY OTHER.
 
With each purchase you = get:
  • Home delivery
  • Total confidentiality
  • FDAApproved
  • Highest Quality
    •  
    Have a nice = day.
    ------=_NextPart_000_0008_06278564.6C84EBB5-- From rtg-dir-bounces@ietf.org Mon Feb 28 07:04:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10341 for ; Mon, 28 Feb 2005 07:04:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5jeE-0005C5-WE for rtg-dir-archive@ietf.org; Mon, 28 Feb 2005 07:05:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5jaw-00036L-1R; Mon, 28 Feb 2005 07:01:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5jau-00036G-Dd for rtg-dir@megatron.ietf.org; Mon, 28 Feb 2005 07:01:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10177 for ; Mon, 28 Feb 2005 07:01:45 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5jbc-000599-1S for rtg-dir@ietf.org; Mon, 28 Feb 2005 07:02:34 -0500 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-blue.research.att.com (Postfix) with ESMTP id A5DFA197496 for ; Mon, 28 Feb 2005 06:43:52 -0500 (EST) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j1SC0Kwn075616 for ; Mon, 28 Feb 2005 04:00:21 -0800 (PST) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j1SC0Kg9075615 for rtg-dir@ietf.org; Mon, 28 Feb 2005 04:00:20 -0800 (PST) (envelope-from fenner) Date: Mon, 28 Feb 2005 04:00:20 -0800 (PST) Message-Id: <200502281200.j1SC0Kg9075615@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Subject: IESG agenda for 2005-03-03 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-03-03). Updated 2:27:37 EDT, February 28, 2005 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date SUB Link Bundling in MPLS Traffic Engineering (Proposed Standard) - 1 of 13 draft-ietf-mpls-bundle-06.txt [Open Text Ballot] Note: Has been pulled out of rfc-ed queue for a problem fix. Back to IESG to approve the changes. Token: Alex Zinin SEC HMAC-authenticated Diffie-Hellman for MIKEY (Proposed Standard) - 2 of 13 draft-ietf-msec-mikey-dhhmac-09.txt [Open Web Ballot] Token: Russ Housley TSV Two-Document ballot: [Open Web Ballot] - 3 of 13 Profile for DCCP Congestion Control ID 2:TCP-like Congestion Control (Proposed Standard) - 3 of 13 draft-ietf-dccp-ccid2-08.txt Profile for DCCP Congestion Control ID 3:TFRC Congestion Control (Proposed Standard) draft-ietf-dccp-ccid3-09.txt Token: Allison Mankin TSV Datagram Congestion Control Protocol (DCCP) (Proposed Standard) - 4 of 13 draft-ietf-dccp-spec-09.txt [Open Web Ballot] Token: Allison Mankin APP Two-Document ballot: [Open Web Ballot] - 5 of 13 Voice Messaging Directory Service (Proposed Standard) - 5 of 13 draft-ietf-vpim-vpimdir-10.txt Voice Message Routing Service (Proposed Standard) draft-ietf-vpim-routing-09.txt Token: Scott Hollenbeck RTG Removing a Restriction on the use of MPLS Explicit NULL (Proposed Standard) - 6 of 13 draft-ietf-mpls-explicit-null-02.txt [Open Web Ballot] Token: Alex Zinin Encoding of Attributes for Multiprotocol Label RTG Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE (Proposed Standard) - 7 of 13 draft-ietf-mpls-rsvpte-attributes-04.txt [Open Web Ballot] Token: Alex Zinin INT Link Scoped IPv6 Multicast Addresses (Proposed Standard) - 8 of 13 draft-ietf-ipv6-link-scoped-mcast-08.txt [Open Web Ballot] Token: Margaret Wasserman INT IPv6 Stateless Address Autoconfiguration (Draft Standard) - 9 of 13 draft-ietf-ipv6-rfc2462bis-07.txt [Open Web Ballot] Token: Margaret Wasserman SEC The Use of RSA Signatures within ESP and AH (Proposed Standard) - 10 of 13 draft-ietf-msec-ipsec-signatures-04.txt Token: Russ Housley SEC Dec 29 The Anonymous SASL Mechanism (Proposed Standard) - 11 of 13 draft-ietf-sasl-anon-05.txt [Open Web Ballot] Token: Sam Hartman An Extensible Markup Language (XML) Configuration APP Access Protocol (XCAP) Usage for Manipulating Presence Document Contents (Proposed Standard) - 12 of 13 draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt [Open Web Ballot] Token: Ted Hardie INT Mobile Node Identifier Option for Mobile IPv6 (Proposed Standard) - 13 of 13 draft-ietf-mip6-mn-ident-option-02.txt [Open Web Ballot] Token: Thomas Narten 2.1.2 Returning Item Area Date Internet X.509 Public Key Infrastructure Certificate SEC Request Message Format (CRMF) (Proposed Standard) - 1 of 1 draft-ietf-pkix-rfc2511bis-08.txt [Open Text Ballot] Note: Significant changes have been made since the last time the IESG looked at this document. I want to make sure that everyone is satisfied before approving it. Token: Russ Housley 2.2 Individual Submissions 2.2.1 New Item Area Date APP Message Submission (Draft Standard) - 1 of 1 draft-gellens-submit-bis-01.txt [Open Web Ballot] Token: Ted Hardie 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date Requirements for Edge-to-Edge Emulation of TDM TSV Circuits over Packet Switching Networks (PSN) (Informational) - 1 of 4 draft-ietf-pwe3-tdm-requirements-06.txt [Open Web Ballot] Note: 2005-02-08: chairs indicate a respin is in the works in response to AD review comments Token: Thomas Narten TSV RSVP Security Properties (Informational) - 2 of 4 draft-ietf-nsis-rsvp-sec-properties-06.txt [Open Web Ballot] Token: Allison Mankin INT A Framework for transmission of IP datagrams over MPEG-2 Networks (Informational) - 3 of 4 draft-ietf-ipdvb-arch-03.txt [Open Web Ballot] Token: Margaret Wasserman INT Authentication Protocol for Mobile IPv6 (Informational) - 4 of 4 draft-ietf-mip6-auth-protocol-04.txt [Open Web Ballot] Note: 2005-02-15: Has a normative dependency on draft-ietf-mip6-mn-ident-option-02.txt, which needs to go through IETF LC first. Token: Thomas Narten 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date APP The wais URI Scheme (Historic) - 1 of 4 draft-hoffman-wais-uri-03.txt [Open Web Ballot] Token: Ted Hardie APP The prospero URI Scheme (Historic) - 2 of 4 draft-hoffman-prospero-uri-03.txt [Open Web Ballot] Token: Ted Hardie Mediating Network Discovery in the Extensible INT Authentication Protocol (EAP) (Informational) - 3 of 4 draft-adrangi-eap-network-discovery-10.txt [Open Web Ballot] Token: Margaret Wasserman APP A Uniform Resource Name (URN) Namespace for the CLEI Code (Informational) - 4 of 4 draft-tesink-urn-clei-00.txt [Open Web Ballot] Token: Ted Hardie 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item Area Date OPS Mar 19 A Suggested Scheme for DNS Resolution of Networks and Gateways (Informational) - 1 of 1 draft-warnicke-network-dns-resolution-05.txt Note: 2005-02-23: I've reviewed this and do not believe it conflicts with any IETF work. I think is fine to be published as an Independent Submission. Token: David Kessens 3.3.2 Returning Item Area Date INT Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks (Informational) - 1 of 2 draft-carroll-dynmobileip-cdma-04.txt [Open Web Ballot] Note: 2005-02-08: IESG: this document violates a MUST NOT in radius, one that is not insignificant. I.e., it relates to security aspects/assumptions underlying radius. So, it 'extends and embraces' an IETF protocol in a way that warrants IETF review/acceptance. Token: Thomas Narten INT National and Local Characters for DNS Top Level Domain (TLD) Names (Informational) - 2 of 2 draft-klensin-idn-tld-04.txt [Open Web Ballot] Note: 2005-02-10: I've reviewed this and do not believe it conflicts with any IETF work. I think is fine to be published as an Independent Submission Token: Thomas Narten 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review Area Date SEC Feb 24 Better-Than-Nothing Security (btns) - 1 of 1 Token: Sam 4.1.2 Proposed for Approval Area Date APP Feb 8 Language Tag Registry Update (ltru) - 1 of 3 Token: Ted INT Jan 19 IPv6 over IEEE 802.15.4 (lowpan) - 2 of 3 Token: Thomas INT Feb 10 Transparent Interconnection of Lots of Links (trill) - 3 of 3 Token: Margaret 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issues From rtg-dir-bounces@ietf.org Tue Mar 1 16:59:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15173 for ; Tue, 1 Mar 2005 16:59:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6FQ3-00073u-VG for rtg-dir-archive@ietf.org; Tue, 01 Mar 2005 17:00:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6FOd-0002pm-CI; Tue, 01 Mar 2005 16:59:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6FOc-0002pS-5K for rtg-dir@megatron.ietf.org; Tue, 01 Mar 2005 16:59:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15126; Tue, 1 Mar 2005 16:58:57 -0500 (EST) Received: from [80.86.78.228] (helo=tbdns.testbed.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6FPM-00072M-Vo; Tue, 01 Mar 2005 17:00:03 -0500 Received: from [192.168.0.100] (h118n2fls31o874.telia.com [213.66.236.118]) (authenticated bits=0) by tbdns.testbed.local (8.12.8/8.12.8) with ESMTP id j21Lpqpt003445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Mar 2005 22:51:53 +0100 Message-ID: <4224E591.9050905@pi.se> Date: Tue, 01 Mar 2005 22:58:41 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Fenner References: <200502230132.j1N1WANu022352@bright.research.att.com> In-Reply-To: <200502230132.j1N1WANu022352@bright.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: Looking at the direction of the Routing Area X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Bill, haven't seen any responses to this, but yes it is a good idea, Tuesday lunch is between ccamp and l2vpn, so it would work :) /Loa Bill Fenner wrote: > Folks, > > Would you be interested in a get together (perhaps Tuesday lunchtime) > in Minneapolis to talk about the direction of the routing area? > Are we covering the right important topics? Are our policies working for > or against us? Are we coordinating with the right external bodies? > What is our worst failing? > > Thanks, > Bill > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From rtg-dir-bounces@ietf.org Tue Mar 1 17:39:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18007 for ; Tue, 1 Mar 2005 17:39:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6G31-0007ki-CY for rtg-dir-archive@ietf.org; Tue, 01 Mar 2005 17:41:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6FyW-0000VY-3x; Tue, 01 Mar 2005 17:36:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6FyV-0000VN-0e for rtg-dir@megatron.ietf.org; Tue, 01 Mar 2005 17:36:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17744; Tue, 1 Mar 2005 17:36:15 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6FzU-0007gU-Nl; Tue, 01 Mar 2005 17:37:22 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.2/8.13.2) with ESMTP id j21Ma5nk013359; Tue, 1 Mar 2005 14:36:05 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.2/8.12.11/Submit) id j21Ma53s013358; Tue, 1 Mar 2005 14:36:05 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 1 Mar 2005 14:36:05 -0800 From: David Meyer To: Bill Fenner Message-ID: <20050301223605.GA13336@1-4-5.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline 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-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: Looking at the direction of the Routing Area X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Bill, >> Would you be interested in a get together (perhaps Tuesday lunchtime) >> in Minneapolis to talk about the direction of the routing area? >> Are we covering the right important topics? Are our policies working for >> or against us? Are we coordinating with the right external bodies? >> What is our worst failing? This is a very reasonable idea and set of topics. However, I'm already booked on Tuesday. Are there other options?=20 Thanks, Dave --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCJO5VORgD1qCZ2KcRAtFxAJ9npesxU6++0GfJ3ZdcTOR09XlGBgCfVihU Dw60vCayJhQ38S2VjymRLlo= =Vws1 -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From rtg-dir-bounces@ietf.org Tue Mar 1 20:57:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03837 for ; Tue, 1 Mar 2005 20:57:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6J7t-00039u-8X for rtg-dir-archive@ietf.org; Tue, 01 Mar 2005 20:58:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6J5j-0001q0-13; Tue, 01 Mar 2005 20:55:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6J5h-0001pv-8D for rtg-dir@megatron.ietf.org; Tue, 01 Mar 2005 20:55:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03719; Tue, 1 Mar 2005 20:55:20 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6J6D-00037k-3d; Tue, 01 Mar 2005 20:56:30 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 302BE1974CC; Tue, 1 Mar 2005 20:37:24 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j221tDuq032115; Tue, 1 Mar 2005 17:55:13 -0800 Message-Id: <200503020155.j221tDuq032115@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-chairs@ietf.org, rtg-dir@ietf.org References: <200502230132.j1N1WANu022352@bright.research.att.com> <4224E591.9050905@pi.se> Date: Tue, 1 Mar 2005 17:55:13 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: Re: Looking at the direction of the Routing Area X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Tuesday lunch is bad for a few people. My next attempt will be Sunday dinnertime, after the reception. If we had a meeting room and some way to get food (room service?), would people be willing to do this? I'd like to get a feeling for how many people might be willing to attend so that we can ask for a room. We've tried several times to have this kind of meeting at a bar or restaurant but failed to manage to get everyone involved in (more than a social) discussion; that's why I'm hoping to get a meeting room at the hotel. Thanks, Bill From rtg-dir-bounces@ietf.org Wed Mar 2 08:14:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08349 for ; Wed, 2 Mar 2005 08:14:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ThZ-0008VE-JY for rtg-dir-archive@ietf.org; Wed, 02 Mar 2005 08:15:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Tg4-0004Tl-0F; Wed, 02 Mar 2005 08:14:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Tdl-00046e-EW; Wed, 02 Mar 2005 08:11:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08046; Wed, 2 Mar 2005 08:11:47 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Ten-0008S5-RE; Wed, 02 Mar 2005 08:13:01 -0500 Received: from [211.207.205.118] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D6Tda-0008Oo-BZ; Wed, 02 Mar 2005 08:11:38 -0500 Received: from BDT@localhost by g2G7.int (8.11.6/8.11.6); Wed, 02 Mar 2005 11:05:02 -0200 Message-ID: From: "Jennifer Easley" To: rtg-dir@ietf.org, ldap-dir-web-archive@ietf.org, cfrg-admin@ietf.org, rserpool-admin@ietf.org Date: Wed, 02 Mar 2005 08:07:02 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NicoleHayes@saintedwardseattle.org Content-Type: multipart/mixed; boundary="--Pz0qyjbABJULD0ZKsFeM" X-Spam-Score: 3.7 (+++) X-Scan-Signature: 3c84bd88e6bbcc6464f782162bb7ae94 Subject: Windows XP Pro $49.95, Office 2003 $69.95 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jennifer Easley List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.7 (+++) X-Scan-Signature: 966811b049c4d80323826ee01e1b1ce9 1px ----Pz0qyjbABJULD0ZKsFeM Content-Type: text/html; Content-Transfer-Encoding: quoted-printable L
    Opt-= in Email Special Offer     unsubscribe me =
    If this notice has reached you in error, please notify us by<= FONT COLOR=3D"#d5d5d0" SIZE=3D"-2" FACE=3D"Arial"> cl= icking here
    SEARCH

    TOP 10 NEW TITLES

     ON SALE NOW!
      1 Office Pro Editi= on 2003
      2 Wind= ows XP Pro
      3 Adobe Creative S= uite Premium
      4 Systemworks Pro = 2004 Edition
      5 Flash MX 2004
      6 Corel Painter 8<= /a>
      7 Adob= e Acrobat 6.0
      8 Windows 2003 Ser= ver
      9 Alias Maya 6.0 W= avefront
      10 Adobe Premiere
      = See more by this man= ufacturer
        Microsoft
        Apple Software
      = Customers also bough= t
        these other item= s...



    		Micr= osoft Office Professional Edition *2003*
    Microsoft<= /a>
    Choose:
     
    <= /a>
    List Price: $899.00
    Price: $69.99
    You Save: $830.01 (92%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System req= uirements  |  Accessories  |&= nbsp; Other Versions

    Features:

    • Analyze and manage business inf= ormation using Access databases
    • Exchange data with other system= s using enhanced XML technology
    • Control information sharing rul= es with enhanced IRM technology
    • Easy-to-use wizards to create e= -mail newsletters and printed marketing materials
    • More than 20 preformatted busin= ess reports
    Sales Rank: #1
    Shipping: International/US or via instant downlo= ad
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 1,768 reviews. Write a = review.
    Microsoft Wind= ows XP Professional or Longhorn Edition
    Micros= oft
    Choose:
     

    =

    List Price: $279.00
    Price: $49.99
    You Save: $229.01 (85%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System= requirements  |  Accessories = ; |  Other Versions

    Features:

    • Designed for businesses of a= ll sizes
    • Manage digital pictures, mu= sic, video, DVDs, and more
    • More security with the abil= ity to encrypt files and folders
    • Built-in voice, video, and = instant messaging support
    • Integration with Windows se= rvers and management solutions

    Sales Rank: #2
    Shipping: International/US or via instant do= wnload
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 868 reviews. Write = a review.

    Adobe Crea= tive Suite Premium
    Ad= obe
    Choose:
     

    List Price: $1149.00
    Price: $99.99
    You Save: $849.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    Sy= stem requirements  |  Accessories&= nbsp; |  Other Versions

    Features: <= /font>

    • An integrated design en= vironment featuring the industry's foremost design tools
    • In-depth tips, expert t= ricks, and comprehensive design resources
    • Intuitive file finding,= smooth workflow, and common interface and toolset
    • Single installer--contr= ol what you install and when you install it
    • Cross-media publishing-= -create content for both print and the Web

    Sales Rank: #3
    Shipping: International/US or via instan= t download
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 498 reviews.     Wr= ite a review.

    Symantec SystemWorks = 2004 Professional
    Symantec
    Choose:
     

    List Price: $99.00
    Price: $29.99
    You Save: $69.01 (70%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requirements  |  Accessories = ; |  Other Versions


    Features: =

    • Norton Utilities op= timizes your PC=BFs performance and solves computer problems <= /li>
    • Norton Password Man= ager keeps your passwords secure and easy to manage
    • Norton GoBack Perso= nal Edition restores your PC after a serious problem
    • Norton CleanSweep r= emoves unwanted programs and files that waste disk space
    • Norton Ghost protec= ts your data from computer disasters

    Sales Rank: #4
    Shipping: International/US or via in= stant download
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 217 reviews. Write a review.

    =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20

    ----Pz0qyjbABJULD0ZKsFeM-- From rtg-dir-bounces@ietf.org Wed Mar 2 08:14:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08371 for ; Wed, 2 Mar 2005 08:14:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Thg-0008VP-2F for rtg-dir-archive@ietf.org; Wed, 02 Mar 2005 08:15:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Tg3-0004Td-HO; Wed, 02 Mar 2005 08:14:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Td1-0003kX-VH; Wed, 02 Mar 2005 08:11:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07974; Wed, 2 Mar 2005 08:11:01 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Te7-0008R1-VC; Wed, 02 Mar 2005 08:12:15 -0500 Received: from 83-145-182-34.cable-modem.tkk.net.pl ([83.145.182.34]) by mx2.foretec.com with smtp (Exim 4.24) id 1D6TcG-0008JA-Ke; Wed, 02 Mar 2005 08:10:19 -0500 Received: from BDT@localhost by g2G7.int (8.11.6/8.11.6); Wed, 02 Mar 2005 11:05:02 -0200 Message-ID: From: "Jennifer Easley" To: rtg-dir@ietf.org, ldap-dir-web-archive@ietf.org, cfrg-admin@ietf.org, rserpool-admin@ietf.org Date: Wed, 02 Mar 2005 08:07:02 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NicoleHayes@saintedwardseattle.org Content-Type: multipart/mixed; boundary="--Pz0qyjbABJULD0ZKsFeM" X-Spam-Score: 0.3 (/) X-Scan-Signature: 3c84bd88e6bbcc6464f782162bb7ae94 Subject: Windows XP Pro $49.95, Office 2003 $69.95 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jennifer Easley List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 966811b049c4d80323826ee01e1b1ce9 1px ----Pz0qyjbABJULD0ZKsFeM Content-Type: text/html; Content-Transfer-Encoding: quoted-printable L
    Opt-= in Email Special Offer     unsubscribe me =
    SEARCH

    TOP 10 NEW TITLES

     ON SALE NOW!
      1 Office Pro Editi= on 2003
      2 Wind= ows XP Pro
      3 Adobe Creative S= uite Premium
      4 Systemworks Pro = 2004 Edition
      5 Flash MX 2004
      6 Corel Painter 8<= /a>
      7 Adob= e Acrobat 6.0
      8 Windows 2003 Ser= ver
      9 Alias Maya 6.0 W= avefront
      10 Adobe Premiere
      = See more by this man= ufacturer
        Microsoft
        Apple Software
      = Customers also bough= t
        these other item= s...



    		Micr= osoft Office Professional Edition *2003*
    Microsoft<= /a>
    Choose:
     
    <= /a>
    List Price: $899.00
    Price: $69.99
    You Save: $830.01 (92%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System req= uirements  |  Accessories  |&= nbsp; Other Versions

    Features:

    • Analyze and manage business inf= ormation using Access databases
    • Exchange data with other system= s using enhanced XML technology
    • Control information sharing rul= es with enhanced IRM technology
    • Easy-to-use wizards to create e= -mail newsletters and printed marketing materials
    • More than 20 preformatted busin= ess reports
    Sales Rank: #1
    Shipping: International/US or via instant downlo= ad
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 1,768 reviews. Write a = review.
    Microsoft Wind= ows XP Professional or Longhorn Edition
    Micros= oft
    Choose:
     

    =

    List Price: $279.00
    Price: $49.99
    You Save: $229.01 (85%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System= requirements  |  Accessories = ; |  Other Versions

    Features:

    • Designed for businesses of a= ll sizes
    • Manage digital pictures, mu= sic, video, DVDs, and more
    • More security with the abil= ity to encrypt files and folders
    • Built-in voice, video, and = instant messaging support
    • Integration with Windows se= rvers and management solutions

    Sales Rank: #2
    Shipping: International/US or via instant do= wnload
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 868 reviews. Write = a review.

    Adobe Crea= tive Suite Premium
    Ad= obe
    Choose:
     

    List Price: $1149.00
    Price: $99.99
    You Save: $849.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    Sy= stem requirements  |  Accessories&= nbsp; |  Other Versions

    Features: <= /font>

    • An integrated design en= vironment featuring the industry's foremost design tools
    • In-depth tips, expert t= ricks, and comprehensive design resources
    • Intuitive file finding,= smooth workflow, and common interface and toolset
    • Single installer--contr= ol what you install and when you install it
    • Cross-media publishing-= -create content for both print and the Web

    Sales Rank: #3
    Shipping: International/US or via instan= t download
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 498 reviews.     Wr= ite a review.

    Symantec SystemWorks = 2004 Professional
    Symantec
    Choose:
     

    List Price: $99.00
    Price: $29.99
    You Save: $69.01 (70%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requirements  |  Accessories = ; |  Other Versions


    Features: =

    • Norton Utilities op= timizes your PC=BFs performance and solves computer problems <= /li>
    • Norton Password Man= ager keeps your passwords secure and easy to manage
    • Norton GoBack Perso= nal Edition restores your PC after a serious problem
    • Norton CleanSweep r= emoves unwanted programs and files that waste disk space
    • Norton Ghost protec= ts your data from computer disasters

    Sales Rank: #4
    Shipping: International/US or via in= stant download
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 217 reviews. Write a review.

    =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20

    ----Pz0qyjbABJULD0ZKsFeM-- From rtg-dir-bounces@ietf.org Wed Mar 2 08:52:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11989 for ; Wed, 2 Mar 2005 08:52:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6UIH-0000uu-Oc for rtg-dir-archive@ietf.org; Wed, 02 Mar 2005 08:53:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6UFX-0001hD-5V; Wed, 02 Mar 2005 08:50:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6UFR-0001h8-CC for rtg-dir@megatron.ietf.org; Wed, 02 Mar 2005 08:50:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11498; Wed, 2 Mar 2005 08:47:18 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6UDH-0000oN-LM; Wed, 02 Mar 2005 08:48:32 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 02 Mar 2005 09:02:09 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,129,1107752400"; d="scan'208"; a="38968156:sNHT19297124" 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 j22Dl2hF006851; Wed, 2 Mar 2005 08:47:03 -0500 (EST) Received: from dhcp-64-102-48-231.cisco.com (dhcp-64-102-48-231.cisco.com [64.102.48.231]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA23309; Wed, 2 Mar 2005 08:47:04 -0500 (EST) Date: Wed, 2 Mar 2005 08:48:14 -0500 (EST) From: Russ White To: Bill Fenner In-Reply-To: <200503020155.j221tDuq032115@bright.research.att.com> Message-ID: References: <200502230132.j1N1WANu022352@bright.research.att.com> <4224E591.9050905@pi.se> <200503020155.j221tDuq032115@bright.research.att.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: Looking at the direction of the Routing Area X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Sunday night wouldn't work for me.... Maybe Tuesday night dinner, or Wednesday morning breakfast? :-) Russ On Tue, 1 Mar 2005, Bill Fenner wrote: > > Tuesday lunch is bad for a few people. My next attempt will be > Sunday dinnertime, after the reception. If we had a meeting room > and some way to get food (room service?), would people be willing > to do this? I'd like to get a feeling for how many people might > be willing to attend so that we can ask for a room. > > We've tried several times to have this kind of meeting at a bar or > restaurant but failed to manage to get everyone involved in (more than > a social) discussion; that's why I'm hoping to get a meeting room at > the hotel. > > Thanks, > Bill > __________________________________ riw@cisco.com CCIE <>< Grace Alone From rtg-dir-bounces@ietf.org Wed Mar 2 08:57:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12477 for ; Wed, 2 Mar 2005 08:57:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6UNS-00011y-3n for rtg-dir-archive@ietf.org; Wed, 02 Mar 2005 08:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ULD-0002d7-Si; Wed, 02 Mar 2005 08:56:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ULB-0002cu-HX for rtg-dir@megatron.ietf.org; Wed, 02 Mar 2005 08:56:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12340; Wed, 2 Mar 2005 08:56:38 -0500 (EST) Received: from [80.86.78.228] (helo=tbdns.testbed.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6UMJ-0000zV-Be; Wed, 02 Mar 2005 08:57:52 -0500 Received: from [172.16.2.202] (gw.imc.kth.se [193.10.152.67]) (authenticated bits=0) by tbdns.testbed.local (8.12.8/8.12.8) with ESMTP id j22DnYpt003951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Mar 2005 14:49:36 +0100 Message-ID: <4225C5EA.3040402@pi.se> Date: Wed, 02 Mar 2005 14:55:54 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200502230132.j1N1WANu022352@bright.research.att.com> <4224E591.9050905@pi.se> <200503020155.j221tDuq032115@bright.research.att.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Bill Fenner , rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: Looking at the direction of the Routing Area X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Tuesday dinner OK if there is not social, Wednesday morning breakfast won't work for me, Sunday night would /Loa Russ White wrote: > Sunday night wouldn't work for me.... Maybe Tuesday night dinner, or > Wednesday morning breakfast? > > :-) > > Russ > > On Tue, 1 Mar 2005, Bill Fenner wrote: > > >>Tuesday lunch is bad for a few people. My next attempt will be >>Sunday dinnertime, after the reception. If we had a meeting room >>and some way to get food (room service?), would people be willing >>to do this? I'd like to get a feeling for how many people might >>be willing to attend so that we can ask for a room. >> >>We've tried several times to have this kind of meeting at a bar or >>restaurant but failed to manage to get everyone involved in (more than >>a social) discussion; that's why I'm hoping to get a meeting room at >>the hotel. >> >>Thanks, >> Bill >> > > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From rtg-dir-bounces@ietf.org Wed Mar 2 09:06:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13318 for ; Wed, 2 Mar 2005 09:06:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6UVt-0001Gg-4k for rtg-dir-archive@ietf.org; Wed, 02 Mar 2005 09:07:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6UR6-0003Pm-Pn; Wed, 02 Mar 2005 09:02:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6UR5-0003Oo-P8 for rtg-dir@megatron.ietf.org; Wed, 02 Mar 2005 09:02:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12371; Wed, 2 Mar 2005 08:56:55 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6UMa-00010G-Cr; Wed, 02 Mar 2005 08:58:09 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 02 Mar 2005 09:11:49 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,129,1107752400"; d="scan'208"; a="38969202:sNHT19792516" Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j22Dui1j016833; Wed, 2 Mar 2005 08:56:44 -0500 (EST) Received: from [10.82.217.51] (rtp-vpn3-305.cisco.com [10.82.217.51]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BFS36962; Wed, 2 Mar 2005 05:56:42 -0800 (PST) Message-ID: <4225C61A.7080703@cisco.com> Date: Wed, 02 Mar 2005 08:56:42 -0500 From: Acee Lindem User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Fenner References: <200502230132.j1N1WANu022352@bright.research.att.com> <4224E591.9050905@pi.se> <200503020155.j221tDuq032115@bright.research.att.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: Looking at the direction of the Routing Area X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Russ White wrote: >Sunday night wouldn't work for me.... Maybe Tuesday night dinner, or >Wednesday morning breakfast? > > These are my preferences as well. Acee >:-) > >Russ > >On Tue, 1 Mar 2005, Bill Fenner wrote: > > > >>Tuesday lunch is bad for a few people. My next attempt will be >>Sunday dinnertime, after the reception. If we had a meeting room >>and some way to get food (room service?), would people be willing >>to do this? I'd like to get a feeling for how many people might >>be willing to attend so that we can ask for a room. >> >>We've tried several times to have this kind of meeting at a bar or >>restaurant but failed to manage to get everyone involved in (more than >>a social) discussion; that's why I'm hoping to get a meeting room at >>the hotel. >> >>Thanks, >> Bill >> >> >> > >__________________________________ >riw@cisco.com CCIE <>< Grace Alone > > > From rtg-dir-bounces@ietf.org Wed Mar 2 10:42:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24235 for ; Wed, 2 Mar 2005 10:42:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6W0p-0003Tf-Il for rtg-dir-archive@ietf.org; Wed, 02 Mar 2005 10:43:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6VzW-0003ni-7K; Wed, 02 Mar 2005 10:42:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6VzV-0003nd-O6 for rtg-dir@megatron.ietf.org; Wed, 02 Mar 2005 10:42:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24004; Wed, 2 Mar 2005 10:39:57 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6VyG-0003QK-IT; Wed, 02 Mar 2005 10:41:13 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 89EDF2D4A38; Wed, 2 Mar 2005 10:36:43 -0500 (EST) 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 83682-01-14; Wed, 2 Mar 2005 10:36:39 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id BFDEC2D4B7D; Wed, 2 Mar 2005 10:36:29 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j22FaRn10608; Wed, 2 Mar 2005 10:36:27 -0500 (EST) Date: Wed, 2 Mar 2005 10:36:27 -0500 From: Jeffrey Haas Message-ID: <20050302153627.GQ3743@nexthop.com> References: <200502230132.j1N1WANu022352@bright.research.att.com> <4224E591.9050905@pi.se> <200503020155.j221tDuq032115@bright.research.att.com> <4225C61A.7080703@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4225C61A.7080703@cisco.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Bill Fenner , rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: Looking at the direction of the Routing Area X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Wed, Mar 02, 2005 at 08:56:42AM -0500, Acee Lindem wrote: > Russ White wrote: > >Sunday night wouldn't work for me.... Maybe Tuesday night dinner, or > >Wednesday morning breakfast? > > > > > These are my preferences as well. I'll add a ditto to this with a preference towards Tuesday night dinner. > Acee -- Jeff Haas NextHop Technologies From rtg-dir-bounces@ietf.org Wed Mar 2 19:46:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18856 for ; Wed, 2 Mar 2005 19:46:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6eUw-0008B9-Dh for rtg-dir-archive@ietf.org; Wed, 02 Mar 2005 19:47:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6eTb-0007Hk-5s; Wed, 02 Mar 2005 19:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6eTa-0007Hf-DS for rtg-dir@megatron.ietf.org; Wed, 02 Mar 2005 19:46:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18754; Wed, 2 Mar 2005 19:44:52 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6eTl-00089T-VP; Wed, 02 Mar 2005 19:46:14 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 076672D49D0; Wed, 2 Mar 2005 19:44:46 -0500 (EST) 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 20819-01-17; Wed, 2 Mar 2005 19:44:43 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id DD46A2D49BB; Wed, 2 Mar 2005 19:44:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2005 19:44:43 -0500 Message-ID: Thread-Topic: Looking at the direction of the Routing Area Thread-Index: AcUeyvE43rwT1jEHRsGBE65I3RgK0wAeKtsg From: "Susan Hares" To: "Bill Fenner" , , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Subject: RE: Looking at the direction of the Routing Area X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Bill: I get into MSP airport at 6:15 pm. I will not be at the=20 Hotel until 7:30pm. I will be glad to join you later. Sue -----Original Message----- From: Bill Fenner [mailto:fenner@research.att.com]=20 Sent: Tuesday, March 01, 2005 8:55 PM To: rtg-chairs@ietf.org; rtg-dir@ietf.org Subject: Re: Looking at the direction of the Routing Area Tuesday lunch is bad for a few people. My next attempt will be Sunday dinnertime, after the reception. If we had a meeting room and some way to get food (room service?), would people be willing to do this? I'd like to get a feeling for how many people might be willing to attend so that we can ask for a room. We've tried several times to have this kind of meeting at a bar or restaurant but failed to manage to get everyone involved in (more than a social) discussion; that's why I'm hoping to get a meeting room at the hotel. Thanks, Bill From rtg-dir-bounces@ietf.org Thu Mar 3 11:15:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11662 for ; Thu, 3 Mar 2005 11:15:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6t0h-0004Sa-Fe for rtg-dir-archive@ietf.org; Thu, 03 Mar 2005 11:17:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6syZ-0003Qj-01; Thu, 03 Mar 2005 11:14:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6syX-0003QS-3c for rtg-dir@megatron.ietf.org; Thu, 03 Mar 2005 11:14:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11552 for ; Thu, 3 Mar 2005 11:14:54 -0500 (EST) Message-Id: <200503031614.LAA11552@ietf.org> Received: from 220.red-80-39-52.pooles.rima-tde.net ([80.39.52.220] helo=gabbertas.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6szt-0004R6-Ia for rtg-dir@ietf.org; Thu, 03 Mar 2005 11:16:23 -0500 From: "Jamison Reiter" To: "Coreen Higginbotham" Date: Thu, 3 Mar 2005 11:42:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C51E97.422738E9" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: Re: Drugss-JFM X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C51E97.422738E9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_004D_01C51E97.422738E9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Visit Our PharmMail=20 SH0P.
     
    SP  OF  Vi ra $200(120p.) Ci is $300(150p.) Lev ra $300(50p.)
    ECIAL FER: ag al it
    And Many Other!
     
    With each purchase you = get:
  • 20%Off All Re-0rders = with us
  • Home delivery
  • Total confidentiality
  • FDAApproved
  • Highest Quality
    •  
    Have a nice = day.
    ------=_NextPart_000_004D_01C51E97.422738E9-- From rtg-dir-bounces@ietf.org Fri Mar 4 18:34:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19399 for ; Fri, 4 Mar 2005 18:34:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7MLL-0001Od-B5 for rtg-dir-archive@ietf.org; Fri, 04 Mar 2005 18:36:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7MIk-0002XB-81; Fri, 04 Mar 2005 18:33:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7MIi-0002Wj-Ec for rtg-dir@megatron.ietf.org; Fri, 04 Mar 2005 18:33:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18996; Fri, 4 Mar 2005 18:33:03 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7MJk-0001Hs-4B; Fri, 04 Mar 2005 18:34:49 -0500 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 510231974F9; Fri, 4 Mar 2005 18:14:50 -0500 (EST) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j24NWqoH018960; Fri, 4 Mar 2005 15:32:52 -0800 Message-Id: <200503042332.j24NWqoH018960@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-chairs@ietf.org, rtg-dir@ietf.org References: <200502230132.j1N1WANu022352@bright.research.att.com> <4224E591.9050905@pi.se> <200503020155.j221tDuq032115@bright.research.att.com> <4225C61A.7080703@cisco.com> Date: Fri, 4 Mar 2005 15:32:52 -0800 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: Re: Looking at the direction of the Routing Area X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Although there was a lot of interest, I haven't been able to manage to schedule something that everyone can make. I think we should plan on doing this in Paris, with much more lead time so ours can be the one that everyone has to schedule around ;-) Bill From rtg-dir-bounces@ietf.org Fri Mar 4 18:37:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19805 for ; Fri, 4 Mar 2005 18:37:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7MO6-0001Wp-Ss for rtg-dir-archive@ietf.org; Fri, 04 Mar 2005 18:39:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7MM8-0004Pc-JQ; Fri, 04 Mar 2005 18:37:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7MM6-0004PX-Dv for rtg-dir@megatron.ietf.org; Fri, 04 Mar 2005 18:37:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19748; Fri, 4 Mar 2005 18:36:19 -0500 (EST) From: kireeti@juniper.net Received: from natint3.juniper.net ([66.129.224.36] helo=kummer.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7MMr-0001UC-E8; Fri, 04 Mar 2005 18:38:02 -0500 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j24Na8Xg074103; Fri, 4 Mar 2005 15:36:08 -0800 (PST) (envelope-from kireeti@kummer.juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) id j24Na8bX074102; Fri, 4 Mar 2005 15:36:08 -0800 (PST) Date: Fri, 4 Mar 2005 15:36:08 -0800 (PST) Message-Id: <200503042336.j24Na8bX074102@kummer.juniper.net> To: fenner@research.att.com, rtg-chairs@ietf.org, rtg-dir@ietf.org In-Reply-To: <200503042332.j24NWqoH018960@bright.research.att.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: Re: Looking at the direction of the Routing Area X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Scheduling around Paris itself may be, well, challenging :-) Kireeti. From rtg-dir-bounces@ietf.org Fri Mar 4 20:59:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02369 for ; Fri, 4 Mar 2005 20:59:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7ObW-0004cR-CE for rtg-dir-archive@ietf.org; Fri, 04 Mar 2005 21:01:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7OYH-0002bw-EC; Fri, 04 Mar 2005 20:57:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7OYF-0002br-EZ for rtg-dir@megatron.ietf.org; Fri, 04 Mar 2005 20:57:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02274; Fri, 4 Mar 2005 20:57:19 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7OZK-0004Zm-CT; Fri, 04 Mar 2005 20:59:05 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D7OXb-0009ja-8t; Sat, 05 Mar 2005 01:57:16 +0000 Date: Fri, 4 Mar 2005 17:56:58 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <553587422.20050304175658@psg.com> To: Bill Fenner In-Reply-To: <200503042332.j24NWqoH018960@bright.research.att.com> References: <200502230132.j1N1WANu022352@bright.research.att.com> <4224E591.9050905@pi.se> <200503020155.j221tDuq032115@bright.research.att.com> <4225C61A.7080703@cisco.com> <200503042332.j24NWqoH018960@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: Looking at the direction of the Routing Area X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit That said, the good-n-old IETF method of having a discussion in a bar can be used. An ad-hoc bar BOF on Sunday night is hereby scheduled :) Also, we will bring the topic of a bigger picture to the RTGAREA meeting on Monday. If you'd like to give a small talk on this--let us know. -- Alex http://www.psg.com/~zinin Friday, March 4, 2005, 3:32:52 PM, Bill Fenner wrote: > Although there was a lot of interest, I haven't been able to manage > to schedule something that everyone can make. I think we should > plan on doing this in Paris, with much more lead time so ours can > be the one that everyone has to schedule around ;-) > Bill From rtg-dir-bounces@ietf.org Sun Mar 6 15:38:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23514 for ; Sun, 6 Mar 2005 15:38:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D82Y7-0004x2-IS for rtg-dir-archive@ietf.org; Sun, 06 Mar 2005 15:40:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D82Up-0000NK-Bs; Sun, 06 Mar 2005 15:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D82Uo-0000NA-1E for rtg-dir@megatron.ietf.org; Sun, 06 Mar 2005 15:37:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23393 for ; Sun, 6 Mar 2005 15:36:58 -0500 (EST) Message-Id: <200503062036.PAA23393@ietf.org> Received: from [61.85.62.29] (helo=jobdragon.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D82Wn-0004uk-P1 for rtg-dir@ietf.org; Sun, 06 Mar 2005 15:39:08 -0500 From: "Nobu Caldwell" To: "Nemesis Casillas" Date: Sun, 6 Mar 2005 15:39:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C52252.422B774C" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: Re: IBN-66-Pharamcy X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C52252.422B774C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, and rather shambling, but spry enough withal. He was dressed in value to him. Steger called in every day for two or three weeks, two the house seemed glum--the meals less appetizing. When she DEAR SIR--Under the existing circumstances you will consider way he handled their accounts. There was a sense of security in down into Broadway; an oblong table, heavy, brown, smoothly polis Cooke, a rising banking personality, was a personal friend of his a matter of fact, it was written by a girl, a member of St. Timot drop in and talk with you some time when I'm down this way. We'l for her relatives, and the Semples had been alienated by her seco Have a nice day. ------=_NextPart_000_001D_01C52252.422B774C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello , = Visit our = Pharm-Mail=20 SH0P and save up to 80%.
     
    Vi ra Am en Ci is Le tra,  And
    ag bi al vi  many other!
     
    Have a nice = day.
    ------=_NextPart_000_001D_01C52252.422B774C-- From rtg-dir-bounces@ietf.org Mon Mar 7 18:00:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13844 for ; Mon, 7 Mar 2005 18:00:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8RFW-0000oR-Ic for rtg-dir-archive@ietf.org; Mon, 07 Mar 2005 18:02:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8RCu-0001NI-MX; Mon, 07 Mar 2005 18:00:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8RCt-0001Mx-Mt for rtg-dir@megatron.ietf.org; Mon, 07 Mar 2005 18:00:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13777 for ; Mon, 7 Mar 2005 18:00:07 -0500 (EST) Message-Id: <200503072300.SAA13777@ietf.org> Received: from [218.55.150.54] (helo=jantzsupply.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D8RF8-0000nn-5b for rtg-dir@ietf.org; Mon, 07 Mar 2005 18:02:31 -0500 From: "Vlasis Gipson" To: "Conchobhar Welsh" Date: Mon, 7 Mar 2005 17:13:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C52252.422CEA5C" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: Re: 66-WIA-Phharmacy X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.2 (++++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C52252.422CEA5C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, marvelous things, and their activities and the rumors concerning by all important financiers and brokers had been sent to the Gove disposition--but the sheer, quiet, determined force of this young as an afterthought, that this man has been particularly interest Harper Steger had drawn up documents which named Jay Cooke & Co., just have to fight it out the best way I can. Good day. as we once were, is apt to make any woman pause, even in the face which he had stammered through platitudinous declarations that th and Simpson, was in the shape of contracts--fat ones--street-pavi Have a nice day. ------=_NextPart_000_001D_01C52252.422CEA5C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello , = Visit our = Pharm-Mail=20 SH0P and save up to 80%.
     
    Vi ra Am en Ci is Le tra,  And
    ag bi al vi  many other!
     
    Have a nice = day.
    ------=_NextPart_000_001D_01C52252.422CEA5C-- From rtg-dir-bounces@ietf.org Tue Mar 8 00:48:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24887 for ; Tue, 8 Mar 2005 00:48:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8XcP-000378-Bf for rtg-dir-archive@ietf.org; Tue, 08 Mar 2005 00:50:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Xa2-0004o1-6Y; Tue, 08 Mar 2005 00:48:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Xa0-0004nw-Kx for rtg-dir@megatron.ietf.org; Tue, 08 Mar 2005 00:48:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24881 for ; Tue, 8 Mar 2005 00:48:24 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8XcK-00036n-7W for rtg-dir@ietf.org; Tue, 08 Mar 2005 00:50:53 -0500 Received: from 69-200-240-196.nyc.rr.com ([69.200.240.196]) by mx2.foretec.com with smtp (Exim 4.24) id 1D8XZq-0002Kp-56 for rtg-dir@ietf.org; Tue, 08 Mar 2005 00:48:18 -0500 Received: from hB1u@localhost by EBT.int (8.11.6/8.11.6); Tue, 08 Mar 2005 03:47:24 -0200 Message-ID: From: "Martha Fletcher" To: rtg-dir@ietf.org Date: Tue, 08 Mar 2005 10:48:24 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: DebbieStevenson@northeastacademycharter.com Content-Type: multipart/mixed; boundary="--waE6DolBh1UNhQJt" X-Spam-Score: 1.4 (+) X-Scan-Signature: 9d5866e4c615ceea0db8f42c46495d22 Cc: tvvgmisis-wg-admin@ietf.org Subject: Winter Special - Buy 1 and Get 1! X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martha Fletcher List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: 3c84bd88e6bbcc6464f782162bb7ae94 av2e ----waE6DolBh1UNhQJt Content-Type: text/html; Content-Transfer-Encoding: quoted-printable y
    Opt-= in Email Special Offer     unsubscribe me
    SEARCH

    TOP 10 NEW TITLES

     ON SALE NOW!
      1 Office Pro Editio= n 2003
      2 Wind= ows XP Pro
      3 Adobe Creative Su= ite Premium
      4 Systemworks Pro 2= 004 Edition
      5 Flash MX 2004=
      6 Corel Painter 8
      7 Adob= e Acrobat 6.0
      8 Windows 2003 Serv= er
      9 Alias Maya 6.0 Wa= vefront
      10 Adobe Premiere
      = See more by this man= ufacturer
        Microsoft
        Apple Software
      = Customers also bough= t
        these other items= ..



    		Micr= osoft Office Professional Edition *2003*
    Microsoft
    Choose:
     
    <= /a>
    List Price: $899.00
    Price: $69.99
    You Save: $830.01 (92%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requ= irements  |  Accessories  |&n= bsp; Other Versions

    Features:

    • Analyze and manage business inf= ormation using Access databases
    • Exchange data with other system= s using enhanced XML technology
    • Control information sharing rul= es with enhanced IRM technology
    • Easy-to-use wizards to create e= -mail newsletters and printed marketing materials
    • More than 20 preformatted busin= ess reports
    Sales Rank: #1
    Shipping: International/US or via instant downlo= ad
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 1,768 reviews. Write a r= eview.
    Microsoft Wind= ows XP Professional or Longhorn Edition
    Microso= ft
    Choose:
     

    =

    List Price: $279.00
    Price: $49.99
    You Save: $229.01 (85%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System = requirements  |  Accessories = |  Other Versions

    Features:

    • Designed for businesses of a= ll sizes
    • Manage digital pictures, mu= sic, video, DVDs, and more
    • More security with the abil= ity to encrypt files and folders
    • Built-in voice, video, and = instant messaging support
    • Integration with Windows se= rvers and management solutions

    Sales Rank: #2
    Shipping: International/US or via instant do= wnload
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 868 reviews. Write a= review.

    Adobe Crea= tive Suite Premium
    Ado= be
    Choose:
     =

    List Price: $1149.00
    Price: $99.99
    You Save: $849.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    Sys= tem requirements  |  Accessories&n= bsp; |  Other Versions

    Features: <= /font>

    • An integrated design en= vironment featuring the industry's foremost design tools
    • In-depth tips, expert t= ricks, and comprehensive design resources
    • Intuitive file finding,= smooth workflow, and common interface and toolset
    • Single installer--contr= ol what you install and when you install it
    • Cross-media publishing-= -create content for both print and the Web

    Sales Rank: #3
    Shipping: International/US or via instan= t download
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 498 reviews.     Wri= te a review.

    Symantec SystemWorks = 2004 Professional
    Symantec
    Choose:
     

    List Price: $99.00
    Price: $29.99
    You Save: $69.01 (70%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requirements  |  Accessories = |  Other Versions


    Features: =

    • Norton Utilities op= timizes your PC=BFs performance and solves computer problems <= /li>
    • Norton Password Man= ager keeps your passwords secure and easy to manage
    • Norton GoBack Perso= nal Edition restores your PC after a serious problem
    • Norton CleanSweep r= emoves unwanted programs and files that waste disk space
    • Norton Ghost protec= ts your data from computer disasters

    Sales Rank: #4
    Shipping: International/US or via in= stant download
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 217 reviews. Write a review.

    =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20

    ----waE6DolBh1UNhQJt-- From rtg-dir-bounces@ietf.org Tue Mar 8 22:09:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19475 for ; Tue, 8 Mar 2005 22:09:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8rcA-0008G8-3w for rtg-dir-archive@ietf.org; Tue, 08 Mar 2005 22:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8rYV-0004Kh-Vp; Tue, 08 Mar 2005 22:08:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8rYV-0004Kb-4l for rtg-dir@megatron.ietf.org; Tue, 08 Mar 2005 22:08:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18659 for ; Tue, 8 Mar 2005 22:08:09 -0500 (EST) Message-Id: <200503090308.WAA18659@ietf.org> Received: from [211.221.55.6] (helo=joesdivingbali.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D8raw-0008Eu-V9 for rtg-dir@ietf.org; Tue, 08 Mar 2005 22:10:47 -0500 From: "Taras Osborne" To: "Maud Bates" Date: Tue, 8 Mar 2005 22:26:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C523D3.422E7605" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 1.1 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: Re: 25-9-Druggs X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C523D3.422E7605 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Unquestionably he had never loved as she had. street-railway stocks, and others. Of all those to whom he appea He paused and gazed at the jury, adjusting his sleeves as he did Oh, I've heard, he smiled. I've seen you. Do you like licori new to the political world of Philadelphia, was not so familiar think perhaps you had better leave Philadelphia, Frank? You needn Aileen lured away from home--to where--to what? Butler could scar Semple. Occasionally also he stopped in the Chestnut Street stor ventured to repeat it in Pethick's presence. Have a nice day. ------=_NextPart_000_000D_01C523D3.422E7605 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello , = Please = Visit our Great Pharm--Mail SH0P=20 and Save up T0 75%.
     
    Vi ra Am en Ci is Le tra,  And
    ag bi al vi  many other!
     
    Just try us and = you will NOT be disappointed :)
     
    Have a nice = day.
    ------=_NextPart_000_000D_01C523D3.422E7605-- From rtg-dir-bounces@ietf.org Fri Mar 11 01:50:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26271 for ; Fri, 11 Mar 2005 01:50:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9e23-0001Ts-0d for rtg-dir-archive@ietf.org; Fri, 11 Mar 2005 01:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9dyv-0001mU-Km; Fri, 11 Mar 2005 01:50:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9dyt-0001l2-Fb for rtg-dir@megatron.ietf.org; Fri, 11 Mar 2005 01:50:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26246 for ; Fri, 11 Mar 2005 01:50:37 -0500 (EST) Message-Id: <200503110650.BAA26246@ietf.org> Received: from 61-30-0-76.dynamic.tfn.net.tw ([61.30.0.76] helo=jahoopa.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D9e1j-0001TR-AD for rtg-dir@ietf.org; Fri, 11 Mar 2005 01:53:41 -0500 From: "Marianna Donahue" To: "Shem Compton" Date: Fri, 11 Mar 2005 01:06:19 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C5259B.42314D0C" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 4.0 (++++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: Re: /82-73/Medicationns X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.8 (++++) X-Scan-Signature: 25620135586de10c627e3628c432b04a This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C5259B.42314D0C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, in a frou-frou of silk. Her splendid hair was drawn up from the A bull, he learned, was one who bought in anticipation of a hig Chapter XXXV out into Third Street, where a hurrying of brokers, messengers, I want to keep up a relationship, however it may look to the publ happy a denouement. Life cannot be put into any mold, and the personally were under complete surveillance. It took six men to be wrong, but perhaps he did love Aileen; and it was possible tha listen to me. I've been loyal to you, haven't I? You've made mon in the little garden allotted him in utter silence and loneliness Have a nice day. ------=_NextPart_000_0008_01C5259B.42314D0C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello , = Visit = Our Pharmma-Mail-SHOP=20 and Save 80%.
     
    Vi ra Am en Ci is Le tra,  And
    ag bi al vi  many other!
     
    Just try us and = you will NOT be disappointed :)
     
    Have a nice = day.
    ------=_NextPart_000_0008_01C5259B.42314D0C-- From rtg-dir-bounces@ietf.org Mon Mar 14 07:00:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20018 for ; Mon, 14 Mar 2005 07:00:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAoJD-00064w-KQ for rtg-dir-archive@ietf.org; Mon, 14 Mar 2005 07:04:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAoF5-0007Ug-SJ; Mon, 14 Mar 2005 07:00:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAoF5-0007UY-7t for rtg-dir@megatron.ietf.org; Mon, 14 Mar 2005 07:00:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19967 for ; Mon, 14 Mar 2005 07:00:12 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAoIh-00063e-Dd for rtg-dir@ietf.org; Mon, 14 Mar 2005 07:03:59 -0500 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-green.research.att.com (Postfix) with ESMTP id C1A74A7BCF for ; Mon, 14 Mar 2005 07:00:04 -0500 (EST) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j2EC02eA021156 for ; Mon, 14 Mar 2005 04:00:03 -0800 (PST) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j2EC0291021155 for rtg-dir@ietf.org; Mon, 14 Mar 2005 04:00:02 -0800 (PST) (envelope-from fenner) Date: Mon, 14 Mar 2005 04:00:02 -0800 (PST) Message-Id: <200503141200.j2EC0291021155@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: IESG agenda for 2005-03-17 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-03-17). Updated 2:27:28 EDT, March 14, 2005 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date TSV Registration of the text/red MIME Sub-Type (Proposed Standard) - 1 of 3 draft-ietf-avt-text-red-05.txt [Open Web Ballot] Token: Allison Mankin Encoding of Attributes for Multiprotocol Label RTG Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE (Proposed Standard) - 2 of 3 draft-ietf-mpls-rsvpte-attributes-04.txt [Open Web Ballot] Token: Alex Zinin SEC The Use of RSA Signatures within ESP and AH (Proposed Standard) - 3 of 3 draft-ietf-msec-ipsec-signatures-04.txt [Open Web Ballot] Token: Russ Housley 2.1.2 Returning Item Area Date Prioritized Treatment of Specific OSPF RTG Packets and Congestion Avoidance (BCP) - 1 of 1 draft-ietf-ospf-scalability-09.txt [Open Web Ballot] Note: Checking if -09 fixes concerns Token: Bill Fenner 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item NONE 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item NONE 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item NONE 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review Area Date INT Mar 10 IP over Resilient Packet Rings (iporpr) - 1 of 1 Token: Thomas 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issues From rtg-dir-bounces@ietf.org Wed Mar 16 23:00:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05648 for ; Wed, 16 Mar 2005 23:00:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBmFD-0007ig-5q for rtg-dir-archive@ietf.org; Wed, 16 Mar 2005 23:04:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBmAS-0004HT-T8; Wed, 16 Mar 2005 22:59:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBmAQ-0004HI-6K; Wed, 16 Mar 2005 22:59:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05535; Wed, 16 Mar 2005 22:59:23 -0500 (EST) Received: from [24.48.163.173] (helo=24-48-163-173.sbtnvt.adelphia.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DBmEU-0007bA-Bd; Wed, 16 Mar 2005 23:03:44 -0500 Received: from EYHo@localhost by 7Lvv.int (8.11.6/8.11.6); Thu, 17 Mar 2005 01:56:15 -0200 Message-ID: From: "Julia Mcmullen" To: rtg-dir@ietf.org, rtgwg@ietf.org Date: Thu, 17 Mar 2005 01:51:15 -0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: FranReiner@amatuersmut.com Content-Type: multipart/mixed; boundary="--qrPSpZUQNtnwqtt6Cr" X-Spam-Score: 2.9 (++) X-Scan-Signature: c5b976cb26c967a52d72d6069c7fc54c Subject: Windows XP Pro $49.95, Office 2003 $69.95 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Julia Mcmullen List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: efecd979fb9d15792ac142aa0178058d SW37 ----qrPSpZUQNtnwqtt6Cr Content-Type: text/html; Content-Transfer-Encoding: quoted-printable T
    Opt-= in Email Special Offer     unsubscribe me
    SEARCH

    TOP 10 NEW TITLES

     ON SALE NOW!
      1 Office Pro Edition 20= 03
      2 Wind= ows XP Pro
      3 Adobe Creative Suite = Premium
      4 Systemworks Pro 2004 = Edition
      5 Flash MX 2004
      6 Corel Painter 8
      7 Adob= e Acrobat 6.0
      8 Windows 2003 Server
      9 Alias Maya 6.0 Wavefr= ont
      10 Adobe Premiere
      = See more by this man= ufacturer
        Microsoft<= /td>
        Ap= ple Software
      = Customers also bough= t
        these other items...<= /a>



    		Micr= osoft Office Professional Edition *2003*
    Microsoft
    Choose:
     
    <= /a>
    List Price: $899.00
    Price: $69.99
    You Save: $830.01 (92%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requirem= ents  |  Accessories  | = Other Versions

    Features:

    • Analyze and manage business inf= ormation using Access databases
    • Exchange data with other system= s using enhanced XML technology
    • Control information sharing rul= es with enhanced IRM technology
    • Easy-to-use wizards to create e= -mail newsletters and printed marketing materials
    • More than 20 preformatted busin= ess reports
    Sales Rank: #1
    Shipping: International/US or via instant downlo= ad
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 1,768 reviews. Write a revie= w.
    Microsoft Wind= ows XP Professional or Longhorn Edition
    Microsoft
    Choose:
     

    =

    List Price: $279.00
    Price: $49.99
    You Save: $229.01 (85%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requ= irements  |  Accessories  |&n= bsp; Other Versions

    Features:

    • Designed for businesses of a= ll sizes
    • Manage digital pictures, mu= sic, video, DVDs, and more
    • More security with the abil= ity to encrypt files and folders
    • Built-in voice, video, and = instant messaging support
    • Integration with Windows se= rvers and management solutions

    Sales Rank: #2
    Shipping: International/US or via instant do= wnload
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 868 reviews. Write a rev= iew.

    Adobe Crea= tive Suite Premium
    Adobe
    Choose:
     

    List Price: $1149.00
    Price: $99.99
    You Save: $849.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System = requirements  |  Accessories = |  Other Versions

    Features: <= /font>

    • An integrated design en= vironment featuring the industry's foremost design tools
    • In-depth tips, expert t= ricks, and comprehensive design resources
    • Intuitive file finding,= smooth workflow, and common interface and toolset
    • Single installer--contr= ol what you install and when you install it
    • Cross-media publishing-= -create content for both print and the Web

    Sales Rank: #3
    Shipping: International/US or via instan= t download
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 498 reviews. Write a= review.

    Symantec SystemWorks = 2004 Professional
    Sym= antec
    Choose:
     =

    List Price: $99.00
    Price: $29.99
    You Save: $69.01 (70%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    Sys= tem requirements  |  Accessories  |&n= bsp; Other Versions


    Features: =

    • Norton Utilities op= timizes your PC=BFs performance and solves computer problems <= /li>
    • Norton Password Man= ager keeps your passwords secure and easy to manage
    • Norton GoBack Perso= nal Edition restores your PC after a serious problem
    • Norton CleanSweep r= emoves unwanted programs and files that waste disk space
    • Norton Ghost protec= ts your data from computer disasters

    Sales Rank: #4
    Shipping: International/US or via in= stant download
    Date Coupon Expires: February 28th, 2005
    Average Customer Review: 3D"5 Based on 217 reviews. Wri= te a review.

    =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20

    ----qrPSpZUQNtnwqtt6Cr-- From rtg-dir-bounces@ietf.org Thu Mar 17 14:35:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11134 for ; Thu, 17 Mar 2005 14:35:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC0qX-00041D-0t for rtg-dir-archive@ietf.org; Thu, 17 Mar 2005 14:39:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC0lq-0008Kc-7k; Thu, 17 Mar 2005 14:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC0lo-0008K6-Uh for rtg-dir@megatron.ietf.org; Thu, 17 Mar 2005 14:35:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11045 for ; Thu, 17 Mar 2005 14:34:58 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC0q7-000403-9G for rtg-dir@ietf.org; Thu, 17 Mar 2005 14:39:27 -0500 Received: from c5147440a.cable.wanadoo.nl ([81.71.68.10]) by mx2.foretec.com with smtp (Exim 4.24) id 1DC0lm-0000NO-Ix for rtg-dir@ietf.org; Thu, 17 Mar 2005 14:34:59 -0500 Message-ID: From: "Vanessa J. Smith" To: rtg-dir@ietf.org Date: Thu, 17 Mar 2005 08:04:07 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_1D669FDC.BDA8D80A" 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-Score: 3.8 (+++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: Microsoft Office 2003 - very low price X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.8 (+++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. ------=_NextPart_000_0000_1D669FDC.BDA8D80A Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_E028348A.BAE23B2E" ------=_NextPart_001_0001_E028348A.BAE23B2E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get access to all the software imaginable for extremely low prices! We sell software 2-6 times cheaper than retail price. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... To visit us go: http://www.protosoft.biz Best, Vanessa Smith _____________________________________________________ To change your mail details, go: http://www.protosoft.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_E028348A.BAE23B2E Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
    Get all the software you ever imagined for less!
    Our software is 2-10 times cheaper than sold by our competitors.

    Just a few examples:
    $79.95 Windows XP Professional (Including: Service Pack 2)
    $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
    $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
    $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
    $79.95 Adobe Acrobat 6.0 Professional
    $59.95 Corel Draw Graphics Suite 11

    Special Offers:
    $89.95 Windows XP Professional + Office XP Professional
    $149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS
    $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

    All main products from Microsoft, Adobe, Macromedia, Corel, etc.
    And lots more... To view full list of products go:

    http://www.protosoft.biz

    Best regards,
    Vanessa J. Smith


    _____________________________________________________
    To change your mail preferences, go: http://www.protosoft.biz/uns.htm
    _____________________________________________________

    ------=_NextPart_001_0001_E028348A.BAE23B2E-- ------=_NextPart_000_0000_1D669FDC.BDA8D80A-- From rtg-dir-bounces@ietf.org Fri Mar 18 07:33:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02390 for ; Fri, 18 Mar 2005 07:33:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCGjo-00033F-Qn for rtg-dir-archive@ietf.org; Fri, 18 Mar 2005 07:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCGcs-000390-R4; Fri, 18 Mar 2005 07:30:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCGcq-00038p-QH for rtg-dir@megatron.ietf.org; Fri, 18 Mar 2005 07:30:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02275 for ; Fri, 18 Mar 2005 07:30:46 -0500 (EST) Received: from lns-p19-8-idf-82-65-68-10.adsl.proxad.net ([82.65.68.10]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DCGhG-0002yH-1A for rtg-dir@ietf.org; Fri, 18 Mar 2005 07:35:23 -0500 Message-ID: <5cf101c52bb3$2bf5fc14$4995f9d1@abilene.com> From: "Vanessa J. Smith" To: rtg-dir@ietf.org Date: Fri, 18 Mar 2005 12:07:28 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_15331948.D646AD1B" 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-Score: 3.5 (+++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: Windows XP - wholesale price X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. ------=_NextPart_000_0000_15331948.D646AD1B Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_A19C29BF.8BD7D10A" ------=_NextPart_001_0001_A19C29BF.8BD7D10A Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Access all the popular software you ever imagined for wholesale prices! Our software is 2-10 times cheaper than sold by our competitors. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... Go visit us at: http://www.protosoft.biz Best regards, Vanessa Smith _____________________________________________________ To change your mail preferences, go here: http://www.protosoft.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_A19C29BF.8BD7D10A Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
    Get access to all the popular software you ever imagined for prices substantially lower than in stores!
    Our software is 2-10 times cheaper than sold by our competitors.

    A few examples:
    $79.95 Windows XP Professional (Including: Service Pack 2)
    $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
    $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
    $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
    $79.95 Adobe Acrobat 6.0 Professional
    $59.95 Corel Draw Graphics Suite 11

    Special Offers:
    $89.95 Windows XP Professional + Office XP Professional
    $149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS
    $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

    All main products from Microsoft, Adobe, Macromedia, Corel, etc.
    And many more... Visit us at:

    http://www.protosoft.biz

    Sincerely,
    Vanessa J. Smith


    _____________________________________________________
    To be taken off future campaigns, go here: http://www.protosoft.biz/uns.htm
    _____________________________________________________

    ------=_NextPart_001_0001_A19C29BF.8BD7D10A-- ------=_NextPart_000_0000_15331948.D646AD1B-- From rtg-dir-bounces@ietf.org Fri Mar 18 09:26:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11529 for ; Fri, 18 Mar 2005 09:26:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCIVY-0007WV-Pf for rtg-dir-archive@ietf.org; Fri, 18 Mar 2005 09:31:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCIPo-00060X-Vr; Fri, 18 Mar 2005 09:25:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCIPn-00060M-RJ; Fri, 18 Mar 2005 09:25:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11404; Fri, 18 Mar 2005 09:25:25 -0500 (EST) Received: from aputeaux-154-1-47-131.w83-199.abo.wanadoo.fr ([83.199.118.131]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DCITa-0007KQ-6y; Fri, 18 Mar 2005 09:30:04 -0500 Received: from lWp@localhost by 2cX.int (8.11.6/8.11.6); Fri, 18 Mar 2005 15:18:22 +0100 Message-ID: From: "Sarah Penn" To: rtg-dir@ietf.org, rtgwg@ietf.org Date: Fri, 18 Mar 2005 15:25:22 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: VickiRichards@threebond.co.uk Content-Type: multipart/mixed; boundary="--SJTdK1tEkMfI98d2Sd92" X-Spam-Score: 1.2 (+) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 Subject: Windows XP Pro $49.95, Office 2003 $69.95 Macromedia X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sarah Penn List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 7191030d885084e634ab0f488bcd9d53 6Rv ----SJTdK1tEkMfI98d2Sd92 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 4598639
    Browse Search Shop My eSoft Community
    Back to Software = Overview

    Home > All Categories > Computers > Software > Operating Systems > = Windows
    All Items
    Auctions
    Bu= y It Now
        Refine Search=
     Top Sellers
    1      Office 2003 Pro     
    6   Macromedia
         Dream Weaver
         MX 2004
    7       CorelDraw
         Graphics Suite 12.0
    11 Alias Wavefront 6.0
    13     Adobe Encore DVD

     

     

    Featured It= em

    		 PRlCE Bids Time Left

    3D"New"  Microsoft= Windows XP PRO
    -Current Edition-

     3D"Gift from Our eStore

    $49.95 USD

    2
    3D"Gift

    = 0h 12m

    Nevv It= ems

    		 PRlCE Bids Time Left

    3D"New"  Micro= soft Office 2003 PRO or
    Microsoft Office XP PRO

     3D"Gift from Our eStore

    $49.95 USD

    7
    3D"Gift

    		 0h 16m
    <= /td>

    3D"New"  Adobe= Photoshop CS 8.0 or Adobe Acrobat PRO 7.0

     3D"Gift from Our eStore

    $59.95 USD

    		 9 3D"Gift 0h 18m

    3D"New"  Macro= media FlashMX Pro 2004 or Macromedia Dreamweaver MX Pro 2004

     3D"Gift from Our eStore

    		 $39.95 USD 1 3D"Gift 0h 15m
    ----SJTdK1tEkMfI98d2Sd92-- From rtg-dir-bounces@ietf.org Fri Mar 18 14:28:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13999 for ; Fri, 18 Mar 2005 14:28:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCNE3-0003OU-Om for rtg-dir-archive@ietf.org; Fri, 18 Mar 2005 14:33:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCN9N-0005qC-8q; Fri, 18 Mar 2005 14:28:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCN9M-0005pz-0Z; Fri, 18 Mar 2005 14:28:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13975; Fri, 18 Mar 2005 14:28:45 -0500 (EST) Received: from [222.234.103.7] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DCNDq-0003Go-Aj; Fri, 18 Mar 2005 14:33:27 -0500 Received: from gambrirgeidw1.inbox.ru (145.116.121.56) by pei1-yfm0.inbox.ru with Microsoft SMTPSVC(5.0.2195.6824); Fri, 18 Mar 2005 23:20:13 +0400 Received: from Pattiv18wvs4di56ozp (208.224.103.4) by qztp385.inbox.ru (InterMail vM.5.01.06.05 257-576-417-597-995-96128971) with SMTP id <61607238896209.ZWM839.kkjja9857.inbox.ru@veloursme057s14nxq73ynd> for ; Fri, 18 Mar 2005 22:18:13 +0300 Message-ID: <9266c77g3880$23182$jl38vij021@Pattikhv317xjs9vm4fe> From: "Mitchell Ortega" To: Date: Fri, 18 Mar 2005 21:23:13 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--akbrlbny88303716450wpefhkegcb" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: Did you know? You can live and work in the USA! X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 ----akbrlbny88303716450wpefhkegcb Content-Type: text/plain; X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA13975 Content-Transfer-Encoding: quoted-printable Hi there! You know those one-in-a-lifetime opportunities that come and you don't ev= en recognize them? Well, listen to this: About six months ago I came across this wonderful website:=20 http://www.gc-nine.info?aid=3D624=20 I didn't believe at first that it could be true. Winning a green card for= a $40 investment?!=20 I took my chance on it, and guess what!=20 IT WORKED!=20 I now have a green card!=20 All I did was Sign in all of my personal details =96 AND THAT'S IT! These wonderful people did everything for me.=20 They took me step by step through the application process,=20 making sure nothing is missing and that=20 my application remains mistake-free. If you have any questions regarding the Lottery please contact us: http://www.gc-nine.info?aid=3D624 Best regards,=20 Patti Black Green Card Lottery Services=20 http://www.gc-nine.info?aid=3D624 No more http://www.gc-nine.info/discon=20 ------------------------------------- %SRY_RND ----akbrlbny88303716450wpefhkegcb-- From rtg-dir-bounces@ietf.org Sat Mar 19 08:21:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19373 for ; Sat, 19 Mar 2005 08:21:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCdy6-0007JD-2q for rtg-dir-archive@ietf.org; Sat, 19 Mar 2005 08:26:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCds5-0005eF-FW; Sat, 19 Mar 2005 08:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCds3-0005az-J9; Sat, 19 Mar 2005 08:20:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19272; Sat, 19 Mar 2005 08:20:02 -0500 (EST) Received: from yyydcccxliv.dsl.saunalahti.fi ([85.76.2.145]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DCdwg-0007HD-2M; Sat, 19 Mar 2005 08:24:52 -0500 Received: from seoul-dns.moose-mail.com (212.246.104.29) by ty747-rc56.moose-mail.com with Microsoft SMTPSVC(5.0.2195.6824); Sat, 19 Mar 2005 17:22:21 +0400 Date: Sat, 19 Mar 2005 09:22:21 -0400 (CST) Message-Id: <724725792584327.p63JGUcshA798@doge0.nicholson90moose-mail.com> To: rtg-dir@ietf.org From: Protect yourself MIME-Version: 1.0 Content-Type: multipart/related; boundary="%OLATTACH1" X-Spam-Score: 1.9 (+) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Subject: Anti spyware like hot buns X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f This is a multi-part message in MIME format. --%OLATTACH1 Content-Type: multipart/alternative; boundary="%OLATTACH2" --%OLATTACH2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Get a capable html e-mailer Spyware infiltrates your computer without your knowledge or consent! Surfing the net, downloading music, using file sharing software are only few of the ways your computer can get infected! Anti-virus programs DO NOT protect your PC from these Trojans, or even detect them! Only a purposely built spyware removal tool such as Spycontrol can! Put an end to the risk; use the #1 spyware removal tool HERE NOW --%OLATTACH2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    <= font color=3Dblack>

    WARNING! 95% of all home PC's are infected with
    Dangerous Spyware &= Adware Trojans!
    Spyware infiltrates your computer without your knowledge or consent!     <= br>
    Surfing the net, downloading music, using file sharing software
    are only few of the ways your computer can get infected!
    Anti-virus programs DO NOT protect your PC from these Trojans, or even det= ect them!
    Only a purposely built spyware removal tool such as Spycontrol can!
    Put an END to the RISK; USE the #1 SPYWARE REMOVAL TOOL HERE NOW


    Off this camp-aign

    --%OLATTACH2-- --%OLATTACH1 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhCALhAMQAAAAAAAYGBgwMDBISEhQUFCoqKi0tLRheAFRUVHd3dyqhATC6AD3pAZaWlsK/ wt7b3uDe4OPi4////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05F VFNDQVBFMi4wAwEAAAAh/h1CdWlsdCB3aXRoIEdJRiBNb3ZpZSBHZWFyIDMuMAAh+QQAKAAAACwA AAAACALhAAAF/qAkjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9is dsvter/gUyQCeZjP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg2gQYy0QiYSLjI2Oj5CRkpOUlZZt hisRl5ydnp+goaKjpHERKmwOqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPExcbFbKhpqw3Nzs/Q 0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6earaspnDs0I8vP09fb3+Pn6+/z9/v8AAwocSLCgwYMI EypcyLChw4UJEjRw8MBBGTPuKjpIgCCix48gQ4ocSbKkyZMo/lOqXMmypcuXMGPKnEmzps2bOHPi 7Dhx05mMG3lGfEi0qNGjSJMqXcq0qdOn+goUcDDmIopT7zYORSC1K4ECX8OCHSu2LNmzZtOiXau2 Ldu3buPCnSu3Lt27dvPi3au3L9+/fgMDHiy4MOHDhr+CBYBAhJlMKLJy5EogAIDLmDNr3sy5s+fP oEOLHk26tOnTqFOrXs26tevXsGPLnu3a8mXHGFOYiaCqAWXawIMLH068uPHjyJMrX04a94MUZMyo StCVufXr2LNr3869u3fQziWcOrG79+/v6NOrX8++vfvhIqyKkZC1gVQC7/Pr38+/v//kzo1XAlYP 8AbPff8l/qjgggw22F98BQo44EXTnefghRhmqOGGsoUnoQgEGmjfYhyWaOKJKG54ShmQmRCdRiPi l+KMNNZoI3oeukhfgRWSeOOPQAYppGwrPtDigPUhOOSSTDbppGY5uvhYb0o+aeWVWJ5I4HMfirej Rhz5mOWYZJb54JddiucTBFSKaeabcMa5nXhljNHlltNVKeeefPYJ3xi7ieGTGfG4SRoDiCaaH6Kc Mcqao35GKuloRdqpo2R6Hpropu9BmpmnqYE66aik3gZogYJOeaChoSmKmauoiUobp5rJ2ioDr+Ja 6q6kVnrIgC/2KGNpotoqmrGx0fqprqZBiiyv0JpJ5253/g76QDOZHmsrqM7SuimzACgbLq6uwtqZ o9yCK+64437LbrTw7ulrtRRulK225r6b62XfMuouv/+222++teqabq7iDqzos/E27OSWv5JwKptB sTpawPp2u6++HKPrscHgFrzsyB0zC6vGDqc85rSG0CudvRYTW67JNB+M8L8ocyzyxgAD3C/PGYes 8tBM2kmti2sK+5rG6Z6s7sA9R63zsj9vrDDQOROt9ZDTRoj0O9jG7FmxNE/ts9RmBw001VBHbayn DG8tN41Gew0sGmEPq+nTNYeMMtx/l402yYR/zDPgcyfO9YsRj2AIpmKP3TbCBePstLI5y7otyDcj fnPa/oqHrmHdR8Z3EaFh6i3zuu1uhrG5CQtu9uZor9s06KLnzmAAVT0GgQmKvExd5KrFrfvxyING +u8lnM5bA6kDZ3zy1FfP+4tlmLAMzKq7RnD14IefWd25kYDG8zHONr347Ct+/enPlbD98N23b//9 q5Efv/lnPB89/gAM4Gl69xP5oSFPxBOgAgVIwPKN4HzwoN8CJ0jB8b3IgY6xiPAsVMEOBpAMp3OA 9voXwXt58IThAyEatKfBikCPgyiMIfgSEUITUARvEpShDqvHIiNRZIRg+98Oh6i7HhaQBKrAoQmJ yESiPcaHIjRgEGHYxCoO7YlHHEESzwC9JVrxi9B6/iLFbHjALiYQjGiM1DL298Aboo6KaYzjqLBY ERtSRTpmrJ8c99in7bGwPHnkoyAlRccoIvGOLszhIBcpp4rUy444hCMjJ4mlJxrIjj4p4RkpyUkg VSSThtTiDdkUyE6a0kpiVIUdKVTKU7pySY58GSR59MJNvvKWG6IIi1RZgi0m0ou4DCaHYqmRWfoP mMJM5oWIyctDBhGZyoymgnQpy17e8HnysKU0t/meAKjikdZ8pja5Sc71fLKazjxDRKBZznau55vo 1GIDMtlKd9pTP2504SxJmU093vOf3/GmG5spSrBxZZwATWhyVAFKE0ykPENBqEInOhyBsmgis3Th /kH9SdGOKoeh8RQBPACpSACY9KQoTalKV8rSlrr0pTCNqUxnStOa2vSmOM2pTnfK05769KdADapQ gQpPfZbgodJZp0SHytSmOvWpUI2qVKdK1apaVapFxehR8zmZpV71q2ANq1jHStaymvWs3zSEVpHY AAoplaNnjatc50rXutr1rlYtKjwcytWS4vWvgA2sYAdLWLPCEwJrlec7ugrXwjr2sZCNrGQd68u9 bhWQG52sZjfL2c569qpZDaUImuHWfn72tKhNrWpXu1JfNsOGDcAsO1lL29ra9rZi1WsDHDrPMgRF krgNrnCHS1yizpNQu+1lW9WZ2eI697nQja5L/nXL2+j81qvSza52t0tZN75WuWgIE3a5S97ymres AUBqBL5LgmZkkrHnja9852tX14pWAs0Ib3Ppy9/++peqIy0Qe0fg3qSa9r8ITrCCewqP6Ax4tLHl kXgbu+AKW7jC8Fxvctt73IrA98IgDvGF4XGRB+M3wryZsIhXzGL/TuSiGybwcj283xbb+MbbJTFy eQvRA+P4x0Auro6vFWMIL7bGQU6yklf74h0fFcUVG++Sp0zluQ7ZxPk18GyrzOUuz9W9ZcByhM0w Dyl7+cxohuqVi4zfBJR2y2mOs5yhCuZrJYDHPlTxnPfM57zO2MQSOTKc+0zoQte0zhIxQaB5/lRm Chv60ZCGqY4jkOijulnLZo60pvdcYDsreswPyGamN03qMwuAtEaqdHsT8A5RO7rUsC50p6HnUFaf odGxzjWsT/3nO5cgIpl0ta6HvelOR6TWaBA2sZdd6PT2WtEJCDaSmU3tOBvb1ySISLJ9XO1un9nZ dTr2r6MtHWV7+9xdRvUDxJ1tW5N52uiOd5BRTWlsjyAiFDK3vPcN5Cyv294i0Daj4c3vgosY1RBg 973d7QB9G/zhIfa3wgPu7lAXALgQz/h/1T1xCQi8Ig7XuMg3Tu5/Q7s8IR+5yufLcYB7nOFcwfjK Z75d6Pmk4wLnTcppznPttlzRCMi3V3pO/nTyQu8iHDn5wGVe9Kbj9uhmwHnQyz10p1vduTaPemPG jXKCX/3rrIW6yUvQkVZXHexor23WQ+1yjqD84qNOu9zrKvakkx3mcH/13PdOWGCTue0IePug+U74 u9Z96yQoO9WZXvjG/9XvbDeBPAQfd8dbnqpQj4A8JI93xl/+82eFfEckH3hGnx30qK9rAPBtiM3f 3eyeT73sryp6l0/ehwet/Ox3r9PVX1rziB+BPIJ9et4bH6z4fjfp0SCV2B//+UH1fZ1cn3gEEH/w 0M++TpMf6uCL4PYgL772x8/U5EOA+sKfekWar3vyu9+kH0f/90uvc/G///475b78JQB+/gewX+/4 F4AtFX/ex3/013D2J4AKKFP6V4D91xXtt4DHxxE+sX/g9wD/J4EaOFMNuHzSAYEAuIECSIHKR3al ZwYZKIIqyFIdSHYFQCEguIIymFIkaHEeiIIJOIMa2IKJVwCZlII6KIMccRFccYMYmINBqIBDWIIk cHHvEINJuII1eHEm4IRnAIRRuIFDaAhU6IIwiIRZeH8UWAZFWAJWyBtQGIY7OHUR0IU9+IXYp4a7 V4Nl2IQniIEE4HxyOIFTBwFuKHwF8IRguIfaN3xkVgCSF4g8koaEGIBLaINm6IO+xYiNeH+GeISJ WB5goYeVKHuPWIcjIBXWRYmdSH6X/igVmbiIg1iKuxcA8kCEiBiJo6gYIciKn3eKsdiDmpiHEWiL VreFbZiLoeiDH0iLvuh+r4iCBSgVu8iJx+h4yRiMVUiM62eMz1iI6oeKkYgGitGL18hzrsiG2tiE 1Oh/1viNzwd+4ziM5UEAvFiL6Lh3yeiHwigCUgGD5xiPvKeO9SgBzHgG3QiP+ph287iO9qiIFeGO cTiQYMeP08iN78iQ+5iN/fiPCZmPEol6DrmNPBKQGTl7yYiJHLl+ArCQH9l0G0kCX9GOAuCMJ2l1 XPEYX/GQ0qGQ3viSBheSBikBKwmQGImTjTePM2mGBPAONimQQNlzXOETYGECPckb/gTQkjeZlPIW kkPZhEVZkz9JlfJIjU1ZAj1pBkfJldCoflc5AmHpAFFpkmQ5clxxEWcpAu7Iki7ZlisXje7olAip liU5lXZZbW8plv04lx25lX/5dYEZAXkJlgRAIWvpl4e5bEtZBoupkllpBgLgipAZmcNmiBBQmWjZ mNIhAH2JlJz5cDEplgTglFnJGwJgmKdZdIH5mavJmI4ZAGwZm/s2mQ8AmnLZmg6QmXWpmwUXmL1Z m5ZplLi5mcRJakupmqyJBgEAm805c8bpmzx5mcG5nKZZnej2nMfplAJQHgGgmd3pnd52nQJgAqSp nLmJntUmimVAmuw5njwSAKUJ/p+y+YKYuZ4l0J6jyZ36SXTy+QD0+Z/2yRuWMZwDCpj8aaD+SQIA WhECAADv2aDDVqAHKqEJ6gD4eaEYmmvGuaEjMKHBaaHMGaJ7pqEROgL4iQYA0JcVqqIqZ5z4yZ4B AKMAUBk0epeSaKABgKPM16Mzd3GXBqQmUJ7hRaQqRwAcMWblmaQ5mmy0aBtMGm+v2REf9wBRWgJK mgYxp6U6MaZkWqZmeqZomqZquqZs2qZuWhKKdwZdSgJfugyTARV4mqd6uqd82qd++qeAWg8S0UJy GqQlYFKYwCJksKiG0KiM+qiOGqmQOqmSWqmUeqmWmqmYuqma2qmc+qmeGqqgjDqqolqqpHqqppqq qLqqqtqqrPqqrhqrsLqo+pMGJsWeAFAKurqrvNqrvvqrwEoJMSp5AABqwXqsyJqsyrqszEoJDcAY iraj+dSs1Fqt1nqt2KqsagkALsd/AOCKRZWt4jqu5Fqu5voHDVehBSh8V1p0rrgC65ai7ZpmJZkA 9xUG+Jqv+rqv/NqvTBACACH5BAEoABMALAwADgCAAB8AAAV4oDEAZGmeaKqubOu+cIyKcm3feB7T eu//wBMvSCwaWcOjchlMMp/QmjNKraam1mwVq+0yud5wESwu+8jm9A2tbsPY7vgKLq+b6HY7Pi/f 891+f2qBgmaEhWKHiF6Ki1qNjlaQkVSTlFCWl18jmnmZnUefoGOco3EhACH5BAEoABMALCAAHABs ABEAAAXQIAAwZCmeaKqubOu25Bq/dFzeDK3vPDunvx7whjIJT8EjjzhU/pjFnHIknS6NUWcV56uK nkwuEkulSsmys7c8TtpwuTfareaKzVg43DWjt8l6JmCAW4VjX15BfYtqMImPiFmIhpFDi4eTa4p6 lWyeKpuSgZidSaRvlmBRe56qXayVo52taLSfq7OmpZSggZS6uZqbhX6xj7+8wKaueby3eFCTqUZQ sK7P2GyDhKtxdbXg0YShu2ldwcVt2b1W7e7vPcDw8/RHtfX4+TVr+v3zIQAh+QQBKAATACwgABwA bAARAAAFNCAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdss1 hQAAIfkEASgAEwAsIAAcANoALAAABf4gADBkKZ5oqq5s67bkGr/0TN94ru88Wv6MnnAosvmCxBEy yWw6XaZTtGd8qn7Xpc5WtXq/vG43N/5iU+UXVwtuu6Hl6joKPBpj9HQRKdeepUFAeGxvhYZKU3to fIKIc1OCjTCMi4B/jo16h5tWdYCfiqF3foyloTKkR6dKlqCsnLCGZ2uWbKOStKuVrq+RS6O8scJg tH2QpLi/ypOSopG8ucPSQ2LLcTPAqK7XvqBp2dPhRInHfd7I59uEuq+90eDi8WHPdouef83v69en ze2O/+QJZJZoDyFPBu2k6rdvnTuFu1ppGkgRTsWLGC9OzMixI7GNHkOKHOdwpMmTKP5TqlzJsqXL lzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl0K1B8OkDVilSxJkyqLfWi23LQ6jiLXp1fI bHXzlVPZqFkBSsFUywerQJSKrCWH52rdEW7lGuSzFhXfvIgS7nWLzeEluMh+6e1LTmJaP9v6Ls6F bbJivOww9wL8V27ntHhtTR4tufBiyZq5nP4r+jJmZQghr0btOjVj2rPD3i592jMM3bZByw6uWWFt 2JVJYy1uODbn57z1Hs8N+jX0g3og0Va9lztx3Lllu4bN+S7w6tOpX04/HLD16Ad7y5h7lTTw2urz iic8X34c6PZ9N16AnY2xTGrr8UsnH3GBXAceg+exp5+CECJIkHuJYQjfgyY012BC49HhXisjBlZa YwG29RlyoVVnomVnYcRVjE7QqFFTaJnlko0rXfLbJlDJyOMJIQAAIfkEASgAEwAsIAA7ANoADQAA BUAgII5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqPyKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4 TC6bz+i0ehsCACH5BAEoABMALCAAOwDaAA0AAAX+ICOOQGmeqCmmbIsybizLcFvPeK7v+a37qtcO yCsajwAiMqVcOptFIpTprFptV9Y0+7tKSyMfLHwLn8bjZG0FDpJUqyZpfQ6C32UbG1jes9V/SWp3 eoFoYm+CinaJi3NCi455bXaDhJZ0l4p9WnCUn5ltoZCCfKCnlX6flZKMdZtCk7B3ZKyyjq+RsqFi q0q9uq6xLl+oucC4q3CJyLXJs5DIL87BvrapxtCR19XatDHMtn99ZsbF2aO8qYbL26y5z/G76NZU wqjFW7hy2cfv3cAC1vn1LxC8Wwi5JUvYyh4mT5R63cImyp88iu6avRLoBiMvKOXq0ZI27+I3OXE4 2u3CA69dS0DHGpWclhLgI1Nn2H3jwnOGPn09gfbkInSoUZ9Ij3ZSytRd06daGhGDaokqT4M8QgAA IfkEASgAEwAsIAA7ANoADQAABUAgII5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqPyKRyyWw6 n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0ehsCACH5BAEoABMALCAAOwDaAA0AAAX+ICOOQGmeqCmm bIsybizLcFvPeK7v+a37qtcOyCsajwAiMqVcOptFIpTprFptV9Y0+7tKSyMfLHwLn8bjZG0FDpJU qyZpfQ6C32UbG1jes9V/SWp3eoFoYm+CinaJi3NCi455bXaDhJZ0l4p9WnCUn5ltoZCCfKCnlX6f lZKMdZtCk7B3ZKyyjq+RsqFiq0q9uq6xLl+oucC4q3CJyLXJs5DIL87BvrapxtCR19XatDHMtn99 ZsbF2aO8qYbL26y5z/G76NZUwqjFW7hy2cfv3cAC1vn1LxC8Wwi5JUvYyh4mT5R63cImyp88iu6a vRLoBiMvKOXq0ZI27+I3OXE42u3CA69dS0DHGpWclhLgI1Nn2H3jwnOGPn09gfbkInSoUZ9Ij3ZS ytRd06daGhGDaokqT4M8QgAAIfkEATwAEwAsHwBUAO4AEQAABf4gwwAkKY4lIKZs67rrK7OxfJ5z ru98fuO9oLAXu9FqJtTQplyqmq0f0EmtHqVQq3ZWHCGnz604hbySy+M007xDC91t1Ko2V8LVwzv6 jsfv+SWAOoIvXWFJh4lPYHVhYId1WYuQkkmViFNlRoFnZ5leTZuFkl+MoqKBn6qkjZSYcqFSqThY nYuot0B8PzCyirezqbObvJaPtkfDdMTFxl26zc6GrtOKy3bPwpPb3NVMj9Cw2kUqiObmpsjJUeLa iaWW49jI4eigwprN8O7ey7aExty5smei3C9f+Xyx6yXNX8N2Cx8KnNbKUSx9sehBfJfx16B5/O69 suiJ2ZVo6qzkKbxWDA7LUx1ZDlPn8BxHmzU9MlxnbV6pSB0JplzDRg/IiEiNDuUWb+LRnvI0wrrk qWrTVWyY7ksoMKWqkMHsgbwWcmovKKZWBr0JVZk3dgpzcbWqtZbHuCdRxmWGSu0zcAjX3qX1dN9A m5PewgXMtKnGxYdLcsE7MysuYHQvJ97YpzPAj5M7ix5NurQTslt2UTXNurVrMXZTVzr2urbt20FQ WnG5GrdvNSEAACH5BAEHABMALCAAiQAGAAcAAAUOIAOMJCOSo4mm5amyaAgAIfkEAQcAEwAsLACI AAkACgAABRUgA4wkwIjlKKIk66ZrqsozzcK0WYYAIfkEAQcAEwAsNgCLAAYABwAABQ8gwIyMCJxi iY5o2rJryoYAIfkEAQcAEwAsPgCLAAYABwAABRAgA4wAI5ImWZ5jirKpKTIhACH5BAEHABMALEsA iwAHAAcAAAUSIMCMDCCaZimSpZqeaIvCrBgCACH5BAEHABMALFMAiwAEAAcAAAUMIAMwpDgCqHmm 6AqEACH5BAEHABMALFkAiwAGAAcAAAUPIMCMjAicYomSrLqiJguEACH5BAEHABMALGYAiwAGAAoA AAUUIAMw5CgCJoqWKru6JSmerbraQAgAIfkEAQcAEwAsbgCLAAYABwAABQ8gwIyMCJxiiY5o2rJr yoYAIfkEAQcAEwAsdgCLAAUABwAABQ0gwIwiYJLmiaYrI5IhACH5BAEHABMALH4AiwAFAAcAAAUN IMCMImCS5ommKyOSIQAh+QQBBwATACyFAIgAAQAKAAAFByADAExpMiEAIfkEAQcAEwAsiACIAAYA CgAABRMgA4yjSAImKTIsmrZq6p7su7YhACH5BAEHABMALJEAiAABAAoAAAUFICOOZAgAIfkEAQcA EwAskwCLAAcACgAABRQgA4wjI5KAeKYluaooHKPt7K5jCAAh+QQBBwATACygAIgABgAKAAAFEyAD jKNIAiYpMiyatmrqnuy7tiEAIfkEAQcAEwAsqACLAAYABwAABQ8gwIyMCJxiiZKsuqImC4QAIfkE AQcAEwAssACIAAEACgAABQcgAwBMaTIhACH5BAEHABMALLQAiwAGAAcAAAUPIAMw5CgCJoqWKrue rzqGACH5BAEHABMALLwAiwAGAAoAAAUUIMCMIgOco3mWK7uSqJmKLd3KcwgAIfkEAQcAEwAsyACL AAkABwAABRIgA4wiWQKnqKIsu5ZvK5/zGAIAIfkEAQcAEwAs0gCLAAcABwAABRIgwIwMIJpmKZKl mp5oi8KsGAIAIfkEAQcAEwAs2QCJAAMACQAABQwgwACiyIxjqaapGAIAIfkEAQcAEwAs3wCLAAYA BwAABQ8gwIyMCJxiiZqriromWYYAIfkEAQcAEwAs5gCIAAYACgAABRMgA4yjSAImKTIsmrZq6p5w KTMhACH5BAEHABMALO8AiwAGAAcAAAUPIMCMjAicYomSrLqiJguEACH5BAEHABMALPcAiAAGAAoA AAUTICCKzEiaQMmsaUmyI/yaMruqIQAh+QQBBwATACwEAZEAEgACAAAFCyADjCQgluSJrmgIACH5 BAFaABMALB0AgwC4AU8AAAX+4CSOZGmeaKqubOu+cCzPdE0rdq7vfO//wKBwSCwaSYyjcslsOp/Q qFSHm1qv2Kx2yyVWu+CweEwuB5PmtHrNbme/7rh8Tq+34Pa8fs/vovuAgYKDQniEh4iJiiSGi46P kHN/kZSVlmKNl5qbnEqZnaChojWTo6anqCmfqaytnKuusbKOsLO2t7i5uru8vb6/wMHCw8TFxsfI ycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wAD ChxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsWM4BQxCihxJsqTJkyj+U6pUWctjMAUw98Bs 6ZJXTEA3axajGaeUTmA++wT9yWvoHqNEcyHNg2bkiKYplk4giaSEVBlXkwrJaoPqU6tDkkyCumJp qT9jUXA9sdZN26hs40J7G+Ps17tbfYplgTQo2alwSRGiq1av4WeEXfgVgbZISLWMn4qMTLmqCbJG JzPWfFkzWs5TOYt9DNay08qAAZO2Stpu6KarT6uGrWK15M7NErdYnFq34qGYq/61XHpvbbypiatG PZw26uSR00J3fvmr3cbJpbceLre092S+y8o17hg4Zb3Qld993Bc5+uLEvUqPz7x+evXZn+dfjzfz Yda5EcEbe0bYZpp+oOHL1xty3s3HYG/yHfggdtpJWBh22cUm2WkY+vUfEuHdEmJg8On3g4HLLVji d/w9WJmDCJpYoYvkzXjebtaNR2N/1fXIIjMjQtYjjCdOd6ORGKqX5H37xZijkVASmWKUtzH54pP7 JfnXkuMEKSSPCvIAm4YZtqagV042mOCGW4LmFHlWnuUmgVZu5tqG8YkGpjleXmjbe0D0eYigJBZE KBeHBpKojwbxJIejlaCYl0IgDZKTVr5cKhOkmLZSKR+advoLSCuVauqpqJaUUwgAIfkEAVoAEwAs GAGDAAEAEQAABQYgII5kKYYAIfkEAVoAEwAsFQGCAAQAEgAABRUgIB4isJSnmJpoq7rsK8f0kq7r EQIAIfkEAVoAEwAsFQGCAAQAEgAABQwgII5kaZ5oqpbMGgIAIfkEAVoAEwAsFQGCAAQAEgAABRUg IB4isJSnmJpoq7rsK8f0kq7rEQIAIfkEAVoAEwAsFQGCAAQAEgAABQwgII5kaZ5oqpbMGgIAIfkE AVoAEwAsFQGCAAQAEgAABRUgIB4isJSnmJpoq7rsK8f0kq7rEQIAOw== --%OLATTACH1-- From rtg-dir-bounces@ietf.org Tue Mar 22 02:13:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01979 for ; Tue, 22 Mar 2005 02:13:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDdf0-0006u2-7r for rtg-dir-archive@ietf.org; Tue, 22 Mar 2005 02:18:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDdZa-0007sV-4Q; Tue, 22 Mar 2005 02:13:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDdZJ-0007j1-W3 for rtg-dir@megatron.ietf.org; Tue, 22 Mar 2005 02:12:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01493 for ; Tue, 22 Mar 2005 02:12:49 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDdeV-0006tk-NE for rtg-dir@ietf.org; Tue, 22 Mar 2005 02:18:13 -0500 Received: from [203.177.147.227] (helo=192.168.0.44) by mx2.foretec.com with smtp (Exim 4.24) id 1DDdZH-0000qE-94 for rtg-dir@ietf.org; Tue, 22 Mar 2005 02:12:48 -0500 From: "makoy" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Tue, 22 Mar 2005 15:26:20 -0800 Message-Id: X-Spam-Score: 4.6 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 8bit Subject: Join the Latest Internet Boom Free Trial for 7 Days X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 8bit Hi Would you mind checking something out for me? Your Private Screening http://profitmovie.cjb.net This is a unique (and really short) animated movie you can share with others by email like I am doing here. As you'll see, you can help a lot of people have a much better life. Make sure you turn up your speakers - the actors are going to actually say your name. Thanks, and let me know if you have any questions. I am very excited about this! Makoy From rtg-dir-bounces@ietf.org Tue Mar 22 22:05:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12491 for ; Tue, 22 Mar 2005 22:05:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDwHI-0002hL-CK for rtg-dir-archive@ietf.org; Tue, 22 Mar 2005 22:11:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDwBo-0007QW-NW; Tue, 22 Mar 2005 22:05:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDwBl-0007Q3-La; Tue, 22 Mar 2005 22:05:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12460; Tue, 22 Mar 2005 22:05:42 -0500 (EST) Received: from pool-70-16-70-72.port.east.verizon.net ([70.16.70.72]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DDwH5-0002gh-OY; Tue, 22 Mar 2005 22:11:18 -0500 Received: from Eys@localhost by OuV.int (8.11.6/8.11.6); Wed, 23 Mar 2005 08:55:25 +0600 Message-ID: From: "Erica Jacobsen" To: rserpool-admin@ietf.org Date: Tue, 22 Mar 2005 22:01:25 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: SamanthaSlater@btnmy.com Content-Type: multipart/mixed; boundary="--SM2dvEsJJwveAmBHPx4" X-Spam-Score: 1.2 (+) X-Scan-Signature: 07d4bcb4600b627a0786c2557bc62e06 Cc: rtg-dir@ietf.org, rtg-bfd@ietf.org, rserpool@ietf.org, rtgwg@ietf.org, rsvp-archive@ietf.org Subject: Office XP & Symantec Software Starting at $29 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Erica Jacobsen List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 SOl ----SM2dvEsJJwveAmBHPx4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 4614953
    Browse Search Shop My eSoft Community
    Back to Software = Overview

    Home > All Categories > Computers > Software > Operating Systems > = Windows
    All Items
    Auctions
    Bu= y It Now
        Refine Search=
     Top Sellers
    1      Office 2003 Pro     
    6   Macromedia
         Dream Weaver
         MX 2004
    7       CorelDraw
         Graphics Suite 12.0
    11 Alias Wavefront 6.0
    13     Adobe Encore DVD

     

     

    Featured It= em

    		 PRlCE Bids Time Left

    3D"New"  Microsoft= Windows XP PRO
    -Current Edition-

     3D"Gift from Our eStore

    $49.95 USD

    9
    3D"Gift

    = 0h 19m

    Nevv It= ems

    		 PRlCE Bids Time Left

    3D"New"  Micro= soft Office 2003 PRO or
    Microsoft Office XP PRO

     3D"Gift from Our eStore

    $49.95 USD

    3
    3D"Gift

    		 0h 11m

    3D"New"  Adobe= Photoshop CS 8.0 or Adobe Acrobat PRO 7.0

     3D"Gift from Our eStore

    $59.95 USD

    		 5 3D"Gift 0h 13m

    3D"New"  Macro= media FlashMX Pro 2004 or Macromedia Dreamweaver MX Pro 2004

     3D"Gift from Our eStore

    		 $39.95 USD 3 3D"Gift 0h 12m
    ----SM2dvEsJJwveAmBHPx4-- From rtg-dir-bounces@ietf.org Wed Mar 23 14:19:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21857 for ; Wed, 23 Mar 2005 14:19:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBTy-0007mB-J1 for rtg-dir-archive@ietf.org; Wed, 23 Mar 2005 14:25:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBNg-0001gm-Hk; Wed, 23 Mar 2005 14:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBNf-0001gY-75 for rtg-dir@megatron.ietf.org; Wed, 23 Mar 2005 14:19:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21681 for ; Wed, 23 Mar 2005 14:19:01 -0500 (EST) Message-Id: <200503231919.OAA21681@ietf.org> Received: from [67.133.92.212] (helo=juarezfamily.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DEBTA-0007kD-JS for rtg-dir@ietf.org; Wed, 23 Mar 2005 14:24:45 -0500 From: "Madhavi Aaron" To: "Cupid Sheridan" Date: Wed, 23 Mar 2005 14:15:13 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C52E1D.4241CE6A" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 3.4 (+++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: Re: Mediccations HUC:55 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.1 (++++) X-Scan-Signature: 25620135586de10c627e3628c432b04a This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C52E1D.4241CE6A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Lord Julian forestalled a fresh outburst on the part of Bishop. Now is she a vixen or am I a fool, or is it both? he asked the leapt from the brass cannon on the Arabella's beak-head, and he accounted that M. de Cussy had proved himself unworthy of the upon the most illustrious and high-born Prince James, Duke of megrims, said he. into the face of his excellency the Deputy-Governor of Jamaica, A thousand pieces, he answered shortly. hushed court. Have a nice day. ------=_NextPart_000_0008_01C52E1D.4241CE6A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello , = VlSIT = Our PharmacyBy-MAlLSHOP and Save 70%
     
    VI RA AM EN LE RA CI IS,  And 
    AG Bl VlT AL many Other.
     
    Just try us and = you will NOT be DlSAPPOlNTED.
     
    Have a nice = day.
    ------=_NextPart_000_0008_01C52E1D.4241CE6A-- From rtg-dir-bounces@ietf.org Thu Mar 24 21:55:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10643 for ; Thu, 24 Mar 2005 21:55:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEf4O-0005x3-T5 for rtg-dir-archive@ietf.org; Thu, 24 Mar 2005 22:01:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEeyG-00074B-Tu; Thu, 24 Mar 2005 21:54:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEeyE-00073n-ME; Thu, 24 Mar 2005 21:54:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10615; Thu, 24 Mar 2005 21:54:44 -0500 (EST) Received: from [59.34.64.55] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DEf3x-0005sB-O3; Thu, 24 Mar 2005 22:00:46 -0500 X-Apparently-To: rtg-dir@ietf.org X-Sieve: CMU Sieve 2.2 Received: from smother.pecan.pochta.ru ([unix socket]) by irreproducible.effectuate.pochta.ru (Cyrus v2.2.1) with LMTPA; Thu, 24 Mar 2005 19:50:32 -0700 Date: Fri, 25 Mar 2005 05:54:32 +0300 From: "Darnell Whitley" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: rtg-dir@ietf.org X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rtgwg-admin@ietf.org, rv@ietf.org, rtgwg-web-archive@ietf.org, rtgwg@ietf.org Subject: You've been selected for a low rate X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.3 (+++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.ok-ref-yes.net/nowss.asp Best Regards, Peggy Nix to be remov(ed: http://www.ok-ref-yes.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Fri Mar 25 09:57:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03728 for ; Fri, 25 Mar 2005 09:57:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEqLX-00022H-OJ for rtg-dir-archive@ietf.org; Fri, 25 Mar 2005 10:03:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEqFS-0007Ts-5r; Fri, 25 Mar 2005 09:57:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEqFQ-0007Tm-KJ for rtg-dir@megatron.ietf.org; Fri, 25 Mar 2005 09:57:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03685 for ; Fri, 25 Mar 2005 09:57:14 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEqLI-0001zd-K1 for rtg-dir@ietf.org; Fri, 25 Mar 2005 10:03:21 -0500 Received: from [211.238.78.97] (helo=211.238.78.97) by mx2.foretec.com with smtp (Exim 4.24) id 1DEqFJ-0008Ma-Qi for rtg-dir@ietf.org; Fri, 25 Mar 2005 09:57:10 -0500 Message-ID: <5c1701c53149$76702a69$0bb90851@accel.net> From: "Susan M. Taylor" To: rtg-dir@ietf.org Date: Fri, 25 Mar 2005 14:48:04 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_68F14BAF.ACC26974" 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-Score: 2.4 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: Replica watch models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_0000_68F14BAF.ACC26974 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_3ECFED7F.22DC7073" ------=_NextPart_001_0001_3ECFED7F.22DC7073 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit REPLICA WATCH MODELS Rolex, Patek Philippe, Bvlgari Cartier, Gucci, Franck Muller .. and 25 other most famous manufacturers. http://www.vipwatches.info All for only $249.99! _________________________________________________________________________ To change your mail preferences, go here: http://www.signoffcorp.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_3ECFED7F.22DC7073 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit

    REPLICA WATCH MODELS

    Rolex, Patek Philippe, Bvlgari
    Cartier, Gucci, Franck Muller

    .. and 25 other most famous manufacturers.

    http://www.vipwatches.info

    All for only $249.99!


    _________________________________________________________________________
    To change your mail preferences, go here
    _________________________________________________________________________

    ------=_NextPart_001_0001_3ECFED7F.22DC7073-- ------=_NextPart_000_0000_68F14BAF.ACC26974-- From rtg-dir-bounces@ietf.org Sat Mar 26 16:39:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03427 for ; Sat, 26 Mar 2005 16:39:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFJ5y-0004rE-SF for rtg-dir-archive@ietf.org; Sat, 26 Mar 2005 16:45:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFIxQ-0005lq-5Y; Sat, 26 Mar 2005 16:36:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFIxO-0005l9-Mt; Sat, 26 Mar 2005 16:36:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03231; Sat, 26 Mar 2005 16:36:31 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFJ3X-0004m0-4n; Sat, 26 Mar 2005 16:42:56 -0500 Received: from [218.25.27.146] (helo=cncln.online.ln.cn) by mx2.foretec.com with smtp (Exim 4.24) id 1DFIxJ-0002xn-DJ; Sat, 26 Mar 2005 16:36:30 -0500 Received: from annal.driveway-ballard.com (HELO recipient.com 66.3.108.15) by eighteenth.com with EMQP; Sat, 26 Mar 2005 18:35:29 -0300 Date: Sat, 26 Mar 2005 15:35:29 -0600 From: "Jerrod Phipps" Message-Id: To: rserpool-archive@ietf.org X-Mailer: CompuServe 7.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rtg-dir@ietf.org, rtgwg-admin@ietf.org, rtgwg-web-archive@ietf.org, rtg-bfd@ietf.org, rsvp-archive@ietf.org, rv@ietf.org, rtg-bfd-admin@ietf.org, rtgwg@ietf.org Subject: Save hundreds every month on low rates X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.forever-mrt-now.net/nowss.asp Best Regards, Yvonne Timmons to be remov(ed: http://www.forever-mrt-now.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Sun Mar 27 14:29:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27526 for ; Sun, 27 Mar 2005 14:29:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFdYe-0000uc-NV for rtg-dir-archive@ietf.org; Sun, 27 Mar 2005 14:36:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFdRS-0005iF-Oh; Sun, 27 Mar 2005 14:28:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFdRR-0005iA-Ip for rtg-dir@megatron.ietf.org; Sun, 27 Mar 2005 14:28:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27430 for ; Sun, 27 Mar 2005 14:28:56 -0500 (EST) Message-Id: <200503271928.OAA27430@ietf.org> Received: from [200.208.91.182] (helo=galorath.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DFdXl-0000qQ-Rj for rtg-dir@ietf.org; Sun, 27 Mar 2005 14:35:31 -0500 From: "Calanthe Moss" To: "Oedipus Welsh" Date: Sun, 27 Mar 2005 14:28:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01C5313B.4247096B" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.2 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: Re: MMedications CBL/42 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is a multi-part message in MIME format. ------=_NextPart_000_004A_01C5313B.4247096B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, provide for a certain distribution of the spoil. My men demand i into the King's service under Charles II. It occurred to him tha seeming to echo some of the mockery that had invested Levasseur's rashness, I'll tell you that the Harbour-Master and the Commandan Wait! Blood bade him, interrupting, and he set a restraining h the semblance of a grating. Next they increased by a half-dozen Of the money and jewels a division was made on the spot. The cac It'll do as well asertruth, said he when Wolverstone had finish What's this? the Captain demanded sharply. Your station is on now, and without noise. you that there is still something left in him of the unfortunate lay there until daybreak. Then Blood went forward alone, and wit part of a hundred lives were lost in reducing it. That's how we Have a nice day. ------=_NextPart_000_004A_01C5313B.4247096B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, = Do you want to sppend LESS on your medications?
     
    Visit = PharmacyByMMail SH0P and SAVE=20 Over 70%
    V GR UM C lS NA
    lA A VALl lAL  XA X and many other
     
    Try uus and you will not be disappointed.
    Have a Nice Day.
     
    ------=_NextPart_000_004A_01C5313B.4247096B-- From rtg-dir-bounces@ietf.org Mon Mar 28 07:02:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08579 for ; Mon, 28 Mar 2005 07:02:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFt32-0001GQ-Ni for rtg-dir-archive@ietf.org; Mon, 28 Mar 2005 07:08:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFsve-00027O-39; Mon, 28 Mar 2005 07:01:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFsvd-00027J-2w for rtg-dir@megatron.ietf.org; Mon, 28 Mar 2005 07:01:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08559 for ; Mon, 28 Mar 2005 07:01:06 -0500 (EST) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFt27-0001Fq-P2 for rtg-dir@ietf.org; Mon, 28 Mar 2005 07:07:52 -0500 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-green.research.att.com (Postfix) with ESMTP id 8F2A9A7B2F for ; Mon, 28 Mar 2005 07:00:55 -0500 (EST) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j2SC02eA070683 for ; Mon, 28 Mar 2005 04:00:03 -0800 (PST) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j2SC02xS070682 for rtg-dir@ietf.org; Mon, 28 Mar 2005 04:00:02 -0800 (PST) (envelope-from fenner) Date: Mon, 28 Mar 2005 04:00:02 -0800 (PST) Message-Id: <200503281200.j2SC02xS070682@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Subject: IESG agenda for 2005-03-31 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-03-31). Updated 2:26:26 EDT, March 28, 2005 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date TSV Interworking between SIP and QSIG (BCP) - 1 of 5 draft-ietf-sipping-qsig2sip-04.txt [Open Web Ballot] Token: Allison Mankin A Session Initiation Protocol (SIP) Event TSV Package for Key Press Stimulus (KPML) (Proposed Standard) - 2 of 5 draft-ietf-sipping-kpml-07.txt [Open Web Ballot] Token: Allison Mankin SEC The Simple and Protected GSS-API Negotiation Mechanism (Proposed Standard) - 3 of 5 draft-ietf-kitten-2478bis-05.txt [Open Web Ballot] Note: proto shepherd: jaltman@columbia.edu Token: Sam Hartman INT IPv6 Host to Router Load Sharing (Proposed Standard) - 4 of 5 draft-ietf-ipv6-host-load-sharing-03.txt [Open Web Ballot] Token: Margaret Wasserman INT Domain Name System (DNS) Case Insensitivity Clarification (Proposed Standard) - 5 of 5 draft-ietf-dnsext-insensitive-05.txt [Open Web Ballot] Note: 2005-01-25: AD review raises some questions, then to IETF LC. Token: Margaret Wasserman 2.1.2 Returning Item Area Date SEC Five-Document ballot: [Open Text Ballot] - 1 of 4 SSH Protocol Architecture (Proposed Standard) - 1 of 4 draft-ietf-secsh-architecture-22.txt Note: IPR Issues have greatly delayed this block of documents. At IETF 62, the IPR WG gave advice that has been included in these documents. By approving these documents, the IESG will be approving the approach recommended by the IPR WG. SSH Connection Protocol (Proposed Standard) draft-ietf-secsh-connect-25.txt SSH Transport Layer Protocol (Proposed Standard) draft-ietf-secsh-transport-24.txt SSH Authentication Protocol (Proposed Standard) draft-ietf-secsh-userauth-27.txt SSH Protocol Assigned Numbers (Proposed Standard) draft-ietf-secsh-assignednumbers-12.txt Token: Russ Housley TSV RTP Retransmission Payload Format (Proposed Standard) - 2 of 4 draft-ietf-avt-rtp-retransmission-11.txt [Open Web Ballot] Token: Allison Mankin SEC Sep 26 IP Encapsulating Security Payload (ESP) (Proposed Standard) - 3 of 4 draft-ietf-ipsec-esp-v3-10.txt [Open Web Ballot] Note: Placed on 2005-03-31 agenda to confirm resolution of discuss positions. Token: Russ Housley SEC GSAKMP (Proposed Standard) - 4 of 4 draft-ietf-msec-gsakmp-sec-08.txt [Open Web Ballot] Token: Russ Housley 2.2 Individual Submissions 2.2.1 New Item Area Date APP Attaching Meaning to Solicitation Class Keywords (Proposed Standard) - 1 of 2 draft-malamud-keyword-discovery-03.txt [Open Web Ballot] Token: Scott Hollenbeck APP Augmented BNF for Syntax Specifications: ABNF (Draft Standard) - 2 of 2 draft-crocker-abnf-rfc2234bis-00.txt [Open Web Ballot] Note: This document obsoletes RFC 2234. It was produced to address comments received during the IESG evaluation of moving 2234 to Draft Standard status. Token: Scott Hollenbeck 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item NONE 3.1.2 Returning Item Area Date IPv6 Host Configuration of DNS Server OPS Information Approaches (Informational) - 1 of 1 draft-ietf-dnsop-ipv6-dns-configuration-05.txt [Open Web Ballot] Note: Back to the IESG to check new version Token: David Kessens 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date Policy-Mandated Labels Such as "Adv:" in APP Email Subject Headers Considered Ineffective At Best (Informational) - 1 of 2 draft-malamud-subject-line-03.txt [Open Web Ballot] Token: Scott Hollenbeck APP Common Format and MIME Type for CSV Files (Informational) - 2 of 2 draft-shafranovich-mime-csv-03.txt [Open Web Ballot] Token: Scott Hollenbeck 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item NONE 3.3.2 Returning Item Area Date OSPF-xTE: An experimental extension to OSPF RTG for Traffic Engineering (Experimental) - 1 of 2 draft-srisuresh-ospf-te-07.txt [Open Web Ballot] Note: The previous concern was the use of an unallocated bit; the update uses the OSPF Capabilites LSA for signalling and draft-ietf-ospf-cap-06 assigns it bit # 9. Token: Bill Fenner MAC-Forced Forwarding: A Method for Traffic INT Separation on an Ethernet Access Network (Informational) - 2 of 2 draft-melsen-mac-forced-fwd-03.txt [Open Web Ballot] Note: Back on agenda to resolve IPv6 issues noted by Margaret. Token: Mark Townsley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval Area Date SEC Mar 8 Better-Than-Nothing Security (btns) - 1 of 1 Token: Sam 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review Area Date INT Mar 10 IP over Resilient Packet Rings (iporpr) - 1 of 1 Token: Mark 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issues From rtg-dir-bounces@ietf.org Mon Mar 28 20:52:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06403 for ; Mon, 28 Mar 2005 20:52:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG60S-00080W-LJ for rtg-dir-archive@ietf.org; Mon, 28 Mar 2005 20:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG5rE-0003Ki-44; Mon, 28 Mar 2005 20:49:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG5rC-0003KI-P9; Mon, 28 Mar 2005 20:49:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06202; Mon, 28 Mar 2005 20:49:24 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG5xo-0007vZ-IS; Mon, 28 Mar 2005 20:56:16 -0500 Received: from c911ac2a.bhz.virtua.com.br ([201.17.172.42] ident=CASA172) by mx2.foretec.com with smtp (Exim 4.24) id 1DG5r7-0004mp-3Z; Mon, 28 Mar 2005 20:49:24 -0500 Received: from scottish-jcoppens.com (EHLO bluestocking.jcoppens.com) by pence.jcoppens.com with SMTP; Mon, 28 Mar 2005 18:49:32 -0700 Date: Tue, 29 Mar 2005 02:52:32 +0100 From: "Jackie Stringer" To: rsvp-archive@ietf.org Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [229], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: rtg-dir@ietf.org, rtgwg-admin@ietf.org, rtgwg-web-archive@ietf.org, rtg-bfd@ietf.org, rv@ietf.org, rtg-bfd-admin@ietf.org, rtgwg@ietf.org Subject: Need a low mortage rate? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.go-mrt-now.com/sign.asp Best Regards, Amie Gonzales to be remov(ed: http://www.go-mrt-now.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Tue Mar 29 18:53:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11577 for ; Tue, 29 Mar 2005 18:53:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGQcw-0004gS-2m for rtg-dir-archive@ietf.org; Tue, 29 Mar 2005 19:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGQVL-0004l5-0M; Tue, 29 Mar 2005 18:52:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGQVJ-0004l0-9N for rtg-dir@megatron.ietf.org; Tue, 29 Mar 2005 18:52:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11497 for ; Tue, 29 Mar 2005 18:52:10 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGQc7-0004fb-1j for rtg-dir@ietf.org; Tue, 29 Mar 2005 18:59:15 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGQVH-0009iv-M2 for rtg-dir@ietf.org; Tue, 29 Mar 2005 23:52:11 +0000 Date: Tue, 29 Mar 2005 15:52:03 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1056837882.20050329155203@psg.com> To: rtg-dir@ietf.org In-Reply-To: <007001c52319$65a7d6a0$a4858182@Puppy> References: <007001c52319$65a7d6a0$a4858182@Puppy> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------71CCF32A9A9B1D" X-Spam-Score: 0.8 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Subject: Fwd: L1VPN drafts X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac ------------71CCF32A9A9B1D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Directorate people- I'll be cc'ing rtg-dir on my discussion with Adrian, Takeda, et al on L1VPNs. Opinions are appreciated please feel free to chime in. Attached are e-mails listing the reading material. -- Alex http://www.psg.com/~zinin ------------71CCF32A9A9B1D Content-Type: message/rfc822; name="1.msg" Content-Disposition: attachment; filename="1.msg" Received: by psg.com (mbox zinin) (with Cubic Circle's cucipop (v1.31 1998/05/13) Mon Mar 7 14:08:47 2005) X-From_: adrian@olddog.co.uk Mon Mar 07 13:26:16 2005 Return-path: Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D8IFT-0001e8-TY for zinin@psg.com; Mon, 07 Mar 2005 13:26:16 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id C28A8E000090; Mon, 7 Mar 2005 13:26:13 +0000 (GMT) Received: from Puppy ([130.129.133.164] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Mar 2005 13:25:51 +0000 Message-ID: <007001c52319$65a7d6a0$a4858182@Puppy> From: "Adrian Farrel" To: zinin@psg.com CC: "Bill Fenner" , "'Kireeti Kompella'" Subject: L1VPN drafts Date: Mon, 7 Mar 2005 13:24:33 -0000 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 07 Mar 2005 13:25:51.0428 (UTC) FILETIME=[2EAEA840:01C52319] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Content-Transfer-Encoding: 7bit Alex, Here's your reading :-) Framework http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-03.txt This is really well cooked. Apart from editorial, the authors think there is nothing else to do. Applicability (of protocols to meeting the framework) http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-02.txt This needs another pass by the authors to fill in some blanks. But it is pretty well advanced. Specific solution http://www.ietf.org/internet-drafts/draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt This draft has been around for the longest time. Conceptually it is done. I believe there is an implementation Second protocol solution model http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-05.txt The "GMPLS UNI" draft specifically mentions L1VPNs and solves some of the models. For other models it might need some extensions. This draft is "pending announcement" Questions? Adrian ------------71CCF32A9A9B1D Content-Type: message/rfc822; name="2.msg" Content-Disposition: attachment; filename="2.msg" Received: by psg.com (mbox zinin) (with Cubic Circle's cucipop (v1.31 1998/05/13) Wed Mar 23 18:48:06 2005) X-From_: takeda.tomonori@lab.ntt.co.jp Wed Mar 23 02:29:23 2005 Return-path: Received: from [222.146.51.136] (helo=smtp.cronos.ocn.ne.jp) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DDvcZ-0006Ed-2e for zinin@psg.com; Wed, 23 Mar 2005 02:29:23 +0000 Received: from TAKEDAPANA.lab.ntt.co.jp (vote.osaka-airport.co.jp [218.42.150.163]) by smtp.cronos.ocn.ne.jp (Postfix) with ESMTP id 7C5441FEC; Wed, 23 Mar 2005 11:29:21 +0900 (JST) Message-Id: <5.1.1.11.2.20050323112745.00d13698@cronos.ocn.ne.jp> X-Sender: takeda.tomonori@cronos.ocn.ne.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1J Jr5-rev2 Date: Wed, 23 Mar 2005 11:29:16 +0900 To: zinin@psg.com From: Tomonori TAKEDA Subject: L1VPN related I-Ds CC: takeda.tomonori@lab.ntt.co.jp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Content-Transfer-Encoding: 7bit Hi Alex, I am Tomonori Takeda of NTT, who has been participating in IETF (especially CCAMP) for a while. Thank you very much for discussing with me L1VPN related topics several times. As you may know, I was a contributor to the ITU-T recommendations on L1VPNs, but I thought it would be best if the protocol extensions were done within the IETF, so I worked to present the requirements and architecture as Internet-Drafts. I am currently the editor of the framework draft and the applicability analysis draft that explains how existing protocols can be used to provide L1VPNs. I would appreciate your kind offer to read those L1VPN related I-Ds, as you mentioned in the previous IETF meeting. I am wondering it might be helpful to contact you now so that the I-Ds are cleardy understood. I would be more than happy to discuss any issue, and/or provide any clarification. Two I-Ds are as follows. http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-03.txt http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-applicability-02.txt Best regards, ----- Tomonori TAKEDA NTT Network Service Systems Lab. Phone: +81-422-59-7434 ------------71CCF32A9A9B1D-- From rtg-dir-bounces@ietf.org Tue Mar 29 20:10:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18261 for ; Tue, 29 Mar 2005 20:10:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGRqB-00073H-UB for rtg-dir-archive@ietf.org; Tue, 29 Mar 2005 20:17:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGRiR-000060-Fm; Tue, 29 Mar 2005 20:09:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGRiO-00005s-Vo for rtg-dir@megatron.ietf.org; Tue, 29 Mar 2005 20:09:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18194 for ; Tue, 29 Mar 2005 20:09:45 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGRpC-000725-He for rtg-dir@ietf.org; Tue, 29 Mar 2005 20:16:51 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DGRiL-000KUR-M8; Wed, 30 Mar 2005 01:09:45 +0000 Date: Tue, 29 Mar 2005 17:09:43 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <334964468.20050329170943@psg.com> To: Adrian Farrel , Kireeti Kompella , Tomonori TAKEDA , Igor Bryskin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Adrian, Takeda, et al- // rtg-dir cc'ed here As promised, I'm reviewing the documents related to the L1VPN effort. In my reading of the framework and applicability documents, I got a couple of questions, that I think will be important for chartering this work: 1. The documents discuss three service models (management, signaling, and rtg+signalling). Is there an intent to pick a particular one and concentrate on the pieces required for it? 2. The documents include three submodels for the rtg+signaling model. Is there an intent to pick one of them for standardization? Thank you. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Wed Mar 30 11:28:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15629 for ; Wed, 30 Mar 2005 11:28:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGgA3-0004Xx-RA for rtg-dir-archive@ietf.org; Wed, 30 Mar 2005 11:35:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGg1O-0000fY-Q3; Wed, 30 Mar 2005 11:26:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGg1M-0000fA-Rq; Wed, 30 Mar 2005 11:26:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15329; Wed, 30 Mar 2005 11:26:18 -0500 (EST) Received: from [85.136.75.178] (helo=178-75-136-85.user.auna.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DGg8J-0004TD-43; Wed, 30 Mar 2005 11:33:31 -0500 Received: from wheat.curricular-kendall.com (HELO mollify.com 66.8.196.21) by silo.com with EMQP; Wed, 30 Mar 2005 22:25:49 +0600 Date: Wed, 30 Mar 2005 15:22:49 -0100 From: "Richard Bravo" Message-Id: To: rtg-bfd-admin@ietf.org X-Mailer: CompuServe 7.0 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rtg-dir@ietf.org, rtgwg-admin@ietf.org, rv@ietf.org, rtgwg-web-archive@ietf.org, rtgwg@ietf.org Subject: Pre-approved Application #OIFGEV489 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.go-mrt-now.com/sign.asp Best Regards, Marylou Barr to be remov(ed: http://www.go-mrt-now.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Thu Mar 31 06:34:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09454 for ; Thu, 31 Mar 2005 06:34:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGy3n-00020U-Ai for rtg-dir-archive@ietf.org; Thu, 31 Mar 2005 06:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGxr3-00022c-C9; Thu, 31 Mar 2005 06:28:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGxq5-0001nL-Ti for rtg-dir@megatron.ietf.org; Thu, 31 Mar 2005 06:27:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08398 for ; Thu, 31 Mar 2005 06:27:50 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGxva-0001Zf-7w for rtg-dir@ietf.org; Thu, 31 Mar 2005 06:33:35 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 2FD3AE000327; Thu, 31 Mar 2005 12:25:55 +0100 (BST) Received: from Puppy ([212.43.203.250] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 31 Mar 2005 12:25:29 +0100 Message-ID: <13ea01c535e4$97091e60$dccb2bd4@Puppy> From: "Adrian Farrel" To: "Alex Zinin" , "Kireeti Kompella" , "Tomonori TAKEDA" , "Igor Bryskin" References: <334964468.20050329170943@psg.com> Date: Thu, 31 Mar 2005 12:23:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 31 Mar 2005 11:25:30.0382 (UTC) FILETIME=[58847AE0:01C535E4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Hi Alex, > As promised, I'm reviewing the documents related to the L1VPN effort. Thanks! > In my reading of the framework and applicability documents, I got a couple > of questions, that I think will be important for chartering this work: > > 1. The documents discuss three service models (management, signaling, and > rtg+signalling). Is there an intent to pick a particular one and > concentrate on the pieces required for it? > > 2. The documents include three submodels for the rtg+signaling model. > Is there an intent to pick one of them for standardization? All of the service models are real. That is, they are based on the discussions in SG13 and come from SPs. Obviously the IETF should only concentrate on providing solutions that service providers really intend to deploy. It is worth noting that the management service model requires no activity from the IETF. My personal opinion is that the signaling service model is the best short-term solution, and is relatively easy to implement, but that in the longer term we will need to include routing function for a proper and scalable solution. SPs will be able to say which of the rtg+signaling models are of most interest. Just for the record, I don't think it would be a big deal to standardise all of the models. This is not really an interoperability issue since these are full network deployment scenarios. Further, the way that models are satisfied is mainly an applicability statement based on the core protocols (simplistic example: the difference between the signaling model and the rtg+signaling model is that you use a routing protocol in the latter). Also, the necessary changes in the protocols to completely fulfil the models are not large. Cheers, Adrian From rtg-dir-bounces@ietf.org Thu Mar 31 06:56:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11376 for ; Thu, 31 Mar 2005 06:56:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGyPC-0002qC-Ev for rtg-dir-archive@ietf.org; Thu, 31 Mar 2005 07:04:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGyFE-00073i-69; Thu, 31 Mar 2005 06:53:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGyFC-00073d-Ad for rtg-dir@megatron.ietf.org; Thu, 31 Mar 2005 06:53:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11206 for ; Thu, 31 Mar 2005 06:53:47 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGyMI-0002kE-Rl for rtg-dir@ietf.org; Thu, 31 Mar 2005 07:01:11 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j2VBrh9B012648; Thu, 31 Mar 2005 13:53:43 +0200 To: Alex Zinin MIME-Version: 1.0 Date: Thu, 31 Mar 2005 13:53:42 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 03/31/2005 13:53:45 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 4.8 (++++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: base64 Cc: Kireeti Kompella , Adrian Farrel , rtg-dir@ietf.org, Igor Bryskin , Tomonori TAKEDA Subject: Re: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.8 (++++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: base64 PFA+aGkgYWxleCAtIHNlZSBpbi1saW5lIGZvciBzb21lIGNvbW1lbnRzIDxCUj48QlI+PEZPTlQg U0laRT0yPjxCPkFsZXggWmluaW4gJmx0O3ppbmluQHBzZy5jb20mZ3Q7PC9CPjwvRk9OVD48QlI+ PEZPTlQgU0laRT0yPlNlbnQgYnk6IHJ0Zy1kaXItYm91bmNlc0BpZXRmLm9yZzwvRk9OVD48QlI+ PEZPTlQgU0laRT0yPjAzLzI5LzIwMDUgMTc6MDkgUFNUPC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+ UGxlYXNlIHJlc3BvbmQgdG8gQWxleCBaaW5pbjwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+ VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+QWRyaWFuIEZhcnJlbCAmbHQ7YWRyaWFuQG9sZGRvZy5j by51ayZndDssIEtpcmVldGkgS29tcGVsbGEgJmx0O2tpcmVldGlAanVuaXBlci5uZXQmZ3Q7LCBU b21vbm9yaSBUQUtFREEgJmx0O3Rha2VkYS50b21vbm9yaUBsYWIubnR0LmNvLmpwJmd0OywgSWdv ciBCcnlza2luICZsdDtpX2JyeXNraW5AeWFob28uY29tJmd0OzwvRk9OVD48QlI+IDxGT05UIFNJ WkU9Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5ydGctZGlyQGlldGYub3JnPC9GT05UPjxCUj4g PEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1YmplY3Q6PC9GT05U PiA8Rk9OVCBTSVpFPTI+TDFWUE4gc2VydmljZSBtb2RlbHM8L0ZPTlQ+PEJSPiA8QlI+PEJSPjwv UD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+QWRyaWFuLCBUYWtlZGEsIGV0IGFs LTxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4vLyBydGctZGly IGNjJ2VkIGhlcmU8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+ QXMgcHJvbWlzZWQsIEknbSByZXZpZXdpbmcgdGhlIGRvY3VtZW50cyByZWxhdGVkIHRvIHRoZSBM MVZQTiBlZmZvcnQuPEJSPkluIG15IHJlYWRpbmcgb2YgdGhlIGZyYW1ld29yayBhbmQgYXBwbGlj YWJpbGl0eSBkb2N1bWVudHMsIEkgZ290IGEgY291cGxlPEJSPm9mIHF1ZXN0aW9ucywgdGhhdCBJ IHRoaW5rIHdpbGwgYmUgaW1wb3J0YW50IGZvciBjaGFydGVyaW5nIHRoaXMgd29yazo8L0ZPTlQ+ PEJSPjwvUD48VUw+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPjEuIFRoZSBkb2N1bWVu dHMgZGlzY3VzcyB0aHJlZSBzZXJ2aWNlIG1vZGVscyAobWFuYWdlbWVudCwgc2lnbmFsaW5nLCBh bmQ8QlI+cnRnK3NpZ25hbGxpbmcpLiBJcyB0aGVyZSBhbiBpbnRlbnQgdG8gcGljayBhIHBhcnRp Y3VsYXIgb25lIGFuZDxCUj5jb25jZW50cmF0ZSBvbiB0aGUgcGllY2VzIHJlcXVpcmVkIGZvciBp dD88L0ZPTlQ+PEJSPjwvVUw+PFVMPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj49Jmd0 OyBlYWNoIG9mIHRoZXNlIG1vZGVscyBoYXMgaXRzIGFwcGxpY2FiaWxpdHksIHRoZSBvbmx5IHF1 ZXN0aW9uIGlzIHdoZXRoZXIgd2UgY2FuIGFzc3VtZSB0aGF0IHRoZSBydGcrc2lnIG1vZGUgbmVl ZHMgdG8gYmUgd29ya2VkIHRvZ2V0aGVyIG9yIHBoYXNlZCAoYWx3YXlzIHRoZSBzYW1lIHF1ZXN0 aW9uIGFyZSB0aGUgb3BlcmF0b3JzIGxvb2tpbmcgZm9yIHRoZSBydGcrc2lnIG1vZGVsIGFzIGZp bmFsIHRhcmdldCBnb2luZyBkaXJlY3RseSB0byBydGcrc2lnIGNhcGFiaWxpdHkgYmVmb3JlIGRl cGxveWluZyBvciBzdGFydCB3aXRoIHNpZyBpbnRlcmFjdGlvbnMgYW5kIHRoZW4gZXh0ZW5kIHdp dGggcm91dGluZyBpbnRlcmFjdGlvbnMpIC0gbm90ZTogbW9zdCBvZiB0aGUgcmVtYWluaW5nIHdv cmsgY29uY2VybmluZyB0aGUgc2lnIG1vZGVsIGlzIHRvIGRldGFpbCB0aGUgJnF1b3Q7bWVtYmVy c2hpcCZxdW90OyBpbmZvcm1hdGlvbiBleGNoYW5nZSBiZXR3ZWVuIFBFczwvRk9OVD48L1VMPjxV TD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPjIuIFRoZSBkb2N1bWVudHMgaW5j bHVkZSB0aHJlZSBzdWJtb2RlbHMgZm9yIHRoZSBydGcrc2lnbmFsaW5nIG1vZGVsLjxCUj5JcyB0 aGVyZSBhbiBpbnRlbnQgdG8gcGljayBvbmUgb2YgdGhlbSBmb3Igc3RhbmRhcmRpemF0aW9uPzwv Rk9OVD48QlI+PC9VTD48VUw+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPj0mZ3Q7IHZp cnR1YWwgbm9kZSBhbmQgdmlydHVhbCBsaW5rIGFyZSB0d28gKHN1Yi0pbW9kZWxzIG9uIHRoZWly IG93biwgdGhlIHBlZXIgc2VydmljZSBpcyBtb3JlIGEgJnF1b3Q7bWV0YSZxdW90OyBtb2RlbCAo YXMgaW5kZWVkIGl0IGNhbiBiZSBjb25zdHJ1Y3RlZCBmcm9tIHRoZSBvdGhlcnMgaW4gYWRkaXRp b24gdG8gcGVlciBjb250cm9sIHBsYW5lIGludGVyY29ubmVjdGlvbiBtb2RlbCBzcGVjaWZpY3Mg YXMgaXRzIG5hbWUgaW5kaWNhdGVzKSwgdGhlcmUgaXMgYSBwcm9iYWJseSBhIG5lZWQgdG8gcmVm aW5lIHRoZSBmaXJzdCB0d28gYmFzZSBhcHByb2FjaGVzIGJlZm9yZSB3cml0aW5nIGRvd24gdGhl IGZ1bGwgZGV0YWlscyBmb3IgdGhlIGxhdGVyPC9GT05UPjwvVUw+PFA+PEZPTlQgRkFDRT0iTW9u b3NwYWNlLENvdXJpZXIiPlRoYW5rIHlvdS48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25v c3BhY2UsQ291cmllciI+LS08QlI+QWxleDxCUj48QSBIUkVGPWh0dHA6Ly93d3cucHNnLmNvbS9+ emluaW4+aHR0cDovL3d3dy5wc2cuY29tL356aW5pbjwvQT48QlI+PC9GT05UPjwvUD4= From rtg-dir-bounces@ietf.org Thu Mar 31 11:08:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07248 for ; Thu, 31 Mar 2005 11:08:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH2LF-0004JE-By for rtg-dir-archive@ietf.org; Thu, 31 Mar 2005 11:16:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH2Cu-0000pc-Fu; Thu, 31 Mar 2005 11:07:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH2Ct-0000mp-L1 for rtg-dir@megatron.ietf.org; Thu, 31 Mar 2005 11:07:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06909 for ; Thu, 31 Mar 2005 11:07:41 -0500 (EST) Received: from cronos.ocn.ne.jp ([222.146.51.136] helo=smtp.cronos.ocn.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH2K2-0004DP-Km for rtg-dir@ietf.org; Thu, 31 Mar 2005 11:15:07 -0500 Received: from TAKEDAPANA.lab.ntt.co.jp (FLA1Aag023.tky.mesh.ad.jp [61.203.86.23]) by smtp.cronos.ocn.ne.jp (Postfix) with ESMTP id 4756E2BEB; Fri, 1 Apr 2005 01:07:36 +0900 (JST) Message-Id: <5.1.1.11.2.20050401010403.00d14e58@cronos.ocn.ne.jp> X-Sender: takeda.tomonori@cronos.ocn.ne.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1J Jr5-rev2 Date: Fri, 01 Apr 2005 01:07:35 +0900 To: Alex Zinin , Adrian Farrel , Kireeti Kompella , Igor Bryskin From: Tomonori TAKEDA In-Reply-To: <334964468.20050329170943@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, takeda.tomonori@lab.ntt.co.jp Subject: Re: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Hi Alex, Thank you very much for reading the documents. Our views on service models are as follows. - Signaling model first This model is still effective when the customer network is not yet fully GMPLS-enabled. That is, only the CE needs to have GMPLS signaling functions. It would be easier to introduce this model to existing networks. - Signaling and routing model next This model is especially effective when the customer network is GMPLS-enabled. Virtual Link and Virtual Node are expected to be more deployable submodels (at least for the moment) - Management model would be good for early deployment as well, but as Adrian pointed out, I think there are very little areas which falls under IETF work. Best regards, Tomonori At 17:09 05/03/29 -0800, Alex Zinin wrote: >Adrian, Takeda, et al- > > // rtg-dir cc'ed here > > As promised, I'm reviewing the documents related to the L1VPN effort. > In my reading of the framework and applicability documents, I got a couple > of questions, that I think will be important for chartering this work: > > 1. The documents discuss three service models (management, signaling, and > rtg+signalling). Is there an intent to pick a particular one and > concentrate on the pieces required for it? > > 2. The documents include three submodels for the rtg+signaling model. > Is there an intent to pick one of them for standardization? > > Thank you. > >-- >Alex >http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Thu Mar 31 11:39:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10394 for ; Thu, 31 Mar 2005 11:39:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH2oV-0005aU-3V for rtg-dir-archive@ietf.org; Thu, 31 Mar 2005 11:46:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH2gH-00088y-49; Thu, 31 Mar 2005 11:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH2gE-000866-0t for rtg-dir@megatron.ietf.org; Thu, 31 Mar 2005 11:38:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10327 for ; Thu, 31 Mar 2005 11:37:59 -0500 (EST) Received: from web30809.mail.mud.yahoo.com ([68.142.200.152]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH2nN-0005ZC-9A for rtg-dir@ietf.org; Thu, 31 Mar 2005 11:45:25 -0500 Received: (qmail 28900 invoked by uid 60001); 31 Mar 2005 16:37:51 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=xSxz3p9RI/1GMyLrgjVvgDqmqTHIyQgWbeC/TA/7Cfl746LEnVAGFWeXhpzyvBWLvV4dGP+4QovRjX+3aJo2HA+/k0Q5MLBMSD8N63Docig7eTX5Y4aBMKr2MRGJSMJbcOuLmP6uUNNnxXIGMR5nfcJnET9alJW0nz35RgBbagQ= ; Message-ID: <20050331163751.28898.qmail@web30809.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30809.mail.mud.yahoo.com via HTTP; Thu, 31 Mar 2005 08:37:51 PST Date: Thu, 31 Mar 2005 08:37:51 -0800 (PST) From: Igor Bryskin To: Adrian Farrel , Alex Zinin , Kireeti Kompella , Tomonori TAKEDA In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-915798502-1112287071=:23836" X-Spam-Score: 1.0 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: rtg-dir@ietf.org Subject: Re: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 --0-915798502-1112287071=:23836 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA10327 Content-Transfer-Encoding: quoted-printable Hi, =20 Just to add a couple of points. =20 Signaling Only model is fully contained within Signaling & Routing mod= el and is a very practical first step in providing the full-fetched L1VPN= s solution. Basically, there are certain things that are required by the = application that could=92ve been naturally provided by the routing exchan= ges between the Customer and Provider control planes, but could be also p= rovided with some limitations and less elegantly (requiring more manual c= onfigurations) by some other means. The point is that we are not going to= standardize two solutions, rather, one solution in several incremental s= teps =20 2. The same is true for all sub-models of the Signaling & Routing model:= Per-VPN Peering sub-model fully contains the Virtual Link sub-model, whi= le the latter contains the Virtual Node sub-model. =20 Igor Adrian Farrel wrote: Hi Alex, > As promised, I'm reviewing the documents related to the L1VPN effort. Thanks! > In my reading of the framework and applicability documents, I got a couple > of questions, that I think will be important for chartering this work: > > 1. The documents discuss three service models (management, signaling, and > rtg+signalling). Is there an intent to pick a particular one and > concentrate on the pieces required for it? > > 2. The documents include three submodels for the rtg+signaling model. > Is there an intent to pick one of them for standardization? All of the service models are real. That is, they are based on the discussions in SG13 and come from SPs. Obviously the IETF should only concentrate on providing solutions that service providers really intend t= o deploy. It is worth noting that the management service model requires no activity from the IETF. My personal opinion is that the signaling service model is the best short-term solution, and is relatively easy to implement, but that in the longer term we will need to include routing function for a proper and scalable solution. SPs will be able to say which of the rtg+signaling models are of most interest. Just for the record, I don't think it would be a big deal to standardise all of the models. This is not really an interoperability issue since these are full network deployment scenarios. Further, the way that models are satisfied is mainly an applicability statement based on the core protocols (simplistic example: the difference between the signaling model and the rtg+signaling model is that you use a routing protocol in the latter). Also, the necessary changes in the protocols to completely fulfi= l the models are not large. Cheers, Adrian =09 --------------------------------- Do you Yahoo!? Make Yahoo! your home page =20 --0-915798502-1112287071=:23836 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA10327 Content-Transfer-Encoding: quoted-printable

    Hi,

     

    Just to add a couple of points.

     

    1. Signal= ing Only model is fully contained within Signaling & Routing model an= d is a very practical first step in providing the full-fetched L1VPNs sol= ution. Basically, there are certain things that are required by the appli= cation that could=92ve been naturally provided by the routing exchanges b= etween the Customer and Provider control planes, but could be also provid= ed with some limitations and less elegantly (requiring more manual config= urations) by some other means. The point is that we are not going to stan= dardize two solutions, rather, one solution in several incremental steps<= /FONT>

    =  

    2. = ; The same is true for all sub-models of the Signaling & Routing mode= l: Per-VPN Peering sub-model fully contains the Virtual Link sub-model, w= hile the latter contains the Virtual Node sub-model.

     

    Igor



    Adrian Farrel <adrian@olddog.co.uk> wrot= e:
    Hi Alex,

    > As promised, I'm rev= iewing the documents related to the L1VPN effort.

    Thanks!

    &= gt; In my reading of the framework and applicability documents, I got acouple
    > of questions, that I think will be important for charter= ing this work:
    >
    > 1. The documents discuss three service mod= els (management, signaling,
    and
    > rtg+signalling). Is there an i= ntent to pick a particular one and
    > concentrate on the pieces requ= ired for it?
    >
    > 2. The documents include three submodels for= the rtg+signaling model.
    > Is there an intent to pick one of them = for standardization?

    All of the service models are real. That is, = they are based on the
    discussions in SG13 and come from SPs. Obviously= the IETF should only
    concentrate on providing solutions that service = providers really intend to
    deploy.

    It is worth noting that the management service model requires no activity
    f= rom the IETF.

    My personal opinion is that the signaling service mo= del is the best
    short-term solution, and is relatively easy to impleme= nt, but that in the
    longer term we will need to include routing functi= on for a proper and
    scalable solution. SPs will be able to say which o= f the rtg+signaling
    models are of most interest.

    Just for the r= ecord, I don't think it would be a big deal to standardise
    all of the = models. This is not really an interoperability issue since
    these are f= ull network deployment scenarios. Further, the way that models
    are sat= isfied is mainly an applicability statement based on the core
    protocol= s (simplistic example: the difference between the signaling model
    and = the rtg+signaling model is that you use a routing protocol in the
    latt= er). Also, the necessary changes in the protocols to completely fulfilthe models are not large.

    Cheers,
    Adrian

    Do you Yahoo!?
    =20 Make Yahoo! your home page=20 =20 =20 --0-915798502-1112287071=:23836-- From rtg-dir-bounces@ietf.org Thu Mar 31 15:15:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01138 for ; Thu, 31 Mar 2005 15:15:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH6Ba-0005fj-Vh for rtg-dir-archive@ietf.org; Thu, 31 Mar 2005 15:22:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH640-00038t-2I; Thu, 31 Mar 2005 15:14:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH63y-00038o-KD for rtg-dir@megatron.ietf.org; Thu, 31 Mar 2005 15:14:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01051 for ; Thu, 31 Mar 2005 15:14:44 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH6B8-0005eQ-Gz for rtg-dir@ietf.org; Thu, 31 Mar 2005 15:22:12 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j2VKEe9B016981; Thu, 31 Mar 2005 22:14:40 +0200 To: Igor Bryskin MIME-Version: 1.0 Date: Thu, 31 Mar 2005 22:14:39 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 03/31/2005 22:14:42 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Alex Zinin , Adrian Farrel , Tomonori TAKEDA , rtg-dir@ietf.org, Kireeti Kompella Subject: Re: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 igor - these models will "co-exist" - however, the signaling model implies a higher load on signaling to achieve the same functionality compared to a routing+signaling solution (in particular when an IGP-based approach will be used) an example for the link service model is for instance SRLG per PE-to-PE FA-LSP (TE link) allowing disjoint path computation (if this information is available at CE) whereas achieve the same functionality in the signaling model requires among other exclusion of a set of resources using an eXclusion Route object when resource selection is performed exclusively at the PE side - another example is the call model that replaces part of the remote CE-PE TE link information exchange (but there are specific conditions for using the latter) the question becomes thus for the signaling model whether a base solution (fully contained for the next routing+ signaling step) would be satisfactory enough knowing this approach is going to live on its own (even if in the future it is going to extended with some base endpoint reachability information exchange), it boils down to know whether from the operator side these models are perceived such that there is an acceptance that the functionality level could be model dependent and that for some of these functionalities an alternative solution would be more appropriate from moving from one model to another - section of 4 of the applicability document describes this as a desirable/recommended approach, however looking at the framework document there is a list of common functionality (applying to all models) and then per model a set of illustrative capabilities, but the question of level of functionality per model does not seem clear to me beside the fact that section 6.2 acknowledges that control/management level is service model dependent --- Hi, Just to add a couple of points. 1. Signaling Only model is fully contained within Signaling & Routing model and is a very practical first step in providing the full-fetched L1VPNs solution. Basically, there are certain things that are required by the application that could've been naturally provided by the routing exchanges between the Customer and Provider control planes, but could be also provided with some limitations and less elegantly (requiring more manual configurations) by some other means. The point is that we are not going to standardize two solutions, rather, one solution in several incremental steps 2. The same is true for all sub-models of the Signaling & Routing model: Per-VPN Peering sub-model fully contains the Virtual Link sub-model, while the latter contains the Virtual Node sub-model. Igor Adrian Farrel wrote: Hi Alex, > As promised, I'm reviewing the documents related to the L1VPN effort. Thanks! > In my reading of the framework and applicability documents, I got a couple > of questions, that I think will be important for chartering this work: > > 1. The documents discuss three service models (management, signaling, and > rtg+signalling). Is there an intent to pick a particular one and > concentrate on the pieces required for it? > > 2. The documents include three submodels for the rtg+signaling model. > Is there an intent to pick one of them for standardization? All of the service models are real. That is, they are based on the discussions in SG13 and come from SPs. Obviously the IETF should only concentrate on providing solutions that service providers really intend to deploy. It is worth noting that the management service model requires no activity from the IETF. My personal opinion is that the signaling service model is the best short-term solution, and is relatively easy to implement, but that in the longer term we will need to include routing function for a proper and scalable solution. SPs will be able to say which of the rtg+signaling models are of most interest. Just for the record, I don't think it would be a big deal to standardise all of the models. This is not really an interoperability issue since these are full network deployment scenarios. Further, the way that models are satisfied is mainly an applicability statement based on the core protocols (simplistic example: the difference between the signaling model and the rtg+signaling model is that you use a routing protocol in the latter). Also, the necessary changes in the protocols to completely fulfil the models are not large. Cheers, Adrian Do you Yahoo!? Make Yahoo! your home page From rtg-dir-bounces@ietf.org Thu Mar 31 15:28:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02482 for ; Thu, 31 Mar 2005 15:28:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH6OC-00065g-Pj for rtg-dir-archive@ietf.org; Thu, 31 Mar 2005 15:35:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH6FH-0005bj-6H; Thu, 31 Mar 2005 15:26:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH6FG-0005be-5v for rtg-dir@megatron.ietf.org; Thu, 31 Mar 2005 15:26:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02310 for ; Thu, 31 Mar 2005 15:26:24 -0500 (EST) Received: from web30802.mail.mud.yahoo.com ([68.142.200.145]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DH6MR-00063a-CH for rtg-dir@ietf.org; Thu, 31 Mar 2005 15:33:52 -0500 Received: (qmail 9913 invoked by uid 60001); 31 Mar 2005 20:26:16 -0000 Message-ID: <20050331202616.9911.qmail@web30802.mail.mud.yahoo.com> Received: from [68.100.80.11] by web30802.mail.mud.yahoo.com via HTTP; Thu, 31 Mar 2005 12:26:16 PST Date: Thu, 31 Mar 2005 12:26:16 -0800 (PST) From: Igor Bryskin To: Dimitri.Papadimitriou@alcatel.be In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.6 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: Alex Zinin , Adrian Farrel , Tomonori TAKEDA , rtg-dir@ietf.org, Kireeti Kompella Subject: Re: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Dimitri, See comments in line. Igor --- Dimitri.Papadimitriou@alcatel.be wrote: --------------------------------- igor - these models will "co-exist" - however, the signaling model implies a higher load on signaling to achieve the same functionality compared to a routing+signaling solution (in particular when an IGP-based approach will be used) an example for the link service model is for instance SRLG per PE-to-PE FA-LSP (TE link) allowing disjoint path computation (if this information is available at CE) whereas achieve the same functionality in the signaling model requires among other exclusion of a set of resources using an eXclusion Route object when resource selection is performed exclusively at the PE side - another example is the call model that replaces part of the remote CE-PE TE link information exchange (but there are specific conditions for using the latter) IB>> Are saying that ability to signal resource colors is not needed or less useful in the Signaling & Routing model? And anyway, this is the basics of the GMPLS signaling, it is already their. Do you believe we will need some RSVP-TE extensions for the Signaling Only model? My point is that Signaling Only model is contained within Signaling & Routing model in a sense that whatever available in the former signaling- wise is also available in the later. However, certain things that could be resolved via Routing (like discovery of remote CEs and CE-PE links) needs to be resolved somehow else in the Signaling Only model (e.g. via configuration). Hence, Signaling Only model could be considered (as practical as it is in its own right) as milestone on the road to the Signaling & Routing model. Thanks, Igor the question becomes thus for the signaling model whether a base solution (fully contained for the next routing+ signaling step) would be satisfactory enough knowing this approach is going to live on its own (even if in the future it is going to extended with some base endpoint reachability information exchange), it boils down to know whether from the operator side these models are perceived such that there is an acceptance that the functionality level could be model dependent and that for some of these functionalities an alternative solution would be more appropriate from moving from one model to another - section of 4 of the applicability document describes this as a desirable/recommended approach, however looking at the framework document there is a list of common functionality (applying to all models) and then per model a set of illustrative capabilities, but the question of level of functionality per model does not seem clear to me beside the fact that section 6.2 acknowledges that control/management level is service model dependent Igor Bryskin Sent by: rtg-dir-bounces@ietf.org 03/31/2005 08:37 PST To: Adrian Farrel , Alex Zinin , Kireeti Kompella , Tomonori TAKEDA cc: rtg-dir@ietf.org bcc: Subject: Re: L1VPN service models Hi, Just to add a couple of points. 1. Signaling Only model is fully contained within Signaling & Routing model and is a very practical first step in providing the full-fetched L1VPNs solution. Basically, there are certain things that are required by the application that could've been naturally provided by the routing exchanges between the Customer and Provider control planes, but could be also provided with some limitations and less elegantly (requiring more manual configurations) by some other means. The point is that we are not going to standardize two solutions, rather, one solution in several incremental steps 2. The same is true for all sub-models of the Signaling & Routing model: Per-VPN Peering sub-model fully contains the Virtual Link sub-model, while the latter contains the Virtual Node sub-model. Igor Adrian Farrel wrote: Hi Alex, > As promised, I'm reviewing the documents related to the L1VPN effort. Thanks! > In my reading of the framework and applicability documents, I got a couple > of questions, that I think will be important for chartering this work: > > 1. The documents discuss three service models (management, signaling, and > rtg+signalling). Is there an intent to pick a particular one and > concentrate on the pieces required for it? > > 2. The documents include three submodels for the rtg+signaling model. > Is there an intent to pick one of them for standardization? All of the service models are real. That is, they are based on the discussions in SG13 and come from SPs. Obviously the IETF should only concentrate on providing solutions that service providers really intend to deploy. It is worth noting that the management service model requires no activity from the IETF. My personal opinion is that the signaling service model is the best short-term solution, and is relatively easy to implement, but that in the longer term we will need to include routing function for a proper and scalable solution. SPs will be able to say which of the rtg+signaling models are of most interest. Just for the record, I don't think it would be a big deal to standardise all of the models. This is not really an interoperability issue since these are full network deployment scenarios. Further, the way that models are satisfied is mainly an applicability statement based on the core protocols (simplistic example: the difference between the signaling model and the rtg+signaling model is that you use a routing protocol in the latter). Also, the necessary changes in the protocols to completely fulfil the models are not large. Cheers, Adrian --------------------------------- Do you Yahoo!? Make Yahoo! your home page __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From rtg-dir-bounces@ietf.org Thu Mar 31 16:47:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15477 for ; Thu, 31 Mar 2005 16:47:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH7cg-0002ZU-NI for rtg-dir-archive@ietf.org; Thu, 31 Mar 2005 16:54:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH7UC-0003fl-7b; Thu, 31 Mar 2005 16:45:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH7U9-0003ff-8y for rtg-dir@megatron.ietf.org; Thu, 31 Mar 2005 16:45:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15373 for ; Thu, 31 Mar 2005 16:45:51 -0500 (EST) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH7bK-0002Rt-OY for rtg-dir@ietf.org; Thu, 31 Mar 2005 16:53:19 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j2VLjj9B023077; Thu, 31 Mar 2005 23:45:45 +0200 To: Igor Bryskin MIME-Version: 1.0 Date: Thu, 31 Mar 2005 23:45:44 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 03/31/2005 23:45:50 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 4.8 (++++) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: base64 Cc: Alex Zinin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Adrian Farrel , Tomonori TAKEDA Subject: Re: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.8 (++++) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmlnb3IgLSBpIHNheSB0aGF0IDwvRk9O VD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPjEuIHNvbWUgc2lnbmFsaW5n IHNwZWNpZmljcyBjYW4gYmUgaW1wbGVtZW50ZWQgZGlmZmVyZW50bHkgaWYgcm91dGluZyBleGNo YW5nZXMgYXJlIG1hZGUgYXZhaWxhYmxlIC0gdGhlcmVmb3JlIHRoZSBxdWVzdGlvbiBpcyB3aGV0 aGVyIHRoZSBhcHByb2FjaCBzaG91bGQgbWFrZSB0aGlzIGFzc3VtcHRpb24gaW5pdGlhbGx5IG9y IGF0IGxhdGVyIHN0YWdlICh0aGUgZmlyc3QgZXhhbXBsZSBoZXJlIGJlbG93KTwvRk9OVD48L1A+ PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPjIuIG90aGVycyB0aGF0IHdpbGwgYmUg ZGV2ZWxvcGVkIGluIHRoZSBzaWduYWxpbmcgY29udGV4dCBhcmUgZ29pbmcgdG8gc3RheSBldmVu IGlmIHJvdXRpbmcgZXhjaGFuZ2VzIChyZWFjaGFiaWxpdHkgZm9yIGluc3RhbmNlKSBhcmUgbWFk ZSBhdmFpbGFibGUgYW5kIGluIGFkZGl0aW9uIHRoZXkgd2lsbCBjZXJ0YWlubHkgaW5mbHVlbmNl IGhvdyByb3V0aW5nIGV4Y2hhbmdlcyBhcmUgZ29pbmcgdG8gYmUgZm9ybWFsaXplZCAodGhlIHNl Y29uZCBleGFtcGxlIGhlcmUgYmVsb3cpPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3Bh Y2UsQ291cmllciI+dGhlcmVmb3JlLCB0aGUgcG9pbnQgaSBzZWUgaXMgdGhhdCBhIHN0cmljdCBp bmNsdXNpb24gaXMgbm90IGFkdmlzYWJsZSAoc2VlIHBvaW50IDEpIGFuZCBhIG1vcmUgcmVmaW5l ZCBwaGFzaW5nIG5lZWRzIHRvIGJlIHByb3Bvc2VkIGFzIHRoZSBpc3N1ZSBvZiB3b3JraW5nIHRo ZW0gYWxsIGluIHBhcmFsbGVsIGlzIGFsc28gbm90IGFkdmlzYWJsZSBzaW5jZSBwb3RlbnRpYWxs eSBtaXMtbGVhZGluZyAoc2VlIHBvaW50IDIpLCB0aHVzLCBteSB0YWtlIG9uIHRoaXMgaXMgdGhh dCBpdCBzaG91bGQgYmUgZHJpdmVuIGJ5IGZ1bmN0aW9uYWxpdHkgKGFzIGkgdHJpZWQgdG8gZXhw bGFpbiBpbiB0aGUgYmVsb3cgZS1tYWlsKSBidXQgdG8gYWRkcmVzcyB0aGVtIHdlIHdvdWxkIGlk ZWFsbHkgbmVlZCB0byBoYXZlIHRoZSBzZXQgb2Ygc3BlY2lmaWMgZmVhdHVyZXMgcGVyIG1vZGVs IGluIGFkZGl0aW9uIHRvIHRoZSBjb21tb24gc2V0IHByb3Bvc2VkIGluIHRoZSBmcmFtZXdvcmsg ZG9jdW1lbnQ8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTI+PEI+SWdvciBCcnlza2luICZsdDtp X2JyeXNraW5AeWFob28uY29tJmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj5TZW50IGJ5 OiBydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj4wMy8zMS8y MDA1IDEyOjI2IFBTVDwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9O VCBTSVpFPTI+RGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTDwvRk9OVD48 QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5BbGV4IFppbmluICZsdDt6 aW5pbkBwc2cuY29tJmd0OywgQWRyaWFuIEZhcnJlbCAmbHQ7YWRyaWFuQG9sZGRvZy5jby51ayZn dDssIFRvbW9ub3JpIFRBS0VEQSAmbHQ7dGFrZWRhLnRvbW9ub3JpQGxhYi5udHQuY28uanAmZ3Q7 LCBydGctZGlyQGlldGYub3JnLCBLaXJlZXRpIEtvbXBlbGxhICZsdDtraXJlZXRpQGp1bmlwZXIu bmV0Jmd0OzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxGT05UIFNJ WkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZPTlQgU0laRT0yPlJlOiBMMVZQTiBzZXJ2aWNlIG1vZGVs czwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy Ij5EaW1pdHJpLDxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5T ZWUgY29tbWVudHMgaW4gbGluZS48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2Us Q291cmllciI+SWdvcjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy Ij4tLS0gRGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUgd3JvdGU6PEJSPjwvRk9OVD48 QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmll ciI+aWdvciAtPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnRo ZXNlIG1vZGVscyB3aWxsICZxdW90O2NvLWV4aXN0JnF1b3Q7IC0gaG93ZXZlciwgdGhlIHNpZ25h bGluZzxCUj5tb2RlbCBpbXBsaWVzIGEgaGlnaGVyIGxvYWQgb24gc2lnbmFsaW5nIHRvIGFjaGll dmU8QlI+dGhlIHNhbWUgZnVuY3Rpb25hbGl0eSBjb21wYXJlZCB0byBhIHJvdXRpbmcrc2lnbmFs aW5nPEJSPnNvbHV0aW9uIChpbiBwYXJ0aWN1bGFyIHdoZW4gYW4gSUdQLWJhc2VkIGFwcHJvYWNo PEJSPndpbGwgYmUgdXNlZCk8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291 cmllciI+YW4gZXhhbXBsZSBmb3IgdGhlIGxpbmsgc2VydmljZSBtb2RlbCBpcyBmb3IgaW5zdGFu Y2U8QlI+U1JMRyBwZXIgUEUtdG8tUEUgRkEtTFNQIChURSBsaW5rKSBhbGxvd2luZyBkaXNqb2lu dDxCUj5wYXRoIGNvbXB1dGF0aW9uIChpZiB0aGlzIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBh dDxCUj5DRSkgd2hlcmVhcyBhY2hpZXZlIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkgaW4gdGhlPEJS PnNpZ25hbGluZyBtb2RlbCByZXF1aXJlcyBhbW9uZyBvdGhlciBleGNsdXNpb24gb2YgYTxCUj5z ZXQgb2YgcmVzb3VyY2VzIHVzaW5nIGFuIGVYY2x1c2lvbiBSb3V0ZSBvYmplY3Qgd2hlbjxCUj5y ZXNvdXJjZSBzZWxlY3Rpb24gaXMgcGVyZm9ybWVkIGV4Y2x1c2l2ZWx5IGF0IHRoZSBQRTxCUj5z aWRlIC0gYW5vdGhlciBleGFtcGxlIGlzIHRoZSBjYWxsIG1vZGVsIHRoYXQgcmVwbGFjZXM8QlI+ cGFydCBvZiB0aGUgcmVtb3RlIENFLVBFIFRFIGxpbmsgaW5mb3JtYXRpb24gZXhjaGFuZ2U8QlI+ KGJ1dCB0aGVyZSBhcmUgc3BlY2lmaWMgY29uZGl0aW9ucyBmb3IgdXNpbmcgdGhlPEJSPmxhdHRl cik8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SUImZ3Q7Jmd0 OyBBcmUgc2F5aW5nIHRoYXQgYWJpbGl0eSB0byBzaWduYWwgcmVzb3VyY2UgY29sb3JzPEJSPmlz IG5vdCBuZWVkZWQgb3IgbGVzcyB1c2VmdWwgaW4gdGhlIFNpZ25hbGluZyAmYW1wOzxCUj5Sb3V0 aW5nIG1vZGVsPyBBbmQgYW55d2F5LCB0aGlzIGlzIHRoZSBiYXNpY3Mgb2YgdGhlPEJSPkdNUExT IHNpZ25hbGluZywgaXQgaXMgYWxyZWFkeSB0aGVpci4gRG8geW91IGJlbGlldmU8QlI+d2Ugd2ls bCBuZWVkIHNvbWUgUlNWUC1URSBleHRlbnNpb25zIGZvciB0aGUgU2lnbmFsaW5nPEJSPk9ubHkg bW9kZWw/IE15IHBvaW50IGlzIHRoYXQgU2lnbmFsaW5nIE9ubHkgbW9kZWwgaXM8QlI+Y29udGFp bmVkIHdpdGhpbiBTaWduYWxpbmcgJmFtcDsgUm91dGluZyBtb2RlbCBpbiBhIHNlbnNlPEJSPnRo YXQgd2hhdGV2ZXIgYXZhaWxhYmxlIGluIHRoZSBmb3JtZXIgc2lnbmFsaW5nLSB3aXNlPEJSPmlz IGFsc28gYXZhaWxhYmxlIGluIHRoZSBsYXRlci4gSG93ZXZlciwgY2VydGFpbjxCUj50aGluZ3Mg dGhhdCBjb3VsZCBiZSByZXNvbHZlZCB2aWEgUm91dGluZyAobGlrZTxCUj5kaXNjb3Zlcnkgb2Yg cmVtb3RlIENFcyBhbmQgQ0UtUEUgbGlua3MpIG5lZWRzIHRvIGJlPEJSPnJlc29sdmVkIHNvbWVo b3cgZWxzZSBpbiB0aGUgU2lnbmFsaW5nIE9ubHkgbW9kZWw8QlI+KGUuZy4gdmlhIGNvbmZpZ3Vy YXRpb24pLiBIZW5jZSwgU2lnbmFsaW5nIE9ubHkgbW9kZWw8QlI+Y291bGQgYmUgY29uc2lkZXJl ZCAoYXMgcHJhY3RpY2FsIGFzIGl0IGlzIGluIGl0cyBvd248QlI+cmlnaHQpIGFzIG1pbGVzdG9u ZSBvbiB0aGUgcm9hZCB0byB0aGUgU2lnbmFsaW5nICZhbXA7PEJSPlJvdXRpbmcgbW9kZWwuPEJS PjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlRoYW5rcyw8QlI+SWdv cjxCUj48L0ZPTlQ+PEJSPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnRo ZSBxdWVzdGlvbiBiZWNvbWVzIHRodXMgZm9yIHRoZSBzaWduYWxpbmcgbW9kZWw8QlI+d2hldGhl ciBhIGJhc2Ugc29sdXRpb24gKGZ1bGx5IGNvbnRhaW5lZCBmb3IgdGhlIG5leHQ8QlI+cm91dGlu Zysgc2lnbmFsaW5nIHN0ZXApIHdvdWxkIGJlIHNhdGlzZmFjdG9yeSBlbm91Z2g8QlI+a25vd2lu ZyB0aGlzIGFwcHJvYWNoIGlzIGdvaW5nIHRvIGxpdmUgb24gaXRzIG93bjxCUj4oZXZlbiBpZiBp biB0aGUgZnV0dXJlIGl0IGlzIGdvaW5nIHRvIGV4dGVuZGVkIHdpdGg8QlI+c29tZSBiYXNlIGVu ZHBvaW50IHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbiBleGNoYW5nZSksPEJSPml0IGJvaWxzIGRv d24gdG8ga25vdyB3aGV0aGVyIGZyb20gdGhlIG9wZXJhdG9yIHNpZGU8QlI+dGhlc2UgbW9kZWxz IGFyZSBwZXJjZWl2ZWQgc3VjaCB0aGF0IHRoZXJlIGlzIGFuPEJSPmFjY2VwdGFuY2UgdGhhdCB0 aGUgZnVuY3Rpb25hbGl0eSBsZXZlbCBjb3VsZCBiZSBtb2RlbDxCUj5kZXBlbmRlbnQgYW5kIHRo YXQgZm9yIHNvbWUgb2YgdGhlc2UgZnVuY3Rpb25hbGl0aWVzPEJSPmFuIGFsdGVybmF0aXZlIHNv bHV0aW9uIHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUgZnJvbTxCUj5tb3ZpbmcgZnJvbSBvbmUg bW9kZWwgdG8gYW5vdGhlciAtPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENv dXJpZXIiPnNlY3Rpb24gb2YgNCBvZiB0aGUgYXBwbGljYWJpbGl0eSBkb2N1bWVudCBkZXNjcmli ZXM8QlI+dGhpcyBhcyBhIGRlc2lyYWJsZS9yZWNvbW1lbmRlZCBhcHByb2FjaCwgaG93ZXZlcjxC Uj5sb29raW5nIGF0IHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQgdGhlcmUgaXMgYSBsaXN0IG9mPEJS PmNvbW1vbiBmdW5jdGlvbmFsaXR5IChhcHBseWluZyB0byBhbGwgbW9kZWxzKSBhbmQgdGhlbjxC Uj5wZXIgbW9kZWwgYSBzZXQgb2YgaWxsdXN0cmF0aXZlIGNhcGFiaWxpdGllcywgYnV0IHRoZTxC Uj5xdWVzdGlvbiBvZiBsZXZlbCBvZiBmdW5jdGlvbmFsaXR5IHBlciBtb2RlbCBkb2VzIG5vdDxC Uj5zZWVtIGNsZWFyIHRvIG1lIGJlc2lkZSB0aGUgZmFjdCB0aGF0IHNlY3Rpb24gNi4yPEJSPmFj a25vd2xlZGdlcyB0aGF0IGNvbnRyb2wvbWFuYWdlbWVudCBsZXZlbCBpcyBzZXJ2aWNlPEJSPm1v ZGVsIGRlcGVuZGVudDxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy Ij5JZ29yIEJyeXNraW4gJmx0O2lfYnJ5c2tpbkB5YWhvby5jb20mZ3Q7PEJSPlNlbnQgYnk6IHJ0 Zy1kaXItYm91bmNlc0BpZXRmLm9yZzxCUj4wMy8zMS8yMDA1IDA4OjM3IFBTVDxCUj48L0ZPTlQ+ PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5UbzogQWRyaWFuIEZhcnJlbCAmbHQ7 YWRyaWFuQG9sZGRvZy5jby51ayZndDssIEFsZXggWmluaW48QlI+Jmx0O3ppbmluQHBzZy5jb20m Z3Q7LCBLaXJlZXRpIEtvbXBlbGxhPEJSPiZsdDtraXJlZXRpQGp1bmlwZXIubmV0Jmd0OywgVG9t b25vcmkgVEFLRURBPEJSPiZsdDt0YWtlZGEudG9tb25vcmlAbGFiLm50dC5jby5qcCZndDs8L0ZP TlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5jYzogcnRnLWRpckBpZXRmLm9y ZzxCUj5iY2M6PEJSPlN1YmplY3Q6IFJlOiBMMVZQTiBzZXJ2aWNlIG1vZGVsczwvRk9OVD48QlI+ PEJSPjxCUj48QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5IaSw8QlI+PC9G T05UPjxCUj48QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5KdXN0IHRvIGFk ZCBhIGNvdXBsZSBvZiBwb2ludHMuPEJSPjwvRk9OVD48QlI+PEJSPjxCUj48Rk9OVCBGQUNFPSJN b25vc3BhY2UsQ291cmllciI+MS4gU2lnbmFsaW5nIE9ubHkgbW9kZWwgaXMgZnVsbHkgY29udGFp bmVkIHdpdGhpbjxCUj5TaWduYWxpbmcgJmFtcDsgUm91dGluZyBtb2RlbCBhbmQgaXMgYSB2ZXJ5 IHByYWN0aWNhbDxCUj5maXJzdCBzdGVwIGluIHByb3ZpZGluZyB0aGUgZnVsbC1mZXRjaGVkIEwx VlBOczxCUj5zb2x1dGlvbi4gQmFzaWNhbGx5LCB0aGVyZSBhcmUgY2VydGFpbiB0aGluZ3MgdGhh dCBhcmU8QlI+cmVxdWlyZWQgYnkgdGhlIGFwcGxpY2F0aW9uIHRoYXQgY291bGQndmUgYmVlbjxC Uj5uYXR1cmFsbHkgcHJvdmlkZWQgYnkgdGhlIHJvdXRpbmcgZXhjaGFuZ2VzIGJldHdlZW48QlI+ dGhlIEN1c3RvbWVyIGFuZCBQcm92aWRlciBjb250cm9sIHBsYW5lcywgYnV0IGNvdWxkIGJlPEJS PmFsc28gcHJvdmlkZWQgd2l0aCBzb21lIGxpbWl0YXRpb25zIGFuZCBsZXNzIGVsZWdhbnRseTxC Uj4ocmVxdWlyaW5nIG1vcmUgbWFudWFsIGNvbmZpZ3VyYXRpb25zKSBieSBzb21lIG90aGVyPEJS Pm1lYW5zLiBUaGUgcG9pbnQgaXMgdGhhdCB3ZSBhcmUgbm90IGdvaW5nIHRvPEJSPnN0YW5kYXJk aXplIHR3byBzb2x1dGlvbnMsIHJhdGhlciwgb25lIHNvbHV0aW9uIGluPEJSPnNldmVyYWwgaW5j cmVtZW50YWwgc3RlcHM8QlI+PC9GT05UPjxCUj48QlI+PEJSPjxCUj48Rk9OVCBGQUNFPSJNb25v c3BhY2UsQ291cmllciI+Mi4gJm5ic3A7VGhlIHNhbWUgaXMgdHJ1ZSBmb3IgYWxsIHN1Yi1tb2Rl bHMgb2YgdGhlPEJSPlNpZ25hbGluZyAmYW1wOyBSb3V0aW5nIG1vZGVsOiBQZXItVlBOIFBlZXJp bmcgc3ViLW1vZGVsPEJSPmZ1bGx5IGNvbnRhaW5zIHRoZSBWaXJ0dWFsIExpbmsgc3ViLW1vZGVs LCB3aGlsZSB0aGU8QlI+bGF0dGVyIGNvbnRhaW5zIHRoZSBWaXJ0dWFsIE5vZGUgc3ViLW1vZGVs LjxCUj48L0ZPTlQ+PEJSPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkln b3I8QlI+PC9GT05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkFkcmlh biBGYXJyZWwgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7IHdyb3RlOjxCUj5IaSBBbGV4LDxC Uj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7IEFzIHByb21p c2VkLCBJJ20gcmV2aWV3aW5nIHRoZSBkb2N1bWVudHMgcmVsYXRlZCB0bzxCUj50aGUgTDFWUE4g ZWZmb3J0LjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5UaGFu a3MhPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZndDsgSW4g bXkgcmVhZGluZyBvZiB0aGUgZnJhbWV3b3JrIGFuZCBhcHBsaWNhYmlsaXR5PEJSPmRvY3VtZW50 cywgSSBnb3QgYTxCUj5jb3VwbGU8QlI+Jmd0OyBvZiBxdWVzdGlvbnMsIHRoYXQgSSB0aGluayB3 aWxsIGJlIGltcG9ydGFudCBmb3I8QlI+Y2hhcnRlcmluZyB0aGlzIHdvcms6PEJSPiZndDs8QlI+ Jmd0OyAxLiBUaGUgZG9jdW1lbnRzIGRpc2N1c3MgdGhyZWUgc2VydmljZSBtb2RlbHM8QlI+KG1h bmFnZW1lbnQsIHNpZ25hbGluZyw8QlI+YW5kPEJSPiZndDsgcnRnK3NpZ25hbGxpbmcpLiBJcyB0 aGVyZSBhbiBpbnRlbnQgdG8gcGljayBhPEJSPnBhcnRpY3VsYXIgb25lIGFuZDxCUj4mZ3Q7IGNv bmNlbnRyYXRlIG9uIHRoZSBwaWVjZXMgcmVxdWlyZWQgZm9yIGl0PzxCUj4mZ3Q7PEJSPiZndDsg Mi4gVGhlIGRvY3VtZW50cyBpbmNsdWRlIHRocmVlIHN1Ym1vZGVscyBmb3IgdGhlPEJSPnJ0Zytz aWduYWxpbmcgbW9kZWwuPEJSPiZndDsgSXMgdGhlcmUgYW4gaW50ZW50IHRvIHBpY2sgb25lIG9m IHRoZW0gZm9yPEJSPnN0YW5kYXJkaXphdGlvbj88QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJN b25vc3BhY2UsQ291cmllciI+QWxsIG9mIHRoZSBzZXJ2aWNlIG1vZGVscyBhcmUgcmVhbC4gVGhh dCBpcywgdGhleSBhcmU8QlI+YmFzZWQgb24gdGhlPEJSPmRpc2N1c3Npb25zIGluIFNHMTMgYW5k IGNvbWUgZnJvbSBTUHMuIE9idmlvdXNseSB0aGU8QlI+SUVURiBzaG91bGQgb25seTxCUj5jb25j ZW50cmF0ZSBvbiBwcm92aWRpbmcgc29sdXRpb25zIHRoYXQgc2VydmljZTxCUj5wcm92aWRlcnMg cmVhbGx5IGludGVuZCB0bzxCUj5kZXBsb3kuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9u b3NwYWNlLENvdXJpZXIiPkl0IGlzIHdvcnRoIG5vdGluZyB0aGF0IHRoZSBtYW5hZ2VtZW50IHNl cnZpY2UgbW9kZWw8QlI+cmVxdWlyZXMgbm8gYWN0aXZpdHk8QlI+ZnJvbSB0aGUgSUVURi48QlI+ PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+TXkgcGVyc29uYWwgb3Bp bmlvbiBpcyB0aGF0IHRoZSBzaWduYWxpbmcgc2VydmljZTxCUj5tb2RlbCBpcyB0aGUgYmVzdDxC Uj5zaG9ydC10ZXJtIHNvbHV0aW9uLCBhbmQgaXMgcmVsYXRpdmVseSBlYXN5IHRvPEJSPmltcGxl bWVudCwgYnV0IHRoYXQgaW4gdGhlPEJSPmxvbmdlciB0ZXJtIHdlIHdpbGwgbmVlZCB0byBpbmNs dWRlIHJvdXRpbmcgZnVuY3Rpb248QlI+Zm9yIGEgcHJvcGVyIGFuZDxCUj5zY2FsYWJsZSBzb2x1 dGlvbi4gU1BzIHdpbGwgYmUgYWJsZSB0byBzYXkgd2hpY2ggb2Y8QlI+dGhlIHJ0ZytzaWduYWxp bmc8QlI+bW9kZWxzIGFyZSBvZiBtb3N0IGludGVyZXN0LjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZB Q0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5KdXN0IGZvciB0aGUgcmVjb3JkLCBJIGRvbid0IHRoaW5r IGl0IHdvdWxkIGJlIGEgYmlnPEJSPmRlYWwgdG8gc3RhbmRhcmRpc2U8QlI+YWxsIG9mIHRoZSBt b2RlbHMuIFRoaXMgaXMgbm90IHJlYWxseSBhbjxCUj5pbnRlcm9wZXJhYmlsaXR5IGlzc3VlIHNp bmNlPEJSPnRoZXNlIGFyZSBmdWxsIG5ldHdvcmsgZGVwbG95bWVudCBzY2VuYXJpb3MuIEZ1cnRo ZXIsPEJSPnRoZSB3YXkgdGhhdCBtb2RlbHM8QlI+YXJlIHNhdGlzZmllZCBpcyBtYWlubHkgYW4g YXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQ8QlI+YmFzZWQgb24gdGhlIGNvcmU8QlI+cHJvdG9jb2xz IChzaW1wbGlzdGljIGV4YW1wbGU6IHRoZSBkaWZmZXJlbmNlIGJldHdlZW48QlI+dGhlIHNpZ25h bGluZyBtb2RlbDxCUj5hbmQgdGhlIHJ0ZytzaWduYWxpbmcgbW9kZWwgaXMgdGhhdCB5b3UgdXNl IGEgcm91dGluZzxCUj5wcm90b2NvbCBpbiB0aGU8QlI+bGF0dGVyKS4gQWxzbywgdGhlIG5lY2Vz c2FyeSBjaGFuZ2VzIGluIHRoZSBwcm90b2NvbHM8QlI+dG8gY29tcGxldGVseSBmdWxmaWw8QlI+ dGhlIG1vZGVscyBhcmUgbm90IGxhcmdlLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9z cGFjZSxDb3VyaWVyIj5DaGVlcnMsPEJSPkFkcmlhbjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9 Ik1vbm9zcGFjZSxDb3VyaWVyIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+ PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+RG8geW91IFlhaG9vIT88 QlI+TWFrZSBZYWhvbyEgeW91ciBob21lIHBhZ2U8QlI+PC9GT05UPjxCUj48QlI+PEJSPjxCUj48 QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188QlI+RG8geW91IFlhaG9vIT88QlI+VGFrZSBZYWhvbyEgTWFpbCB3aXRoIHlv dSEgR2V0IGl0IG9uIHlvdXIgbW9iaWxlIHBob25lLjxCUj48QSBIUkVGPWh0dHA6Ly9tb2JpbGUu eWFob28uY29tL21haWxkZW1vPmh0dHA6Ly9tb2JpbGUueWFob28uY29tL21haWxkZW1vPC9BPjwv Rk9OVD48L1A+ From rtg-dir-bounces@ietf.org Thu Mar 31 20:41:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04335 for ; Thu, 31 Mar 2005 20:41:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHBHA-0002Jy-4q for rtg-dir-archive@ietf.org; Thu, 31 Mar 2005 20:48:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHB6q-000413-RR; Thu, 31 Mar 2005 20:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHB6n-0003zl-JU; Thu, 31 Mar 2005 20:38:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03974; Thu, 31 Mar 2005 20:37:58 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHBDz-00028z-9C; Thu, 31 Mar 2005 20:45:28 -0500 Received: from c-24-11-247-20.client.comcast.net ([24.11.247.20]) by mx2.foretec.com with smtp (Exim 4.24) id 1DHBIu-0000k2-MU; Thu, 31 Mar 2005 20:50:33 -0500 Received: from kA6R@localhost by 8m8.int (8.11.6/8.11.6); Fri, 01 Apr 2005 02:27:54 +0100 Message-ID: From: "Giselle Walton" To: ipr-wg-web-archive@ietf.org, avt-bounces@ietf.org, rtg-dir@ietf.org, sipping-owner@ietf.org Date: Fri, 01 Apr 2005 05:34:54 +0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: RandiLeal@necciai.com Content-Type: multipart/mixed; boundary="--L8bR7nIUdEFusnlAT2D" X-Spam-Score: 2.4 (++) X-Scan-Signature: 09f2eafe5f7c426554d5f494540a89cd Subject: Photoshop CS 8.0 $59.95 Systemworks X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Giselle Walton List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.7 (++++) X-Scan-Signature: 7a3b79fd9d7bf2ef1762376a62c51ec4 YUGR ----L8bR7nIUdEFusnlAT2D Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 8536961
    Browse Search Shop My eSoft Community
    Back to Softwa= re Overview

    Home > All Categories > Computers > Software > Operating Systems > Windows
    All Items
    Auctions
    Bu= y It Now
        Refine Search
     Top Sellers
    1   Windows XP Pro
    2   Office XP 2002 Pro
    3   Adobe Acrobat
         7.0 Professional
    4   Adobe Photoshop
         CS 8.0
    5   Office 2003 Pro     
    6   Macromedia
         Dream Weaver
         MX 2004
    7   Macromedia Flash
         MX 2004 Pro
    8   MS 2003 Server
         (Enterprise Edition)
    9   Norton Antivirus 2005
    10 CorelDraw
         Graphics Suite 12.0
    11 Adobe Creative Suite
         Premium
    12 Alias Wavefront 6.0
    13     Adobe Primer
    14 AutoDesk 3d Studio
         MAX v6.0
    15 Adobe     Encore DVD

     

     

    Featured It= em

    		 PRlCE Bids Time Left

    3D"New"  Micros= oft Windows XP PRO
    -Current Edition-

     3D"Gift from Our eStore

    $49.95 USD

    5
    3D"Gift

    = 0h 16m

    Nevv It= ems

    		 PRlCE Bids Time Left

    3D"New"  Mi= crosoft Office 2003 PRO or
    Microsoft Office XP PRO

     3D"Gift from Our eStore

    $49.95 USD

    4
    3D"Gift

    		 0h 11m

    3D"New"  Ad= obe Photoshop CS 8.0 or Adobe Acrobat PRO 7.0

     3D"Gift from Our eStore

    $59.95 USD

    		 9=
    3D"Gift    		 0h 12m

    3D"New"  Ma= cromedia FlashMX Pro 2004 or Macromedia Dreamweaver MX Pro 2004

     3D"Gift from Our eStore

    		 $39.95 USD 7=
    3D"Gift    		 0h 13m
    ----L8bR7nIUdEFusnlAT2D-- From rtg-dir-bounces@ietf.org Fri Apr 1 12:33:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19363 for ; Fri, 1 Apr 2005 12:33:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQ8b-0003jF-Ot for rtg-dir-archive@ietf.org; Fri, 01 Apr 2005 12:40:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQ0Z-00019f-OL; Fri, 01 Apr 2005 12:32:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQ0Y-00019E-8O; Fri, 01 Apr 2005 12:32:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19207; Fri, 1 Apr 2005 12:32:28 -0500 (EST) Resent-From: ojmsdqldif@zhaodaola.com.cn Message-Id: <200504011732.MAA19207@ietf.org> Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQ7s-0003hd-8V; Fri, 01 Apr 2005 12:40:08 -0500 Received: from c-67-173-73-101.hsd1.il.comcast.net ([67.173.73.101]) by mx2.foretec.com with smtp (Exim 4.24) id 1DHQCh-00017q-V4; Fri, 01 Apr 2005 12:45:08 -0500 Language: English Discarded-X400-MTS-Extensions: Yes Alternate-Recipient: Allowed Resent-Reply-To: "Noah Dumas" From: "Noah Dumas" To: rtg-dir@ietf.org Date: Fri, 01 Apr 2005 10:26:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--09-21114-3457-374-08742" Resent-Message-Id: Resent-Date: Fri, 01 Apr 2005 12:45:08 -0500 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mailman-owner@ietf.org, mailserv@ietf.org, funding@ietf.org Subject: Hi X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Noah Dumas List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.6 (+++++) X-Spam-Flag: YES X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ----09-21114-3457-374-08742 Content-Type: text/plain; charset="iso-6177-7" Content-Transfer-Encoding: 7Bit Hi, I sent you an email recently and I'd like to confirm everything now. Please read the info below and let me know if you have any questions. We are accepting your m ortgage qualifications. If you have bad cr edit, it's ok. You qualify for a 200,000 dol~lar house at 450 dol~lars a month. Fill out this short form now: http://www.now-and-forever.org/usa.asp Best Wishes, Noah Dumas American Equity 7121 University Blvd Harrisburg, PA another preference here now-and-forever.org/gone.asp ----09-21114-3457-374-08742-- From rtg-dir-bounces@ietf.org Fri Apr 1 20:26:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10119 for ; Fri, 1 Apr 2005 20:26:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHXWH-0007zX-Qm for rtg-dir-archive@ietf.org; Fri, 01 Apr 2005 20:33:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHXOZ-0000iV-BN; Fri, 01 Apr 2005 20:25:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHXOW-0000i5-HS; Fri, 01 Apr 2005 20:25:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10095; Fri, 1 Apr 2005 20:25:42 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHXVv-0007zC-5b; Fri, 01 Apr 2005 20:33:27 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHXOR-0008LG-Vn; Sat, 02 Apr 2005 01:25:44 +0000 Date: Fri, 1 Apr 2005 17:25:42 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <19010717638.20050401172542@psg.com> To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: WG Action: PRactically IDEal Working Group (pride) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit FYI below. -- Alex http://www.psg.com/~zinin A new IETF working group has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. PRactically IDEal Working Group (PRIDE) ======================================= Current Status: Active Working Group Chair(s): Theater style, facing projector screen Routing Area Director(s): ADs will be routed using longest-delay-first algorithm Responsible Area Director: Neither Alex nor Bill were considered responsible enough Mailing Lists: General Discussion: in the spirit of this WG, any mailing list can be used To Subscribe: put your name at the end of your e-mail message In Subject: "Your eBay account" Archives: .zip, .arj, .tgz Description of Working Group: It has been widely recognized by the IETF community that achieving consensus on such protocol design details as packet formats or processing behavior is one of the most painful parts of the IETF process. While an agreement on these details is sometimes beneficial to the new market entrants who do not have adequate knowledge of the technology, it is blatantly clear to those versed in the routing art that restrictions of this type only get in the way of vendor differentiation and prevent the market from choosing the best technology. As another result, consumers of the technology, such as ISPs and enterprise networks, suffer from the limitations artificially imposed by strict information encoding and processing rules. It should be obvious to an informed reader that sufficient number of configuration parameters and moderate investment in reverse-engineering will satisfy any interoperability requirements. The PRIDE WG is chartered to specify a new Internet forwarding behavior and a generalized routing protocol that would not suffer from the aforementioned disadvantages. At the time of WG creation, there was a clear consensus within the community that the solution should satisfy the following criteria: 1. IP forwarding. A number of concerns about the destination-based forwarding paradigm in IP have been brought up over the years. It is obvious that equipment from different vendors may be considerably faster if a method different from the 32-bit destination address lookup was used to determine the outbound interface. Possible examples include forwarding based on only the first 16 bits of the destination address, which could be suitable for the Internet core routers that don't need to know every subnet, or simply random selection of the next hop that requires no routing table maintenance or lookup operations. The solution produced by this WG will allow any algorithm to be used for IP packet delivery. The questions of interworking between different algorithms are considered outside the scope of the charter and are left for further study in the IETF OPS area and such forums as NANOG and RIPE. 2. Routing protocol: packet encapsulation. The long practice of encapsulating packets using a common transport protocol (TCP or UDP) or IP protocol number has proven to be unnecessarily restrictive. On top of the obvious inflexibility, this unfortunate limitation introduces additional security threats--publicly available IP protocol and TCP/UDP port numbers for the routing protocols make a targeted attack an easy task. Clearly, allowing the administrator to configure these parameters on a per-session basis or (better) change them in time, will substantially increase security of the network infrastructure. The protocol developed by this WG will allow the administrator to configure the encapsulation parameters. Advanced implementations are expected to simplify the configuration process by collecting statistical information and predicting correct encapsulation methods. Latest industry developments in pattern recognition make this practically feasible. 3. Routing protocol: information encoding. Experience with strict-format and TLV-based encoding has shown that flexibility in packet format is extremely useful for the protocol evolution. This WG will take the next step in this direction and will allow multiple encoding formats to be used between the protocol peers. The question of agreeing on the exact format between the sender and the receiver of the protocol messages is outside of the scope of this WG, however it is envisioned that this information maybe dynamically signalled, or statically configured by the administrator. Nevertheless, to achieve basic interoperability, the protocol encoding will be restricted so that the basic piece of the packet format is always an 8-bit integer, a.k.a. byte. Furthermore, to highlight the "Be liberal in what you receive and conservative in what you send" rule, receivers will be required to make as much sense as possible out of the received message, and senders will be restricted to using a single format per message. 4. Routing protocol: node-local behavior. For reasons unknown to the community, RTG ADs have been pushing WGs to specify certain aspects of node-local routing behavior, such as criteria for route calculation, best path determination, or routing update processing. This has been generally perceived as useless and counter-productive. It is an explicit non-goal of this WG to waste its time on describing such obviously implementation- specific aspects. It is painfully obvious to those adequately knowledgeable in routing that behavior of predominant implementations is in no way controlled by the protocol specification, and implementation of the so-called "standard" behavior by other vendors only diverts valuable resources from the reverse-engineering efforts. This WG is officially relieved from the duty of specifying the MIB modules, documenting protocol analysis, and publishing implementation reports--Tom Nadeau will take care of the MIBs (and Bert) anyways; vendor marketing departments are much better at protocol analysis than the IETF; and implementation reports only reveal confidential marketing information. Goals and Milestones: Jul 05 Paris Nov 05 Submit internet-draft on requirements for a framework document May 06 Refresh requirements document Jul 06 Should we go back to Paris? Internet-Drafts: - Guinness seems to be the preferred draft in the Internet routing community From rtg-dir-bounces@ietf.org Mon Apr 4 02:29:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26052 for ; Mon, 4 Apr 2005 02:29:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DILDp-0003q9-Ae for rtg-dir-archive@ietf.org; Mon, 04 Apr 2005 02:38:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIKxq-0006WO-Ol; Mon, 04 Apr 2005 02:21:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIKxo-0006WD-9H for rtg-dir@megatron.ietf.org; Mon, 04 Apr 2005 02:21:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24726 for ; Mon, 4 Apr 2005 02:21:30 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIL5f-0003R6-Ke for rtg-dir@ietf.org; Mon, 04 Apr 2005 02:29:40 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j346LHWZ012805; Mon, 4 Apr 2005 15:21:17 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j346LGs9028433; Mon, 4 Apr 2005 15:21:17 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j346LGaq028430; Mon, 4 Apr 2005 15:21:16 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j346LGpR019211; Mon, 4 Apr 2005 15:21:16 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j346LGFJ019208; Mon, 4 Apr 2005 15:21:16 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j346LF0m004325; Mon, 4 Apr 2005 15:21:15 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j346LFou003739; Mon, 4 Apr 2005 15:21:15 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf0.m.ecl.ntt.co.jp [129.60.5.144]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j346LFiB003736; Mon, 4 Apr 2005 15:21:15 +0900 (JST) Received: from TAKEDA_PANA.lab.ntt.co.jp by imf.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id PAA21587; Mon, 4 Apr 2005 15:21:13 +0900 (JST) Message-Id: <5.1.1.9.2.20050404145834.05578928@imf.m.ecl.ntt.co.jp> X-Sender: tt043@imf.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Mon, 04 Apr 2005 15:19:25 +0900 To: Dimitri.Papadimitriou@alcatel.be, Igor Bryskin From: Tomonori TAKEDA In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Content-Transfer-Encoding: 7bit Cc: Alex Zinin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Content-Transfer-Encoding: 7bit Hi Dimitri, Igor, I get your points, and here are my personal opinions. In general, commonalities over models/submodels are important. I think there could be several signaling protcol extensions needed from base/common specifications only for the signaling model, but they are expected to be very minor. (Note it would be also desirable not to extend CEs as much as possible, as described in section 4 of applicability analysis I-D.) One significant difference I think would be whether we rely on manual configuration (in the signaling model) or on routing protocols (in the signaling and routing model). One typical example is how to acquire reachability information. Best regards, Tomonori At 23:45 05/03/31 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >igor - i say that > >1. some signaling specifics can be implemented differently if routing >exchanges are made available - therefore the question is whether the >approach should make this assumption initially or at later stage (the >first example here below) > >2. others that will be developed in the signaling context are going to >stay even if routing exchanges (reachability for instance) are made >available and in addition they will certainly influence how routing >exchanges are going to be formalized (the second example here below) > >therefore, the point i see is that a strict inclusion is not advisable >(see point 1) and a more refined phasing needs to be proposed as the issue >of working them all in parallel is also not advisable since potentially >mis-leading (see point 2), thus, my take on this is that it should be >driven by functionality (as i tried to explain in the below e-mail) but to >address them we would ideally need to have the set of specific features >per model in addition to the common set proposed in the framework document > >Igor Bryskin >Sent by: rtg-dir-bounces@ietf.org >03/31/2005 12:26 PST > >To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >cc: Alex Zinin , Adrian Farrel , >Tomonori TAKEDA , rtg-dir@ietf.org, Kireeti >Kompella >bcc: >Subject: Re: L1VPN service models > > >Dimitri, > >See comments in line. > >Igor > >--- Dimitri.Papadimitriou@alcatel.be wrote: > > >--------------------------------- > >igor - > >these models will "co-exist" - however, the signaling >model implies a higher load on signaling to achieve >the same functionality compared to a routing+signaling >solution (in particular when an IGP-based approach >will be used) > >an example for the link service model is for instance >SRLG per PE-to-PE FA-LSP (TE link) allowing disjoint >path computation (if this information is available at >CE) whereas achieve the same functionality in the >signaling model requires among other exclusion of a >set of resources using an eXclusion Route object when >resource selection is performed exclusively at the PE >side - another example is the call model that replaces >part of the remote CE-PE TE link information exchange >(but there are specific conditions for using the >latter) > >IB>> Are saying that ability to signal resource colors >is not needed or less useful in the Signaling & >Routing model? And anyway, this is the basics of the >GMPLS signaling, it is already their. Do you believe >we will need some RSVP-TE extensions for the Signaling >Only model? My point is that Signaling Only model is >contained within Signaling & Routing model in a sense >that whatever available in the former signaling- wise >is also available in the later. However, certain >things that could be resolved via Routing (like >discovery of remote CEs and CE-PE links) needs to be >resolved somehow else in the Signaling Only model >(e.g. via configuration). Hence, Signaling Only model >could be considered (as practical as it is in its own >right) as milestone on the road to the Signaling & >Routing model. > >Thanks, >Igor > > > >the question becomes thus for the signaling model >whether a base solution (fully contained for the next >routing+ signaling step) would be satisfactory enough >knowing this approach is going to live on its own >(even if in the future it is going to extended with >some base endpoint reachability information exchange), >it boils down to know whether from the operator side >these models are perceived such that there is an >acceptance that the functionality level could be model >dependent and that for some of these functionalities >an alternative solution would be more appropriate from >moving from one model to another - > >section of 4 of the applicability document describes >this as a desirable/recommended approach, however >looking at the framework document there is a list of >common functionality (applying to all models) and then >per model a set of illustrative capabilities, but the >question of level of functionality per model does not >seem clear to me beside the fact that section 6.2 >acknowledges that control/management level is service >model dependent > >Igor Bryskin >Sent by: rtg-dir-bounces@ietf.org >03/31/2005 08:37 PST > >To: Adrian Farrel , Alex Zinin >, Kireeti Kompella >, Tomonori TAKEDA > >cc: rtg-dir@ietf.org >bcc: >Subject: Re: L1VPN service models > > > > >Hi, > > > >Just to add a couple of points. > > > >1. Signaling Only model is fully contained within >Signaling & Routing model and is a very practical >first step in providing the full-fetched L1VPNs >solution. Basically, there are certain things that are >required by the application that could've been >naturally provided by the routing exchanges between >the Customer and Provider control planes, but could be >also provided with some limitations and less elegantly >(requiring more manual configurations) by some other >means. The point is that we are not going to >standardize two solutions, rather, one solution in >several incremental steps > > > > >2. The same is true for all sub-models of the >Signaling & Routing model: Per-VPN Peering sub-model >fully contains the Virtual Link sub-model, while the >latter contains the Virtual Node sub-model. > > > >Igor > > >Adrian Farrel wrote: >Hi Alex, > > > As promised, I'm reviewing the documents related to >the L1VPN effort. > >Thanks! > > > In my reading of the framework and applicability >documents, I got a >couple > > of questions, that I think will be important for >chartering this work: > > > > 1. The documents discuss three service models >(management, signaling, >and > > rtg+signalling). Is there an intent to pick a >particular one and > > concentrate on the pieces required for it? > > > > 2. The documents include three submodels for the >rtg+signaling model. > > Is there an intent to pick one of them for >standardization? > >All of the service models are real. That is, they are >based on the >discussions in SG13 and come from SPs. Obviously the >IETF should only >concentrate on providing solutions that service >providers really intend to >deploy. > >It is worth noting that the management service model >requires no activity >from the IETF. > >My personal opinion is that the signaling service >model is the best >short-term solution, and is relatively easy to >implement, but that in the >longer term we will need to include routing function >for a proper and >scalable solution. SPs will be able to say which of >the rtg+signaling >models are of most interest. > >Just for the record, I don't think it would be a big >deal to standardise >all of the models. This is not really an >interoperability issue since >these are full network deployment scenarios. Further, >the way that models >are satisfied is mainly an applicability statement >based on the core >protocols (simplistic example: the difference between >the signaling model >and the rtg+signaling model is that you use a routing >protocol in the >latter). Also, the necessary changes in the protocols >to completely fulfil >the models are not large. > >Cheers, >Adrian > >--------------------------------- > >Do you Yahoo!? >Make Yahoo! your home page > > > > > >__________________________________ >Do you Yahoo!? >Take Yahoo! Mail with you! Get it on your mobile phone. >http://mobile.yahoo.com/maildemo From rtg-dir-bounces@ietf.org Mon Apr 4 17:23:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13077 for ; Mon, 4 Apr 2005 17:23:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZAl-0001mH-T1 for rtg-dir-archive@ietf.org; Mon, 04 Apr 2005 17:31:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYsc-0002If-9o; Mon, 04 Apr 2005 17:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYsa-0002IT-0C for rtg-dir@megatron.ietf.org; Mon, 04 Apr 2005 17:13:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11391 for ; Mon, 4 Apr 2005 17:13:01 -0400 (EDT) Received: from 82-40-64-141.cable.ubr09.uddi.blueyonder.co.uk ([82.40.64.141]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DIZ0U-00012m-LM for rtg-dir@ietf.org; Mon, 04 Apr 2005 17:21:20 -0400 Message-ID: <8b4801c53957$5fd23978$1e4d3d32@3web.net> From: "Vanessa J. Smith" To: rtg-dir@ietf.org Date: Mon, 04 Apr 2005 20:47:40 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_3F6284C0.8315FEE4" 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-Score: 3.5 (+++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: Windows XP + Office XP = $89.95 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0000_3F6284C0.8315FEE4 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_57D18F79.6461F508" ------=_NextPart_001_0001_57D18F79.6461F508 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get all the software possible for extremely low prices! We sell software 2-6 times cheaper than retail price. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... Please visit us at: http://www.softwareparade.biz Sincerely, Vanessa Smith _____________________________________________________ To change your mail details, go here: http://www.softwareparade.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_57D18F79.6461F508 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
    Get all the software you need for extremely low prices!
    Our software is 2-10 times cheaper than sold by our competitors.

    Examples:
    $79.95 Windows XP Professional (Including: Service Pack 2)
    $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
    $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
    $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
    $79.95 Adobe Acrobat 6.0 Professional
    $69.95 MS Project 2003 Professional

    Special Offers:
    $89.95 Windows XP Professional + Office XP Professional
    $149.95 Adobe Creative Suite Premium (5 CD)
    $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

    All main products from Microsoft, Adobe, Macromedia, Corel, etc.
    And many more... Enter here:

    http://www.softwareparade.biz

    Best regards,
    Vanessa Smith


    _____________________________________________________
    To change your mail preferences, go here: http://www.softwareparade.biz/uns.htm
    _____________________________________________________

    ------=_NextPart_001_0001_57D18F79.6461F508-- ------=_NextPart_000_0000_3F6284C0.8315FEE4-- From rtg-dir-bounces@ietf.org Wed Apr 6 18:31:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12821 for ; Wed, 6 Apr 2005 18:31:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJJBk-0000eK-FN for rtg-dir-archive@ietf.org; Wed, 06 Apr 2005 18:39:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJJ25-00043Q-3G; Wed, 06 Apr 2005 18:29:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJJ23-00043J-FQ for rtg-dir@megatron.ietf.org; Wed, 06 Apr 2005 18:29:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12734 for ; Wed, 6 Apr 2005 18:29:48 -0400 (EDT) Message-Id: <200504062229.SAA12734@ietf.org> Received: from 82-36-100-7.cable.ubr01.king.blueyonder.co.uk ([82.36.100.7] helo=jimdefee.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJJAP-0000bu-9A for rtg-dir@ietf.org; Wed, 06 Apr 2005 18:38:34 -0400 From: "Marla Blanchard" To: "Oighrig Tobin" Date: Wed, 6 Apr 2005 18:29:45 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C53A01.425462D9" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: Re: CiALlS VALLlUM V'iagra X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C53A01.425462D9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, now that this honourable service might redeem one who was a pirat fringed it there. The overseer was too contemptuous and perhaps of Barbados well astern. All day we have been sailing east befor would have engaged all Captain Blood's attention, he now took no which the shipmaster, however, makes little attempt to reproduce. Main. being warped alongside, and he wondered a little what this manoeu Well? he said alter a pause. What do you say to that? save him. Therefore he said nothing. He inclined his head in waste of valuable material. Slaves were urgently required in the Rivarol, as down from a thistle by the winds of autumn. The Gene Five minutes after that they were board and board, the Jongvrow h Have a nice day. ------=_NextPart_000_0008_01C53A01.425462D9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, = Woulld you like to spend less on your MEDlCATl0NS?
     
    VlSIT PharamcyByMMAlL SHOP and SAVE OVER 70%
     
    VA U AG  C IS
    Ll M Vl RA lAL  and many other
     
    Have a nice = day.
    P.S. You will be pleasanntly surprised with our prices!
    ------=_NextPart_000_0008_01C53A01.425462D9-- From rtg-dir-bounces@ietf.org Thu Apr 7 03:25:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22156 for ; Thu, 7 Apr 2005 03:25:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJRWl-0006Gr-Jz for rtg-dir-archive@ietf.org; Thu, 07 Apr 2005 03:34:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRNq-0003h4-Cg; Thu, 07 Apr 2005 03:24:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRNo-0003gd-7z; Thu, 07 Apr 2005 03:24:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22078; Thu, 7 Apr 2005 03:24:54 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJRWI-0006G8-NV; Thu, 07 Apr 2005 03:33:44 -0400 Received: from [83.220.40.251] (helo=NATALIA) by mx2.foretec.com with smtp (Exim 4.24) id 1DJRNl-00066L-6x; Thu, 07 Apr 2005 03:24:53 -0400 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 61095, updated: 12.12.2004] FCC: mailbox://syfegw@yahoo.com/Sent X-Identity-Key: id1 Date: Thu, 07 Apr 2005 03:26:18 -0500 From: Shawna Boswell X-Accept-Language: en-us, en MIME-Version: 1.0 To: rtg-dir@ietf.org Content-Type: multipart/related; boundary="------------090406050605000504000009" Message-Id: X-Spam-Score: 3.0 (+++) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Subject: re[2]: X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 This is a multi-part message in MIME format. --------------090406050605000504000009 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

    Games I'm against it Amateur How are you?

    help me USA

    --------------090406050605000504000009 Content-Type: image/gif; name="rutland.GIF" Content-ID: Content-Disposition: inline; filename="rutland.GIF" Content-Transfer-Encoding: base64 R0lGODlhfwLjAfBrAAUJAP///yH5BAQAABAALAAAAAB/AuMBAAL/jI+py+0Po5y02ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qDQDA9gsOi8dkRbdbTqvX7Pbu fHbL5/S6vQKH3/f8vj+cl/c3SFhoOBQYeLjI2OiIkpj4OElZadkQGXm5ydk5qMml6DlKWkoGeiBpusra +oSKoAom6yAaI5hii6cXgCuT+cqb4ZtDPCz8SZugnMVs5rxiTAI7gSvtkonGdC1BbcO9G0fovazbbP5M rgL+kW1hjQyTra3E/gBcHI9hP6dezh8MXax56cSl4mUQnsGCXnrRG6gPIj6JDx2KMyZQDzGB/wfdUWz4 z4tCbSAtLvwYjmTFjg2vCUu4kKM5XwjZAWzjj+FKKhpPUgwVExZBky1rXvQIlCPRpCWJBj0KU9nQiQyZ ssToUZBKqf5GOjO68yU9sFhp0dwqM2KdnAugRem50+rSq2fdeZU7DyTSkEWfyrrLtC6+vT/nOhWbVdVe wlcDoyPbNipLx35tjTwc8aYatgzcBhTps7FhwHdJQ54LmK9c1KdNQ0UL+nVTvK1ry47jGnZk2asnG5bY cXLuvrot0g6rVg5nTEqdwJ0tWjDx6VaHHy/u8jRr3tuxQ05d2Hr36bhtF1c9HgI3o0mvU09vfndcN8tr Nd9Wfr5N89TF+//PrN1/3FkHXnT8uReYgQMCuGBoKMm31IHpYaYXWPJBR59nDql3XxJaOfibTqKUJuFw XyU3oYkjfjcUel4pJiFlZJ3Y4Hy9hRThbSsmpkuHmonBFoqOTYEYhh8WCQqJNb73YkYoCggbjLzldaF7 UnpX2ZXkiNcZOM/FRt6Og5nl2Y+zlJmThkcU2WV+UY05ZYn80WgjlGES2GJ4M4rJJDJUUhgal1Uyh0ah YMqoY5NNpWljGoxSJeJbb7ZpKJKE6mYnghGklmmIerqJYVUTDgqel0IqeJ5O9hm6oXaiXhhPV42e4lZe dXZIRJ6fjiUnqJp26qKlKfaKqauo9rlkb8D/7vreoJe2euiwyQaaVqhlyGqrtWoiwpim0hab7LfNMnvs r8SCOW654nq7rqftqrrql1jO219c1fYDTbZKbQuEraQKi2e4y6rbrp2SFGjuklqSOyrD653qVMQJ02tS e+4al2G1+j5s5ht/BvsmsuBSXDCD53XKqV3GTtzsVH6e+y936HEor7oCWtwxrU5urA6/PUgHq2Uwoxzj R0ILXPSXDdPFp7K+/jYwy87eI2zJNVbsbs5E0snzlrj+XDVfPU6kJJwkA3rpTGQHCCnI+bbYLcGIGu2g oIiGCjTTWVYN6s6znvNY1/5GikTesGKst8M8no1ZvNJQVSqZMmNLjVBF/1MmIt6XA6p5yGKvZLlkFFJq rRbeCK5v0IWHXZVPak/+tN247ltWqhLr/fKTbd9+d7oJHp42u3cHfyPvD4qG9cXFnxk46ql/7godcWOz e/SLVO5814Rbj9PX0XjPPR/YZy849OGfj771oZOPuvnpvw8/J+Oz377R8d+PfyNB0j+46vn/D8A9MAp3 5OsG+AKIwARWYX+LYt8FfKbAyJjgbxwqAQU9cMEuqS+DHvNRRei3jwO+4IOlYwMHd9GBE1ajhCBQ4UAk uCYWzsCFOFjOSUAYQq19rxzSKwkNNwWdW73QgPYZ4jpkeBAjsuCH+FlCfW7owGPoMBcN7KESRYCcIv8m kYjMueIJOPgQJobwWkjsoGagWEANQLAFJIRIKJbhm2fAMXkbeuOz6pgKi0HrX4ijI6+CoxKMZecofRSk yYrSRyG9DHGsigUfYfLGp+BxN6tZJCSDEskwNlKOjvRjhSiVST1Cqy80SyEEK7NCiFFtihOsIhfsOJYt 2ksvsPykHWEYyFfWcStaBEotb/nHXfJSmL00ZB6J2cXgIFM/iPTlMmmpQWXmkpDC1BwPZVmhZlKzmr8s pBG1actJXpORzTRkOdtyyxyaaW/IqR4F1nhEZuSyF8A0Ei01Wc9oIpOewWwUPkOJzST+s5/a8mE4A5rM fAaTk9185jFhmM99blL/nFdc6D73iNA//hOioBmiRcdp0Xl+VJ8PhCc75VWfVapyia5kzTHflseBHtR+ eETXPEmqUYMqVKc1PSdDe2qgYub0YR61pUgTClSJdnSLOD3oTSc6zU9ulKFLbSgzmSpTrBYURDTL2Um1 Z0pWYtGVIhUJU6lGz0mWlaQv9Gk6IQrUrALUqm5VIkEbCtecArGoCG2VUI1aTqiWbqFynatDDSvEc65V nyEN7Ez5WlIROrN3zwvrSql4zbU+VoOKdSxbBfrW0I4zrjzVa19v+tO7XjS1UmVhYTX714y21oucbGw6 BUtXtRY0ra+1ZkRzK1q8plKHX+VZCyU7DbJ2drSx/00qiGbpRX/y9LDcrK5qmyrb4N4WsHtN6kWl+01w yraET3UsOD3rXFI2l6C+1e1vR9rX4V42HQQEazuQO1aQbhJ0usORG2+FST2V0rux2m8jCctM9BpnmJQk sO42Wt4BqxbBVS2IG0VZKYH2FpCDbSAJK6xf/753q2mVL1eBmE0cHlesHrKDGL9QxhC8+KdnVeNgdSbW RKXxvixe01pivBl5AJmLzB3jPcaQ0l7yr8c0hfGQFzjfzTxZnVOuII3feaoZFyHJtaDbjlcc5QiKecxf hCeKl6xl93UPs3C1xImxTAMwVrnG4zCzAdE8Z8elOQhChIQ95ZfnIlMPhVcuJv+U32ziPX8uisllcpzn rOg20xmpkXZOoGm73RHI2ZSzwKCdE83oRofZYxuotKApSulLb03G7UU1Bzb9alULIdBcpnKoLYhfGy/1 wGhcXj2HimINGxTEwsbRkXhlWh66DrWziaUuJ+tN+t4Ra84uMVV9JRgNQ1vZ/AX2LyWZxU4u8tt/7nUm 1SvKZ0vR0XrO3vfYbWWonFa4tT2vdnU5zKjaE724HS+hbmtVXEKTt3U1w73vetRoBnKq+p70heVKzXzb m6PArW6bgFlL9UYV06B+t4qpCO9Uj7jeaMXnVJOZbFebfLZajS9rSa7uthZK4HBGOXdxU8SUIzjT6+Vu N3X//udXbtjVLc9sOA3s8I57/NZ+DnlezQuwDrv35MHStsNX/qHwwqO5Lo15sYcN35kJfOs47+LBpguj U/M87T9neXBjOXTw/nqxo3xJqT9ta3ezMdcrhCyqN55znVI9u4gNumF5/vfdEt6vnOVnfPsM+SCa1axm bzbaJV/otWO+7VbX7szdm160ct7Bide101X65aWb+qx0hyx4V85xwGP07YK3fHglbVfxRvLf5HzrVYm+ WmdydaKID/epC3t7pYJegssNvZJ1v3PjvwPvptf7CPne3W1SVPYKn3jkI8rgf/wW8dsnsfPv/V2f/r7P pQf+ahlu+8xrn7+Lb7jI01vw/6LL/rqWHTWP63cL2FdKzIYYFndt3rYqs4dsKhcbIKNMXcdZH+Zd3Sd+ ldJhxMZ6YoF+yMZgnqNbV7Vs27R/2QR8H+ZhwRdivoR0c5d/7SZr62Zcj3Z6mcdq4gNkL0hmmOAo1Adm lSWD/ldzfmaD75CDuUBGAvh/2ZIPTjeDD3gHsFaEuIZjQChq/XMDPBiFWZg+tQZySqgDWOhp6EcJq6eF PYSErLYxPACGy2dtMEcKe0aGZehEa1iFTXh3jsZwWhSHVgBdSWdkcvhjZ1hmODhW8EZYoreHUIZdxwWI T0iHOxhyJLFLwEFvo0SJNfVQNUYcyWdhD5hhF8eBN0J2mv/kbZDUiC72iEgmiB41iaPXTq4YWBSnfKIF OhlHixqne6wFfbiYi6dohnYodneYiEyDa5O3az5nfP2WYYZXYa13cAqWgec3WslGd6jli8qRil6GaGdm h9nYVox3GJUIdOfWhlgFeiPVTs44dSuyiHUngj53jYHIbjGog6g3PTAYhzP3ee2XjM2ISJNndppHZ/Q3 i7nXfi93eCPnfvEIiT1WPryXNlZYfXsoOvy4ebNnXSAokKFFkOoIe/J3eQfJfwyJL/jFdL7GOffIjcP4 UR15kdxnjdPIb9JHXeGmfbSXfAQ5gSTpiCLEP8CTOQ+ZaCw1kDVxi1rVRu5nghW4byT/uIL0xYEkKG0U Vo0tyJNS9jV4ZnhBY332SIhEMmtfeZWlwBla+YpceZJNJj58JpZjSZZvY5ZnGZRpGY5+MIzTt41uCUBe E5cmaHl96T96KZhidjp96ZeLhmdqNpiLiUDzA5h0oY0/qZaMSZl7KTmGGSb1JZlDUpmdGUDr85hJgpmT 6ZmlGT+ogJl9Y4FxSZqm6ZpbeJmpKZu5Q4WvaZuXAJqzKZvEeJu9+T6oqZu6yZu+SZznA5zBOZqcWZxy mJeN+RfI+Zh1eYWm0oXddpdOGEd+yGMQgpKtJHlRglR1KJVc+ZnPCZ2JqZzT2YCd6J2JFJOD+Jce1pbp Rm3v6Z3x/6mC6TiIwpdgF5Y/x3meKuaNd7htdNRo/DmfXcWe9FmI+NmcmhaCvLigEOqU/emf+AOgAeo8 w7mE2/aJxYigM4RGWAefqvGgDeqAhfShFMphnSN+lnk0GiqUAxpr6EaO7WlOnXOi3FgYN1qMpGiBEUmh QCqhMteWkuEmF1qgp2meMpqG6fmFK2qALOoXE9qgYAdY87kRFiJiVfgpKmqjhdiiHxqCzhmjTvoxNNp/ 8RdtSRifw9Z0CLiAP9paKQan8Fmnv6N1IJqjk1WmZiodaJqh1xlZnoSdaGig9ZmglsioPXWk6yml7CGE hCRv49amazqeFXmo/6klgnqmhFqovf+npCu2pHCBWZRKgGL5iVJaMTs6fcYkb6K6qWHVYOT0lxEkmp76 qYtKqwg6oJraomymEHOTXMdBSa5KaMNqq8QqptK2rC+qQLmqq1EJqjnEYbWKqKXKqhBqrHJZg9txrBSJ LH5KfEtao7UKrMi6QbsqoxzaLwvoraSqrWHKreAar/dlrFOZj+O6rPfaq9CartXKCIOqoe76rriIrfL6 jikmhiXlieV6qXf3sFU1KQvpsORapP56rs6qqeoaPgQLnQZ7sEZ5cVdKpG9arKQDkYxYss1TaRbKdgn7 r/4ZMh6LPiArnFC6nDurhTibmiLLs0Gbgz4bnWoqtEf7hk26mzr/i7RNS5hKa5hA67RTC6hIwppMS7VZ W57sumRSq7Vfi6FQu5nSCbZlu7WBGmpGa7Zrqz+x2ZVqy7Zxewi5KZRkK7d3Cz90+6RYi7d9yz16a4Vw 67eD2weAuxirSLiJO7duSxiCq7iPK48FpiuOC7mVi42v45gCa7mbe4S147may7mhCyRc8bm8KrqnuwaO qZioy7qApjbb07qx67r2QLmya7tORjvAeLu7CwhcA7q8C7xSkLmmG7zFiwUEa7zJ+wh7q7zNu7gf47zR WwjQK73V+wcqab3ZW5K6q73d2wSI673huzW/K77l+wPka77pq77ry77t677vC7/xm7S3ypQu/7qykWWz nlZl+Su/ejmiJxgToyrASiei+4u+/ZtAqDSrpHifDLp3Bky8CJyFCjyvA6y/FvxuuibBQoukc9o3vvpw aBEOJfusDiy5F/o6Gxy0HSyVH4w2vgo+dTOnOUqbBQhtoaPCK8xLsWpOlyipbBJsCWWKPSxNHszAE5vD PJsfwRqi2Bmr5qZSCXgkNxx+OgKtMpvEt7nE+dnCR1zEYfpmisQqq2o2fOKX35nFy7nFC2bEd/rFHipd fzPGFFvGTZI5c5TGxfm5b+zEEneC01ZyHTXDzmphMuwneazGknvEkhTCYAxg8jUaiyzJm4XBiGybntvI SvrEEkjCZ5adPP9MxCXMyBFryZVpMo0cfkQMxYh5gX08NkdDs5JTyr15yhPryEW6wO6Esdw5oaNsPPw7 y8EszMNMzMVszMeMzMmszMvMzM3szM8MzdEszdNMzdW8tn9ao6aGrLqMo/JKyta8vKucdx80sykBvgPm zcAMzvJ4xfg7NuWMZdycK4O8zriZOwTqG/m7zZz8vfRcz5UAyz2agP+lrK4MqfzczhEKSqD8rGucqO0B rP88hgZmp2I8S5JqyzvSzq5MN9oIx12sKB5trhLdtgedqbPSPJo8wzZ8qXkCyhULxa/xoqPM0iQ90d6H 0KTTsZwc0/5MQCicygwtOqss1D5t0wO7w0H/TUEB/dFNTa4uOJdO3dO3LCUAe8BH3c95CqYxhtFb7dRc PNBbXdWZHMtUrdEojNUATa1fTchNLNUI7dAc68sJrdQgvdEcnYlpXdJfasG0ScV/LM4QC9RuHMpuvcte zcezqtd7jTwRzco2CsS2Kp+tPNh/nc8VW9iGjdnqvNiqKJ+445Ue+MKj3Z2IjTk/zawM3Tio/c2dLUDd Fox6tqBTDBzYfL9ivdBE2tAX3ZQl7NqJHMF3/dvKy9l4OdzSy72dfNzJW5sbu9zPDd3RLd3TTd3Vbd3X jd0HaqUMWmCrhMWp9BPbeGJ5WdzZXWeTzU7HM97WqcEJIt5xDN7mva6A/z3JfifHOe3cxh3W6Czfq/DK ZP3UO6ncnL3PlB3E/W0KspzYomqfdP3ZBE1KY62nbAzbl6jYCG7P62nZ7omMSLTTu8rFGO2zZb2lwY3h SOaEjEzTWRffHI6xf+zi4iTTG17Y5X3iPVnZMY4zZVSRKl7hOs7XSKzjNn7jgZjjc11UKL2iPCLXhJ2r Vn0nRl3km+DLLw2CtLvkcNLkJG7Yuy0UU+7fXlzjF42CEN7XP+7jdzrVI+11YO66Ry7mrkdeJ7zgh63Z db3gRO7mqEjfar5+VukpPIzNaX7ZgzzUcb7nGb5oHc1RgP445rnlGb0nK/7fid4J1MLbzwcxzyXOvv9d pRSeqCPa1pb+tF1K6qeO6qmu6qvO6q3u6q8O67Eu67NO67Vu67eO67mu67vO673u678O7MEu7MNO7MVu 7MeO7Mmu7MvO7M3u7M8O7dEu7dNO7dVOlKlr4o9mBFdtsdrZSkFoz1h5diaU7eFZr/OcsoRGZHh5ohl0 lzoJBffd3GrYUjs4uu/KcTSIr333h1DYXUck3IYWpf/e7Wr3qizr7aZT7r+w8Ot+QfsK7uru71YWT5WM ezXkWtMV8Tb2rcVm4Z9+Z52nSrzGzypUHnFEph2O2yEfigQNUH594UFlbgCxcEtZkCfvwNc22P9o845a e2y+skR9MpdEr2EdqYL/zVwt72WfTMct46o8rfJ+d2QG2OAPi3FlroeAF3EdPpPZN4JurfWAnnuxiPX1 Bo2zKHEN+1TC9Y6waPX7MIlhxPalhW5gZIv4R/DUxYZl5UN4VfVsdV0R1rBSH3YpWH6DH42B3/Xnp+Qy 93gKtoLuHpJGx+8jqXwfabFEpZOLpYwajwdxv3lJKY0uxPmeD/j+6HtOVXBVebH6JzReK2Cwz4JRifiZ FrOlD34eZKQkS1fHNsQU72A3mfUud/m1R/OdhfM5yY7IV/BwJIm6XXzsmO+iwn/3zW1SP4GpyvdhJvr2 +fcwN3iiZ5G1v46NnvvnD+4QO3SxJ0MQtouVD4+n/4X6JzRhxGb5GGmNJr971X90F5nwBBAgDDXZ8zQ5 H0SxYZxX1d35OIosR2kTzWgzKbVtXbSTrbua8dt+1HCRCoJ0ngtxBzzRXL0XSIj76X5Tae3IdDax15xv SGJBw8/iZFhWMsFi5NftlSdX5KQ1eoqV8+eSrG/LioqPaOvPDq2Qrs5CbQkmEvKNy5ER6NFGkFKRbW2w sY0usvCxKE/Ss09PrQdUjDWWbc+sdiZV9IDTMzfxrjVx6vDUsItD15EMmThLU3d3KRmr2ZQrS3pH6LpK efgYbNkS7/n4w/tbVGH7nJuG+1odnP1ZGRPY/d1X3Zgq7ntszzRh4QhRi4ZsHv85Rc7MleMVryE2PxMp VrR4ESMKi+cydvR46WNIkSNJljTZ5GRKlStZtnT58iQ0RDBpRqt5E2fOlTJ19vT5E2jQkvSEkiRaFGlS pUuZNnX6FGpUqVOpVrV69SPHplqrEpzpjyXXimKRkt3IE+tLszF3OVmr8y1NekTjluW36WtYtBfr+uxL TOlftXvZggQpGCbiwZ3ShiKUdydPs2QVd6wM2bDQyxg3821LqbPK0CkBEZ7K0a1pzpJVw7nVurBeW0xH U6w98VBqqAgFLlRirps7z50IKgTkpgtwsBCSjRjT3EiY4sERJS8NT/i+e/968wDoat317t7FTbPm/HqO o8//LXmvh4/883BH49WxDr36pGK58aBb056B6RwqKqJ26ptvkf/O8u2TVmDBRBbGDJADwUkycC8bY1y5 Yjuv1PMFlVSWYQ+5CEvLUMNXLoSwFyQC0ojFQdLDMB3XVoxIQRhxiRCNOWqg8McYU8ysJlpCnOUueFQE TBUlHQwlkDdS6KVJmwIMZruvjrTyRAuNoJK8vLY8KMscoRySS32Q5PELI7F86Ewv4/wQzjWZY0zGTKTj 5yc313tTmu8qHK7KuZ5cKB8PfdBuIDnpAtRQ5AykZTZKFRS0HbwCNYXSVVZ5YkQ0GbFUoijhdNNOK/EB hj5EyyS1nEP/RLHRK1v1yw7w/1J1xjHbikFvJikTtFGLSyzdksQGX/NRTzFBbFbXMMGKlswMedHtv1qv hZTPT7/s1EXQhvVmR0/DtRZNEZu9cilUKy0zs8l+lZY4fwxctpovrf2N22WzXdfeZ3+BIwpNCZ6X2Yei nVRNfYG0KU8tAJXQTm9rGWdgPJOTRd2Mk7WrvYW1VXWOx6p0DduRe+XV0UVClTPgfVmMmZUUqymYE1hH eTUNijlOEsBqf4aYz2/vrbNcaHYEU+NtH26ww3P7JLFV3nZGMFSLMYtSwPw+vlVh4wRGcZ/6flHUanOx w89sq7mLdV+09wtovA/Dy1m+bj8OeT92OZx7YIAYVKjEr/8J9429w8v2uui0WWW3a+2IfOo2l2BrDPPM Nfeo8s09N6nzli7/nPTSSw/d9NT9APsq1FV/HXa4Ro+d9tptvx333HXfffXZKSPMddpmrzM2zxVNK3je sxq+SEP3JjZVf89IPjDmJxeJ+kpWa935tVPvPLTsl/d5LKkznt763fDGPn2TM0KdP8y7pNz67OPqi/r5 CXWaZMxUN5hz7ZPe9hbTK+6Rr131EyBuRoe/BaKPOFzT0hF487IB2cI6gMvGjShoH0R90G/kYJ3gshM0 iYWLbugR14oGRELWlSdu3Rkh1nKFsDsprkI4YpIK4WOfDPKwh+4RWyxyOJceSSpoj5P/nAkRxzOGaENp b5nR0prmMKbNIjvIepIFyXe0tu3Jg4syUxb7JSR7Nc2C8TtQuoY1LSVi0Ecc6p8B05gvqMmRaYOKYYIC McENlsyKActSxNikI9jMj4oV04cXeSChWgkOaLO5osyeJ7NC8g9nJhLWhApVw5VFbZJVBKQqalSy3znS SctJ1iqxM7Ix4WJKGNwYm3SGSVGxLJCS7B0qLVlFUgFHbuZ7ZAcj+a5ZofJRjoFi0Wz5qGMeDIUi9CRk GMYoO5rymlOKVKlsuEN0GfFdRpNY9I4FynQIiz5eMRcCPWYzxdUoNcdzXwyJl7ToVQdhw5zQBWDGS116 y2D2VOXN/zZpLHWaz28DpSe1aDbKYh1slFxBpPfC6S56ufKWbWSB//zjMFxSrJray+UYvTlJkZ2PpOP0 Erh61ktRnoqZAW0jRAtJLV3pzKLhpBJDLzaxOOQrkVqZKPTECSyjYvNkWnyoLpkDK1AwNKTKbFhKB2jS gmJ0jv9aqU+15lI6EU2qgAQPwNKkKpXVUXt1nCmxXhlFmDp0SV+lKpBKQU+UFoiN7BxVP5+6wjUCSI0O nSsd2Zgy8/BtVW60JA4BNta5UUc8LfUnRCi4Qg+lc4gGJZPj3lM48ySqo9uqZdiwltDFQW+oEkEijWwF wqu9LY9dxcZ7lIOOdwpHG9EZ6wU9q/88377OgbuBHU8J9FvjHld5waXccAsaGOQ+F7q0U+5WHggypgJF fNHV7na5213vxq4yxLUM8Hx3ze+SbB4EJGB2g0Ku6souMtIVoHjfR97xXk+kuzOsARl4X6KCVybsHcpe TvnfAOIkvM0NiUTLi1/9BtivVe1vfR08vqS4V33UfG+FFzQ1oyjYwhCksIEfPE/i6dXE5eOwf62bX+Fp OL6i2fCE2UbZEtr0oDirIXXOhjdRnTaWnBRBjqHpWheKB59knM4PNclk3roNVHUbyIugWMLE1hhUf+Qk YMODMqoRechp4LHZSrREuLX2gmHuLThA+GVB0eqE7NMkYOE6rrr/sllZdj0iLPkYJLzW7J935iIhMWZI xD7NtnklM1hjS1dEK9RGYBSjkCWrQ0BrdY2Kjutaz/Y0S1+akB1V89AOfeArsuym07zoPcDlVVK3GiFz zqX+vizrrbJTnzlq66xt2LFVh/JkRAozP3sqNKeNCdMJjeslPZpKkrZarsZmpb5kO+FtlpOLKv01tE1L itseU5+xTthIf+lse+SYcE7NLKLLuSleg7TPyVRhuteH0itD8t56qyg4uR2pbbJ13fCeN1ohvU54y/vX pVyvgn0dQW13m9VlnJNAN0psTI92naYCeFhJ/WiNf/Sj1F5rTnGt72IHaJ8dx6mqbVlWjuZZ/6emZTa3 Fb7yhzOSUFDt809ZPu02QHsYvmYpl/UcaWhFMrANhfnSL47QkAOdoA9nqsF9iSM+v/WoLR/VZ2iGrW8q Xes1bVhOcd5hmhL8pGAatKIVrsii57pFHL+XbDUFdXPaGtU8jWres8lwO0Z16Z82Y0/Japi0ez2UKvpz sHcm8GQvO79Vc7PM4RxEElIycmbG7TqCiFR47o2xGtctOmvLZYN0rfRqy208payn0i4Ty/65LWzHYZDN M+7MMLQb7E+bZcGv/cxLclvpofPEllb51omZMYptJ+DzlpS7zn9+8+Sy/AxPn7rPlz729SJP0lg/gd7n fk5eiNzyjx/96f9X//rZ3/6Xm0xeEOZdZ7afYvW6X/nL0f/+P1ebX3o551QDNcDP1D6seE4MvhaMAC/s gSqHvrKKxBCswWTsWhxPxSLwMKZKvaSoATWQ/+wt+xSwdhzQ+h6QXphPfkBsxCbN2HxlxRBPMarNxUQQ AvtntKpHzuRLdEpQBR3u/TTHBF1wn4JAiPbkM37MtXqPm8hs9vjGeSyPmNbtcC4v3xYta4yPtXKL5zQo yA7LDIgstICo84Csg3AvzcoQPyYP3NBQ92Zw0lqvyfjlsbYwCRlkp6jBk7TwyUCP3gpsG7Dp7x6NnCLs r55t3H5G0titr8iIgwyPtjgt0Yhoi47wj4T/D+5IQbO+CI/UBQoSDvgWjf+q4BA5sdQc8e7C5tIKURPb JN4KzjRiLXEay63GqN0gTdlmkeoypefg5Xzy7pM6TrHu0OICyxd/sdFqbmJ0ceZa6RQxjA7X5Uj6rZuO jZnkCqtEjpdqieogqBl4RGvW0BZhMINm75noBvjIjhebLfjqTc9kyt1aywO5pqtYSmzK0enE7Bz5bQ6l EQSvC9+w0Qv48cT8hBzHptx6sRugjKZGqhK60fPOjtNqMeYqye36MZOyDudqMZEQsh+BreK2LAOBURwz cbKEBscWkl92pfA+8COhcUgE0gZZTqSQjeYksgVhRixK6yEPD6jGZiIp/6rqbvLrMDIdNRIS1THakm9w Qs6u9MckexCgfMpCdM4Tf8wZs0wVmw4gk5Iad+nUuGpeQK65bpDjdvKqIFFlpM28YM4pf07iLMYoBQsp 2/KczjIU2c6gVpIVzarShCnqJFElQY0QX4phWrGUNiEdu27KFiufpEZu7knEmi0xHccUpzESaUVcuowJ pfD44DADBykWM7Mpj0f1rJI0kwQPLQsL1xG9WOkTlyg9jowxOe8DdQ3MHoeRHhPdSO/2jGaRxMxVYAsr lRD/irP96m+HFnAEldM4m9M57S8EQbI4kfM5qxP9zo9AmnA6mdM6u9M7vxM8JZDFcjAy98cAwxM90/8T d4KwBoWwPM3uPNVTPucTCD3wPUMM+twzPumTP/vzNOwzP8cTOr1ywPzTQA8UdJBsDGETDfXw4DQIzVir 95AvyeTBDtlGIdUjDSvriC409HYMQUPUuIrRTF6E6fxJi5To6p4tLHmRFB3J0bQMFWNrLUXURv+nMV0q LjeuqKqSKKWFuHxuqGyuqUyThfjHR1fsRpc0BVcFmMTS1k5u25KRGYswSKu0xxQSlyor24KsJIW0GplU TE0HLmfx7fwKHbcSTImKVw5y65CG2PTO4pRuTZV0TO+UKhYx8pAw7aY0MGFN/nyw8faSLylN/zaqIXfR 1fCUUZuUJMORU8bSnF7/c0WvUhCRkYlAkClPbtfkslE/lX4i68qWEhEJ8UPFsC6xDTFZZczMLEOJJtsq cwynEAlB1Vb5kzqF61Z3lVcFVPt6FViDlUCnL1eF1ViPFVmTVVmXlVmb1VmfFVqjVVqnlVqr1VqvFVuz VVu3lVu71Vu/9Tux8zWKVXQCSDC0E1zTFVf+zVfI9fsc6FzFT13ntXm65yzclS3gVYHwlV61tQ+D4wqV 8FakCUJpFd1aqIIYxYd2E4n+lYYQll/79VpPdVO4FLP+7Qnt0GEftvi6B5yibMkkL2Pt1fSAU2JP9iYo 1poqdpk2ljddlkLrcWSDCWYT0plm9jt4C2V3tvsK//ZfIVaGmpBg8ZFBke9PBtAci7Y3frZsmJZnn1bG FHRCOdZjTdaDZBZos7ZirYHHsDb2LpYMuRNq51VlDTZoSRZdE3ZDUy9gY0WezFZrw/Zj1bY9x9Zu29Vn U6hjV3Vcv8hoqfayPjYJmZZw25ayxPZuT9Zpp/Zv2xZdFXa2vPZofSwzE1JpHWJxBfdxE5dzmSFja8xj 3ZZjufaxapZtic9JRdccb5ZdB1ZeOxd2SVdlWVYgLhbCAtd1cdZmV3V1S1dmNXd2Y1d4GYhmo0xgg7dC g9N4vdZtx1VUl/dhg3dzh5d68zRiU/Z6q1d7y0dcm09wtxd8U3B6l3N8w9d8qf/rdW+ne8+XfdvXfd8X fuNXfueXfuvXfu8Xf/NXf/eXf/vXf/8XgANYdi5j+Zj3Dxb0P/0vfZNXgP2zfJ23Z2OPcRFXARX4fha4 gbvzgbk2gokTQzGYAS24gUA4g5/TaTdWdJ2X9EL2a/UxZ0GWg+G2OYbWhGhYeTH3iTw4dy33DOumhM/r hK/wd3nXbG23hScXeNnVSYMYU0iWdlW3dnG3dT8XZiO3grL3h7FrdG14aN+WikN3cb7Nhb9YiaH4dC0W jK1piGmIZjGWjPHxZ282i7GPiTl0tfDJZAsXdffQcUc33844jA03jgHXixv3bLn0cuV4jrVvi69YhhlY hff/tnKh8ElnyJBxuLbqWI0N947XGGv1+PRIeJEfLGaF2I+NV3b7mPUoGY4t+ZAxOY8buYkNGJUDGW2v uIcdmYJHGX3HI3PHmIN9SJIl+JFpWZiHeYZV2ZdxGZKNjJM/qI4xhZejS5M1L24lJZYv2YMnGGitlpUl 2Y6Zd5CVOZhtOZMd2VUdFoGnmXyn2F4lt/ycuGqRGWSttmaT15OZWZzl+Y1TOWSNeJOdWWrZOXec+InV uHnxuIgnl5gZem2/N5fN2Jwfem77eWFFtqJbNpp0doMJuv8K8oUhN/fwuGHJmaTl9oY7mYW5WJCZeVQl OJkdC0KtuYYH2qNvGqdzWqd3/5qne9qnfxqog1qoh5qoi9qojxqpk1qpl5qpm9qpnxqqo1qqPZeHzTWb lWadK3iXa3l1phpPH9mq6XlwRbl36m98O9qr1dOY6+ucV1lnP8ysFxit0xo90/ilx/mqsVk53smd7Vhu XzZrTvqY33FlR7ppsZiureJzl9ie126PC9uu+Vl3VctV7Dqg8Vl3TZmNyTqxGRmib5lCe0iMkXiMry10 u/iiI3ux2+y0S9tlO9s7Pxu1F/eaO8+hQRk4DRqV9zm0RZuQlxmYYBs8R3tpT1msbdu4uanKVnu3W1q3 31q5o9ihhTu2izemffi4+bj1THu5mdu3z7iMP5i7pXutqf+7OYkblqG7vIv5tx96kymXns+6vVG6mc37 vNtYcn53tUC6a527sd9MaE36cvd7vgdchmnbvreLv0nblRuat1v5wc15kicaio95niFXsiEruRMcugIc oyGawuvZvQ8ar6Gbwhe6kMn7SVlWu0ecw6PP+8DGhlmbd138sAFZnZt7j7ETbnOcsrmZvl9cyIecyIvc yI8cyZNcyZecyZvcyZ8cyqNcyqecyqvcyq8cy7Ncy7ecy7vcy78czMNczMeczMvczM8czdNczdeczdvc zd8czuNczueczuvczu8cz/Ncz/ecz/vcz/8c0ANd0Aed0Avd0A8d0XlWruOZx9d3iVP/G9LLOsbPD8St LNHrM329+7kvG33Ce9MLm6qJ25UX/NKNp3st+8LNGC1SnXZXGGlXm9XfW8RLvTE+/Y95L503/IZtt3Yr OyFwndfXUbMRm9brWV6ROPeC/cexOdl9fGsLAth9HNk5vdjR19jdS4ibnY0Nm9lVS9lVl6q1Pdqzndqr PfwuGtqJ1tul/XG//dsP99d7fd233Zor3dw1gz+OXb/nHdfxVt5znco2193Zndxf+t5DmHS5l94BHpHD nd//Hd5ZY+HfvbJh+ODPfWEVvqp5PbwtXvNYHbXTXdwhPqW5/eIHGNUfOInH3bK7vd5hPbhF/uFNXqQN /uRRXrcd/z1QRnXg9X3h3/sRX7fn+z11Pf7me6Jqnzfnd/jflf2dk37kwbnCh57kd97lj7698r2Sn5fn CX7rIdzr+3Kz0Xnml52maR7ryU/rwb7ou37i8xluqL7VZ7nhGZ7b7V3n0777Ep7aRz3qo5vR337YWTfk 7X7ZKX2u9X7AjvDVZfrvz37Xw37uo0jwid7eIV/x65XvZd7j5T6Sy15pbR30Kb7ROTvzq0/oX8jzMf/x nR7qN3/1a/7qTz/84j3jR1/gK7/qzb7zJR/tf5/2tdjnYX7pRZ+xdxPvpzfWQb7lWT/4p2b4y3jTjd/X ZTrwhUrTiT/7Tf/5e/Z2t9/DN/jyOyEe+H090o/f8btf/def/dvf/d8f/uNf/uef/uvf/qW6AAAAIf5w aHFnaHVtZWF5bG5sZmR4ZmlyY3ZzY3hnZ2J3a2ZucWR1eHdmbmZvenZzcnRranByZXBnZ3hycG5ydnlz bGxobmNqZmhkcnR0c3RlZnJwdmhyb3pwam1ncGNjenp4ZWh1Znh4bGdzemZienp3em92ADs= --------------090406050605000504000009-- From rtg-dir-bounces@ietf.org Thu Apr 7 20:36:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23487 for ; Thu, 7 Apr 2005 20:36:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJhcU-0000p2-Mg for rtg-dir-archive@ietf.org; Thu, 07 Apr 2005 20:45:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJhRv-0001yM-AQ; Thu, 07 Apr 2005 20:34:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJhRs-0001yH-D0 for rtg-dir@megatron.ietf.org; Thu, 07 Apr 2005 20:34:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23308 for ; Thu, 7 Apr 2005 20:34:10 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJhaW-0000mm-B0 for rtg-dir@ietf.org; Thu, 07 Apr 2005 20:43:09 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJhRn-0007CB-Uo; Fri, 08 Apr 2005 00:34:08 +0000 Date: Thu, 7 Apr 2005 19:34:06 -0500 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1873021459.20050407193406@psg.com> To: Tomonori TAKEDA In-Reply-To: <5.1.1.9.2.20050404145834.05578928@imf.m.ecl.ntt.co.jp> References: <5.1.1.9.2.20050404145834.05578928@imf.m.ecl.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: Igor Bryskin , Dimitri.Papadimitriou@alcatel.be, Kireeti Kompella , rtg-dir@ietf.org, Adrian Farrel Subject: Re: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Folks- Thanks everyone for your responses. It appears that there's an agreement on making the signalling-only model the first step and then enhancing it with some routing (for some value of this word) mechanisms. Before we go further, I'd like to make sure we agree on the bigger picture. Correct as needed, pls. Briefly, in the general case: CE functionality. Needs to know: 1) what prefixes are behind other CEs, i.e. reachability information Manually configured or smth like OSPF DC in the sig-only case. NOTE: in the general case, those don't have to be IP. 2) set of signaling params. the minimal set is the remote CE interface and basic connection characteristics (mux type, BW). advanced cases may include more TE information to influence the LSP trajectory. Manually configured in the the sig-only case. 3) how to signal the connection through the provider's cloud 4) status of established connections PE functionality. Needs to know: 1) (in the sig+rtg model) how to help CEs distribute reachability information + (in the per-VPN peer mode) may also need to expose some internal topology to the CEs 2) CE's signaling notation 3) how to process CE's signaling requests and translate them into internal GMPLS LSP requests 4) how to tell CEs about connection status -- Alex From rtg-dir-bounces@ietf.org Fri Apr 8 15:56:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05459 for ; Fri, 8 Apr 2005 15:56:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJzjG-0002ZM-Jv for rtg-dir-archive@ietf.org; Fri, 08 Apr 2005 16:05:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzMi-0004X1-Rc; Fri, 08 Apr 2005 15:42:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzMh-0004WM-LJ for rtg-dir@megatron.ietf.org; Fri, 08 Apr 2005 15:42:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00346 for ; Fri, 8 Apr 2005 15:42:01 -0400 (EDT) Message-Id: <200504081942.PAA00346@ietf.org> Received: from lns-vlq-26-nic-82-254-174-120.adsl.proxad.net ([82.254.174.120] helo=jmpcreative.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJzVS-0000KX-6u for rtg-dir@ietf.org; Fri, 08 Apr 2005 15:51:09 -0400 From: "Motya Shoemaker" To: "Gwladus Ackerman" Date: Fri, 8 Apr 2005 15:42:01 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C53A01.4256DE89" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: Re: C'ialis VALLlUM Viagrra X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C53A01.4256DE89 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, in an instant moored her firmly to the Victorieuse. eyeing him askance, it is Levasseur. You may have heard of me. of the English. Levasseur had brought them back to Tortuga from the water, narrowly missing one of the crowded boats that waited Meanwhile Ogle was growing impatient. His arm still gripped by since a slave had made an attack upon him and all but strangled h Captain Blood did not directly answer. As before he perched hims Is that what you thought? My God! that our lives should depend u way, ye muckrake, faith, I'll be humouring you. alongside the towering mass of the Encarnadon. Up the ladder wen If you please, Colonel, said he, with a graceful flourish of the conviction which Wolverstone's argument was imposing upon his Have a nice day. ------=_NextPart_000_0008_01C53A01.4256DE89 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, = Would you like to spend less on yoour MEDlCATl0NS?
     
    VlSIT PPharmacyByMail SHOP and SAVE OVER 70%
     
    VA U AG  C IS
    Ll M Vl RA lAL  and many other
     
    Have a nice = day.
    P.S. You will be pleasaantly surprised with our prices!
    ------=_NextPart_000_0008_01C53A01.4256DE89-- From rtg-dir-bounces@ietf.org Sun Apr 10 11:48:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28048 for ; Sun, 10 Apr 2005 11:48:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKeom-0003de-VO for rtg-dir-archive@ietf.org; Sun, 10 Apr 2005 11:57:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKeex-00007p-7L; Sun, 10 Apr 2005 11:47:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKeew-00007g-Kd for rtg-dir@megatron.ietf.org; Sun, 10 Apr 2005 11:47:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28020 for ; Sun, 10 Apr 2005 11:47:35 -0400 (EDT) Message-Id: <200504101547.LAA28020@ietf.org> Received: from [211.244.21.66] (helo=jdsouth.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKeo8-0003a6-DJ for rtg-dir@ietf.org; Sun, 10 Apr 2005 11:57:09 -0400 From: "Dunja Jordan" To: "Iolanthe Irby" Date: Sun, 10 Apr 2005 11:47:41 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C53DE2.42594A9D" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.0 (+) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Subject: Re: VALlUM CIALlS VlA'GRA X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.8 (+) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C53DE2.42594A9D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, by the wishes of his officers - it was only because the service Royal master and the French nation. That which I think will be phrase filled his brain, reechoing and reverberating there. to have done with it for ever. Yet here have I been committed by Wolverstone swore elaborately, then suddenly checked. Out of the have kept him fast in Port Royal; but his sense of duty was smoth Seamanship is imbordand. Bud guns is guns. When he came to the surface again, gasping for air, the Cinco Lla knows, are just those of a hangman - to rid the Caribbean of alone. La Foudre under cover of the darkness had struck away to Have a nice day. ------=_NextPart_000_0008_01C53DE2.42594A9D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, = Do yyou want to cut down expenses on druggs?
     
    Visit = PPharmacyByMAlL STORE and=20 save up to   7 5 %
     
    *      =20 *  ***      =20 *       *****   =20 ******      =20 *            =       =20  *      = *      =20 *      **   =20 **      *     =20 *     =20 *            =  =20 ******    ***      =20 *      ***     =20 ***   *****
    *       * =20 ***       = *      =20 *****    ******      =20 *            =      =20   *     =20 *       *     =20 **    **     =20 *      *      *=20            =20  ******    ***      =20 *      ***     =20 ***   ***** 
    *      =20 *   *       * = *    =20 *     *   *    =20 *     *=20 *            =        =20 *    *       *=20 *      **   = *      *=20 *      *   =20 *            =  =20 *      *   =20 *       * *     =20 *        *  =20 *     *
    *      =20 *   *       * = *    =20 *     *   *    =20 *     *=20 *            =        =20 *    *       *=20 *      **   = *      *=20 *      *   =20 *            =  =20 *      *   =20 *       * *     =20 *        *  =20 *     *
     *    =20 *    *      *  =20 *    *        =20 *     *    *  =20 *            =        =20 ****       *   = *    =20 * *  *     *  =20 *     =20 ****           &nb= sp;  =20 *          =20 *      *   *    =20 *        *    = **** =20
     *     *   =20 *      *   *   =20 *         = *    =20 *    *  =20 *            =        =20 ****       *   = *    =20 * *  *     *  =20 *     =20 ****           &nb= sp;  =20 *          =20 *      *   *    =20 *        *    = **** =20
      *   *     = *    =20 *******   *  ****   * ****   =20 *******           =        =20 *  *      *******    = *  *=20 *    *******     * =20 *            =   =20 *          =20 *     *******   =20 *       =20 *        **
      *  =20 *     *     *******   = * =20 ****   * ****   =20 *******           =        =20 *  *      *******    = *  *=20 *    *******     * =20 *            =   =20 *          =20 *     *******   =20 *       =20 *        **
       *=20 *      *   =20 *       *  *    =20 *   *   *   =20 *      =20 *            =     =20 *    *    = *      =20 *   *   **   = *      =20 *   *   =20 *            =  =20 *      *    *   =20 *       *   *   =20 *   *   *     *
       = *=20 *      *   =20 *       *  *    =20 *   *   *   =20 *      =20 *            =     =20 *    *    = *      =20 *   *   **   = *      =20 *   *   =20 *            =  =20 *      *    *   =20 *       *   *   =20 *   *   *     = *
       =20 *      ***  =20 *       *    = ****   =20 *    **  *      =20 *            =    =20 *      *  =20 *       *  ***   ** =20 *       *  = *     =20 *            =  =20 ******    ***   = *      =20 *  ******   ***   *****
       =20 *      ***  =20 *       *    = ****   =20 *    **  *      =20 *            =    =20 *      *  =20 *       *  ***   ** =20 *       *  = *     =20 *            =  =20 ******    ***   = *      =20 *  ******   ***   ***** =
     
    ----- Original Message -----
    You will be pleasantly surprisedd with our prices!
    ------=_NextPart_000_0008_01C53DE2.42594A9D-- From rtg-dir-bounces@ietf.org Mon Apr 11 07:04:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02098 for ; Mon, 11 Apr 2005 07:04:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKwrr-0004BC-O6 for rtg-dir-archive@ietf.org; Mon, 11 Apr 2005 07:14:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKwgd-0001Fz-Vy; Mon, 11 Apr 2005 07:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKwgc-0001FP-Fl for rtg-dir@megatron.ietf.org; Mon, 11 Apr 2005 07:02:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01939 for ; Mon, 11 Apr 2005 07:02:23 -0400 (EDT) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKwpr-00046b-41 for rtg-dir@ietf.org; Mon, 11 Apr 2005 07:12:07 -0400 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-green.research.att.com (Postfix) with ESMTP id 1213EA7B00 for ; Mon, 11 Apr 2005 07:02:14 -0400 (EDT) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j3BB02eA030867 for ; Mon, 11 Apr 2005 04:00:02 -0700 (PDT) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j3BB02lb030866 for rtg-dir@ietf.org; Mon, 11 Apr 2005 04:00:02 -0700 (PDT) (envelope-from fenner) Date: Mon, 11 Apr 2005 04:00:02 -0700 (PDT) Message-Id: <200504111100.j3BB02lb030866@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: IESG agenda for 2005-04-14 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-04-14). Updated 2:25:54 EDT, April 11, 2005 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date An INVITE Inititiated Dialog Event Package TSV for the Session Initiation Protocol (SIP) (Proposed Standard) - 1 of 2 draft-ietf-sipping-dialog-package-05.txt [Open Web Ballot] Token: Allison Mankin An Extension to the Session Initiation TSV Protocol for Request History Information (Proposed Standard) - 2 of 2 draft-ietf-sip-history-info-06.txt [Open Web Ballot] Token: Allison Mankin 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item NONE 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item NONE 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item NONE 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issues From rtg-dir-bounces@ietf.org Mon Apr 11 17:11:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00646 for ; Mon, 11 Apr 2005 17:11:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6LU-0008WH-J4 for rtg-dir-archive@ietf.org; Mon, 11 Apr 2005 17:21:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5cN-0001ue-1R; Mon, 11 Apr 2005 16:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5cM-0001tr-4c for rtg-dir@megatron.ietf.org; Mon, 11 Apr 2005 16:34:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22262 for ; Mon, 11 Apr 2005 16:34:09 -0400 (EDT) Message-Id: <200504112034.QAA22262@ietf.org> Received: from apoitiers-152-1-17-46.w83-193.abo.wanadoo.fr ([83.193.15.46] helo=jamiroquai.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DL5lE-0005fP-To for rtg-dir@ietf.org; Mon, 11 Apr 2005 16:43:57 -0400 From: "Kato Haley" To: "Detlef Durham" Date: Mon, 11 Apr 2005 16:34:14 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C53DE2.425ADF46" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.2 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: Re: WALIUM CiALlS Wiagra X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C53DE2.425ADF46 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The man was tall and built on lines of agile strength, with a should thus come upon the Arabella at a time when, separated from So, so! M. de Rivarol smiled malignantly. Not only do you off ship was found almost between the Spaniards, her bows in line wit from him a moment, out to sea. Quite suddenly she looked at him Why, what's to fear? he said. It's a Christian country, this, You are not afraid to die, Don Diego? He expressed it to Wolverstone, who met him as he stepped aboard This way, said Mr. Blood. on me with some damage to my ship and loss of life to five of my If I command you... the Baron was beginning. But Blood across the great harbour of Port Royal to the green hills rising Have a nice day. ------=_NextPart_000_0008_01C53DE2.425ADF46 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, = Would you like to spend less on your MEDlCATl0NS?
     
    Visit = PharmacyByyMail STORE and=20 save up to   7 5 %
     
    VA U AG  C IS
    Ll M Vl RA lAL  and many other
     
    ----- Original Message -----
    Check Out our lowest prices on the Net!
    ------=_NextPart_000_0008_01C53DE2.425ADF46-- From rtg-dir-bounces@ietf.org Wed Apr 13 04:00:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03987 for ; Wed, 13 Apr 2005 04:00:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLcxe-0007QM-Vj for rtg-dir-archive@ietf.org; Wed, 13 Apr 2005 04:10:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLclh-0002bj-2Z; Wed, 13 Apr 2005 03:58:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLcle-0002Yy-Cy; Wed, 13 Apr 2005 03:58:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03830; Wed, 13 Apr 2005 03:58:24 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLcvG-0007Mw-Oa; Wed, 13 Apr 2005 04:08:31 -0400 Received: from [84.240.49.206] (helo=lan-84-240-49-206.vln.skynet.lt ident=[nitro]-27409) by mx2.foretec.com with smtp (Exim 4.24) id 1DLclV-0004Sz-42; Wed, 13 Apr 2005 03:58:25 -0400 Authentication-Results: moire.es from=premium.moresby.es; domainkeys=neutral (no sig) X-Originating-IP: [182.16.96.168] Received: from premium.soliton.es (EHLO premium.deduct.es) by premium.suspend.es with SMTP; Wed, 13 Apr 2005 01:55:15 -0700 Date: Wed, 13 Apr 2005 11:55:15 +0300 From: "Preston Orr" To: rtg-bfd-admin@ietf.org Message-ID: <117941.5257.mrohr@yebox.com> X-Mailer: Kana Connect 6 X-Spam-Score: 3.2 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: rtg-dir@ietf.org, rtgwg-admin@ietf.org, rv@ietf.org, rtgwg-web-archive@ietf.org, rtgwg@ietf.org Subject: High rates? Not with us! low fixed rate X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.2 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mrg-now-yes.com/sign.asp Best Regards, Cecile Friend to be remov(ed: http://www.mrg-now-yes.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Wed Apr 13 12:27:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11058 for ; Wed, 13 Apr 2005 12:27:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkrZ-0003j1-CV for rtg-dir-archive@ietf.org; Wed, 13 Apr 2005 12:37:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLkgH-0006ab-RR; Wed, 13 Apr 2005 12:25:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLkgH-0006aC-E3 for rtg-dir@megatron.ietf.org; Wed, 13 Apr 2005 12:25:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11011 for ; Wed, 13 Apr 2005 12:25:30 -0400 (EDT) Received: from cronos.ocn.ne.jp ([222.146.51.136] helo=smtp.cronos.ocn.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkq5-0003gO-RV for rtg-dir@ietf.org; Wed, 13 Apr 2005 12:35:42 -0400 Received: from TAKEDAPANA.lab.ntt.co.jp (FLA1Ado127.tky.mesh.ad.jp [210.151.151.127]) by smtp.cronos.ocn.ne.jp (Postfix) with ESMTP id AA4E03F5E; Thu, 14 Apr 2005 01:25:27 +0900 (JST) Message-Id: <5.1.1.11.2.20050414012429.00d16678@cronos.ocn.ne.jp> X-Sender: takeda.tomonori@cronos.ocn.ne.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1J Jr5-rev2 Date: Thu, 14 Apr 2005 01:25:26 +0900 To: Alex Zinin From: Tomonori TAKEDA In-Reply-To: <1873021459.20050407193406@psg.com> References: <5.1.1.9.2.20050404145834.05578928@imf.m.ecl.ntt.co.jp> <5.1.1.9.2.20050404145834.05578928@imf.m.ecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Cc: Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Igor Bryskin , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Hi Alex, Thank you very much for your further investigations. Please see my opinions in line. At 19:34 05/04/07 -0500, Alex Zinin wrote: >Folks- > > Thanks everyone for your responses. > > It appears that there's an agreement on making the signalling-only model the > first step and then enhancing it with some routing (for some value of this > word) mechanisms. > > Before we go further, I'd like to make sure we agree on the bigger picture. > Correct as needed, pls. Briefly, in the general case: > > CE functionality. Needs to know: > > 1) what prefixes are behind other CEs, i.e. reachability information > Manually configured or smth like OSPF DC in the sig-only case. > NOTE: in the general case, those don't have to be IP. Yes. In the sig-only model, customers may wish to obtain prefixes behind other CEs, or may not. And mechanisms for customers to obtain reachability information behind other CEs are transparent to the provider. In one case, as you suggested, customers may wish to obtain reachability information behind other CEs via OSPF DC (between CEs). This operation is transparent to the provider, and this is out of scope of the L1VPN work. In the typical deployment scenario, all VPN sites are managed by a single administrative entity (operator), and this entity knows prefixes behind other CEs. > 2) set of signaling params. the minimal set is the remote CE interface > and basic connection characteristics (mux type, BW). advanced cases > may include more TE information to influence the LSP trajectory. > Manually configured in the the sig-only case. Yes. Parameters in existing signaling protocols are good enough to handle all of those parameters (see GMPLS overlay I-D). Note manually configured or something else is out of the scope of the protocol (even in the sig+rtg model). > 3) how to signal the connection through the provider's cloud Yes. As in 2) above, parameters in existing signaling protocols are good enough to signal the connection through the provider's cloud. Provider's core nodes (PEs and Ps) and CEs all use GMPLS signaling, so no special procedures are required. > 4) status of established connections Yes. This is definitely needed. Since L1VPN connections are just GMPLS LSPs, we can use existing GMPLS mechanisms. Namely, we can utilize control plane mechanisms (e.g., Refresh messages) to monitor the status of these connections. Note since we are focusing on GMPLS perspective, mechanisms such as data plane OAM mechanisms are out of the scope, > PE functionality. Needs to know: > > 1) (in the sig+rtg model) how to help CEs distribute reachability information > + (in the per-VPN peer mode) may also need to expose some internal > topology to the CEs Yes. This is the additional piece required for the sig+rtg model Note to help CEs distribute reachability information, we already have several mechanisms (see GVPN I-D). In addition, the per-VPN peer model is conceptually similar to virtual routers although the implementation might be different. > 2) CE's signaling notation Yes. As I mentioned above (2) and 3) in CE functionality), CE's signaling notation is just normal GMPLS signaling notation. Inventing new signaling protocols is out of the scope for us. There is no reason to assume anything except the normal GMPLS signaling. > 3) how to process CE's signaling requests and translate them into internal > GMPLS LSP requests Yes. Note we already have several mechanisms, such as stitching/nesting. Here, we do not perform any "translation". We expect to use the same signaling protocols and formats. The only "mapping" required is from one IP address space to another. > 4) how to tell CEs about connection status Yes. As I mentioned above (4) in CE functionality), we can use existing GMPLS mechanisms, such as Refresh, Notify and PathErr. In summary, I think all items are important functionalities to provide L1VPN services, and most of them are already covered by standard GMPLS (RFC3473) or proposed extensions (GVPN I-D, GMPLS overlay I-D). I do not think there are any major items missing here. Best regards, Tomonori, >-- >Alex > > From rtg-dir-bounces@ietf.org Thu Apr 14 07:46:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02858 for ; Thu, 14 Apr 2005 07:46:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM2xp-0002u9-6n for rtg-dir-archive@ietf.org; Thu, 14 Apr 2005 07:56:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM2ma-0000tW-2F; Thu, 14 Apr 2005 07:45:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM2mY-0000tI-LY for rtg-dir@megatron.ietf.org; Thu, 14 Apr 2005 07:45:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02753 for ; Thu, 14 Apr 2005 07:45:13 -0400 (EDT) Message-Id: <200504141145.HAA02753@ietf.org> Received: from bobburty.demon.co.uk ([80.177.168.108] helo=jlpa.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DM2wW-0002rW-Ak for rtg-dir@ietf.org; Thu, 14 Apr 2005 07:55:33 -0400 From: "Hena Jack" To: "Sammi Miles" Date: Thu, 14 Apr 2005 07:45:09 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C54072.425E57C5" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: Re: Va1ium ClALlS V'iagra X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.8 (++++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C54072.425E57C5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, asked the stars. of metal and of men, and if I know him at all he'll sink us befor song perishing on their lips, stared, stricken and bewildered at flamboyance he had named La Foudre, and there on the following da fallen against him in this venture. The tables had been turned u hauled aboard. his the risk if it should afterwards not be forthcoming. also of my coming before he set out. a suggestion of a sneer, it's the most ye should expect from me, I hope I am not obscure, said he. necessary to bribe a gang of scoundrels to depart from obedience to be vindictive. I doubt if ye're worth the pains I've taken fo As the Captain's evidence concluded, Lord Jeffreys looked across Have a nice day. ------=_NextPart_000_0008_01C54072.425E57C5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello,
     
    #     #                         =
                     #####                                             # =
    #
#     #  #    ##     ####   #####     ##            #     #  #    ##    =
#       #   ####               #     #    ##    #       #  #    #  #    =
#
#     #  #   #  #   #    #  #    #   #  #           #        #   #  #   =
#       #  #                   #     #   #  #   #       #  #    #  ##  =
##
#     #  #  #    #  #       #    #  #    #          #        #  #    #  =
#       #   ####               #     #  #    #  #       #  #    #  # ## =
#
 #   #   #  ######  #  ###  #####   ######          #        #  ######  =
#       #       #               #   #   ######  #       #  #    #  #    =
#
  # #    #  #    #  #    #  #   #   #    #          #     #  #  #    #  =
#       #  #    #                # #    #    #  #       #  #    #  #    =
#
   #     #  #    #   ####   #    #  #    #           #####   #  #    #  =
######  #   ####                  #     #    #  ######  #   ####   #    =
#
     
    And Many other.
     
    Visit = PharamcyByMAlL SHOPP and save up = to  =20 6 0 %
     
    Have a nice = day.
    ----- Original Message -----
    Try us aand you will NOT BE DlSAPPOlNTED!
    ------=_NextPart_000_0008_01C54072.425E57C5-- From rtg-dir-bounces@ietf.org Thu Apr 14 11:33:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24927 for ; Thu, 14 Apr 2005 11:33:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6VM-0004az-NI for rtg-dir-archive@ietf.org; Thu, 14 Apr 2005 11:43:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6LE-0006KP-Kb; Thu, 14 Apr 2005 11:33:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6LC-0006Bg-N3 for rtg-dir@megatron.ietf.org; Thu, 14 Apr 2005 11:33:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24875 for ; Thu, 14 Apr 2005 11:32:50 -0400 (EDT) Received: from pd9536eea.dip.t-dialin.net ([217.83.110.234]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DM6Uq-0004Zr-LK for rtg-dir@ietf.org; Thu, 14 Apr 2005 11:43:14 -0400 Message-ID: <1eed01c540fe$54fc293c$3618afc6@about.com> From: "Vanessa J. Smith" To: rtg-dir@ietf.org Date: Thu, 14 Apr 2005 14:27:52 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_2A61C269.DC255309" 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-Score: 4.5 (++++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: Cheap software X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.5 (++++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is a multi-part message in MIME format. ------=_NextPart_000_0000_2A61C269.DC255309 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_8B7D980F.3DE782EB" ------=_NextPart_001_0001_8B7D980F.3DE782EB Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Access all the software you need for extremely low prices! We sell software 2-6 times cheaper than retail price. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... To view full list of products go: http://www.soft-disks.com Sincerely, Vanessa Smith _____________________________________________________ To change your mail details, go: http://www.soft-disks.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_8B7D980F.3DE782EB Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
    Get all the popular software imaginable for prices substantially lower than in stores!
    Our software is 2-10 times cheaper than sold by our competitors.

    Just a few examples:
    $79.95 Windows XP Professional (Including: Service Pack 2)
    $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
    $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
    $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
    $79.95 Adobe Acrobat 6.0 Professional
    $59.95 Corel Draw Graphics Suite 11

    Special Offers:
    $89.95 Windows XP Professional + Office XP Professional
    $149.95 Adobe Creative Suite Premium (5 CD)
    $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

    All main products from Microsoft, Adobe, Macromedia, Corel, etc.
    And many more... Please visit us at:

    http://www.soft-disks.com

    Best regards,
    Vanessa Smith


    _____________________________________________________
    To be taken out, go here: http://www.soft-disks.com/uns.htm
    _____________________________________________________

    ------=_NextPart_001_0001_8B7D980F.3DE782EB-- ------=_NextPart_000_0000_2A61C269.DC255309-- From rtg-dir-bounces@ietf.org Thu Apr 14 14:24:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09070 for ; Thu, 14 Apr 2005 14:24:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9BB-0003L1-T5 for rtg-dir-archive@ietf.org; Thu, 14 Apr 2005 14:35:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM90W-0000CP-Ap; Thu, 14 Apr 2005 14:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM90U-0000C2-87 for rtg-dir@megatron.ietf.org; Thu, 14 Apr 2005 14:24:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08994 for ; Thu, 14 Apr 2005 14:23:52 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9AO-0003JW-DZ for rtg-dir@ietf.org; Thu, 14 Apr 2005 14:34:16 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j3EINm9x003568; Thu, 14 Apr 2005 20:23:48 +0200 To: Tomonori TAKEDA MIME-Version: 1.0 Date: Thu, 14 Apr 2005 20:23:47 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 04/14/2005 20:23:48 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: Alex Zinin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Igor Bryskin , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 hi tomonori, all see in-line - starting with [dp] At 19:34 05/04/07 -0500, Alex Zinin wrote: > Folks- > > Thanks everyone for your responses. > > It appears that there's an agreement on making the signalling-only model the > first step and then enhancing it with some routing (for some value of this > word) mechanisms. > > Before we go further, I'd like to make sure we agree on the bigger picture. > Correct as needed, pls. Briefly, in the general case: > > CE functionality. Needs to know: > > 1) what prefixes are behind other CEs, i.e. reachability information > Manually configured or smth like OSPF DC in the sig-only case. > NOTE: in the general case, those don't have to be IP. Yes. In the sig-only model, customers may wish to obtain prefixes behind other CEs, or may not. And mechanisms for customers to obtain reachability information behind other CEs are transparent to the provider. In one case, as you suggested, customers may wish to obtain reachability information behind other CEs via OSPF DC (between CEs). This operation is transparent to the provider, and this is out of scope of the L1VPN work. [dp] in fact this is pointing us to one of the fundamental issues that were never part of any GMPLS discussion in the overlay model context, the address resolution problem without which all mechanism from the CE are simple manual [dp] the other question is of course ensure proper reachability information exchange among PE's such that incoming request can be routed toward the appropriate egress PE In the typical deployment scenario, all VPN sites are managed by a single administrative entity (operator), and this entity knows prefixes behind other CEs. [dp] as usual, we would have two cases in the single carrier context, single AS vs multiple AS > 2) set of signaling params. the minimal set is the remote CE interface > and basic connection characteristics (mux type, BW). advanced cases > may include more TE information to influence the LSP trajectory. > Manually configured in the the sig-only case. Yes. Parameters in existing signaling protocols are good enough to handle all of those parameters (see GMPLS overlay I-D). Note manually configured or something else is out of the scope of the protocol (even in the sig+rtg model). > 3) how to signal the connection through the provider's cloud Yes. As in 2) above, parameters in existing signaling protocols are good enough to signal the connection through the provider's cloud. Provider's core nodes (PEs and Ps) and CEs all use GMPLS signaling, so no special procedures are required. [dp] see point 3 here below > 4) status of established connections Yes. This is definitely needed. Since L1VPN connections are just GMPLS LSPs, we can use existing GMPLS mechanisms. Namely, we can utilize control plane mechanisms (e.g., Refresh messages) to monitor the status of these connections. Note since we are focusing on GMPLS perspective, mechanisms such as data plane OAM mechanisms are out of the scope, [dp] ok - here there is a need to analyze details in terms of requirements concerning PathErr/ResvErr information exchange through the IF_ID RSVP_HOP object TLV and further refine the Notify message exchange > PE functionality. Needs to know: > > 1) (in the sig+rtg model) how to help CEs distribute reachability > information + (in the per-VPN peer mode) may also need to expose some > internal topology to the CEs Yes. This is the additional piece required for the sig+rtg model [dp] this is definitelly one of the major piece of work for this model Note to help CEs distribute reachability information, we already have several mechanisms (see GVPN I-D). In addition, the per-VPN peer model is conceptually similar to virtual routers although the implementation might be different. > 2) CE's signaling notation Yes. As I mentioned above (2) and 3) in CE functionality), CE's signaling notation is just normal GMPLS signaling notation. Inventing new signaling protocols is out of the scope for us. There is no reason to assume anything except the normal GMPLS signaling. > 3) how to process CE's signaling requests and translate them into internal > GMPLS LSP requests Yes. Note we already have several mechanisms, such as stitching/nesting. Here, we do not perform any "translation". We expect to use the same signaling protocols and formats. The only "mapping" required is from one IP address space to another. [dp] CE's signaling requests are expected to make use of GMPLS LSP request, the point here is to detail operations such as nesting, shuffling, etc. in the network, the latter (i.e. shuffling) implies protocol operations for objects SESSION, SENDER_TEMPLATE, FILTER_SPEC, etc. that carries end-to-end significant addresses ... example translation of sessions lists when Notify messages crosses PE's > 4) how to tell CEs about connection status Yes. As I mentioned above (4) in CE functionality), we can use existing GMPLS mechanisms, such as Refresh, Notify and PathErr. In summary, I think all items are important functionalities to provide L1VPN services, and most of them are already covered by standard GMPLS (RFC3473) or proposed extensions (GVPN I-D, GMPLS overlay I-D). I do not think there are any major items missing here. [dp] concerning the signaling most of the details would indeed be related to the shuffling operation, concerning reachability information exchange both cases i.e between PE's only (sig model) and between CE's through PE's (sig+rtg model) requires further work [dp] i would like also to know whether there is an assumption about homogeneity of the protocols (same protocol running between CE-PE and PE-..-PE) or can we assume that a different protocol can be running between CE-PE and between PE's ? Best regards, Tomonori, >-- >Alex > > From rtg-dir-bounces@ietf.org Sat Apr 16 04:30:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04661 for ; Sat, 16 Apr 2005 04:30:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMirJ-00027h-4d for rtg-dir-archive@ietf.org; Sat, 16 Apr 2005 04:40:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMiHt-0004Sq-P4; Sat, 16 Apr 2005 04: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 1DMiHq-0004SF-T9; Sat, 16 Apr 2005 04:04:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03299; Sat, 16 Apr 2005 04:04:14 -0400 (EDT) Received: from [221.167.147.166] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMiRB-0000fW-Gn; Sat, 16 Apr 2005 04:14:59 -0400 Received: from DMF@localhost by Vg4u.int (8.11.6/8.11.6); Sat, 16 Apr 2005 07:58:34 -0100 Message-ID: <5dJKFlUKFcHd6kK4ryrwmP@337back.com> From: "Martha Berliner" To: rtg-bfd@ietf.org, rtg-dir@ietf.org, rtgwg@ietf.org Date: Sat, 16 Apr 2005 02:00:34 -0700 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: UrsulaCooley@generalaromatics.com Content-Type: multipart/mixed; boundary="--IerAP7DTQwqPhiOfFg" X-Spam-Score: 3.6 (+++) X-Scan-Signature: ad122f56a92d6ccd133117ee8a4b1ff3 Subject: Windows XP Products available for Download X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martha Berliner List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.6 (+++) X-Scan-Signature: c5b976cb26c967a52d72d6069c7fc54c XInu ----IerAP7DTQwqPhiOfFg Content-Type: text/html; Content-Transfer-Encoding: quoted-printable B
    Opt-= in Email Special Offer     unsubscribe me
    SEARCH

    TOP 10 NEW TITLES

     ON SALE NOW!
      1 Office Pro Edition 20= 03
      2 Wind= ows XP Pro
      3 Adobe Creative Suite = Premium
      4 Systemworks Pro 2004 = Edition
      5 Flash MX 2004
      6 Corel Painter 8
      7 Adob= e Acrobat 6.0
      8 Windows 2003 Server
      9 Alias Maya 6.0 Wavefr= ont
      10 Adobe Premiere
      = See more by this man= ufacturer
        Microsoft<= /td>
        Ap= ple Software
      = Customers also bough= t
        these other items...<= /a>



    		Micr= osoft Office Professional Edition *2003*
    Microsoft
    Choose:
     
    =
    List Price: $899.00
    Price: $69.99
    You Save: $830.01 (92%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requirem= ents  |  Accessories  | = Other Versions

    Features:

    • Analyze and manage business inf= ormation using Access databases
    • Exchange data with other system= s using enhanced XML technology
    • Control information sharing rul= es with enhanced IRM technology
    • Easy-to-use wizards to create e= -mail newsletters and printed marketing materials
    • More than 20 preformatted busin= ess reports
    Sales Rank: #1
    Shipping: International/US or via instant downlo= ad
    Date Coupon Expires: April 28th, 2005
    Average Customer Review: 3D"5 Based on 1,768 reviews. Write a revie= w.
    Microsoft Wind= ows XP Professional or Longhorn Edition
    Microsoft
    Choose:
     

    =

    List Price: $279.00
    Price: $49.99
    You Save: $229.01 (85%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requ= irements  |  Accessories  |&n= bsp; Other Versions

    Features:

    • Designed for businesses of a= ll sizes
    • Manage digital pictures, mu= sic, video, DVDs, and more
    • More security with the abil= ity to encrypt files and folders
    • Built-in voice, video, and = instant messaging support
    • Integration with Windows se= rvers and management solutions

    Sales Rank: #2
    Shipping: International/US or via instant do= wnload
    Date Coupon Expires: April 28th, 2005
    Average Customer Review: 3D"5 Based on 868 reviews. Write a rev= iew.

    Adobe Crea= tive Suite Premium
    Adobe
    Choose:
     

    List Price: $1149.00
    Price: $99.99
    You Save: $849.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System = requirements  |  Accessories = |  Other Versions

    Features: <= /font>

    • An integrated design en= vironment featuring the industry's foremost design tools
    • In-depth tips, expert t= ricks, and comprehensive design resources
    • Intuitive file finding,= smooth workflow, and common interface and toolset
    • Single installer--contr= ol what you install and when you install it
    • Cross-media publishing-= -create content for both print and the Web

    Sales Rank: #3
    Shipping: International/US or via instan= t download
    Date Coupon Expires: April 28th, 2005
    Average Customer Review: 3D"5 Based on 498 reviews. Write a= review.

    Symantec SystemWorks = 2004 Professional
    Sym= antec
    Choose:
     =

    List Price: $99.00
    Price: $29.99
    You Save: $69.01 (70%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    Sys= tem requirements  |  Accessories  |&n= bsp; Other Versions


    Features: =

    • Norton Utilities op= timizes your PC=BFs performance and solves computer problems <= /li>
    • Norton Password Man= ager keeps your passwords secure and easy to manage
    • Norton GoBack Perso= nal Edition restores your PC after a serious problem
    • Norton CleanSweep r= emoves unwanted programs and files that waste disk space
    • Norton Ghost protec= ts your data from computer disasters

    Sales Rank: #4
    Shipping: International/US or via in= stant download
    Date Coupon Expires: April 28th, 2005
    Average Customer Review: 3D"5 Based on 217 reviews. Wri= te a review.

    =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20

    ----IerAP7DTQwqPhiOfFg-- From rtg-dir-bounces@ietf.org Mon Apr 18 07:05:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07314 for ; Mon, 18 Apr 2005 07:05:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNUFK-0005Xx-Pv for rtg-dir-archive@ietf.org; Mon, 18 Apr 2005 07:16:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNU24-0007TI-Jn; Mon, 18 Apr 2005 07:03:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNU22-0007TC-SU for rtg-dir@megatron.ietf.org; Mon, 18 Apr 2005 07:03:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07125 for ; Mon, 18 Apr 2005 07:03:08 -0400 (EDT) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNUCq-0005DM-Ay for rtg-dir@ietf.org; Mon, 18 Apr 2005 07:14:20 -0400 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-blue.research.att.com (Postfix) with ESMTP id 9628A1974C6 for ; Mon, 18 Apr 2005 07:01:58 -0400 (EDT) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j3IB03eA007913 for ; Mon, 18 Apr 2005 04:00:03 -0700 (PDT) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j3IB02ga007912 for rtg-dir@ietf.org; Mon, 18 Apr 2005 04:00:02 -0700 (PDT) (envelope-from fenner) Date: Mon, 18 Apr 2005 04:00:02 -0700 (PDT) Message-Id: <200504181100.j3IB02ga007912@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Subject: IESG agenda for 2005-04-25 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-04-25). Updated 2:26:15 EDT, April 18, 2005 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date Real-Time Transport Protocol (RTP) Payload TSV Formats for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec (Proposed Standard) - 1 of 3 draft-ietf-avt-rtp-vmr-wb-10.txt Note: 3GPP2 needs by October Thomas has corresponded with the chairs Token: Allison Mankin APP Server To Server Notification Protocol Requirements (Proposed Standard) - 2 of 3 draft-ietf-lemonade-notify-s2s-00.txt [Open Web Ballot] Token: Ted Hardie RTP Payload Format for Extended AMR Wideband TSV (AMR-WB+) Audio Codec (Proposed Standard) - 3 of 3 draft-ietf-avt-rtp-amrwbplus-06.txt Token: Allison Mankin 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item Area Date APP Jul 22 Domain Name System Uniform Resource Identifiers (Proposed Standard) - 1 of 3 draft-josefsson-dns-url-11.txt [Open Web Ballot] Token: Ted Hardie SEC Datagram Transport Layer Security (Proposed Standard) - 2 of 3 draft-rescorla-dtls-04.txt [Open Web Ballot] Token: Russ Housley APP Media Type Specifications and Registration Procedures (BCP) - 3 of 3 draft-freed-media-type-reg-04.txt [Open Web Ballot] Token: Scott Hollenbeck 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item NONE 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date APP URN Namespace for Federated Content (Informational) - 1 of 2 draft-dtessman-urn-namespace-federated-content-01.txt [Open Web Ballot] Note: RFC Editor note: Rules for Lexical Equivalence:    In addition to the rules defined in RFC 2141 [4], normalize the    case of the ProviderId before comparison. Rules for Lexical Equivalence:    In addition to the rules defined in RFC 2141 [4], normalize the    case of the ProviderId to lower case before comparison. Token: Ted Hardie APP ISAN URN Definition (Informational) - 2 of 2 draft-dolan-urn-isan-00.txt [Open Web Ballot] Token: Ted Hardie 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item NONE 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. Agenda Working Group News 6. IAB News We can use 7. Management Issues From rtg-dir-bounces@ietf.org Wed Apr 20 05:02:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18040 for ; Wed, 20 Apr 2005 05:02:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOBHM-0003Ii-70 for rtg-dir-archive@ietf.org; Wed, 20 Apr 2005 05:13:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOB4z-0000Cx-94; Wed, 20 Apr 2005 05:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOB4x-0000Cs-VY for rtg-dir@megatron.ietf.org; Wed, 20 Apr 2005 05:01:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18019 for ; Wed, 20 Apr 2005 05:01:01 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOBG6-0003Ho-9i for rtg-dir@ietf.org; Wed, 20 Apr 2005 05:12:37 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3K90m86006068; Wed, 20 Apr 2005 18:00:48 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3K90lOl000138; Wed, 20 Apr 2005 18:00:47 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3K90lQB000127; Wed, 20 Apr 2005 18:00:47 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3K90klE007067; Wed, 20 Apr 2005 18:00:46 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3K90kk6007056; Wed, 20 Apr 2005 18:00:46 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3K90jrj013219; Wed, 20 Apr 2005 18:00:45 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3K90jK7001982; Wed, 20 Apr 2005 18:00:45 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (ipf0.m.ecl.ntt.co.jp [129.60.5.159]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j3K90jaM001977; Wed, 20 Apr 2005 18:00:45 +0900 (JST) Received: from TAKEDA_PANA.lab.ntt.co.jp by imf.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA08017; Wed, 20 Apr 2005 18:00:43 +0900 (JST) Message-Id: <5.1.1.9.2.20050420152913.067fc360@imf.m.ecl.ntt.co.jp> X-Sender: tt043@imf.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Wed, 20 Apr 2005 18:01:51 +0900 To: Dimitri.Papadimitriou@alcatel.be From: Tomonori TAKEDA In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Igor Bryskin , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: L1VPN service models X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Content-Transfer-Encoding: 7bit Hi Dimitri, Thank you very much for your comments, and sorry for late response. Please see in-line. At 20:23 05/04/14 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >hi tomonori, all > >see in-line - starting with [dp] > >At 19:34 05/04/07 -0500, Alex Zinin wrote: > > Folks- > > > > Thanks everyone for your responses. > > > > It appears that there's an agreement on making the signalling-only model >the > > first step and then enhancing it with some routing (for some value of >this > > word) mechanisms. > > > > Before we go further, I'd like to make sure we agree on the bigger >picture. > > Correct as needed, pls. Briefly, in the general case: > > > > CE functionality. Needs to know: > > > > 1) what prefixes are behind other CEs, i.e. reachability information > > Manually configured or smth like OSPF DC in the sig-only case. > > NOTE: in the general case, those don't have to be IP. > >Yes. > >In the sig-only model, customers may wish to obtain prefixes behind other >CEs, or may not. And mechanisms for customers to obtain reachability >information behind other CEs are transparent to the provider. In one case, >as you suggested, customers may wish to obtain reachability information >behind other CEs via OSPF DC (between CEs). This operation is transparent >to the provider, and this is out of scope of the L1VPN work. > >[dp] in fact this is pointing us to one of the fundamental issues that were >never part of any GMPLS discussion in the overlay model context, the >address >resolution problem without which all mechanism from the CE are simple >manual OK. There may be a need to further consider this issue. Note this functionality is not L1VPN specific, and that is why I mentioned this is out of scope of the L1VPN work. >[dp] the other question is of course ensure proper reachability information >exchange among PE's such that incoming request can be routed toward the >appropriate egress PE Agreed. This is an important functionality for the PE. >In the typical deployment scenario, all VPN sites are managed by a single >administrative entity (operator), and this entity knows prefixes behind >other CEs. > >[dp] as usual, we would have two cases in the single carrier context, >single >AS vs multiple AS Yes. Note, even in multiple ASes, in the single carrier context, addresses may be assigned by a single administrative entity. > > 2) set of signaling params. the minimal set is the remote CE interface > > and basic connection characteristics (mux type, BW). advanced cases > > may include more TE information to influence the LSP trajectory. > > Manually configured in the the sig-only case. > >Yes. > >Parameters in existing signaling protocols are good enough to handle all of >those parameters (see GMPLS overlay I-D). > >Note manually configured or something else is out of the scope of the >protocol (even in the sig+rtg model). > > > 3) how to signal the connection through the provider's cloud > >Yes. > >As in 2) above, parameters in existing signaling protocols are good enough >to signal the connection through the provider's cloud. Provider's core >nodes (PEs and Ps) and CEs all use GMPLS signaling, so no special >procedures are required. > >[dp] see point 3 here below > > > 4) status of established connections > >Yes. This is definitely needed. > >Since L1VPN connections are just GMPLS LSPs, we can use existing GMPLS >mechanisms. Namely, we can utilize control plane mechanisms (e.g., Refresh >messages) to monitor the status of these connections. > >Note since we are focusing on GMPLS perspective, mechanisms such as data >plane OAM mechanisms are out of the scope, > >[dp] ok - here there is a need to analyze details in terms of requirements >concerning PathErr/ResvErr information exchange through the IF_ID RSVP_HOP >object TLV and further refine the Notify message exchange I do not think there is anything special for L1VPNs. Could you please share your ideas? > > PE functionality. Needs to know: > > > > 1) (in the sig+rtg model) how to help CEs distribute reachability > > information + (in the per-VPN peer mode) may also need to expose some > > internal topology to the CEs > >Yes. This is the additional piece required for the sig+rtg model > >[dp] this is definitelly one of the major piece of work for this model > >Note to help CEs distribute reachability information, we already have >several mechanisms (see GVPN I-D). In addition, the per-VPN peer model is >conceptually similar to virtual routers although the implementation might >be different. > > > 2) CE's signaling notation > >Yes. > >As I mentioned above (2) and 3) in CE functionality), CE's signaling >notation is just normal GMPLS signaling notation. Inventing new signaling >protocols is out of the scope for us. There is no reason to assume anything >except the normal GMPLS signaling. > > > 3) how to process CE's signaling requests and translate them into >internal > > GMPLS LSP requests > >Yes. > >Note we already have several mechanisms, such as stitching/nesting. Here, >we do not perform any "translation". We expect to use the same signaling >protocols and formats. The only "mapping" required is from one IP address >space to another. > >[dp] CE's signaling requests are expected to make use of GMPLS LSP request, >the point here is to detail operations such as nesting, shuffling, etc. in >the network, the latter (i.e. shuffling) implies protocol operations for >objects SESSION, SENDER_TEMPLATE, FILTER_SPEC, etc. that carries end-to-end >significant addresses ... example translation of sessions lists when Notify >messages crosses PE's OK. First, we need to think whether we would want shuffling as a standard mechanism. My personal opinion is that stitching/nesting already supports required mechanisms for L1VPNs. Therefore, I am not sure whether we need another approach (shuffling). > > 4) how to tell CEs about connection status > >Yes. > >As I mentioned above (4) in CE functionality), we can use existing GMPLS >mechanisms, such as Refresh, Notify and PathErr. > >In summary, I think all items are important functionalities to provide >L1VPN services, and most of them are already covered by standard GMPLS >(RFC3473) or proposed extensions (GVPN I-D, GMPLS overlay I-D). > >I do not think there are any major items missing here. > >[dp] concerning the signaling most of the details would indeed be related >to the shuffling operation, concerning reachability information exchange >both cases i.e between PE's only (sig model) and between CE's through PE's >(sig+rtg model) requires further work Agreed. As I said above, need for shuffling is a subject for discussion. >[dp] i would like also to know whether there is an assumption about >homogeneity of the protocols (same protocol running between CE-PE and >PE-..-PE) or can we assume that a different protocol can be running between >CE-PE and between PE's ? If homegeneity means the same protocol, regardless of the same instance or not, then my understanding is that we are looking at homegeneity. For example, - We would not run GMPLS CR-LDP between CE and PE, and GMPLS RSVP-TE in the provider network. So, there is no need to perform protocol conversion (or parameter mapping). Best regards, Tomonori >Best regards, > >Tomonori, > > >-- > >Alex > > > > From rtg-dir-bounces@ietf.org Fri Apr 22 17:22:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03829 for ; Fri, 22 Apr 2005 17:22:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP5ms-0000gd-LO for rtg-dir-archive@ietf.org; Fri, 22 Apr 2005 17:34:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP5ay-0006is-GS; Fri, 22 Apr 2005 17:21:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP5aw-0006h0-Sb for rtg-dir@megatron.ietf.org; Fri, 22 Apr 2005 17:21:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03796 for ; Fri, 22 Apr 2005 17:21:48 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP5md-0000g2-MD for rtg-dir@ietf.org; Fri, 22 Apr 2005 17:33:56 -0400 Received: from aut75-3-82-227-118-51.fbx.proxad.net ([82.227.118.51]) by mx2.foretec.com with smtp (Exim 4.24) id 1DP5au-0007IK-1t for rtg-dir@ietf.org; Fri, 22 Apr 2005 17:21:49 -0400 Message-ID: From: "Susan M. Taylor" <62asa@about.com> To: rtg-dir@ietf.org Date: Fri, 22 Apr 2005 21:10:50 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_69C4FC99.768B6299" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.0 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: Swiss watches - copies X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This is a multi-part message in MIME format. ------=_NextPart_000_0000_69C4FC99.768B6299 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_5F4DC4C3.CC8EC696" ------=_NextPart_001_0001_5F4DC4C3.CC8EC696 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit REPLICA WATCH MODELS - exact copies of the original watches - perfect as a gift for your colleagues and friends - free gift box Rolex, Patek Philippe, Omega Cartier, Gucci, Franck Muller .. and 25 other most famous manufacturers. http://www.cheapwatches.biz All copies are for only $249.99! _________________________________________________________________________ To change your mail preferences, go here _________________________________________________________________________ ------=_NextPart_001_0001_5F4DC4C3.CC8EC696 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

    REPLICA WATCH MODELS

    - exact copies of the original watches
    - perfect as a gift for your colleagues and friends
    - free gift box

    Rolex, Patek Philippe, Omega
    Cartier, Gucci, Franck Muller

    .. and 25 other most famous manufacturers.

    http://www.cheapwatches.biz

    All copies are for only $249.99!


    _________________________________________________________________________
    To change your mail preferences, go here
    _________________________________________________________________________

    ------=_NextPart_001_0001_5F4DC4C3.CC8EC696-- ------=_NextPart_000_0000_69C4FC99.768B6299-- From rtg-dir-bounces@ietf.org Sat Apr 23 02:29:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00768 for ; Sat, 23 Apr 2005 02:29:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPEKM-0004aQ-6x for rtg-dir-archive@ietf.org; Sat, 23 Apr 2005 02:41:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPE7V-0006bp-HM; Sat, 23 Apr 2005 02:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPE7S-0006ax-OQ for rtg-dir@megatron.ietf.org; Sat, 23 Apr 2005 02:27:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00583 for ; Sat, 23 Apr 2005 02:27:57 -0400 (EDT) Message-Id: <200504230627.CAA00583@ietf.org> Received: from 218-162-64-61.dynamic.hinet.net ([218.162.64.61] helo=jlgolf.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DPEJE-0004Z8-4P for rtg-dir@ietf.org; Sat, 23 Apr 2005 02:40:09 -0400 From: "Redd Jamison" To: "Babur Landry" Date: Sat, 23 Apr 2005 02:27:55 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C545A2.4269F8FB" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: Re: Walium CiALlS VlA'GRA X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C545A2.4269F8FB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, My lord, you are in the right. I am a fool. But don't be speculations born of that singular fragrance. He was in no mood buccaneer had slashed the halyard with his cutlass. The boarders it, and there ran into Pitt, alone, toiling with a wooden spade u Peter Blood gaped at him a moment in consternation. The man was It's good-bye, my lord, said Blood. And there's another thing my belief that we shall not meet again. You'll keep that opinion to yourself, the Captain answered him. pain. glance at the swarm of fierce, half-naked fellows lounging in a of eight. Gold has at all times been considered the best of Levasseur dashed one hand against the other, as if dusting them. cracking Bishop like a flea only by their submission to the domin THE LAST FIGHT OF THE ARABELLA Have a nice day. ------=_NextPart_000_0008_01C545A2.4269F8FB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, = Would you like to sspend less on your MEDlCATl0NS?
    V gr
    ia a as low as $200.00=20 (120 piIIs)
    Ci li
    a s as low as $180.00=20 (80 piIIs)
    Va iu
    l m as low as $250.00=20 (220 piIIs)
    Le t
    vi ra as low as $300.00=20 (50 piIIs)
    X a
    an x as low as $270.00=20 (200 piIIs) and many = other
     
    Have a nice day.
    P.S. You will be pleasantly surprised with our priices! =
    ------=_NextPart_000_0008_01C545A2.4269F8FB-- From rtg-dir-bounces@ietf.org Sat Apr 23 16:46:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23657 for ; Sat, 23 Apr 2005 16:46:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPRiP-0008RX-A5 for rtg-dir-archive@ietf.org; Sat, 23 Apr 2005 16:59:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPRU6-0003Cm-7n; Sat, 23 Apr 2005 16:44:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPRU1-0003Ce-OG for rtg-dir@megatron.ietf.org; Sat, 23 Apr 2005 16:44:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23530 for ; Sat, 23 Apr 2005 16:44:07 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPRfv-0008Pb-CP for rtg-dir@ietf.org; Sat, 23 Apr 2005 16:56:28 -0400 Received: from du-069-0188.access.clara.net ([217.158.132.188] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DPRTt-0008IK-I2; Sat, 23 Apr 2005 21:44:03 +0100 Message-ID: <00a401c54845$754979a0$1c849ed9@Puppy> From: "Adrian Farrel" To: "Alex Zinin" References: <5.1.1.9.2.20050420152913.067fc360@imf.m.ecl.ntt.co.jp> Date: Sat, 23 Apr 2005 21:05:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Dimitri.Papadimitriou@alcatel.be, takeda.tomonori@lab.ntt.co.jp, Igor Bryskin , rtg-dir@ietf.org Subject: L1VPN evaluation status? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Content-Transfer-Encoding: 7bit Hi Alex, There has been some reasonably constructive discussion on this topic which to me indicates: - Not all of the decisions have been taken yet Probably a good thing :-) - There is value in having an open (wider) debate in some context perhaps on the L1VPN mailing list. If you don't think this is inappropriate, I would like someone (Dimitri? Tomonori? me?) to move some of the discussion to there. - There are no *huge* protocol holes that have been identified. (I didn't hear anyone say, "And therefore we need a new routing protocol.") Soooo... How is your assessment coming along? Which way are you inclined to jump? And what more can we do to help with your evaluation? Cheers, Adrian ----- Original Message ----- From: "Tomonori TAKEDA" To: Cc: "Alex Zinin" ; ; ; "Kireeti Kompella" ; "Igor Bryskin" ; "Adrian Farrel" ; Sent: Wednesday, April 20, 2005 10:01 AM Subject: Re: L1VPN service models > Hi Dimitri, > > Thank you very much for your comments, and sorry for late response. > > Please see in-line. > > At 20:23 05/04/14 +0200, Dimitri.Papadimitriou@alcatel.be wrote: > > >hi tomonori, all > > > >see in-line - starting with [dp] > > > >At 19:34 05/04/07 -0500, Alex Zinin wrote: > > > Folks- > > > > > > Thanks everyone for your responses. > > > > > > It appears that there's an agreement on making the signalling-only model > >the > > > first step and then enhancing it with some routing (for some value of > >this > > > word) mechanisms. > > > > > > Before we go further, I'd like to make sure we agree on the bigger > >picture. > > > Correct as needed, pls. Briefly, in the general case: > > > > > > CE functionality. Needs to know: > > > > > > 1) what prefixes are behind other CEs, i.e. reachability informati on > > > Manually configured or smth like OSPF DC in the sig-only case. > > > NOTE: in the general case, those don't have to be IP. > > > >Yes. > > > >In the sig-only model, customers may wish to obtain prefixes behind other > >CEs, or may not. And mechanisms for customers to obtain reachability > >information behind other CEs are transparent to the provider. In one case, > >as you suggested, customers may wish to obtain reachability information > >behind other CEs via OSPF DC (between CEs). This operation is transparent > >to the provider, and this is out of scope of the L1VPN work. > > > >[dp] in fact this is pointing us to one of the fundamental issues that were > >never part of any GMPLS discussion in the overlay model context, the > >address > >resolution problem without which all mechanism from the CE are simple > >manual > > OK. There may be a need to further consider this issue. > > Note this functionality is not L1VPN specific, and that is why I mentioned > this is out of scope of the L1VPN work. > > > >[dp] the other question is of course ensure proper reachability information > >exchange among PE's such that incoming request can be routed toward the > >appropriate egress PE > > Agreed. This is an important functionality for the PE. > > > >In the typical deployment scenario, all VPN sites are managed by a single > >administrative entity (operator), and this entity knows prefixes behind > >other CEs. > > > >[dp] as usual, we would have two cases in the single carrier context, > >single > >AS vs multiple AS > > Yes. > > Note, even in multiple ASes, in the single carrier context, addresses may > be assigned by a single administrative entity. > > > > > 2) set of signaling params. the minimal set is the remote CE interface > > > and basic connection characteristics (mux type, BW). advanced cases > > > may include more TE information to influence the LSP trajectory. > > > Manually configured in the the sig-only case. > > > >Yes. > > > >Parameters in existing signaling protocols are good enough to handle all of > >those parameters (see GMPLS overlay I-D). > > > >Note manually configured or something else is out of the scope of the > >protocol (even in the sig+rtg model). > > > > > 3) how to signal the connection through the provider's cloud > > > >Yes. > > > >As in 2) above, parameters in existing signaling protocols are good enough > >to signal the connection through the provider's cloud. Provider's core > >nodes (PEs and Ps) and CEs all use GMPLS signaling, so no special > >procedures are required. > > > >[dp] see point 3 here below > > > > > 4) status of established connections > > > >Yes. This is definitely needed. > > > >Since L1VPN connections are just GMPLS LSPs, we can use existing GMPLS > >mechanisms. Namely, we can utilize control plane mechanisms (e.g., Refresh > >messages) to monitor the status of these connections. > > > >Note since we are focusing on GMPLS perspective, mechanisms such as data > >plane OAM mechanisms are out of the scope, > > > >[dp] ok - here there is a need to analyze details in terms of requirements > >concerning PathErr/ResvErr information exchange through the IF_ID RSVP_HOP > >object TLV and further refine the Notify message exchange > > I do not think there is anything special for L1VPNs. Could you please share > your ideas? > > > > > PE functionality. Needs to know: > > > > > > 1) (in the sig+rtg model) how to help CEs distribute reachability > > > information + (in the per-VPN peer mode) may also need to expose some > > > internal topology to the CEs > > > >Yes. This is the additional piece required for the sig+rtg model > > > >[dp] this is definitelly one of the major piece of work for this model > > > >Note to help CEs distribute reachability information, we already have > >several mechanisms (see GVPN I-D). In addition, the per-VPN peer model is > >conceptually similar to virtual routers although the implementation might > >be different. > > > > > 2) CE's signaling notation > > > >Yes. > > > >As I mentioned above (2) and 3) in CE functionality), CE's signaling > >notation is just normal GMPLS signaling notation. Inventing new signaling > >protocols is out of the scope for us. There is no reason to assume anything > >except the normal GMPLS signaling. > > > > > 3) how to process CE's signaling requests and translate them into > >internal > > > GMPLS LSP requests > > > >Yes. > > > >Note we already have several mechanisms, such as stitching/nesting. Here, > >we do not perform any "translation". We expect to use the same signaling > >protocols and formats. The only "mapping" required is from one IP address > >space to another. > > > >[dp] CE's signaling requests are expected to make use of GMPLS LSP request, > >the point here is to detail operations such as nesting, shuffling, etc. in > >the network, the latter (i.e. shuffling) implies protocol operations for > >objects SESSION, SENDER_TEMPLATE, FILTER_SPEC, etc. that carries end-to-end > >significant addresses ... example translation of sessions lists when Notify > >messages crosses PE's > > OK. First, we need to think whether we would want shuffling as a standard > mechanism. > > My personal opinion is that stitching/nesting already supports required > mechanisms for L1VPNs. Therefore, I am not sure whether we need another > approach (shuffling). > > > > > 4) how to tell CEs about connection status > > > >Yes. > > > >As I mentioned above (4) in CE functionality), we can use existing GMPLS > >mechanisms, such as Refresh, Notify and PathErr. > > > >In summary, I think all items are important functionalities to provide > >L1VPN services, and most of them are already covered by standard GMPLS > >(RFC3473) or proposed extensions (GVPN I-D, GMPLS overlay I-D). > > > >I do not think there are any major items missing here. > > > >[dp] concerning the signaling most of the details would indeed be related > >to the shuffling operation, concerning reachability information exchange > >both cases i.e between PE's only (sig model) and between CE's through PE's > >(sig+rtg model) requires further work > > Agreed. > > As I said above, need for shuffling is a subject for discussion. > > > >[dp] i would like also to know whether there is an assumption about > >homogeneity of the protocols (same protocol running between CE-PE and > >PE-..-PE) or can we assume that a different protocol can be running between > >CE-PE and between PE's ? > > If homegeneity means the same protocol, regardless of the same instance or > not, then my understanding is that we are looking at homegeneity. For example, > - We would not run GMPLS CR-LDP between CE and PE, and GMPLS RSVP-TE in the > provider network. > So, there is no need to perform protocol conversion (or parameter mapping). > > > Best regards, > > Tomonori > > > >Best regards, > > > >Tomonori, > > > > >-- > > >Alex > > > > > > > > > From rtg-dir-bounces@ietf.org Sun Apr 24 04:02:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25785 for ; Sun, 24 Apr 2005 04:02:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPcG4-00087p-Bo for rtg-dir-archive@ietf.org; Sun, 24 Apr 2005 04:14:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPc2Z-0005V4-MP; Sun, 24 Apr 2005 04:00:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPc2M-0005UC-FH; Sun, 24 Apr 2005 04:00:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25664; Sun, 24 Apr 2005 04:00:15 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPcEK-00086M-3l; Sun, 24 Apr 2005 04:12:40 -0400 Received: from [211.58.135.180] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DPc2G-0000y1-Nf; Sun, 24 Apr 2005 04:00:13 -0400 Received: from rOvX@localhost by WqAc.int (8.11.6/8.11.6); Sun, 24 Apr 2005 02:53:43 -0600 Message-ID: <9ZM8r5EH3vNoUmGwVw4tGLekc@doctrinaypraxis.org> From: "Diane Glazer" To: rtg-bfd@ietf.org Date: Sun, 24 Apr 2005 09:58:43 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NicoleSiegel@yogirajashram.org Content-Type: multipart/mixed; boundary="--wF0TYNzKlfcLigFiE" X-Spam-Score: 4.8 (++++) X-Scan-Signature: b148ead9c6581b10314b24a9438d3a5f Cc: rtg-dir@ietf.org, rtgwg@ietf.org Subject: 80 % Discount on All Win XP Titles X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Diane Glazer List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.8 (++++) X-Scan-Signature: 6217cd54077d488d29096a65a152105e uXI ----wF0TYNzKlfcLigFiE Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 8
    Opt-= in Email Special Offer     unsubscribe me
    SEARCH

    TOP 10 NEW TITLES

     ON SALE NOW!
      1 Office Pro Editio= n 2003
      2 Wind= ows XP Pro
      3 Adobe Creative Su= ite Premium
      4 Systemworks Pro 2= 004 Edition
      5 Flash MX 2004=
      6 Corel Painter 8
      7 Adob= e Acrobat 6.0
      8 Windows 2003 Serv= er
      9 Alias Maya 6.0 Wa= vefront
      10 Adobe Premiere
      = See more by this man= ufacturer
        Microsoft
        Apple Software
      = Customers also bough= t
        these other items= ..



    		Micr= osoft Office Professional Edition *2003*
    Microsoft
    Choose:
     
    List Price: $899.00
    Price: $69.99
    You Save: $830.01 (92%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requ= irements  |  Accessories  |&n= bsp; Other Versions

    Features:

    • Analyze and manage business inf= ormation using Access databases
    • Exchange data with other system= s using enhanced XML technology
    • Control information sharing rul= es with enhanced IRM technology
    • Easy-to-use wizards to create e= -mail newsletters and printed marketing materials
    • More than 20 preformatted busin= ess reports
    Sales Rank: #1
    Shipping: International/US or via instant downlo= ad
    Date Coupon Expires: May 30th, 2005
    Average Customer Review: 3D"5 Based on 1,768 reviews. Write a r= eview.
    Microsoft Wind= ows XP Professional or Longhorn Edition
    Microso= ft
    Choose:
     

    =

    List Price: $279.00
    Price: $49.99
    You Save: $229.01 (85%)



    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System = requirements  |  Accessories = |  Other Versions

    Features:

    • Designed for businesses of a= ll sizes
    • Manage digital pictures, mu= sic, video, DVDs, and more
    • More security with the abil= ity to encrypt files and folders
    • Built-in voice, video, and = instant messaging support
    • Integration with Windows se= rvers and management solutions

    Sales Rank: #2
    Shipping: International/US or via instant do= wnload
    Date Coupon Expires: May 30th, 2005
    Average Customer Review: 3D"5 Based on 868 reviews. Write a= review.

    Adobe Crea= tive Suite Premium
    Ado= be
    Choose:
     =

    List Price: $1149.00
    Price: $99.99
    You Save: $849.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    Sys= tem requirements  |  Accessories&n= bsp; |  Other Versions

    Features: <= /font>

    • An integrated design en= vironment featuring the industry's foremost design tools
    • In-depth tips, expert t= ricks, and comprehensive design resources
    • Intuitive file finding,= smooth workflow, and common interface and toolset
    • Single installer--contr= ol what you install and when you install it
    • Cross-media publishing-= -create content for both print and the Web

    Sales Rank: #3
    Shipping: International/US or via instan= t download
    Date Coupon Expires: May 30th, 2005
    Average Customer Review: 3D"5 Based on 498 reviews.     Wri= te a review.

    ----wF0TYNzKlfcLigFiE-- From rtg-dir-bounces@ietf.org Sun Apr 24 06:04:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03740 for ; Sun, 24 Apr 2005 06:04:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPeA9-0001Fh-Tj for rtg-dir-archive@ietf.org; Sun, 24 Apr 2005 06:16:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPdxC-0002cY-4S; Sun, 24 Apr 2005 06:03:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPdxA-0002cS-R6 for rtg-dir@megatron.ietf.org; Sun, 24 Apr 2005 06:03:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03681 for ; Sun, 24 Apr 2005 06:03:01 -0400 (EDT) Message-Id: <200504241003.GAA03681@ietf.org> Received: from ctv-217-147-43-40.init.lt ([217.147.43.40] helo=galeriemacabre.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DPe9A-0001EV-9S for rtg-dir@ietf.org; Sun, 24 Apr 2005 06:15:29 -0400 From: "Elea Mahan" To: "Adetokunbo Anaya" Date: Sun, 24 Apr 2005 06:02:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C545A2.426B7CD6" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.2 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: Re: VALlUM C-ALLIS VlAGRRA X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C545A2.426B7CD6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, slowly. fragments before their occupants could extricate themselves. The they do. Like Pilate, you wash your hands. He laughed savagely man to apply to me. Still, considering that ye willingly did me would be his opportunity. But Miss Bishop had retired for the Maracaybo isn't. So no doubt he'll lose it with fewer misgivings all that he had endured seemed as nothing. To Pitt, this separat She was nowhere to be seen among the shipping in that narrow, her mainsail unfurled to increase her steering way, and go about to view it as it now is, before I can determine my own place in i Lord Julian was sententious, as I gather that he often was. Lif Have a nice day. ------=_NextPart_000_0008_01C545A2.426B7CD6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, = Would you like to spend less on your MEDlCATl0NS?
    V gr
    ia a as low as $200.00=20 (120 piIIs)
    Ci li
    a s as low as $180.00=20 (80 piIIs)
    Va iu
    l m as low as $250.00=20 (220 piIIs)
    Le t
    vi ra as low as $300.00=20 (50 piIIs)
    X a
    an x as low as $270.00=20 (200 piIIs) and many = other
     
    Have a nice day.
    P.S. You will be pleasantly surprised with our pricees! =
    ------=_NextPart_000_0008_01C545A2.426B7CD6-- From rtg-dir-bounces@ietf.org Sun Apr 24 15:41:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16605 for ; Sun, 24 Apr 2005 15:41:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPnAc-00032u-Bh for rtg-dir-archive@ietf.org; Sun, 24 Apr 2005 15:53:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPmx8-0004Bp-Je; Sun, 24 Apr 2005 15:39:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPmx8-0004Bb-2m; Sun, 24 Apr 2005 15:39:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16442; Sun, 24 Apr 2005 15:39:36 -0400 (EDT) Received: from [212.118.77.61] (helo=77-061.tlmh.s5.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DPn9B-00030Y-Gs; Sun, 24 Apr 2005 15:52:08 -0400 Received: from 192.242.31.248 (EHLO mail.gkiwhost.biz) (219.164.224.20) (InterMail vG.8.53.28.03 207-2836-895-20040331) with ESMTP id <66161101151738.QLSU3309.gx6.fuse.net@optu.br> for ; Sun, 24 Apr 2005 15:37:59 -0500 Message-Id: <21GUJ6QTO18W718PM8@UOFT61.UTOLEDO.EDU> Date: Sun, 24 Apr 2005 13:37:59 -0700 From: "Newsletter of Rolex Watches" To: rtg-dir@ietf.org, policy-admin@ietf.org, imrg-admin@ietf.org, p2prg-web-archive@ietf.org, mmusic-admin@ietf.org X-Originating-Email: [dslivi@netscape.net] X-Spam-Score: 2.4 (++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: Re: Rolex Order Details - flash upstart map X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 :-:Hello:-: Original SWISS movement watches All reputed makes and models available -Rolex -Cartier -Frank Muller -Omega -zenith -Tag Heuer -Oyster Perpetual http://personalwatches.com/index.php?ref=news The Watches, clocks and alarm clocks manufactured in Switzerland bear the designation -Swiss made- (or its abbreviation "Swiss") as well as the logo of the producer or distributor. This label enjoys a solid reputation throughout the world. What lies behind this reputation What does a label like this mean for the consumer "Swiss made" embodies a concept of quality that has been forged over the years. It includes the technical quality of watches (accuracy, reliability, water-resistance and shock-resistance), as well as their aesthetic quality (elegance and originality of design). It covers both traditional manufacturing and new technologies (micro-electronics). The Swiss are not the only watchmakers to manufacture high-quality timepieces and are consequently faced with strong competition. However, thanks to their unique infrastructure and to their know-how and spirit of innovation, they have succeeded in maintaining their leading position. The intrinsic value of the "Swiss made" label, therefore, is the result of considerable efforts on the part of watchmaking companies, who are ultimately responsible for maintaining its reputation. Your Free shipping & guarantee http://personalwatches.com/index.php?ref=news We would like to take this opportunity to offer you our fine selection of Italian crafted Rolex Timepieces. sincerely, Tessa Howe Manager New Italian Rolex Timepieces Inc Not interested- http://merchantgalaxy.com/gone.php From rtg-dir-bounces@ietf.org Mon Apr 25 16:56:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28543 for ; Mon, 25 Apr 2005 16:56:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQApS-0002Sc-2W for rtg-dir-archive@ietf.org; Mon, 25 Apr 2005 17:09:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQAcQ-0001dN-DB; Mon, 25 Apr 2005 16:55:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQAcL-0001cm-8z for rtg-dir@megatron.ietf.org; Mon, 25 Apr 2005 16:55:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28360 for ; Mon, 25 Apr 2005 16:55:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQAoZ-0002Oj-Sa for rtg-dir@ietf.org; Mon, 25 Apr 2005 17:08:29 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DQAcA-0005CD-5k; Mon, 25 Apr 2005 20:55:34 +0000 Date: Mon, 25 Apr 2005 13:55:31 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <3610676628.20050425135531@psg.com> To: "Adrian Farrel" In-Reply-To: <00a401c54845$754979a0$1c849ed9@Puppy> References: <5.1.1.9.2.20050420152913.067fc360@imf.m.ecl.ntt.co.jp> <00a401c54845$754979a0$1c849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Dimitri.Papadimitriou@alcatel.be, takeda.tomonori@lab.ntt.co.jp, Igor Bryskin , rtg-dir@ietf.org Subject: Re: L1VPN evaluation status? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Content-Transfer-Encoding: 7bit Adrian, et al- Sorry for the delay. I took some time off last week. I'll catch up on this within a couple of days and get back to you. -- Alex http://www.psg.com/~zinin Saturday, April 23, 2005, 1:05:14 PM, Adrian Farrel wrote: > Hi Alex, > There has been some reasonably constructive discussion on this topic which > to me indicates: > - Not all of the decisions have been taken yet > Probably a good thing :-) > - There is value in having an open (wider) debate in some > context perhaps on the L1VPN mailing list. > If you don't think this is inappropriate, I would like > someone (Dimitri? Tomonori? me?) to move some of the > discussion to there. > - There are no *huge* protocol holes that have been identified. > (I didn't hear anyone say, "And therefore we need a new routing > protocol.") > Soooo... > How is your assessment coming along? Which way are you inclined to jump? > And what more can we do to help with your evaluation? > Cheers, > Adrian > ----- Original Message ----- > From: "Tomonori TAKEDA" > To: > Cc: "Alex Zinin" ; ; > ; "Kireeti Kompella" ; "Igor > Bryskin" ; "Adrian Farrel" ; > > Sent: Wednesday, April 20, 2005 10:01 AM > Subject: Re: L1VPN service models >> Hi Dimitri, >> >> Thank you very much for your comments, and sorry for late response. >> >> Please see in-line. >> >> At 20:23 05/04/14 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >> >> >hi tomonori, all >> > >> >see in-line - starting with [dp] >> > >> >At 19:34 05/04/07 -0500, Alex Zinin wrote: >> > > Folks- >> > > >> > > Thanks everyone for your responses. >> > > >> > > It appears that there's an agreement on making the signalling-only > model >> >the >> > > first step and then enhancing it with some routing (for some value > of >> >this >> > > word) mechanisms. >> > > >> > > Before we go further, I'd like to make sure we agree on the bigger >> >picture. >> > > Correct as needed, pls. Briefly, in the general case: >> > > >> > > CE functionality. Needs to know: >> > > >> > > 1) what prefixes are behind other CEs, i.e. reachability informati > on >> > > Manually configured or smth like OSPF DC in the sig-only case. >> > > NOTE: in the general case, those don't have to be IP. >> > >> >Yes. >> > >> >In the sig-only model, customers may wish to obtain prefixes behind > other >> >CEs, or may not. And mechanisms for customers to obtain reachability >> >information behind other CEs are transparent to the provider. In one > case, >> >as you suggested, customers may wish to obtain reachability information >> >behind other CEs via OSPF DC (between CEs). This operation is > transparent >> >to the provider, and this is out of scope of the L1VPN work. >> > >> >[dp] in fact this is pointing us to one of the fundamental issues that > were >> >never part of any GMPLS discussion in the overlay model context, the >> >address >> >resolution problem without which all mechanism from the CE are simple >> >manual >> >> OK. There may be a need to further consider this issue. >> >> Note this functionality is not L1VPN specific, and that is why I > mentioned >> this is out of scope of the L1VPN work. >> >> >> >[dp] the other question is of course ensure proper reachability > information >> >exchange among PE's such that incoming request can be routed toward the >> >appropriate egress PE >> >> Agreed. This is an important functionality for the PE. >> >> >> >In the typical deployment scenario, all VPN sites are managed by a > single >> >administrative entity (operator), and this entity knows prefixes behind >> >other CEs. >> > >> >[dp] as usual, we would have two cases in the single carrier context, >> >single >> >AS vs multiple AS >> >> Yes. >> >> Note, even in multiple ASes, in the single carrier context, addresses > may >> be assigned by a single administrative entity. >> >> >> > > 2) set of signaling params. the minimal set is the remote CE > interface >> > > and basic connection characteristics (mux type, BW). advanced > cases >> > > may include more TE information to influence the LSP > trajectory. >> > > Manually configured in the the sig-only case. >> > >> >Yes. >> > >> >Parameters in existing signaling protocols are good enough to handle > all of >> >those parameters (see GMPLS overlay I-D). >> > >> >Note manually configured or something else is out of the scope of the >> >protocol (even in the sig+rtg model). >> > >> > > 3) how to signal the connection through the provider's cloud >> > >> >Yes. >> > >> >As in 2) above, parameters in existing signaling protocols are good > enough >> >to signal the connection through the provider's cloud. Provider's core >> >nodes (PEs and Ps) and CEs all use GMPLS signaling, so no special >> >procedures are required. >> > >> >[dp] see point 3 here below >> > >> > > 4) status of established connections >> > >> >Yes. This is definitely needed. >> > >> >Since L1VPN connections are just GMPLS LSPs, we can use existing GMPLS >> >mechanisms. Namely, we can utilize control plane mechanisms (e.g., > Refresh >> >messages) to monitor the status of these connections. >> > >> >Note since we are focusing on GMPLS perspective, mechanisms such as > data >> >plane OAM mechanisms are out of the scope, >> > >> >[dp] ok - here there is a need to analyze details in terms of > requirements >> >concerning PathErr/ResvErr information exchange through the IF_ID > RSVP_HOP >> >object TLV and further refine the Notify message exchange >> >> I do not think there is anything special for L1VPNs. Could you please > share >> your ideas? >> >> >> > > PE functionality. Needs to know: >> > > >> > > 1) (in the sig+rtg model) how to help CEs distribute reachability >> > > information + (in the per-VPN peer mode) may also need to expose > some >> > > internal topology to the CEs >> > >> >Yes. This is the additional piece required for the sig+rtg model >> > >> >[dp] this is definitelly one of the major piece of work for this model >> > >> >Note to help CEs distribute reachability information, we already have >> >several mechanisms (see GVPN I-D). In addition, the per-VPN peer model > is >> >conceptually similar to virtual routers although the implementation > might >> >be different. >> > >> > > 2) CE's signaling notation >> > >> >Yes. >> > >> >As I mentioned above (2) and 3) in CE functionality), CE's signaling >> >notation is just normal GMPLS signaling notation. Inventing new > signaling >> >protocols is out of the scope for us. There is no reason to assume > anything >> >except the normal GMPLS signaling. >> > >> > > 3) how to process CE's signaling requests and translate them into >> >internal >> > > GMPLS LSP requests >> > >> >Yes. >> > >> >Note we already have several mechanisms, such as stitching/nesting. > Here, >> >we do not perform any "translation". We expect to use the same > signaling >> >protocols and formats. The only "mapping" required is from one IP > address >> >space to another. >> > >> >[dp] CE's signaling requests are expected to make use of GMPLS LSP > request, >> >the point here is to detail operations such as nesting, shuffling, etc. > in >> >the network, the latter (i.e. shuffling) implies protocol operations > for >> >objects SESSION, SENDER_TEMPLATE, FILTER_SPEC, etc. that carries > end-to-end >> >significant addresses ... example translation of sessions lists when > Notify >> >messages crosses PE's >> >> OK. First, we need to think whether we would want shuffling as a > standard >> mechanism. >> >> My personal opinion is that stitching/nesting already supports required >> mechanisms for L1VPNs. Therefore, I am not sure whether we need another >> approach (shuffling). >> >> >> > > 4) how to tell CEs about connection status >> > >> >Yes. >> > >> >As I mentioned above (4) in CE functionality), we can use existing > GMPLS >> >mechanisms, such as Refresh, Notify and PathErr. >> > >> >In summary, I think all items are important functionalities to provide >> >L1VPN services, and most of them are already covered by standard GMPLS >> >(RFC3473) or proposed extensions (GVPN I-D, GMPLS overlay I-D). >> > >> >I do not think there are any major items missing here. >> > >> >[dp] concerning the signaling most of the details would indeed be > related >> >to the shuffling operation, concerning reachability information > exchange >> >both cases i.e between PE's only (sig model) and between CE's through > PE's >> >(sig+rtg model) requires further work >> >> Agreed. >> >> As I said above, need for shuffling is a subject for discussion. >> >> >> >[dp] i would like also to know whether there is an assumption about >> >homogeneity of the protocols (same protocol running between CE-PE and >> >PE-..-PE) or can we assume that a different protocol can be running > between >> >CE-PE and between PE's ? >> >> If homegeneity means the same protocol, regardless of the same instance > or >> not, then my understanding is that we are looking at homegeneity. For > example, >> - We would not run GMPLS CR-LDP between CE and PE, and GMPLS RSVP-TE in > the >> provider network. >> So, there is no need to perform protocol conversion (or parameter > mapping). >> >> >> Best regards, >> >> Tomonori >> >> >> >Best regards, >> > >> >Tomonori, >> > >> > >-- >> > >Alex >> > > >> > > >> >> >> From rtg-dir-bounces@ietf.org Wed Apr 27 00:08:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22448 for ; Wed, 27 Apr 2005 00:08:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQe3W-0000Ln-F1 for rtg-dir-archive@ietf.org; Wed, 27 Apr 2005 00:21:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQdph-0007ml-7f; Wed, 27 Apr 2005 00:07:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQdpg-0007mU-AE; Wed, 27 Apr 2005 00:07:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22290; Wed, 27 Apr 2005 00:07:25 -0400 (EDT) Received: from [222.243.9.99] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DQe2E-0000JA-DF; Wed, 27 Apr 2005 00:20:28 -0400 Received: from indifferent-jcoppens.com (EHLO episodic.jcoppens.com) by covert.jcoppens.com with SMTP; Wed, 27 Apr 2005 06:03:14 +0100 Date: Wed, 27 Apr 2005 04:07:14 -0100 From: "Elton Hoyt" To: rtg-bfd-admin@ietf.org Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [704], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 3.3 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: saad@ietf.org, rtg-dir@ietf.org, s@ietf.org, rtgwg-web-archive@ietf.org, rtgwg-admin@ietf.org, rtgwg@ietf.org, s.o.f.t.w.a.r.e@ietf.org, rv@ietf.org Subject: Need a low mortage rate? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.3 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.cr3at3.com/sign.asp Best Regards, Kurtis Holmes to be remov(ed: http://www.cr3at3.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Wed Apr 27 08:47:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06322 for ; Wed, 27 Apr 2005 08:47:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQm9V-0002JT-54 for rtg-dir-archive@ietf.org; Wed, 27 Apr 2005 09:00:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQltO-0006vx-1K; Wed, 27 Apr 2005 08:43:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQltM-0006vp-56 for rtg-dir@megatron.ietf.org; Wed, 27 Apr 2005 08:43:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05941 for ; Wed, 27 Apr 2005 08:43:46 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQm5y-0002DK-Tx for rtg-dir@ietf.org; Wed, 27 Apr 2005 08:56:53 -0400 Received: from cc312330-b.groni1.gr.home.nl ([82.73.80.3]) by mx2.foretec.com with smtp (Exim 4.24) id 1DQltJ-0005No-PZ for rtg-dir@ietf.org; Wed, 27 Apr 2005 08:43:45 -0400 Message-ID: From: "Vanessa J. Smith" To: rtg-dir@ietf.org Date: Wed, 27 Apr 2005 12:37:15 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_8F9B4843.F3C54A0A" 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-Score: 1.0 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: Adobe Creative Suite (5 CD) - very low price X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. ------=_NextPart_000_0000_8F9B4843.F3C54A0A Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_F90F11BC.F0790680" ------=_NextPart_001_0001_F90F11BC.F0790680 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get access to all the software you ever imagined for wholesale prices! We sell software 2-6 times cheaper than retail price. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... For full list of products go: http://www.softdisks.biz Best regards, Vanessa Smith _____________________________________________________ To change your mail details, go here: http://www.softdisks.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_F90F11BC.F0790680 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
    Get access to all the software you ever imagined for bottom prices!
    We sell software 2-6 times cheaper than retail price.

    A few examples:
    $79.95 Windows XP Professional (Including: Service Pack 2)
    $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
    $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
    $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
    $79.95 Adobe Acrobat 6.0 Professional
    $69.95 MS Project 2003 Professional

    Special Offers:
    $89.95 Windows XP Professional + Office XP Professional
    $149.95 Adobe Creative Suite Premium (5 CD)
    $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

    All main products from Microsoft, Adobe, Macromedia, Corel, etc.
    And many more... To visit us go:

    http://www.softdisks.biz

    Sincerely,
    Vanessa J. Smith


    _____________________________________________________
    To stop further mailings, go: http://www.softdisks.biz/uns.htm
    _____________________________________________________

    ------=_NextPart_001_0001_F90F11BC.F0790680-- ------=_NextPart_000_0000_8F9B4843.F3C54A0A-- From rtg-dir-bounces@ietf.org Mon May 2 12:27:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01453 for ; Mon, 2 May 2005 12:27:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSdze-0007HS-HN for rtg-dir-archive@ietf.org; Mon, 02 May 2005 12:42:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSdlt-000330-Sz; Mon, 02 May 2005 12:27:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSdlr-00032i-Jb; Mon, 02 May 2005 12:27:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01414; Mon, 2 May 2005 12:27:45 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSdzW-0007HF-Qq; Mon, 02 May 2005 12:41:58 -0400 Received: from 82.131.189.19.pool.invitel.hu ([82.131.189.19]) by mx2.foretec.com with smtp (Exim 4.24) id 1DSdla-0003iy-Sp; Mon, 02 May 2005 12:27:34 -0400 Delivered-To: with@abominable.dreamhost.com Received: from stopover.dreamhost.com by princeton.dreamhost.com (Pingofix) with ESMTP id 0CC1A17D9B for ; Mon, 02 May 2005 23:20:25 +0600 Message-ID: Date: Mon, 02 May 2005 14:23:25 -0300 From: "Anderson Comer" To: X-Mailer: Mailman v2.0.4 X-SpamTest-Info: Profile: Formal (167/041151) X-SpamTest-Info: Profile: Detect Hard No RBL (4/030598) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Instant low rates X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.h0us1ng.net/sign.asp Best Regards, Tracy Bullock to be remov(ed: http://www.h0us1ng.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Tue May 3 06:25:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27590 for ; Tue, 3 May 2005 06:25:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSuoa-0004Xr-D7 for rtg-dir-archive@ietf.org; Tue, 03 May 2005 06:39:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSuYv-0000pT-UH; Tue, 03 May 2005 06:23:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSuYu-0000pO-Or for rtg-dir@megatron.ietf.org; Tue, 03 May 2005 06:23:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27469 for ; Tue, 3 May 2005 06:23:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSumm-0004WD-9p for rtg-dir@ietf.org; Tue, 03 May 2005 06:37:52 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DSuYs-00093x-0t; Tue, 03 May 2005 10:23:30 +0000 Date: Tue, 3 May 2005 03:23:25 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1448660476.20050503032325@psg.com> To: "Adrian Farrel" In-Reply-To: <00a401c54845$754979a0$1c849ed9@Puppy> References: <5.1.1.9.2.20050420152913.067fc360@imf.m.ecl.ntt.co.jp> <00a401c54845$754979a0$1c849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Dimitri.Papadimitriou@alcatel.be, takeda.tomonori@lab.ntt.co.jp, Igor Bryskin , rtg-dir@ietf.org Subject: Re: L1VPN evaluation status? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Content-Transfer-Encoding: 7bit Adrian, et al- I think we can go ahead with this. Agree with Adrian--let's talk the technical part of the discussion to the list--Dimitri, Tomonori, please follow up on this. Bill and I would like this to be a separate WG, so we need to start working on the charter, which implies that we need two proposed WG chairs. Please send your recommendations unicast to Bill and me. -- Alex http://www.psg.com/~zinin Saturday, April 23, 2005, 1:05:14 PM, Adrian Farrel wrote: > Hi Alex, > There has been some reasonably constructive discussion on this topic which > to me indicates: > - Not all of the decisions have been taken yet > Probably a good thing :-) > - There is value in having an open (wider) debate in some > context perhaps on the L1VPN mailing list. > If you don't think this is inappropriate, I would like > someone (Dimitri? Tomonori? me?) to move some of the > discussion to there. > - There are no *huge* protocol holes that have been identified. > (I didn't hear anyone say, "And therefore we need a new routing > protocol.") > Soooo... > How is your assessment coming along? Which way are you inclined to jump? > And what more can we do to help with your evaluation? > Cheers, > Adrian > ----- Original Message ----- > From: "Tomonori TAKEDA" > To: > Cc: "Alex Zinin" ; ; > ; "Kireeti Kompella" ; "Igor > Bryskin" ; "Adrian Farrel" ; > > Sent: Wednesday, April 20, 2005 10:01 AM > Subject: Re: L1VPN service models >> Hi Dimitri, >> >> Thank you very much for your comments, and sorry for late response. >> >> Please see in-line. >> >> At 20:23 05/04/14 +0200, Dimitri.Papadimitriou@alcatel.be wrote: >> >> >hi tomonori, all >> > >> >see in-line - starting with [dp] >> > >> >At 19:34 05/04/07 -0500, Alex Zinin wrote: >> > > Folks- >> > > >> > > Thanks everyone for your responses. >> > > >> > > It appears that there's an agreement on making the signalling-only > model >> >the >> > > first step and then enhancing it with some routing (for some value > of >> >this >> > > word) mechanisms. >> > > >> > > Before we go further, I'd like to make sure we agree on the bigger >> >picture. >> > > Correct as needed, pls. Briefly, in the general case: >> > > >> > > CE functionality. Needs to know: >> > > >> > > 1) what prefixes are behind other CEs, i.e. reachability informati > on >> > > Manually configured or smth like OSPF DC in the sig-only case. >> > > NOTE: in the general case, those don't have to be IP. >> > >> >Yes. >> > >> >In the sig-only model, customers may wish to obtain prefixes behind > other >> >CEs, or may not. And mechanisms for customers to obtain reachability >> >information behind other CEs are transparent to the provider. In one > case, >> >as you suggested, customers may wish to obtain reachability information >> >behind other CEs via OSPF DC (between CEs). This operation is > transparent >> >to the provider, and this is out of scope of the L1VPN work. >> > >> >[dp] in fact this is pointing us to one of the fundamental issues that > were >> >never part of any GMPLS discussion in the overlay model context, the >> >address >> >resolution problem without which all mechanism from the CE are simple >> >manual >> >> OK. There may be a need to further consider this issue. >> >> Note this functionality is not L1VPN specific, and that is why I > mentioned >> this is out of scope of the L1VPN work. >> >> >> >[dp] the other question is of course ensure proper reachability > information >> >exchange among PE's such that incoming request can be routed toward the >> >appropriate egress PE >> >> Agreed. This is an important functionality for the PE. >> >> >> >In the typical deployment scenario, all VPN sites are managed by a > single >> >administrative entity (operator), and this entity knows prefixes behind >> >other CEs. >> > >> >[dp] as usual, we would have two cases in the single carrier context, >> >single >> >AS vs multiple AS >> >> Yes. >> >> Note, even in multiple ASes, in the single carrier context, addresses > may >> be assigned by a single administrative entity. >> >> >> > > 2) set of signaling params. the minimal set is the remote CE > interface >> > > and basic connection characteristics (mux type, BW). advanced > cases >> > > may include more TE information to influence the LSP > trajectory. >> > > Manually configured in the the sig-only case. >> > >> >Yes. >> > >> >Parameters in existing signaling protocols are good enough to handle > all of >> >those parameters (see GMPLS overlay I-D). >> > >> >Note manually configured or something else is out of the scope of the >> >protocol (even in the sig+rtg model). >> > >> > > 3) how to signal the connection through the provider's cloud >> > >> >Yes. >> > >> >As in 2) above, parameters in existing signaling protocols are good > enough >> >to signal the connection through the provider's cloud. Provider's core >> >nodes (PEs and Ps) and CEs all use GMPLS signaling, so no special >> >procedures are required. >> > >> >[dp] see point 3 here below >> > >> > > 4) status of established connections >> > >> >Yes. This is definitely needed. >> > >> >Since L1VPN connections are just GMPLS LSPs, we can use existing GMPLS >> >mechanisms. Namely, we can utilize control plane mechanisms (e.g., > Refresh >> >messages) to monitor the status of these connections. >> > >> >Note since we are focusing on GMPLS perspective, mechanisms such as > data >> >plane OAM mechanisms are out of the scope, >> > >> >[dp] ok - here there is a need to analyze details in terms of > requirements >> >concerning PathErr/ResvErr information exchange through the IF_ID > RSVP_HOP >> >object TLV and further refine the Notify message exchange >> >> I do not think there is anything special for L1VPNs. Could you please > share >> your ideas? >> >> >> > > PE functionality. Needs to know: >> > > >> > > 1) (in the sig+rtg model) how to help CEs distribute reachability >> > > information + (in the per-VPN peer mode) may also need to expose > some >> > > internal topology to the CEs >> > >> >Yes. This is the additional piece required for the sig+rtg model >> > >> >[dp] this is definitelly one of the major piece of work for this model >> > >> >Note to help CEs distribute reachability information, we already have >> >several mechanisms (see GVPN I-D). In addition, the per-VPN peer model > is >> >conceptually similar to virtual routers although the implementation > might >> >be different. >> > >> > > 2) CE's signaling notation >> > >> >Yes. >> > >> >As I mentioned above (2) and 3) in CE functionality), CE's signaling >> >notation is just normal GMPLS signaling notation. Inventing new > signaling >> >protocols is out of the scope for us. There is no reason to assume > anything >> >except the normal GMPLS signaling. >> > >> > > 3) how to process CE's signaling requests and translate them into >> >internal >> > > GMPLS LSP requests >> > >> >Yes. >> > >> >Note we already have several mechanisms, such as stitching/nesting. > Here, >> >we do not perform any "translation". We expect to use the same > signaling >> >protocols and formats. The only "mapping" required is from one IP > address >> >space to another. >> > >> >[dp] CE's signaling requests are expected to make use of GMPLS LSP > request, >> >the point here is to detail operations such as nesting, shuffling, etc. > in >> >the network, the latter (i.e. shuffling) implies protocol operations > for >> >objects SESSION, SENDER_TEMPLATE, FILTER_SPEC, etc. that carries > end-to-end >> >significant addresses ... example translation of sessions lists when > Notify >> >messages crosses PE's >> >> OK. First, we need to think whether we would want shuffling as a > standard >> mechanism. >> >> My personal opinion is that stitching/nesting already supports required >> mechanisms for L1VPNs. Therefore, I am not sure whether we need another >> approach (shuffling). >> >> >> > > 4) how to tell CEs about connection status >> > >> >Yes. >> > >> >As I mentioned above (4) in CE functionality), we can use existing > GMPLS >> >mechanisms, such as Refresh, Notify and PathErr. >> > >> >In summary, I think all items are important functionalities to provide >> >L1VPN services, and most of them are already covered by standard GMPLS >> >(RFC3473) or proposed extensions (GVPN I-D, GMPLS overlay I-D). >> > >> >I do not think there are any major items missing here. >> > >> >[dp] concerning the signaling most of the details would indeed be > related >> >to the shuffling operation, concerning reachability information > exchange >> >both cases i.e between PE's only (sig model) and between CE's through > PE's >> >(sig+rtg model) requires further work >> >> Agreed. >> >> As I said above, need for shuffling is a subject for discussion. >> >> >> >[dp] i would like also to know whether there is an assumption about >> >homogeneity of the protocols (same protocol running between CE-PE and >> >PE-..-PE) or can we assume that a different protocol can be running > between >> >CE-PE and between PE's ? >> >> If homegeneity means the same protocol, regardless of the same instance > or >> not, then my understanding is that we are looking at homegeneity. For > example, >> - We would not run GMPLS CR-LDP between CE and PE, and GMPLS RSVP-TE in > the >> provider network. >> So, there is no need to perform protocol conversion (or parameter > mapping). >> >> >> Best regards, >> >> Tomonori >> >> >> >Best regards, >> > >> >Tomonori, >> > >> > >-- >> > >Alex >> > > >> > > >> >> >> From rtg-dir-bounces@ietf.org Tue May 3 14:27:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18540 for ; Tue, 3 May 2005 14:27:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT2Ld-0000nP-UN for rtg-dir-archive@ietf.org; Tue, 03 May 2005 14:42:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT26R-0004kX-34; Tue, 03 May 2005 14:26:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT26O-0004kS-Si for rtg-dir@megatron.ietf.org; Tue, 03 May 2005 14:26:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18380 for ; Tue, 3 May 2005 14:26:35 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT2KI-0000m0-IH for rtg-dir@ietf.org; Tue, 03 May 2005 14:41:01 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j43IQR22028047; Tue, 3 May 2005 20:26:27 +0200 To: Alex Zinin MIME-Version: 1.0 Date: Tue, 3 May 2005 20:26:25 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/03/2005 20:26:29 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: rtg-dir@ietf.org, Dimitri.Papadimitriou@alcatel.be, Kireeti Kompella , Adrian Farrel , Igor Bryskin , takeda.tomonori@lab.ntt.co.jp Subject: Re: L1VPN evaluation status? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 alex - ok no problem concerning me in order to streamline the technical discussion, here below a sum'up and pointers to the discussion items to be provided on the list indicated with (*) CE functionality ---------------- 1) reachability information (what prefixes are behind other CEs) Note: in the general case, those don't have to be IP Signaling model: - Manually configuration and/or transparent exchange (*) Need for an address resolution mechanism (as this mechanism is not L1VPN specific further discussion required as whether within or outside the scope) In any case need to ensure proper reachability information exchange among PE's such that incoming request can be routed toward the appropriate egress PE In a first phase, all VPN sites are managed by a single administrative entity (operator), and this entity knows prefixes behind other CEs. In the single carrier context, two cases are possible single vs multiple AS 2) Set of signaling parameters: the minimal set is the remote CE interface and basic connection characteristics (LSP Encoding Type, BW, etc). The current set of parameters in existing GMPLS RSVP-TE signaling documents (and related) are good enough to handle this case. Note: advanced traffic parameters may include more TE information to influence the LSP trajectory. Manually configured in the the sig-only and sig+rtg case. 3) how to signal the connection through the provider's cloud parameters in existing GMPLS RSVP-TE signaling documents (and related) are good enough to signal the connection through the provider's cloud. As Provider's core nodes (PEs and Ps) and CEs all use GMPLS signaling, so no special procedures are required. 4) Status of established connections L1VPN connections being GMPLS LSPs, re-use of existing GMPLS control mechanisms can be used to monitor the status of these connections. (*) Provide further details for PathErr/ResvErr, Notify message exchange through (CE-PE boundary) e.g. IF_ID ERROR_SPEC object TLV; the Notify Request object processing and routing of the Notify message Note: mechanisms such as data plane OAM mechanisms are out of the scope PE functionality ---------------- 1) (in the sig+rtg model) how to help CEs distribute reachability information + (in the per-VPN peer mode) may also need to expose some internal topology to the CEs Several mechanisms for CEs to distribute reachability information are detailed in the GVPN I-D. (*) The per-VPN peer model is conceptually similar to virtual routers; however as the implementation may be different additional thoughts could be required 2) CE's signaling notation As above (2) and 3) for CE functionality 3) How to process CE's signaling requests and translate them into internal GMPLS LSP requests. Several mechanisms are possible i.e. stitching and shuffling (application of the contiguous LSP signaling to the L1VPN context is introduced in Section 2.2 of the GVPN I-D). The latter requires address translation at PEs. (*) Further details required to support CE functionality (point 4) Nesting of the incoming CE-to-CE LSP into a network LSP also requires further details. (*) Further discussion expected concerning the set of signaling mechanisms to be progressed for L1VPN. 4) how to tell CEs about connection status Same as (4) for CE functionality Note: concerning reachability information exchange in the (sig+rtg model) further discussion about homogeneity of the protocols i.e. same protocol b/w CE-PE and PE-..-PE or different protocol between CE-PE and between PE's (*) From rtg-dir-bounces@ietf.org Tue May 3 21:37:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00903 for ; Tue, 3 May 2005 21:37:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT93k-0005hU-2Z for rtg-dir-archive@ietf.org; Tue, 03 May 2005 21:52:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT8pL-0006kk-6j; Tue, 03 May 2005 21:37:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT8pK-0006io-C9 for rtg-dir@megatron.ietf.org; Tue, 03 May 2005 21:37:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00862 for ; Tue, 3 May 2005 21:37:24 -0400 (EDT) Received: from [69.20.61.144] (helo=www.stylusinc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT93J-0005g5-AF for rtg-dir@ietf.org; Tue, 03 May 2005 21:51:54 -0400 Received: (qmail 25149 invoked by uid 48); 3 May 2005 23:13:26 -0000 Date: 3 May 2005 23:13:26 -0000 Message-ID: <20050503231326.25148.qmail@www.stylusinc.com> To: rtg-dir@ietf.org From: LaSalle Bank Content-Type: text/html X-Spam-Score: 4.6 (++++) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Subject: LaSalle Bank - Urgent Account Verification! X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Lasalle Bank

     

    Dear Customer,

    It has come to our attention that your account information needs to be updated as part of our continuing commitment to protect your account and to keep your information private.

    If you could please take 5-10 minutes out of your online experience and update your personal records you will not run in any future problems with the online service.

    To get started please click the link below:
    https://www.lasallebank.com/index.html?shortname=lasalle&longname=LaSalle+Online

    If your account information is not updated within 48 hours then your ability to use your online account will become restricted.

    Thank you for your promt attention to this matter. Please understand that this is a security measure meant to help protect your privacy and your account.

    If you have any questions, feel free to contact our customer support department any time at:
    customer-support@lasallebank.com


    We apologize for any inconvenience this may cause, and appreciate your assistance in helping us maintain the integrity of the entire LaSalle Banking system.


    Sincerely,
    The Lasalle Bank Team

    © Copyright 2005, Lasalle Bank Corporation. All Rights Reserved.

     
     
    From rtg-dir-bounces@ietf.org Wed May 4 00:19:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12706 for ; Wed, 4 May 2005 00:19:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTBaC-0000tt-1U for rtg-dir-archive@ietf.org; Wed, 04 May 2005 00:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTBLb-0007Lv-BS; Wed, 04 May 2005 00:18:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTBLY-0007Lq-KK for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 00:18:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12692 for ; Wed, 4 May 2005 00:18:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTBZZ-0000tM-SR for rtg-dir@ietf.org; Wed, 04 May 2005 00:33:22 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTBLR-000MeY-S1; Wed, 04 May 2005 04:18:45 +0000 Date: Tue, 3 May 2005 21:18:42 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <314876349.20050503211842@psg.com> To: "Adrian Farrel" , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, "Kireeti Kompella" , "Igor Bryskin" , In-Reply-To: <00a401c54845$754979a0$1c849ed9@Puppy> References: <5.1.1.9.2.20050420152913.067fc360@imf.m.ecl.ntt.co.jp> <00a401c54845$754979a0$1c849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Subject: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Folks- Before we bring it to the l1vpn mailing list, I'd like to run this draft by you guys for comments. -- Alex Layer 1 Virtual Private Networks (l1vpn) Last Modified: 2005-01-25 Chair(s): TBD TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Technical Advisor(s): Mailing Lists: General Discussion: l1vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html Description of Working Group: L1VPN Working Group's task is to specify mechanisms necessary for providing a VPN service over a GMPLS transport network. The following two service models will be addressed: 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. The GMPLS network is not involved in distribution of user's routing information. 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits utilization of the provider's control plane for distribution of user's routing information (e.g. similar to the MPLS/BGP model). The WG will work on the following items: 1. Specification of the L1VPN user-to-network interface (UNI) basic mode, including both CE and PE functionality. 2. Specification of the L1VPN node-to-node interface (NNI) basic mode. 3. MIB modules and/or extensions required for UNI and NNI basic mode. 4. Specification of L1VPN UNI enhanced mode. 5. Specification of L1VPN NNI enhanced mode. 6. MIB modules and/or extensions required for UNI and NNI enhanced mode. Protocol extensions required for L1VPN will be done in cooperation with CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. Milestones: Sep 05 Submit first Internet Drafts of UNI and NNI basic mode specifications Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic mode Jun 06 Submit UNI and NNI basic mode specifications to IESG for publication as Proposed Standard Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode specifications Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for publication as Proposed Standard Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for publication as Proposed Standard Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for publication as Proposed Standard From rtg-dir-bounces@ietf.org Wed May 4 08:10:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26599 for ; Wed, 4 May 2005 08:10:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTIwX-0003q4-QI for rtg-dir-archive@ietf.org; Wed, 04 May 2005 08:25:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTIhz-0008Pp-OR; Wed, 04 May 2005 08:10:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTIhx-0008Pa-Lq for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 08:10:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26589 for ; Wed, 4 May 2005 08:10:28 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTIw2-0003pB-Jn for rtg-dir@ietf.org; Wed, 04 May 2005 08:25:03 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j44CAP22001519; Wed, 4 May 2005 14:10:25 +0200 To: Alex Zinin MIME-Version: 1.0 Date: Wed, 4 May 2005 14:10:25 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/04/2005 14:10:26 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Igor Bryskin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 alex, all, see in-line for comments > Layer 1 Virtual Private Networks (l1vpn) > > Last Modified: 2005-01-25 < Last Modified: 2005-01-25 > Last Modified: 2005-05-04 > Chair(s): > TBD > TBD > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Technical Advisor(s): > > Mailing Lists: > General Discussion: l1vpn@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn > Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html > > Description of Working Group: > > L1VPN Working Group's task is to specify mechanisms necessary for > providing a VPN service over a GMPLS transport network. > > The following two service models will be addressed: > > 1. Basic mode: the CE-PE interface's functional repertoire is limited to > path setup signalling only. The GMPLS network is not involved in > distribution of user's routing information. in this base model, VPN membership information exchange between PE's (what is referred to as CE reachability) is to be provided (the CE-PE link properties are to be considered as improvement); the difference wrt to the enhanced mode described here below (point 2) is that this information does not cross the CE-PE boundary in the base mode one would assume this information is manually registered at PEs and in the enhanced mode "registration" would be provided through the routing protocol running between CE-PE boundary > 2. Enhanced mode: the CE-PE interface provides the signaling capabilities > as in the Basic mode, plus permits utilization of the provider's control > plane for distribution of user's routing information (e.g. similar to > the MPLS/BGP model). > > The WG will work on the following items: > > 1. Specification of the L1VPN user-to-network interface (UNI) basic mode, > including both CE and PE functionality. > > 2. Specification of the L1VPN node-to-node interface (NNI) basic mode. > > 3. MIB modules and/or extensions required for UNI and NNI basic mode. > > 4. Specification of L1VPN UNI enhanced mode. > > 5. Specification of L1VPN NNI enhanced mode. > > 6. MIB modules and/or extensions required for UNI and NNI enhanced mode. > > Protocol extensions required for L1VPN will be done in cooperation with > CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. > > Milestones: > > Sep 05 Submit first Internet Drafts of UNI and NNI basic mode > specifications > Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic > mode > Jun 06 Submit UNI and NNI basic mode specifications to IESG for > publication as Proposed Standard > Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode > specifications > Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for > publication as Proposed Standard > Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for > publication as Proposed Standard > Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for > publication as Proposed Standard Aug 07 ? From rtg-dir-bounces@ietf.org Wed May 4 08:54:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02579 for ; Wed, 4 May 2005 08:54:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTJct-0005F4-P9 for rtg-dir-archive@ietf.org; Wed, 04 May 2005 09:09:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTJLq-0001gx-U1; Wed, 04 May 2005 08:51:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTJLp-0001go-II for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 08:51:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02297 for ; Wed, 4 May 2005 08:51:39 -0400 (EDT) Message-Id: <200505041251.IAA02297@ietf.org> Received: from [220.89.51.87] (helo=kgbgirls.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTJZt-00058m-FT for rtg-dir@ietf.org; Wed, 04 May 2005 09:06:15 -0400 From: "Xavior Dietz" To: "Lindon Stuart" Date: Wed, 4 May 2005 08:51:16 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C54EF7.4278D354" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: =?iso-8859-1?q?Vi=E0GRA_V=E0LL1UM_C1AL=EDS?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.8 (++++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C54EF7.4278D354 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, for as long as he might remain in Hispaniola, and to give effect Captain Blood took up his duties at once. There was much to be d In the background, moving slowly away down the line of prisoners, broke from them. It spread into a roar of acclamation; for bluff Captain Blood, I, too, will speak frankly; and you, too, must blow, the Hidalga blazed at the Englishman with both her forward that restless spirit by which he was imbued. A set of curious he felt, that for the sake of humanity he must slit the comb of down to the boats waiting at the beach to convey the treasure abo If it is a mistake to grant Captain Blood a commission, the mista The Dutch master got in his way with hands upheld to arrest his Have a nice day. ------=_NextPart_000_0013_01C54EF7.4278D354 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, Do you want to spend Iess on = your p=EDlIs?
     
    V=EDAGRA VALL=ECUM CIAL=ECSS and = many other.
     
    Save over 7 0 % with MEDlCATIONS By MAILL SHOP.
     
    Have a nice day.
     
     
     
     
    for as long as he might remain in Hispaniola, and to give effect
    = Captain Blood took up his duties at once. There was much to be
    d = In the background, moving slowly away down the line of
    prisoners, = broke from them. It spread into a roar of acclamation; for
    bluff = Captain Blood, I, too, will speak frankly; and you, too,
    must = blow, the Hidalga blazed at the Englishman with both her
    forward = that restless spirit by which he was imbued. A set of
    curious = he felt, that for the sake of humanity he must slit the comb
    of = down to the boats waiting at the beach to convey the treasure
    abo = If it is a mistake to grant Captain Blood a commission, the
    mista = The Dutch master got in his way with hands upheld to arrest
    his =
    ------=_NextPart_000_0013_01C54EF7.4278D354-- From rtg-dir-bounces@ietf.org Wed May 4 10:18:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13057 for ; Wed, 4 May 2005 10:18:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTKvx-0007sL-9G for rtg-dir-archive@ietf.org; Wed, 04 May 2005 10:33:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKhf-00030K-CC; Wed, 04 May 2005 10:18:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKhc-000308-Kt for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 10:18:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13031 for ; Wed, 4 May 2005 10:18:14 -0400 (EDT) Received: from web30814.mail.mud.yahoo.com ([68.142.201.140]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTKvg-0007rn-HU for rtg-dir@ietf.org; Wed, 04 May 2005 10:32:51 -0400 Received: (qmail 9997 invoked by uid 60001); 4 May 2005 14:18:03 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Tp4IL6b83bk6NEWzXFRDMiMMBP6a2xJT8igsTV7qFB0io8xoO6LPjUjbEm1nSwa4/J3hUAhJG8lTR3zSDN55F2Qw53+/IJAh7JHD9KqMcx4T/umQQdyBPafFbv+2bnfLk28wKJztqBXWrgHTwwkRg7itPEDhjht4srNoU6sSp/c= ; Message-ID: <20050504141803.9995.qmail@web30814.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30814.mail.mud.yahoo.com via HTTP; Wed, 04 May 2005 07:18:03 PDT Date: Wed, 4 May 2005 07:18:03 -0700 (PDT) From: Igor Bryskin To: Alex Zinin , Adrian Farrel , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , takeda.tomonori@lab.ntt.co.jp In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1930781288-1115216283=:9694" X-Spam-Score: 1.0 (+) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 --0-1930781288-1115216283=:9694 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA13031 Content-Transfer-Encoding: quoted-printable Alex, All =20 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits utilization of the provider's control plane for distribution of user's routing information (e.g. similar to the MPLS/BGP model). I=92d like to replace this with: =20 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits utilization of the provider's control plane for distribution of user's arbitrary control plane information betw= een the VPN sites including but not limited to routing information. =20 Provider network IHMO should make no assumptions on what protocols are ru= nning within VPNs. Generally speaking, a L1VPN user is not necessarily GM= PLS controlled network. Furthermore, even in case it does use GMPLS it ne= eds L1VPN CE-CE connections to provide (TE) links within VPNs. Specifical= ly, the User should be capable to run LMP for such links, it also should = be possible to establish signaling (RSVP) adjacencies between their ends,= etc. The bottom line is that distribution of routing information between= CEs IHMO is not sufficient. I believe this is consistent with the requir= ements stated in ITU-T SG13 L1VPN documents=20 =20 Igor =20 =20 Alex Zinin wrote:=20 Folks- Before we bring it to the l1vpn mailing list, I'd like to run this draft by you guys for comments. --=20 Alex Layer 1 Virtual Private Networks (l1vpn) Last Modified: 2005-01-25 Chair(s): TBD TBD Routing Area Director(s): Bill Fenner=20 Alex Zinin=20 Routing Area Advisor: Alex Zinin=20 Technical Advisor(s): Mailing Lists: General Discussion: l1vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html Description of Working Group: L1VPN Working Group's task is to specify mechanisms necessary for providing a VPN service over a GMPLS transport network. The following two service models will be addressed: 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. The GMPLS network is not involved in distribution of user's routing information. 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits utilization of the provider's control plane for distribution of user's routing information (e.g. similar to the MPLS/BGP model). The WG will work on the following items: 1. Specification of the L1VPN user-to-network interface (UNI) basic mode, including both CE and PE functionality. 2. Specification of the L1VPN node-to-node interface (NNI) basic mode. 3. MIB modules and/or extensions required for UNI and NNI basic mode. 4. Specification of L1VPN UNI enhanced mode. 5. Specification of L1VPN NNI enhanced mode. 6. MIB modules and/or extensions required for UNI and NNI enhanced mode. Protocol extensions required for L1VPN will be done in cooperation with CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. Milestones: Sep 05 Submit first Internet Drafts of UNI and NNI basic mode specifications Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic mode Jun 06 Submit UNI and NNI basic mode specifications to IESG for publication as Proposed Standard Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode specifications Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for publication as Proposed Standard Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for publication as Proposed Standard Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for publication as Proposed Standard =20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 --0-1930781288-1115216283=:9694 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA13031 Content-Transfer-Encoding: quoted-printable

    Alex, All

     

    2. Enhanced mode: the CE-PE interface provi= des the signaling capabilities
    as in the Basic mode, plus permits util= ization of the provider's control
    plane for distribution of user's rou= ting information (e.g. similar to the
    MPLS/BGP model).

    I=92d like to replace this with:=

     

    2. Enhanced mode: the CE-PE interface provi= des the signaling capabilities
    as in the Basic mode, plus permits util= ization of the provider's control
    plane for distribution of user's arb= itrary control plane information between the VPN sites including but not = limited to routing information.

     

    Provider network IHMO should make no assump= tions on what protocols are running within VPNs. Generally speaking, a L1= VPN user is not necessarily GMPLS controlled network. Furthermore, even i= n case it does use GMPLS it needs L1VPN CE-CE connections to provide (TE)= links within VPNs. Specifically, the User should be capable to run LMP f= or such links, it also should be possible to establish signaling (RSVP) a= djacencies between their ends, etc. The bottom line is that distribution = of routing information between CEs IHMO is not sufficient. I believe this= is consistent with the requirements stated in ITU-T SG13 L1VPN documents=

     

    Igor = ; 

     



    Alex Zinin <zinin@psg.com&= gt; wrote:

    Folks-

    Before we bring it to th= e l1vpn mailing list, I'd like to run this draft
    by you guys for comme= nts.

    --
    Alex


    Layer 1 Virtual Private Networks (l1vp= n)

    Last Modified: 2005-01-25
    Chair(s):
    TBD
    TBD
    Ro= uting Area Director(s):
    Bill Fenner
    Alex Zinin

    Routing Are= a Advisor:
    Alex Zinin

    Technical Advisor(s):

    Mailing Lis= ts:
    General Discussion: l1vpn@ietf.org
    To Subscribe: https://www1.i= etf.org/mailman/listinfo/l1vpn
    Archive: http://www.ietf.org/mail-archi= ve/web/l1vpn/index.html

    Description of Working Group:

    L1VPN Working Group's task is to specify mechanisms necess= ary for
    providing a VPN service over a GMPLS transport network.
    The following two service models will be addressed:

    1. Basic mode= : the CE-PE interface's functional repertoire is limited to
    path setup= signalling only. The GMPLS network is not involved in
    distribution of= user's routing information.

    2. Enhanced mode: the CE-PE interface= provides the signaling capabilities
    as in the Basic mode, plus permit= s utilization of the provider's control
    plane for distribution of user= 's routing information (e.g. similar to the
    MPLS/BGP model).

    Th= e WG will work on the following items:

    1. Specification of the L1V= PN user-to-network interface (UNI) basic mode,
    including both CE and P= E functionality.

    2. Specification of the L1VPN node-to-node interf= ace (NNI) basic mode.

    3. MIB modules and/or extensions required fo= r UNI and NNI basic mode.

    4. Specification of L1VPN UNI enhanced mode.

    5. Specification of L1VPN NNI enhance= d mode.

    6. MIB modules and/or extensions required for UNI and NNI = enhanced mode.

    Protocol extensions required for L1VPN will be done= in cooperation with
    CCAMP, OSPF, IS-IS, IDR, and other WGs where nece= ssary.

    Milestones:

    Sep 05 Submit first Internet Drafts of U= NI and NNI basic mode
    specifications
    Dec 05 Submit first Internet D= rafts of MIB modules for UNI and NNI basic
    mode
    Jun 06 Submit UNI a= nd NNI basic mode specifications to IESG for
    publication as Proposed S= tandard
    Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mo= de
    specifications
    Aug 06 Submit MIB modules for UNI and NNI basic m= ode to IESG for
    publication as Proposed Standard
    Dec 06 Submit UNI = and NNI enhanced mode specifications to IESG for
    publication as Propos= ed Standard
    Aug 06 Submit MIB modules for UNI and NNI enhanced mode to= IESG for
    publication as Proposed Standard



     

    ___________= _______________________________________
    Do You Yahoo!?
    Tired of spa= m? Yahoo! Mail has the best spam protection around
    http://mail.yahoo= .com=20 --0-1930781288-1115216283=:9694-- From rtg-dir-bounces@ietf.org Wed May 4 10:34:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15230 for ; Wed, 4 May 2005 10:34:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTLBM-0008Qn-RI for rtg-dir-archive@ietf.org; Wed, 04 May 2005 10:49:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKww-0007PO-S5; Wed, 04 May 2005 10:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTKwv-0007PE-Ow for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 10:34:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15168 for ; Wed, 4 May 2005 10:34:03 -0400 (EDT) Received: from natint3.juniper.net ([66.129.224.36] helo=kummer.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTLB1-0008Q6-AU for rtg-dir@ietf.org; Wed, 04 May 2005 10:48:40 -0400 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j44EXm1l005641; Wed, 4 May 2005 07:33:48 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j44EXm7R005638; Wed, 4 May 2005 07:33:48 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 4 May 2005 07:33:48 -0700 (PDT) From: Kireeti Kompella To: Alex Zinin In-Reply-To: <314876349.20050503211842@psg.com> Message-ID: <20050504071954.K5472@kummer.juniper.net> References: <5.1.1.9.2.20050420152913.067fc360@imf.m.ecl.ntt.co.jp> <00a401c54845$754979a0$1c849ed9@Puppy> <314876349.20050503211842@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Kireeti Kompella , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Igor Bryskin , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b On Tue, 3 May 2005, Alex Zinin wrote: > Layer 1 Virtual Private Networks (l1vpn) > > Last Modified: 2005-01-25 > Chair(s): > TBD > TBD > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Technical Advisor(s): > > Mailing Lists: > General Discussion: l1vpn@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn > Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html > > Description of Working Group: > > L1VPN Working Group's task is to specify mechanisms necessary for > providing a VPN service over a GMPLS transport network. > > The following two service models will be addressed: > > 1. Basic mode: the CE-PE interface's functional repertoire is limited to > path setup signalling only. The GMPLS network is not involved in > distribution of user's routing information. Well, reachability information needs to be exchanged (what CE's are in my VPN, and how can I reach them (via which PE)?). > 2. Enhanced mode: the CE-PE interface provides the signaling capabilities > as in the Basic mode, plus permits utilization of the provider's control > plane for distribution of user's routing information (e.g. similar to the > MPLS/BGP model). Here, there is additional routing info, typically about CE-PE links. > The WG will work on the following items: We should add the l1vpn framework document. I usually don't care much for fw docs, but this one is useful, and sets out the reference models. If the charter uses the terms 'basic' and 'enhanced' modes, these can be defined in detail in the fw doc. > 1. Specification of the L1VPN user-to-network interface (UNI) basic mode, > including both CE and PE functionality. > > 2. Specification of the L1VPN node-to-node interface (NNI) basic mode. NNI = network-to-network > 3. MIB modules and/or extensions required for UNI and NNI basic mode. > > 4. Specification of L1VPN UNI enhanced mode. > > 5. Specification of L1VPN NNI enhanced mode. > > 6. MIB modules and/or extensions required for UNI and NNI enhanced mode. > > Protocol extensions required for L1VPN will be done in cooperation with > CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. > > Milestones: > > Sep 05 Submit first Internet Drafts of UNI and NNI basic mode > specifications as individual drafts? as WG docs? > Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic > mode ditto > Jun 06 Submit UNI and NNI basic mode specifications to IESG for > publication as Proposed Standard Seems too much time here. I would suggest mar 06. > Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode > specifications Why serialize between basic and enhanced modes? The initial enhanced mode draft(s) could be submitted jan/feb 06. > Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for > publication as Proposed Standard > Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for > publication as Proposed Standard > Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for > publication as Proposed Standard Kireeti. ------- From rtg-dir-bounces@ietf.org Wed May 4 12:21:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26107 for ; Wed, 4 May 2005 12:21:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTMrE-0003GO-II for rtg-dir-archive@ietf.org; Wed, 04 May 2005 12:36:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMcw-0000A3-S1; Wed, 04 May 2005 12:21:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTMcv-00009v-45 for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 12:21:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26079 for ; Wed, 4 May 2005 12:21:30 -0400 (EDT) Received: from natint3.juniper.net ([66.129.224.36] helo=kummer.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTMr1-0003G9-Le for rtg-dir@ietf.org; Wed, 04 May 2005 12:36:08 -0400 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j44GLC1l006154; Wed, 4 May 2005 09:21:12 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j44GLCxN006151; Wed, 4 May 2005 09:21:12 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 4 May 2005 09:21:12 -0700 (PDT) From: Kireeti Kompella To: Alex Zinin In-Reply-To: <314876349.20050503211842@psg.com> Message-ID: <20050504091948.U5472@kummer.juniper.net> References: <5.1.1.9.2.20050420152913.067fc360@imf.m.ecl.ntt.co.jp> <00a401c54845$754979a0$1c849ed9@Puppy> <314876349.20050503211842@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Kireeti Kompella , rtg-dir@ietf.org, Igor Bryskin , Adrian Farrel , dpapadimitriou@psg.com, takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Tue, 3 May 2005, Alex Zinin wrote: > Layer 1 Virtual Private Networks (l1vpn) > > Last Modified: 2005-01-25 > Chair(s): > TBD > TBD > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin One question: what is the rationale for having L1VPN in the Routing Area, whereas L2VPN and L3VPN are in Internet? Kireeti. ------- From rtg-dir-bounces@ietf.org Wed May 4 13:24:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02876 for ; Wed, 4 May 2005 13:24:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTNq1-0005Dg-QR for rtg-dir-archive@ietf.org; Wed, 04 May 2005 13:39:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTNb5-00035r-QX; Wed, 04 May 2005 13:23:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTNb4-00035m-DD for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 13:23:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02785 for ; Wed, 4 May 2005 13:23:39 -0400 (EDT) Received: from web30802.mail.mud.yahoo.com ([68.142.200.145]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTNpC-0005Bd-4r for rtg-dir@ietf.org; Wed, 04 May 2005 13:38:18 -0400 Received: (qmail 26988 invoked by uid 60001); 4 May 2005 17:23:32 -0000 Message-ID: <20050504172332.26986.qmail@web30802.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30802.mail.mud.yahoo.com via HTTP; Wed, 04 May 2005 10:23:32 PDT Date: Wed, 4 May 2005 10:23:32 -0700 (PDT) From: Igor Bryskin To: Dimitri.Papadimitriou@alcatel.be In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1036453969-1115227412=:26957" X-Spam-Score: 1.1 (+) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: Alex Zinin , rtg-dir@ietf.org, Dimitri.Papadimitriou@alcatel.be, Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 --0-1036453969-1115227412=:26957 Content-Type: text/plain; charset=us-ascii Good idea. Igor Dimitri.Papadimitriou@alcatel.be wrote: igor, all - now that i am thinking of it there is probably a need to add a sentence like "The WG will also liaise with related ITU-T SGs" after "... and other WGs where necessary." Igor Bryskin Sent by: rtg-dir-bounces@ietf.org 05/04/2005 07:18 MST To: Alex Zinin , Adrian Farrel , Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, rtg-dir@ietf.org, Kireeti Kompella , takeda.tomonori@lab.ntt.co.jp cc: bcc: Subject: Re: Draft L1VPN Charter Alex, All 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits utilization of the provider's control plane for distribution of user's routing information (e.g. similar to the MPLS/BGP model). I'd like to replace this with: 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits utilization of the provider's control plane for distribution of user's arbitrary control plane information between the VPN sites including but not limited to routing information. Provider network IHMO should make no assumptions on what protocols are running within VPNs. Generally speaking, a L1VPN user is not necessarily GMPLS controlled network. Furthermore, even in case it does use GMPLS it needs L1VPN CE-CE connections to provide (TE) links within VPNs. Specifically, the User should be capable to run LMP for such links, it also should be possible to establish signaling (RSVP) adjacencies between their ends, etc. The bottom line is that distribution of routing information between CEs IHMO is not sufficient. I believe this is consistent with the requirements stated in ITU-T SG13 L1VPN documents Igor Alex Zinin wrote: Folks- Before we bring it to the l1vpn mailing list, I'd like to run this draft by you guys for comments. -- Alex Layer 1 Virtual Private Networks (l1vpn) Last Modified: 2005-01-25 Chair(s): TBD TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Technical Advisor(s): Mailing Lists: General Discussion: l1vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html Description of Working Group: L1VPN Working Group's task is to specify mechanisms necessary for providing a VPN service over a GMPLS transport network. The following two service models will be addressed: 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. The GMPLS network is not involved in distribution of user's routing information. 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits utilization of the provider's control plane for distribution of user's routing information (e.g. similar to the MPLS/BGP model). The WG will work on the following items: 1. Specification of the L1VPN user-to-network interface (UNI) basic mode, including both CE and PE functionality. 2. Specification of the L1VPN node-to-node interface (NNI) basic mode. 3. MIB modules and/or extensions required for UNI and NNI basic mode. 4. Specification of L1VPN UNI enhanced mode. 5. Specification of L1VPN NNI enhanced mode. 6. MIB modules and/or extensions required for UNI and NNI enhanced mode. Protocol extensions required for L1VPN will be done in cooperation with CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. Milestones: Sep 05 Submit first Internet Drafts of UNI and NNI basic mode specifications Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic mode Jun 06 Submit UNI and NNI basic mode specifications to IESG for publication as Proposed Standard Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode specifications Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for publication as Proposed Standard Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for publication as Proposed Standard Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for publication as Proposed Standard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------- Discover Yahoo! Find restaurants, movies, travel & more fun for the weekend. Check it out! --0-1036453969-1115227412=:26957 Content-Type: text/html; charset=us-ascii

    Good idea.
    Igor

    Dimitri.Papadimitriou@alcatel.be wrote:

    igor, all - now that i am thinking of it there is probably a need to add a sentence like "The WG will also liaise with related ITU-T SGs" after "... and other WGs where necessary."

    Igor Bryskin <i_bryskin@yahoo.com>
    Sent by: rtg-dir-bounces@ietf.org
    05/04/2005 07:18 MST

    To: Alex Zinin <zinin@psg.com>, Adrian Farrel <adrian@olddog.co.uk>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, rtg-dir@ietf.org, Kireeti Kompella <kireeti@juniper.net>, takeda.tomonori@lab.ntt.co.jp
    cc:
    bcc:
    Subject: Re: Draft L1VPN Charter


    Alex, All



    2. Enhanced mode: the CE-PE interface provides the signaling capabilities
    as in the Basic mode, plus permits utilization of the provider's control
    plane for distribution of user's routing information (e.g. similar to the
    MPLS/BGP model).

    I'd like to replace this with:



    2. Enhanced mode: the CE-PE interface provides the signaling capabilities
    as in the Basic mode, plus permits utilization of the provider's control
    plane for distribution of user's arbitrary control plane information between the VPN sites including but not limited to routing information.



    Provider network IHMO should make no assumptions on what protocols are running within VPNs. Generally speaking, a L1VPN user is not necessarily GMPLS controlled network. Furthermore, even in case it does use GMPLS it needs L1VPN CE-CE connections to provide (TE) links within VPNs. Specifically, the User should be capable to run LMP for such links, it also should be possible to establish signaling (RSVP) adjacencies between their ends, etc. The bottom line is that distribution of routing information between CEs IHMO is not sufficient. I believe this is consistent with the requirements stated in ITU-T SG13 L1VPN documents



    Igor  





    Alex Zinin <zinin@psg.com> wrote:

    Folks-

    Before we bring it to the l1vpn mailing list, I'd like to run this draft
    by you guys for comments.

    --
    Alex


    Layer 1 Virtual Private Networks (l1vpn)

    Last Modified: 2005-01-25
    Chair(s):
    TBD
    TBD
    Routing Area Director(s):
    Bill Fenner
    Alex Zinin

    Routing Area Advisor:
    Alex Zinin

    Technical Advisor(s):

    Mailing Lists:
    General Discussion: l1vpn@ietf.org
    To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn
    Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html

    Description of Working Group:

    L1VPN Working Group's task is to specify mechanisms necessary for
    providing a VPN service over a GMPLS transport network.
    The following two service models will be addressed:

    1. Basic mode: the CE-PE interface's functional repertoire is limited to
    path setup signalling only. The GMPLS network is not involved in
    distribution of user's routing information.

    2. Enhanced mode: the CE-PE interface provides the signaling capabilities
    as in the Basic mode, plus permits utilization of the provider's control
    plane for distribution of user's routing information (e.g. similar to the
    MPLS/BGP model).

    The WG will work on the following items:

    1. Specification of the L1VPN user-to-network interface (UNI) basic mode,
    including both CE and PE functionality.

    2. Specification of the L1VPN node-to-node interface (NNI) basic mode.
    !
    3. MIB modules and/or extensions required for UNI and NNI basic mode.

    4. Specification of L1VPN UNI enhanced mode.

    5. Specification of L1VPN NNI enhanced mode.

    6. MIB modules and/or extensions required for UNI and NNI enhanced mode.

    Protocol extensions required for L1VPN will be done in cooperation with
    CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary.

    Milestones:

    Sep 05 Submit first Internet Drafts of UNI and NNI basic mode
    specifications
    Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic
    mode
    Jun 06 Submit UNI and NNI basic mode specifications to IESG for
    publication as Proposed Standard
    Jun 06 Submit first Internet Draf! ts of UNI and NNI enhanced mode
    specifications
    Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for
    publication as Proposed Standard
    Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for
    publication as Proposed Standard
    Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for
    publication as Proposed Standard





    __________________________________________________
    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around
    http://mail.yahoo.com

    Discover Yahoo!
    Find restaurants, movies, travel & more fun for the weekend. Check it out! --0-1036453969-1115227412=:26957-- From rtg-dir-bounces@ietf.org Wed May 4 18:36:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19618 for ; Wed, 4 May 2005 18:36:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTShv-0002pl-G5 for rtg-dir-archive@ietf.org; Wed, 04 May 2005 18:51:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTSTQ-0000c9-7r; Wed, 04 May 2005 18:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTSTP-0000c4-33 for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 18:36:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19585 for ; Wed, 4 May 2005 18:36:04 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTShZ-0002pK-2o for rtg-dir@ietf.org; Wed, 04 May 2005 18:50:46 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTSTL-0001RL-CV; Wed, 04 May 2005 22:36:03 +0000 Date: Wed, 4 May 2005 15:36:01 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <107602060.20050504153601@psg.com> To: Dimitri.Papadimitriou@alcatel.be In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp, Igor Bryskin , rtg-dir@ietf.org Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Dimitri, >> The following two service models will be addressed: >> >> 1. Basic mode: the CE-PE interface's functional repertoire is limited to >> path setup signalling only. The GMPLS network is not involved in >> distribution of user's routing information. > in this base model, VPN membership information exchange between PE's (what > is referred to as CE reachability) is to be provided (the CE-PE link > properties are to be considered as improvement); the difference wrt to the > enhanced mode > described here below (point 2) is that this information does not cross the > CE-PE boundary > in the base mode one would assume this information is manually registered > at PEs and in the enhanced mode "registration" would be provided through > the routing protocol running between CE-PE boundary Not clear to me that the text above should be changed--the PEs will have to exchange whatever information they will have to exchange to make the thing work. >> Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for >> publication as Proposed Standard >> Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for >> publication as Proposed Standard > Aug 07 ? ok Alex From rtg-dir-bounces@ietf.org Wed May 4 18:48:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20510 for ; Wed, 4 May 2005 18:48:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTStX-0003I6-3G for rtg-dir-archive@ietf.org; Wed, 04 May 2005 19:03:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTSeO-00048D-S3; Wed, 04 May 2005 18:47:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTSeO-000488-BX for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 18:47:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20470 for ; Wed, 4 May 2005 18:47:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTSsZ-0003Gy-Fo for rtg-dir@ietf.org; Wed, 04 May 2005 19:02:07 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTSeN-00024V-1b; Wed, 04 May 2005 22:47:27 +0000 Date: Wed, 4 May 2005 15:47:24 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1123742435.20050504154724@psg.com> To: Kireeti Kompella In-Reply-To: <20050504091948.U5472@kummer.juniper.net> References: <5.1.1.9.2.20050420152913.067fc360@imf.m.ecl.ntt.co.jp> <00a401c54845$754979a0$1c849ed9@Puppy> <314876349.20050503211842@psg.com> <20050504091948.U5472@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Igor Bryskin , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp, rtg-dir@ietf.org, dpapadimitriou@psg.com Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Kireeti, >> Routing Area Advisor: >> Alex Zinin > One question: what is the rationale for having L1VPN in the Routing > Area, whereas L2VPN and L3VPN are in Internet? Looking back, I believe putting L2VPN and L3VPN in RTG was a big mistake. A lot of complexity related to their work, as well as people involved are in RTG. Same with L1VPN--it builds on the technology developed with RTG. Alex From rtg-dir-bounces@ietf.org Wed May 4 18:48:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20520 for ; Wed, 4 May 2005 18:48:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTStX-0003IA-L5 for rtg-dir-archive@ietf.org; Wed, 04 May 2005 19:03:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTScz-00046H-NY; Wed, 04 May 2005 18:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTScy-00046C-1J for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 18:46:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20290 for ; Wed, 4 May 2005 18:45:56 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTSr9-0003BH-0L for rtg-dir@ietf.org; Wed, 04 May 2005 19:00:39 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTScu-000206-U0; Wed, 04 May 2005 22:45:57 +0000 Date: Wed, 4 May 2005 15:45:54 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1919760085.20050504154554@psg.com> To: Kireeti Kompella In-Reply-To: <20050504071954.K5472@kummer.juniper.net> References: <5.1.1.9.2.20050420152913.067fc360@imf.m.ecl.ntt.co.jp> <00a401c54845$754979a0$1c849ed9@Puppy> <314876349.20050503211842@psg.com> <20050504071954.K5472@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: Igor Bryskin , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp, rtg-dir@ietf.org, Dimitri.Papadimitriou@alcatel.be Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Kireeti, >> The following two service models will be addressed: >> >> 1. Basic mode: the CE-PE interface's functional repertoire is limited to >> path setup signalling only. The GMPLS network is not involved in >> distribution of user's routing information. > Well, reachability information needs to be exchanged (what CE's are in > my VPN, and how can I reach them (via which PE)?). I thought this was supposed to be manually configured in the signalling-only scenario, no? >> 2. Enhanced mode: the CE-PE interface provides the signaling capabilities >> as in the Basic mode, plus permits utilization of the provider's control >> plane for distribution of user's routing information (e.g. similar to the >> MPLS/BGP model). > Here, there is additional routing info, typically about CE-PE links. My understanding of the routing info distribution was that it would provide the VPN-prefix to remote CE mapping. >> The WG will work on the following items: > We should add the l1vpn framework document. I usually don't care much > for fw docs, but this one is useful, and sets out the reference > models. If the charter uses the terms 'basic' and 'enhanced' modes, > these can be defined in detail in the fw doc. I thought the basic and enhanced mode specs would essentially be the profiles of different protocol features, pulling together different functionality. With this model in mind, do we still need a fw doc? >> 1. Specification of the L1VPN user-to-network interface (UNI) basic mode, >> including both CE and PE functionality. >> >> 2. Specification of the L1VPN node-to-node interface (NNI) basic mode. > NNI = network-to-network I remember ATM. I didn't like the original expansion though, since we're talking about a single network, hence the change. Don't care much though. >> Milestones: >> >> Sep 05 Submit first Internet Drafts of UNI and NNI basic mode >> specifications > as individual drafts? as WG docs? It's a WG charter. Individuals don't count :) >> Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic >> mode > ditto >> Jun 06 Submit UNI and NNI basic mode specifications to IESG for >> publication as Proposed Standard > Seems too much time here. I would suggest mar 06. C'est bon >> Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode >> specifications > Why serialize between basic and enhanced modes? The initial enhanced > mode draft(s) could be submitted jan/feb 06. Walk first? Alex From rtg-dir-bounces@ietf.org Wed May 4 18:50:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20644 for ; Wed, 4 May 2005 18:50:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTSvU-0003OZ-PV for rtg-dir-archive@ietf.org; Wed, 04 May 2005 19:05:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTSff-0004MX-V0; Wed, 04 May 2005 18:48:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTSfe-0004MS-C6 for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 18:48:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20560 for ; Wed, 4 May 2005 18:48:43 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTStp-0003IT-Ei for rtg-dir@ietf.org; Wed, 04 May 2005 19:03:25 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTSfb-000290-Id; Wed, 04 May 2005 22:48:43 +0000 Date: Wed, 4 May 2005 15:48:41 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <192513221.20050504154841@psg.com> To: Igor Bryskin In-Reply-To: <20050504172332.26986.qmail@web30802.mail.mud.yahoo.com> References: <20050504172332.26986.qmail@web30802.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Dimitri.Papadimitriou@alcatel.be, takeda.tomonori@lab.ntt.co.jp, rtg-dir@ietf.org, Adrian Farrel Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Makes my skin crawl after the ITU NGN workshop earlier this week, but I can add that. Will have to talk to the future WG chairs to clearly explain that this shouldn't become a DoS... -- Alex http://www.psg.com/~zinin Wednesday, May 4, 2005, 10:23:32 AM, Igor Bryskin wrote: > Good idea. > Igor > Dimitri.Papadimitriou@alcatel.be wrote: > igor, all - now that i am thinking of it there is probably a need to > add a sentence like "The WG will also liaise with related ITU-T SGs" > after "... and other WGs where necessary." > Igor Bryskin > Sent by: rtg-dir-bounces@ietf.org > 05/04/2005 07:18 MST > To: Alex Zinin , Adrian Farrel , > Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, rtg-dir@ietf.org, Kireeti > Kompella , takeda.tomonori@lab.ntt.co.jp > cc: > bcc: > Subject: Re: Draft L1VPN Charter > Alex, All > 2. Enhanced mode: the CE-PE interface provides the signaling capabilities > as in the Basic mode, plus permits utilization of the provider's control > plane for distribution of user's routing information (e.g. similar to the > MPLS/BGP model). > I'd like to replace this with: > 2. Enhanced mode: the CE-PE interface provides the signaling capabilities > as in the Basic mode, plus permits utilization of the provider's control > plane for distribution of user's arbitrary control plane information > between the VPN sites including but not limited to routing information. > Provider network IHMO should make no assumptions on what protocols are > running within VPNs. Generally speaking, a L1VPN user is not necessarily > GMPLS controlled network. Furthermore, even in case it does use GMPLS it > needs L1VPN CE-CE connections to provide (TE) links within VPNs. > Specifically, the User should be capable to run LMP for such links, it > also should be possible to establish signaling (RSVP) adjacencies between > their ends, etc. The bottom line is that distribution of routing > information between CEs IHMO is not sufficient. I believe this is > consistent with the requirements stated in ITU-T SG13 L1VPN documents > Igor > Alex Zinin wrote: > Folks- > Before we bring it to the l1vpn mailing list, I'd like to run this draft > by you guys for comments. From rtg-dir-bounces@ietf.org Wed May 4 18:54:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21167 for ; Wed, 4 May 2005 18:54:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTSzr-0003Y6-Sd for rtg-dir-archive@ietf.org; Wed, 04 May 2005 19:09:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTSlJ-0005ny-GC; Wed, 04 May 2005 18:54:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTSlH-0005nt-Id for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 18:54:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21131 for ; Wed, 4 May 2005 18:54:32 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTSzS-0003Xn-Ju for rtg-dir@ietf.org; Wed, 04 May 2005 19:09:14 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTSlF-0002cP-EQ; Wed, 04 May 2005 22:54:33 +0000 Date: Wed, 4 May 2005 15:54:31 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <941595905.20050504155431@psg.com> To: Igor Bryskin In-Reply-To: <20050504141803.9995.qmail@web30814.mail.mud.yahoo.com> References: 6667 <20050504141803.9995.qmail@web30814.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA21131 Cc: Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp, rtg-dir@ietf.org, Dimitri.Papadimitriou@alcatel.be Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Igor, > 2. Enhanced mode: the CE-PE interface provides the signaling capabiliti= es > as in the Basic mode, plus permits utilization of the provider's contro= l > plane for distribution of user's routing information (e.g. similar to t= he > MPLS/BGP model). > I=92d like to replace this with: > 2. Enhanced mode: the CE-PE interface provides the signaling capabiliti= es > as in the Basic mode, plus permits utilization of the provider's contro= l > plane for distribution of user's arbitrary control plane information > between the VPN sites including but not limited to routing information. > Provider network IHMO should make no assumptions on what protocols are > running within VPNs. Generally speaking, a L1VPN user is not necessaril= y > GMPLS controlled network. Furthermore, even in case it does use GMPLS i= t > needs L1VPN CE-CE connections to provide (TE) links within VPNs. > Specifically, the User should be capable to run LMP for such links, it > also should be possible to establish signaling (RSVP) adjacencies betwe= en > their ends, etc. The bottom line is that distribution of routing > information between CEs IHMO is not sufficient. I believe this is > consistent with the requirements stated in ITU-T SG13 L1VPN documents=20 Distributing "arbitrary" control plane information is a scary idea. In fact, I should really change that to "reachability" to be even more specific. Igor, could you explain how representing CE-CE connections as TE links an= d running LMP over them requires additional info to be distributed by the cloud's control plane? Alex From rtg-dir-bounces@ietf.org Wed May 4 19:23:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25719 for ; Wed, 4 May 2005 19:23:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTTRD-0004p0-3r for rtg-dir-archive@ietf.org; Wed, 04 May 2005 19:37:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTTBo-00048L-1F; Wed, 04 May 2005 19:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTTBm-00048G-67 for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 19:21:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25663 for ; Wed, 4 May 2005 19:21:54 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTTPw-0004nT-Dm for rtg-dir@ietf.org; Wed, 04 May 2005 19:36:37 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j44NLpLD001167; Thu, 5 May 2005 01:21:51 +0200 To: Alex Zinin MIME-Version: 1.0 Date: Thu, 5 May 2005 01:21:50 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/05/2005 01:21:53 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 4.8 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: base64 Cc: Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Adrian Farrel , Igor Bryskin , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.8 (++++) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmFsZXggPC9GT05UPjxCUj48Rk9OVCBG QUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OyZndDsmZ3Q7IFRoZSBmb2xsb3dpbmcgdHdvIHNl cnZpY2UgbW9kZWxzIHdpbGwgYmUgYWRkcmVzc2VkOjxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0OyZn dDsmZ3Q7ICZuYnNwOzEuIEJhc2ljIG1vZGU6IHRoZSBDRS1QRSBpbnRlcmZhY2UncyBmdW5jdGlv bmFsIHJlcGVydG9pcmUgaXMgbGltaXRlZCB0bzxCUj4mZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNw OyBwYXRoIHNldHVwIHNpZ25hbGxpbmcgb25seS4gVGhlIEdNUExTIG5ldHdvcmsgaXMgbm90IGlu dm9sdmVkIGluPEJSPiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IGRpc3RyaWJ1dGlvbiBvZiB1 c2VyJ3Mgcm91dGluZyBpbmZvcm1hdGlvbi48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25v c3BhY2UsQ291cmllciI+Jmd0OyZndDsgaW4gdGhpcyBiYXNlIG1vZGVsLCBWUE4gbWVtYmVyc2hp cCBpbmZvcm1hdGlvbiBleGNoYW5nZSBiZXR3ZWVuIFBFJ3MgKHdoYXQ8QlI+Jmd0OyZndDsgaXMg cmVmZXJyZWQgdG8gYXMgQ0UgcmVhY2hhYmlsaXR5KSBpcyB0byBiZSBwcm92aWRlZCAodGhlIENF LVBFIGxpbms8QlI+Jmd0OyZndDsgcHJvcGVydGllcyBhcmUgdG8gYmUgY29uc2lkZXJlZCBhcyBp bXByb3ZlbWVudCk7IHRoZSBkaWZmZXJlbmNlIHdydCB0byB0aGU8QlI+Jmd0OyZndDsgZW5oYW5j ZWQgbW9kZTxCUj4mZ3Q7Jmd0OyBkZXNjcmliZWQgaGVyZSBiZWxvdyAocG9pbnQgMikgaXMgdGhh dCB0aGlzIGluZm9ybWF0aW9uIGRvZXMgbm90IGNyb3NzIHRoZTxCUj4mZ3Q7Jmd0OyBDRS1QRSBi b3VuZGFyeTxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7 Jmd0OyBpbiB0aGUgYmFzZSBtb2RlIG9uZSB3b3VsZCBhc3N1bWUgdGhpcyBpbmZvcm1hdGlvbiBp cyBtYW51YWxseSByZWdpc3RlcmVkPEJSPiZndDsmZ3Q7IGF0IFBFcyBhbmQgaW4gdGhlIGVuaGFu Y2VkIG1vZGUgJnF1b3Q7cmVnaXN0cmF0aW9uJnF1b3Q7IHdvdWxkIGJlIHByb3ZpZGVkIHRocm91 Z2g8QlI+Jmd0OyZndDsgdGhlIHJvdXRpbmcgcHJvdG9jb2wgcnVubmluZyBiZXR3ZWVuIENFLVBF IGJvdW5kYXJ5PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZn dDsgTm90IGNsZWFyIHRvIG1lIHRoYXQgdGhlIHRleHQgYWJvdmUgc2hvdWxkIGJlIGNoYW5nZWQt LXRoZSBQRXMgd2lsbCBoYXZlPEJSPiZndDsgdG8gZXhjaGFuZ2Ugd2hhdGV2ZXIgaW5mb3JtYXRp b24gdGhleSB3aWxsIGhhdmUgdG8gZXhjaGFuZ2UgdG8gbWFrZSB0aGU8QlI+Jmd0OyB0aGluZyB3 b3JrLjxCUj48L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj50aGUg c2lnbmFsaW5nIG1vZGVsIGludm9sdmVzIGV4Y2hhbmdlIG9mIG1lbWJlcnNoaXAgKHRlcm0gdXNl ZCBpbiB0aGUgZnJhbWV3b3JrKSBpbmZvcm1hdGlvbiBiZXR3ZWVuIFBFczsgdGhpcyByZWZlcnMg dG8gdGhlIHNldCBvZiBpbmZvcm1hdGlvbiB0aGF0IGlkZW50aWZpZXMgQ0UgZW5kcG9pbnRzLCB0 aGVpciBhc3NvY2lhdGVkIFZQTiwgZXRjLjwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3Nw YWNlLENvdXJpZXIiPnRoZXJlZm9yZSB0aGUgbmV0d29yayBpcyBpbnZvbHZlZCBpbiBkaXN0cmli dXRpbmcgdGhpcyBpbmZvcm1hdGlvbiBzdWJzZXF1ZW50bHkgdXNlZCBieSB0aGUgaW5ncmVzcyBQ RSB0byBmb3J3YXJkIHRoZSBpbmNvbWluZyBDRSByZXF1ZXN0IHRvd2FyZHMgdGhlIGFwcHJvcHJp YXRlIGRlc3RpbmF0aW9uPC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmll ciI+dGhhbmtzLDwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0g ZGltaXRyaS48QlI+PC9GT05UPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48L1A+ From rtg-dir-bounces@ietf.org Wed May 4 21:07:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03977 for ; Wed, 4 May 2005 21:07:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTV4R-0000ij-M7 for rtg-dir-archive@ietf.org; Wed, 04 May 2005 21:22:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTUpG-0002Fg-8F; Wed, 04 May 2005 21:06:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTUpE-0002FR-AQ for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 21:06:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03921 for ; Wed, 4 May 2005 21:06:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTV3Q-0000dP-IR for rtg-dir@ietf.org; Wed, 04 May 2005 21:21:28 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTUpA-000BsN-6X; Thu, 05 May 2005 01:06:44 +0000 Date: Wed, 4 May 2005 18:06:37 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <997764879.20050504180637@psg.com> To: Dimitri.Papadimitriou@alcatel.be In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Adrian Farrel , rtg-dir@ietf.org, Igor Bryskin , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Dimitri, Do you believe proposed text of the charter should be changed, if so how? 10x. Alex >> Not clear to me that the text above should be changed--the PEs will have >> to exchange whatever information they will have to exchange to make the >> thing work. > the signaling model involves exchange of membership (term used in the > framework) information between PEs; this refers to the set of information > that identifies CE endpoints, their associated VPN, etc. > therefore the network is involved in distributing this information > subsequently used by the ingress PE to forward the incoming CE request > towards the appropriate destination > thanks, > - dimitri. From rtg-dir-bounces@ietf.org Wed May 4 21:09:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04054 for ; Wed, 4 May 2005 21:09:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTV5c-0000kC-LB for rtg-dir-archive@ietf.org; Wed, 04 May 2005 21:23:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTUq4-0002IG-Oe; Wed, 04 May 2005 21:07:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTUq3-0002IB-QC for rtg-dir@megatron.ietf.org; Wed, 04 May 2005 21:07:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03974 for ; Wed, 4 May 2005 21:07:37 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTV4G-0000iV-2w for rtg-dir@ietf.org; Wed, 04 May 2005 21:22:20 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTUq1-000Bx5-4M; Thu, 05 May 2005 01:07:37 +0000 Date: Wed, 4 May 2005 18:07:30 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <811368769.20050504180730@psg.com> To: Dimitri.Papadimitriou@alcatel.be In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: Igor Bryskin , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp, Kireeti Kompella , rtg-dir@ietf.org Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Hmmm... endorsement? I thought it was about cooperation, whatever that means, no? -- Alex http://www.psg.com/~zinin Wednesday, May 4, 2005, 4:35:09 PM, Dimitri.Papadimitriou@alcatel.be wrote: > alex, i understand ... the reason is to be clear in terms of protocol > work endorsement (also CCAMP WG was triggered by SG13 during Seoul > meeting) ... but indeed worth re-explaining the rules of the game > Alex Zinin > 05/04/2005 15:48 MST > Please respond to Alex Zinin > To:Igor Bryskin > cc:Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Adrian Farrel > , rtg-dir@ietf.org, Kireeti Kompella > , > bcc: > Subject:Re: Draft L1VPN Charter > Makes my skin crawl after the ITU NGN workshop earlier this week, but I can > add that. Will have to talk to the future WG chairs to clearly explain that > this shouldn't become a DoS... > -- > Alex > http://www.psg.com/~zinin > Wednesday, May 4, 2005, 10:23:32 AM, Igor Bryskin wrote: >> Good idea. >> Igor >> Dimitri.Papadimitriou@alcatel.be wrote: >> igor, all - now that i am thinking of it there is probably a need to >> add a sentence like "The WG will also liaise with related ITU-T SGs" >> after "... and other WGs where necessary." >> Igor Bryskin >> Sent by: rtg-dir-bounces@ietf.org >> 05/04/2005 07:18 MST >> To: Alex Zinin , Adrian Farrel , >> Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, rtg-dir@ietf.org, Kireeti >> Kompella , takeda.tomonori@lab.ntt.co.jp >> cc: >> bcc: >> Subject: Re: Draft L1VPN Charter >> Alex, All >> 2. Enhanced mode: the CE-PE interface provides the signaling capabilities >> as in the Basic mode, plus permits utilization of the provider's control >> plane for distribution of user's routing information (e.g. similar to the >> MPLS/BGP model). >> I'd like to replace this with: >> 2. Enhanced mode: the CE-PE interface provides the signaling capabilities >> as in the Basic mode, plus permits utilization of the provider's control >> plane for distribution of user's arbitrary control plane information >> between the VPN sites including but not limited to routing information. >> Provider network IHMO should make no assumptions on what protocols are >> running within VPNs. Generally speaking, a L1VPN user is not necessarily >> GMPLS controlled network. Furthermore, even in case it does use GMPLS it >> needs L1VPN CE-CE connections to provide (TE) links within VPNs. >> Specifically, the User should be capable to run LMP for such links, it >> also should be possible to establish signaling (RSVP) adjacencies between >> their ends, etc. The bottom line is that distribution of routing >> information between CEs IHMO is not sufficient. I believe this is >> consistent with the requirements stated in ITU-T SG13 L1VPN documents >> Igor >> Alex Zinin wrote: >> Folks- >> Before we bring it to the l1vpn mailing list, I'd like to run this draft >> by you guys for comments. From rtg-dir-bounces@ietf.org Thu May 5 04:07:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00924 for ; Thu, 5 May 2005 04:07:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTbcR-0004RM-C2 for rtg-dir-archive@ietf.org; Thu, 05 May 2005 04:22:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTbMP-00023V-Ki; Thu, 05 May 2005 04:05:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTbMN-00023C-C9 for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 04:05:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00655 for ; Thu, 5 May 2005 04:05:24 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTbab-0004O6-Hk for rtg-dir@ietf.org; Thu, 05 May 2005 04:20:10 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j4585KLD030706; Thu, 5 May 2005 10:05:20 +0200 To: Alex Zinin MIME-Version: 1.0 Date: Thu, 5 May 2005 10:05:19 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/05/2005 10:05:22 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Adrian Farrel , Igor Bryskin , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 alex > Do you believe proposed text of the charter should be changed yes > if so how? 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. The GMPLS network is involved in the distribution of user's routing information (e.g. reachable CE interfaces, VPN associated information, etc.) between PEs. thanks, - dimitri. From rtg-dir-bounces@ietf.org Thu May 5 05:41:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06873 for ; Thu, 5 May 2005 05:41:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTd5k-0000Bw-Po for rtg-dir-archive@ietf.org; Thu, 05 May 2005 05:56:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTcqa-0002kd-7g; Thu, 05 May 2005 05:40:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTcqZ-0002kU-7z for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 05:40:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06793 for ; Thu, 5 May 2005 05:40:40 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTd4o-00005K-KU for rtg-dir@ietf.org; Thu, 05 May 2005 05:55:28 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j459ebLD008004; Thu, 5 May 2005 11:40:37 +0200 MIME-Version: 1.0 To: Alex Zinin Date: Thu, 5 May 2005 11:40:36 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/05/2005 11:40:39 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 4.3 (++++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: base64 Cc: Igor Bryskin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.3 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: base64 PFA+YWxleCw8QlI+PEJSPmltaG8gdGhlIG1pbGVzdG9uZXMgc2hvdWxkIGJlIGNvbnNlcXVlbnQg d2l0aCBhbGwgdGhlIGludGVyYWN0aW9ucyB0aGUgTDFWUE4gV0cgd2lsbCBoYXZlIHRvIHRha2Ug aW50byBhY2NvdW50IGUuZy4gcHJvdG9jb2wgc3BlY2lmaWMgV0cgZm9yIGNvb3BlcmF0aW9uIGFu ZCByZXZpZXdzIGJ1dCBhbHNvIGluY29ycG9yYXRlIGNvbW1lbnRzIGZyb20gZXhwZXJ0IGFuZCBB RCByZXZpZXdzLCBldGMuIDxCUj48QlI+dGhlcmVmb3JlLCBjb25zaWRlciBzaXggbW9udGhzIGJl dHdlZW4gZmlyc3QgV0cgSS1EIGFuZCBJRVNHIHN1Ym1pc3Npb24gaXMgaW1obyB0aGUgbGVhc3Qg d2Ugc2hvdWxkIGNvbnNpZGVyOyBhbHNvIHdpdGggc3VjaCBzZXJpYWxpemVkIG1pbGVzdG9uZXMs IG9uZSBlbnN1cmVzIGdyYWR1YWwgcHJvZ3Jlc3MgY29uc2lzdGVudCB3aXRoIHdoYXQgaGFzIGJl ZW4gcHJldmlvdXNseSBkaXNjdXNzZWQgb24gdGhpcyBsaXN0PEJSPjxCUj4tPEJSPjxCUj5TZXAg MDUgU3VibWl0IGZpcnN0IEludGVybmV0IERyYWZ0cyBvZiBVTkkgYW5kIE5OSSBiYXNpYyBtb2Rl IHNwZWNpZmljYXRpb25zPEJSPjxCUj5EZWMgMDUgU3VibWl0IGZpcnN0IEludGVybmV0IERyYWZ0 cyBvZiBNSUIgbW9kdWxlcyBmb3IgVU5JIGFuZCBOTkkgYmFzaWMgbW9kZTxCUj48QlI+QXByIDA2 IFN1Ym1pdCBVTkkgYW5kIE5OSSBiYXNpYyBtb2RlIHNwZWNpZmljYXRpb25zIHRvIElFU0cgZm9y IHB1YmxpY2F0aW9uIGFzIFByb3Bvc2VkIFN0YW5kYXJkPEJSPjxCUj5KdW4gMDYgU3VibWl0IGZp cnN0IEludGVybmV0IERyYWZ0cyBvZiBVTkkgYW5kIE5OSSBlbmhhbmNlZCBtb2RlIHNwZWNpZmlj YXRpb25zPEJSPjxCUj5BdWcgMDYgU3VibWl0IE1JQiBtb2R1bGVzIGZvciBVTkkgYW5kIE5OSSBi YXNpYyBtb2RlIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIFByb3Bvc2VkIFN0YW5kYXJkPEJS PjxCUj5EZWMgMDYgU3VibWl0IFVOSSBhbmQgTk5JIGVuaGFuY2VkIG1vZGUgc3BlY2lmaWNhdGlv bnMgdG8gSUVTRyBmb3IgcHVibGljYXRpb24gYXMgUHJvcG9zZWQgU3RhbmRhcmQ8QlI+PEJSPkF1 ZyAwNyBTdWJtaXQgTUlCIG1vZHVsZXMgZm9yIFVOSSBhbmQgTk5JIGVuaGFuY2VkIG1vZGUgdG8g SUVTRyBmb3IgcHVibGljYXRpb24gYXMgUHJvcG9zZWQgU3RhbmRhcmQ8QlI+PEJSPi08QlI+PEJS Pm5vdGU6IGNvbmNlcm5pbmcgdGhlIEZXIGRvY3VtZW50ICh0aGUgdGl0bGUgb2YgaXQgY291bGQg YmUgbW9kaWZpZWQgYXMgYXBwcm9wcmlhdGUpIHNob3VsZCBpbWhvIGJlY29tZSB0aGUgcmVwb3Np dG9yeSBvZiB0aGUgc3BlY2lmaWMgTDFWUE4gdGVybXMsIGFuZCBkZWZpbml0aW9ucyAodGhhdCB3 ZXJlIG5vdCBwYXJ0IG9mIG90aGVyIEx4VlBOIGRvY3VtZW50cyk7IHRoaXMgaGVscHMgaW4gYXZv aWRpbmcgcmVwZWF0aW5nIGFsbCBvdmVyIGRlZmluaXRpb25zIGFuZCBhcHBlbmRpeGVzIGluIGVh Y2ggZG9jdW1lbnQgYW5kIG1haW50YWluIGEgc2luZ2xlIGFuZCBjb25zaXN0ZW50IGludGVycHJl dGF0aW9uIG9mIHRoZXNlIHRlcm1zOyB0aGlzIGRvY3VtZW50IGNvdWxkIGJlIHN0YXJ0ZWQgaW4g U2VwJzA1IGFuZCBiZSBzdWJtaXR0ZWQgdG8gdGhlIElFU0cgZm9yIGluc3QuIHdoZW4gdGhlIGVu aGFuY2VkIG1vZGUgc3BlY2lmaWNhdGlvbiBnZXRzIHN0YWJpbGl6ZWQ7IHRoaXMgc2FpZCwgaXQg c2hvdWxkIG5vdCBjcmVhdGUgYW55IHNwZWNpZmljIG92ZXJoZWFkIG9yIGJlIGJsb2NraW5nIHBy b2dyZXNzIG9mIG90aGVyIGRvY3VtZW50czwvUD4= From rtg-dir-bounces@ietf.org Thu May 5 10:42:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04590 for ; Thu, 5 May 2005 10:42:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DThme-0005fU-AE for rtg-dir-archive@ietf.org; Thu, 05 May 2005 10:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DThY9-0000BO-6g; Thu, 05 May 2005 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 1DThY8-0000B5-3l; Thu, 05 May 2005 10:42:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04538; Thu, 5 May 2005 10:41:57 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DThmR-0005f4-AS; Thu, 05 May 2005 10:56:47 -0400 Received: from cable-195-162-222-91.upc.chello.be ([195.162.222.91]) by mx2.foretec.com with smtp (Exim 4.24) id 1DThY3-00024t-GC; Thu, 05 May 2005 10:41:56 -0400 Delivered-To: mince@cheesecloth.dreamhost.com Received: from cheerful.dreamhost.com by proprietor.dreamhost.com (Pingofix) with ESMTP id 8CC4A04D4B for ; Thu, 05 May 2005 20:37:08 +0500 Message-ID: Date: Thu, 05 May 2005 09:43:08 -0600 From: "Margarito Goldsmith" To: X-Mailer: Mailman v2.0.5 X-SpamTest-Info: Profile: Formal (167/041129) X-SpamTest-Info: Profile: Detect Hard No RBL (4/030556) X-Spam-Score: 2.2 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: You've been selected for a low rate X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.h0us1ng.net/sign.asp Best Regards, Kerry Pritchard to be remov(ed: http://www.h0us1ng.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Thu May 5 11:21:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08715 for ; Thu, 5 May 2005 11:21:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTiOn-0007gf-S7 for rtg-dir-archive@ietf.org; Thu, 05 May 2005 11:36:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTi7k-000888-HK; Thu, 05 May 2005 11:18:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTi7i-000883-8y for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 11:18:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08432 for ; Thu, 5 May 2005 11:18:43 -0400 (EDT) Received: from web30807.mail.mud.yahoo.com ([68.142.200.150]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTiM0-0007Yg-ES for rtg-dir@ietf.org; Thu, 05 May 2005 11:33:34 -0400 Received: (qmail 47769 invoked by uid 60001); 5 May 2005 15:18:34 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=ekjR7ozO3ki5RKSa9a3q7aLq1Xn177L/sBnxAvxVgTiRwGDLQmVKD2A+88bHmiwBle0UJGrYqUtuiwIDceim50yuiu/Njl03fkdsBNsCjQh2RygamLDtX170/AGntAFy8O3mlxm4tWxyEjtLPAZjBAdwqHR2hrtg+PNDl4RRjCA= ; Message-ID: <20050505151834.47767.qmail@web30807.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30807.mail.mud.yahoo.com via HTTP; Thu, 05 May 2005 08:18:34 PDT Date: Thu, 5 May 2005 08:18:34 -0700 (PDT) From: Igor Bryskin To: Alex Zinin In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-306656907-1115306314=:46529" X-Spam-Score: 1.3 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp, rtg-dir@ietf.org, Dimitri.Papadimitriou@alcatel.be Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 --0-306656907-1115306314=:46529 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA08432 Content-Transfer-Encoding: quoted-printable Alex, =20 See in-line. =20 Igor Alex Zinin wrote:=20 Igor, > 2. Enhanced mode: the CE-PE interface provides the signaling capabiliti= es > as in the Basic mode, plus permits utilization of the provider's contro= l > plane for distribution of user's routing information (e.g. similar to t= he > MPLS/BGP model). > I#9619;d like to replace this with: > 2. Enhanced mode: the CE-PE interface provides the signaling capabiliti= es > as in the Basic mode, plus permits utilization of the provider's contro= l > plane for distribution of user's arbitrary control plane information > between the VPN sites including but not limited to routing information. > Provider network IHMO should make no assumptions on what protocols are > running within VPNs. Generally speaking, a L1VPN user is not necessaril= y > GMPLS controlled network. Furthermore, even in case it does use GMPLS i= t > needs L1VPN CE-CE connections to provide (TE) links within VPNs. > Specifically, the User should be capable to run LMP for such links, it > also should be possible to establish signaling (RSVP) adjacencies betwe= en > their ends, etc. The bottom line is that distribution of routing > information between CEs IHMO is not sufficient. I believe this is > consistent with the requirements stated in ITU-T SG13 L1VPN documents=20 Distributing "arbitrary" control plane information is a scary idea. In fact, I should really change that to "reachability" to be even more specific. Igor, could you explain how representing CE-CE connections as TE links an= d running LMP over them requires additional info to be distributed by the cloud's control plane? Alex =20 Let=92s consider a very simple VPN view: =20 C1-----CE1=3D=3D=3D=3D=3D=3D=3D=3DCE2-----C2 =20 In order for CE1 and CE2 discover TE link CE1-CE2 they may try to use LMP= which requires exchange of IP packets between CE1 and CE2, The fact that= there is a data plane connectivity between CE1 and CE2 (realized via L1V= PN connection) does not necessarily mean that CE1 and CE2 can use this co= nnection for the purpose of exchanging IP packets. Consider, for instance= , the situation when CE1 and CE2 are SDH cross-connects and the CE1-CE2 c= onnection is a VC4-4c LSP. Hence, the Provider network needs to participa= te in the out-of-band IP packet delivery to make CE1-CE2 LMP session work. =20 Likewise, when, say, C1 decides to provision an LSP from C1 to C2 RSVP me= ssages will need to be propagated between CE1 and CE2. Prior to that C1 n= eeds to compute a TE path for the LSP, hence it needs to know the attribu= tes of, say, TE link CE2-C2, which could be achieved if routing and TE in= formation is flooded over an IGP adjacency between CE1 and CE2. Mind that= just the knowledge of the fact that C2 could be reachable via CE2 is not= sufficient =96 there could be no TE path of the required parameters and = quality available between CE2 and C2. =20 The bottom line is that the Provider network needs to participate in pret= ty much every aspect of the VPN control plane, and as scary as it sounds,= the simplest way to accomplish this is to allow arbitrary control plane = connectivity between CEs. If one assumes that VPN control plane is always= IP based, the phrase =93arbitrary control plane connectivity=94 could be= transformed into =93IP connectivity=94. However, generally speaking, the= VPN control plane may not necessarily be IP based. =20 Igor =20 =20 =09 --------------------------------- Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. --0-306656907-1115306314=:46529 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA08432 Content-Transfer-Encoding: quoted-printable

    Alex,

     

    See in-line.

     

    Igor

    Alex Zinin <zinin@psg.= com> wrote:     <= /P>

    Igor,

    > 2. Enhanced mode: th= e CE-PE interface provides the signaling capabilities
    > as in the B= asic mode, plus permits utilization of the provider's control
    > pla= ne for distribution of user's routing information (e.g. similar to the> MPLS/BGP model).

    > I▓d like to replace this with:
    > 2. Enhanced mode: the CE-PE interface provides the signaling c= apabilities
    > as in the Basic mode, plus permits utilization of the= provider's control
    > plane for distribution of user's arbitrary co= ntrol plane information
    > between the VPN sites including but not limited to routing information.

    > Provider n= etwork IHMO should make no assumptions on what protocols are
    > runn= ing within VPNs. Generally speaking, a L1VPN user is not necessarily
    &= gt; GMPLS controlled network. Furthermore, even in case it does use GMPLS= it
    > needs L1VPN CE-CE connections to provide (TE) links within VP= Ns.
    > Specifically, the User should be capable to run LMP for such = links, it
    > also should be possible to establish signaling (RSVP) a= djacencies between
    > their ends, etc. The bottom line is that distr= ibution of routing
    > information between CEs IHMO is not sufficient= . I believe this is
    > consistent with the requirements stated in IT= U-T SG13 L1VPN documents

    Distributing "arbitrary" control plane i= nformation is a scary idea. In
    fact, I should really change that to "r= eachability" to be even more
    specific.

    Igor, could you explain = how representing CE-CE connections as TE links and
    running LMP over them requires additional info to be distributed = by the
    cloud's control plane?

    Alex

     

    Let=92= s consider a very simple VPN view:

    &nbs= p;

    C1--= ---CE1=3D=3D=3D=3D=3D=3D=3D=3DCE2-----C2

    &nbs= p;

    In o= rder for CE1 and CE2 discover TE link CE1-CE2 they may try to use LMP whi= ch requires exchange of IP packets between CE1 and CE2, The fact that the= re is a data plane connectivity between CE1 and CE2 (realized via L1VPN c= onnection) does not necessarily mean that CE1 and CE2 can use this connec= tion for the purpose of exchanging IP packets. Consider, for instance, th= e situation when CE1 and CE2 are SDH cross-connects and the CE1-CE2 conne= ction is a VC4-4c LSP. Hence, the Provider network needs to participate i= n the out-of-band IP packet delivery to make CE1-CE2 LMP session work.

    &nbs= p;

    Like= wise, when, say, C1 decides to provision an LSP from C1 to C2 RSVP messag= es will need to be propagated between CE1 and CE2. Prior to that C1 needs= to compute a TE path for the LSP, hence it needs to know the attributes = of, say, TE link CE2-C2, which could be achieved if routing and TE inform= ation is flooded over an IGP adjacency between CE1 and CE2. Mind that jus= t the knowledge of the fact that C2 could be reachable via CE2 is not suf= ficient =96 there could be no TE path of the required parameters and qual= ity available between CE2 and C2.

    &nbs= p;

    The = bottom line is that the Provider network needs to participate in pretty m= uch every aspect of the VPN control plane, and as scary as it sounds, the= simplest way to accomplish this is to allow arbitrary control plane conn= ectivity between CEs. If one assumes that VPN control plane is always IP = based, the phrase =93arbitrary control plane connectivity=94 could be tra= nsformed into =93IP connectivity=94. However, generally speaking, the VPN= control plane may not necessarily be IP based.<= /P>

    &nbs= p;

    Igor=

    &nbs= p;

    &nbs= p;

    Yahoo! Mail Mobile
    =20 Take Yahoo! Mail with you! Check email on your = mobile phone. --0-306656907-1115306314=:46529-- From rtg-dir-bounces@ietf.org Thu May 5 11:57:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12844 for ; Thu, 5 May 2005 11:57:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTixY-00014A-I2 for rtg-dir-archive@ietf.org; Thu, 05 May 2005 12:12:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTiiy-0006lr-BP; Thu, 05 May 2005 11:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTiiu-0006li-Km for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 11:57:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12835 for ; Thu, 5 May 2005 11:57:09 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTixC-00013c-Oh for rtg-dir@ietf.org; Thu, 05 May 2005 12:12:00 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j45FuuLD013392; Thu, 5 May 2005 17:56:56 +0200 To: Igor Bryskin MIME-Version: 1.0 Date: Thu, 5 May 2005 17:56:55 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/05/2005 17:56:58 MIME-Version: 1.0 Content-Type: text/html; charset=Big5 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 3.9 (+++) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: base64 Cc: Alex Zinin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.9 (+++) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmlnb3IsPC9GT05UPjwvUD48UD48Rk9O VCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+eW91IG1lbnRpb24gdGhhdCB0aGUgcHJvdmlkZXIn cyBjb250cm9sIHBsYW5lIG5lZWRzIHRvIHBhcnRpY2lwYXRlIGluIENFLUNFIGNvbnRyb2wgbWVz c2FnZSBleGNoYW5nZXMsIGFjdHVhbGx5IHRoaXMgaXMgbm90IHRoZSBjYXNlLCBSRkMgMzk0NiBz dXBwb3J0cyB0aGUgcG9zc2libGl0eSB0byByZXF1ZXN0IGZvciBEQ0MgY2hhbm5lbCB0cmFuc3Bh cmVuY3kgKGlmIHN1cHBvcnRlZCBieSB0aGUgbmV0d29yayBkYXRhIHBsYW5lKSwgYW5kIG5vdGhp bmcgcHJldmVudHMgZnJvbSBydW5uaW5nIHRoZSBMTVAgc2Vzc2lvbiBvdmVyIHRoZSBWQy00LVhj IGNvbm5lY3Rpb24gaXRzZWxmIC0gaW4gY2FzZSA8L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1v bm9zcGFjZSxDb3VyaWVyIj4tIGNvbmNlcm5pbmcgdGhlIGV4Y2hhbmdlIG9mIG90aGVyIGNvbnRy b2wgcGxhbmUgaW5mb3JtYXRpb24gdGhlIEwxVlBOIG1vZGVscyBkZXNjcmliZWQgc2luY2Ugc28g ZmFyIGRvZXMgbm90IGFzc3VtZSBzb21ldGhpbmcgZGlmZmVyZW50IGZyb20gd2hhdCBoYXMgYmVl biBkZXZlbG9wZWQgaW4gdGhlIEdNUExTIG92ZXJsYXkgY29udGV4dCBpLmUuIHRoZSBjb25uZWN0 aW9uIGF0IHRoZSBTREgvY2lyY3VpdCBsZXZlbCBpcyB1c2VkIGJ5IHRoZSBjbGllbnQgY29udHJv bCBwbGFuZSB0byBleGNoYW5nZSBpdHMgb3duIGNvbnRyb2wgcGxhbmUgaW5mb3JtYXRpb24sIGlu IGNhc2UgZGVkaWNhdGVkIGNoYW5uZWwgYXJlIHJlcXVpcmVkIC0gZm9yIGluc3RhbmNlIHdoZW4g dGhlIGNsaWVudCBuZXR3b3JrIHdhbnRzIHRvIG1haW50YWluIGFuIG91dCBvZiBiYW5kIGNvbnRy b2wgY2hhbm5lbCAtIHRoYXQgaXMgdG8gYmUgZXN0YWJsaXNoZWQgb3ZlciBhIGRlZGljYXRlZCBW Qy00LVhjPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT0yPjxCPklnb3IgQnJ5c2tpbiAmbHQ7aV9i cnlza2luQHlhaG9vLmNvbSZndDs8L0I+PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+U2VudCBieTog cnRnLWRpci1ib3VuY2VzQGlldGYub3JnPC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+MDUvMDUvMjAw NSAwODoxOCBNU1Q8L0ZPTlQ+PEJSPjxCUj4gPEZPTlQgU0laRT0yPlRvOjwvRk9OVD4gPEZPTlQg U0laRT0yPkFsZXggWmluaW4gJmx0O3ppbmluQHBzZy5jb20mZ3Q7PC9GT05UPjxCUj4gPEZPTlQg U0laRT0yPmNjOjwvRk9OVD4gPEZPTlQgU0laRT0yPktpcmVldGkgS29tcGVsbGEgJmx0O2tpcmVl dGlAanVuaXBlci5uZXQmZ3Q7LCBBZHJpYW4gRmFycmVsICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVr Jmd0OywgdGFrZWRhLnRvbW9ub3JpQGxhYi5udHQuY28uanAsIHJ0Zy1kaXJAaWV0Zi5vcmcsIERp bWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUw8L0ZPTlQ+PEJSPiA8Rk9OVCBT SVpFPTI+YmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+IDxGT05U IFNJWkU9Mj5SZTogRHJhZnQgTDFWUE4gQ2hhcnRlcjwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQ PjxGT05UIFNJWkU9ND5BbGV4LDwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND6hQDwvRk9OVD48 QlI+PEJSPjxGT05UIFNJWkU9ND5TZWUgaW4tbGluZS48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpF PTQ+oUA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+SWdvcjwvRk9OVD48QlI+PEJSPjxGT05U IFNJWkU9ND48Qj48ST5BbGV4IFppbmluICZsdDt6aW5pbkBwc2cuY29tJmd0OzwvST48L0I+IHdy b3RlOiA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+SWdvciw8L0ZPTlQ+PEJSPjxCUj48Rk9O VCBTSVpFPTQ+Jmd0OyAyLiBFbmhhbmNlZCBtb2RlOiB0aGUgQ0UtUEUgaW50ZXJmYWNlIHByb3Zp ZGVzIHRoZSBzaWduYWxpbmcgY2FwYWJpbGl0aWVzPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0 OyBhcyBpbiB0aGUgQmFzaWMgbW9kZSwgcGx1cyBwZXJtaXRzIHV0aWxpemF0aW9uIG9mIHRoZSBw cm92aWRlcidzIGNvbnRyb2w8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IHBsYW5lIGZvciBk aXN0cmlidXRpb24gb2YgdXNlcidzIHJvdXRpbmcgaW5mb3JtYXRpb24gKGUuZy4gc2ltaWxhciB0 byB0aGU8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IE1QTFMvQkdQIG1vZGVsKS48L0ZPTlQ+ PEJSPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBJ+f5kIGxpa2UgdG8gcmVwbGFjZSB0aGlzIHdpdGg6 PC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PiZndDsgMi4gRW5oYW5jZWQgbW9kZTogdGhlIENF LVBFIGludGVyZmFjZSBwcm92aWRlcyB0aGUgc2lnbmFsaW5nIGNhcGFiaWxpdGllczwvRk9OVD48 QlI+PEZPTlQgU0laRT00PiZndDsgYXMgaW4gdGhlIEJhc2ljIG1vZGUsIHBsdXMgcGVybWl0cyB1 dGlsaXphdGlvbiBvZiB0aGUgcHJvdmlkZXIncyBjb250cm9sPC9GT05UPjxCUj48Rk9OVCBTSVpF PTQ+Jmd0OyBwbGFuZSBmb3IgZGlzdHJpYnV0aW9uIG9mIHVzZXIncyBhcmJpdHJhcnkgY29udHJv bCBwbGFuZSBpbmZvcm1hdGlvbjwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgYmV0d2VlbiB0 aGUgVlBOIHNpdGVzIGluY2x1ZGluZyBidXQgbm90IGxpbWl0ZWQgdG8gcm91dGluZyBpbmZvcm1h dGlvbi48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBQcm92aWRlciBuZXR3b3JrIElI TU8gc2hvdWxkIG1ha2Ugbm8gYXNzdW1wdGlvbnMgb24gd2hhdCBwcm90b2NvbHMgYXJlPC9GT05U PjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBydW5uaW5nIHdpdGhpbiBWUE5zLiBHZW5lcmFsbHkgc3Bl YWtpbmcsIGEgTDFWUE4gdXNlciBpcyBub3QgbmVjZXNzYXJpbHk8L0ZPTlQ+PEJSPjxGT05UIFNJ WkU9ND4mZ3Q7IEdNUExTIGNvbnRyb2xsZWQgbmV0d29yay4gRnVydGhlcm1vcmUsIGV2ZW4gaW4g Y2FzZSBpdCBkb2VzIHVzZSBHTVBMUyBpdDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgbmVl ZHMgTDFWUE4gQ0UtQ0UgY29ubmVjdGlvbnMgdG8gcHJvdmlkZSAoVEUpIGxpbmtzIHdpdGhpbiBW UE5zLjwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgU3BlY2lmaWNhbGx5LCB0aGUgVXNlciBz aG91bGQgYmUgY2FwYWJsZSB0byBydW4gTE1QIGZvciBzdWNoIGxpbmtzLCBpdDwvRk9OVD48QlI+ PEZPTlQgU0laRT00PiZndDsgYWxzbyBzaG91bGQgYmUgcG9zc2libGUgdG8gZXN0YWJsaXNoIHNp Z25hbGluZyAoUlNWUCkgYWRqYWNlbmNpZXMgYmV0d2VlbjwvRk9OVD48QlI+PEZPTlQgU0laRT00 PiZndDsgdGhlaXIgZW5kcywgZXRjLiBUaGUgYm90dG9tIGxpbmUgaXMgdGhhdCBkaXN0cmlidXRp b24gb2Ygcm91dGluZzwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgaW5mb3JtYXRpb24gYmV0 d2VlbiBDRXMgSUhNTyBpcyBub3Qgc3VmZmljaWVudC4gSSBiZWxpZXZlIHRoaXMgaXM8L0ZPTlQ+ PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IGNvbnNpc3RlbnQgd2l0aCB0aGUgcmVxdWlyZW1lbnRzIHN0 YXRlZCBpbiBJVFUtVCBTRzEzIEwxVlBOIGRvY3VtZW50cyA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBT SVpFPTQ+RGlzdHJpYnV0aW5nICZxdW90O2FyYml0cmFyeSZxdW90OyBjb250cm9sIHBsYW5lIGlu Zm9ybWF0aW9uIGlzIGEgc2NhcnkgaWRlYS4gSW48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5mYWN0 LCBJIHNob3VsZCByZWFsbHkgY2hhbmdlIHRoYXQgdG8gJnF1b3Q7cmVhY2hhYmlsaXR5JnF1b3Q7 IHRvIGJlIGV2ZW4gbW9yZTwvRk9OVD48QlI+PEZPTlQgU0laRT00PnNwZWNpZmljLjwvRk9OVD48 QlI+PEJSPjxGT05UIFNJWkU9ND5JZ29yLCBjb3VsZCB5b3UgZXhwbGFpbiBob3cgcmVwcmVzZW50 aW5nIENFLUNFIGNvbm5lY3Rpb25zIGFzIFRFIGxpbmtzIGFuZDwvRk9OVD48QlI+PEZPTlQgU0la RT00PnJ1bm5pbmcgTE1QIG92ZXIgdGhlbSByZXF1aXJlcyBhZGRpdGlvbmFsIGluZm8gdG8gYmUg ZGlzdHJpYnV0ZWQgYnkgdGhlPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Y2xvdWQncyBjb250cm9s IHBsYW5lPzwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND5BbGV4PC9GT05UPjxCUj48QlI+PEZP TlQgU0laRT00PqFAPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PkxldKGmcyBjb25zaWRlciBh IHZlcnkgc2ltcGxlIFZQTiB2aWV3OjwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND6hQDwvRk9O VD48QlI+PEJSPjxGT05UIFNJWkU9ND5DMS0tLS0tQ0UxPT09PT09PT1DRTItLS0tLUMyPC9GT05U PjxCUj48QlI+PEZPTlQgU0laRT00PqFAPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PkluIG9y ZGVyIGZvciBDRTEgYW5kIENFMiBkaXNjb3ZlciBURSBsaW5rIENFMS1DRTIgdGhleSBtYXkgdHJ5 IHRvIHVzZSBMTVAgd2hpY2ggcmVxdWlyZXMgZXhjaGFuZ2Ugb2YgSVAgcGFja2V0cyBiZXR3ZWVu IENFMSBhbmQgQ0UyLCBUaGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgZGF0YSBwbGFuZSBjb25uZWN0 aXZpdHkgYmV0d2VlbiBDRTEgYW5kIENFMiAocmVhbGl6ZWQgdmlhIEwxVlBOIGNvbm5lY3Rpb24p IGRvZXMgbm90IG5lY2Vzc2FyaWx5IG1lYW4gdGhhdCBDRTEgYW5kIENFMiBjYW4gdXNlIHRoaXMg Y29ubmVjdGlvbiBmb3IgdGhlIHB1cnBvc2Ugb2YgZXhjaGFuZ2luZyBJUCBwYWNrZXRzLiBDb25z aWRlciwgZm9yIGluc3RhbmNlLCB0aGUgc2l0dWF0aW9uIHdoZW4gQ0UxIGFuZCBDRTIgYXJlIFNE SCBjcm9zcy1jb25uZWN0cyBhbmQgdGhlIENFMS1DRTIgY29ubmVjdGlvbiBpcyBhIFZDNC00YyBM U1AuIEhlbmNlLCB0aGUgUHJvdmlkZXIgbmV0d29yayBuZWVkcyB0byBwYXJ0aWNpcGF0ZSBpbiB0 aGUgb3V0LW9mLWJhbmQgSVAgcGFja2V0IGRlbGl2ZXJ5IHRvIG1ha2UgQ0UxLUNFMiBMTVAgc2Vz c2lvbiB3b3JrLjwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND6hQDwvRk9OVD48QlI+PEJSPjxG T05UIFNJWkU9ND5MaWtld2lzZSwgd2hlbiwgc2F5LCBDMSBkZWNpZGVzIHRvIHByb3Zpc2lvbiBh biBMU1AgZnJvbSBDMSB0byBDMiBSU1ZQIG1lc3NhZ2VzIHdpbGwgbmVlZCB0byBiZSBwcm9wYWdh dGVkIGJldHdlZW4gQ0UxIGFuZCBDRTIuIFByaW9yIHRvIHRoYXQgQzEgbmVlZHMgdG8gY29tcHV0 ZSBhIFRFIHBhdGggZm9yIHRoZSBMU1AsIGhlbmNlIGl0IG5lZWRzIHRvIGtub3cgdGhlIGF0dHJp YnV0ZXMgb2YsIHNheSwgVEUgbGluayBDRTItQzIsIHdoaWNoIGNvdWxkIGJlIGFjaGlldmVkIGlm IHJvdXRpbmcgYW5kIFRFIGluZm9ybWF0aW9uIGlzIGZsb29kZWQgb3ZlciBhbiBJR1AgYWRqYWNl bmN5IGJldHdlZW4gQ0UxIGFuZCBDRTIuIE1pbmQgdGhhdCBqdXN0IHRoZSBrbm93bGVkZ2Ugb2Yg dGhlIGZhY3QgdGhhdCBDMiBjb3VsZCBiZSByZWFjaGFibGUgdmlhIENFMiBpcyBub3Qgc3VmZmlj aWVudCChViB0aGVyZSBjb3VsZCBiZSBubyBURSBwYXRoIG9mIHRoZSByZXF1aXJlZCBwYXJhbWV0 ZXJzIGFuZCBxdWFsaXR5IGF2YWlsYWJsZSBiZXR3ZWVuIENFMiBhbmQgQzIuPC9GT05UPjxCUj48 QlI+PEZPTlQgU0laRT00PqFAPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PlRoZSBib3R0b20g bGluZSBpcyB0aGF0IHRoZSBQcm92aWRlciBuZXR3b3JrIG5lZWRzIHRvIHBhcnRpY2lwYXRlIGlu IHByZXR0eSBtdWNoIGV2ZXJ5IGFzcGVjdCBvZiB0aGUgVlBOIGNvbnRyb2wgcGxhbmUsIGFuZCBh cyBzY2FyeSBhcyBpdCBzb3VuZHMsIHRoZSBzaW1wbGVzdCB3YXkgdG8gYWNjb21wbGlzaCB0aGlz IGlzIHRvIGFsbG93IGFyYml0cmFyeSBjb250cm9sIHBsYW5lIGNvbm5lY3Rpdml0eSBiZXR3ZWVu IENFcy4gSWYgb25lIGFzc3VtZXMgdGhhdCBWUE4gY29udHJvbCBwbGFuZSBpcyBhbHdheXMgSVAg YmFzZWQsIHRoZSBwaHJhc2UgoadhcmJpdHJhcnkgY29udHJvbCBwbGFuZSBjb25uZWN0aXZpdHmh qCBjb3VsZCBiZSB0cmFuc2Zvcm1lZCBpbnRvIKGnSVAgY29ubmVjdGl2aXR5oaguIEhvd2V2ZXIs IGdlbmVyYWxseSBzcGVha2luZywgdGhlIFZQTiBjb250cm9sIHBsYW5lIG1heSBub3QgbmVjZXNz YXJpbHkgYmUgSVAgYmFzZWQuPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PqFAPC9GT05UPjxC Uj48QlI+PEZPTlQgU0laRT00Pklnb3I8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+oUA8L0ZP TlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+oUA8L0ZPTlQ+PEJSPjxIUiBXSURUSD0iOTklIiBTSVpF PSIyIiBBTElHTj0ibGVmdCI+PEZPTlQgQ09MT1I9QkxBQ0s+PEJSPjwvRk9OVD48Rk9OVCBTSVpF PTQ+WWFob28hIE1haWwgTW9iaWxlPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQgQ09MT1I9QkxVRT48 VT48QSBIUkVGPWh0dHA6Ly91cy5yZC55YWhvby5jb20vbWFpbF91cy90YWdsaW5lcy9tb2JpbGUv Kmh0dHA6Ly9tb2JpbGUueWFob28uY29tL2xlYXJuL21haWw+VGFrZSBZYWhvbyEgTWFpbCB3aXRo IHlvdSE8L0E+PC9VPjwvRk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxBQ0s+IENoZWNrIGVtYWls IG9uIHlvdXIgbW9iaWxlIHBob25lLjwvRk9OVD48L1A+ From rtg-dir-bounces@ietf.org Thu May 5 12:27:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15987 for ; Thu, 5 May 2005 12:27:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjQW-0002dG-Q0 for rtg-dir-archive@ietf.org; Thu, 05 May 2005 12:42:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjBd-0007Rk-J1; Thu, 05 May 2005 12:26:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjBb-0007Rb-Gz for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 12:26:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15957 for ; Thu, 5 May 2005 12:26:48 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjPv-0002cw-Oo for rtg-dir@ietf.org; Thu, 05 May 2005 12:41:40 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTjBO-000Nhz-UG; Thu, 05 May 2005 16:26:39 +0000 Date: Thu, 5 May 2005 09:26:37 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <17418738.20050505092637@psg.com> To: Dimitri.Papadimitriou@alcatel.be In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=big5 X-Spam-Score: 0.8 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA15957 Cc: Igor Bryskin , rtg-dir@ietf.org, takeda.tomonori@lab.ntt.co.jp, Adrian Farrel , Kireeti Kompella Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Igor, Dimitri- I just realized that we've again fallen in to the same trap--we're havin= g a discussion on technical details here :) I'll change the text to say "distribution of some information from user'= s control plane", and we'll leave the rest to you guys and the WG process. --=20 Alex http://www.psg.com/~zinin Thursday, May 5, 2005, 8:56:55 AM, Dimitri.Papadimitriou@alcatel.be wrote= : > igor, > you mention that the provider's control plane needs to participate in > CE-CE control message exchanges, actually this is not the case, RFC 394= 6 > supports the possiblity to request for DCC channel transparency (if > supported by the network data plane), and nothing prevents from running > the LMP session over the VC-4-Xc connection itself - in case=20 > - concerning the exchange of other control plane information the L1VPN > models described since so far does not assume something different from > what has been developed in the GMPLS overlay context i.e. the connectio= n > at the SDH/circuit level is used by the client control plane to exchang= e > its own control plane information, in case dedicated channel are requir= ed > - for instance when the client network wants to maintain an out of band > control channel - that is to be established over a dedicated VC-4-Xc > Igor Bryskin > Sent by: rtg-dir-bounces@ietf.org > 05/05/2005 08:18 MST > To:Alex Zinin > cc:Kireeti Kompella , Adrian Farrel > , takeda.tomonori@lab.ntt.co.jp, rtg-dir@ietf.org, > Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > bcc: > Subject:Re: Draft L1VPN Charter > Alex, > =A1@ > See in-line. > =A1@ > Igor > Alex Zinin wrote:=20 > Igor, >> 2. Enhanced mode: the CE-PE interface provides the signaling capabilit= ies >> as in the Basic mode, plus permits utilization of the provider's contr= ol >> plane for distribution of user's routing information (e.g. similar to = the >> MPLS/BGP model). >> I=F9=FEd like to replace this with: >> 2. Enhanced mode: the CE-PE interface provides the signaling capabilit= ies >> as in the Basic mode, plus permits utilization of the provider's contr= ol >> plane for distribution of user's arbitrary control plane information >> between the VPN sites including but not limited to routing information. >> Provider network IHMO should make no assumptions on what protocols are >> running within VPNs. Generally speaking, a L1VPN user is not necessari= ly >> GMPLS controlled network. Furthermore, even in case it does use GMPLS = it >> needs L1VPN CE-CE connections to provide (TE) links within VPNs. >> Specifically, the User should be capable to run LMP for such links, it >> also should be possible to establish signaling (RSVP) adjacencies betw= een >> their ends, etc. The bottom line is that distribution of routing >> information between CEs IHMO is not sufficient. I believe this is >> consistent with the requirements stated in ITU-T SG13 L1VPN documents=20 > Distributing "arbitrary" control plane information is a scary idea. In > fact, I should really change that to "reachability" to be even more > specific. > Igor, could you explain how representing CE-CE connections as TE links = and > running LMP over them requires additional info to be distributed by the > cloud's control plane? > Alex > =A1@ > Let=A1=A6s consider a very simple VPN view: > =A1@ > C1-----CE1=3D=3D=3D=3D=3D=3D=3D=3DCE2-----C2 > =A1@ > In order for CE1 and CE2 discover TE link CE1-CE2 they may try to use > LMP which requires exchange of IP packets between CE1 and CE2, The fact > that there is a data plane connectivity between CE1 and CE2 (realized v= ia > L1VPN connection) does not necessarily mean that CE1 and CE2 can use th= is > connection for the purpose of exchanging IP packets. Consider, for > instance, the situation when CE1 and CE2 are SDH cross-connects and the > CE1-CE2 connection is a VC4-4c LSP. Hence, the Provider network needs t= o > participate in the out-of-band IP packet delivery to make CE1-CE2 LMP > session work. > =A1@ > Likewise, when, say, C1 decides to provision an LSP from C1 to C2 RSVP > messages will need to be propagated between CE1 and CE2. Prior to that = C1 > needs to compute a TE path for the LSP, hence it needs to know the > attributes of, say, TE link CE2-C2, which could be achieved if routing > and TE information is flooded over an IGP adjacency between CE1 and CE2. > Mind that just the knowledge of the fact that C2 could be reachable via > CE2 is not sufficient =A1V there could be no TE path of the required > parameters and quality available between CE2 and C2. > =A1@ > The bottom line is that the Provider network needs to participate in > pretty much every aspect of the VPN control plane, and as scary as it > sounds, the simplest way to accomplish this is to allow arbitrary contr= ol > plane connectivity between CEs. If one assumes that VPN control plane i= s > always IP based, the phrase =A1=A7arbitrary control plane connectivity=A1= =A8 > could be transformed into =A1=A7IP connectivity=A1=A8. However, general= ly > speaking, the VPN control plane may not necessarily be IP based. > =A1@ > Igor > =A1@ > =A1@ > Yahoo! Mail Mobile > Take Yahoo! Mail with you! Check email on your mobile phone. From rtg-dir-bounces@ietf.org Thu May 5 12:32:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16314 for ; Thu, 5 May 2005 12:32:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjVW-0002sC-Bf for rtg-dir-archive@ietf.org; Thu, 05 May 2005 12:47:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjGo-0008S8-1M; Thu, 05 May 2005 12:32:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjGm-0008S3-K8 for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 12:32:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16305 for ; Thu, 5 May 2005 12:32:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjV6-0002rx-3N for rtg-dir@ietf.org; Thu, 05 May 2005 12:47:01 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTjGi-000O28-3G; Thu, 05 May 2005 16:32:08 +0000 Date: Thu, 5 May 2005 09:32:06 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <342135922.20050505093206@psg.com> To: Dimitri.Papadimitriou@alcatel.be In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Adrian Farrel , rtg-dir@ietf.org, Igor Bryskin , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Dimitri, This isn't really user's routing info (as e.g. customer prefixes would be). How about we simply don't say anything about what exactly PEs exchange? Limiting the CE-PE interface to signalling already sets the upper limit for the info PEs can potentially exchange. -- Alex http://www.psg.com/~zinin Thursday, May 5, 2005, 1:05:19 AM, Dimitri.Papadimitriou@alcatel.be wrote: > alex >> Do you believe proposed text of the charter should be changed > yes >> if so how? > 1. Basic mode: the CE-PE interface's functional repertoire is limited to > path setup signalling only. The GMPLS network is involved in the > distribution of user's routing information (e.g. reachable CE > interfaces, > VPN associated information, etc.) between PEs. > thanks, > - dimitri. From rtg-dir-bounces@ietf.org Thu May 5 12:47:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17386 for ; Thu, 5 May 2005 12:47:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjjt-0003XV-5O for rtg-dir-archive@ietf.org; Thu, 05 May 2005 13:02:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjVG-0002xx-HF; Thu, 05 May 2005 12:47:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjVF-0002xs-DK for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 12:47:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17368 for ; Thu, 5 May 2005 12:47:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjjY-0003X7-MY for rtg-dir@ietf.org; Thu, 05 May 2005 13:01:58 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTjVB-000P1J-W3; Thu, 05 May 2005 16:47:06 +0000 Date: Thu, 5 May 2005 09:47:04 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1448398035.20050505094704@psg.com> To: Dimitri.Papadimitriou@alcatel.be In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp, Igor Bryskin , rtg-dir@ietf.org Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit OK -- Alex > alex, > imho the milestones should be consequent with all the interactions the > L1VPN WG will have to take into account e.g. protocol specific WG for > cooperation and reviews but also incorporate comments from expert and AD > reviews, etc. > therefore, consider six months between first WG I-D and IESG > submission is imho the least we should consider; also with such > serialized milestones, one ensures gradual progress consistent with what > has been previously discussed on this list > - > Sep 05 Submit first Internet Drafts of UNI and NNI basic mode specifications > Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic mode > Apr 06 Submit UNI and NNI basic mode specifications to IESG for publication as Proposed Standard > Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode specifications > Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for publication as Proposed Standard > Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for publication as Proposed Standard > Aug 07 Submit MIB modules for UNI and NNI enhanced mode to IESG for publication as Proposed Standard > note: concerning the FW document (the title of it could be modified as > appropriate) should imho become the repository of the specific L1VPN > terms, and definitions (that were not part of other LxVPN documents); > this helps in avoiding repeating all over definitions and appendixes in > each document and maintain a single and consistent interpretation of > these terms; this document could be started in Sep'05 and be submitted to > the IESG for inst. when the enhanced mode specification gets stabilized; > this said, it should not create any specific overhead or be blocking > progress of other documents From rtg-dir-bounces@ietf.org Thu May 5 12:53:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17981 for ; Thu, 5 May 2005 12:53:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjq0-0003lB-NK for rtg-dir-archive@ietf.org; Thu, 05 May 2005 13:08:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjYG-0003V4-Ua; Thu, 05 May 2005 12:50:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjYE-0003UQ-NW for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 12:50:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17585 for ; Thu, 5 May 2005 12:50:11 -0400 (EDT) Received: from web30805.mail.mud.yahoo.com ([68.142.200.148]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTjmW-0003em-LA for rtg-dir@ietf.org; Thu, 05 May 2005 13:05:03 -0400 Received: (qmail 72150 invoked by uid 60001); 5 May 2005 16:50:02 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=K2Xq2xES4l6Z4rMhf2x/QMEMvpXVw1APPiHB+VfSe3tGHJh4H0uRY0bTt1Lm7nXUVqFcDtaQ+dZ+bER7RaT8psFXRyXVh+2a0X7DnwFOjvm3MrHd2+H387/GwuhZvEBJXTgDGaTSM4Z8TzrS8CuH8dfoLg2MjHClmJ07O3QHj+s= ; Message-ID: <20050505165002.72144.qmail@web30805.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30805.mail.mud.yahoo.com via HTTP; Thu, 05 May 2005 09:50:02 PDT Date: Thu, 5 May 2005 09:50:02 -0700 (PDT) From: Igor Bryskin To: Alex Zinin , Dimitri.Papadimitriou@alcatel.be In-Reply-To: <17418738.20050505092637@psg.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-27091036-1115311802=:71533" X-Spam-Score: 0.5 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: Igor Bryskin , rtg-dir@ietf.org, takeda.tomonori@lab.ntt.co.jp, Adrian Farrel , Kireeti Kompella Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 --0-27091036-1115311802=:71533 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA17585 Content-Transfer-Encoding: quoted-printable Great idea. That is, actually, more or less what I was asking for. =20 Igor Alex Zinin wrote: Igor, Dimitri- I just realized that we've again fallen in to the same trap--we're having a discussion on technical details here :) I'll change the text to say "distribution of some information from user's control plane", and we'll leave the rest to you guys and the WG process. --=20 Alex http://www.psg.com/~zinin Thursday, May 5, 2005, 8:56:55 AM, Dimitri.Papadimitriou@alcatel.be wrote= : > igor, > you mention that the provider's control plane needs to participate in > CE-CE control message exchanges, actually this is not the case, RFC 394= 6 > supports the possiblity to request for DCC channel transparency (if > supported by the network data plane), and nothing prevents from running > the LMP session over the VC-4-Xc connection itself - in case=20 > - concerning the exchange of other control plane information the L1VPN > models described since so far does not assume something different from > what has been developed in the GMPLS overlay context i.e. the connectio= n > at the SDH/circuit level is used by the client control plane to exchang= e > its own control plane information, in case dedicated channel are requir= ed > - for instance when the client network wants to maintain an out of band > control channel - that is to be established over a dedicated VC-4-Xc > Igor Bryskin=20 > Sent by: rtg-dir-bounces@ietf.org > 05/05/2005 08:18 MST > To:Alex Zinin=20 > cc:Kireeti Kompella , Adrian Farrel > , takeda.tomonori@lab.ntt.co.jp, rtg-dir@ietf.org, > Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > bcc: > Subject:Re: Draft L1VPN Charter > Alex, > =A1@ > See in-line. > =A1@ > Igor > Alex Zinin wrote:=20 > Igor, >> 2. Enhanced mode: the CE-PE interface provides the signaling capabilit= ies >> as in the Basic mode, plus permits utilization of the provider's contr= ol >> plane for distribution of user's routing information (e.g. similar to = the >> MPLS/BGP model). >> I=F9=FEd like to replace this with: >> 2. Enhanced mode: the CE-PE interface provides the signaling capabilit= ies >> as in the Basic mode, plus permits utilization of the provider's contr= ol >> plane for distribution of user's arbitrary control plane information >> between the VPN sites including but not limited to routing information. >> Provider network IHMO should make no assumptions on what protocols are >> running within VPNs. Generally speaking, a L1VPN user is not necessari= ly >> GMPLS controlled network. Furthermore, even in case it does use GMPLS = it >> needs L1VPN CE-CE connections to provide (TE) links within VPNs. >> Specifically, the User should be capable to run LMP for such links, it >> also should be possible to establish signaling (RSVP) adjacencies betw= een >> their ends, etc. The bottom line is that distribution of routing >> information between CEs IHMO is not sufficient. I believe this is >> consistent with the requirements stated in ITU-T SG13 L1VPN documents=20 > Distributing "arbitrary" control plane information is a scary idea. In > fact, I should really change that to "reachability" to be even more > specific. > Igor, could you explain how representing CE-CE connections as TE links = and > running LMP over them requires additional info to be distributed by the > cloud's control plane? > Alex > =A1@ > Let=A1=A6s consider a very simple VPN view: > =A1@ > C1-----CE1=3D=3D=3D=3D=3D=3D=3D=3DCE2-----C2 > =A1@ > In order for CE1 and CE2 discover TE link CE1-CE2 they may try to use > LMP which requires exchange of IP packets between CE1 and CE2, The fact > that there is a data plane connectivity between CE1 and CE2 (realized v= ia > L1VPN connection) does not necessarily mean that CE1 and CE2 can use th= is > connection for the purpose of exchanging IP packets. Consider, for > instance, the situation when CE1 and CE2 are SDH cross-connects and the > CE1-CE2 connection is a VC4-4c LSP. Hence, the Provider network needs t= o > participate in the out-of-band IP packet delivery to make CE1-CE2 LMP > session work. > =A1@ > Likewise, when, say, C1 decides to provision an LSP from C1 to C2 RSVP > messages will need to be propagated between CE1 and CE2. Prior to that = C1 > needs to compute a TE path for the LSP, hence it needs to know the > attributes of, say, TE link CE2-C2, which could be achieved if routing > and TE information is flooded over an IGP adjacency between CE1 and CE2. > Mind that just the knowledge of the fact that C2 could be reachable via > CE2 is not sufficient =A1V there could be no TE path of the required > parameters and quality available between CE2 and C2. > =A1@ > The bottom line is that the Provider network needs to participate in > pretty much every aspect of the VPN control plane, and as scary as it > sounds, the simplest way to accomplish this is to allow arbitrary contr= ol > plane connectivity between CEs. If one assumes that VPN control plane i= s > always IP based, the phrase =A1=A7arbitrary control plane connectivity=A1= =A8 > could be transformed into =A1=A7IP connectivity=A1=A8. However, general= ly > speaking, the VPN control plane may not necessarily be IP based. > =A1@ > Igor > =A1@ > =A1@ > Yahoo! Mail Mobile > Take Yahoo! Mail with you! Check email on your mobile phone. =09 --------------------------------- Discover Yahoo! Get on-the-go sports scores, stock quotes, news & more. Check it out! --0-27091036-1115311802=:71533 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA17585 Content-Transfer-Encoding: quoted-printable
    Great idea. That is, actually, more or less what I was asking f= or.
     
    <= tbody><= /td>
    =
    SEARCH

    <= td vAlign=3Dbottom>

    TOP 10 NEW TITLES

    <= td width=3D4>  Microsoft=

     = ON SALE NOW!

     1 Office Pro 2003
     2 Windows XP Pro
     3 Adobe Creative Suite Premium
    &nbs= p;4 Norton Antivirus 2005
     5 Flash MX 2004
     6 Corel Draw 12
     7 Adobe Acrobat 7.0
     8 Windows 2003 Server
     9 Alias Maya 6 Wavefrt
    10 Adobe Premiere
     = See more by this manufacturer=
      
    &= nbsp;  Apple Software
      Customers also bought
       these oth= er items...



    		Microsoft Office Professional= Edition *2003*
    Microsoft
    <= td vAlign=3Dtop noWrap>
    Choose:
    <= tr>
     
    List Price:$899.00
    Price:$69.99<= /b>
    You Save:$830.01 (92= %)



    Availability:= Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requirements  |  Accessories  |  Other Versions

    Featur= es:

    • Analyze and manage business information using Access databases
    • Exchange data with other systems u= sing enhanced XML technology
    • Control information sharing rules with enhanced IRM technology
    • Easy-to-use wizards to create e-mail n= ewsletters and printed marketing materials
    • = More than 20 preformatted business reports
      • Sales Rank: #1
      Ship= ping: International/US or via instant download
      Date Coupon Expi= res: June 30th, 2005
      Average Customer= Review: 3D"5 Based on 1,768 reviews. Write a review.
      <= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
      Microsoft Windows XP= Professional or Longhorn Edition
      Microsoft
      Choose:
       

      <= a href=3Dhttp://yoursmartware.com/?F>

      $279.00
      Price:$49.99
      You Save= :$229.01 (85%)



      Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
      Media: CD-ROM / Download

      System = requirements  |  Acces= sories  |  Other Versi= ons

      Features:=

      • Designed for businesses o= f all sizes
      • Manage digital p= ictures, music, video, DVDs, and more
      • More security with the ability to encrypt files and folders
      • Built-in voice, video, and insta= nt messaging support
      • Integra= tion with Windows servers and management solutions

      Sales Rank: #2
      Shipping: In= ternational/US or via instant download
      Date Coupon Expires: Jun= e 30th, 2005
      Average Customer Review:= 3D"5 Based on 868 reviews. Writ= e a review.

      Adobe Photoshop CS2 V 9.0
      Adobe
      Choose:
       

      List Price: $599.00
      Price:$69.99
      You Save:$529.01 (90%)


      Availability: Available for INSTANT download!
      Coupon Code:= ISe229
      Media: CD-ROM / Download

      System requirements&nb= sp; |  Accessories  |&= nbsp; Other Versions

      <= p>Features:

        Customized workspace; save personalized wor= kspace and tool settings; create customized shortcuts
      • Unparalleled efficiency--automate production ta= sks with built-in or customized scripts
      • Improved file management, new design possibilities, and a more= intuitive way to create for the Web
      • Support for 16-bit images, digital camera raw data, and non-squar= e pixels
      • Create or modify ph= otos using painting, drawing, and retouching tools

      Sales Rank: #3
      Shipping:= International/US or via instant download
      Date Coupon Expires:<= /b> June 30th, 2005
      Average Customer Revi= ew: 3D"5 Based on 498 reviews. Write a review.

    ----Sr10CfUxltBGcq9-- From rtg-dir-bounces@ietf.org Mon Jun 13 10:08:27 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15509 for ; Mon, 13 Jun 2005 10:08:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhpyN-0007Au-PF for rtg-dir-archive@ietf.org; Mon, 13 Jun 2005 10:31:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhpbb-0004hx-CF; Mon, 13 Jun 2005 10:07:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhpbZ-0004hn-7v for rtg-dir@megatron.ietf.org; Mon, 13 Jun 2005 10:07:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15433 for ; Mon, 13 Jun 2005 10:07:55 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhpxq-00079x-An for rtg-dir@ietf.org; Mon, 13 Jun 2005 10:30:59 -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 j5DE7TBm057469; Mon, 13 Jun 2005 07:07:33 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.28.4.239]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j5DE7Se57843; Mon, 13 Jun 2005 07:07:28 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20050613095716.037455d8@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 13 Jun 2005 10:07:26 -0400 To: Alex Zinin From: Ross Callon In-Reply-To: <13610704709.20050603121737@psg.com> References: <5.0.0.25.2.20050602223948.049834c8@zircon.juniper.net> <177295214.20050601221810@psg.com> <5.0.0.25.2.20050602223948.049834c8@zircon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: rcallon@juniper.net, rtg-dir@ietf.org, riw@cisco.com Subject: Re: rtg-dir review: ross, russ: draft-ietf-mpls-lsp-ping-09.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 On the most part the document looks quite good. My one substantial issue is the lack of a defined mechanism for authentication in draft-ietf-mpls-lsp-ping-09.txt. One point might be the computational cost of this: However, this would seem to be just as much an issue for BFD, which is after all supposed to be do-able at a very rapid rate and which does authentication. Also, LSP Ping is potentially useful at an "interact with a human trying to debug things" rate, which would imply that authentication should be fast enough for at least this common case. Also, making authentication work at a very high rate is an implementation issue, and is possible (at least if planned for in future products). The most obvious authentication methods (password, MD5, SHA1) are defined for BFD (see section 6.6 of draft-ietf-bfd-base-02.txt), and probably should also be available for LSP Ping. Other points: The security considerations section does discuss authentication. For example: "Authentication will help reduce the number of seemingly valid MPLS echo requests, and thus cut down the Denial of Service attacks;" First of all, I don't see how you can state that authentication could be used for this purpose, when there is no authentication defined. Secondly, authentication only helps prevent DoS for those parts of the system which are *after* the packets with bad authentication are discarded. For whatever part of the system has to actually check the authentication and discard bad packets, authentication can make DoS *worse*, due to the fact that checking authentication itself requires work. Whether this is a win or a loss for the specific case of DoS attacks therefore depends upon a variety of details (such as whether checking the authentication is done in software on a central CPU, or is done in some sort of dedicated hardware). Possibly the security section should explain this. Also there are other more clearly positive advantages of authentication, such as preventing a hacker from initiating a ping, which also might be worth discussing in the security section. Thanks, Ross At 12:17 PM 6/3/2005 -0700, Alex Zinin wrote: >Ross, > > Thanks. Within a week should be fine. > >-- >Alex >http://www.psg.com/~zinin > >Thursday, June 2, 2005, 7:43:35 PM, Ross Callon wrote: > > Okay. I can look at this. > > > When do you want the review? > > > thanks, Ross > > > At 10:18 PM 6/1/2005 -0700, Alex Zinin wrote: > >>skill-specific: Ross (MPLS) > >>round-robin: Russ > >> > >>This one is out of the MPLS WG, on its way to the IETF LC, which I'm > >>starting. > >> > >>http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-09.txt > >> > >> > Abstract > >> > > >> > This document describes a simple and efficient mechanism that can be > >> > used to detect data plane failures in Multi-Protocol Label Switching > >> > (MPLS) Label Switched Paths (LSPs). There are two parts to this > >> > document: information carried in an MPLS "echo request" and "echo > >> > reply" for the purposes of fault detection and isolation; and > >> > mechanisms for reliably sending the echo reply. > >> > >>Thank you. > >>-- > >>Alex > >>http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Tue Jun 14 02:34:57 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14093 for ; Tue, 14 Jun 2005 02:34:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di5NB-0006IM-GO for rtg-dir-archive@ietf.org; Tue, 14 Jun 2005 02:58:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di50U-0004jp-DO; Tue, 14 Jun 2005 02:34:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di50S-0004jI-Td for rtg-dir@megatron.ietf.org; Tue, 14 Jun 2005 02:34:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14084 for ; Tue, 14 Jun 2005 02:34:39 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di5Mt-0006I2-TB for rtg-dir@ietf.org; Tue, 14 Jun 2005 02:57:52 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Di50P-00050m-0F; Tue, 14 Jun 2005 06:34:37 +0000 Date: Mon, 13 Jun 2005 23:34:33 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1847300379.20050613233433@psg.com> To: Ross Callon In-Reply-To: <5.0.0.25.2.20050613095716.037455d8@zircon.juniper.net> References: <5.0.0.25.2.20050602223948.049834c8@zircon.juniper.net> <177295214.20050601221810@psg.com> <5.0.0.25.2.20050602223948.049834c8@zircon.juniper.net> <5.0.0.25.2.20050613095716.037455d8@zircon.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, riw@cisco.com Subject: Re: rtg-dir review: ross, russ: draft-ietf-mpls-lsp-ping-09.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Ross, Russ- Thanks for reviewing, guys. I'll send your comments to the WG cc'ing the rtg-dir. Ross, regarding lack of authentication per se, I can see how an argument can be made that this is not worse than what the current IP ping/tracert have. I does seem strange that the doc tells what the authentication can do while there is none. -- Alex http://www.psg.com/~zinin Monday, June 13, 2005, 7:07:26 AM, Ross Callon wrote: > On the most part the document looks quite good. My one substantial > issue is the lack of a defined mechanism for authentication in > draft-ietf-mpls-lsp-ping-09.txt. > One point might be the computational cost of this: However, this would > seem to be just as much an issue for BFD, which is after all supposed > to be do-able at a very rapid rate and which does authentication. Also, > LSP Ping is potentially useful at an "interact with a human trying to > debug things" rate, which would imply that authentication should be fast > enough for at least this common case. Also, making authentication > work at a very high rate is an implementation issue, and is possible (at > least if planned for in future products). > The most obvious authentication methods (password, MD5, SHA1) are > defined for BFD (see section 6.6 of draft-ietf-bfd-base-02.txt), and probably > should also be available for LSP Ping. > Other points: The security considerations section does discuss > authentication. For example: > "Authentication will help reduce the number of seemingly valid > MPLS echo requests, and thus cut down the Denial of Service > attacks;" > First of all, I don't see how you can state that authentication could > be used for this purpose, when there is no authentication defined. > Secondly, authentication only helps prevent DoS for those parts of > the system which are *after* the packets with bad authentication are > discarded. For whatever part of the system has to actually check the > authentication and discard bad packets, authentication can make > DoS *worse*, due to the fact that checking authentication itself > requires work. Whether this is a win or a loss for the specific case of > DoS attacks therefore depends upon a variety of details (such as > whether checking the authentication is done in software on a central > CPU, or is done in some sort of dedicated hardware). Possibly the > security section should explain this. Also there are other more clearly > positive advantages of authentication, such as preventing a hacker > from initiating a ping, which also might be worth discussing in the > security section. > Thanks, Ross > At 12:17 PM 6/3/2005 -0700, Alex Zinin wrote: >>Ross, >> >> Thanks. Within a week should be fine. >> >>-- >>Alex >>http://www.psg.com/~zinin >> >>Thursday, June 2, 2005, 7:43:35 PM, Ross Callon wrote: >> > Okay. I can look at this. >> >> > When do you want the review? >> >> > thanks, Ross >> >> > At 10:18 PM 6/1/2005 -0700, Alex Zinin wrote: >> >>skill-specific: Ross (MPLS) >> >>round-robin: Russ >> >> >> >>This one is out of the MPLS WG, on its way to the IETF LC, which I'm >> >>starting. >> >> >> >>http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-09.txt >> >> >> >> > Abstract >> >> > >> >> > This document describes a simple and efficient mechanism that can be >> >> > used to detect data plane failures in Multi-Protocol Label Switching >> >> > (MPLS) Label Switched Paths (LSPs). There are two parts to this >> >> > document: information carried in an MPLS "echo request" and "echo >> >> > reply" for the purposes of fault detection and isolation; and >> >> > mechanisms for reliably sending the echo reply. >> >> >> >>Thank you. >> >>-- >> >>Alex >> >>http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Tue Jun 14 07:37:32 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05257 for ; Tue, 14 Jun 2005 07:37:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiA62-0002oc-Nm for rtg-dir-archive@ietf.org; Tue, 14 Jun 2005 08:00:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di9j8-0005Z1-3R; Tue, 14 Jun 2005 07:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di9j7-0005Yw-1k for rtg-dir@megatron.ietf.org; Tue, 14 Jun 2005 07:37:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05227 for ; Tue, 14 Jun 2005 07:37:04 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiA5X-0002nv-2I for rtg-dir@ietf.org; Tue, 14 Jun 2005 08:00:19 -0400 Received: from chello062178148169.6.14.vie.surfer.at ([62.178.148.169]) by mx2.foretec.com with smtp (Exim 4.24) id 1Di9iq-0007Ex-95 for rtg-dir@ietf.org; Tue, 14 Jun 2005 07:36:51 -0400 Received: from zMp@localhost by F5Oe.int (8.11.6/8.11.6); Tue, 14 Jun 2005 13:17:03 -0400 Message-ID: <7HiEZFfVA7G9D56tvq6zrju@actors.co.uk> From: "Elena Shepard" To: rtg-dir@ietf.org Date: Tue, 14 Jun 2005 15:13:03 -0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: DenaWalsh@triboluminescence.com Content-Type: multipart/mixed; boundary="--Hsj2AmtTpRVJVHH" X-Spam-Score: 2.5 (++) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Subject: Windows XP Pro $49.95 XP X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Elena Shepard List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.5 (++) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac smYm ----Hsj2AmtTpRVJVHH Content-Type: text/html; Content-Transfer-Encoding: quoted-printable E
    Opt-in Email Special Offer &n= bsp;   unsubscribe me
    <= tbody><= /td>
    =
    SEARCH

    <= td vAlign=3Dbottom>

    TOP 10 NEW TITLES

    <= td width=3D4>  Microsoft=

     = ON SALE NOW!

     1 Office Pro 2003
     2 Windows XP Pro
     3 Adobe Creative Suite Premium
    &nbs= p;4 Norton Antivirus 2005
     5 Flash MX 2004
     6 Corel Draw 12
     7 Adobe Acrobat 7.0
     8 Windows 2003 Server
     9 Alias Maya 6 Wavefrt
    10 Adobe Premiere
     = See more by this manufacturer=
      
    &= nbsp;  Apple Software
      Customers also bought
       these oth= er items...



    		Microsoft Office Professional= Edition *2003*
    Microsoft
    <= td vAlign=3Dtop noWrap>
    Choose:
    <= tr>
     
    List Price:$899.00
    Price:$69.99<= /b>
    You Save:$830.01 (92= %)



    Availability:= Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requirements  |  Accessories  |  Other Versions

    Featur= es:

    • Analyze and manage business information using Access databases
    • Exchange data with other systems u= sing enhanced XML technology
    • Control information sharing rules with enhanced IRM technology
    • Easy-to-use wizards to create e-mail n= ewsletters and printed marketing materials
    • = More than 20 preformatted business reports
      • Sales Rank: #1
      Ship= ping: International/US or via instant download
      Date Coupon Expi= res: June 30th, 2005
      Average Customer= Review: 3D"5 Based on 1,768 reviews. Write a review.
      <= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
      Microsoft Windows XP= Professional or Longhorn Edition
      Microsoft
      Choose:
       

      <= a href=3Dhttp://superhrunsoft.com/?Z>

      $279.00
      Price:$49.99
      You Save= :$229.01 (85%)



      Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
      Media: CD-ROM / Download

      System = requirements  |  Acces= sories  |  Other Versi= ons

      Features:=

      • Designed for businesses o= f all sizes
      • Manage digital p= ictures, music, video, DVDs, and more
      • More security with the ability to encrypt files and folders
      • Built-in voice, video, and insta= nt messaging support
      • Integra= tion with Windows servers and management solutions

      Sales Rank: #2
      Shipping: In= ternational/US or via instant download
      Date Coupon Expires: Jun= e 30th, 2005
      Average Customer Review:= 3D"5 Based on 868 reviews. Writ= e a review.

      Adobe Photoshop CS2 V 9.0
      Adobe
      Choose:
       

      List Price: $599.00
      Price:$69.99
      You Save:$529.01 (90%)


      Availability: Available for INSTANT download!
      Coupon Code:= ISe229
      Media: CD-ROM / Download

      System requirements&nb= sp; |  Accessories  |&= nbsp; Other Versions

      <= p>Features:

        Customized workspace; save personalized wor= kspace and tool settings; create customized shortcuts
      • Unparalleled efficiency--automate production ta= sks with built-in or customized scripts
      • Improved file management, new design possibilities, and a more= intuitive way to create for the Web
      • Support for 16-bit images, digital camera raw data, and non-squar= e pixels
      • Create or modify ph= otos using painting, drawing, and retouching tools

      Sales Rank: #3
      Shipping:= International/US or via instant download
      Date Coupon Expires:<= /b> June 30th, 2005
      Average Customer Revi= ew: 3D"5 Based on 498 reviews. Write a review.

    ----Hsj2AmtTpRVJVHH-- From rtg-dir-bounces@ietf.org Wed Jun 15 09:13:37 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13552 for ; Wed, 15 Jun 2005 09:13:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiY4o-0007NE-Dp for rtg-dir-archive@ietf.org; Wed, 15 Jun 2005 09:37:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiXhO-0003Ak-MR; Wed, 15 Jun 2005 09:12:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiXhM-00039u-KA for rtg-dir@megatron.ietf.org; Wed, 15 Jun 2005 09:12:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13496 for ; Wed, 15 Jun 2005 09:12:51 -0400 (EDT) Received: from judges.dnsaccess.info ([64.157.121.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiY43-0007MU-W8 for rtg-dir@ietf.org; Wed, 15 Jun 2005 09:36:20 -0400 Received: from apache by judges.dnsaccess.info with local (Exim 4.42) id 1DiYgv-0005UK-Rj for rtg-dir@ietf.org; Wed, 15 Jun 2005 09:16:29 -0500 To: rtg-dir@ietf.org From: Paypal Account Review Department MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Wed, 15 Jun 2005 09:16:29 -0500 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA13496 Subject: Notification of Limited Account Access (Routing Code: PP-091-233-629) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Untitled Document =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
    =A0
    As part of our security measures,= we regularly=20 screen activity in the PayPal system. We recently noticed the follo= wing=20 issue on your account:
    =20

    We recently received a report of unauthorized = credit=20 card use associated with this account. As a precaution, we have l= imited=20 access to your PayPal account in order to protect against future = unauthorized=20 transactions.

    =A0=20

    Case ID Number: PP-091-233-629

    For your protection, we have limi= ted access=20 to your account until additional security measures can be completed= . We=20 apologize for any inconvenience this may cause.
    =20

    To review your account and some or all of the = information=20 that PayPal used to make its decision to limit your account acces= s, please=20 visit the Resolution Center by following the link below:

    https://www.paypal.com/cgi-bin/webscr?cmd=3Dlogin-run= =20
    If, after reviewing your account = information,=20 you seek further clarification regarding your account access, pleas= e contact=20 PayPal by visiting the Help Center and clicking "Contact Us"=
    =20


    We thank you for your prompt attention to this matter. Please und= erstand=20 that this is a security measure intended to help protect you and = your=20 account. We apologize for any inconvenience.

    =20

    Sincerely,
    PayPal Account Review Department

    =A0

    PayPal Email ID PP545
    =20

    Accounts Management as outlined in our User Ma= nagement=20 , Paypal will
    periodically send you information about site ch= anges and=20 enhancements
    =20

    Visit our Privacy Policy and User Agreement if= you have=20 any questions :
    http://www.paypal.com/cgi-bin/web= scr?cmd=3Dp/gen/ua/policy_privacy-outside=20

    From rtg-dir-bounces@ietf.org Thu Jun 16 22:03:19 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04911 for ; Thu, 16 Jun 2005 22:03:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj6Zb-0006nl-Rj for rtg-dir-archive@ietf.org; Thu, 16 Jun 2005 22:27:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj69t-0007LC-Mu; Thu, 16 Jun 2005 22:00:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj69r-0007Kk-QX; Thu, 16 Jun 2005 22:00:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04709; Thu, 16 Jun 2005 22:00:24 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj6Wl-0006cY-Ul; Thu, 16 Jun 2005 22:24:16 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dj69j-000DZ8-Ag; Fri, 17 Jun 2005 02:00:27 +0000 Date: Thu, 16 Jun 2005 19:00:25 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <349058829.20050616190025@psg.com> To: routing-discussion@ietf.org In-Reply-To: <200506151852.OAA14446@ietf.org> References: <200506151852.OAA14446@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Fwd: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit Since the second BOF on this topic was inconclusive regarding community support, the IESG is reevaluating the community consensus on whether a WG should be formed or not. If you have input on this, positive or negative, please send it to iesg@ietf.org. -- Alex http://www.psg.com/~zinin This is a forwarded message From: The IESG To: IETF-Announce@ietf.org Cc: rbridge@postel.org Date: Wednesday, June 15, 2005, 11:52:27 AM Subject: WG Review: Transparent Interconnection of Lots of Links (trill) ===8<==============Original message text=============== A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by June 22nd. +++ Transparent Interconnection of Lots of Links (trill) ===================================================== Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Mark Townsley Margaret Wasserman Internet Area Advisor: Mark Townsley Technical Advisor: Bill Fenner Secretary(ies): TBD Mailing Lists: General Discussion: rbridge@postel.org To Subscribe: http://www.postel.org/mailman/listinfo/rbridge Archive: http://www.postel.org/pipermail/rbridge Description of Working Group: The TRILL WG will design a solution for shortest-path frame routing in multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies, using the link-state routing protocol technology. This work will initially be based on draft-perlman-rbridge-03.txt. The design should have the following properties: - Minimal or no configuration required - Load-splitting among multiple paths - Routing loop mitigation (possibly through a TTL field) - Support of multiple points of attachment - Support for broadcast and multicast - No significant service delay after attachment - No less secure than existing bridged solutions Any changes introduced to the Ethernet service model should be analyzed and clearly documented. To ensure compatibility with IEEE VLANs and the Ethernet service model, the WG will request an IEEE liaison relationship with IEEE 802.1. It is not an explicit requirement that the solution should be able to run on existing IP routers or IEEE 802 switches as a software upgrade. However, the working group should take deployment considerations into account, to ensure that the solution can interwork with bridges in a flexible manner (e.g., to allow incremental deployment into LANs that currently use 802.1D bridges). The TRILL working will work with the L2VPN WG and IEEE 802.1 to develop interworking between TRILL and 802.1D bridges at the edge, such that a bridged sub-cloud could be attached to TRILL devices in more than one place for redundancy. The solution must not interfere with the end-to-end transparency of the Internet architecture or with end-to-end congestion control and QOS mechanisms. The WG will work on the following items: (1) Develop a problem statement and architecture document that describes the high-level TRILL architecture, discusses the scalability of that architecture, describe the threat model and security impacts of the TRILL solution, and describes the expected impacts (if any) of the TRILL solution on the Ethernet service model. (2) Define the requirements for a TRILL-capable routing protocol, and select one or more existing routing protocols that could meet those requirements. (3) Work with the appropriate Routing area working group to extend an existing routing protocol to meet the TRILL working group requirements. Note: The TRILL working group is not chartered to develop a new routing protocol or to make substantial modifications to an existing routing protocol. If, during the requirements definition and selection phase, the TRILL working group discovers that no existing routing protocol will meet their needs, we will need to re-assess the TRILL WG charter to determine how/if this work should proceed. (4) Produce a (set of) TRILL specification(s) for standards track publication that defines what information must be carried in an encapsulation header for data packets, and determine how to map that information to various link types (only IEEE 802 links initially) The TRILL working group is chartered to undertake all of the above tasks and may begin work on more than one of these tasks in parallel. However, the problem statement and architecture document should be completed before the details of the base protocol are finalized, while there is still time to consider changes to the architecture without major impacts on established specifications. Goals and Milestones: Aug 05 Accept Problem statement and architecture document as a WG work item Aug 05 Accept base protocol specification as a WG document Oct 05 Accept routing protocol requirements as a WG work item Dec 05 Submit problem statement and architecture document to the IESG for publication as an Informational RFC Mar 06 Submit routing protocol requirements to the IESG for publication as an Informational RFC Mar 06 Choose routing protocol(s) that can meet the requirements. Apr 06 Start work with routing area WG(s) to undertake TRILL extensions. Sep 06 Base protocol specification submitted to the IESG for publication as a Proposed Standard RFC Dec 06 Re-charter or shut down the WG _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ===8<===========End of original message text=========== From rtg-dir-bounces@ietf.org Sun Jun 19 10:05:32 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06590 for ; Sun, 19 Jun 2005 10:05:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dk0o4-0005Wq-GN for rtg-dir-archive@ietf.org; Sun, 19 Jun 2005 10:29:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk0ON-0002O5-MU; Sun, 19 Jun 2005 10:03:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk0OL-0002O0-HC for rtg-dir@megatron.ietf.org; Sun, 19 Jun 2005 10:03:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06331 for ; Sun, 19 Jun 2005 10:03:15 -0400 (EDT) Received: from [222.96.207.220] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dk0lq-0005Tq-7D for rtg-dir@ietf.org; Sun, 19 Jun 2005 10:27:36 -0400 Received: from CWh@localhost by jkMD.int (8.11.6/8.11.6); Sun, 19 Jun 2005 11:18:18 -0400 Message-ID: From: "German Dotson" To: rtg-dir@ietf.org Date: Sun, 19 Jun 2005 16:19:18 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: EddyFinn@obligor.com Content-Type: multipart/mixed; boundary="--lJn4K6FcpZ8YXte3Z" X-Spam-Score: 3.9 (+++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: agentx-web-archive@ietf.org, dcom@ietf.org, aids@ietf.org Subject: O Casino Spring Fling Competition :) FRE:5yzyUW2 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: German Dotson List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.9 (+++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 yszM ----lJn4K6FcpZ8YXte3Z Content-Type: text/html; Content-Transfer-Encoding: quoted-printable bbzaddCB3QdnnE9N

    Welcome to MS@Casin0 - a REVOLUTION in = CYBER GAMlNG!
    MS@Casin0 establishes a turning point in Casin0 history by
    uniquely allowing players worldwide to play as dealer thus
    receiving some of the most favorable odds normally reserved for
    the Casin0.

    MS@Casin0 offers popular games, including Black-jack, Roullette,
    Sl0t Machines and Video P0ker all featuring unmatched graphics and sounds.=

    You may play with REAL M0NEY or just play for Fun (no bank details needed)=

    Questions and Answers
    --------------------

    Q: MS@Casin0 offers matchless credibility and it's easy to check. How ? A: Robert as Player and Graham as Dealer enter one of the games. Once the = game
    is over, they verify that one's losing sum is the other's winning sum.
    =
    Q: MS@Casin0 offers the highest payouts available. How is that possible? A: Payouts are constant in games like Blackjack and Roulette (and for all<= br> games with the same rules). MS@Casin0's unique concept allows players to become the Dealer, which improves their winning odds, thus B00STING
    their payout rates.

    The top daily player (determined at 23:59) gets $200 bonus!

    Winnings generated from playing as Dealer are also accumulated.

    The scoreboard will be updated every hour.

    Visit our site http://4highrollers.net -try your luck & NO DEP0= SIT REQUIRED !

    Best regards,

    Riley Quick
    Casin0 Manager

    ----lJn4K6FcpZ8YXte3Z-- From rtg-dir-bounces@ietf.org Sun Jun 19 13:58:40 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22953 for ; Sun, 19 Jun 2005 13:58:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dk4Rh-0001uO-Cg for rtg-dir-archive@ietf.org; Sun, 19 Jun 2005 14:23:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk42A-0005nC-Ck; Sun, 19 Jun 2005 13:56:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk429-0005mc-9X; Sun, 19 Jun 2005 13:56:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22722; Sun, 19 Jun 2005 13:56:35 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dk4Pg-0001rq-P3; Sun, 19 Jun 2005 14:20:58 -0400 Received: from c-67-166-81-203.hsd1.or.comcast.net ([67.166.81.203]) by mx2.foretec.com with smtp (Exim 4.24) id 1Dk421-0007yP-3r; Sun, 19 Jun 2005 13:56:30 -0400 Received: from moys.biz by discussxht (no.2zx) id iucgenhitx with SMTP; Sun, 19 Jun 2005 14:49:12 -0400 Message-ID: <20041rtaqd3.ED8DA244AE@mailhost1q.lists.techtarget.com> Date: Sun, 19 Jun 2005 11:49:12 -0700 From: "Earnestine Quintana" To: rtg-dir@ietf.org X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: saad@ietf.org, saad-admin@ietf.org, s@ietf.org, rtgwg@ietf.org, rtgwg-web-archive@ietf.org, rtgwg-admin@ietf.org, s.o.f.t.w.a.r.e@ietf.org, rv@ietf.org Subject: Dont miss out on low rates X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.4 (++++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.mtg1-23.com/signs.asp Best Regards, Aldo Bond to be remov(ed: http://www.mtg1-23.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Sun Jun 19 21:12:32 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20627 for ; Sun, 19 Jun 2005 21:12:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkBDd-0002MG-9e for rtg-dir-archive@ietf.org; Sun, 19 Jun 2005 21:36:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkApZ-0001iz-1z; Sun, 19 Jun 2005 21:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkApY-0001iu-76 for rtg-dir@megatron.ietf.org; Sun, 19 Jun 2005 21:12:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20621 for ; Sun, 19 Jun 2005 21:12:02 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkBDA-0002Lw-49 for rtg-dir@ietf.org; Sun, 19 Jun 2005 21:36:28 -0400 Received: from c-24-14-168-77.hsd1.il.comcast.net ([24.14.168.77]) by mx2.foretec.com with smtp (Exim 4.24) id 1DkApQ-0007xs-Ss for rtg-dir@ietf.org; Sun, 19 Jun 2005 21:11:58 -0400 Received: from 9bns@localhost by 61n.int (8.11.6/8.11.6); Sun, 19 Jun 2005 19:41:32 -0700 Message-ID: From: "Kate Ventura" To: rtg-dir@ietf.org Date: Sun, 19 Jun 2005 22:41:32 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: LyndaSemel@innovations.com Content-Type: multipart/mixed; boundary="--ZTLx7iC5yuPqHvaX" X-Spam-Score: 1.7 (+) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: agentx-web-archive@ietf.org, dcom@ietf.org, aids@ietf.org Subject: Microsoft Special Deals X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kate Ventura List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.7 (+) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 7d8 ----ZTLx7iC5yuPqHvaX Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 0
    Opt-in Email Special Offer &n= bsp;   unsubscribe me=
    = = List Price:
    SEARCH

    TOP 10 NEW TITLES

    = =

     = ON SALE NOW!

     1 Office Pro 2003
     2 W= indows XP Pro
     3 Adob= e Creative Suite Premium
     4<= a href=3Dhttp://obscureware.com/?9> Norton Antivirus 2005
     = 5 Flash MX 2004
     6 Corel Draw 12
     7= Adobe Acrobat 7.0
     8 Windows 2003 Server
     = ;9 Alias Maya 6 Wavefrt
    &= nbsp;10 Adobe Premiere
    &= nbsp; See more by this manufacturer
       Microsoft
       Apple Softwar= e
      Customers also b= ought
       these other items...



    		Microsoft Office Professional Edition *2003*
    Microsoft
    Choose:
     
    $899.00
    Price:$69.99
    You Save= :$830.01 (92%)



    Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
    Media: CD-ROM / Download

    System re= quirements  |  Accessori= es  |  Other Versions

    Features:

    • Analyze and manage business inform= ation using Access databases
    • Exchange data with other systems using enhanced XML technology
    • Control information sharing rules with= enhanced IRM technology
    • Eas= y-to-use wizards to create e-mail newsletters and printed marketing materi= als
    • More than 20 preformatte= d business reports
    Sales Ra= nk: #1
    Shipping: International/US or via insta= nt download
    Date Coupon Expires: June 30th, 2005
    Average Customer Review: 3D"5 Based on 1,768 re= views.     Write a review.
    Microsoft Windows XP Professional or Longhorn Edition
    <= span class=3Dsmall>Microsoft
    Choose:
     = ;

    = = =
    List Price:$279.0= 0
    Price:$49.99
    You Save:$229.01 (85%)



    Availability: Available for = INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM = / Download

    System requirements  |  Accessories  |  Other Versions

    Features:

    • Designed for = businesses of all sizes
    • Mana= ge digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt files and f= olders
    • Built-in voice, video= , and instant messaging support
    • Integration with Windows servers and management solutions

      • Sales Rank: #2
      Shippin= g: International/US or via instant download
      Date Coupon Expires= : June 30th, 2005
      Average Customer Re= view: 3D"5 Based on 868 reviews. Write a review.

      Adobe Photoshop CS2 V 9.0
      = Adobe
      =
      Choose:
       

      List Price:<= /td> $599.00
      Price:$69.99
      You Save:$529.01 (90%)


      Availability: Available for INSTANT download!
      Coupon Code:= ISe229
      Media: CD-ROM / Download

      System requirements = ; |  Accessories  | = ; Other Versions

      <= font size=3D1>Features:

      • Customized workspace; save personalized workspace= and tool settings; create customized shortcuts
      • Unparalleled efficiency--automate production tasks wi= th built-in or customized scripts
      • Improved file management, new design possibilities, and a more intui= tive way to create for the Web
      • Support for 16-bit images, digital camera raw data, and non-square pixel= s
      • Create or modify photos us= ing painting, drawing, and retouching tools

      Sales Rank: #3
      Shipping: In= ternational/US or via instant download
      Date Coupon Expires: Jun= e 30th, 2005
      Average Customer Review:= 3D"5 Based on 498 reviews. Write = a review.

    ----ZTLx7iC5yuPqHvaX-- From rtg-dir-bounces@ietf.org Mon Jun 20 06:38:30 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13497 for ; Mon, 20 Jun 2005 06:38:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkK3S-0005Hj-GR for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 07:03:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkJex-0006KK-RP; Mon, 20 Jun 2005 06:37:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkJew-0006J9-50; Mon, 20 Jun 2005 06:37:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13359; Mon, 20 Jun 2005 06:37:39 -0400 (EDT) Message-Id: <200506201037.GAA13359@ietf.org> Received: from pool-70-16-136-57.phil.east.verizon.net ([70.16.136.57]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DkK2c-0005Fz-19; Mon, 20 Jun 2005 07:02:11 -0400 FCC: mailbox://kmknekn@yahoo.com/Sent X-Identity-Key: id1 Date: Mon, 20 Jun 2005 15:37:25 +0400 From: Annabelle Reagan X-Accept-Language: en-us, en MIME-Version: 1.0 To: rtg-dir@ietf.org Content-Type: multipart/related; boundary="------------040602050204070101010000" X-Spam-Score: 3.0 (+++) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Subject: Hi X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.8 (+++) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 This is a multi-part message in MIME format. --------------040602050204070101010000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

    Are you sure? i'm sorry Mau I ask Look Smart

    I'd like to make Net

    --------------040602050204070101010000 Content-Type: image/gif; name="tar.GIF" Content-ID: Content-Disposition: inline; filename="tar.GIF" Content-Transfer-Encoding: base64 R0lGODlhhgLoAfBRAAUFAP///yH5BAQAABAALAAAAAB/AuMBAAL/jI+py+0Po5y02ouz3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qDQDA9gsOi8dkRbdbTqvX7Pbu fHbL5/S6vQKH3/f8vj+cl/c3SFhoOBQYeLjI2OiIkpj4OElZadkQGXm5ydk5qMml6DlKWkoGeiBpusra +oSKoAom6yAaI5hii6cXgCuT+cqb4ZtDPCz8SZugnMVs5rxiTAI7gSvtkonGdC1BbcO9G0fovazbbP5M rgL+kW1hjQyTra3E/gBcHI9hP6dezh8MXax56cSl4mUQnsGCXnrRG6gPIj6JDx2KMyZQDzGB/wfdUWz4 z4tCbSAtLvwYjmTFjg2vCUu4kKM5XwjZAWzjj+FKKhpPUgwVExZBky1rXvQIlCPRpCWJBj0KU9nQiQyZ ssToUZBKqf5GOjO68yU9sFhp0dwqM2KdnAugRem50+rSq2fdeZU7DyTSkEWfyrrLtC6+vT/nOhWbVdVe wlcDoyPbNipLx35tjTwc8aYatgzcBhTps7FhwHdJQ54LmK9c1KdNQ0UL+nVTvK1ry47jGnZk2asnG5bY cXLuvrot0g6rVg5nTEqdwJ0tWjDx6VaHHy/u8jRr3tuxQ05d2Hr36bhtF1c9HgI3o0mvU09vfndcN8tr Nd9Wfr5N89TF+//PrN1/3FkHXnT8uReYgQMCuGBoKMm31IHpYaYXWPJBR59nDql3XxJaOfibTqKUJuFw XyU3oYkjfjcUel4pJiFlZJ3Y4Hy9hRThbSsmpkuHmonBFoqOTYEYhh8WCQqJNb73YkYoCggbjLzldaF7 UnpX2ZXkiNcZOM/FRt6Og5nl2Y+zlJmThkcU2WV+UY05ZYn80WgjlGES2GJ4M4rJJDJUUhgal1Uyh0ah YMqoY5NNpWljGoxSJeJbb7ZpKJKE6mYnghGklmmIerqJYVUTDgqel0IqeJ5O9hm6oXaiXhhPV42e4lZe dXZIRJ6fjiUnqJp26qKlKfaKqauo9rlkb8D/7vreoJe2euiwyQaaVqhlyGqrtWoiwpim0hab7LfNMnvs r8SCOW654nq7rqftqrrql1jO219c1fYDTbZKbQuEraQKi2e4y6rbrp2SFGjuklqSOyrD653qVMQJ02tS e+4al2G1+j5s5ht/BvsmsuBSXDCD53XKqV3GTtzsVH6e+y936HEor7oCWtwxrU5urA6/PUgHq2Uwoxzj R0ILXPSXDdPFp7K+/jYwy87eI2zJNVbsbs5E0snzlrj+XDVfPU6kJJwkA3rpTGQHCCnI+bbYLcGIGu2g oIiGCjTTWVYN6s6znvNY1/5GikTesGKst8M8no1ZvNJQVSqZMmNLjVBF/1MmIt6XA6p5yGKvZLlkFFJq rRbeCK5v0IWHXZVPak/+tN247ltWqhLr/fKTbd9+d7oJHp42u3cHfyPvD4qG9cXFnxk46ql/7godcWOz e/SLVO5814Rbj9PX0XjPPR/YZy849OGfj771oZOPuvnpvw8/J+Oz377R8d+PfyNB0j+46vn/D8A9MAp3 5OsG+AKIwARWYX+LYt8FfKbAyJjgbxwqAQU9cMEuqS+DHvNRRei3jwO+4IOlYwMHd9GBE1ajhCBQ4UAk uCYWzsCFOFjOSUAYQq19rxzSKwkNNwWdW73QgPYZ4jpkeBAjsuCH+FlCfW7owGPoMBcN7KESRYCcIv8m kYjMueIJOPgQJobwWkjsoGagWEANQLAFJIRIKJbhm2fAMXkbeuOz6pgKi0HrX4ijI6+CoxKMZecofRSk yYrSRyG9DHGsigUfYfLGp+BxN6tZJCSDEskwNlKOjvRjhSiVST1Cqy80SyEEK7NCiFFtihOsIhfsOJYt 2ksvsPykHWEYyFfWcStaBEotb/nHXfJSmL00ZB6J2cXgIFM/iPTlMmmpQWXmkpDC1BwPZVmhZlKzmr8s pBG1actJXpORzTRkOdtyyxyaaW/IqR4F1nhEZuSyF8A0Ei01Wc9oIpOewWwUPkOJzST+s5/a8mE4A5rM fAaTk9185jFhmM99blL/nFdc6D73iNA//hOioBmiRcdp0Xl+VJ8PhCc75VWfVapyia5kzTHflseBHtR+ eETXPEmqUYMqVKc1PSdDe2qgYub0YR61pUgTClSJdnSLOD3oTSc6zU9ulKFLbSgzmSpTrBYURDTL2Um1 Z0pWYtGVIhUJU6lGz0mWlaQv9Gk6IQrUrALUqm5VIkEbCtecArGoCG2VUI1aTqiWbqFynatDDSvEc65V nyEN7Ez5WlIROrN3zwvrSql4zbU+VoOKdSxbBfrW0I4zrjzVa19v+tO7XjS1UmVhYTX714y21oucbGw6 BUtXtRY0ra+1ZkRzK1q8plKHX+VZCyU7DbJ2drSx/00qiGbpRX/y9LDcrK5qmyrb4N4WsHtN6kWl+01w yraET3UsOD3rXFI2l6C+1e1vR9rX4V42HQQEazuQO1aQbhJ0usORG2+FST2V0rux2m8jCctM9BpnmJQk sO42Wt4BqxbBVS2IG0VZKYH2FpCDbSAJK6xf/753q2mVL1eBmE0cHlesHrKDGL9QxhC8+KdnVeNgdSbW RKXxvixe01pivBl5AJmLzB3jPcaQ0l7yr8c0hfGQFzjfzTxZnVOuII3feaoZFyHJtaDbjlcc5QiKecxf hCeKl6xl93UPs3C1xImxTAMwVrnG4zCzAdE8Z8elOQhChIQ95ZfnIlMPhVcuJv+U32ziPX8uisllcpzn rOg20xmpkXZOoGm73RHI2ZSzwKCdE83oRofZYxuotKApSulLb03G7UU1Bzb9alULIdBcpnKoLYhfGy/1 wGhcXj2HimINGxTEwsbRkXhlWh66DrWziaUuJ+tN+t4Ra84uMVV9JRgNQ1vZ/AX2LyWZxU4u8tt/7nUm 1SvKZ0vR0XrO3vfYbWWonFa4tT2vdnU5zKjaE724HS+hbmtVXEKTt3U1w73vetRoBnKq+p70heVKzXzb m6PArW6bgFlL9UYV06B+t4qpCO9Uj7jeaMXnVJOZbFebfLZajS9rSa7uthZK4HBGOXdxU8SUIzjT6+Vu N3X//udXbtjVLc9sOA3s8I57/NZ+DnlezQuwDrv35MHStsNX/qHwwqO5Lo15sYcN35kJfOs47+LBpguj U/M87T9neXBjOXTw/nqxo3xJqT9ta3ezMdcrhCyqN55znVI9u4gNumF5/vfdEt6vnOVnfPsM+SCa1axm bzbaJV/otWO+7VbX7szdm160ct7Bide101X65aWb+qx0hyx4V85xwGP07YK3fHglbVfxRvLf5HzrVYm+ WmdydaKID/epC3t7pYJegssNvZJ1v3PjvwPvptf7CPne3W1SVPYKn3jkI8rgf/wW8dsnsfPv/V2f/r7P pQf+ahlu+8xrn7+Lb7jI01vw/6LL/rqWHTWP63cL2FdKzIYYFndt3rYqs4dsKhcbIKNMXcdZH+Zd3Sd+ ldJhxMZ6YoF+yMZgnqNbV7Vs27R/2QR8H+ZhwRdivoR0c5d/7SZr62Zcj3Z6mcdq4gNkL0hmmOAo1Adm lSWD/ldzfmaD75CDuUBGAvh/2ZIPTjeDD3gHsFaEuIZjQChq/XMDPBiFWZg+tQZySqgDWOhp6EcJq6eF PYSErLYxPACGy2dtMEcKe0aGZehEa1iFTXh3jsZwWhSHVgBdSWdkcvhjZ1hmODhW8EZYoreHUIZdxwWI T0iHOxhyJLFLwEFvo0SJNfVQNUYcyWdhD5hhF8eBN0J2mv/kbZDUiC72iEgmiB41iaPXTq4YWBSnfKIF OhlHixqne6wFfbiYi6dohnYodneYiEyDa5O3az5nfP2WYYZXYa13cAqWgec3WslGd6jli8qRil6GaGdm h9nYVox3GJUIdOfWhlgFeiPVTs44dSuyiHUngj53jYHIbjGog6g3PTAYhzP3ee2XjM2ISJNndppHZ/Q3 i7nXfi93eCPnfvEIiT1WPryXNlZYfXsoOvy4ebNnXSAokKFFkOoIe/J3eQfJfwyJL/jFdL7GOffIjcP4 UR15kdxnjdPIb9JHXeGmfbSXfAQ5gSTpiCLEP8CTOQ+ZaCw1kDVxi1rVRu5nghW4byT/uIL0xYEkKG0U Vo0tyJNS9jV4ZnhBY332SIhEMmtfeZWlwBla+YpceZJNJj58JpZjSZZvY5ZnGZRpGY5+MIzTt41uCUBe E5cmaHl96T96KZhidjp96ZeLhmdqNpiLiUDzA5h0oY0/qZaMSZl7KTmGGSb1JZlDUpmdGUDr85hJgpmT 6ZmlGT+ogJl9Y4FxSZqm6ZpbeJmpKZu5Q4WvaZuXAJqzKZvEeJu9+T6oqZu6yZu+SZznA5zBOZqcWZxy mJeN+RfI+Zh1eYWm0oXddpdOGEd+yGMQgpKtJHlRglR1KJVc+ZnPCZ2JqZzT2YCd6J2JFJOD+Jce1pbp Rm3v6Z3x/6mC6TiIwpdgF5Y/x3meKuaNd7htdNRo/DmfXcWe9FmI+NmcmhaCvLigEOqU/emf+AOgAeo8 w7mE2/aJxYigM4RGWAefqvGgDeqAhfShFMphnSN+lnk0GiqUAxpr6EaO7WlOnXOi3FgYN1qMpGiBEUmh QCqhMteWkuEmF1qgp2meMpqG6fmFK2qALOoXE9qgYAdY87kRFiJiVfgpKmqjhdiiHxqCzhmjTvoxNNp/ 8RdtSRifw9Z0CLiAP9paKQan8Fmnv6N1IJqjk1WmZiodaJqh1xlZnoSdaGig9ZmglsioPXWk6yml7CGE hCRv49amazqeFXmo/6klgnqmhFqovf+npCu2pHCBWZRKgGL5iVJaMTs6fcYkb6K6qWHVYOT0lxEkmp76 qYtKqwg6oJraomymEHOTXMdBSa5KaMNqq8QqptK2rC+qQLmqq1EJqjnEYbWKqKXKqhBqrHJZg9txrBSJ LH5KfEtao7UKrMi6QbsqoxzaLwvoraSqrWHKreAar/dlrFOZj+O6rPfaq9CartXKCIOqoe76rriIrfL6 jikmhiXlieV6qXf3sFU1KQvpsORapP56rs6qqeoaPgQLnQZ7sEZ5cVdKpG9arKQDkYxYss1TaRbKdgn7 r/4ZMh6LPiArnFC6nDurhTibmiLLs0Gbgz4bnWoqtEf7hk26mzr/i7RNS5hKa5hA67RTC6hIwppMS7VZ W57sumRSq7Vfi6FQu5nSCbZlu7WBGmpGa7Zrqz+x2ZVqy7Zxewi5KZRkK7d3Cz90+6RYi7d9yz16a4Vw 67eD2weAuxirSLiJO7duSxiCq7iPK48FpiuOC7mVi42v45gCa7mbe4S147may7mhCyRc8bm8KrqnuwaO qZioy7qApjbb07qx67r2QLmya7tORjvAeLu7CwhcA7q8C7xSkLmmG7zFiwUEa7zJ+wh7q7zNu7gf47zR WwjQK73V+wcqab3ZW5K6q73d2wSI673huzW/K77l+wPka77pq77ry77t677vC7/xm7S3ypQu/7qykWWz nlZl+Su/ejmiJxgToyrASiei+4u+/ZtAqDSrpHifDLp3Bky8CJyFCjyvA6y/FvxuuibBQoukc9o3vvpw aBEOJfusDiy5F/o6Gxy0HSyVH4w2vgo+dTOnOUqbBQhtoaPCK8xLsWpOlyipbBJsCWWKPSxNHszAE5vD PJsfwRqi2Bmr5qZSCXgkNxx+OgKtMpvEt7nE+dnCR1zEYfpmisQqq2o2fOKX35nFy7nFC2bEd/rFHipd fzPGFFvGTZI5c5TGxfm5b+zEEneC01ZyHTXDzmphMuwneazGknvEkhTCYAxg8jUaiyzJm4XBiGybntvI SvrEEkjCZ5adPP9MxCXMyBFryZVpMo0cfkQMxYh5gX08NkdDs5JTyr15yhPryEW6wO6Esdw5oaNsPPw7 y8EszMNMzMVszMeMzMmszMvMzM3szM8MzdEszdNMzdW8tn9ao6aGrLqMo/JKyta8vKucdx80sykBvgPm zcAMzvJ4xfg7NuWMZdycK4O8zriZOwTqG/m7zZz8vfRcz5UAyz2agP+lrK4MqfzczhEKSqD8rGucqO0B rP88hgZmp2I8S5JqyzvSzq5MN9oIx12sKB5trhLdtgedqbPSPJo8wzZ8qXkCyhULxa/xoqPM0iQ90d6H 0KTTsZwc0/5MQCicygwtOqss1D5t0wO7w0H/TUEB/dFNTa4uOJdO3dO3LCUAe8BH3c95CqYxhtFb7dRc PNBbXdWZHMtUrdEojNUATa1fTchNLNUI7dAc68sJrdQgvdEcnYlpXdJfasG0ScV/LM4QC9RuHMpuvcte zcezqtd7jTwRzco2CsS2Kp+tPNh/nc8VW9iGjdnqvNiqKJ+445Ue+MKj3Z2IjTk/zawM3Tio/c2dLUDd Fox6tqBTDBzYfL9ivdBE2tAX3ZQl7NqJHMF3/dvKy9l4OdzSy72dfNzJW5sbu9zPDd3RLd3TTd3Vbd3X jd0HaqUMWmCrhMWp9BPbeGJ5WdzZXWeTzU7HM97WqcEJIt5xDN7mva6A/z3JfifHOe3cxh3W6Czfq/DK ZP3UO6ncnL3PlB3E/W0KspzYomqfdP3ZBE1KY62nbAzbl6jYCG7P62nZ7omMSLTTu8rFGO2zZb2lwY3h SOaEjEzTWRffHI6xf+zi4iTTG17Y5X3iPVnZMY4zZVSRKl7hOs7XSKzjNn7jgZjjc11UKL2iPCLXhJ2r Vn0nRl3km+DLLw2CtLvkcNLkJG7Yuy0UU+7fXlzjF42CEN7XP+7jdzrVI+11YO66Ry7mrkdeJ7zgh63Z db3gRO7mqEjfar5+VukpPIzNaX7ZgzzUcb7nGb5oHc1RgP445rnlGb0nK/7fid4J1MLbzwcxzyXOvv9d pRSeqCPa1pb+tF1K6qeO6qmu6qvO6q3u6q8O67Eu67NO67Vu67eO67mu67vO673u678O7MEu7MNO7MVu 7MeO7Mmu7MvO7M3u7M8O7dEu7dNO7dVOlKlr4o9mBFdtsdrZSkFoz1h5diaU7eFZr/OcsoRGZHh5ohl0 lzoJBffd3GrYUjs4uu/KcTSIr333h1DYXUck3IYWpf/e7Wr3qizr7aZT7r+w8Ot+QfsK7uru71YWT5WM ezXkWtMV8Tb2rcVm4Z9+Z52nSrzGzypUHnFEph2O2yEfigQNUH594UFlbgCxcEtZkCfvwNc22P9o845a e2y+skR9MpdEr2EdqYL/zVwt72WfTMct46o8rfJ+d2QG2OAPi3FlroeAF3EdPpPZN4JurfWAnnuxiPX1 Bo2zKHEN+1TC9Y6waPX7MIlhxPalhW5gZIv4R/DUxYZl5UN4VfVsdV0R1rBSH3YpWH6DH42B3/Xnp+Qy 93gKtoLuHpJGx+8jqXwfabFEpZOLpYwajwdxv3lJKY0uxPmeD/j+6HtOVXBVebH6JzReK2Cwz4JRifiZ FrOlD34eZKQkS1fHNsQU72A3mfUud/m1R/OdhfM5yY7IV/BwJIm6XXzsmO+iwn/3zW1SP4GpyvdhJvr2 +fcwN3iiZ5G1v46NnvvnD+4QO3SxJ0MQtouVD4+n/4X6JzRhxGb5GGmNJr971X90F5nwBBAgDDXZ8zQ5 H0SxYZxX1d35OIosR2kTzWgzKbVtXbSTrbua8dt+1HCRCoJ0ngtxBzzRXL0XSIj76X5Tae3IdDax15xv SGJBw8/iZFhWMsFi5NftlSdX5KQ1eoqV8+eSrG/LioqPaOvPDq2Qrs5CbQkmEvKNy5ER6NFGkFKRbW2w sY0usvCxKE/Ss09PrQdUjDWWbc+sdiZV9IDTMzfxrjVx6vDUsItD15EMmThLU3d3KRmr2ZQrS3pH6LpK efgYbNkS7/n4w/tbVGH7nJuG+1odnP1ZGRPY/d1X3Zgq7ntszzRh4QhRi4ZsHv85Rc7MleMVryE2PxMp VrR4ESMKi+cydvR46WNIkSNJljTZ5GRKlStZtnT58iQ0RDBpRqt5E2fOlTJ19vT5E2jQkvSEkiRaFGlS pUuZNnX6FGpUqVOpVrV69SPHplqrEpzpjyXXimKRkt3IE+tLszF3OVmr8y1NekTjluW36WtYtBfr+uxL TOlftXvZggQpGCbiwZ3ShiKUdydPs2QVd6wM2bDQyxg3821LqbPK0CkBEZ7K0a1pzpJVw7nVurBeW0xH U6w98VBqqAgFLlRirps7z50IKgTkpgtwsBCSjRjT3EiY4sERJS8NT/i+e/968wDoat317t7FTbPm/HqO o8//LXmvh4/883BH49WxDr36pGK58aBb056B6RwqKqJ26ptvkf/O8u2TVmDBRBbGDJADwUkycC8bY1y5 Yjuv1PMFlVSWYQ+5CEvLUMNXLoSwFyQC0ojFQdLDMB3XVoxIQRhxiRCNOWqg8McYU8ysJlpCnOUueFQE TBUlHQwlkDdS6KVJmwIMZruvjrTyRAuNoJK8vLY8KMscoRySS32Q5PELI7F86Ewv4/wQzjWZY0zGTKTj 5yc313tTmu8qHK7KuZ5cKB8PfdBuIDnpAtRQ5AykZTZKFRS0HbwCNYXSVVZ5YkQ0GbFUoijhdNNOK/EB hj5EyyS1nEP/RLHRK1v1yw7w/1J1xjHbikFvJikTtFGLSyzdksQGX/NRTzFBbFbXMMGKlswMedHtv1qv hZTPT7/s1EXQhvVmR0/DtRZNEZu9cilUKy0zs8l+lZY4fwxctpovrf2N22WzXdfeZ3+BIwpNCZ6X2Yei nVRNfYG0KU8tAJXQTm9rGWdgPJOTRd2Mk7WrvYW1VXWOx6p0DduRe+XV0UVClTPgfVmMmZUUqymYE1hH eTUNijlOEsBqf4aYz2/vrbNcaHYEU+NtH26ww3P7JLFV3nZGMFSLMYtSwPw+vlVh4wRGcZ/6flHUanOx w89sq7mLdV+09wtovA/Dy1m+bj8OeT92OZx7YIAYVKjEr/8J9429w8v2uui0WWW3a+2IfOo2l2BrDPPM Nfeo8s09N6nzli7/nPTSSw/d9NT9APsq1FV/HXa4Ro+d9tptvx333HXfffXZKSPMddpmrzM2zxVNK3je sxq+SEP3JjZVf89IPjDmJxeJ+kpWa935tVPvPLTsl/d5LKkznt763fDGPn2TM0KdP8y7pNz67OPqi/r5 CXWaZMxUN5hz7ZPe9hbTK+6Rr131EyBuRoe/BaKPOFzT0hF487IB2cI6gMvGjShoH0R90G/kYJ3gshM0 iYWLbugR14oGRELWlSdu3Rkh1nKFsDsprkI4YpIK4WOfDPKwh+4RWyxyOJceSSpoj5P/nAkRxzOGaENp b5nR0prmMKbNIjvIepIFyXe0tu3Jg4syUxb7JSR7Nc2C8TtQuoY1LSVi0Ecc6p8B05gvqMmRaYOKYYIC McENlsyKActSxNikI9jMj4oV04cXeSChWgkOaLO5osyeJ7NC8g9nJhLWhApVw5VFbZJVBKQqalSy3znS SctJ1iqxM7Ix4WJKGNwYm3SGSVGxLJCS7B0qLVlFUgFHbuZ7ZAcj+a5ZofJRjoFi0Wz5qGMeDIUi9CRk GMYoO5rymlOKVKlsuEN0GfFdRpNY9I4FynQIiz5eMRcCPWYzxdUoNcdzXwyJl7ToVQdhw5zQBWDGS116 y2D2VOXN/zZpLHWaz28DpSe1aDbKYh1slFxBpPfC6S56ufKWbWSB//zjMFxSrJray+UYvTlJkZ2PpOP0 Erh61ktRnoqZAW0jRAtJLV3pzKLhpBJDLzaxOOQrkVqZKPTECSyjYvNkWnyoLpkDK1AwNKTKbFhKB2jS gmJ0jv9aqU+15lI6EU2qgAQPwNKkKpXVUXt1nCmxXhlFmDp0SV+lKpBKQU+UFoiN7BxVP5+6wjUCSI0O nSsd2Zgy8/BtVW60JA4BNta5UUc8LfUnRCi4Qg+lc4gGJZPj3lM48ySqo9uqZdiwltDFQW+oEkEijWwF wqu9LY9dxcZ7lIOOdwpHG9EZ6wU9q/88377OgbuBHU8J9FvjHld5waXccAsaGOQ+F7q0U+5WHggypgJF fNHV7na5213vxq4yxLUM8Hx3ze+SbB4EJGB2g0Ku6souMtIVoHjfR97xXk+kuzOsARl4X6KCVybsHcpe TvnfAOIkvM0NiUTLi1/9BtivVe1vfR08vqS4V33UfG+FFzQ1oyjYwhCksIEfPE/i6dXE5eOwf62bX+Fp OL6i2fCE2UbZEtr0oDirIXXOhjdRnTaWnBRBjqHpWheKB59knM4PNclk3roNVHUbyIugWMLE1hhUf+Qk YMODMqoRechp4LHZSrREuLX2gmHuLThA+GVB0eqE7NMkYOE6rrr/sllZdj0iLPkYJLzW7J935iIhMWZI xD7NtnklM1hjS1dEK9RGYBSjkCWrQ0BrdY2Kjutaz/Y0S1+akB1V89AOfeArsuym07zoPcDlVVK3GiFz zqX+vizrrbJTnzlq66xt2LFVh/JkRAozP3sqNKeNCdMJjeslPZpKkrZarsZmpb5kO+FtlpOLKv01tE1L itseU5+xTthIf+lse+SYcE7NLKLLuSleg7TPyVRhuteH0itD8t56qyg4uR2pbbJ13fCeN1ohvU54y/vX pVyvgn0dQW13m9VlnJNAN0psTI92naYCeFhJ/WiNf/Sj1F5rTnGt72IHaJ8dx6mqbVlWjuZZ/6emZTa3 Fb7yhzOSUFDt809ZPu02QHsYvmYpl/UcaWhFMrANhfnSL47QkAOdoA9nqsF9iSM+v/WoLR/VZ2iGrW8q Xes1bVhOcd5hmhL8pGAatKIVrsii57pFHL+XbDUFdXPaGtU8jWres8lwO0Z16Z82Y0/Japi0ez2UKvpz sHcm8GQvO79Vc7PM4RxEElIycmbG7TqCiFR47o2xGtctOmvLZYN0rfRqy208payn0i4Ty/65LWzHYZDN M+7MMLQb7E+bZcGv/cxLclvpofPEllb51omZMYptJ+DzlpS7zn9+8+Sy/AxPn7rPlz729SJP0lg/gd7n fk5eiNzyjx/96f9X//rZ3/6Xm0xeEOZdZ7afYvW6X/nL0f/+P1ebX3o551QDNcDP1D6seE4MvhaMAC/s gSqHvrKKxBCswWTsWhxPxSLwMKZKvaSoATWQ/+wt+xSwdhzQ+h6QXphPfkBsxCbN2HxlxRBPMarNxUQQ AvtntKpHzuRLdEpQBR3u/TTHBF1wn4JAiPbkM37MtXqPm8hs9vjGeSyPmNbtcC4v3xYta4yPtXKL5zQo yA7LDIgstICo84Csg3AvzcoQPyYP3NBQ92Zw0lqvyfjlsbYwCRlkp6jBk7TwyUCP3gpsG7Dp7x6NnCLs r55t3H5G0titr8iIgwyPtjgt0Yhoi47wj4T/D+5IQbO+CI/UBQoSDvgWjf+q4BA5sdQc8e7C5tIKURPb JN4KzjRiLXEay63GqN0gTdlmkeoypefg5Xzy7pM6TrHu0OICyxd/sdFqbmJ0ceZa6RQxjA7X5Uj6rZuO jZnkCqtEjpdqieogqBl4RGvW0BZhMINm75noBvjIjhebLfjqTc9kyt1aywO5pqtYSmzK0enE7Bz5bQ6l EQSvC9+w0Qv48cT8hBzHptx6sRugjKZGqhK60fPOjtNqMeYqye36MZOyDudqMZEQsh+BreK2LAOBURwz cbKEBscWkl92pfA+8COhcUgE0gZZTqSQjeYksgVhRixK6yEPD6jGZiIp/6rqbvLrMDIdNRIS1THakm9w Qs6u9MckexCgfMpCdM4Tf8wZs0wVmw4gk5Iad+nUuGpeQK65bpDjdvKqIFFlpM28YM4pf07iLMYoBQsp 2/KczjIU2c6gVpIVzarShCnqJFElQY0QX4phWrGUNiEdu27KFiufpEZu7knEmi0xHccUpzESaUVcuowJ pfD44DADBykWM7Mpj0f1rJI0kwQPLQsL1xG9WOkTlyg9jowxOe8DdQ3MHoeRHhPdSO/2jGaRxMxVYAsr lRD/irP96m+HFnAEldM4m9M57S8EQbI4kfM5qxP9zo9AmnA6mdM6u9M7vxM8JZDFcjAy98cAwxM90/8T d4KwBoWwPM3uPNVTPucTCD3wPUMM+twzPumTP/vzNOwzP8cTOr1ywPzTQA8UdJBsDGETDfXw4DQIzVir 95AvyeTBDtlGIdUjDSvriC409HYMQUPUuIrRTF6E6fxJi5To6p4tLHmRFB3J0bQMFWNrLUXURv+nMV0q LjeuqKqSKKWFuHxuqGyuqUyThfjHR1fsRpc0BVcFmMTS1k5u25KRGYswSKu0xxQSlyor24KsJIW0GplU TE0HLmfx7fwKHbcSTImKVw5y65CG2PTO4pRuTZV0TO+UKhYx8pAw7aY0MGFN/nyw8faSLylN/zaqIXfR 1fCUUZuUJMORU8bSnF7/c0WvUhCRkYlAkClPbtfkslE/lX4i68qWEhEJ8UPFsC6xDTFZZczMLEOJJtsq cwynEAlB1Vb5kzqF61Z3lVcFVPt6FViDlUCnL1eF1ViPFVmTVVmXlVmb1VmfFVqjVVqnlVqr1VqvFVuz VVu3lVu71Vu/9Tux8zWKVXQCSDC0E1zTFVf+zVfI9fsc6FzFT13ntXm65yzclS3gVYHwlV61tQ+D4wqV 8FakCUJpFd1aqIIYxYd2E4n+lYYQll/79VpPdVO4FLP+7Qnt0GEftvi6B5yibMkkL2Pt1fSAU2JP9iYo 1poqdpk2ljddlkLrcWSDCWYT0plm9jt4C2V3tvsK//ZfIVaGmpBg8ZFBke9PBtAci7Y3frZsmJZnn1bG FHRCOdZjTdaDZBZos7ZirYHHsDb2LpYMuRNq51VlDTZoSRZdE3ZDUy9gY0WezFZrw/Zj1bY9x9Zu29Vn U6hjV3Vcv8hoqfayPjYJmZZw25ayxPZuT9Zpp/Zv2xZdFXa2vPZofSwzE1JpHWJxBfdxE5dzmSFja8xj 3ZZjufaxapZtic9JRdccb5ZdB1ZeOxd2SVdlWVYgLhbCAtd1cdZmV3V1S1dmNXd2Y1d4GYhmo0xgg7dC g9N4vdZtx1VUl/dhg3dzh5d68zRiU/Z6q1d7y0dcm09wtxd8U3B6l3N8w9d8qf/rdW+ne8+XfdvXfd8X fuNXfueXfuvXfu8Xf/NXf/eXf/vXf/8XgANYdi5j+Zj3Dxb0P/0vfZNXgP2zfJ23Z2OPcRFXARX4fha4 gbvzgbk2gokTQzGYAS24gUA4g5/TaTdWdJ2X9EL2a/UxZ0GWg+G2OYbWhGhYeTH3iTw4dy33DOumhM/r hK/wd3nXbG23hScXeNnVSYMYU0iWdlW3dnG3dT8XZiO3grL3h7FrdG14aN+WikN3cb7Nhb9YiaH4dC0W jK1piGmIZjGWjPHxZ282i7GPiTl0tfDJZAsXdffQcUc33844jA03jgHXixv3bLn0cuV4jrVvi69YhhlY hff/tnKh8ElnyJBxuLbqWI0N947XGGv1+PRIeJEfLGaF2I+NV3b7mPUoGY4t+ZAxOY8buYkNGJUDGW2v uIcdmYJHGX3HI3PHmIN9SJIl+JFpWZiHeYZV2ZdxGZKNjJM/qI4xhZejS5M1L24lJZYv2YMnGGitlpUl 2Y6Zd5CVOZhtOZMd2VUdFoGnmXyn2F4lt/ycuGqRGWSttmaT15OZWZzl+Y1TOWSNeJOdWWrZOXec+InV uHnxuIgnl5gZem2/N5fN2Jwfem77eWFFtqJbNpp0doMJuv8K8oUhN/fwuGHJmaTl9oY7mYW5WJCZeVQl OJkdC0KtuYYH2qNvGqdzWqd3/5qne9qnfxqog1qoh5qoi9qojxqpk1qpl5qpm9qpnxqqo1qqPZeHzTWb lWadK3iXa3l1phpPH9mq6XlwRbl36m98O9qr1dOY6+ucV1lnP8ysFxit0xo90/ilx/mqsVk53smd7Vhu XzZrTvqY33FlR7ppsZiureJzl9ie126PC9uu+Vl3VctV7Dqg8Vl3TZmNyTqxGRmib5lCe0iMkXiMry10 u/iiI3ux2+y0S9tlO9s7Pxu1F/eaO8+hQRk4DRqV9zm0RZuQlxmYYBs8R3tpT1msbdu4uanKVnu3W1q3 31q5o9ihhTu2izemffi4+bj1THu5mdu3z7iMP5i7pXutqf+7OYkblqG7vIv5tx96kymXns+6vVG6mc37 vNtYcn53tUC6a527sd9MaE36cvd7vgdchmnbvreLv0nblRuat1v5wc15kicaio95niFXsiEruRMcugIc oyGawuvZvQ8ar6Gbwhe6kMn7SVlWu0ecw6PP+8DGhlmbd138sAFZnZt7j7ETbnOcsrmZvl9cyIecyIvc yI8cyZNcyZecyZvcyZ8cyqNcyqecyqvcyq8cy7Ncy7ecy7vcy78czMNczMeczMvczM8czdNczdeczdvc zd8czuNczueczuvczu8cz/Ncz/ecz/vcz/8c0ANd0Aed0Avd0A8d0XlWruOZx9d3iVP/G9LLOsbPD8St LNHrM329+7kvG33Ce9MLm6qJ25UX/NKNp3st+8LNGC1SnXZXGGlXm9XfW8RLvTE+/Y95L503/IZtt3Yr OyFwndfXUbMRm9brWV6ROPeC/cexOdl9fGsLAth9HNk5vdjR19jdS4ibnY0Nm9lVS9lVl6q1Pdqzndqr PfwuGtqJ1tul/XG//dsP99d7fd233Zor3dw1gz+OXb/nHdfxVt5znco2193Zndxf+t5DmHS5l94BHpHD nd//Hd5ZY+HfvbJh+ODPfWEVvqp5PbwtXvNYHbXTXdwhPqW5/eIHGNUfOInH3bK7vd5hPbhF/uFNXqQN /uRRXrcd/z1QRnXg9X3h3/sRX7fn+z11Pf7me6Jqnzfnd/jflf2dk37kwbnCh57kd97lj7698r2Sn5fn CX7rIdzr+3Kz0Xnml52maR7ryU/rwb7ou37i8xluqL7VZ7nhGZ7b7V3n0777Ep7aRz3qo5vR337YWTfk 7X7ZKX2u9X7AjvDVZfrvz37Xw37uo0jwid7eIV/x65XvZd7j5T6Sy15pbR30Kb7ROTvzq0/oX8jzMf/x nR7qN3/1a/7qTz/84j3jR1/gK7/qzb7zJR/tf5/2tdjnYX7pRZ+xdxPvpzfWQb7lWT/4p2b4y3jTjd/X ZTrwhUrTiT/7Tf/5e/Z2t9/DN/jyOyEe+H090o/f8btf/def/dvf/d8f/uNf/uef/uvf/qW6AAAAIf5w aHFnaHVtZWF5bG5sZmR4ZmlyY3ZzY3hnZ2J3a2ZucWR1eHdmbmZvenZzcnRranByZXBnZ3hycG5ydnlz d2R6dHZoenpheHd1eWFxYnJzenJjeWF3d3N4aGdlam1tdW5vbGJ2ADs= --------------040602050204070101010000-- From rtg-dir-bounces@ietf.org Mon Jun 20 07:00:57 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15309 for ; Mon, 20 Jun 2005 07:00:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkKPB-0005pS-P0 for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 07:25:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkK0o-0000Zl-Mw; Mon, 20 Jun 2005 07:00:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkK0m-0000Zg-9j for rtg-dir@megatron.ietf.org; Mon, 20 Jun 2005 07:00:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15287 for ; Mon, 20 Jun 2005 07:00:13 -0400 (EDT) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkKOR-0005ob-Bt for rtg-dir@ietf.org; Mon, 20 Jun 2005 07:24:46 -0400 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-green.research.att.com (Postfix) with ESMTP id D1007A7BB0 for ; Mon, 20 Jun 2005 07:00:03 -0400 (EDT) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j5KB023h004453 for ; Mon, 20 Jun 2005 04:00:02 -0700 (PDT) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j5KB02Ed004452 for rtg-dir@ietf.org; Mon, 20 Jun 2005 04:00:02 -0700 (PDT) (envelope-from fenner) Date: Mon, 20 Jun 2005 04:00:02 -0700 (PDT) Message-Id: <200506201100.j5KB02Ed004452@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Subject: IESG agenda for 2005-06-23 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-06-23). Updated 2:26:42 EDT, June 20, 2005 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date Enhancements for Authenticated Identity TSV Management in the Session Initiation Protocol (SIP) (Proposed Standard) - 1 of 7 draft-ietf-sip-identity-05.txt [Open Web Ballot] Token: Allison Mankin TSV A One-way Active Measurement Protocol (OWAMP) (Proposed Standard) - 2 of 7 draft-ietf-ippm-owdp-14.txt [Open Web Ballot] Note: PROTO shepherd: Henk Uijterwaal, henk@ripe.net Token: Allison Mankin INT Detecting Network Attachment (DNA) in IPv4 (Proposed Standard) - 3 of 7 draft-ietf-dhc-dna-ipv4-12.txt [Open Web Ballot] Token: Margaret Wasserman APP The Atom Syndication Format (Proposed Standard) - 4 of 7 draft-ietf-atompub-format-09.txt [Open Web Ballot] Note: Paul Hoffman is the shepherd for the atompub working group. Token: Scott Hollenbeck TSV Session Initiation Protocol Call Control - Conferencing for User Agents (BCP) - 5 of 7 draft-ietf-sipping-cc-conferencing-07.txt [Open Web Ballot] Note: PROTO shepherd: gonzalo.camarillo@ericsson.com Token: Allison Mankin APP IMAP4 ACL extension (Proposed Standard) - 6 of 7 draft-ietf-imapext-2086upd-07.txt [Open Web Ballot] Note: Proto shepherd is Lisa Dusseault Token: Scott Hollenbeck SEC X.509 Certificate Extension for S/MIME Capabilities (Proposed Standard) - 7 of 7 draft-ietf-smime-certcapa-05.txt [Open Web Ballot] Token: Russ Housley 2.1.2 Returning Item Area Date APP LDAP: The Protocol (Proposed Standard) - 1 of 3 draft-ietf-ldapbis-protocol-31.txt Token: Ted Hardie APP Network News Transfer Protocol (Proposed Standard) - 2 of 3 draft-ietf-nntpext-base-27.txt [Open Web Ballot] Note: Document shepherd: Russ Allbery Returning to secure positive ballots needed due to AD changes since the document was last reviewed. Token: Scott Hollenbeck The Extensible Markup Language (XML) APP Configuration Access Protocol (XCAP) (Proposed Standard) - 3 of 3 draft-ietf-simple-xcap-07.txt [Open Web Ballot] Note: Returning to see if we can clear Margaret's discuss. Token: Ted Hardie 2.2 Individual Submissions 2.2.1 New Item Area Date Lightweight Directory Access Protocol (LDAP) APP schema definitions for X.509 Certificates (Proposed Standard) - 1 of 4 draft-zeilenga-ldap-x509-01.txt [Open Web Ballot] Token: Ted Hardie APP The LDAP Assertion Control (Proposed Standard) - 2 of 4 draft-zeilenga-ldap-assert-05.txt [Open Web Ballot] Token: Ted Hardie APP LDAP Absolute True and False Filters (Proposed Standard) - 3 of 4 draft-zeilenga-ldap-t-f-10.txt [Open Web Ballot] Token: Ted Hardie APP LDAP Read Entry Controls (Proposed Standard) - 4 of 4 draft-zeilenga-ldap-readentry-04.txt [Open Web Ballot] Token: Ted Hardie 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date RObust Header Compression (ROHC): ROHC over TSV Channels that can Reorder Packets (Informational) - 1 of 2 draft-ietf-rohc-over-reordering-03.txt [Open Web Ballot] Note: PROTO shepherd: lars-erik.jonsson@ericsson.com Token: Allison Mankin TSV Session Initiation Protocol Torture Test Messages (Informational) - 2 of 2 draft-ietf-sipping-torture-tests-07.txt [Open Web Ballot] Note: Document was not released till there were five full peer reviews. Tests used in interops. Token: Allison Mankin 3.1.2 Returning Item Area Date OPS Operational Considerations and Issues with IPv6 DNS (Informational) - 1 of 1 draft-ietf-dnsop-ipv6-dns-issues-10.txt [Open Web Ballot] Note: To check on the status of the resolution of Thomas DISCUSS. Token: David Kessens 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date APP Scripting Media Types (Informational) - 1 of 4 draft-hoehrmann-script-types-03.txt [Open Web Ballot] Token: Scott Hollenbeck APP XHTML+Voice - application/xhtml-voice+xml (Informational) - 2 of 4 draft-mccobb-xplusv-media-type-04.txt [Open Web Ballot] Token: Scott Hollenbeck The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, APP application/srgs, application/srgs+xml, application/ccxml+xml and application/pls+xml (Informational) - 3 of 4 draft-froumentin-voice-mediatypes-02.txt [Open Web Ballot] Token: Scott Hollenbeck SEC Attacks on Cryptographic Hashes in Internet Protocols (Informational) - 4 of 4 draft-hoffman-hash-attacks-04.txt [Open Web Ballot] Token: Russ Housley 3.2.2 Returning Item Area Date APP Three-Document ballot: [Open Web Ballot] - 1 of 2 SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message (Experimental) - 1 of 2 draft-katz-submitter-01.txt Note: Please check update ballot write-up Sender ID: Authenticating E-Mail (Experimental) draft-lyon-senderid-core-01.txt Note: Sent to dea-dir Purported Responsible Address in E-Mail Messages (Experimental) draft-lyon-senderid-pra-01.txt Note: Sent to dea-dir Token: Ted Hardie Sender Policy Framework (SPF) for Authorizing APP Use of Domains in E-MAIL, version 1 (Experimental) - 2 of 2 draft-schlitt-spf-classic-02.txt [Open Web Ballot] Note: Please check updated ballot Token: Ted Hardie 3.3 Individual Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. Other matters may be recorded in comments to be passed on to the RFC Editor as community review of the document. 3.3.1 New Item Area Date GEN Circuit Cross-Connect (Informational) - 1 of 1 draft-kompella-ccc-02.txt Token: Mark Townsley 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review Area Date INT Jun 9 Manet Autoconfiguration (autoconf) - 1 of 2 Token: Margaret APP Jun 16 Calendaring and Scheduling Standards Simplification (calsify) - 2 of 2 Token: Ted 4.1.2 Proposed for Approval Area Date RTG May 18 Layer 1 Virtual Private Networks (l1vpn) - 1 of 3 Token: Alex INT Jun 3 Transparent Interconnection of Lots of Links (trill) - 2 of 3 Token: Margaret INT Apr 28 Site Multihoming by IPv6 Intermediation (shim6) - 3 of 3 Token: Margaret 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval Area Date INT Jun 1 Protocol for carrying Authentication for Network Access (pana) - 1 of 1 Token: Mark 5. IAB News We Can Use 6. Management Issues 7. Working Group News From rtg-dir-bounces@ietf.org Mon Jun 20 09:56:39 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29293 for ; Mon, 20 Jun 2005 09:56:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkN9A-0001xu-Ic for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 10:21:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkMiw-0003VC-L2; Mon, 20 Jun 2005 09:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkMiu-0003Uh-97; Mon, 20 Jun 2005 09:54:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29168; Mon, 20 Jun 2005 09:53:50 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkN6S-0001ug-Py; Mon, 20 Jun 2005 10:18:23 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A9B172D4B19; Mon, 20 Jun 2005 09:53: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 49065-01-29; Mon, 20 Jun 2005 09:53:28 -0400 (EDT) Received: from BOS-exch01.corp.nexthop.com (unknown [192.168.11.20]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A62912D48B9; Mon, 20 Jun 2005 09:53:27 -0400 (EDT) Received: from aa-exchange1.corp.nexthop.com ([65.247.36.233]) by BOS-exch01.corp.nexthop.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Jun 2005 09:53:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2005 09:53:26 -0400 Message-ID: Thread-Topic: WG Review: Transparent Interconnection of Lots of Links (trill) Thread-Index: AcVy4gNEhepqi1LwQv+Qa7PbM7WaPQCvUC+A From: "Susan Hares" To: "Alex Zinin" , X-OriginalArrivalTime: 20 Jun 2005 13:53:27.0352 (UTC) FILETIME=[6F105B80:01C5759F] X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: quoted-printable Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: RE: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: quoted-printable Why are we doing this? Is it IP or is it Frames? If it is Frames, why is it not 802.1 - etc?=20 Sue Hares -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com]=20 Sent: Thursday, June 16, 2005 10:00 PM To: routing-discussion@ietf.org Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: Fwd: WG Review: Transparent Interconnection of Lots of Links (trill) Since the second BOF on this topic was inconclusive regarding community support, the IESG is reevaluating the community consensus on whether a WG should be formed or not. If you have input on this, positive or negative, please send it to iesg@ietf.org. --=20 Alex http://www.psg.com/~zinin This is a forwarded message From: The IESG To: IETF-Announce@ietf.org Cc: rbridge@postel.org Date: Wednesday, June 15, 2005, 11:52:27 AM Subject: WG Review: Transparent Interconnection of Lots of Links (trill) =3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DOriginal message = text=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A new IETF working group has been proposed in the Internet Area. The IESG has=20 not made any determination as yet. The following draft charter was submitted,=20 and is provided for informational purposes only. Please send your comments to=20 the IESG mailing list (iesg@ietf.org) by June 22nd. +++ Transparent Interconnection of Lots of Links (trill)=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Current Status: Proposed Working Group Chair(s): TBD Internet Area Director(s): Mark Townsley Margaret Wasserman Internet Area Advisor: Mark Townsley Technical Advisor: Bill Fenner Secretary(ies): TBD Mailing Lists: General Discussion: rbridge@postel.org To Subscribe: http://www.postel.org/mailman/listinfo/rbridge Archive: http://www.postel.org/pipermail/rbridge Description of Working Group: The TRILL WG will design a solution for shortest-path frame routing in multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies, using the link-state routing protocol technology. This work will initially be based on draft-perlman-rbridge-03.txt. The design should have the following properties: - Minimal or no configuration required - Load-splitting among multiple paths - Routing loop mitigation (possibly through a TTL field) - Support of multiple points of attachment - Support for broadcast and multicast - No significant service delay after attachment - No less secure than existing bridged solutions Any changes introduced to the Ethernet service model should be analyzed and clearly documented. To ensure compatibility with IEEE VLANs and the Ethernet service model, the WG will request an IEEE liaison relationship with IEEE 802.1. It is not an explicit requirement that the solution should be able to run on existing IP routers or IEEE 802 switches as a software upgrade. However, the working group should take deployment considerations into account, to ensure that the solution can interwork with bridges in a flexible manner (e.g., to allow incremental deployment into LANs that currently use 802.1D bridges). The TRILL working will work with the L2VPN WG and IEEE 802.1 to develop interworking between TRILL and 802.1D bridges at the edge, such that a bridged sub-cloud could be attached to TRILL devices in more than one place for redundancy. The solution must not interfere with the end-to-end transparency of the Internet architecture or with end-to-end congestion control and QOS mechanisms. The WG will work on the following items: (1) Develop a problem statement and architecture document that describes the high-level TRILL architecture, discusses the scalability of that architecture, describe the threat model and security impacts of the TRILL solution, and describes the expected impacts (if any) of the TRILL solution on the Ethernet service model. (2) Define the requirements for a TRILL-capable routing protocol, and select one or more existing routing protocols that could meet those requirements. (3) Work with the appropriate Routing area working group to extend an existing routing protocol to meet the TRILL working group requirements. Note: The TRILL working group is not chartered to develop a new routing protocol or to make substantial modifications to an existing routing protocol. If, during the requirements definition and selection phase, the TRILL working group discovers that no existing routing protocol will meet their needs, we will need to re-assess the TRILL WG charter to determine how/if this work should proceed. (4) Produce a (set of) TRILL specification(s) for standards track publication that defines what information must be carried in an encapsulation header for data packets, and determine how to map that information to various link types (only IEEE 802 links initially) The TRILL working group is chartered to undertake all of the above tasks and may begin work on more than one of these tasks in parallel. However, the problem statement and architecture document should be completed before the details of the base protocol are finalized, while there is still time to consider changes to the architecture without major impacts on established specifications. Goals and Milestones: Aug 05 Accept Problem statement and architecture document as a WG work item Aug 05 Accept base protocol specification as a WG document Oct 05 Accept routing protocol requirements as a WG work item Dec 05 Submit problem statement and architecture document to the IESG for publication as an Informational RFC Mar 06 Submit routing protocol requirements to the IESG for publication as an Informational RFC Mar 06 Choose routing protocol(s) that can meet the requirements. Apr 06 Start work with routing area WG(s) to undertake TRILL extensions. Sep 06 Base protocol specification submitted to the IESG for publication as a Proposed Standard RFC Dec 06 Re-charter or shut down the WG _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce =3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DEnd of original message = text=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From rtg-dir-bounces@ietf.org Mon Jun 20 13:55:43 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23621 for ; Mon, 20 Jun 2005 13:55:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkQsb-000053-Jg for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 14:20:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQTc-0000pf-8I; Mon, 20 Jun 2005 13:54:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQTb-0000pO-2F; Mon, 20 Jun 2005 13:54:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23213; Mon, 20 Jun 2005 13:53:05 -0400 (EDT) Received: from imo-d01.mx.aol.com ([205.188.157.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkQpy-0008Pk-W9; Mon, 20 Jun 2005 14:17:40 -0400 Received: from ewgray2k@netscape.net by imo-d01.mx.aol.com (mail_out_v38_r1.7.) id b.13a.10403438 (22683); Mon, 20 Jun 2005 13:52:38 -0400 (EDT) Received: from [192.168.7.131] (c-24-61-197-198.hsd1.nh.comcast.net [24.61.197.198]) by air-in04.mx.aol.com (v106.2) with ESMTP id MAILININ44-589b42b702642f; Mon, 20 Jun 2005 13:52:37 -0400 Message-ID: <42B70260.4010801@netscape.net> Date: Mon, 20 Jun 2005 13:52:32 -0400 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: shares@nexthop.com References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070905060101000003010107" X-AOL-IP: 24.61.197.198 X-Mailer: Unknown (No Version) X-Spam-Score: 1.3 (+) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Alex Zinin , rtg-dir@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c --------------070905060101000003010107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sue, The trouble with obvious questions is that everybody assumes they've been asked already. Now this question has been asked at least once, for sure. :-) From the charter attached in Alex's previous message, the purpose is to "route" Ethernet Frames. Quote: The TRILL WG will design a solution for shortest-path frame routing in multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies, using the link-state routing protocol technology. Since it is clear that at least some people are not satisfied with the 802.1 approach (perhaps because of the relative inefficiency associated with completely unused high capacity links), I assume you mean to ask "why is it not IEEE" - rather than "why is it not 802.1". I believe that is a very good question. I know of no very good reason why the IEEE might not specify how to use an OSPF-like routing protocol to fulfill the role previously handled by Spanning Tree Protocol. Perhaps the only reason why it is being discussed here is that it might be better - for implementers - if the protocol used was more than "OSPF-like." -- Eric shares@nexthop.com wrote: >Why are we doing this? Is it IP or is it Frames? >If it is Frames, why is it not 802.1 - etc? > >Sue Hares > >-----Original Message----- >From: Alex Zinin [mailto:zinin@psg.com] >Sent: Thursday, June 16, 2005 10:00 PM >To: routing-discussion@ietf.org >Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org >Subject: Fwd: WG Review: Transparent Interconnection of Lots of Links >(trill) > >Since the second BOF on this topic was inconclusive regarding community >support, the IESG is reevaluating the community consensus on whether a >WG >should be formed or not. > >If you have input on this, positive or negative, please send it to >iesg@ietf.org. > > > --------------070905060101000003010107 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sue,

        The trouble with obvious questions is that everybody assumes they've been  asked already.
    Now this question has been asked at least once, for sure.  :-)

        From the charter attached in Alex's previous message, the purpose is to "route" Ethernet
    Frames. Quote:
    The TRILL WG will design a solution for shortest-path frame routing in
multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies,
using the link-state routing protocol technology.
    Since it is clear that at least some people are not satisfied with the 802.1 approach (perhaps
    because of the relative inefficiency associated with completely unused high capacity links), I
    assume you mean to ask "why is it not IEEE" - rather than "why is it not 802.1".

        I believe that is a very good question.  I know of no very good reason why the IEEE might
    not specify how to use an OSPF-like routing protocol to fulfill the role previously handled by
    Spanning Tree Protocol. Perhaps the only reason why it is being discussed here is that it might
    be better - for implementers - if the protocol used was more than "OSPF-like."

    --
    Eric

    shares@nexthop.com wrote: 
    Why are we doing this?  Is it IP or is it Frames?
If it is Frames, why is it not 802.1 - etc? 

Sue Hares

-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com] 
Sent: Thursday, June 16, 2005 10:00 PM
To: routing-discussion@ietf.org
Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org
Subject: Fwd: WG Review: Transparent Interconnection of Lots of Links
(trill)

Since the second BOF on this topic was inconclusive regarding community
support, the IESG is reevaluating the community consensus on whether a
WG
should be formed or not.

If you have input on this, positive or negative, please send it to
iesg@ietf.org.
    --------------070905060101000003010107-- From rtg-dir-bounces@ietf.org Mon Jun 20 14:28:43 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26348 for ; Mon, 20 Jun 2005 14:28:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkROY-0000xa-PF for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 14:53:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQx2-0004z5-Hg; Mon, 20 Jun 2005 14:24:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQx0-0004yx-09; Mon, 20 Jun 2005 14:24:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26076; Mon, 20 Jun 2005 14:24:41 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkRKd-0000pp-AN; Mon, 20 Jun 2005 14:49:16 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 20 Jun 2005 11:24:24 -0700 Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5KIOLqi009875; Mon, 20 Jun 2005 11:24:21 -0700 (PDT) Received: from [10.21.147.148] (sjc-vpn7-916.cisco.com [10.21.147.148]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id LAA08965; Mon, 20 Jun 2005 11:20:40 -0700 Message-ID: <42B708F7.9030707@tony.li> Date: Mon, 20 Jun 2005 11:20:39 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ewgray@GraIyMage.com References: <42B70260.4010801@netscape.net> In-Reply-To: <42B70260.4010801@netscape.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, rtg-chairs@ietf.org, routing-discussion@ietf.org, shares@nexthop.com Subject: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit In other instances, when proposals were IEEE'ish, we were directed to take them to the IEEE. Tony Eric W Gray wrote: > Sue, > > The trouble with obvious questions is that everybody assumes they've > been asked already. > Now this question has been asked at least once, for sure. :-) > > From the charter attached in Alex's previous message, the purpose is > to "route" Ethernet > Frames. Quote: > > The TRILL WG will design a solution for shortest-path frame routing in > multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies, > using the link-state routing protocol technology. > > Since it is clear that at least some people are not satisfied with the > 802.1 approach (perhaps > because of the relative inefficiency associated with completely unused > high capacity links), I > assume you mean to ask "why is it not IEEE" - rather than "why is it not > 802.1". > > I believe that is a very good question. I know of no very good > reason why the IEEE might > not specify how to use an OSPF-like routing protocol to fulfill the role > previously handled by > Spanning Tree Protocol. Perhaps the only reason why it is being > discussed here is that it might > be better - for implementers - if the protocol used was more than > "OSPF-like." > > -- > Eric > > shares@nexthop.com wrote: > >>Why are we doing this? Is it IP or is it Frames? >>If it is Frames, why is it not 802.1 - etc? >> >>Sue Hares >> >>-----Original Message----- >>From: Alex Zinin [mailto:zinin@psg.com] >>Sent: Thursday, June 16, 2005 10:00 PM >>To: routing-discussion@ietf.org >>Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org >>Subject: Fwd: WG Review: Transparent Interconnection of Lots of Links >>(trill) >> >>Since the second BOF on this topic was inconclusive regarding community >>support, the IESG is reevaluating the community consensus on whether a >>WG >>should be formed or not. >> >>If you have input on this, positive or negative, please send it to >>iesg@ietf.org. >> >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Mon Jun 20 14:46:34 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27339 for ; Mon, 20 Jun 2005 14:46:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkRfp-0001Ka-IF for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 15:11:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkRHg-0007XY-Kk; Mon, 20 Jun 2005 14:46:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkRHe-0007WH-AU; Mon, 20 Jun 2005 14:46:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27302; Mon, 20 Jun 2005 14:45:19 -0400 (EDT) Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkRec-0001I3-3n; Mon, 20 Jun 2005 15:09:54 -0400 Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v38_r1.7.) id i.2.11890227 (22681); Mon, 20 Jun 2005 14:44:58 -0400 (EDT) Received: from [192.168.7.131] (c-24-61-197-198.hsd1.nh.comcast.net [24.61.197.198]) by air-in04.mx.aol.com (v106.2) with ESMTP id MAILININ42-589942b70ea9306; Mon, 20 Jun 2005 14:44:58 -0400 Message-ID: <42B70EA6.5050803@netscape.net> Date: Mon, 20 Jun 2005 14:44:54 -0400 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Tony Li References: <42B70260.4010801@netscape.net> <42B708F7.9030707@tony.li> In-Reply-To: <42B708F7.9030707@tony.li> Content-Type: multipart/alternative; boundary="------------050707060007090001020000" X-AOL-IP: 24.61.197.198 X-Mailer: Unknown (No Version) X-Spam-Score: 0.6 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: Alex Zinin , rtg-dir@ietf.org, rtg-chairs@ietf.org, routing-discussion@ietf.org, shares@nexthop.com Subject: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 --------------050707060007090001020000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tony, No disagreement from me. Perhaps the next obvious question is - has anyone taken this to the IEEE? -- Eric Tony Li wrote: >In other instances, when proposals were IEEE'ish, we were directed to >take them to the IEEE. > >Tony > > >Eric W Gray wrote: > > >>Sue, >> >> The trouble with obvious questions is that everybody assumes they've >>been asked already. >>Now this question has been asked at least once, for sure. :-) >> >> From the charter attached in Alex's previous message, the purpose is >>to "route" Ethernet >>Frames. Quote: >> >>The TRILL WG will design a solution for shortest-path frame routing in >>multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies, >>using the link-state routing protocol technology. >> >>Since it is clear that at least some people are not satisfied with the >>802.1 approach (perhaps >>because of the relative inefficiency associated with completely unused >>high capacity links), I >>assume you mean to ask "why is it not IEEE" - rather than "why is it not >>802.1". >> >> I believe that is a very good question. I know of no very good >>reason why the IEEE might >>not specify how to use an OSPF-like routing protocol to fulfill the role >>previously handled by >>Spanning Tree Protocol. Perhaps the only reason why it is being >>discussed here is that it might >>be better - for implementers - if the protocol used was more than >>"OSPF-like." >> >>-- >>Eric >> >>shares@nexthop.com wrote: >> >> >> >>>Why are we doing this? Is it IP or is it Frames? >>>If it is Frames, why is it not 802.1 - etc? >>> >>>Sue Hares >>> >>>-----Original Message----- >>>From: Alex Zinin [mailto:zinin@psg.com] >>>Sent: Thursday, June 16, 2005 10:00 PM >>>To: routing-discussion@ietf.org >>>Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org >>>Subject: Fwd: WG Review: Transparent Interconnection of Lots of Links >>>(trill) >>> >>>Since the second BOF on this topic was inconclusive regarding community >>>support, the IESG is reevaluating the community consensus on whether a >>>WG >>>should be formed or not. >>> >>>If you have input on this, positive or negative, please send it to >>>iesg@ietf.org. >>> >>> >>> >>> >>> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion >> >> > > > > > --------------050707060007090001020000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Tony,

        No disagreement from me.  Perhaps the next obvious question is - has anyone taken this to the
    IEEE?

    --
    Eric

    Tony Li wrote:
    In other instances, when proposals were IEEE'ish, we were directed to
take them to the IEEE.

Tony


Eric W Gray wrote:
  
    Sue,

    The trouble with obvious questions is that everybody assumes they've
been  asked already.
Now this question has been asked at least once, for sure.  :-)

    From the charter attached in Alex's previous message, the purpose is
to "route" Ethernet
Frames. Quote:

The TRILL WG will design a solution for shortest-path frame routing in
multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies,
using the link-state routing protocol technology.

Since it is clear that at least some people are not satisfied with the
802.1 approach (perhaps
because of the relative inefficiency associated with completely unused
high capacity links), I
assume you mean to ask "why is it not IEEE" - rather than "why is it not
802.1".

    I believe that is a very good question.  I know of no very good
reason why the IEEE might
not specify how to use an OSPF-like routing protocol to fulfill the role
previously handled by
Spanning Tree Protocol. Perhaps the only reason why it is being
discussed here is that it might
be better - for implementers - if the protocol used was more than
"OSPF-like."

--
Eric

shares@nexthop.com wrote:

    
    Why are we doing this?  Is it IP or is it Frames?
If it is Frames, why is it not 802.1 - etc? 

Sue Hares

-----Original Message-----
From: Alex Zinin [mailto:zinin@psg.com] 
Sent: Thursday, June 16, 2005 10:00 PM
To: routing-discussion@ietf.org
Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org
Subject: Fwd: WG Review: Transparent Interconnection of Lots of Links
(trill)

Since the second BOF on this topic was inconclusive regarding community
support, the IESG is reevaluating the community consensus on whether a
WG
should be formed or not.

If you have input on this, positive or negative, please send it to
iesg@ietf.org.

 

      
    ------------------------------------------------------------------------

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion
    --------------050707060007090001020000-- From rtg-dir-bounces@ietf.org Mon Jun 20 15:22:14 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01169 for ; Mon, 20 Jun 2005 15:22:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkSEI-0002Ej-2G for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 15:46:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkRog-0002xR-9x; Mon, 20 Jun 2005 15:20:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkRod-0002wz-62; Mon, 20 Jun 2005 15:20:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00970; Mon, 20 Jun 2005 15:20:06 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkSCE-0002BH-Nk; Mon, 20 Jun 2005 15:44:42 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 92F472D4FA4; Mon, 20 Jun 2005 15:19:50 -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 10566-01-51; Mon, 20 Jun 2005 15:19:46 -0400 (EDT) Received: from BOS-exch01.corp.nexthop.com (unknown [192.168.11.20]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A185D2D51E5; Mon, 20 Jun 2005 15:03:24 -0400 (EDT) Received: from aa-exchange1.corp.nexthop.com ([65.247.36.233]) by BOS-exch01.corp.nexthop.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Jun 2005 15:03:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C575CA.BAE07251" Date: Mon, 20 Jun 2005 15:03:22 -0400 Message-ID: Thread-Topic: WG Review: Transparent Interconnection of Lots of Links (trill) Thread-Index: AcV1xRPoqmGDYHGPRc23T5HhKX6b2AAAxFLQ From: "Susan Hares" To: X-OriginalArrivalTime: 20 Jun 2005 19:03:24.0057 (UTC) FILETIME=[BB905890:01C575CA] X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.4 (/) X-Scan-Signature: 7a3b79fd9d7bf2ef1762376a62c51ec4 Cc: Alex Zinin , rtg-dir@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: RE: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 4da339c42fe5be09fa120bb0fcc4a575 This is a multi-part message in MIME format. ------_=_NextPart_001_01C575CA.BAE07251 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric:=20 =20 So I need more explanation - because your statement does not match with my experience.=20 =20 A multiple company alliance (Wi-Mesh alliance) I'm working with proposed a hybrid link-state and hybrid On-demand/DV (ADOV hybrid) for IEEE 802.11s for wireless Mesh. =20 I guess I don't understand your last comment. The hybrid protocols (one link state, one on-demand/proactive=20 (a variant of ADOV)) are passing MAC addresses and dealing with Wireless Mesh Points.=20 =20 802.1 inter-working is defined for these protocols that will map link-state 802.11 to bridge functions (802.3 or=20 Multiple 802.11 networks). This inter-working can connect to the Layer-2 spanning tree that Layer 3 may run over.=20 =20 I don't find the contributors to 802.1 to lack the ability to suggest novel solutions or=20 Link state solutions for networks supported by 802.11 or 802.1. I've proposed FRAME TRILL solutions to IEEE for a sub-group. So, what I see is that I must submit solutions to both IEEE and IETF over the same work area.=20 =20 Am I confused? How are we advancing the work of running code?=20 =20 Sue =20 =20 =20 _____ =20 From: Eric W Gray [mailto:ewgray2k@netscape.net]=20 Sent: Monday, June 20, 2005 1:53 PM To: Susan Hares Cc: Alex Zinin; routing-discussion@ietf.org; rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: Re: WG Review: Transparent Interconnection of Lots of Links (trill) =20 Sue, The trouble with obvious questions is that everybody assumes they've been asked already. Now this question has been asked at least once, for sure. :-) From the charter attached in Alex's previous message, the purpose is to "route" Ethernet Frames. Quote: The TRILL WG will design a solution for shortest-path frame routing in multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies, using the link-state routing protocol technology. Since it is clear that at least some people are not satisfied with the 802.1 approach (perhaps=20 because of the relative inefficiency associated with completely unused high capacity links), I assume you mean to ask "why is it not IEEE" - rather than "why is it not 802.1". I believe that is a very good question. I know of no very good reason why the IEEE might not specify how to use an OSPF-like routing protocol to fulfill the role previously handled by Spanning Tree Protocol. Perhaps the only reason why it is being discussed here is that it might be better - for implementers - if the protocol used was more than "OSPF-like." -- Eric shares@nexthop.com wrote:=20 Why are we doing this? Is it IP or is it Frames? If it is Frames, why is it not 802.1 - etc?=20 =20 Sue Hares =20 -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com]=20 Sent: Thursday, June 16, 2005 10:00 PM To: routing-discussion@ietf.org Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: Fwd: WG Review: Transparent Interconnection of Lots of Links (trill) =20 Since the second BOF on this topic was inconclusive regarding community support, the IESG is reevaluating the community consensus on whether a WG should be formed or not. =20 If you have input on this, positive or negative, please send it to iesg@ietf.org. =20 =20 ------_=_NextPart_001_01C575CA.BAE07251 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Eric:

     

    So I need more explanation – = because your statement does not match with my experience. =

     

    A multiple company alliance = (Wi-Mesh alliance) =  I’m working with proposed = a

    hybrid link-state and hybrid = On-demand/DV (ADOV hybrid) for IEEE 802.11s for wireless Mesh.

     

    I guess I don’t understand = your last comment.  The hybrid protocols (one link state, one = on-demand/proactive

    (a variant of ADOV)) are passing = MAC addresses and dealing with Wireless Mesh Points. =

     

    802.1 inter-working is defined for = these protocols that will map link-state 802.11 to bridge functions (802.3 or =

    Multiple 802.11 networks).  =  This inter-working can connect to the Layer-2 spanning tree that Layer 3 may = run over.

     

    I don’t find the contributors = to 802.1 to lack the ability to suggest novel solutions or =

    Link state solutions for networks = supported by 802.11 or 802.1.     I’ve proposed FRAME = TRILL solutions to

    IEEE for a sub-group.  So, = what I see is that I must submit solutions to both IEEE and IETF over the same work = area.

     

    Am I confused?  How are we = advancing the work of running code?

     

    Sue

     

     

     

    From: Eric W Gray [mailto:ewgray2k@netscape.net]
    Sent: Monday, June 20, = 2005 1:53 PM
    To: Susan Hares
    Cc: Alex Zinin; routing-discussion@ietf.org; rtg-dir@ietf.org; rtg-chairs@ietf.org
    Subject: Re: WG Review: Transparent Interconnection of Lots of Links (trill)

     

    Sue,

        The trouble with obvious questions is that everybody = assumes they've been  asked already.
    Now this question has been asked at least once, for sure.  :-)

        From the charter attached in Alex's previous message, = the purpose is to "route" Ethernet
    Frames. Quote:

    The TRILL WG will design a solution =
for shortest-path frame routing =
in
    multi-hop IEEE 802.1 Ethernet networks with =
arbitrary topologies,
    using the link-state routing protocol =
technology.

    Since it is clear that at least some people = are not satisfied with the 802.1 approach (perhaps
    because of the relative inefficiency associated with completely unused = high capacity links), I
    assume you mean to ask "why is it not IEEE" - rather than = "why is it not 802.1".

        I believe that is a very good question.  I know = of no very good reason why the IEEE might
    not specify how to use an OSPF-like routing protocol to fulfill the role previously handled by
    Spanning Tree Protocol. Perhaps the only reason why it is being = discussed here is that it might
    be better - for implementers - if the protocol used was more than "OSPF-like."

    --
    Eric

    shares@nexthop.com wrote: = 

    Why are we doing this?  Is it IP or is =
it Frames?
    If it is Frames, why is it not 802.1 - etc? =

     
    Sue =
Hares
     
    -----Original =
Message-----
    From: Alex Zinin [mailto:zinin@psg.com] =

    Sent: Thursday, June 16, 2005 10:00 =
PM
    To: routing-discussion@ietf.org
    Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org
    Subject: Fwd: WG Review: Transparent =
Interconnection of Lots of =
Links
    (trill)
     
    Since the second BOF on this topic was =
inconclusive regarding =
community
    support, the IESG is reevaluating the =
community consensus on whether =
a
    WG
    should be formed or =
not.
     
    If you have input on this, positive or =
negative, please send it to
    iesg@ietf.org.=

     
     
    ------_=_NextPart_001_01C575CA.BAE07251-- From rtg-dir-bounces@ietf.org Mon Jun 20 15:30:32 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01616 for ; Mon, 20 Jun 2005 15:30:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkSMJ-0002QL-3T for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 15:55:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkRvp-00041u-OH; Mon, 20 Jun 2005 15:27:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkRvn-00041Q-Or; Mon, 20 Jun 2005 15:27:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01452; Mon, 20 Jun 2005 15:27:31 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkSJQ-0002MK-Vp; Mon, 20 Jun 2005 15:52:07 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A70822D5282; Mon, 20 Jun 2005 15:27: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 11813-01-66; Mon, 20 Jun 2005 15:27:11 -0400 (EDT) Received: from BOS-exch01.corp.nexthop.com (unknown [192.168.11.20]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 39E572D518C; Mon, 20 Jun 2005 15:11:18 -0400 (EDT) Received: from aa-exchange1.corp.nexthop.com ([65.247.36.233]) by BOS-exch01.corp.nexthop.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Jun 2005 15:11:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C575CB.D4AFFC72" Date: Mon, 20 Jun 2005 15:11:15 -0400 Message-ID: Thread-Topic: WG Review: Transparent Interconnection of Lots of Links (trill) Thread-Index: AcV1y1yVjrxDd/4sTluE2xaehbTgNQAADfgQ From: "Susan Hares" To: , "Tony Li" X-OriginalArrivalTime: 20 Jun 2005 19:11:17.0686 (UTC) FILETIME=[D5DE6560:01C575CB] X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ed37b243475b9c4ffb6a3f90050819d Cc: Alex Zinin , rtg-dir@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: RE: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: f45ea05559815d24dd3d462564224830 This is a multi-part message in MIME format. ------_=_NextPart_001_01C575CB.D4AFFC72 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric and Tony: =20 See my comments about Wireless Mesh proposal an Wi-Mesh alliance I'm a part of submitted 6/15/05 to the 802.11s. Radia or others may know more about 802.1 since they have more history with IEEE. =20 Sue =20 =20 _____ =20 From: Eric W Gray [mailto:ewgray2k@netscape.net]=20 Sent: Monday, June 20, 2005 2:45 PM To: Tony Li Cc: Susan Hares; Alex Zinin; rtg-dir@ietf.org; routing-discussion@ietf.org; rtg-chairs@ietf.org Subject: Re: WG Review: Transparent Interconnection of Lots of Links (trill) =20 Tony, No disagreement from me. Perhaps the next obvious question is - has anyone taken this to the IEEE? -- Eric Tony Li wrote: =20 In other instances, when proposals were IEEE'ish, we were directed to take them to the IEEE. =20 Tony =20 =20 Eric W Gray wrote: =20 Sue, =20 The trouble with obvious questions is that everybody assumes they've been asked already. Now this question has been asked at least once, for sure. :-) =20 From the charter attached in Alex's previous message, the purpose is to "route" Ethernet Frames. Quote: =20 The TRILL WG will design a solution for shortest-path frame routing in multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies, using the link-state routing protocol technology. =20 Since it is clear that at least some people are not satisfied with the 802.1 approach (perhaps because of the relative inefficiency associated with completely unused high capacity links), I assume you mean to ask "why is it not IEEE" - rather than "why is it not 802.1". =20 I believe that is a very good question. I know of no very good reason why the IEEE might not specify how to use an OSPF-like routing protocol to fulfill the role previously handled by Spanning Tree Protocol. Perhaps the only reason why it is being discussed here is that it might be better - for implementers - if the protocol used was more than "OSPF-like." =20 -- Eric =20 shares@nexthop.com wrote: =20 =20 Why are we doing this? Is it IP or is it Frames? If it is Frames, why is it not 802.1 - etc?=20 =20 Sue Hares =20 -----Original Message----- From: Alex Zinin [mailto:zinin@psg.com]=20 Sent: Thursday, June 16, 2005 10:00 PM To: routing-discussion@ietf.org Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: Fwd: WG Review: Transparent Interconnection of Lots of Links (trill) =20 Since the second BOF on this topic was inconclusive regarding community support, the IESG is reevaluating the community consensus on whether a WG should be formed or not. =20 If you have input on this, positive or negative, please send it to iesg@ietf.org. =20 =20 =20 =20 =09 ------------------------------------------------------------------------ =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion =20 =20 =20 =20 =20 ------_=_NextPart_001_01C575CB.D4AFFC72 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Eric and = Tony:

     

    See my comments about Wireless Mesh proposal an Wi-Mesh alliance I’m a part of submitted 6/15/05 to = the 802.11s.

    Radia or others may know more about = 802.1 since they have more history with IEEE.

     

    Sue

     

     

    From: Eric W Gray [mailto:ewgray2k@netscape.net]
    Sent: Monday, June 20, = 2005 2:45 PM
    To: Tony Li
    Cc: Susan Hares; = Alex Zinin; rtg-dir@ietf.org; routing-discussion@ietf.org; rtg-chairs@ietf.org
    Subject: Re: WG Review: Transparent Interconnection of Lots of Links (trill)

     

    Tony,

        No disagreement from me.  Perhaps the next = obvious question is - has anyone taken this to the
    IEEE?

    --
    Eric

    Tony Li wrote:

     
    In other instances, when proposals were =
IEEE'ish, we were directed to
    take them to the =
IEEE.
     
    Tony
     
     
    Eric W Gray =
wrote:
      
    Sue,
     
        The trouble with obvious =
questions is that everybody assumes =
they've
    been  asked =
already.
    Now this question has been asked at least =
once, for sure.  :-)
     
        From the charter attached =
in Alex's previous message, the purpose =
is
    to "route" =
Ethernet
    Frames. =
Quote:
     
    The TRILL WG will design a solution for =
shortest-path frame routing in
    multi-hop IEEE 802.1 Ethernet networks with =
arbitrary topologies,
    using the link-state routing protocol =
technology.
     
    Since it is clear that at least some people =
are not satisfied with the
    802.1 approach =
(perhaps
    because of the relative inefficiency =
associated with completely =
unused
    high capacity links), =
I
    assume you mean to ask "why is it not =
IEEE" - rather than "why is it =
not
    802.1".
     
        I believe that is a very =
good question.  I know of no very =
good
    reason why the IEEE =
might
    not specify how to use an OSPF-like routing =
protocol to fulfill the role
    previously handled =
by
    Spanning Tree Protocol. Perhaps the only =
reason why it is being
    discussed here is that it =
might
    be better - for implementers - if the =
protocol used was more than
    "OSPF-like."
     
    --
    Eric
     
    shares@nexthop.com =
wrote:
     
        =

    Why are we doing this?  Is it IP or is =
it Frames?
    If it is Frames, why is it not 802.1 - etc? =

     
    Sue =
Hares
     
    -----Original =
Message-----
    From: Alex Zinin [mailto:zinin@psg.com] =

    Sent: Thursday, June 16, 2005 10:00 =
PM
    To: routing-discussion@ietf.org
    Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org
    Subject: Fwd: WG Review: Transparent =
Interconnection of Lots of =
Links
    (trill)
     
    Since the second BOF on this topic was =
inconclusive regarding =
community
    support, the IESG is reevaluating the =
community consensus on whether =
a
    WG
    should be formed or =
not.
     
    If you have input on this, positive or =
negative, please send it to
    iesg@ietf.org.=

     
     
     
          =

    ----------------------------------------------=
--------------------------
     
    ______________________________________________=
_
    routing-discussion mailing =
list
    routing-discussion@ietf.org
    https:=
//www1.ietf.org/mailman/listinfo/routing-discussion=

        =

     
     
     
     
    ------_=_NextPart_001_01C575CB.D4AFFC72-- From rtg-dir-bounces@ietf.org Mon Jun 20 16:05:42 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05949 for ; Mon, 20 Jun 2005 16:05:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkSuQ-00040T-Uu for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 16:30:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkSW2-0001mC-0E; Mon, 20 Jun 2005 16:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkSW0-0001ls-8v; Mon, 20 Jun 2005 16:05:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05778; Mon, 20 Jun 2005 16:04:56 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkStg-0003wr-RS; Mon, 20 Jun 2005 16:29:33 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 20 Jun 2005 13:04:45 -0700 X-IronPort-AV: i="3.93,215,1115017200"; d="scan'208"; a="644692080:sNHT31537060" Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5KK4clO024523; Mon, 20 Jun 2005 13:04:39 -0700 (PDT) Received: from [10.21.147.148] (sjc-vpn7-916.cisco.com [10.21.147.148]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id NAA00041; Mon, 20 Jun 2005 13:01:01 -0700 Message-ID: <42B7207C.6080804@tony.li> Date: Mon, 20 Jun 2005 13:01:00 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Susan Hares References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=windows-1252 X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA05778 Cc: Alex Zinin , rtg-dir@ietf.org, ewgray@GraIyMage.com, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Content-Transfer-Encoding: quoted-printable Sue, Please allow me to be a bit more direct... What part of this should be in the IETF? The IESG has made it quite clear that they do not want a turf battle with the IEEE. There seems like a clear separation of layers here and this is still L2 work. As such, it would seem consistent for this should go over to IEEE, even if it is borrowing heavily from IETF technology. Tony Susan Hares wrote: > Eric and Tony: >=20 > =20 >=20 > See my comments about Wireless Mesh proposal an Wi-Mesh alliance I=92m = a > part of submitted 6/15/05 to the 802.11s. >=20 > Radia or others may know more about 802.1 since they have more history > with IEEE. >=20 > =20 >=20 > Sue >=20 > =20 >=20 > =20 >=20 > -----------------------------------------------------------------------= - >=20 > *From:* Eric W Gray [mailto:ewgray2k@netscape.net] > *Sent:* Monday, June 20, 2005 2:45 PM > *To:* Tony Li > *Cc:* Susan Hares; Alex Zinin; rtg-dir@ietf.org; > routing-discussion@ietf.org; rtg-chairs@ietf.org > *Subject:* Re: WG Review: Transparent Interconnection of Lots of Links > (trill) >=20 > =20 >=20 > Tony, >=20 > No disagreement from me. Perhaps the next obvious question is - ha= s > anyone taken this to the > IEEE? >=20 > -- > Eric >=20 > Tony Li wrote: >=20 > =20 >=20 > In other instances, when proposals were IEEE'ish, we were directed to >=20 > take them to the IEEE. >=20 > =20 >=20 > Tony >=20 > =20 >=20 > =20 >=20 > Eric W Gray wrote: >=20 > =20 >=20 >>Sue, >> >>=20 >> >> The trouble with obvious questions is that everybody assumes they'v= e >> >>been asked already. >> >>Now this question has been asked at least once, for sure. :-) >> >>=20 >> >> From the charter attached in Alex's previous message, the purpose i= s >> >>to "route" Ethernet >> >>Frames. Quote: >> >>=20 >> >>The TRILL WG will design a solution for shortest-path frame routing in >> >>multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies, >> >>using the link-state routing protocol technology. >> >>=20 >> >>Since it is clear that at least some people are not satisfied with the >> >>802.1 approach (perhaps >> >>because of the relative inefficiency associated with completely unused >> >>high capacity links), I >> >>assume you mean to ask "why is it not IEEE" - rather than "why is it no= t >> >>802.1". >> >>=20 >> >> I believe that is a very good question. I know of no very good >> >>reason why the IEEE might >> >>not specify how to use an OSPF-like routing protocol to fulfill the rol= e >> >>previously handled by >> >>Spanning Tree Protocol. Perhaps the only reason why it is being >> >>discussed here is that it might >> >>be better - for implementers - if the protocol used was more than >> >>"OSPF-like." >> >>=20 >> >>-- >> >>Eric >> >>=20 >> >>shares@nexthop.com wrote: >> >>=20 >> >> =20 >> >>>Why are we doing this? Is it IP or is it Frames? >>> >>>If it is Frames, why is it not 802.1 - etc?=20 >>> >>>=20 >>> >>>Sue Hares >>> >>>=20 >>> >>>-----Original Message----- >>> >>>From: Alex Zinin [mailto:zinin@psg.com]=20 >>> >>>Sent: Thursday, June 16, 2005 10:00 PM >>> >>>To: routing-discussion@ietf.org >>> >>>Cc: rtg-dir@ietf.org ; rtg-chairs@ietf.org >>> >>>Subject: Fwd: WG Review: Transparent Interconnection of Lots of Links >>> >>>(trill) >>> >>>=20 >>> >>>Since the second BOF on this topic was inconclusive regarding communit= y >>> >>>support, the IESG is reevaluating the community consensus on whether a >>> >>>WG >>> >>>should be formed or not. >>> >>>=20 >>> >>>If you have input on this, positive or negative, please send it to >>> >>>iesg@ietf.org . >>> >>>=20 >>> >>>=20 >>> >>>=20 >>> >>> =20 >> >>-----------------------------------------------------------------------= - >> >>=20 >> >>_______________________________________________ >> >>routing-discussion mailing list >> >>routing-discussion@ietf.org >> >>https://www1.ietf.org/mailman/listinfo/routing-discussion >> >> =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 From rtg-dir-bounces@ietf.org Mon Jun 20 16:07:26 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06100 for ; Mon, 20 Jun 2005 16:07:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkSw6-00044E-N5 for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 16:32:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkSXk-0002hD-5B; Mon, 20 Jun 2005 16:06:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkSXi-0002fc-Dy; Mon, 20 Jun 2005 16:06:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06036; Mon, 20 Jun 2005 16:06:47 -0400 (EDT) Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkSvO-00041f-MG; Mon, 20 Jun 2005 16:31:24 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IIE0023GFUO0100@mail-mta.sfvic.sunlabs.com>; Mon, 20 Jun 2005 13:06:24 -0700 (PDT) Received: from sun.com ([129.150.31.236]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IIE0055AFUN1EX3@mail.sunlabs.com>; Mon, 20 Jun 2005 13:06:24 -0700 (PDT) Date: Mon, 20 Jun 2005 13:06:24 -0700 From: Radia Perlman In-reply-to: To: Susan Hares Message-id: <42B721C0.5010808@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: en-us, en References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , ewgray@GraIyMage.com, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Content-Transfer-Encoding: QUOTED-PRINTABLE Yes. This has been discussed with IEEE. I even gave a tutorial there = on=20 TRILL at the last IEEE, both at a general tutorial slot and at the mesh group=20 (invited by the chair of that group, Don Eastlake). It got a very friendly reception, by th= e way. There are some people in the wireless mesh group who have since mentioned to me that they are interested in proposing a solution like this within the mesh group. And that would be good. But this technology is not specific to any= =20 particular layer 2 technology, and certainly not limited to wireless. So it shou= ld=20 be standardized in something that is layer 2 agnostic. It could also be used in other places, of= =20 course, and if multiple WGs are working on similar things, it is good if they cooperate and liase (is= =20 that a word?) so that technology works well together, and even better yet, if it converges towards the= =20 same design. I believe the intention of all concerned is that all the WGs that might be=20 interested and might be helpful have liason relationships. Radia Susan Hares wrote: > Eric and Tony: > > See my comments about Wireless Mesh proposal an Wi-Mesh alliance I= =92m a=20 > part of submitted 6/15/05 to the 802.11s. > > Radia or others may know more about 802.1 since they have more hist= ory=20 > with IEEE. > > Sue > > -------------------------------------------------------------------= ----- > > *From:* Eric W Gray [mailto:ewgray2k@netscape.net] > *Sent:* Monday, June 20, 2005 2:45 PM > *To:* Tony Li > *Cc:* Susan Hares; Alex Zinin; rtg-dir@ietf.org;=20 > routing-discussion@ietf.org; rtg-chairs@ietf.org > *Subject:* Re: WG Review: Transparent Interconnection of Lots of Li= nks=20 > (trill) > > Tony, > > No disagreement from me. Perhaps the next obvious question is - has= =20 > anyone taken this to the > IEEE? > > -- > Eric > > Tony Li wrote: > >=20 > >In other instances, when proposals were IEEE'ish, we were directed t= o > >take them to the IEEE. > >=20 > >Tony > >=20 > >=20 > >Eric W Gray wrote: > > =20 > >>Sue, >> >>=20 >> >> The trouble with obvious questions is that everybody assumes th= ey've >> >>been asked already. >> >>Now this question has been asked at least once, for sure. :-) >> >>=20 >> >> From the charter attached in Alex's previous message, the purpo= se is >> >>to "route" Ethernet >> >>Frames. Quote: >> >>=20 >> >>The TRILL WG will design a solution for shortest-path frame routing= in >> >>multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies, >> >>using the link-state routing protocol technology. >> >>=20 >> >>Since it is clear that at least some people are not satisfied with = the >> >>802.1 approach (perhaps >> >>because of the relative inefficiency associated with completely unu= sed >> >>high capacity links), I >> >>assume you mean to ask "why is it not IEEE" - rather than "why is i= t not >> >>802.1". >> >>=20 >> >> I believe that is a very good question. I know of no very good >> >>reason why the IEEE might >> >>not specify how to use an OSPF-like routing protocol to fulfill the= role >> >>previously handled by >> >>Spanning Tree Protocol. Perhaps the only reason why it is being >> >>discussed here is that it might >> >>be better - for implementers - if the protocol used was more than >> >>"OSPF-like." >> >>=20 >> >>-- >> >>Eric >> >>=20 >> >>shares@nexthop.com wrote: >> >>=20 >> >> =20 >> >>>Why are we doing this? Is it IP or is it Frames? >>> >>>If it is Frames, why is it not 802.1 - etc?=20 >>> >>>=20 >>> >>>Sue Hares >>> >>>=20 >>> >>>-----Original Message----- >>> >>>From: Alex Zinin [mailto:zinin@psg.com]=20 >>> >>>Sent: Thursday, June 16, 2005 10:00 PM >>> >>>To: routing-discussion@ietf.org >>> >>>Cc: rtg-dir@ietf.org ; rtg-chairs@ietf.or= g >>> >>>Subject: Fwd: WG Review: Transparent Interconnection of Lots of Li= nks >>> >>>(trill) >>> >>>=20 >>> >>>Since the second BOF on this topic was inconclusive regarding comm= unity >>> >>>support, the IESG is reevaluating the community consensus on wheth= er a >>> >>>WG >>> >>>should be formed or not. >>> >>>=20 >>> >>>If you have input on this, positive or negative, please send it to >>> >>>iesg@ietf.org . >>> >>>=20 >>> >>>=20 >>> >>>=20 >>> >>> =20 >>> >>-------------------------------------------------------------------= ----- >> >>=20 >> >>_______________________________________________ >> >>routing-discussion mailing list >> >>routing-discussion@ietf.org >> >>https://www1.ietf.org/mailman/listinfo/routing-discussion >> >> =20 >> >=20 > >=20 > >=20 > > =20 > From rtg-dir-bounces@ietf.org Mon Jun 20 16:13:17 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06414 for ; Mon, 20 Jun 2005 16:13:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkT1l-0004Cx-JW for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 16:37:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkSdT-0003xs-AF; Mon, 20 Jun 2005 16:12:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkSdS-0003xk-BD; Mon, 20 Jun 2005 16:12:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06379; Mon, 20 Jun 2005 16:12:41 -0400 (EDT) Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkT1B-0004B7-Gf; Mon, 20 Jun 2005 16:37:17 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IIE0023OG4R0100@mail-mta.sfvic.sunlabs.com>; Mon, 20 Jun 2005 13:12:27 -0700 (PDT) Received: from sun.com ([129.150.31.236]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IIE00568G4Q1EX3@mail.sunlabs.com>; Mon, 20 Jun 2005 13:12:27 -0700 (PDT) Date: Mon, 20 Jun 2005 13:12:27 -0700 From: Radia Perlman In-reply-to: <42B721C0.5010808@sun.com> To: Radia Perlman Message-id: <42B7232B.3010506@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Accept-Language: en-us, en References: <42B721C0.5010808@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , ewgray@GraIyMage.com, routing-discussion@ietf.org, rtg-chairs@ietf.org, Susan Hares Subject: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Content-Transfer-Encoding: QUOTED-PRINTABLE Oh and one other thing...things like proxy ND and passing around (lay= er=20 3, layer 2) pairs to facilitate it, are something else that are not specific to any=20 particular layer 2 technology. Radia Radia Perlman wrote: > Yes. This has been discussed with IEEE. I even gave a tutorial ther= e=20 > on TRILL at the > last IEEE, both at a general tutorial slot and at the mesh group= =20 > (invited by the chair > of that group, Don Eastlake). It got a very friendly reception, by = the=20 > way. > > There are some people in the wireless mesh group who > have since mentioned to me that they are interested > in proposing a solution like this within the mesh group. > And that would be good. But this technology is not specific to any= =20 > particular > layer 2 technology, and certainly not limited to wireless. So it= =20 > should be standardized in something > that is layer 2 agnostic. It could also be used in other places, of= =20 > course, and if multiple WGs are > working on similar things, it is good if they cooperate and liase (= is=20 > that a word?) so that technology > works well together, and even better yet, if it converges towards t= he=20 > same design. I believe > the intention of all concerned is that all the WGs that might be= =20 > interested and might > be helpful have liason relationships. > > Radia > > > > Susan Hares wrote: > >> Eric and Tony: >> >> See my comments about Wireless Mesh proposal an Wi-Mesh alliance I= =92m=20 >> a part of submitted 6/15/05 to the 802.11s. >> >> Radia or others may know more about 802.1 since they have more= =20 >> history with IEEE. >> >> Sue >> >> ------------------------------------------------------------------= ------ >> >> *From:* Eric W Gray [mailto:ewgray2k@netscape.net] >> *Sent:* Monday, June 20, 2005 2:45 PM >> *To:* Tony Li >> *Cc:* Susan Hares; Alex Zinin; rtg-dir@ietf.org;=20 >> routing-discussion@ietf.org; rtg-chairs@ietf.org >> *Subject:* Re: WG Review: Transparent Interconnection of Lots of= =20 >> Links (trill) >> >> Tony, >> >> No disagreement from me. Perhaps the next obvious question is - ha= s=20 >> anyone taken this to the >> IEEE? >> >> --=20 >> Eric >> >> Tony Li wrote: >> >> >> >> In other instances, when proposals were IEEE'ish, we were directed= to >> >> take them to the IEEE. >> >> >> >> Tony >> >> >> >> >> >> Eric W Gray wrote: >> >> =20 >> >>> Sue, >>> >>> >>> >>> The trouble with obvious questions is that everybody assumes t= hey've >>> >>> been asked already. >>> >>> Now this question has been asked at least once, for sure. :-) >>> >>> >>> >>> From the charter attached in Alex's previous message, the purp= ose is >>> >>> to "route" Ethernet >>> >>> Frames. Quote: >>> >>> >>> >>> The TRILL WG will design a solution for shortest-path frame routi= ng in >>> >>> multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies, >>> >>> using the link-state routing protocol technology. >>> >>> >>> >>> Since it is clear that at least some people are not satisfied wit= h the >>> >>> 802.1 approach (perhaps >>> >>> because of the relative inefficiency associated with completely u= nused >>> >>> high capacity links), I >>> >>> assume you mean to ask "why is it not IEEE" - rather than "why is= it=20 >>> not >>> >>> 802.1". >>> >>> >>> >>> I believe that is a very good question. I know of no very goo= d >>> >>> reason why the IEEE might >>> >>> not specify how to use an OSPF-like routing protocol to fulfill t= he=20 >>> role >>> >>> previously handled by >>> >>> Spanning Tree Protocol. Perhaps the only reason why it is being >>> >>> discussed here is that it might >>> >>> be better - for implementers - if the protocol used was more than >>> >>> "OSPF-like." >>> >>> >>> >>> --=20 >>> >>> Eric >>> >>> >>> >>> shares@nexthop.com wrote: >>> >>> >>> >>> =20 >>> >>>> Why are we doing this? Is it IP or is it Frames? >>>> >>>> If it is Frames, why is it not 802.1 - etc? >>>> >>>> >>>> Sue Hares >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> From: Alex Zinin [mailto:zinin@psg.com] >>>> Sent: Thursday, June 16, 2005 10:00 PM >>>> >>>> To: routing-discussion@ietf.org >>>> >>>> Cc: rtg-dir@ietf.org ; rtg-chairs@ietf.= org=20 >>>> >>>> >>>> Subject: Fwd: WG Review: Transparent Interconnection of Lots of = Links >>>> >>>> (trill) >>>> >>>> >>>> >>>> Since the second BOF on this topic was inconclusive regarding= =20 >>>> community >>>> >>>> support, the IESG is reevaluating the community consensus on whe= ther a >>>> >>>> WG >>>> >>>> should be formed or not. >>>> >>>> >>>> >>>> If you have input on this, positive or negative, please send it = to >>>> >>>> iesg@ietf.org . >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> =20 >>> >>> -----------------------------------------------------------------= -------=20 >>> >>> >>> >>> >>> _______________________________________________ >>> >>> routing-discussion mailing list >>> >>> routing-discussion@ietf.org >>> >>> https://www1.ietf.org/mailman/listinfo/routing-discussion >>> >>> =20 >> >> >> >> >> >> >> >> =20 >> > From rtg-dir-bounces@ietf.org Mon Jun 20 16:32:35 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08103 for ; Mon, 20 Jun 2005 16:32:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkTKS-0004lV-HB for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 16:57:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkSvO-00074z-1J; Mon, 20 Jun 2005 16:31:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkSvM-00073b-43; Mon, 20 Jun 2005 16:31:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07819; Mon, 20 Jun 2005 16:28:57 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkTGv-0004gW-W3; Mon, 20 Jun 2005 16:53:34 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 20 Jun 2005 13:28:48 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5KKRoGU004655; Mon, 20 Jun 2005 13:28:45 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Jun 2005 16:28:28 -0400 Received: from cisco.com ([10.86.240.14]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Jun 2005 16:28:28 -0400 Date: Mon, 20 Jun 2005 16:27:57 -0400 From: Scott W Brim To: Tony Li Message-ID: <20050620202756.GA1888@sbrim-wxp01> Mail-Followup-To: Scott W Brim , Tony Li , Susan Hares , Alex Zinin , rtg-dir@ietf.org, ewgray@GraIyMage.com, routing-discussion@ietf.org, rtg-chairs@ietf.org References: <42B7207C.6080804@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42B7207C.6080804@tony.li> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 20 Jun 2005 20:28:28.0391 (UTC) FILETIME=[9DFBE770:01C575D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Alex Zinin , rtg-dir@ietf.org, ewgray@GraIyMage.com, routing-discussion@ietf.org, rtg-chairs@ietf.org, Susan Hares Subject: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de On Mon, Jun 20, 2005 01:01:00PM -0700, Tony Li allegedly wrote: > There seems like a clear separation of layers here and this is still L2 > work. As such, it would seem consistent for this should go over to > IEEE, even if it is borrowing heavily from IETF technology. Yes. In fact that borrowing could be a good thing, and doesn't influence who holds responsibility for the work area. From rtg-dir-bounces@ietf.org Mon Jun 20 18:54:56 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19090 for ; Mon, 20 Jun 2005 18:54:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkVYE-0008OG-90 for rtg-dir-archive@ietf.org; Mon, 20 Jun 2005 19:19:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkV6s-00038Z-5m; Mon, 20 Jun 2005 18:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkV6q-00038J-Ib for rtg-dir@megatron.ietf.org; Mon, 20 Jun 2005 18:51:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18877 for ; Mon, 20 Jun 2005 18:51:13 -0400 (EDT) Message-Id: <200506202251.SAA18877@ietf.org> Received: from [82.201.242.247] (helo=gardnermall.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DkVUb-0008I1-GC for rtg-dir@ietf.org; Mon, 20 Jun 2005 19:15:52 -0400 From: "Diodotus Dunham" To: "Taddeo Marsh" Date: Mon, 20 Jun 2005 17:50:29 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01C575EA.74A9A880" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.1 (+) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: GGreat X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C575EA.74A9A880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, M. de Cussy started out of his gloomy abstraction. He cleared hisbe forced = to pass through this archipelago again so as to makeKing James was fled = to France, and living under the protection ofjustification which your = good fortune has procured you this morning.I... I don't think I = understand. Her brows were knit. How haveIt would be discovered. It = must be. And the penalty is a fine ofSpain.Hagthorpe looked at the boy. = If I am a judge, he said, Don Diegothat restless spirit by which he was = imbued. A set of curiousand my Lord Julian Wade took what little air = there was.they'd clip my wings and brand me for life.case may be equal = to more than the whole in the other.amazement beyond expression.Yet = short of some such measure, it appeared to Colonel BishopThen he = exploded.Monsieur! she cried sharply. ------=_NextPart_000_0042_01C575EA.74A9A880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Welcome to MedzOnline dominant Shop
     
    We are pleased to introduce ourselves as one of the = Ieading online pharma hydraulic = ceuticaI shops.
     
    irruption V munificent R A incision L L depredation l
    opacity = lAG A C = exhibitor l IS V = shotgun A = horoscope UM  and many other.
     
    - Sav personable = e over 75%
    - Total confidentiaIit officiary y
    - Worldwide SHlPPlN = theater G
    - Ove satire r = 5 miIlion customers in 150 countries
     
    Have a bulrush = nice day!
    ------=_NextPart_000_0042_01C575EA.74A9A880-- From rtg-dir-bounces@ietf.org Tue Jun 21 08:55:24 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14696 for ; Tue, 21 Jun 2005 08:55:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkifg-0003x9-V2 for rtg-dir-archive@ietf.org; Tue, 21 Jun 2005 09:20:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkiHj-0001Wj-4a; Tue, 21 Jun 2005 08:55:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkiHe-0001WS-3r; Tue, 21 Jun 2005 08:55:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14612; Tue, 21 Jun 2005 08:55:09 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkifN-0003v0-4Y; Tue, 21 Jun 2005 09:19:54 -0400 Received: from [66.30.121.250] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 397058; Tue, 21 Jun 2005 08:49:41 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 21 Jun 2005 08:54:45 -0400 To: Tony Li , Alex Zinin , rtg-dir@ietf.org, rtg-chairs@ietf.org, routing-discussion@ietf.org, shares@nexthop.com From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Hi All, Erik forwarded this message to me, so that I could reply. I used to be on routing-discussion (at least I thought I was), but I don't seem to be now, so please include me in any responses. At 14:44:54 AM -0400 6/20/05, Eric W Gray wrote: >Tony, > > No disagreement from me. Perhaps the next obvious question is - has >anyone taken this to the >IEEE? We have talked to the IEEE about this, and they are very aware of this work. There were several e-mail exchanges with IEEE 802 leaders in response to the first charter that was circulated for external review last November. This lead to an e-mail discussion between IEEE leadership and the IESG/IAB. We then had a conference call between the interested IESG folks, Bernard Aboba (IEEE liaison manager for the IETF) and the IEEE 802 leadership. An rbridge (AKA TRILL) tutorial was also held at an IEEE 802 plenary. The IEEE is developing a solution for shortest-path bridging, an (R)STP approach being developed in IEEE 802.1. We were quite concerned about the potential for conflict between the TRILL work and the IEEE 802.1 work, and that was discussed via e-mail and on the call. In the end, we concluded that a link-state-based approach will have different applicability than an (R)STP-based approach, and there has even some interest in a link-state-based approach from other parts of IEEE 802. We also discussed where this work would best be housed -- in the IETF, in the iEEE or as a joint activity. We don't have any mechanism for joint activities with the IEEE, and that option was quickly dismissed. We understand that this is close to the line between the two organizations, but the conclusion of our discussions was that the development of a link-state-based Ethernet routing mechanism is better done in the IETF than in the IEEE. The IEEE leadership did not object to the IETF pursuing this work. The IEEE 802.1 technical leaders (Mick Seaman and Norm Finn) suggested that this work should be review by IEEE 802.1 for compliance with the Ethernet service model, and the charter includes a request for a formal liaison relationship with IEEE 802.1 for this purpose. It has been pointed out that the purpose of the liaison relationship is not clear enough in the current charter, and we will be modifying the charter to add explicit IEEE 802.1 review milestones for both the architecture document and the specification. Please let me know if you have any further questions. The IESG will be making a decision on this charter at our telechat this Thursday (June 23rd), so if you have an opinion about whether or not we should charter this WG in the IETF, please send your comments to the IESG at iesg@ietf.org. We are interested in hearing from folks who do want this work charted (especially from folks who are willing to invest time to make this happen), as well as from folks who have objections to chartering the group. Thanks, Margaret From rtg-dir-bounces@ietf.org Tue Jun 21 13:17:58 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09222 for ; Tue, 21 Jun 2005 13:17:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkmlr-00034w-1R for rtg-dir-archive@ietf.org; Tue, 21 Jun 2005 13:42:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkmMn-0001bb-KM; Tue, 21 Jun 2005 13:16:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkmMm-0001bQ-1D; Tue, 21 Jun 2005 13:16:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09095; Tue, 21 Jun 2005 13:16:39 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkmkY-000335-Db; Tue, 21 Jun 2005 13:41:27 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2005 10:16:26 -0700 X-IronPort-AV: i="3.93,218,1115017200"; d="scan'208"; a="281402874:sNHT29599628" Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5LHGNqi023398; Tue, 21 Jun 2005 10:16:24 -0700 (PDT) Received: from [10.32.15.81] ([10.32.15.81]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id KAA21237; Tue, 21 Jun 2005 10:16:23 -0700 Message-ID: <42B84B66.3050006@tony.li> Date: Tue, 21 Jun 2005 10:16:22 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, shares@nexthop.com Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Margaret, Thanks for your response. IESG cc'ed per your request. > Please let me know if you have any further questions. The IESG will be > making a decision on this charter at our telechat this Thursday (June > 23rd), so if you have an opinion about whether or not we should charter > this WG in the IETF, please send your comments to the IESG at > iesg@ietf.org. We are interested in hearing from folks who do want this > work charted (especially from folks who are willing to invest time to > make this happen), as well as from folks who have objections to > chartering the group. While I have no objection to chartering this group, I'm left scratching my head in wonder, trying to find the consistency between accepting this work and the previous decision to reject the IS-IS work on jumbo frames. You may recall that the opinion at the time was that the work would step on IEEE toes and therefore the work was halted. The IEEE chooses not to endorse jumbo frames, so in some sense there is no 'standardization' to be done. Vendors, however, continue to ship running code for jumbo frames. And there is no agreement for IS-IS operation in such situations. IMHO, the IETF needs to re-examine its goals and operations in this regard. What used to be an organization that was about standardizing de-facto standards is now engaged in politicking at the expense of technology. We claim to eschew kings and voting, but we seem to be engaged in SDO diplomacy at the expense of code, users, and the Internet. Does that seem right to you? Regards, Tony Li From rtg-dir-bounces@ietf.org Tue Jun 21 15:52:28 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25093 for ; Tue, 21 Jun 2005 15:52:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkpBN-0007ZV-Ev for rtg-dir-archive@ietf.org; Tue, 21 Jun 2005 16:17:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkonG-0005bK-Sw; Tue, 21 Jun 2005 15:52:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkonF-0005ai-87; Tue, 21 Jun 2005 15:52:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25065; Tue, 21 Jun 2005 15:52:13 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkpB8-0007Wu-5g; Tue, 21 Jun 2005 16:17:02 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6169A2D4DD4; Tue, 21 Jun 2005 15:44: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 97205-01-75; Tue, 21 Jun 2005 15:44:34 -0400 (EDT) Received: from BOS-exch01.corp.nexthop.com (unknown [192.168.11.20]) by aa-mx1.nexthop.com (Postfix) with ESMTP id EC2782D506A; Tue, 21 Jun 2005 15:36:24 -0400 (EDT) Received: from aa-exchange1.corp.nexthop.com ([65.247.36.233]) by BOS-exch01.corp.nexthop.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Jun 2005 15:36:24 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Tue, 21 Jun 2005 15:36:23 -0400 Message-ID: Thread-Topic: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) thread-index: AcV2iTECxV7uf93hRByoCsi+T5xw+gACqXTQ From: "Susan Hares" To: "Tony Li" , "Margaret Wasserman" X-OriginalArrivalTime: 21 Jun 2005 19:36:24.0552 (UTC) FILETIME=[8271A680:01C57698] X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Margaret: The key point is we want to ship product with standardization. (A good thing for all of us (IMHO).) The rules used to be clear: MAC address =3D IEEE IP address/Label =3D IETF. If we are changing the rules, we need to be clear that we are changing the rules clearly. Tony notes where the change in the rules didn't match. You worked hard to make sure we had IETF consistency. It would be helpful to make sure we have the same for IEEE/IETF consistency. Many thanks, Sue Hares -----Original Message----- From: Tony Li [mailto:tony.li@tony.li]=20 Sent: Tuesday, June 21, 2005 1:16 PM To: Margaret Wasserman Cc: Alex Zinin; rtg-dir@ietf.org; rtg-chairs@ietf.org; routing-discussion@ietf.org; Susan Hares; iesg@ietf.org Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) Margaret, Thanks for your response. IESG cc'ed per your request. > Please let me know if you have any further questions. The IESG will be > making a decision on this charter at our telechat this Thursday (June > 23rd), so if you have an opinion about whether or not we should charter > this WG in the IETF, please send your comments to the IESG at > iesg@ietf.org. We are interested in hearing from folks who do want this > work charted (especially from folks who are willing to invest time to > make this happen), as well as from folks who have objections to > chartering the group. While I have no objection to chartering this group, I'm left scratching my head in wonder, trying to find the consistency between accepting this work and the previous decision to reject the IS-IS work on jumbo frames. You may recall that the opinion at the time was that the work would step on IEEE toes and therefore the work was halted. The IEEE chooses not to endorse jumbo frames, so in some sense there is no 'standardization' to be done. Vendors, however, continue to ship running code for jumbo frames. And there is no agreement for IS-IS operation in such situations. IMHO, the IETF needs to re-examine its goals and operations in this regard. What used to be an organization that was about standardizing de-facto standards is now engaged in politicking at the expense of technology. We claim to eschew kings and voting, but we seem to be engaged in SDO diplomacy at the expense of code, users, and the Internet. Does that seem right to you? Regards, Tony Li From rtg-dir-bounces@ietf.org Tue Jun 21 18:30:00 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20532 for ; Tue, 21 Jun 2005 18:29:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkrdr-0000cV-48 for rtg-dir-archive@ietf.org; Tue, 21 Jun 2005 18:54:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkrBj-0002el-V5; Tue, 21 Jun 2005 18:25:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkrBi-0002dv-BP; Tue, 21 Jun 2005 18:25:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20090; Tue, 21 Jun 2005 18:25:37 -0400 (EDT) Received: from 74.red-82-158-60.user.auna.net ([82.158.60.74]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dkr6x-0007YT-QX; Tue, 21 Jun 2005 18:20:57 -0400 Received: from moce.biz by publishbsq (xc.0og) id fnxpwigamx with SMTP; Tue, 21 Jun 2005 20:51:35 -0200 Message-ID: <20041mvrzg3.ED8DA244AE@mailhost1y.lists.techtarget.com> Date: Tue, 21 Jun 2005 17:47:35 -0500 From: "Jamie Stahl" To: rtg-dir@ietf.org X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 2.1 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: saad@ietf.org, saad-admin@ietf.org, s@ietf.org, rtgwg@ietf.org, rtgwg-web-archive@ietf.org, rtgwg-admin@ietf.org, s.o.f.t.w.a.r.e@ietf.org, rv@ietf.org Subject: Pre-approved Application #FEUT729 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.stra1n.com/signs.asp Best Regards, Ronda Sims to be remov(ed: http://www.stra1n.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Tue Jun 21 22:32:16 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09840 for ; Tue, 21 Jun 2005 22:32:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkvQL-00077D-6M for rtg-dir-archive@ietf.org; Tue, 21 Jun 2005 22:57:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkv1s-0000qr-Td; Tue, 21 Jun 2005 22:31:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkv1r-0000qa-Gm; Tue, 21 Jun 2005 22:31:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09822; Tue, 21 Jun 2005 22:31:49 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkvPt-000771-2U; Tue, 21 Jun 2005 22:56:42 -0400 Received: from 66-214-35-128.lb-cres.charterpipeline.net ([66.214.35.128]) by mx2.foretec.com with smtp (Exim 4.24) id 1Dkv1p-00060I-O1; Tue, 21 Jun 2005 22:31:50 -0400 Received: from leash.gjdiim.rarefy.diphthong.com by prognosis.rushmore.muscle.com (pwhupfix) with SMTP id 4B29E820770 for ; Wed, 22 Jun 2005 00:26:59 -0300 Message-ID: Date: Tue, 21 Jun 2005 22:32:59 -0500 From: "Teresa Naquin" To: X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: Become one of the low rates X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.3 (+++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.stra1n.com/signs.asp Best Regards, Lee Burke to be remov(ed: http://www.stra1n.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Wed Jun 22 07:02:57 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24600 for ; Wed, 22 Jun 2005 07:02:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl3Od-00031t-Oc for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 07:27:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl2yS-000795-Ry; Wed, 22 Jun 2005 07:00:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl2yR-00077O-6s; Wed, 22 Jun 2005 07:00:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24444; Wed, 22 Jun 2005 06:59:34 -0400 (EDT) Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl3LL-0002xM-2p; Wed, 22 Jun 2005 07:24:32 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j5MAxLe4274900; Wed, 22 Jun 2005 10:59:21 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5MAxLG6264646; Wed, 22 Jun 2005 11:59:21 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j5MAxKwb012581; Wed, 22 Jun 2005 11:59:20 +0100 Received: from mail-gw3.hursley.ibm.com (mail-gw3.hursley.ibm.com [9.20.131.251]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j5MAxKOc012560; Wed, 22 Jun 2005 11:59:20 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw3.hursley.ibm.com with esmtp (Exim 4.50) id 1Dl2wx-0001We-U9; Wed, 22 Jun 2005 11:59:19 +0100 Received: from zurich.ibm.com (sig-9-145-134-171.de.ibm.com [9.145.134.171]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id j5MAxJo157738; Wed, 22 Jun 2005 11:59:19 +0100 Message-ID: <42B94484.5070806@zurich.ibm.com> Date: Wed, 22 Jun 2005 12:59:16 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Susan Hares References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Margaret Wasserman Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit I can't speak to past events, but in this case there has been substantial discusssion with IEEE and I don't think there is any disturbance to the addressing "rule" that you cite. But the skill set for this particular work is in the IETF. Nobody denies that it's in the grey area where the question of scope can be discussed endlessly, but the intention is now to decide quickly, since the proponents have been more than patient. Brian Susan Hares wrote: > Margaret: > > The key point is we want to ship product with standardization. > (A good thing for all of us (IMHO).) > > The rules used to be clear: > > MAC address = IEEE > IP address/Label = IETF. > > If we are changing the rules, we need to be clear that we are changing > the rules clearly. Tony notes where the change in the rules didn't > match. > > You worked hard to make sure we had IETF consistency. It would be > helpful to make sure we have the same for IEEE/IETF consistency. > > Many thanks, > > Sue Hares > > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li] > Sent: Tuesday, June 21, 2005 1:16 PM > To: Margaret Wasserman > Cc: Alex Zinin; rtg-dir@ietf.org; rtg-chairs@ietf.org; > routing-discussion@ietf.org; Susan Hares; iesg@ietf.org > Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of > Links (trill) > > > Margaret, > > Thanks for your response. IESG cc'ed per your request. > > >>Please let me know if you have any further questions. The IESG will > > be > >>making a decision on this charter at our telechat this Thursday (June >>23rd), so if you have an opinion about whether or not we should > > charter > >>this WG in the IETF, please send your comments to the IESG at >>iesg@ietf.org. We are interested in hearing from folks who do want > > this > >>work charted (especially from folks who are willing to invest time to >>make this happen), as well as from folks who have objections to >>chartering the group. > > > While I have no objection to chartering this group, I'm left scratching > my head in wonder, trying to find the consistency between accepting this > work and the previous decision to reject the IS-IS work on jumbo frames. > You may recall that the opinion at the time was that the work would > step on IEEE toes and therefore the work was halted. The IEEE chooses > not to endorse jumbo frames, so in some sense there is no > 'standardization' to be done. Vendors, however, continue to ship > running code for jumbo frames. And there is no agreement for IS-IS > operation in such situations. > > IMHO, the IETF needs to re-examine its goals and operations in this > regard. What used to be an organization that was about standardizing > de-facto standards is now engaged in politicking at the expense of > technology. We claim to eschew kings and voting, but we seem to be > engaged in SDO diplomacy at the expense of code, users, and the > Internet. Does that seem right to you? > > Regards, > Tony Li > > > From rtg-dir-bounces@ietf.org Wed Jun 22 07:51:56 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29332 for ; Wed, 22 Jun 2005 07:51:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl4A1-0004gA-RQ for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 08:16:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl3jV-00080E-Kv; Wed, 22 Jun 2005 07:49:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl3jS-000803-Nf; Wed, 22 Jun 2005 07:49:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29211; Wed, 22 Jun 2005 07:49:21 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl47W-0004cd-JB; Wed, 22 Jun 2005 08:14:18 -0400 Received: from [66.30.121.250] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 398480; Wed, 22 Jun 2005 07:44:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <42B84B66.3050006@tony.li> References: <42B84B66.3050006@tony.li> Date: Wed, 22 Jun 2005 07:49:16 -0400 To: Tony Li From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, shares@nexthop.com Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Hi Tony, At 10:16 AM -0700 6/21/05, Tony Li wrote: >While I have no objection to chartering this group, I'm left scratching >my head in wonder, trying to find the consistency between accepting this >work and the previous decision to reject the IS-IS work on jumbo frames. I am sorry, but I am not familiar with the decision to reject work on IS-IS jumbo frames. I don't follow the IS-IS WG, so if the decision was made in that context, I would not have been aware of it. > You may recall that the opinion at the time was that the work would >step on IEEE toes and therefore the work was halted. The IEEE chooses >not to endorse jumbo frames, so in some sense there is no >'standardization' to be done. Vendors, however, continue to ship >running code for jumbo frames. And there is no agreement for IS-IS >operation in such situations. This sounds like a difficult situation. In the particular case of TRILL, we were concerned that the work might conflict with IEEE work, so we talked to the IEEE 802 leadership about it. They did not express interest in chartering this work in the IEEE, and they did not object to chartering it in the IETF. I am not quite sure what we would have done if the IEEE had said that they would not charter the work, but that they objected to the IETF chartering the work... Luckily for me and the folks working on TRILL, we did not have to figure out what to do in that situation. >IMHO, the IETF needs to re-examine its goals and operations in this >regard. What used to be an organization that was about standardizing >de-facto standards is now engaged in politicking at the expense of >technology. We claim to eschew kings and voting, but we seem to be >engaged in SDO diplomacy at the expense of code, users, and the >Internet. Does that seem right to you? Personally, I agree with you on many counts... I think that we do our best work when we standardize something that is already implemented in various forms and/or when vendors or operators decide that it would be useful to standardize an already-deployed technology, so that we can maximize interoperability and have a clear forum to discuss clarifications and extensions. There are, of course, a large number of people who don't agree with that image of the IETF. They believe that we should be standardizing ideas that come out of our research efforts, developing solutions to real (or perceived?) problems with the operation of the Internet, and/or standardizing solutions that will meet the needs of market niches that are not addressed by current technologies. In fact, I suspect that most of us have fallen into one of those camps from time-to-time. There is a widely held belief that standardizing a solution greatly increases the possibility that vendors and operators will implement and deploy the solution, and I am really not sure that this is the case... Maybe this is a cultural issue -- 3GPP vendor and operators, for example, will implement and deploy whatever is standardized as "3GPP". But, the more traditional Internet doesn't work that way -- we can't make someone implement something by standardizing it, and we can't prevent them by not standardizing it. It might help for us to remember that more often. Ultimately, though, the best way to address this problem is not by trying to enforce a specific view of the IETF from the top down (which would defeat the whole purpose), but through communicating a different vision of the IETF and trying to get enough people to adopt that vision that it becomes the prevailing culture (again?). Margaret I From rtg-dir-bounces@ietf.org Wed Jun 22 08:17:22 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02231 for ; Wed, 22 Jun 2005 08:17:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl4Yc-0005ZJ-TN for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 08:42:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl47l-0001qz-Ky; Wed, 22 Jun 2005 08:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl47i-0001p0-K1; Wed, 22 Jun 2005 08:14:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01788; Wed, 22 Jun 2005 08:12:39 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl4U3-0005Rl-PY; Wed, 22 Jun 2005 08:37:37 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2005 08:12:31 -0400 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5MCCRgl019379; Wed, 22 Jun 2005 08:12:27 -0400 (EDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 05:11:25 -0700 Received: from cisco.com ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 05:11:46 -0700 Date: Wed, 22 Jun 2005 08:11:12 -0400 From: Scott W Brim To: Margaret Wasserman Message-ID: <20050622121111.GE4988@sbrim-wxp01> Mail-Followup-To: Scott W Brim , Margaret Wasserman , Tony Li , Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, shares@nexthop.com References: <42B84B66.3050006@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 22 Jun 2005 12:11:46.0330 (UTC) FILETIME=[8F65C7A0:01C57723] X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, shares@nexthop.com Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On Wed, Jun 22, 2005 07:49:16AM -0400, Margaret Wasserman allegedly wrote: > In the particular case of TRILL, we were concerned that the work > might conflict with IEEE work, so we talked to the IEEE 802 > leadership about it. They did not express interest in chartering > this work in the IEEE, and they did not object to chartering it in > the IETF. I am told that there is a new work item developing somewhere in IEEE 802, "shortest path bridging", which will deal with optimum paths and fast convergence while maintaining current forwarding semantics. I was also told that there is talk of a tutorial BOF at the Paris IETF about it. I'm trying to get my source to speak up and say all this wrt TRILL. From rtg-dir-bounces@ietf.org Wed Jun 22 08:24:45 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02774 for ; Wed, 22 Jun 2005 08:24:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl4fn-0005lv-3T for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 08:49:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4Dq-0004V6-6P; Wed, 22 Jun 2005 08:20:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4Do-0004Uv-EV; Wed, 22 Jun 2005 08:20:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02447; Wed, 22 Jun 2005 08:20:40 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl4bo-0005gy-4I; Wed, 22 Jun 2005 08:45:38 -0400 Received: from du-069-0228.access.clara.net ([217.158.132.228] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1Dl4DX-000Ds8-8T; Wed, 22 Jun 2005 13:20:33 +0100 Message-ID: <070101c57725$1ca07420$7f849ed9@Puppy> From: "Adrian Farrel" To: "Brian E Carpenter" References: <42B94484.5070806@zurich.ibm.com> Date: Wed, 22 Jun 2005 13:22:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Margaret Wasserman , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit I think the skill-set to which Brian refers is link state routing. (Care to confirm, Brian?) If so, why is this WG targeted at the Internet Area not the Routing area? Cheers, Adrian (Still not opposing, just seeking clarification) ----- Original Message ----- From: "Brian E Carpenter" To: "Susan Hares" Cc: "Tony Li" ; "Margaret Wasserman" ; "Alex Zinin" ; ; ; ; Sent: Wednesday, June 22, 2005 11:59 AM Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) > I can't speak to past events, but in this case there has been > substantial discusssion with IEEE and I don't think there is any > disturbance to the addressing "rule" that you cite. But the > skill set for this particular work is in the IETF. Nobody > denies that it's in the grey area where the question of scope > can be discussed endlessly, but the intention is now to decide > quickly, since the proponents have been more than patient. > > Brian > > Susan Hares wrote: > > Margaret: > > > > The key point is we want to ship product with standardization. > > (A good thing for all of us (IMHO).) > > > > The rules used to be clear: > > > > MAC address = IEEE > > IP address/Label = IETF. > > > > If we are changing the rules, we need to be clear that we are changing > > the rules clearly. Tony notes where the change in the rules didn't > > match. > > > > You worked hard to make sure we had IETF consistency. It would be > > helpful to make sure we have the same for IEEE/IETF consistency. > > > > Many thanks, > > > > Sue Hares > > > > -----Original Message----- > > From: Tony Li [mailto:tony.li@tony.li] > > Sent: Tuesday, June 21, 2005 1:16 PM > > To: Margaret Wasserman > > Cc: Alex Zinin; rtg-dir@ietf.org; rtg-chairs@ietf.org; > > routing-discussion@ietf.org; Susan Hares; iesg@ietf.org > > Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of > > Links (trill) > > > > > > Margaret, > > > > Thanks for your response. IESG cc'ed per your request. > > > > > >>Please let me know if you have any further questions. The IESG will > > > > be > > > >>making a decision on this charter at our telechat this Thursday (June > >>23rd), so if you have an opinion about whether or not we should > > > > charter > > > >>this WG in the IETF, please send your comments to the IESG at > >>iesg@ietf.org. We are interested in hearing from folks who do want > > > > this > > > >>work charted (especially from folks who are willing to invest time to > >>make this happen), as well as from folks who have objections to > >>chartering the group. > > > > > > While I have no objection to chartering this group, I'm left scratching > > my head in wonder, trying to find the consistency between accepting this > > work and the previous decision to reject the IS-IS work on jumbo frames. > > You may recall that the opinion at the time was that the work would > > step on IEEE toes and therefore the work was halted. The IEEE chooses > > not to endorse jumbo frames, so in some sense there is no > > 'standardization' to be done. Vendors, however, continue to ship > > running code for jumbo frames. And there is no agreement for IS-IS > > operation in such situations. > > > > IMHO, the IETF needs to re-examine its goals and operations in this > > regard. What used to be an organization that was about standardizing > > de-facto standards is now engaged in politicking at the expense of > > technology. We claim to eschew kings and voting, but we seem to be > > engaged in SDO diplomacy at the expense of code, users, and the > > Internet. Does that seem right to you? > > > > Regards, > > Tony Li > > > > > > > > > From rtg-dir-bounces@ietf.org Wed Jun 22 08:48:35 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04839 for ; Wed, 22 Jun 2005 08:48:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl52r-0006XP-Go for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 09:13:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4dw-0005se-Gf; Wed, 22 Jun 2005 08:47:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4du-0005re-Dy; Wed, 22 Jun 2005 08:47:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04769; Wed, 22 Jun 2005 08:47:41 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl51x-0006VS-AI; Wed, 22 Jun 2005 09:12:39 -0400 Received: from [66.30.121.250] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 398544; Wed, 22 Jun 2005 08:42:13 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050622121111.GE4988@sbrim-wxp01> References: <42B84B66.3050006@tony.li> <20050622121111.GE4988@sbrim-wxp01> Date: Wed, 22 Jun 2005 08:44:48 -0400 To: Scott W Brim From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, shares@nexthop.com Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hi Scott, We are aware of this proposed work in the IEEE, and the major proponents of this work (Mick Seaman and Norm Finn) were present on the call that we had with IEEE 802 leadership to discuss chartering the TRILL WG in the IETF. The proposed IEEE effort is an (R)STP-based mechanism and will, therefore, have different applicability than a link-state-based mechanism, such as TRILL. I am not sure how/if either will fare in the market, but they are not directly overlapping efforts. In fact, there has been some interest in TRILL expressed by at least one IEEE WG chair, as that group may have a need for a link-state Ethernet routing mechanism. Margaret At 8:11 AM -0400 6/22/05, Scott W Brim wrote: >On Wed, Jun 22, 2005 07:49:16AM -0400, Margaret Wasserman allegedly wrote: >> In the particular case of TRILL, we were concerned that the work >> might conflict with IEEE work, so we talked to the IEEE 802 >> leadership about it. They did not express interest in chartering >> this work in the IEEE, and they did not object to chartering it in >> the IETF. > >I am told that there is a new work item developing somewhere in IEEE >802, "shortest path bridging", which will deal with optimum paths and >fast convergence while maintaining current forwarding semantics. I >was also told that there is talk of a tutorial BOF at the Paris IETF >about it. I'm trying to get my source to speak up and say all this >wrt TRILL. From rtg-dir-bounces@ietf.org Wed Jun 22 09:02:13 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06041 for ; Wed, 22 Jun 2005 09:02:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5G2-0006zh-HI for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 09:27:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4nZ-0002CD-39; Wed, 22 Jun 2005 08:57:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4nU-0002Ax-MI; Wed, 22 Jun 2005 08:57:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05562; Wed, 22 Jun 2005 08:57:35 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5BX-0006oP-8b; Wed, 22 Jun 2005 09:22:33 -0400 Received: from [66.30.121.250] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 398559; Wed, 22 Jun 2005 08:52:18 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <070101c57725$1ca07420$7f849ed9@Puppy> References: <42B94484.5070806@zurich.ibm.com> <070101c57725$1ca07420$7f849ed9@Puppy> Date: Wed, 22 Jun 2005 08:57:27 -0400 To: "Adrian Farrel" , "Brian E Carpenter" From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hi Adrian, At 1:22 PM +0100 6/22/05, Adrian Farrel wrote: >I think the skill-set to which Brian refers is link state routing. (Care >to confirm, Brian?) Yes, expertise in link-state routing is certainly one reason why this work could be seen as more in-scope for the IETF than for the IEEE. Also, frankly, there is interest in the IETF in doing this work (a link-state-based Ethernet routing solution), while the IEEE is continuing to pursue (R)STP-based approaches. >If so, why is this WG targeted at the Internet Area not the Routing area? This questions has been discussed in the IESG, as well, and we did not have 100% agreement regarding the area in which this work belongs. Personally, I think that TRILL is a better fit for the Internet area, and I will explain why... Traditionally, the division between the Internet area and the Routing area has been that the Routing area deals with protocols that distribute routing information (routes/labels) and the Internet area has been responsible for the forwarding behaviour and encapsulation mechanisms that make use of that information. The TRILL charter maintains that split -- any work on the routing protocols themselves would be done in the routing area, while the encapsulation/forwarding mechanism would be developed in the Internet area. Perhaps you have a different model of the division between the Routing and Internet areas that makes you think otherwise? The IESG discussed this issue several months ago. We agreed that this work is close to the line between Internet and Routing, but we reached an agreement that it would best be placed in the Internet area, with the understanding that we would appoint a technical advisor and a WG co-chair with routing expertise. BIll Fenner volunteered to be the Technical Advisor, and Bill and Alex took an action item to return with a list of potential co-chairs. Ultimately, I am not sure that it matters all that much which area this work is done in, since it will require expertise and involvement from both areas in order to succeed. Margaret From rtg-dir-bounces@ietf.org Wed Jun 22 09:03:31 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06212 for ; Wed, 22 Jun 2005 09:03:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5HI-000729-IO for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 09:28:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4rH-0002rB-Cf; Wed, 22 Jun 2005 09:01:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4rB-0002qI-Cb; Wed, 22 Jun 2005 09:01:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05893; Wed, 22 Jun 2005 09:00:57 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5En-0006vq-KB; Wed, 22 Jun 2005 09:25:55 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2005 09:00:48 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5MCxVh5018725; Wed, 22 Jun 2005 08:59:53 -0400 (EDT) Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 08:59:18 -0400 Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 05:59:16 -0700 Received: from cisco.com ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 05:58:38 -0700 Date: Wed, 22 Jun 2005 08:58:41 -0400 From: Scott W Brim To: Margaret Wasserman Message-ID: <20050622125838.GF4988@sbrim-wxp01> Mail-Followup-To: Scott W Brim , Margaret Wasserman , Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, shares@nexthop.com References: <42B84B66.3050006@tony.li> <20050622121111.GE4988@sbrim-wxp01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 22 Jun 2005 12:58:38.0098 (UTC) FILETIME=[1B578720:01C5772A] X-Spam-Score: 1.1 (+) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, shares@nexthop.com Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 OK thanks. From rtg-dir-bounces@ietf.org Wed Jun 22 10:45:09 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18319 for ; Wed, 22 Jun 2005 10:45:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl6rf-0002HR-OX for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 11:10:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl6JL-00087Z-VR; Wed, 22 Jun 2005 10:34:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl5Fi-0006id-4z; Wed, 22 Jun 2005 09:26:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08484; Wed, 22 Jun 2005 09:25:10 -0400 (EDT) Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5cD-0007pp-SF; Wed, 22 Jun 2005 09:50:09 -0400 Received: from dh029172.ahqps.alcatel.fr (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j5MDOugJ003097; Wed, 22 Jun 2005 08:24:56 -0500 (CDT) Date: Wed, 22 Jun 2005 06:24:51 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <79728562.20050622062451@alcatel.com> To: Margaret Wasserman In-Reply-To: References: <42B94484.5070806@zurich.ibm.com> <070101c57725$1ca07420$7f849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 22 Jun 2005 10:34:39 -0400 Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Adrian Farrel , Brian E Carpenter , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Sorry for a dry reply--traveling, in meetings. As Margaret said, the IESG didn't have an agreement on this. I personally believe the expertise required for TRILL is in RTG. The question of whether the WG should be formed has been dominating the discussion though. -- Alex Wednesday, June 22, 2005, 5:57:27 AM, Margaret Wasserman wrote: > Hi Adrian, > At 1:22 PM +0100 6/22/05, Adrian Farrel wrote: >>I think the skill-set to which Brian refers is link state routing. (Care >>to confirm, Brian?) > Yes, expertise in link-state routing is certainly one reason why this > work could be seen as more in-scope for the IETF than for the IEEE. > Also, frankly, there is interest in the IETF in doing this work (a > link-state-based Ethernet routing solution), while the IEEE is > continuing to pursue (R)STP-based approaches. >>If so, why is this WG targeted at the Internet Area not the Routing area? > This questions has been discussed in the IESG, as well, and we did > not have 100% agreement regarding the area in which this work belongs. > Personally, I think that TRILL is a better fit for the Internet area, > and I will explain why... > Traditionally, the division between the Internet area and the Routing > area has been that the Routing area deals with protocols that > distribute routing information (routes/labels) and the Internet area > has been responsible for the forwarding behaviour and encapsulation > mechanisms that make use of that information. > The TRILL charter maintains that split -- any work on the routing > protocols themselves would be done in the routing area, while the > encapsulation/forwarding mechanism would be developed in the Internet > area. > Perhaps you have a different model of the division between the > Routing and Internet areas that makes you think otherwise? > The IESG discussed this issue several months ago. We agreed that > this work is close to the line between Internet and Routing, but we > reached an agreement that it would best be placed in the Internet > area, with the understanding that we would appoint a technical > advisor and a WG co-chair with routing expertise. BIll Fenner > volunteered to be the Technical Advisor, and Bill and Alex took an > action item to return with a list of potential co-chairs. > Ultimately, I am not sure that it matters all that much which area > this work is done in, since it will require expertise and involvement > from both areas in order to succeed. > Margaret From rtg-dir-bounces@ietf.org Wed Jun 22 10:45:23 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18358 for ; Wed, 22 Jun 2005 10:45:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl6ru-0002II-MS for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 11:10:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl6JM-00087e-2n; Wed, 22 Jun 2005 10:34:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl5jM-0003Q9-6u; Wed, 22 Jun 2005 09:57:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12039; Wed, 22 Jun 2005 09:57:22 -0400 (EDT) Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl67Q-0000az-3V; Wed, 22 Jun 2005 10:22:21 -0400 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 23 Jun 2005 00:21:57 +1000 Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5MDuS91009751; Wed, 22 Jun 2005 23:56:30 +1000 (EST) Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id IAA28900; Wed, 22 Jun 2005 08:56:59 -0500 (CDT) Date: Wed, 22 Jun 2005 08:56:59 -0500 From: David Ward To: Margaret Wasserman Message-ID: <20050622085659.V23594@cfcentral.cisco.com> References: <42B94484.5070806@zurich.ibm.com> <070101c57725$1ca07420$7f849ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from margaret@thingmagic.com on Wed, Jun 22, 2005 at 08:57:27AM -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Wed, 22 Jun 2005 10:34:39 -0400 Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Adrian Farrel , Brian E Carpenter , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 AFAIK, the only place that "routing L2" in a protocol has been drafted is in ISIS. We wrote to draft to show that it was possible and to think through the protocol implications (how to reduce flooding, spf churn, layout the packet format) of what was even feasible. The WG will not accept it as a WG item until all of this has been resolved. -DWard On Wed, Jun 22, 2005 at 08:57:27AM -0400, Margaret Wasserman wrote: > > Hi Adrian, > > At 1:22 PM +0100 6/22/05, Adrian Farrel wrote: > >I think the skill-set to which Brian refers is link state routing. (Care > >to confirm, Brian?) > > Yes, expertise in link-state routing is certainly one reason why this > work could be seen as more in-scope for the IETF than for the IEEE. > Also, frankly, there is interest in the IETF in doing this work (a > link-state-based Ethernet routing solution), while the IEEE is > continuing to pursue (R)STP-based approaches. > > >If so, why is this WG targeted at the Internet Area not the Routing area? > > This questions has been discussed in the IESG, as well, and we did > not have 100% agreement regarding the area in which this work belongs. > > Personally, I think that TRILL is a better fit for the Internet area, > and I will explain why... > > Traditionally, the division between the Internet area and the Routing > area has been that the Routing area deals with protocols that > distribute routing information (routes/labels) and the Internet area > has been responsible for the forwarding behaviour and encapsulation > mechanisms that make use of that information. > > The TRILL charter maintains that split -- any work on the routing > protocols themselves would be done in the routing area, while the > encapsulation/forwarding mechanism would be developed in the Internet > area. > > Perhaps you have a different model of the division between the > Routing and Internet areas that makes you think otherwise? > > The IESG discussed this issue several months ago. We agreed that > this work is close to the line between Internet and Routing, but we > reached an agreement that it would best be placed in the Internet > area, with the understanding that we would appoint a technical > advisor and a WG co-chair with routing expertise. BIll Fenner > volunteered to be the Technical Advisor, and Bill and Alex took an > action item to return with a list of potential co-chairs. > > Ultimately, I am not sure that it matters all that much which area > this work is done in, since it will require expertise and involvement > from both areas in order to succeed. > > Margaret From rtg-dir-bounces@ietf.org Wed Jun 22 10:46:06 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18514 for ; Wed, 22 Jun 2005 10:46:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl6sa-0002Li-O3 for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 11:11:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl6PS-0000wR-M2; Wed, 22 Jun 2005 10:40:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl6PQ-0000vj-Bz; Wed, 22 Jun 2005 10:40:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17530; Wed, 22 Jun 2005 10:38:53 -0400 (EDT) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl6lb-00020M-KO; Wed, 22 Jun 2005 11:03:53 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j5MEciGM390982; Wed, 22 Jun 2005 14:38:44 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5MEciG6229114; Wed, 22 Jun 2005 15:38:44 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j5MEchGi023747; Wed, 22 Jun 2005 15:38:43 +0100 Received: from mail-gw3.hursley.ibm.com (mail-gw3.hursley.ibm.com [9.20.131.251]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j5MEch8o023744; Wed, 22 Jun 2005 15:38:43 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw3.hursley.ibm.com with esmtp (Exim 4.50) id 1Dl6NH-0005di-NM; Wed, 22 Jun 2005 15:38:43 +0100 Received: from zurich.ibm.com (sig-9-146-217-118.de.ibm.com [9.146.217.118]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id j5MEcho93782; Wed, 22 Jun 2005 15:38:43 +0100 Message-ID: <42B977EF.3060308@zurich.ibm.com> Date: Wed, 22 Jun 2005 16:38:39 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Margaret Wasserman References: <42B94484.5070806@zurich.ibm.com> <070101c57725$1ca07420$7f849ed9@Puppy> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Adrian Farrel , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit I concur with Margaret completely Brian Margaret Wasserman wrote: > > Hi Adrian, > > At 1:22 PM +0100 6/22/05, Adrian Farrel wrote: > >> I think the skill-set to which Brian refers is link state routing. (Care >> to confirm, Brian?) > > > Yes, expertise in link-state routing is certainly one reason why this > work could be seen as more in-scope for the IETF than for the IEEE. > Also, frankly, there is interest in the IETF in doing this work (a > link-state-based Ethernet routing solution), while the IEEE is > continuing to pursue (R)STP-based approaches. > >> If so, why is this WG targeted at the Internet Area not the Routing area? > > > This questions has been discussed in the IESG, as well, and we did not > have 100% agreement regarding the area in which this work belongs. > > Personally, I think that TRILL is a better fit for the Internet area, > and I will explain why... > > Traditionally, the division between the Internet area and the Routing > area has been that the Routing area deals with protocols that distribute > routing information (routes/labels) and the Internet area has been > responsible for the forwarding behaviour and encapsulation mechanisms > that make use of that information. > > The TRILL charter maintains that split -- any work on the routing > protocols themselves would be done in the routing area, while the > encapsulation/forwarding mechanism would be developed in the Internet area. > > Perhaps you have a different model of the division between the Routing > and Internet areas that makes you think otherwise? > > The IESG discussed this issue several months ago. We agreed that this > work is close to the line between Internet and Routing, but we reached > an agreement that it would best be placed in the Internet area, with the > understanding that we would appoint a technical advisor and a WG > co-chair with routing expertise. BIll Fenner volunteered to be the > Technical Advisor, and Bill and Alex took an action item to return with > a list of potential co-chairs. > > Ultimately, I am not sure that it matters all that much which area this > work is done in, since it will require expertise and involvement from > both areas in order to succeed. > > Margaret > > > > From rtg-dir-bounces@ietf.org Wed Jun 22 12:23:55 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28614 for ; Wed, 22 Jun 2005 12:23:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl8PI-0005w1-GT for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 12:48:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl7w2-00062c-AE; Wed, 22 Jun 2005 12:18:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl7vz-000621-Vc for rtg-dir@megatron.ietf.org; Wed, 22 Jun 2005 12:18:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28215 for ; Wed, 22 Jun 2005 12:18:36 -0400 (EDT) Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dl8K8-0005l7-Up for rtg-dir@ietf.org; Wed, 22 Jun 2005 12:43:37 -0400 Received: (qmail 46153 invoked from network); 22 Jun 2005 16:18:31 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 22 Jun 2005 16:18:31 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j5MGIB2V039677; Wed, 22 Jun 2005 12:18:11 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200506221618.j5MGIB2V039677@workhorse.faster-light.net> To: Brian E Carpenter In-reply-to: Your message of "Wed, 22 Jun 2005 12:59:16 +0200." <42B94484.5070806@zurich.ibm.com> Date: Wed, 22 Jun 2005 12:18:11 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c In message <42B94484.5070806@zurich.ibm.com> Brian E Carpenter writes: > > I can't speak to past events, but in this case there has been > substantial discusssion with IEEE and I don't think there is any > disturbance to the addressing "rule" that you cite. But the > skill set for this particular work is in the IETF. Nobody > denies that it's in the grey area where the question of scope > can be discussed endlessly, but the intention is now to decide > quickly, since the proponents have been more than patient. > > Brian Brian, [Appology in advance for the length of this.] One of the conclusions that could potentially come out of a group that has more expertice in this area is that the whole idea of bridging in anything but a very small scale and trivial topology in general is a bad idea and therefore this work and any further spanning tree work is best not pursued anywhere. Others have mentioned that IETF tends to standardize those things that have proven useful rather than push ideas upon user communities (Tony, others). [insert mantra on running code and all that.] Its clear that there is no interest in providers in bridging solutions. There have been enough failures to keep most people from further attempts, ranging from the bridging done in regional acedemic networks in the late 1980s to attempts to use IP at the edges and ATM in the middle, to the complete failure in the market of ATM approaches such as RFC1577, NHRP, MPOA. Bridging seems to be a preferred solution in enterprise. A decade ago there was a good reason to do so. If you moved a box from one ethernet segment to another you had to change its IP address. This was a pain for personal workstations (whether Sun, Linux, PC, MAC, whatever) which are very numerous. DHCP has changed that. Only machines providing a service need a fixed address and a DNS mapping to that address. Even though DHCP is universally available and widely deployed in enterprise, enterprise hasn't caught on that the reliance on bridging is no longer in their best interest (in fact the opposite is true since diagnosing routing problems is much easier). The remaining problem for enterprise is moving the servers. Most enterprise IT departments can deal with renumbering a server if they have to do so to accomodate a physical move and the better ones configure a whole new server and have it running and then just switch the DNS entry (giving it a short TTL 24 hours prior to the switch, etc, etc) in addition to making the switch off hours. Mobility offers a new problem. It would be nice to be able to keep your laptop running and move about within wireless space with any changes to addressing made transparently. The best way to do this involves decoupling the destination address of the box from the interface address. Loopback devices and interface aliases are nothing new to routers and Linux and *ix systems. A better solution to the problem of mobility of small devices like IP phones and laptops might be entirely at layer 3 using the above toolbox (microsoft can add loopbacks and aliases if they don't support such a capability). A limited initial solution might be as simple as having the abiliby for the OS to bind to the loopback on outbound connections by default rather than the interface (this is solved at the application layer in some router code and kerberos implementations and other things that providers have "fixed" for dual homing and recompiled) and tracking the host route to the loopback within a limited set of wireless access points (for example all those at a given IETF meeting). This can be made general by having DHCP offer a preferred loopback address for the device to use. Solving the problem of mobility between adjacent domains isn't much harder. The problem with switching the loopback device is that with current OS all TCP connections stop working. For short lived protocols such as SMTP or POP and HTTP this is less of a problem than for long lived connections such as SSH's slogin service (no one really uses telnet, I hope). For the short lived connections allowing the loopback of a geographicly adjacent domain might provide a sufficient grace period on the transition to solve the problem. It would be best if the OS could support a preferred address on the loopback and an alias on the loopback to support the TCP connections still using the old address. Beyond that there would need to be a way to change the TCP address of one end of a TCP connection. This would have to be solved in TCP itself. There is currently no header option for "accept alternate address" and "drop address" in TCP but having that would be sufficient. It would also open a new opportunity for abuse in TCP connections with no cryptographic integrety check so the security section of such a draft would have to be very non-empty. It might be that we'd have to restrict use of this option to TCP connections with some form of cryptographic check (but I digress). Ultimately one should be able to drive (or fly, or bicycle, or whatever) across a continent with a laptop open and keep the same TCP connection open the whole time. The solution might be as simple as some OS enhancements and enhancements to DHCP and a TCP option. Please note that a spanning tree or link state solution isn't going to get us there and therefore is a limited temporary solution. There are sure to be other less used non-TCP protocols that are affected. Just like with NAT eventually this would be resolved. For example, a SIP enhancement might be needed to accomodate connection to a phone that is moving about in the address space. In the past the BSD folks would go to it, we'd play with it at IETF, some providers would start to support it if that was needed, we'd write an internet-draft which would become an RFC and 5-10 years later deployment would be widespread. It worked for DHCP. It worked (for some limited value of worked) for multicast. The IETF often works differently these days, but that doesn't mean that running code wouldn't help matters. Then again, the conclusions of this discussion might be quite different but thats my thoughts on the topic. Curtis ps - Anyone seriously interested in these ideas please send private email (anyone at ISC interested?) or at least change the subject. This is sort of off topic or mostly a digression but I felt that if I were saying "bad solution" in order to be constructive I needed to outline a better solution. pps - In the past work on "bad solutions" were referred to ITU or other organization though I'm not sure that practice is codified in any IESG policy. I suspect a lot of the "send it to IEEE" might be motivated by the "bad solutions are out of scope for IETF" sentiment. :-) From rtg-dir-bounces@ietf.org Wed Jun 22 12:24:57 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28741 for ; Wed, 22 Jun 2005 12:24:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl8QI-0005z1-5Q for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 12:49:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl81u-00076Q-68; Wed, 22 Jun 2005 12:24:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl81t-00076A-Cf; Wed, 22 Jun 2005 12:24:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28687; Wed, 22 Jun 2005 12:24:39 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl8Py-0005wq-1O; Wed, 22 Jun 2005 12:49:40 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2005 09:24:25 -0700 X-IronPort-AV: i="3.93,221,1115017200"; d="scan'208"; a="281780601:sNHT29574364" Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5MGOHVX018662; Wed, 22 Jun 2005 09:24:17 -0700 (PDT) Received: from [10.21.122.155] (sjc-vpn6-667.cisco.com [10.21.122.155]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id JAA27195; Wed, 22 Jun 2005 09:24:16 -0700 Message-ID: <42B990B0.1060700@tony.li> Date: Wed, 22 Jun 2005 09:24:16 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman References: <42B84B66.3050006@tony.li> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, shares@nexthop.com Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Hi Margaret, >> You may recall that the opinion at the time was that the work would >> step on IEEE toes and therefore the work was halted. The IEEE chooses >> not to endorse jumbo frames, so in some sense there is no >> 'standardization' to be done. Vendors, however, continue to ship >> running code for jumbo frames. And there is no agreement for IS-IS >> operation in such situations. > > In the particular case of TRILL, we were concerned that the work might > conflict with IEEE work, so we talked to the IEEE 802 leadership about > it. They did not express interest in chartering this work in the IEEE, > and they did not object to chartering it in the IETF. > > I am not quite sure what we would have done if the IEEE had said that > they would not charter the work, but that they objected to the IETF > chartering the work... Luckily for me and the folks working on TRILL, > we did not have to figure out what to do in that situation. Given this, I would like to propose that we re-open the work on IS-IS over jumbo frames. Since the IEEE has clearly said that jumbo frames are out of scope, they can hardly object to the IETF working on it. > Ultimately, though, the best way to address this problem is not by > trying to enforce a specific view of the IETF from the top down (which > would defeat the whole purpose), but through communicating a different > vision of the IETF and trying to get enough people to adopt that vision > that it becomes the prevailing culture (again?). Please see above. We were stopped previously by the IESG adopting just such a specific view about structured standards development and imposing it from the top down. You seem to indicate that the situation may have changed and that the IESG may now be more amenable to a more pragmatic approach. Regards, Tony From rtg-dir-bounces@ietf.org Wed Jun 22 12:26:54 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28922 for ; Wed, 22 Jun 2005 12:26:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl8SB-00063L-7l for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 12:51:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl7vq-0005x5-Jo; Wed, 22 Jun 2005 12:18:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl7vo-0005wa-R7; Wed, 22 Jun 2005 12:18:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28195; Wed, 22 Jun 2005 12:18:14 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl8Jm-0005kU-MK; Wed, 22 Jun 2005 12:43:16 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0B75C2D5397; Wed, 22 Jun 2005 12:18:03 -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 95327-01-75; Wed, 22 Jun 2005 12:18:01 -0400 (EDT) Received: from BOS-exch01.corp.nexthop.com (unknown [192.168.11.20]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7ADF22D5050; Wed, 22 Jun 2005 11:57:54 -0400 (EDT) Received: from aa-exchange1.corp.nexthop.com ([65.247.36.233]) by BOS-exch01.corp.nexthop.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jun 2005 11:57:54 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Wed, 22 Jun 2005 11:57:51 -0400 Message-ID: Thread-Topic: Re: WG Review: Transparent Interconnection of Lots of Links (trill) thread-index: AcV3OpUk/NpWbBtnRwC1Lx3LU6q7fgABy7xA From: "Susan Hares" To: "Margaret Wasserman" , "Tony Li" , "Alex Zinin" , , , X-OriginalArrivalTime: 22 Jun 2005 15:57:54.0176 (UTC) FILETIME=[2676C800:01C57743] X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Subject: RE: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable I believe the expertise for link-state protocols is in the routing area. Sue Hares -----Original Message----- From: routing-discussion-bounces@ietf.org [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Margaret Wasserman Sent: Tuesday, June 21, 2005 8:55 AM To: Tony Li; Alex Zinin; rtg-dir@ietf.org; rtg-chairs@ietf.org; routing-discussion@ietf.org; Susan Hares Subject: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) Hi All, Erik forwarded this message to me, so that I could reply. I used to=20 be on routing-discussion (at least I thought I was), but I don't seem=20 to be now, so please include me in any responses. At 14:44:54 AM -0400 6/20/05, Eric W Gray wrote: >Tony, > > No disagreement from me. Perhaps the next obvious question is - has >anyone taken this to the >IEEE? We have talked to the IEEE about this, and they are very aware of=20 this work. There were several e-mail exchanges with IEEE 802 leaders=20 in response to the first charter that was circulated for external=20 review last November. This lead to an e-mail discussion between IEEE=20 leadership and the IESG/IAB. We then had a conference call between=20 the interested IESG folks, Bernard Aboba (IEEE liaison manager for=20 the IETF) and the IEEE 802 leadership. An rbridge (AKA TRILL)=20 tutorial was also held at an IEEE 802 plenary. The IEEE is developing a solution for shortest-path bridging, an=20 (R)STP approach being developed in IEEE 802.1. We were quite=20 concerned about the potential for conflict between the TRILL work and=20 the IEEE 802.1 work, and that was discussed via e-mail and on the=20 call. In the end, we concluded that a link-state-based approach will=20 have different applicability than an (R)STP-based approach, and there=20 has even some interest in a link-state-based approach from other=20 parts of IEEE 802. We also discussed where this work would best be housed -- in the=20 IETF, in the iEEE or as a joint activity. We don't have any=20 mechanism for joint activities with the IEEE, and that option was=20 quickly dismissed. We understand that this is close to the line=20 between the two organizations, but the conclusion of our discussions=20 was that the development of a link-state-based Ethernet routing=20 mechanism is better done in the IETF than in the IEEE. The IEEE=20 leadership did not object to the IETF pursuing this work. The IEEE 802.1 technical leaders (Mick Seaman and Norm Finn)=20 suggested that this work should be review by IEEE 802.1 for=20 compliance with the Ethernet service model, and the charter includes=20 a request for a formal liaison relationship with IEEE 802.1 for this=20 purpose. It has been pointed out that the purpose of the liaison=20 relationship is not clear enough in the current charter, and we will=20 be modifying the charter to add explicit IEEE 802.1 review milestones=20 for both the architecture document and the specification. Please let me know if you have any further questions. The IESG will=20 be making a decision on this charter at our telechat this Thursday=20 (June 23rd), so if you have an opinion about whether or not we should=20 charter this WG in the IETF, please send your comments to the IESG at=20 iesg@ietf.org. We are interested in hearing from folks who do want=20 this work charted (especially from folks who are willing to invest=20 time to make this happen), as well as from folks who have objections=20 to chartering the group. Thanks, Margaret _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Wed Jun 22 12:27:27 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29019 for ; Wed, 22 Jun 2005 12:27:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl8Si-00064p-Bv for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 12:52:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl7za-0006eb-Hn; Wed, 22 Jun 2005 12:22:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl7zY-0006dV-32; Wed, 22 Jun 2005 12:22:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28479; Wed, 22 Jun 2005 12:22:16 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl8Nh-0005sh-73; Wed, 22 Jun 2005 12:47:17 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3A4B92D4FD5; Wed, 22 Jun 2005 12:22:10 -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 96352-02-47; Wed, 22 Jun 2005 12:22:06 -0400 (EDT) Received: from BOS-exch01.corp.nexthop.com (unknown [192.168.11.20]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 799CE2D4AAE; Wed, 22 Jun 2005 12:02:00 -0400 (EDT) Received: from aa-exchange1.corp.nexthop.com ([65.247.36.233]) by BOS-exch01.corp.nexthop.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jun 2005 12:01:59 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Wed, 22 Jun 2005 12:01:58 -0400 Message-ID: Thread-Topic: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) thread-index: AcV3OtV3QBoyRP39TDeBul7X3zxPSwACGadg From: "Susan Hares" To: "Brian E Carpenter" X-OriginalArrivalTime: 22 Jun 2005 16:01:59.0980 (UTC) FILETIME=[B8F97EC0:01C57743] X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Brian: Please substitute "rule of thumb" for "rule" in my previous message. Also - IMHO: Quick decisions =3D good.=20 Sue -----Original Message----- From: routing-discussion-bounces@ietf.org [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Wednesday, June 22, 2005 6:59 AM To: Susan Hares Cc: Alex Zinin; rtg-dir@ietf.org; iesg@ietf.org; routing-discussion@ietf.org; rtg-chairs@ietf.org Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) I can't speak to past events, but in this case there has been substantial discusssion with IEEE and I don't think there is any disturbance to the addressing "rule" that you cite. But the skill set for this particular work is in the IETF. Nobody denies that it's in the grey area where the question of scope can be discussed endlessly, but the intention is now to decide quickly, since the proponents have been more than patient. Brian Susan Hares wrote: > Margaret: >=20 > The key point is we want to ship product with standardization. > (A good thing for all of us (IMHO).) >=20 > The rules used to be clear: >=20 > MAC address =3D IEEE > IP address/Label =3D IETF. >=20 > If we are changing the rules, we need to be clear that we are changing > the rules clearly. Tony notes where the change in the rules didn't > match. >=20 > You worked hard to make sure we had IETF consistency. It would be > helpful to make sure we have the same for IEEE/IETF consistency. >=20 > Many thanks, >=20 > Sue Hares >=20 > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li]=20 > Sent: Tuesday, June 21, 2005 1:16 PM > To: Margaret Wasserman > Cc: Alex Zinin; rtg-dir@ietf.org; rtg-chairs@ietf.org; > routing-discussion@ietf.org; Susan Hares; iesg@ietf.org > Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of > Links (trill) >=20 >=20 > Margaret, >=20 > Thanks for your response. IESG cc'ed per your request. >=20 >=20 >>Please let me know if you have any further questions. The IESG will >=20 > be >=20 >>making a decision on this charter at our telechat this Thursday (June >>23rd), so if you have an opinion about whether or not we should >=20 > charter >=20 >>this WG in the IETF, please send your comments to the IESG at >>iesg@ietf.org. We are interested in hearing from folks who do want >=20 > this >=20 >>work charted (especially from folks who are willing to invest time to >>make this happen), as well as from folks who have objections to >>chartering the group. >=20 >=20 > While I have no objection to chartering this group, I'm left scratching > my head in wonder, trying to find the consistency between accepting this > work and the previous decision to reject the IS-IS work on jumbo frames. > You may recall that the opinion at the time was that the work would > step on IEEE toes and therefore the work was halted. The IEEE chooses > not to endorse jumbo frames, so in some sense there is no > 'standardization' to be done. Vendors, however, continue to ship > running code for jumbo frames. And there is no agreement for IS-IS > operation in such situations. >=20 > IMHO, the IETF needs to re-examine its goals and operations in this > regard. What used to be an organization that was about standardizing > de-facto standards is now engaged in politicking at the expense of > technology. We claim to eschew kings and voting, but we seem to be > engaged in SDO diplomacy at the expense of code, users, and the > Internet. Does that seem right to you? >=20 > Regards, > Tony Li >=20 >=20 >=20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Wed Jun 22 12:34:49 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29892 for ; Wed, 22 Jun 2005 12:34:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl8Zl-0006Pf-HP for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 12:59:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl88O-0001sL-48; Wed, 22 Jun 2005 12:31:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl88L-0001ro-QA; Wed, 22 Jun 2005 12:31:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29373; Wed, 22 Jun 2005 12:31:19 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl8WS-0006FF-Cw; Wed, 22 Jun 2005 12:56:20 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5B24A2D50F9; Wed, 22 Jun 2005 12:31: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 97634-01-68; Wed, 22 Jun 2005 12:31:05 -0400 (EDT) Received: from BOS-exch01.corp.nexthop.com (unknown [192.168.11.20]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 85AD02D5124; Wed, 22 Jun 2005 12:11:30 -0400 (EDT) Received: from aa-exchange1.corp.nexthop.com ([65.247.36.233]) by BOS-exch01.corp.nexthop.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jun 2005 12:11:30 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Wed, 22 Jun 2005 12:11:28 -0400 Message-ID: Thread-Topic: WG Review: Transparent Interconnection of Lots of Links (trill) thread-index: AcV3Op8WK9yGNX1PS5ihIdmLzkviWwACMqHw From: "Susan Hares" To: "Radia Perlman" X-OriginalArrivalTime: 22 Jun 2005 16:11:30.0219 (UTC) FILETIME=[0CDD0FB0:01C57745] X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Content-Transfer-Encoding: quoted-printable Cc: Alex Zinin , rtg-dir@ietf.org, ewgray@GraIyMage.com, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: RE: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Content-Transfer-Encoding: quoted-printable Radia: That is a very valid point. The Layer2/Layer3 linking is important and outside of the scope of Layer-2. Layer 3 expertise is key to that one.=20 Just like ISIS jumbo grams - with cross-over between the two.=20 Sue -----Original Message----- From: routing-discussion-bounces@ietf.org [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Radia Perlman Sent: Monday, June 20, 2005 4:12 PM To: Radia Perlman Cc: Alex Zinin; rtg-dir@ietf.org; ewgray@GraIyMage.com; routing-discussion@ietf.org; rtg-chairs@ietf.org; Susan Hares Subject: Re: WG Review: Transparent Interconnection of Lots of Links (trill) Oh and one other thing...things like proxy ND and passing around (layer=20 3, layer 2) pairs to facilitate it, are something else that are not specific to any=20 particular layer 2 technology. Radia Radia Perlman wrote: > Yes. This has been discussed with IEEE. I even gave a tutorial there=20 > on TRILL at the > last IEEE, both at a general tutorial slot and at the mesh group=20 > (invited by the chair > of that group, Don Eastlake). It got a very friendly reception, by the > way. > > There are some people in the wireless mesh group who > have since mentioned to me that they are interested > in proposing a solution like this within the mesh group. > And that would be good. But this technology is not specific to any=20 > particular > layer 2 technology, and certainly not limited to wireless. So it=20 > should be standardized in something > that is layer 2 agnostic. It could also be used in other places, of=20 > course, and if multiple WGs are > working on similar things, it is good if they cooperate and liase (is=20 > that a word?) so that technology > works well together, and even better yet, if it converges towards the=20 > same design. I believe > the intention of all concerned is that all the WGs that might be=20 > interested and might > be helpful have liason relationships. > > Radia > > > > Susan Hares wrote: > >> Eric and Tony: >> >> See my comments about Wireless Mesh proposal an Wi-Mesh alliance I'm=20 >> a part of submitted 6/15/05 to the 802.11s. >> >> Radia or others may know more about 802.1 since they have more=20 >> history with IEEE. >> >> Sue >> >> ------------------------------------------------------------------------ >> >> *From:* Eric W Gray [mailto:ewgray2k@netscape.net] >> *Sent:* Monday, June 20, 2005 2:45 PM >> *To:* Tony Li >> *Cc:* Susan Hares; Alex Zinin; rtg-dir@ietf.org;=20 >> routing-discussion@ietf.org; rtg-chairs@ietf.org >> *Subject:* Re: WG Review: Transparent Interconnection of Lots of=20 >> Links (trill) >> >> Tony, >> >> No disagreement from me. Perhaps the next obvious question is - has=20 >> anyone taken this to the >> IEEE? >> >> --=20 >> Eric >> >> Tony Li wrote: >> >> >> >> In other instances, when proposals were IEEE'ish, we were directed to >> >> take them to the IEEE. >> >> >> >> Tony >> >> >> >> >> >> Eric W Gray wrote: >> >> =20 >> >>> Sue, >>> >>> >>> >>> The trouble with obvious questions is that everybody assumes they've >>> >>> been asked already. >>> >>> Now this question has been asked at least once, for sure. :-) >>> >>> >>> >>> From the charter attached in Alex's previous message, the purpose is >>> >>> to "route" Ethernet >>> >>> Frames. Quote: >>> >>> >>> >>> The TRILL WG will design a solution for shortest-path frame routing in >>> >>> multi-hop IEEE 802.1 Ethernet networks with arbitrary topologies, >>> >>> using the link-state routing protocol technology. >>> >>> >>> >>> Since it is clear that at least some people are not satisfied with the >>> >>> 802.1 approach (perhaps >>> >>> because of the relative inefficiency associated with completely unused >>> >>> high capacity links), I >>> >>> assume you mean to ask "why is it not IEEE" - rather than "why is it >>> not >>> >>> 802.1". >>> >>> >>> >>> I believe that is a very good question. I know of no very good >>> >>> reason why the IEEE might >>> >>> not specify how to use an OSPF-like routing protocol to fulfill the=20 >>> role >>> >>> previously handled by >>> >>> Spanning Tree Protocol. Perhaps the only reason why it is being >>> >>> discussed here is that it might >>> >>> be better - for implementers - if the protocol used was more than >>> >>> "OSPF-like." >>> >>> >>> >>> --=20 >>> >>> Eric >>> >>> >>> >>> shares@nexthop.com wrote: >>> >>> >>> >>> =20 >>> >>>> Why are we doing this? Is it IP or is it Frames? >>>> >>>> If it is Frames, why is it not 802.1 - etc? >>>> >>>> >>>> Sue Hares >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> From: Alex Zinin [mailto:zinin@psg.com] >>>> Sent: Thursday, June 16, 2005 10:00 PM >>>> >>>> To: routing-discussion@ietf.org >>>> >>>> Cc: rtg-dir@ietf.org ; rtg-chairs@ietf.org >>>> >>>> >>>> Subject: Fwd: WG Review: Transparent Interconnection of Lots of Links >>>> >>>> (trill) >>>> >>>> >>>> >>>> Since the second BOF on this topic was inconclusive regarding=20 >>>> community >>>> >>>> support, the IESG is reevaluating the community consensus on whether a >>>> >>>> WG >>>> >>>> should be formed or not. >>>> >>>> >>>> >>>> If you have input on this, positive or negative, please send it to >>>> >>>> iesg@ietf.org . >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> =20 >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> _______________________________________________ >>> >>> routing-discussion mailing list >>> >>> routing-discussion@ietf.org >>> >>> https://www1.ietf.org/mailman/listinfo/routing-discussion >>> >>> =20 >> >> >> >> >> >> >> >> =20 >> > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Wed Jun 22 12:51:46 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01800 for ; Wed, 22 Jun 2005 12:51:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl8qA-0006zw-BZ for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 13:16:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl8Pc-0000Cu-6P; Wed, 22 Jun 2005 12:49:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl8Pa-0000Bz-2O; Wed, 22 Jun 2005 12:49:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01374; Wed, 22 Jun 2005 12:49:04 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl8nd-0006tk-7R; Wed, 22 Jun 2005 13:14:06 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id ADAA12D5064; Wed, 22 Jun 2005 12:48: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 01518-01-24; Wed, 22 Jun 2005 12:48:50 -0400 (EDT) Received: from BOS-exch01.corp.nexthop.com (unknown [192.168.11.20]) by aa-mx1.nexthop.com (Postfix) with ESMTP id EC4CF2D5290; Wed, 22 Jun 2005 12:27:39 -0400 (EDT) Received: from aa-exchange1.corp.nexthop.com ([65.247.36.233]) by BOS-exch01.corp.nexthop.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jun 2005 12:27:39 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Wed, 22 Jun 2005 12:27:37 -0400 Message-ID: Thread-Topic: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) thread-index: AcV3Kfv7wSoq/cgDQTGa/OAV3u86eAAGxxiw From: "Susan Hares" To: "Margaret Wasserman" , "Adrian Farrel" , "Brian E Carpenter" X-OriginalArrivalTime: 22 Jun 2005 16:27:39.0340 (UTC) FILETIME=[4E8130C0:01C57747] X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Margaret: I suggest that the expertise in the link state is in the Routing area of the IETF. If it belongs in the IETF due to expertise, it belongs in the Routing.=20 Critical early review has been determined to be key to a quickly deployed specification. =20 Sue -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com]=20 Sent: Wednesday, June 22, 2005 8:57 AM To: Adrian Farrel; Brian E Carpenter Cc: Tony Li; Alex Zinin; rtg-dir@ietf.org; iesg@ietf.org; routing-discussion@ietf.org; rtg-chairs@ietf.org; Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) Hi Adrian, At 1:22 PM +0100 6/22/05, Adrian Farrel wrote: >I think the skill-set to which Brian refers is link state routing. (Care >to confirm, Brian?) Yes, expertise in link-state routing is certainly one reason why this=20 work could be seen as more in-scope for the IETF than for the IEEE.=20 Also, frankly, there is interest in the IETF in doing this work (a=20 link-state-based Ethernet routing solution), while the IEEE is=20 continuing to pursue (R)STP-based approaches. >If so, why is this WG targeted at the Internet Area not the Routing area? This questions has been discussed in the IESG, as well, and we did=20 not have 100% agreement regarding the area in which this work belongs. Personally, I think that TRILL is a better fit for the Internet area,=20 and I will explain why... Traditionally, the division between the Internet area and the Routing=20 area has been that the Routing area deals with protocols that=20 distribute routing information (routes/labels) and the Internet area=20 has been responsible for the forwarding behaviour and encapsulation=20 mechanisms that make use of that information. The TRILL charter maintains that split -- any work on the routing=20 protocols themselves would be done in the routing area, while the=20 encapsulation/forwarding mechanism would be developed in the Internet=20 area. Perhaps you have a different model of the division between the=20 Routing and Internet areas that makes you think otherwise? The IESG discussed this issue several months ago. We agreed that=20 this work is close to the line between Internet and Routing, but we=20 reached an agreement that it would best be placed in the Internet=20 area, with the understanding that we would appoint a technical=20 advisor and a WG co-chair with routing expertise. BIll Fenner=20 volunteered to be the Technical Advisor, and Bill and Alex took an=20 action item to return with a list of potential co-chairs. Ultimately, I am not sure that it matters all that much which area=20 this work is done in, since it will require expertise and involvement=20 from both areas in order to succeed. Margaret From rtg-dir-bounces@ietf.org Wed Jun 22 13:17:50 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04268 for ; Wed, 22 Jun 2005 13:17:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl9FT-0007wa-Vj for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 13:42:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl8qL-0008Q5-NF; Wed, 22 Jun 2005 13:16:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl8qK-0008Pp-JZ; Wed, 22 Jun 2005 13:16:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04021; Wed, 22 Jun 2005 13:16:41 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl9EL-0007uI-Uz; Wed, 22 Jun 2005 13:41:43 -0400 Received: from [10.0.0.171] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 399041; Wed, 22 Jun 2005 13:11:18 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 22 Jun 2005 13:16:28 -0400 To: "Susan Hares" , "Adrian Farrel" , "Brian E Carpenter" From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Hi Sue, The TRILL WG would not be chartered to develop a link-state routing protocol. They would be chartered to make use of an existing link-state routing protocol, and any extensions or modifications to that protocol would be referred to the appropriate routing area WG. The TRILL WG would determine the mechanisms for encapsulating and forwarding Ethernet frames and for auto-configuring the rbridges. I am not sure that in-depth expertise in link-state routing protocols is needed for that. Instead, you need expertise in encapsulation, forwarding and configuration, which are all Internet area topics. Margaret At 12:27 PM -0400 6/22/05, Susan Hares wrote: >Margaret: > >I suggest that the expertise in the link state is in the Routing area of >the IETF. If it belongs in the IETF due to expertise, it belongs in the >Routing. > >Critical early review has been determined to be key to a quickly >deployed specification. > >Sue > >-----Original Message----- >From: Margaret Wasserman [mailto:margaret@thingmagic.com] >Sent: Wednesday, June 22, 2005 8:57 AM >To: Adrian Farrel; Brian E Carpenter >Cc: Tony Li; Alex Zinin; rtg-dir@ietf.org; iesg@ietf.org; >routing-discussion@ietf.org; rtg-chairs@ietf.org; Susan Hares >Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of >Links (trill) > > >Hi Adrian, > >At 1:22 PM +0100 6/22/05, Adrian Farrel wrote: >>I think the skill-set to which Brian refers is link state routing. >(Care >>to confirm, Brian?) > >Yes, expertise in link-state routing is certainly one reason why this >work could be seen as more in-scope for the IETF than for the IEEE. >Also, frankly, there is interest in the IETF in doing this work (a >link-state-based Ethernet routing solution), while the IEEE is >continuing to pursue (R)STP-based approaches. > >>If so, why is this WG targeted at the Internet Area not the Routing >area? > >This questions has been discussed in the IESG, as well, and we did >not have 100% agreement regarding the area in which this work belongs. > >Personally, I think that TRILL is a better fit for the Internet area, >and I will explain why... > >Traditionally, the division between the Internet area and the Routing >area has been that the Routing area deals with protocols that >distribute routing information (routes/labels) and the Internet area >has been responsible for the forwarding behaviour and encapsulation >mechanisms that make use of that information. > >The TRILL charter maintains that split -- any work on the routing >protocols themselves would be done in the routing area, while the >encapsulation/forwarding mechanism would be developed in the Internet >area. > >Perhaps you have a different model of the division between the >Routing and Internet areas that makes you think otherwise? > >The IESG discussed this issue several months ago. We agreed that >this work is close to the line between Internet and Routing, but we >reached an agreement that it would best be placed in the Internet >area, with the understanding that we would appoint a technical >advisor and a WG co-chair with routing expertise. BIll Fenner >volunteered to be the Technical Advisor, and Bill and Alex took an >action item to return with a list of potential co-chairs. > >Ultimately, I am not sure that it matters all that much which area >this work is done in, since it will require expertise and involvement >from both areas in order to succeed. > >Margaret From rtg-dir-bounces@ietf.org Wed Jun 22 13:18:33 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04453 for ; Wed, 22 Jun 2005 13:18:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl9GB-0007ya-DE for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 13:43:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl8rQ-0000Rn-42; Wed, 22 Jun 2005 13:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl8rO-0000O7-8c; Wed, 22 Jun 2005 13:17:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04301; Wed, 22 Jun 2005 13:17:54 -0400 (EDT) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl9FX-0007wR-LJ; Wed, 22 Jun 2005 13:42:56 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-blue.research.att.com (Postfix) with ESMTP id 05ABE197397; Wed, 22 Jun 2005 13:12:02 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j5MHHj11005533; Wed, 22 Jun 2005 13:17:45 -0400 Message-Id: <200506221717.j5MHHj11005533@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: tony.li@tony.li References: <42B84B66.3050006@tony.li> <42B990B0.1060700@tony.li> Date: Wed, 22 Jun 2005 13:17:45 -0400 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org Subject: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Tony, [cc: header slightly trimmed] >I would like to propose that we re-open the work on IS-IS >over jumbo frames. Since the IEEE has clearly said that jumbo frames >are out of scope, they can hardly object to the IETF working on it. My recollection, assisted with email archives, was that in December 2001, you, Randy and Ran agreed on a way forward: split the longer MTU specification into a new document, and then define IS-IS over that. Randy sent out drafts called draft-ymbk-mtu-00 in late 2001/early 2002 that I thought were for the first step, but I never saw anything beyond that. Since this was happening right as I was becoming an AD, perhaps I have some of the details of the plan wrong, but I had thought that there was a way forward that was then dropped by the participants due to lack of cycles, not because the IESG said no. Bill From rtg-dir-bounces@ietf.org Wed Jun 22 14:19:13 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12822 for ; Wed, 22 Jun 2005 14:19:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlA2U-0002NM-LN for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 14:33:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl9Yj-0005Xl-V0; Wed, 22 Jun 2005 14:02:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl9Yi-0005Wl-NO; Wed, 22 Jun 2005 14:02:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07271; Wed, 22 Jun 2005 14:02:41 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl9hi-0000cr-4W; Wed, 22 Jun 2005 14:12:03 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 22 Jun 2005 10:46:50 -0700 Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5MHknvM016101; Wed, 22 Jun 2005 10:46:49 -0700 (PDT) Received: from [10.21.122.155] (sjc-vpn6-667.cisco.com [10.21.122.155]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id KAA16198; Wed, 22 Jun 2005 10:43:09 -0700 Message-ID: <42B9A32D.5040302@tony.li> Date: Wed, 22 Jun 2005 10:43:09 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Fenner References: <42B84B66.3050006@tony.li> <42B990B0.1060700@tony.li> <200506221717.j5MHHj11005533@bright.research.att.com> In-Reply-To: <200506221717.j5MHHj11005533@bright.research.att.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Bill, Sorry, but I was explicitly told to stop work. Regardless of that, are you saying that it's possible to continue the work? Tony Bill Fenner wrote: > Tony, > > [cc: header slightly trimmed] > > >>I would like to propose that we re-open the work on IS-IS >>over jumbo frames. Since the IEEE has clearly said that jumbo frames >>are out of scope, they can hardly object to the IETF working on it. > > > My recollection, assisted with email archives, was that in December > 2001, you, Randy and Ran agreed on a way forward: split the longer MTU > specification into a new document, and then define IS-IS over that. > Randy sent out drafts called draft-ymbk-mtu-00 in late 2001/early 2002 > that I thought were for the first step, but I never saw anything beyond > that. > > Since this was happening right as I was becoming an AD, perhaps I have > some of the details of the plan wrong, but I had thought that there was > a way forward that was then dropped by the participants due to lack of > cycles, not because the IESG said no. > > Bill > From rtg-dir-bounces@ietf.org Wed Jun 22 14:51:46 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16294 for ; Wed, 22 Jun 2005 14:51:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlAXQ-0005WR-2N for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 15:05:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlA4o-0000Gj-8h; Wed, 22 Jun 2005 14:35:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlA4l-0000Et-4X; Wed, 22 Jun 2005 14:35:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14922; Wed, 22 Jun 2005 14:35:36 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlAJc-0004Mx-3b; Wed, 22 Jun 2005 14:51:13 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0DE7D2D559A; Wed, 22 Jun 2005 14:25:59 -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 21370-01-12; Wed, 22 Jun 2005 14:25:54 -0400 (EDT) Received: from BOS-exch01.corp.nexthop.com (unknown [192.168.11.20]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9E55B2D51CD; Wed, 22 Jun 2005 14:01:37 -0400 (EDT) Received: from aa-exchange1.corp.nexthop.com ([65.247.36.233]) by BOS-exch01.corp.nexthop.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jun 2005 14:01:37 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Date: Wed, 22 Jun 2005 14:01:35 -0400 Message-ID: Thread-Topic: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) thread-index: AcV3Uiw6/YojNlnKSayAsFVlmJatwwAAG+Iw From: "Susan Hares" To: "Margaret Wasserman" , "Adrian Farrel" , "Brian E Carpenter" X-OriginalArrivalTime: 22 Jun 2005 18:01:37.0309 (UTC) FILETIME=[6EFEFCD0:01C57754] X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Margaret:=20 Routing creates forwarding. The difficulty is in the timing of the updates and not the actual forwarding. Creating encapsulations that scale and can perform well has been in the routing area (MPLS is an example). Updating from the control plane to the forwarding plane is also in the Routing area (FORCES) due to the timing issues. =20 Even if you use existing protocols, you may have timing constraints or protocol issues. An example of this is the MANET OSPF work. (Please refer to the MANET page for this.) Reduced flooding has been discussed and experimented with in MANET. Reduced flooding is key to reducing overload on some IEEE substrates (wireless mesh). Security of the Bridge protocol should be a concern. Again, the discussions in the RP-SEC group have long discussed good and bad algorithms.=20 In 802.1 you are talking about inter-working between multiple LAN areas. This most resembles ISIS/OSPF inter-areas. Auto-configuration of inter-area nodes has experience in routing or the operations. My understanding is that you are not assigning MAC address (aka DHCP like functions) but creating forwarding state.=20 So I guess my summary comment is: "I do not agree with you". The critical component of this work is the link-state, routing auto-configuration and security knobs known to the routing area.=20 If we are trying to get this protocol out quickly, let's build on the expertise in the routing area.=20 Sue Hares -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com]=20 Sent: Wednesday, June 22, 2005 1:16 PM To: Susan Hares; Adrian Farrel; Brian E Carpenter Cc: Tony Li; Alex Zinin; rtg-dir@ietf.org; iesg@ietf.org; routing-discussion@ietf.org; rtg-chairs@ietf.org Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) Hi Sue, The TRILL WG would not be chartered to develop a link-state routing=20 protocol. They would be chartered to make use of an existing=20 link-state routing protocol, and any extensions or modifications to=20 that protocol would be referred to the appropriate routing area WG. The TRILL WG would determine the mechanisms for encapsulating and=20 forwarding Ethernet frames and for auto-configuring the rbridges. I=20 am not sure that in-depth expertise in link-state routing protocols=20 is needed for that. Instead, you need expertise in encapsulation,=20 forwarding and configuration, which are all Internet area topics. Margaret At 12:27 PM -0400 6/22/05, Susan Hares wrote: >Margaret: > >I suggest that the expertise in the link state is in the Routing area of >the IETF. If it belongs in the IETF due to expertise, it belongs in the >Routing. > >Critical early review has been determined to be key to a quickly >deployed specification. > >Sue > >-----Original Message----- >From: Margaret Wasserman [mailto:margaret@thingmagic.com] >Sent: Wednesday, June 22, 2005 8:57 AM >To: Adrian Farrel; Brian E Carpenter >Cc: Tony Li; Alex Zinin; rtg-dir@ietf.org; iesg@ietf.org; >routing-discussion@ietf.org; rtg-chairs@ietf.org; Susan Hares >Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of >Links (trill) > > >Hi Adrian, > >At 1:22 PM +0100 6/22/05, Adrian Farrel wrote: >>I think the skill-set to which Brian refers is link state routing. >(Care >>to confirm, Brian?) > >Yes, expertise in link-state routing is certainly one reason why this >work could be seen as more in-scope for the IETF than for the IEEE. >Also, frankly, there is interest in the IETF in doing this work (a >link-state-based Ethernet routing solution), while the IEEE is >continuing to pursue (R)STP-based approaches. > >>If so, why is this WG targeted at the Internet Area not the Routing >area? > >This questions has been discussed in the IESG, as well, and we did >not have 100% agreement regarding the area in which this work belongs. > >Personally, I think that TRILL is a better fit for the Internet area, >and I will explain why... > >Traditionally, the division between the Internet area and the Routing >area has been that the Routing area deals with protocols that >distribute routing information (routes/labels) and the Internet area >has been responsible for the forwarding behaviour and encapsulation >mechanisms that make use of that information. > >The TRILL charter maintains that split -- any work on the routing >protocols themselves would be done in the routing area, while the >encapsulation/forwarding mechanism would be developed in the Internet >area. > >Perhaps you have a different model of the division between the >Routing and Internet areas that makes you think otherwise? > >The IESG discussed this issue several months ago. We agreed that >this work is close to the line between Internet and Routing, but we >reached an agreement that it would best be placed in the Internet >area, with the understanding that we would appoint a technical >advisor and a WG co-chair with routing expertise. BIll Fenner >volunteered to be the Technical Advisor, and Bill and Alex took an >action item to return with a list of potential co-chairs. > >Ultimately, I am not sure that it matters all that much which area >this work is done in, since it will require expertise and involvement >from both areas in order to succeed. > >Margaret From rtg-dir-bounces@ietf.org Wed Jun 22 16:44:48 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03615 for ; Wed, 22 Jun 2005 16:44:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlCTl-0001Du-NQ for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 17:09:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBzs-0006zJ-0C; Wed, 22 Jun 2005 16:38:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBzq-0006z4-CW; Wed, 22 Jun 2005 16:38:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02657; Wed, 22 Jun 2005 16:38:41 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlC8d-0007lg-Gv; Wed, 22 Jun 2005 16:48:02 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA11042; Wed, 22 Jun 2005 13:22:40 -0700 (PDT) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j5MKMdn05196; Wed, 22 Jun 2005 13:22:39 -0700 (PDT) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Jun 2005 16:22:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jun 2005 16:22:38 -0400 Message-ID: Thread-Topic: Fwd: Re: WG Review: Transparent Interconnection of Lots ofLinks (trill) Thread-Index: AcV3U5IsQqy7w2XaTVyMB0cfld2vEQAEyW9w From: "Manfredi, Albert E" To: "Margaret Wasserman" X-OriginalArrivalTime: 22 Jun 2005 20:22:38.0746 (UTC) FILETIME=[2267CFA0:01C57768] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots ofLinks (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable If TRILL is striving to adapt a link state protocol to a flat address space, seems to me that within the current IETF structure, expertise would be in the routing area. But this seems to create confusion. Maybe I'm confused, but I don't think TRILL is going after creating larger layer 2 nets at all, right? Just attempting to do something more clever than a spanning tree for the layer 2 catenet. So I don't think that lack of market success of NHRP or MPOA, from the old ION wg, where two fair dinkum *routing* protocols were being meshed together, applies here. Isn't the scope of TRILL far smaller? I hope so. We need a "bridging" area in the IETF, then, and perhaps work on things like IGMP snooping can go in there as well. This might help alleviate some of the concerns I've seen aired. We need a home for "this is really supposed to be IEEE work, but they don't want to do it or they need help." Bert > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com]=20 > Sent: Wednesday, June 22, 2005 12:16 PM > To: Susan Hares; Adrian Farrel; Brian E Carpenter > Cc: Alex Zinin; rtg-dir@ietf.org; iesg@ietf.org;=20 > routing-discussion@ietf.org; rtg-chairs@ietf.org > Subject: RE: Fwd: Re: WG Review: Transparent Interconnection=20 > of Lots ofLinks (trill) >=20 >=20 > Hi Sue, >=20 > The TRILL WG would not be chartered to develop a link-state routing=20 > protocol. They would be chartered to make use of an existing=20 > link-state routing protocol, and any extensions or modifications to=20 > that protocol would be referred to the appropriate routing area WG. >=20 > The TRILL WG would determine the mechanisms for encapsulating and=20 > forwarding Ethernet frames and for auto-configuring the rbridges. I=20 > am not sure that in-depth expertise in link-state routing protocols=20 > is needed for that. Instead, you need expertise in encapsulation,=20 > forwarding and configuration, which are all Internet area topics. >=20 > Margaret From rtg-dir-bounces@ietf.org Wed Jun 22 17:18:29 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06320 for ; Wed, 22 Jun 2005 17:18:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlD0O-0002pH-SO for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 17:43:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlCbt-0007Ra-TA; Wed, 22 Jun 2005 17:18:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlCbs-0007RM-1l; Wed, 22 Jun 2005 17:18:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06309; Wed, 22 Jun 2005 17:18:05 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlCzx-0002oi-GA; Wed, 22 Jun 2005 17:43:09 -0400 Received: from jurassic.eng.sun.com ([129.146.104.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j5MLI2Kg015402; Wed, 22 Jun 2005 14:18:02 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5MLHvsZ377256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jun 2005 14:17:59 -0700 (PDT) Message-ID: <42B9D5A2.3050408@sun.com> Date: Wed, 22 Jun 2005 14:18:26 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Adrian Farrel , Brian E Carpenter , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Margaret Wasserman wrote: > The TRILL WG would determine the mechanisms for encapsulating and > forwarding Ethernet frames and for auto-configuring the rbridges. I am > not sure that in-depth expertise in link-state routing protocols is > needed for that. Instead, you need expertise in encapsulation, > forwarding and configuration, which are all Internet area topics. In addition to the above, there is also a need to work out the details how TRILL devices interact with IEEE 802.1D bridges at the edge. This is an issue where the L2VPN WG has some experience, and working with L2VPN and IEEE 802.1 is key. So being in the same area (INT) as L2VPN might be helpful. Erik From rtg-dir-bounces@ietf.org Wed Jun 22 17:22:53 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06681 for ; Wed, 22 Jun 2005 17:22:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlD4e-00037Q-Jz for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 17:47:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlCff-00007J-J6; Wed, 22 Jun 2005 17:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlCfe-000075-Fj; Wed, 22 Jun 2005 17:22:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06579; Wed, 22 Jun 2005 17:22:03 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlD3n-00031b-P2; Wed, 22 Jun 2005 17:47:07 -0400 Received: from jurassic.eng.sun.com ([129.146.108.38]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j5MLM1Kg018055; Wed, 22 Jun 2005 14:22:01 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5MLLv7v378344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jun 2005 14:21:59 -0700 (PDT) Message-ID: <42B9D692.8020407@sun.com> Date: Wed, 22 Jun 2005 14:22:26 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Fenner References: <42B84B66.3050006@tony.li> <42B990B0.1060700@tony.li> <200506221717.j5MHHj11005533@bright.research.att.com> In-Reply-To: <200506221717.j5MHHj11005533@bright.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, tony.li@tony.li, iesg@ietf.org, routing-discussion@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Bill Fenner wrote: > My recollection, assisted with email archives, was that in December > 2001, you, Randy and Ran agreed on a way forward: split the longer MTU > specification into a new document, and then define IS-IS over that. > Randy sent out drafts called draft-ymbk-mtu-00 in late 2001/early 2002 > that I thought were for the first step, but I never saw anything beyond > that. My recollection is that the feedback from IEEE 802 was that we shouldn't touch non-standard things like jumbo-frames, and as a result nothing more was done in this area. Perhaps we asked a suboptimal question back then; whether IEEE 802 liked the idea of us doing something for jumboframes and IS-IS. Had we instead asked them whether they were going to specify how jumboframes work with IS-IS, we would probably have received a different answer. Erik From rtg-dir-bounces@ietf.org Wed Jun 22 17:25:03 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06861 for ; Wed, 22 Jun 2005 17:25:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlD6k-0003Bu-E7 for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 17:50:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlCho-0000jT-4E; Wed, 22 Jun 2005 17:24:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlChn-0000jI-Hz; Wed, 22 Jun 2005 17:24:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06823; Wed, 22 Jun 2005 17:24:13 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlD5s-00038t-R5; Wed, 22 Jun 2005 17:49:17 -0400 Received: from jurassic.eng.sun.com ([129.146.106.105]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j5MLO6Kg019297; Wed, 22 Jun 2005 14:24:06 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5MLO1ZO378938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jun 2005 14:24:03 -0700 (PDT) Message-ID: <42B9D70E.5040401@sun.com> Date: Wed, 22 Jun 2005 14:24:30 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@faster-light.net References: <200506221618.j5MGIB2V039677@workhorse.faster-light.net> In-Reply-To: <200506221618.j5MGIB2V039677@workhorse.faster-light.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Brian E Carpenter , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > Its clear that there is no interest in providers in bridging > solutions. There have been enough failures to keep most people from > further attempts, ranging from the bridging done in regional acedemic > networks in the late 1980s to attempts to use IP at the edges and ATM > in the middle, to the complete failure in the market of ATM approaches > such as RFC1577, NHRP, MPOA. I'm confused. There seems to be a lot of provider interest in L2VPN technology, which is providing what looks like a bridged service across a WAN. Erik From rtg-dir-bounces@ietf.org Wed Jun 22 18:22:24 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12696 for ; Wed, 22 Jun 2005 18:22:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlE0G-0005ud-Sf for rtg-dir-archive@ietf.org; Wed, 22 Jun 2005 18:47:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlDZz-0004Fp-FN; Wed, 22 Jun 2005 18:20:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlDZx-0004Et-2O for rtg-dir@megatron.ietf.org; Wed, 22 Jun 2005 18:20:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12387 for ; Wed, 22 Jun 2005 18:20:13 -0400 (EDT) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DlDy9-0005lf-9Q for rtg-dir@ietf.org; Wed, 22 Jun 2005 18:45:17 -0400 Received: (qmail 52988 invoked from network); 22 Jun 2005 22:20:03 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 22 Jun 2005 22:20:03 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j5MMJfxv044008; Wed, 22 Jun 2005 18:19:41 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200506222219.j5MMJfxv044008@workhorse.faster-light.net> To: Erik Nordmark In-reply-to: Your message of "Wed, 22 Jun 2005 14:24:30 PDT." <42B9D70E.5040401@sun.com> Date: Wed, 22 Jun 2005 18:19:41 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, curtis@faster-light.net, Brian E Carpenter , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb In message <42B9D70E.5040401@sun.com> Erik Nordmark writes: > > Curtis Villamizar wrote: > > > Its clear that there is no interest in providers in bridging > > solutions. There have been enough failures to keep most people from > > further attempts, ranging from the bridging done in regional acedemic > > networks in the late 1980s to attempts to use IP at the edges and ATM > > in the middle, to the complete failure in the market of ATM approaches > > such as RFC1577, NHRP, MPOA. > > I'm confused. There seems to be a lot of provider interest in L2VPN > technology, which is providing what looks like a bridged service across > a WAN. > > Erik For one things that's selling a service to someone else not building one's own network on top of a bridged service. btw- VPLS would be a bridged service. L2VPN is just the L2 part. The motivation for L2VPN with carriers that I've spoken to is not that there is a gold mine in this service. It is quite the contrary. The bridged services and leased lines of any distance are a shrinking market or very slow growth at best and no longer justify their own network when the IP network is growing to circuit capacities in multiples of OC192. If these services can be efficiently carried over the same nework that carries IP it would be a cost savings and in some cases get these services back in the black again. Provider backbones over anything resembling a bridged network seems to be close to dead. Also note that I said that past experience is enough to keep "most" people from repeating mistakes of the past. Another mistake of the past is radically overestimating market growth so if anyone does indicate a gold mine in L2VPN I'd be skeptical. Curtis From rtg-dir-bounces@ietf.org Thu Jun 23 08:17:24 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03088 for ; Thu, 23 Jun 2005 08:17:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlR2O-0000Pk-A5 for rtg-dir-archive@ietf.org; Thu, 23 Jun 2005 08:42:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlQdD-0005qt-03; Thu, 23 Jun 2005 08:16:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlQdB-0005qO-El; Thu, 23 Jun 2005 08:16:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03030; Thu, 23 Jun 2005 08:16:28 -0400 (EDT) Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlR1U-0000OU-RG; Thu, 23 Jun 2005 08:41:38 -0400 Received: by newdev.harvard.edu (Postfix, from userid 501) id 4C2B53E8142; Thu, 23 Jun 2005 08:16:19 -0400 (EDT) To: iesg@ietf.org, routing-discussion@ietf.org, rtg-dir@ietf.org Message-Id: <20050623121619.4C2B53E8142@newdev.harvard.edu> Date: Thu, 23 Jun 2005 08:16:19 -0400 (EDT) From: sob@harvard.edu (Scott Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Tony reported: > Sorry, but I was explicitly told to stop work. Tony is quite correct Erik then opined: > My recollection is that the feedback from IEEE 802 was that we shouldn't > touch non-standard things like jumbo-frames, and as a result nothing > more was done in this area. > > Perhaps we asked a suboptimal question back then; whether IEEE 802 liked > the idea of us doing something for jumboframes and IS-IS. Had we instead > asked them whether they were going to specify how jumboframes work with > IS-IS, we would probably have received a different answer. my discussions with the IEEE at that time mentioned IS-IS but that was not a factor in the exchange - the IEEE said flatly that 1/ jumbo frames for Ethernet were not gonna happen in the IEEE 2/ they did not want the IETF to make a standard that defined or assumed jumbo frames on Ethernet re: Erik's suggested question - in effect they did answer that question 'no - they were not going to specify how jumboframes work at all (nevermind with IS-IS) and please do not that that answer to mean that the IETF should do so' Scott From rtg-dir-bounces@ietf.org Thu Jun 23 08:47:47 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05989 for ; Thu, 23 Jun 2005 08:47:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlRVp-0001ux-8c for rtg-dir-archive@ietf.org; Thu, 23 Jun 2005 09:12:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlR55-0002dZ-Tg; Thu, 23 Jun 2005 08:45:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlR51-0002d9-6b; Thu, 23 Jun 2005 08:45:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05227; Thu, 23 Jun 2005 08:41:45 -0400 (EDT) Received: from imo-d01.mx.aol.com ([205.188.157.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlRPv-0001X5-5K; Thu, 23 Jun 2005 09:06:55 -0400 Received: from ewgray2k@netscape.net by imo-d01.mx.aol.com (mail_out_v38_r1.7.) id 7.c2.10b588af (22682); Thu, 23 Jun 2005 08:41:21 -0400 (EDT) Received: from [192.168.7.131] (c-24-61-197-198.hsd1.nh.comcast.net [24.61.197.198]) by air-in04.mx.aol.com (v106.2) with ESMTP id MAILININ43-589a42baadf0170; Thu, 23 Jun 2005 08:41:21 -0400 Message-ID: <42BAADE8.6060802@netscape.net> Date: Thu, 23 Jun 2005 08:41:12 -0400 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: margaret@thingmagic.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 24.61.197.198 X-Mailer: Unknown (No Version) X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Adrian Farrel , Brian E Carpenter , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7bit Margaret, The interesting thing here is that any changes in the encapsulation of Ethernet frames would have drastic implications on all Ethernet equipment - including NIC cards in Ethernet end stations. If this is not the case, then we are talking about an encapsulation of a transport segment, rather than encapsulation end-to-end. If that is what we are talking about, how does this "encapsulation" differ from Martini? Because of these considerations, I had assumed that what we would be doing in the alleged TRILL working group is specifying how Ethernet (MAC) address reachability would be advertised in an OSPF-like routing protocol. For the sake of simplifying the discussion, let's assume that it would be OSPF instead of an off the cuff spinout of a generic link state routing protocol. If the intent is to specify the use of the OSPF routing protocol to advertise MAC reachability - as it certainly seems to be - then the same argument you make for this work in the IETF applies to doing it in the Routing Area as well. That is where the specific expertise lies. On the other hand, if the intent is to specify yet another L2 encapsulation - which could be used as an argument for doing this in the Internet Area - then the alleged expertise (for yet another L2 encapsulation) is no more specific to the IETF than to any other organization you might care to name. My general impression from the discussion is that we may have been successful in playing word games with IEEE on this score where we have not been anywhere near as successful in a similar context previously. If that is the case, then those who have been successful in this should be congratulated for their ability to bandy words - if not necessarily for their intentions in doing so. It also looks to me like some people want to do this work and - because they have to go to the IETF anyway - they want to do it in the IETF. Frankly, I think we might be able to make an argument for doing this work in the IETF - but only if we simultaneously acknowledge that it should be doen in the Routing Area. One of the things that doing it this way might help to do is eliminate some of the energy being poured into this effort that is apparently based - at least in part - on some agenda(s) not shared with the IETF as a whole. Just to be crystal clear, I think it is obvious that some of the IETF leadership wants to do this work. I also think it is clear that a lot of people want this work to be done somewhere. And it should also be clear that not everyone in the IETF is convinced that the IETF is the place to do it - irrespective of whether or not the IEEE wants to play in the same sandbox too. But - if we're going to do it in the IETF, let's do it in the right Area. -- Eric margaret@thingmagic.com wrote: > > Hi Sue, > > The TRILL WG would not be chartered to develop a link-state routing > protocol. They would be chartered to make use of an existing > link-state routing protocol, and any extensions or modifications to > that protocol would be referred to the appropriate routing area WG. > > The TRILL WG would determine the mechanisms for encapsulating and > forwarding Ethernet frames and for auto-configuring the rbridges. I > am not sure that in-depth expertise in link-state routing protocols is > needed for that. Instead, you need expertise in encapsulation, > forwarding and configuration, which are all Internet area topics. > > Margaret > > > At 12:27 PM -0400 6/22/05, Susan Hares wrote: > >> Margaret: >> >> I suggest that the expertise in the link state is in the Routing area of >> the IETF. If it belongs in the IETF due to expertise, it belongs in the >> Routing. >> >> Critical early review has been determined to be key to a quickly >> deployed specification. >> >> Sue >> >> -----Original Message----- >> From: Margaret Wasserman [mailto:margaret@thingmagic.com] >> Sent: Wednesday, June 22, 2005 8:57 AM >> To: Adrian Farrel; Brian E Carpenter >> Cc: Tony Li; Alex Zinin; rtg-dir@ietf.org; iesg@ietf.org; >> routing-discussion@ietf.org; rtg-chairs@ietf.org; Susan Hares >> Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of >> Links (trill) >> >> >> Hi Adrian, >> >> At 1:22 PM +0100 6/22/05, Adrian Farrel wrote: >> >>> I think the skill-set to which Brian refers is link state routing. >> >> (Care >> >>> to confirm, Brian?) >> >> >> Yes, expertise in link-state routing is certainly one reason why this >> work could be seen as more in-scope for the IETF than for the IEEE. >> Also, frankly, there is interest in the IETF in doing this work (a >> link-state-based Ethernet routing solution), while the IEEE is >> continuing to pursue (R)STP-based approaches. >> >>> If so, why is this WG targeted at the Internet Area not the Routing >> >> area? >> >> This questions has been discussed in the IESG, as well, and we did >> not have 100% agreement regarding the area in which this work belongs. >> >> Personally, I think that TRILL is a better fit for the Internet area, >> and I will explain why... >> >> Traditionally, the division between the Internet area and the Routing >> area has been that the Routing area deals with protocols that >> distribute routing information (routes/labels) and the Internet area >> has been responsible for the forwarding behaviour and encapsulation >> mechanisms that make use of that information. >> >> The TRILL charter maintains that split -- any work on the routing >> protocols themselves would be done in the routing area, while the >> encapsulation/forwarding mechanism would be developed in the Internet >> area. >> >> Perhaps you have a different model of the division between the >> Routing and Internet areas that makes you think otherwise? >> >> The IESG discussed this issue several months ago. We agreed that >> this work is close to the line between Internet and Routing, but we >> reached an agreement that it would best be placed in the Internet >> area, with the understanding that we would appoint a technical >> advisor and a WG co-chair with routing expertise. BIll Fenner >> volunteered to be the Technical Advisor, and Bill and Alex took an >> action item to return with a list of potential co-chairs. >> >> Ultimately, I am not sure that it matters all that much which area >> this work is done in, since it will require expertise and involvement >> from both areas in order to succeed. >> >> Margaret > > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Thu Jun 23 09:23:48 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09413 for ; Thu, 23 Jun 2005 09:23:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlS4g-0003gc-QP for rtg-dir-archive@ietf.org; Thu, 23 Jun 2005 09:48:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlRe7-0000mn-Og; Thu, 23 Jun 2005 09:21:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlRe6-0000mc-MM; Thu, 23 Jun 2005 09:21:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09182; Thu, 23 Jun 2005 09:21:24 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlS2H-0003XP-Ux; Thu, 23 Jun 2005 09:46:34 -0400 Received: from [66.30.121.250] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 400379; Thu, 23 Jun 2005 09:16:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <42BAADE8.6060802@netscape.net> References: <42BAADE8.6060802@netscape.net> Date: Thu, 23 Jun 2005 09:20:21 -0400 To: ewgray@GraIyMage.com From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Adrian Farrel , Brian E Carpenter , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Hi Eric, At 8:41 AM -0400 6/23/05, Eric W Gray wrote: > If the intent is to specify the use of the OSPF routing protocol >to advertise MAC >reachability - as it certainly seems to be - then the same argument >you make for this >work in the IETF applies to doing it in the Routing Area as well. >That is where the >specific expertise lies. Determining how the Ethernet addresses would be advertised in OSPF (or IS-IS) would be done in the appropriate Routing area WG (presumably the OSPF or IS-IS WG). I believe that we are in agreement about where this expertise lies. > On the other hand, if the intent is to specify yet another L2 >encapsulation - which >could be used as an argument for doing this in the Internet Area - >then the alleged >expertise (for yet another L2 encapsulation) is no more specific to >the IETF than to >any other organization you might care to name. I have seen plenty of bad encapsulations. If expertise is not required, then perhaps the people who wrote the bad encapsulations (ones that failed to consider MTU/fragmentation issues, for example) were just sloppy? > My general impression from the discussion is that we may have >been successful >in playing word games with IEEE on this score where we have not been anywhere >near as successful in a similar context previously. If that is the >case, then those who >have been successful in this should be congratulated for their >ability to bandy words >- if not necessarily for their intentions in doing so. Your paragraph seems to assume that the IETF and the IEEE both wanted to do this work, and we somehow _won_ the right to do it through some negotiation. This isn't the case at all. There are some people in the IETF who wanted to do this work. The IEEE is not interested in doing this work, preferring to continue their work on (R)STP-based solutions. We (the IESG) initiated a discussion with the IEEE 802 leadership about this topic, and the IEEE leadership did not object to this work being done in the IETF. We have been (and continue to be) a bit concerned about whether there are sufficient quantities of the right expertise in the IETF to do this work well. However, responses to technical discussions on the TRILL list have been quite good, and there does seem to be a core group of well-qualified people committed to this work. > It also looks to me like some people want to do this work and - >because they >have to go to the IETF anyway - they want to do it in the IETF. >Frankly, I think >we might be able to make an argument for doing this work in the IETF >- but only >if we simultaneously acknowledge that it should be doen in the Routing Area. > > One of the things that doing it this way might help to do is >eliminate some of the >energy being poured into this effort that is apparently based - at >least in part - on >some agenda(s) not shared with the IETF as a whole. It is not clear to me what motivations you are ascribing to whom. If you think that there is a possibility of any type of misconduct or gaming of the system here, perhaps you could be more explicit? > Just to be crystal clear, I think it is obvious that some of the >IETF leadership >wants to do this work. I also think it is clear that a lot of people >want this work to >be done somewhere. And it should also be clear that not everyone in >the IETF is >convinced that the IETF is the place to do it - irrespective of >whether or not the >IEEE wants to play in the same sandbox too. But - if we're going to >do it in the >IETF, let's do it in the right Area. I am a bit concerned about this paragraph, because you seem to be indicating that "some members of the IETF leadership" are doing something underhanded here. Personally, I think that the TRILL proposal is technically interesting and may benefit the Internet. I also respect the key contributors to this effort. I have advocated for this work because it was brought to me, and because I believe that it would be a good thing to do. This is how most IETF efforts get started, and I don't think that there is anything unethical going on here. Do you think otherwise? If the IESG decides to charter this work (we are considering that on our telechat today), then the IESG will need to decide in which area to charter it. I don't consider this choice to be as black-and-white as you apparently do. However, I do think that the work itself (what the TRILL WG would be doing, not what the link-state routing protocol WG would need to do) is more closely related to other INT area efforts (such as L2VPN) than it is to the routing area. Your comments about the "alleged expertise" required to design an L2 encapsulation, and the fact that you didn't mention the configuration aspects of this work indicate to me that you may be underestimating the amount and complexity of the non-routing-protocol work involved in this effort. Just so that you understand, I am not planning to be the responsible AD for this work, and it is not an issue to me whether the responsible AD is Mark, Bill or Alex (I trust all of them, and I believe that they all have the expertise to do a good job here). The decision about where to place this work should be based, IMO, on where it belongs in the current structure of the IETF areas, and I personally see it as more appropriate for the INT area. I understand that you see it differently, and some other people share your view. This is something that we will have to work out in the IESG if we decide to charter the group. Thank you for your input, and I hope that you will consider being involved in the resulting WG, regardless of the area in which it is chartered. Margaret From rtg-dir-bounces@ietf.org Thu Jun 23 10:21:51 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15806 for ; Thu, 23 Jun 2005 10:21:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlSyr-0006OW-Ta for rtg-dir-archive@ietf.org; Thu, 23 Jun 2005 10:47:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSVp-0002rM-Q5; Thu, 23 Jun 2005 10:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSVo-0002qr-EN; Thu, 23 Jun 2005 10:17:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14891; Thu, 23 Jun 2005 10:16:06 -0400 (EDT) Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlStF-00067y-0J; Thu, 23 Jun 2005 10:41:17 -0400 Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v38_r1.7.) id 7.e7.119e10e4 (22680); Thu, 23 Jun 2005 10:15:18 -0400 (EDT) Received: from [192.168.7.131] (c-24-61-197-198.hsd1.nh.comcast.net [24.61.197.198]) by air-in04.mx.aol.com (v106.2) with ESMTP id MAILININ41-589842bac3f5c2; Thu, 23 Jun 2005 10:15:17 -0400 Message-ID: <42BAC3ED.4060305@netscape.net> Date: Thu, 23 Jun 2005 10:15:09 -0400 From: Eric W Gray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Margaret Wasserman References: <42BAADE8.6060802@netscape.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 24.61.197.198 X-Mailer: Unknown (No Version) X-Spam-Score: 0.1 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Adrian Farrel , Brian E Carpenter , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: 7bit Margaret, What you did not answer is my initial comment about encapsulation. I will include that again here: "The interesting thing here is that any changes in the encapsulation of Ethernet frames would have drastic implications on all Ethernet equipment - including NIC cards in Ethernet end stations. If this is not the case, then we are talking about an encapsulation of a transport segment, rather than encapsulation end-to-end. If that is what we are talking about, how does this 'encapsulation' differ from Martini? " As this was my first paragraph, and it set the tone for the remaining comments, omitting it may have been just a little disingenuous. Given that nobody has explained - as far as I know - what encapsulation changes we expect to make (that are not covered by work already completed), your entire argument about "encapsulation complexity" may be irrelevant. As for my specific references to word-smithing, this also requires an understanding of the scope of intent to change Ethernet encapsulation. If we talk to the IEEE about using OSPF to transport MAC address information, naturally they would be amenable to specifying how that should be done in the IETF. But did we talk specifically about introducing a new Ethernet encasulation when we talked to the IEEE? If we are not talking about a new (or changed) end-to-end Ethernet encapsulation, then we are talking about tunneling encapsulation for L2 frames across part of the network. If we plan to use L3/label encapsulation to do this, then we need to know how this requirement differs from existing mechanisms (hence the Martini reference that also is included in the text you omitted). If we are talking strictly about defining ways to use existing encapsulation in some combination with extending routing protocols. then the work belongs in the Routing Area, more than in the Internet Area. One other possibility is that we may be talking about single hop encapsulation for OSPF-like advertisements in BPDU-like setup transactions. In this case, the expertise you refer to does not exist in the IETF any more than it does elsewhere - since this is not something that has been done before. My concern is that - if we are indeed talking about a replacement for Ethernet encapsulation, then we will probably find out that the IEEE does care. The fact that we intend to liase with the IEEE is good, but it will not help if it turns out that they do not want us to proceed further after we have spent huge amounts of energy getting to the point that everybody finally understands what it is that we intend to do. -- Eric Margaret Wasserman wrote: > > Hi Eric, > > At 8:41 AM -0400 6/23/05, Eric W Gray wrote: > >> If the intent is to specify the use of the OSPF routing protocol >> to advertise MAC >> reachability - as it certainly seems to be - then the same argument >> you make for this >> work in the IETF applies to doing it in the Routing Area as well. >> That is where the >> specific expertise lies. > > > Determining how the Ethernet addresses would be advertised in OSPF (or > IS-IS) would be done in the appropriate Routing area WG (presumably > the OSPF or IS-IS WG). I believe that we are in agreement about where > this expertise lies. > >> On the other hand, if the intent is to specify yet another L2 >> encapsulation - which >> could be used as an argument for doing this in the Internet Area - >> then the alleged >> expertise (for yet another L2 encapsulation) is no more specific to >> the IETF than to >> any other organization you might care to name. > > > I have seen plenty of bad encapsulations. If expertise is not > required, then perhaps the people who wrote the bad encapsulations > (ones that failed to consider MTU/fragmentation issues, for example) > were just sloppy? > >> My general impression from the discussion is that we may have been >> successful >> in playing word games with IEEE on this score where we have not been >> anywhere >> near as successful in a similar context previously. If that is the >> case, then those who >> have been successful in this should be congratulated for their >> ability to bandy words >> - if not necessarily for their intentions in doing so. > > > Your paragraph seems to assume that the IETF and the IEEE both wanted > to do this work, and we somehow _won_ the right to do it through some > negotiation. This isn't the case at all. There are some people in > the IETF who wanted to do this work. The IEEE is not interested in > doing this work, preferring to continue their work on (R)STP-based > solutions. We (the IESG) initiated a discussion with the IEEE 802 > leadership about this topic, and the IEEE leadership did not object to > this work being done in the IETF. > > We have been (and continue to be) a bit concerned about whether there > are sufficient quantities of the right expertise in the IETF to do > this work well. However, responses to technical discussions on the > TRILL list have been quite good, and there does seem to be a core > group of well-qualified people committed to this work. > >> It also looks to me like some people want to do this work and - >> because they >> have to go to the IETF anyway - they want to do it in the IETF. >> Frankly, I think >> we might be able to make an argument for doing this work in the IETF >> - but only >> if we simultaneously acknowledge that it should be doen in the >> Routing Area. >> >> One of the things that doing it this way might help to do is >> eliminate some of the >> energy being poured into this effort that is apparently based - at >> least in part - on >> some agenda(s) not shared with the IETF as a whole. > > > It is not clear to me what motivations you are ascribing to whom. If > you think that there is a possibility of any type of misconduct or > gaming of the system here, perhaps you could be more explicit? > >> Just to be crystal clear, I think it is obvious that some of the >> IETF leadership >> wants to do this work. I also think it is clear that a lot of people >> want this work to >> be done somewhere. And it should also be clear that not everyone in >> the IETF is >> convinced that the IETF is the place to do it - irrespective of >> whether or not the >> IEEE wants to play in the same sandbox too. But - if we're going to >> do it in the >> IETF, let's do it in the right Area. > > > I am a bit concerned about this paragraph, because you seem to be > indicating that "some members of the IETF leadership" are doing > something underhanded here. Personally, I think that the TRILL > proposal is technically interesting and may benefit the Internet. I > also respect the key contributors to this effort. I have advocated > for this work because it was brought to me, and because I believe that > it would be a good thing to do. This is how most IETF efforts get > started, and I don't think that there is anything unethical going on > here. Do you think otherwise? > > If the IESG decides to charter this work (we are considering that on > our telechat today), then the IESG will need to decide in which area > to charter it. I don't consider this choice to be as black-and-white > as you apparently do. However, I do think that the work itself (what > the TRILL WG would be doing, not what the link-state routing protocol > WG would need to do) is more closely related to other INT area efforts > (such as L2VPN) than it is to the routing area. > > Your comments about the "alleged expertise" required to design an L2 > encapsulation, and the fact that you didn't mention the configuration > aspects of this work indicate to me that you may be underestimating > the amount and complexity of the non-routing-protocol work involved in > this effort. > > Just so that you understand, I am not planning to be the responsible > AD for this work, and it is not an issue to me whether the responsible > AD is Mark, Bill or Alex (I trust all of them, and I believe that they > all have the expertise to do a good job here). The decision about > where to place this work should be based, IMO, on where it belongs in > the current structure of the IETF areas, and I personally see it as > more appropriate for the INT area. I understand that you see it > differently, and some other people share your view. This is something > that we will have to work out in the IESG if we decide to charter the > group. > > Thank you for your input, and I hope that you will consider being > involved in the resulting WG, regardless of the area in which it is > chartered. > > Margaret > > > From rtg-dir-bounces@ietf.org Thu Jun 23 10:44:41 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18364 for ; Thu, 23 Jun 2005 10:44:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlTKx-0007a1-W8 for rtg-dir-archive@ietf.org; Thu, 23 Jun 2005 11:09:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSwU-0008Fu-F8; Thu, 23 Jun 2005 10:44:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSwT-0008DZ-3o; Thu, 23 Jun 2005 10:44:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18344; Thu, 23 Jun 2005 10:44:31 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlTKn-0007Z5-JU; Thu, 23 Jun 2005 11:09:43 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-4.cisco.com with ESMTP; 23 Jun 2005 07:44:22 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5NEiHbd002444; Thu, 23 Jun 2005 10:44:17 -0400 (EDT) Message-Id: <200506231444.j5NEiHbd002444@rtp-core-1.cisco.com> To: sob@harvard.edu (Scott Bradner) In-reply-to: Your message of Thu, 23 Jun 2005 08:16:19 -0400. <20050623121619.4C2B53E8142@newdev.harvard.edu> 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 Date: Thu, 23 Jun 2005 10:44:17 -0400 From: Eric Rosen X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: erosen@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab > they were not going to specify how jumboframes work at all > (nevermind with IS-IS) and please do not that that answer to mean that > the IETF should do so Really, with regard to jumbo frames the marketplace has spoken and the IEEE has lost. Jumbo frames are a defacto standard. (Of course, just as happens in theIETF, the IEEE folks don't always admit it when they've lost out to the marketplace.) Given that jumbo frames are in use, it seems silly to say that we can't specify how to use them for IP protocols. There is even some precedent; RFC 3032 (MPLS encaps) mentions the possibility of using ethernet frames which contain 1504 or 1508 bytes. It's even sillier to say that (a) we're not allowed to do a carefully scoped standard that solves a well-specified and immediate problem in the use of an existing de facto standard, but that (b) it's fine to do a standard which tells folks to ignore IEEE entirely and do bridging in a completely new way. From rtg-dir-bounces@ietf.org Thu Jun 23 11:25:41 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23900 for ; Thu, 23 Jun 2005 11:25:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlTye-0001PK-JU for rtg-dir-archive@ietf.org; Thu, 23 Jun 2005 11:50:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTZ2-0000wd-Dm; Thu, 23 Jun 2005 11:24:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTYy-0000wN-SP; Thu, 23 Jun 2005 11:24:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23609; Thu, 23 Jun 2005 11:24:12 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlTxA-0001Gl-6Y; Thu, 23 Jun 2005 11:49:24 -0400 Received: from jurassic.eng.sun.com ([129.146.58.166]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j5NFO8FF010911; Thu, 23 Jun 2005 08:24:08 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5NFO4e3660036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 23 Jun 2005 08:24:06 -0700 (PDT) Message-ID: <42BAD431.8000403@sun.com> Date: Thu, 23 Jun 2005 08:24:33 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ewgray@GraIyMage.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill)] X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit [With reduced cc list] Eric W Gray wrote: > The interesting thing here is that any changes in the encapsulation > of Ethernet > frames would have drastic implications on all Ethernet equipment - > including NIC > cards in Ethernet end stations. If this is not the case, then we are > talking about an > encapsulation of a transport segment, rather than encapsulation > end-to-end. If that > is what we are talking about, how does this "encapsulation" differ from > Martini? Perhaps I can help answer this. The encapsulation is not end-to-end; it is merely between the TRILL devices. The draft-radia-rbridge draft shows the current thinking for the encapsulation, with a header than in the case of carrying things over Ethernet include - source rbridge MAC address (so that bridges between the rbridges don't get confused) - next hop rbridge MAC address (to avoid proliferation should the bridges flood the frame and multiple rbridges receive it) - ttl (to limit the damage from any temporary routing loops) - last hop rbridge (so that intermediate rbridges don't need to track the location of each station) - Ethernet type So this is quite different than the Martini approach. Should TRILL later be expanded to apply to run over MPLS (something which is not in the current charter) then I suspect we'd end up with an encapsulation like Martini, and a link-state routing protocol carrying the MAC addresses. So the TRILL work is architecturally quite similar to the VPLS work in L2VPN. The encapsulation that is safe and scalable for Ethernet is a key difference. Erik From rtg-dir-bounces@ietf.org Thu Jun 23 11:50:15 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26454 for ; Thu, 23 Jun 2005 11:50:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlUMR-0002gG-2x for rtg-dir-archive@ietf.org; Thu, 23 Jun 2005 12:15:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTwt-0006pM-C5; Thu, 23 Jun 2005 11:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTwq-0006nW-8r; Thu, 23 Jun 2005 11:49:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26412; Thu, 23 Jun 2005 11:48:57 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlULB-0002Xq-Tl; Thu, 23 Jun 2005 12:14:10 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 23 Jun 2005 08:48:44 -0700 Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j5NFmf6p016373; Thu, 23 Jun 2005 08:48:42 -0700 (PDT) Received: from [10.21.144.8] (sjc-vpn7-8.cisco.com [10.21.144.8]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id IAA17342; Thu, 23 Jun 2005 08:48:41 -0700 Message-ID: <42BAD9D8.90903@tony.li> Date: Thu, 23 Jun 2005 08:48:40 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Bradner References: <20050623121619.4C2B53E8142@newdev.harvard.edu> In-Reply-To: <20050623121619.4C2B53E8142@newdev.harvard.edu> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Scott, > 2/ they did not want the IETF to make a standard that > defined or assumed jumbo frames on Ethernet My understanding further extended that prohibition to any informational or experimental RFC as well. Those would have been (and still would be) the best possible outcomes. There was no requirement to make IS-IS over jumbo frames into a standard. Tony From rtg-dir-bounces@ietf.org Thu Jun 23 11:56:35 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26979 for ; Thu, 23 Jun 2005 11:56:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlUSZ-000300-Dc for rtg-dir-archive@ietf.org; Thu, 23 Jun 2005 12:21:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlU0x-0007Na-QB; Thu, 23 Jun 2005 11:53:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlU0v-0007Mz-Bq; Thu, 23 Jun 2005 11:53:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26675; Thu, 23 Jun 2005 11:53:11 -0400 (EDT) Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlUPH-0002pL-OD; Thu, 23 Jun 2005 12:18:23 -0400 Received: by newdev.harvard.edu (Postfix, from userid 501) id A21C13E8933; Thu, 23 Jun 2005 11:53:04 -0400 (EDT) To: sob@harvard.edu, tony.li@tony.li In-Reply-To: <42BAD9D8.90903@tony.li> Message-Id: <20050623155304.A21C13E8933@newdev.harvard.edu> Date: Thu, 23 Jun 2005 11:53:04 -0400 (EDT) From: sob@harvard.edu (Scott Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de > My understanding further extended that prohibition to any informational > or experimental RFC as well. that was the case to start with, but as someone else pointed out, a few years later the IEEE said that they would accept an info RFC (thought they were not all that happy) Scott From rtg-dir-bounces@ietf.org Thu Jun 23 12:06:39 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28064 for ; Thu, 23 Jun 2005 12:06:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlUcI-0003W7-Vw for rtg-dir-archive@ietf.org; Thu, 23 Jun 2005 12:31:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlUCy-0001V4-MZ; Thu, 23 Jun 2005 12:05:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlUCv-0001Tp-SZ; Thu, 23 Jun 2005 12:05:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27968; Thu, 23 Jun 2005 12:05:35 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlUbF-0003Ts-UO; Thu, 23 Jun 2005 12:30:48 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 23 Jun 2005 09:05:20 -0700 X-IronPort-AV: i="3.93,224,1115017200"; d="scan'208"; a="193706692:sNHT25529372" Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j5NG5Ebp013083; Thu, 23 Jun 2005 09:05:15 -0700 (PDT) Received: from [10.21.144.8] (sjc-vpn7-8.cisco.com [10.21.144.8]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id JAA20712; Thu, 23 Jun 2005 09:05:14 -0700 Message-ID: <42BADDB9.9040406@tony.li> Date: Thu, 23 Jun 2005 09:05:13 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Bradner References: <20050623155304.A21C13E8933@newdev.harvard.edu> In-Reply-To: <20050623155304.A21C13E8933@newdev.harvard.edu> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit >>My understanding further extended that prohibition to any informational >>or experimental RFC as well. > > that was the case to start with, but as someone else pointed out, > a few years later the IEEE said that they would accept an info RFC > (thought they were not all that happy) First I hear of it. In any case, I would very much like to progress the work. Given the non-standard status of jumbo frames, I have no problem moving forward with informational or experimental as the goal. Tony From rtg-dir-bounces@ietf.org Thu Jun 23 12:29:38 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01463 for ; Thu, 23 Jun 2005 12:29:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlUyW-0004pR-5l for rtg-dir-archive@ietf.org; Thu, 23 Jun 2005 12:54:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlUZD-0008JI-0l; Thu, 23 Jun 2005 12:28:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlUZ8-0008H1-SI; Thu, 23 Jun 2005 12:28:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01300; Thu, 23 Jun 2005 12:28:26 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlUxM-0004m1-Ha; Thu, 23 Jun 2005 12:53:40 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E42A22D5B0F; Thu, 23 Jun 2005 12:28:08 -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 30404-01-20; Thu, 23 Jun 2005 12:28:05 -0400 (EDT) Received: from BOS-exch01.corp.nexthop.com (unknown [192.168.11.20]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C2B122D510C; Thu, 23 Jun 2005 11:47:10 -0400 (EDT) Received: from aa-exchange1.corp.nexthop.com ([65.247.36.233]) by BOS-exch01.corp.nexthop.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Jun 2005 11:47:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Jun 2005 11:47:07 -0400 Message-ID: Thread-Topic: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) thread-index: AcV39y3xYHVK+ghnRqWSf5EYctsVsQAEqUBg From: "Susan Hares" To: "Margaret Wasserman" , X-OriginalArrivalTime: 23 Jun 2005 15:47:10.0153 (UTC) FILETIME=[D1026B90:01C5780A] X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Adrian Farrel , Brian E Carpenter Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Margaret:=20 Does IETF have a formal relationship with IEEE? The paragraphs from your earlier mails have me a bit confused. =20 > Your paragraph seems to assume that the IETF and the IEEE both wanted=20 > to do this work, and we somehow _won_ the right to do it through some=20 > negotiation. This isn't the case at all. There are some people in=20 > the IETF who wanted to do this work. The IEEE is not interested in=20 > doing this work, preferring to continue their work on (R)STP-based=20 > solutions. We (the IESG) initiated a discussion with the IEEE 802=20 > leadership about this topic, and the IEEE leadership did not object=20 > to this work being done in the IETF. [....]=20 > We have been (and continue to be) a bit concerned about whether there=20 > are sufficient quantities of the right expertise in the IETF to do=20 > this work well. However, responses to technical discussions on the=20 > TRILL list have been quite good, and there does seem to be a core=20 > group of well-qualified people committed to this work. 1st - I'm happy to contribute to this work in what ever forum it exists in. 2nd - I would like to have this discussion end today (after IESG), but it would be "way cool" and necessary to document who, what, when and where in a document that you can post online about the IEEE/IETF discussions. 3rd - It would be "way cool"/useful to summarize this discussion in a document that is associated with the working group pages. Shalom,=20 Sue Hares (Still inspired by folks like you to make the IETF consistent!) From rtg-dir-bounces@ietf.org Thu Jun 23 12:50:36 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03348 for ; Thu, 23 Jun 2005 12:50:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlVIq-0005ve-Ld for rtg-dir-archive@ietf.org; Thu, 23 Jun 2005 13:15:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlUtm-0003qA-JC; Thu, 23 Jun 2005 12:49:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlUtl-0003pq-MP for rtg-dir@megatron.ietf.org; Thu, 23 Jun 2005 12:49:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03253 for ; Thu, 23 Jun 2005 12:49:50 -0400 (EDT) Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DlVI5-0005tq-Nh for rtg-dir@ietf.org; Thu, 23 Jun 2005 13:15:04 -0400 Received: (qmail 36220 invoked from network); 23 Jun 2005 16:49:42 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 23 Jun 2005 16:49:42 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j5NGnAkW046351; Thu, 23 Jun 2005 12:49:10 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200506231649.j5NGnAkW046351@workhorse.faster-light.net> To: erosen@cisco.com In-reply-to: Your message of "Thu, 23 Jun 2005 10:44:17 EDT." <200506231444.j5NEiHbd002444@rtp-core-1.cisco.com> Date: Thu, 23 Jun 2005 12:49:10 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: rtg-dir@ietf.org, Scott Bradner , routing-discussion@ietf.org, iesg@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 In message <200506231444.j5NEiHbd002444@rtp-core-1.cisco.com> Eric Rosen writes: > > > > they were not going to specify how jumboframes work at all > > (nevermind with IS-IS) and please do not that that answer to mean that > > the IETF should do so > > Really, with regard to jumbo frames the marketplace has spoken and the IEEE > has lost. Jumbo frames are a defacto standard. (Of course, just as happens > in theIETF, the IEEE folks don't always admit it when they've lost out to > the marketplace.) > > Given that jumbo frames are in use, it seems silly to say that we can't > specify how to use them for IP protocols. There is even some precedent; RFC > 3032 (MPLS encaps) mentions the possibility of using ethernet frames which > contain 1504 or 1508 bytes. > > It's even sillier to say that (a) we're not allowed to do a carefully scoped > standard that solves a well-specified and immediate problem in the use of an > existing de facto standard, but that (b) it's fine to do a standard which > tells folks to ignore IEEE entirely and do bridging in a completely new way. I have to agree that it is silly that IEEE does not acknowledge jumbo frames. The provider market has spoken and any large router or large ethernet switch either implements jumbo frames or doesn't play in that market. The reason for jumbo frames is that packet fragmentation in the core can destroy performance. As long as MTUs larger than 1500 are in use, and they are, and the provider POPs where they are handling very high throughput interfaces of higher MTU, the ethernet MTU will be large enough or ethernet won't be used. Its as simple as that. Lets not use the argument that IEEE should let IETF do things with jumbo frames because they are allowing IETF to do something else. Perhaps IETF can specify how ISIS works with the defacto ethernet-like link layer protocol that happens to differ only in the MTU size and make it informational. Its not as if lack of an RFC has stopped any implementations or deployments so far the benefit of anyone else that wants to play it wouldn't hurt to provide an informational document. Curtis From rtg-dir-bounces@ietf.org Thu Jun 23 13:01:06 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04675 for ; Thu, 23 Jun 2005 13:01:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlVT0-0006Xh-Dy for rtg-dir-archive@ietf.org; Thu, 23 Jun 2005 13:26:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlV3R-0006qm-EA; Thu, 23 Jun 2005 12:59:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlV3P-0006os-1Q for rtg-dir@megatron.ietf.org; Thu, 23 Jun 2005 12:59:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04488 for ; Thu, 23 Jun 2005 12:59:48 -0400 (EDT) Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DlVRl-0006Qi-HZ for rtg-dir@ietf.org; Thu, 23 Jun 2005 13:25:01 -0400 Received: (qmail 39141 invoked from network); 23 Jun 2005 16:59:49 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 23 Jun 2005 16:59:49 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j5NGxHbG046390; Thu, 23 Jun 2005 12:59:17 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200506231659.j5NGxHbG046390@workhorse.faster-light.net> To: Tony Li In-reply-to: Your message of "Thu, 23 Jun 2005 08:48:40 PDT." <42BAD9D8.90903@tony.li> Date: Thu, 23 Jun 2005 12:59:17 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rtg-dir@ietf.org, Scott Bradner , routing-discussion@ietf.org, iesg@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 In message <42BAD9D8.90903@tony.li> Tony Li writes: > > > Scott, > > > 2/ they did not want the IETF to make a standard that > > defined or assumed jumbo frames on Ethernet > > My understanding further extended that prohibition to any informational > or experimental RFC as well. Those would have been (and still would be) > the best possible outcomes. There was no requirement to make IS-IS over > jumbo frames into a standard. > > Tony I think we should have just defied that and written and informational document. Its kind of silly for the IETF to expect vendors to keep implementing toward expired internet-drafts long after a defacto standard exists as is done all too often. Lets face it. Jumbo ethernet frames have been around and have been widely implemented for about 10 years now. Curtis From rtg-dir-bounces@ietf.org Fri Jun 24 12:31:27 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22725 for ; Fri, 24 Jun 2005 12:31:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlrU4-0000Jm-PV for rtg-dir-archive@ietf.org; Fri, 24 Jun 2005 12:56:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlr52-0003Fp-MU; Fri, 24 Jun 2005 12:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlr51-0003Fh-Kt for rtg-dir@megatron.ietf.org; Fri, 24 Jun 2005 12:30:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22680 for ; Fri, 24 Jun 2005 12:30:57 -0400 (EDT) Received: from [61.149.197.131] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DlrTT-0000Hr-A2 for rtg-dir@ietf.org; Fri, 24 Jun 2005 12:56:23 -0400 Received: from GiC@localhost by R1cB.int (8.11.6/8.11.6); Fri, 24 Jun 2005 21:54:10 +0400 Message-ID: From: "Martha Reiser" To: rtg-dir@ietf.org Date: Fri, 24 Jun 2005 19:55:10 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: EricaBlanton@cottus.com Content-Type: multipart/mixed; boundary="--t8VHG9SeMgYR9g3" X-Spam-Score: 4.8 (++++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: agentx-web-archive@ietf.org, dcom@ietf.org, aids@ietf.org Subject: Over 80% Savings on ALL best-selling Microsoft titles X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martha Reiser List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.8 (++++) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 LV0 ----t8VHG9SeMgYR9g3 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 6
    Opt-in Email Special Offer &n= bsp;   unsubscribe me
    SEARCH

    <= tr vAlign=3Dtop bgColor=3D#333399>

    TOP 10 NEW TITLES

    <= /td>
    5

     = ON SALE NOW!

     1 O= ffice Pro 2003
     2 Window= s XP Pro
     3 Adobe Cre= ative Suite Premium
     4 Norton Antivirus 2005
      Flash MX 2004
     6 Corel Draw 12
     7 Adobe = Acrobat 7.0
     8 Window= s 2003 Server
     9 Alias = Maya 6 Wavefrt
     10 Adobe = Premiere
      See more= by this manufacturer
     <= /td>  Microsoft<= /td>
       Apple Software
      Customers also bought
       <= font face=3Dverdana,arial,helvetica size=3D1> these other items...
    <= /td>



    Microsoft Offi= ce Professional Edition *2003*
    Microsoft
    Choose= :
    &= nbsp;
    =
    List Price:$899.00
    Price:$69.99<= /b>
    You Save:$830.01 (92= %)



    Availability:= Available for INSTANT download!
    Coupon Code: ISe229
    Med= ia: CD-ROM / Download

    System requirements  |  Accessories  |  Other Versions

    Features:

    • Analyze= and manage business information using Access databases
    • Exchange data with other systems using enhance= d XML technology
    • Control inf= ormation sharing rules with enhanced IRM technology
    • Easy-to-use wizards to create e-mail newsletters a= nd printed marketing materials
    • More than 20 preformatted business reports
    Sales Rank: #1
    Shipping: Int= ernational/US or via instant download
    Date Coupon Expires: June= 30th, 2005
    Average Customer Review: = 3D"5 Based on 1,768 reviews. Write a= review.
    Microsoft Windows XP Professional or = Longhorn Edition
    Microsoft =
    Choose:
    <= /td> <= /a>

    List Price:$279.00
    Price:$49.99
    You Save:<= /td>$229.01 (= 85%)



    Availability:= Available for INSTANT download!
    Coupon Code: ISe229
    Med= ia: CD-ROM / Download

    System requirements  |  Accessories  |  Other Versions

    Features:

    • Desi= gned for businesses of all sizes
    • Manage digital pictures, music, video, DVDs, and more
      • More security with the ability to encrypt f= iles and folders
    • Built-in vo= ice, video, and instant messaging support
    • <= font size=3D1>Integration with Windows servers and management solutions

    Sales Rank: #2
    Shipping: International/US or via instant download
    Date Co= upon Expires: June 30th, 2005
    Average= Customer Review: 3D"5 Based on 868 reviews. Write a review.

    Adobe Photoshop CS2 V 9= 0
    Adobe=
    Choose:=
     

    List Price:<= /td> $599.00
    Price:$69.99
    You Save:$529.01 (90%)



    = Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requirements  |&nb= sp; Accessories  |  Other Versions

    Features:

    • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
    • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
    • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
    • Support f= or 16-bit images, digital camera raw data, and non-square pixels
    • Create or modify photos using paintin= g, drawing, and retouching tools

    Sales Rank: #3
    Shipping: International= /US or via instant download
    Date Coupon Expires: June 30th, 200= 5
    Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.=

    ----t8VHG9SeMgYR9g3-- From rtg-dir-bounces@ietf.org Fri Jun 24 13:13:11 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25909 for ; Fri, 24 Jun 2005 13:13:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dls8U-00028D-30 for rtg-dir-archive@ietf.org; Fri, 24 Jun 2005 13:38:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlrjn-0002V5-Dt; Fri, 24 Jun 2005 13:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlrjm-0002RS-Fr; Fri, 24 Jun 2005 13:13:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25858; Fri, 24 Jun 2005 13:12:39 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dls7w-0001yr-J8; Fri, 24 Jun 2005 13:38:05 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DlrjE-0007x8-LR; Fri, 24 Jun 2005 17:12:32 +0000 Date: Fri, 24 Jun 2005 10:12:26 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1993574863.20050624101226@psg.com> To: iesg@ietf.org, rtg-chairs@ietf.org, rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: On vacation till end of next week X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit FYI, I'm going on vacation today, back after the Independence day. I'll probably have connectivity, but will pretend I don't. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Fri Jun 24 18:53:09 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04258 for ; Fri, 24 Jun 2005 18:53:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlxRW-0008VV-Gn for rtg-dir-archive@ietf.org; Fri, 24 Jun 2005 19:18:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlx1X-0006j1-V6; Fri, 24 Jun 2005 18:51:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlx1V-0006f4-AI; Fri, 24 Jun 2005 18:51:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04062; Fri, 24 Jun 2005 18:51:42 -0400 (EDT) Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlxQ6-0008SM-LJ; Fri, 24 Jun 2005 19:17:12 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j5OMpXrU127722; Fri, 24 Jun 2005 22:51:33 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5OMpXto255000; Fri, 24 Jun 2005 23:51:33 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j5OMpWt4008709; Fri, 24 Jun 2005 23:51:33 +0100 Received: from mail-gw3.hursley.ibm.com (mail-gw3.hursley.ibm.com [9.20.131.251]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j5OMpWXl008701; Fri, 24 Jun 2005 23:51:32 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw3.hursley.ibm.com with esmtp (Exim 4.50) id 1Dlx1I-0000rM-KJ; Fri, 24 Jun 2005 23:51:32 +0100 Received: from zurich.ibm.com (sig-9-145-132-60.de.ibm.com [9.145.132.60]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id j5OMpVo93706; Fri, 24 Jun 2005 23:51:31 +0100 Message-ID: <42BC6EFE.5040407@zurich.ibm.com> Date: Fri, 24 Jun 2005 22:37:18 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Tony Li References: <20050623155304.A21C13E8933@newdev.harvard.edu> <42BADDB9.9040406@tony.li> In-Reply-To: <42BADDB9.9040406@tony.li> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Scott Bradner , routing-discussion@ietf.org, iesg@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Tony Li wrote: >>>My understanding further extended that prohibition to any informational >>>or experimental RFC as well. >> >>that was the case to start with, but as someone else pointed out, >>a few years later the IEEE said that they would accept an info RFC >>(thought they were not all that happy) > > > > First I hear of it. In any case, I would very much like to progress the > work. Given the non-standard status of jumbo frames, I have no problem > moving forward with informational or experimental as the goal. This sounds like information to me, not like an experiment. So I'd support the idea of aiming at an Informational RFC. (Peanut gallery question - any other Informationals needed for jumbo frames, or is IS-IS the only one that needs documenting?) Brian From rtg-dir-bounces@ietf.org Fri Jun 24 20:00:17 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10626 for ; Fri, 24 Jun 2005 20:00:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlyUS-0002HE-Rp for rtg-dir-archive@ietf.org; Fri, 24 Jun 2005 20:25:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlxyw-000680-KJ; Fri, 24 Jun 2005 19:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlxyu-00067m-EO; Fri, 24 Jun 2005 19:53:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09628; Fri, 24 Jun 2005 19:53:05 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlyNU-0001zK-7m; Fri, 24 Jun 2005 20:18:33 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Jun 2005 16:52:42 -0700 X-IronPort-AV: i="3.93,229,1115017200"; d="scan'208"; a="194169663:sNHT26480122" Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j5ONqd6p008688; Fri, 24 Jun 2005 16:52:39 -0700 (PDT) Received: from [10.21.83.109] (sjc-vpn4-878.cisco.com [10.21.83.109]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id QAA09365; Fri, 24 Jun 2005 16:52:39 -0700 Message-ID: <42BC9CC6.4000109@tony.li> Date: Fri, 24 Jun 2005 16:52:38 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter References: <20050623155304.A21C13E8933@newdev.harvard.edu> <42BADDB9.9040406@tony.li> <42BC6EFE.5040407@zurich.ibm.com> In-Reply-To: <42BC6EFE.5040407@zurich.ibm.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Scott Bradner , routing-discussion@ietf.org, iesg@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit > This sounds like information to me, not like an experiment. So I'd support > the idea of aiming at an Informational RFC. Thanks Brian. > (Peanut gallery question - any other Informationals needed for jumbo > frames, > or is IS-IS the only one that needs documenting?) I'm not aware of other significant protocols that are not using an Ethertype encapsulation at this point, so no. Tony From rtg-dir-bounces@ietf.org Sat Jun 25 08:18:47 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21869 for ; Sat, 25 Jun 2005 08:18:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmA1G-0004EU-Eh for rtg-dir-archive@ietf.org; Sat, 25 Jun 2005 08:44:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm9ai-0005nc-Go; Sat, 25 Jun 2005 08:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm9ag-0005nX-Br for rtg-dir@megatron.ietf.org; Sat, 25 Jun 2005 08:16:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21792 for ; Sat, 25 Jun 2005 08:16:53 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dm9zK-0004Al-Qm for rtg-dir@ietf.org; Sat, 25 Jun 2005 08:42:28 -0400 Received: from [211.242.215.94] (helo=211.242.215.94) by mx2.foretec.com with smtp (Exim 4.24) id 1Dm9aU-0004Mj-L4 for rtg-dir@ietf.org; Sat, 25 Jun 2005 08:16:43 -0400 Message-ID: <839801c5797e$d86e1e7d$f6a99b91@accessus.net> From: "Richard K. Lee" <61amril@accessus.net> To: rtg-dir@ietf.org Date: Sat, 25 Jun 2005 12:06:37 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_DC2C9F8B.7B4B2341" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: Cialis - 75% OFF X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.9 (+++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_0000_DC2C9F8B.7B4B2341 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_8F40F46E.A0924D0B" ------=_NextPart_001_0001_8F40F46E.A0924D0B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Perfect erection Long duration of effects No prescription asked Only $2.99/$1.99 per dose (2 doses in each pill): CIALIS - http://www.tabletsnow.com/sv/ VIAGRA - http://www.tabletsnow.com/vt/ Directly from the manufacturer! _________________________________________________________________________ To be taken off future campaigns, go here _________________________________________________________________________ ------=_NextPart_001_0001_8F40F46E.A0924D0B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

    Perfect erection
    Long duration of effects
    No prescription asked

    Only $2.99/$1.99 per dose (2 doses in each pill):
    CIALIS - http://www.tabletsnow.com/sv/
    VIAGRA - http://www.tabletsnow.com/vt/

    Directly from the manufacturer!


    _________________________________________________________________________
    To be taken off future campaigns, go here
    _________________________________________________________________________

    ------=_NextPart_001_0001_8F40F46E.A0924D0B-- ------=_NextPart_000_0000_DC2C9F8B.7B4B2341-- From rtg-dir-bounces@ietf.org Sat Jun 25 11:09:34 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09652 for ; Sat, 25 Jun 2005 11:09:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmCgZ-00009F-3z for rtg-dir-archive@ietf.org; Sat, 25 Jun 2005 11:35:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmCH5-0008SC-V2; Sat, 25 Jun 2005 11:08:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmCH4-0008S7-QX for rtg-dir@megatron.ietf.org; Sat, 25 Jun 2005 11:08:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09524 for ; Sat, 25 Jun 2005 11:08:48 -0400 (EDT) Received: from [218.1.188.88] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DmCfk-00006g-5Y for rtg-dir@ietf.org; Sat, 25 Jun 2005 11:34:26 -0400 Received: from Tno@localhost by CFYN.int (8.11.6/8.11.6); Sat, 25 Jun 2005 17:22:51 +0100 Message-ID: From: "Scottie Dutton" To: rtg-dir@ietf.org, dcom@ietf.org, aids@ietf.org, agentx-web-archive@ietf.org Date: Sat, 25 Jun 2005 22:22:51 +0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: LanceMcelroy@aoll.co.uk Content-Type: multipart/mixed; boundary="--cEaqL7nqCxcbPfbdv9H" X-Spam-Score: 3.5 (+++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Subject: Adobe Products available for Download X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Scottie Dutton List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 BQ2 ----cEaqL7nqCxcbPfbdv9H Content-Type: text/html; Content-Transfer-Encoding: quoted-printable h
    Opt-in Email Special Offer &n= bsp;   unsubscribe me
    SEARCH

    <= tr vAlign=3Dtop bgColor=3D#333399>

    TOP 10 NEW TITLES

    <= /td>
    5

     = ON SALE NOW!

     1 O= ffice Pro 2003
     2 Window= s XP Pro
     3 Adobe Cre= ative Suite Premium
     4 Norton Antivirus 2005
      Flash MX 2004
     6 Corel Draw 12
     7 Adobe = Acrobat 7.0
     8 Window= s 2003 Server
     9 Alias = Maya 6 Wavefrt
     10 Adobe = Premiere
      See more= by this manufacturer
     <= /td>  Microsoft<= /td>
       Apple Software
      Customers also bought
       <= font face=3Dverdana,arial,helvetica size=3D1> these other items...
    <= /td>



    Microsoft Offi= ce Professional Edition *2003*
    Microsoft
    Choose= :
    &= nbsp;
    =
    List Price:$899.00
    Price:$69.99<= /b>
    You Save:$830.01 (92= %)



    Availability:= Available for INSTANT download!
    Coupon Code: ISe229
    Med= ia: CD-ROM / Download

    System requirements  |  Accessories  |  Other Versions

    Features:

    • Analyze= and manage business information using Access databases
    • Exchange data with other systems using enhance= d XML technology
    • Control inf= ormation sharing rules with enhanced IRM technology
    • Easy-to-use wizards to create e-mail newsletters a= nd printed marketing materials
    • More than 20 preformatted business reports
    Sales Rank: #1
    Shipping: Int= ernational/US or via instant download
    Date Coupon Expires: June= 30th, 2005
    Average Customer Review: = 3D"5 Based on 1,768 reviews. Write a= review.
    Microsoft Windows XP Professional or = Longhorn Edition
    Microsoft =
    Choose:
    <= /td> <= /a>

    List Price:$279.00
    Price:$49.99
    You Save:<= /td>$229.01 (= 85%)



    Availability:= Available for INSTANT download!
    Coupon Code: ISe229
    Med= ia: CD-ROM / Download

    System requirements  |  Accessories  |  Other Versions

    Features:

    • Desi= gned for businesses of all sizes
    • Manage digital pictures, music, video, DVDs, and more
      • More security with the ability to encrypt f= iles and folders
    • Built-in vo= ice, video, and instant messaging support
    • <= font size=3D1>Integration with Windows servers and management solutions

    Sales Rank: #2
    Shipping: International/US or via instant download
    Date Co= upon Expires: June 30th, 2005
    Average= Customer Review: 3D"5 Based on 868 reviews. Write a review.

    Adobe Photoshop CS2 V 9= 0
    Adobe=
    Choose:=
     

    List Price:<= /td> $599.00
    Price:$69.99
    You Save:$529.01 (90%)



    = Availability: Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requirements  |&nb= sp; Accessories  |  Other Versions

    Features:

    • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
    • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
    • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
    • Support f= or 16-bit images, digital camera raw data, and non-square pixels
    • Create or modify photos using paintin= g, drawing, and retouching tools

    Sales Rank: #3
    Shipping: International= /US or via instant download
    Date Coupon Expires: June 30th, 200= 5
    Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.=

    ----cEaqL7nqCxcbPfbdv9H-- From rtg-dir-bounces@ietf.org Sun Jun 26 12:33:49 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08472 for ; Sun, 26 Jun 2005 12:02:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmZzw-0005mt-1P for rtg-dir-archive@ietf.org; Sun, 26 Jun 2005 12:28:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZXl-0001gk-Ot; Sun, 26 Jun 2005 11:59:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmZXd-0001eP-N6 for rtg-dir@megatron.ietf.org; Sun, 26 Jun 2005 11:59:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05983 for ; Sun, 26 Jun 2005 11:59:25 -0400 (EDT) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DmZwa-0001NE-3I for rtg-dir@ietf.org; Sun, 26 Jun 2005 12:25:16 -0400 Received: (qmail 18445 invoked from network); 26 Jun 2005 15:59:21 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 26 Jun 2005 15:59:21 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j5QG0iXk006764; Sun, 26 Jun 2005 12:00:44 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200506261600.j5QG0iXk006764@workhorse.faster-light.net> To: Brian E Carpenter In-reply-to: Your message of "Fri, 24 Jun 2005 22:37:18 +0200." <42BC6EFE.5040407@zurich.ibm.com> Date: Sun, 26 Jun 2005 12:00:44 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: rtg-dir@ietf.org, Tony Li , Scott Bradner , routing-discussion@ietf.org, iesg@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 In message <42BC6EFE.5040407@zurich.ibm.com> Brian E Carpenter writes: > > Tony Li wrote: > >>>My understanding further extended that prohibition to any informational > >>>or experimental RFC as well. > >> > >>that was the case to start with, but as someone else pointed out, > >>a few years later the IEEE said that they would accept an info RFC > >>(thought they were not all that happy) > > > > > > > > First I hear of it. In any case, I would very much like to progress the > > work. Given the non-standard status of jumbo frames, I have no problem > > moving forward with informational or experimental as the goal. > > This sounds like information to me, not like an experiment. So I'd support > the idea of aiming at an Informational RFC. > > (Peanut gallery question - any other Informationals needed for jumbo frames, > or is IS-IS the only one that needs documenting?) > > Brian Brian, It probably would not hurt to have an informational draft describing jumbo frames, the reason for needing a them, when to use them and importantly when not to use them. Jumbo frames exists only to avoid the performance drop that would otherwise potentially cripple core networks using GbE or 10GbE and aggregating higher MTU links. Since jumbo frames could otherwise be harmful, it might make sense to ask that equipment be capable of forwarding jumbo frames but originate standard MTU frames (except when verifying MTU such as in ISIS) and that end user devices such as NIC cards never originate jumbo frames. It should also be clearly stated that jumbo frames be disabled by default and any equipment supporting them at the very least put harsh warnings in the equipment's user documentation about the feature being non-standard and has a potential to cause interoperability problem if just casually enabled. The fear of the IEEE folks might be that once word gets out of jumbo frames a lot of people who don't really need them will be asking for them and equipment in bridged environments won't be able to deal with them. In bridged environments fragmenting isn't a possibility and today most equipment doesn't support jumbo frames, mainly just the larger routers and switches sold into the large provider market. (Peanut gallery answer. Now all you need is an author.) Curtis From rtg-dir-bounces@ietf.org Sun Jun 26 13:37:10 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25994 for ; Sun, 26 Jun 2005 13:37:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmbTB-0006fS-Hs for rtg-dir-archive@ietf.org; Sun, 26 Jun 2005 14:03:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmb1x-0004BF-RH; Sun, 26 Jun 2005 13:34:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmb1v-0004Ak-S2; Sun, 26 Jun 2005 13:34:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25793; Sun, 26 Jun 2005 13:34:47 -0400 (EDT) Received: from adsl-65-67-187-82.dsl.rcsntx.swbell.net ([65.67.187.82] helo=defiant.dfw.nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmbQs-0006br-2R; Sun, 26 Jun 2005 14:00:38 -0400 Received: from stephen (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id j5QHYMS16520; Sun, 26 Jun 2005 12:34:22 -0500 Message-ID: <015a01c57a75$4e1e7b70$6801a8c0@stephen> From: "Stephen Sprunk" To: , "Brian E Carpenter" References: <200506261600.j5QG0iXk006764@workhorse.faster-light.net> Date: Sun, 26 Jun 2005 12:10:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1218 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1218 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Scott Bradner , routing-discussion@ietf.org, iesg@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Thus spake "Curtis Villamizar" > It probably would not hurt to have an informational draft describing > jumbo frames, the reason for needing a them, when to use them and > importantly when not to use them. > > Jumbo frames exists only to avoid the performance drop that would > otherwise potentially cripple core networks using GbE or 10GbE > and aggregating higher MTU links. Since jumbo frames could > otherwise be harmful, it might make sense to ask that equipment be > capable of forwarding jumbo frames but originate standard MTU > frames (except when verifying MTU such as in ISIS) and that end > user devices such as NIC cards never originate jumbo frames. That seems excessively restrictive. There are many environments today using jumbo frames (8k-10k MTU) on end hosts without problems. This also begs for a definition of what exactly a "jumbo" frame is; does an MPLS label (or several) on the front of a 1500-byte Ethernet frame count? Does a packet on media with a >1500 byte native MTU count? Should a host on FDDI or a direct HDLC/PPP link be limited to 1500 byte packets -- even though its native MTU is 4470 -- because we fear it might need to talk to an Ethernet-connected host? > It should also be clearly stated that jumbo frames be disabled by > default and any equipment supporting them at the very least put > harsh warnings in the equipment's user documentation about the > feature being non-standard and has a potential to cause > interoperability problem if just casually enabled. I certainly agree that jumbo frames should be disabled by default, and the warning should explicitly note that severe problems will result if hosts on the same subnet have different ideas of what the MTU is. I personally have never seen a problem with jumbos when every device on a subnet supports them and is configured with the same MTU, but perhaps someone else can offer some enlightening anecdotes. We might consider adding a means for hosts configured with a "jumbo" MTU to determine if all of its neighbors (and intermediate L2 devices) can indeed handle such packets. If such a mechansim existed, we could allow jumbos to be on by default since hosts could detect when it was necessary to fall back to a non-jumbo MTU. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From rtg-dir-bounces@ietf.org Sun Jun 26 14:09:35 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28847 for ; Sun, 26 Jun 2005 14:09:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmbyY-0007O4-Df for rtg-dir-archive@ietf.org; Sun, 26 Jun 2005 14:35:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmbYI-0001TU-PE; Sun, 26 Jun 2005 14:08:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmbYG-0001Sz-6J; Sun, 26 Jun 2005 14:08:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28715; Sun, 26 Jun 2005 14:08:14 -0400 (EDT) Received: from parsley.amaranth.net ([204.10.1.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmbxE-0007M8-J3; Sun, 26 Jun 2005 14:34:05 -0400 Received: from ancho.senie.com (c-24-34-19-2.hsd1.ma.comcast.net [24.34.19.2]) (authenticated bits=0) by parsley.amaranth.net (8.12.11/8.12.11) with ESMTP id j5QI7rY9023067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Jun 2005 14:07:54 -0400 Message-Id: <6.2.3.4.2.20050626135052.07407810@mail.amaranth.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 26 Jun 2005 13:59:37 -0400 To: "Stephen Sprunk" , , "Brian E Carpenter" From: Daniel Senie In-Reply-To: <015a01c57a75$4e1e7b70$6801a8c0@stephen> References: <200506261600.j5QG0iXk006764@workhorse.faster-light.net> <015a01c57a75$4e1e7b70$6801a8c0@stephen> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on parsley.amaranth.net X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: rtg-dir@ietf.org, Scott Bradner , routing-discussion@ietf.org, iesg@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac At 01:10 PM 6/26/2005, Stephen Sprunk wrote: >Thus spake "Curtis Villamizar" > > It probably would not hurt to have an informational draft describing > > jumbo frames, the reason for needing a them, when to use them and > > importantly when not to use them. > > > > Jumbo frames exists only to avoid the performance drop that would > > otherwise potentially cripple core networks using GbE or 10GbE > > and aggregating higher MTU links. Since jumbo frames could > > otherwise be harmful, it might make sense to ask that equipment be > > capable of forwarding jumbo frames but originate standard MTU > > frames (except when verifying MTU such as in ISIS) and that end > > user devices such as NIC cards never originate jumbo frames. > >That seems excessively restrictive. There are many environments today using >jumbo frames (8k-10k MTU) on end hosts without problems. Indeed, it would seem to make sense for communications between front end and back end servers (e.g. app server to database cases). In controlled environments it should help boost database transactions, NFS and whatnot. This was certainly one reason FDDI was used in places in the past, as large frame sizes were permitted on that medium. >This also begs for a definition of what exactly a "jumbo" frame is; does an >MPLS label (or several) on the front of a 1500-byte Ethernet frame count? >Does a packet on media with a >1500 byte native MTU count? Should a host on >FDDI or a direct HDLC/PPP link be limited to 1500 byte packets -- even >though its native MTU is 4470 -- because we fear it might need to talk to an >Ethernet-connected host? > > It should also be clearly stated that jumbo frames be disabled by > > default and any equipment supporting them at the very least put > > harsh warnings in the equipment's user documentation about the > > feature being non-standard and has a potential to cause > > interoperability problem if just casually enabled. > >I certainly agree that jumbo frames should be disabled by default, and the >warning should explicitly note that severe problems will result if hosts on >the same subnet have different ideas of what the MTU is. I personally have >never seen a problem with jumbos when every device on a subnet supports them >and is configured with the same MTU, but perhaps someone else can offer some >enlightening anecdotes. > >We might consider adding a means for hosts configured with a "jumbo" MTU to >determine if all of its neighbors (and intermediate L2 devices) can indeed >handle such packets. If such a mechansim existed, we could allow jumbos to >be on by default since hosts could detect when it was necessary to fall back >to a non-jumbo MTU. Indeed, OSPF has had such a mechanism for years as a result of the existence of LAN media types with disparate MTUs (token ring, FDDI). Routers are permitted to pack LSAs into packets up to MTU size, and if another router on the LAN had a different MTU, significant problems resulted (and those problems could lie dormant in a live network for a long time before things broke, as it turned out). It would certainly be worthwhile to have some means for testing. The trick is when a transport or routing session fails, some generic mechanism is really needed to think to ask the remote end for its MTU. That could be an ICMP message asking for MTU. Keep in mind, however, that a station which can't receive a frame due to MTU mismatch (recipient had MTU 1500, sender something bigger) will not even hear the frame (dropped at MAC level) so it can't respond with an error message. The Ethernet MTU of 1500 allowed this issue to be ignored for a long time. Other media had issues with it, but they were mostly ignored as Ethernet dominated. It'd sure be nice if this were dealt with on a generic basis. Probably could have been piggybacked on ARP responses if there'd been a range of MTUs to worry about when ARP was proposed. Oh well. From rtg-dir-bounces@ietf.org Sun Jun 26 15:44:49 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07858 for ; Sun, 26 Jun 2005 15:44:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmdSk-0001DF-CC for rtg-dir-archive@ietf.org; Sun, 26 Jun 2005 16:10:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmd33-00015F-Fo; Sun, 26 Jun 2005 15:44:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmd32-000154-3s; Sun, 26 Jun 2005 15:44:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07825; Sun, 26 Jun 2005 15:44:05 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmdS1-0001BP-AY; Sun, 26 Jun 2005 16:09:58 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Jun 2005 12:43:51 -0700 Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5QJhlVX012711; Sun, 26 Jun 2005 12:43:47 -0700 (PDT) Received: from [10.21.99.23] (sjc-vpn1-791.cisco.com [10.21.99.23]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id MAA04536; Sun, 26 Jun 2005 12:43:43 -0700 Message-ID: <42BF0568.5090708@tony.li> Date: Sun, 26 Jun 2005 12:43:36 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@faster-light.net References: <200506261600.j5QG0iXk006764@workhorse.faster-light.net> In-Reply-To: <200506261600.j5QG0iXk006764@workhorse.faster-light.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Brian E Carpenter , Scott Bradner , routing-discussion@ietf.org, iesg@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit > Jumbo frames exists only to avoid the performance drop that would > otherwise potentially cripple core networks using GbE or 10GbE and > aggregating higher MTU links. Another, and perhaps more common, reason for jumbo frames is to support high speed data center and storage applications. Many modern systems have an 8KB primary memory page size, and can be most efficient at bulk transfers when they can make use of the page as a transfer unit. Tony From rtg-dir-bounces@ietf.org Mon Jun 27 09:23:17 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19519 for ; Mon, 27 Jun 2005 09:23:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmtzC-0003UE-Pn for rtg-dir-archive@ietf.org; Mon, 27 Jun 2005 09:49:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmtYp-0008M1-7i; Mon, 27 Jun 2005 09:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmtYn-0008LY-Ta; Mon, 27 Jun 2005 09:22:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19374; Mon, 27 Jun 2005 09:21:59 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmtxr-0003Ru-0j; Mon, 27 Jun 2005 09:48:01 -0400 Received: from robinson-5-81-56-70-100.fbx.proxad.net ([81.56.70.100]) by mx2.foretec.com with smtp (Exim 4.24) id 1DmtYY-0004m8-Kk; Mon, 27 Jun 2005 09:21:47 -0400 Received: from mail by complementation.quotedb.com with local (Exim 4.50) id 1YNJGfch-551KK-1W for rtg-dir@ietf.org; Mon, 27 Jun 2005 06:21:42 -0800 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [69.72.26.12] by www.complementation.quotedb.com with http (uid:76732) (RMM 4.0); for ; Mon, 27 Jun 2005 06:21:42 -0800 From: Concetta To: rtg-dir@ietf.org Date: Mon, 27 Jun 2005 06:21:42 -0800 (CEST) X-Sender: 76732 X-Mailer: RMM Message-Id: <1YNJGfch-551KK-1W@complementation.quotedb.com> X-Sender: unknown X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Subject: Be smart.. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable You have not tried Cialls yet? Than you cannot even imagine what it is like to be a real man in bed! The thing is that a great errrect1on is provided for you exactly when you want. CialIs has a Iot of advantaqes over Viagra - the effect lasts 36 hours! - you are ready to start within just 10 minutes! - you can mix it with alcohol! We ship to any country! http://fnlunqnbumqc.com.ldpjpc5mneljmol.singlenl.com Concetta From rtg-dir-bounces@ietf.org Mon Jun 27 14:41:41 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22900 for ; Mon, 27 Jun 2005 14:41:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmyxN-0002WJ-E1 for rtg-dir-archive@ietf.org; Mon, 27 Jun 2005 15:07:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmyXq-0000pP-KP; Mon, 27 Jun 2005 14:41:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmyXp-0000pG-Lk for rtg-dir@megatron.ietf.org; Mon, 27 Jun 2005 14:41:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22890 for ; Mon, 27 Jun 2005 14:41:19 -0400 (EDT) Received: from host86-133-146-247.range86-133.btcentralplus.com ([86.133.146.247]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dmyx0-0002Vd-OY for rtg-dir@ietf.org; Mon, 27 Jun 2005 15:07:24 -0400 Message-ID: From: "Vanessa J. Smith" <60cesar@absolutemotion.com> To: rtg-dir@ietf.org Date: Mon, 27 Jun 2005 18:23:49 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_C49FF96E.2A50F9A3" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.5 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: Macromedia Studio MX 2004 - very low price X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is a multi-part message in MIME format. ------=_NextPart_000_0000_C49FF96E.2A50F9A3 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_631BBB90.61A41B3C" ------=_NextPart_001_0001_631BBB90.61A41B3C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Access all the popular software imaginable for bottom prices! We sell software 2-6 times cheaper than retail price. Just a few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... Go visit us at: http://www.softdisks-inc.com Regards, Vanessa Smith _____________________________________________________ To be taken off future campaigns, go here: http://www.softdisks-inc.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_631BBB90.61A41B3C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
    Access all the popular software imaginable for bottom prices!
    We sell software 2-6 times cheaper than retail price.

    Just a few examples:
    $79.95 Windows XP Professional (Including: Service Pack 2)
    $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
    $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
    $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
    $79.95 Adobe Acrobat 6.0 Professional
    $69.95 MS Project 2003 Professional

    Special Offers:
    $89.95 Windows XP Professional + Office XP Professional
    $149.95 Adobe Creative Suite Premium (5 CD)
    $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

    All main products from Microsoft, Adobe, Macromedia, Corel, etc.
    And many more... Go visit us at:

    http://www.softdisks-inc.com

    Regards,
    Vanessa Smith


    _____________________________________________________
    To be taken off future campaigns, go here: http://www.softdisks-inc.com/uns.htm
    _____________________________________________________

    ------=_NextPart_001_0001_631BBB90.61A41B3C-- ------=_NextPart_000_0000_C49FF96E.2A50F9A3-- From rtg-dir-bounces@ietf.org Tue Jun 28 07:50:41 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26718 for ; Tue, 28 Jun 2005 07:50:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnF1K-0000j6-JV for rtg-dir-archive@ietf.org; Tue, 28 Jun 2005 08:16:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEXg-00078R-Th; Tue, 28 Jun 2005 07:46:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEXf-00077z-EX; Tue, 28 Jun 2005 07:46:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26306; Tue, 28 Jun 2005 07:46:13 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnEwu-0000Ln-Gs; Tue, 28 Jun 2005 08:12:26 -0400 Received: from [221.145.65.14] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DnEXV-0004Mo-7E; Tue, 28 Jun 2005 07:46:05 -0400 Received: from ny-tupperlake8b-345.albyny.adelphia.net (pD115D2D1.dip.t-dialin.net [112.210.194.58]) by maurice.beonex.com with ESMTP id 288B9C0449B for ; Tue, 28 Jun 2005 16:42:59 +0400 Message-Id: <7074291120.0729079@bcc3.kofak.com> Date: Tue, 28 Jun 2005 07:43:59 -0500 From: "Lindsey Gray" To: rtg-dir@ietf.org, policy-admin@ietf.org, imrg-admin@ietf.org, p2prg-web-archive@ietf.org, mmusic-admin@ietf.org X-Spam-Score: 4.4 (++++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: Your site needs a Mass Marketing Program - Exposure ...-u 78 on X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.4 (++++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca We just setup an incredible deal for you to put your website promotion on autopilot. Here's all the details: http://www.allyourpromoneeds.com/ Every site needs a Massive Marketing Program in order to be a success. The most essential part of any campaign is traffic and sales. It’s easy to get exposure to 100K+ every month. Imagine - your traffic / sales problem solved forever. Spots in this program are limited, so hurry on over: http://www.allyourpromoneeds.com/ -------------------------------------------------------------- To stop *future*mailings*: http://www.allyourpromoneeds.com//opts.html senatorial diabetes adolescent circumlocution agony. sortie revery dispersion plymouth typewritten. yvette amino harrow deviant distortion. harry rectangle squelch irresolution benign. tendon gritty lily card country. numeral audible ear delay weekday. classification teat alexandra airspeed clapboard. design andean anybody oven marquis. violent diurnal moonlight buck ailanthus. cavitate cider arlene placeable slapstick. blythe daunt testicle kendall carlson. actor prospector cutworm freshmen chalice. counterargument blueprint godlike downward hey. carpenter eruption anton authoritative confiscatory. valhalla chinquapin deltoid annum opposition. teal dean motet dramatic horace. From rtg-dir-bounces@ietf.org Tue Jun 28 08:11:57 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29612 for ; Tue, 28 Jun 2005 08:11:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnFLu-0003BQ-20 for rtg-dir-archive@ietf.org; Tue, 28 Jun 2005 08:38:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEvk-0004oq-H0; Tue, 28 Jun 2005 08:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEvj-0004of-46 for rtg-dir@megatron.ietf.org; Tue, 28 Jun 2005 08:11:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29536 for ; Tue, 28 Jun 2005 08:11:05 -0400 (EDT) Message-Id: <200506281211.IAA29536@ietf.org> Received: from xdsl-3668.lodz.dialog.net.pl ([84.40.207.84] helo=kekoldi.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DnFL4-0002ut-Ag for rtg-dir@ietf.org; Tue, 28 Jun 2005 08:37:18 -0400 From: "Drina Cheatham" To: "Sachiko Pitts" Date: Tue, 28 Jun 2005 07:11:08 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C57BDA.77079600" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scan-Module: SMTP[2005.06.27 (2005.06.03)] X-Spam-Score: 1.1 (+) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: you maybe needd it X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C57BDA.77079600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Rivarol's flag.Enheartened by that apparent sympathy and consideration, Mr. = Bloodthe four of them stared together seawards.killed me. But because = my death might cause you pain, because yourhanged him.Calm, Don Miguel! = he was quietly but firmly enjoined. Do notrebels-convict some one = ventured to laugh.deemed it overwhelming, his victory was rendered = barren by threegrey, a faint excitement tinting her fair cheeks and = sparkling inpassage. This fort the Admiral, in those days of waiting, = hadside had at last veered in his own favour.award us more. And things = are as they would have been if M. deIn the cabin he flung into a chair, = and exploded, with a violenceleast of the defiance aroused in him by a = blow which he dared not,wall of the fort through whose crenels were = thrust the black nosesBy his peers? ------=_NextPart_000_0049_01C57BDA.77079600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, Welcome to the Med = beheld zOnline - online pharmaceu mission tical = shop.
     
    V successful = A selfexpression = UM V setting I R reclaim = A  sadism CI I hardbitten = S
    L laughter I decimally AG realgar AL  and many other.
     
    With benefaction = our shop you get -
     
    BEST PRlC eolation = ES
    Excellent = selfpropelling service
    Fast shi bindweed = pping
    Private online ord = indecipherable ering
     
    Have a nice day.
    ------=_NextPart_000_0049_01C57BDA.77079600-- From rtg-dir-bounces@ietf.org Wed Jun 29 09:02:32 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15782 for ; Wed, 29 Jun 2005 09:02:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnccc-0005SH-7N for rtg-dir-archive@ietf.org; Wed, 29 Jun 2005 09:28:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DncCr-000653-4A; Wed, 29 Jun 2005 09:02:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DncCk-000643-81; Wed, 29 Jun 2005 09:02:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15749; Wed, 29 Jun 2005 09:02:13 -0400 (EDT) Message-Id: <200506291302.JAA15749@ietf.org> Received: from pool-70-110-248-203.phil.east.verizon.net ([70.110.248.203]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DnccD-0005QQ-0n; Wed, 29 Jun 2005 09:28:39 -0400 FCC: mailbox://vzpnzojz@hotmail.com/Sent X-Identity-Key: id1 Date: Wed, 29 Jun 2005 19:55:33 +0600 From: Tyree Hinson X-Accept-Language: en-us, en MIME-Version: 1.0 To: rtg-dir@ietf.org Content-Type: multipart/related; boundary="------------030302090109070502000002" X-Spam-Score: 2.5 (++) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Subject: re [23] X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.3 (+++) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 This is a multi-part message in MIME format. --------------030302090109070502000002 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

    in 2009 cat in 1928 Harley Davidson

    Graduation The NFL

    --------------030302090109070502000002 Content-Type: image/gif; name="runt.GIF" Content-ID: Content-Disposition: inline; filename="runt.GIF" Content-Transfer-Encoding: base64 R0lGODlhnQJSAfTUAAYGAICAgMDAwP8AAAAA/////wAzADMAADMzADMzMzMzZjNmMzNmZmYzZmZmM2ZmZpmZmcyZmczMzMz/zMz////MzP//zAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAQAAAAALAAA AACNAkoBAAX/YCGOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqFQIqFqv2Kx2y+16 v+CweEwum8/otHrNbrvf8Lh8Tq/bxyfAdM/v+/+AgYKDhDx6JoeFiouMjY6PkJFQiSSUkpeYmZqbnJ1M liKgnqOkpaanqIuioqmtrq+wsbIuq7O2t7i5upK1u76/wMHCVHnDxsfIycm9ys3Oz9ClzNHU1dbXf9PY 29zd3j7a3+Lj5OWVxebp6uvV4ezv8PG47vL19vee9Pj7/P2F+v4CChzYBCDBgwgTGkKnsKHDPwMGXDP4 qUseViOqZMQYSmMKjx9BltAScgVIMDRI/1biaEWFx5YlVUScSZPmipoRU9i8ibOnRBE7SQRFEYZoFqNe Zqi8yJKSSKMmn6LAqbNm1aElrF6iuOQLIo4FRErdCDYsRpgjLX6NSjYpDLdmXY7d2LEpT59YR+DNaSJv 371BtQL1u9JrWi5fDdNSe1juyhZzzZYt4PNvT8tUs17mxXDPXLQd2T6+uBhqYktX1joOHXJyXdRoP+uR 3TbmVcA/heLGzAL3TN18Bwe3vfhp6tFIi8OWepw0XcisIgPfLLyy3r3TM0PiqiQyaOlxkRcunbh8cvHO w7eGfvZl9Nnva5u+vfu6b83Dp/rOXb0/C/CNncfaelG1t1x76BFHVv9vv+UU2G/V5fYghJRRSNg/nU0h nVhgMQcKgAl62CGHoqmnIFMFmvgYbaGxeNsJgmkXIX8X2scfg3zV+Bx7KQ54YoAEthjfjv99OBmEOSaZ 305YMUmhcJFwl8SGTo1oXl1vcWgkdAmmReR8P6411kmrJOJeevrlZ+OaMA6lY4Vq3iVYiUVy6SOYaBJ3 pmp3ylXlkUm2uSSST8L5U5OFqpKhFFR22SVMoBWHJZB+fskngOBFmpyHlpKoYp/43cjmnKFKmChvMFhX J49FHoJpU5PF5mqZjp6naZqDpXrqdP6x6YiUSHjnaZh7ylBsrZdaCep4q3HJaZ/DPvsiZofu6uv/m29S K2qYfK6aaaPkqSftp6KBOOO2006LaJwYIuKHbLDROZq5qo3pmrjKkrugvI4ZF694wy5rI2C+pmkqu9nh la6dq9pJZb4NB2wivaxRTJ2cGPeqMSPAHqGYpV4idS9TQzL8bVuMNVvnd/9O6qO/chK8MaqG4iizoOiK vAWyIRfFr20SS8zeyOfmHKFMblqYbTaLRoESz8JSfBqezZ782s7heltlyHfCDHLCqtaMdHDY3oczwqdh LXC9cP08n9cvEy2Z3IZeSGqppV7McdOTGAi1XTcI+wKZJYqY5eCz7osc3HHHLGPBOEN+tsLaGs21284Z nnXhLU9Mt9R5b3t3/3aTj97uSO/C+vXq+h5ONdD52uu6w2bS2vWWa4t9NK9jH2y57i6ErfLwq8m+edW4 e64U3dcBv7vBOVu19Lt8P2F162uD3i2lQV7vYqusQmr7uM+Bt+5wptctOc0tOIk268z2+H2l4IN6rPba Nw8n3vTp+n4gHTOC9yC2veURD00DFFDDVKaRW7WEfBUDS17OJ7qk/W96YssWvUBEOBQxjIHj25qxiEYo KA2sd7/DT5Sq54QB+o1biKNfkCTTvRfWb4YNRBAEhZQx0g3sRjIq2/8K9qYNfqt2M0zilfSVQ569rncV MuHMQrUwDPYhgEV4WK2uV4MjKlFwrDOiDXkIlf8dvqaHPiya3vajxiA+qYgju5XLsGcuOdJwiywzYAwa JJEJWa5GMbIWIbBIhKgd5kCYi2GBEDm1wogQhoeMZCNJlidHopF3P9Rb3Si3H9+xr5KLlCT86hip5qzO lPiTG3YyGchVbtKKV2RhQT6GsqMk8ngkW0rabDlKMaqNe0sMo/l2RaqbgW0znXzeCSGZS1720jVtE+af EPNEx6GvPmZ7ZZwgmL8dEHII0dwlNJnnxFrGypnww14zVSdDZNlxiso8F304yUbnrS+dOpsfKFtjysst kZblnFzoMpPNeIYoeZ+Q5UMWylAjDNEY32yoRCc6g4cOI6IUzahGzYHRjXr/9KPY6ChIR0pSZYi0pChN qS9OqtKWuhQWLH2pTGc6ipjS9KY4XaG7csrTnrrCpj4NqlA1pNCSvvOotUvZLR2Izr8BwW5KI5sx/fTL qzHmafksiy6BiR7G5Y4bQFUIUgE3N2p+EJjhVGc3Y3a2a9VnkVUVgzm3alUsZLWfc9yeV9UJ1qKOtIki gx0/cfmpfuKViz3wiwV950piCe2Aisvr3CZ5RlHqtXNf3UZYEQJYSr6NgD8qpSGd+tRTLZaVmvRn/Cjm Rcl+yY6iBeNrEVqOzRLkgbRx0auO568RPbKaOFDsG6MqqvRlD4mKRB7nfLuikt2ugOOw7UA6yLb07JZV /3nl4G/3qYPzUXGKOgIXX51I3c9+8FizVe1amyFdgZR3XrYbLylntRzsIjaxhfIueAVJR+QSdnHztW/i Lqtecjqjvf6QVXylpV1FmtG6oOWBft2qJuP2F5/PjB9kIdwpzD7YGwjux16VB+CzFo+2yt1wdwdVXOJO FbouYy075wpcrgXNwyiOrl89OuIb41PGxjNZhCVMXJrVE7Is+5jPDolOIxLJq3tdr0l3rNEgp3dHDUac lTl3y+AW+bvatHBd7erIlAF0nf6NWOegnGNxhHgfW1ZRtM4ZA30KVsU58KORGwtXMquWeO8MbGYHxDg2 w/gbb8ZHOBmcZmb+ebyEHv/ymOmqQiliEpYBhbT9mCe+5DLanx/uRqLtgdVNR9rEbgt0jCVdVqXyRrhS tSh3D73PUIdH1XckF3qjbGD2UpmisjU1vhb43yznTso2s6fuMI1hTTNxxDamM8h2jVlnt+PXEoXtY+Py 3llXM9BJVuIP+IguPXfxXjLGoQt7tKzOPvfRiMZ2Q7kYtUbTGobabrO1a0Bug93zv/eGt5yDnetg1rsh o5YHvQ1kb/nU2beMtOxki5DaZfO3y81Wa32DOXGHnxLXipa3m1FMSiHLsNQPb1VVy9xUIaTP3ClB95Jb O1c5plWLXdU3iEWOaJKP0+Q1NGvMlYNrSg/h5V8eOtH/r6rVMvmZn9pu58ADrlmeD/XqWGeU1bPO9a4H a+teD7vYwQH2sZv97CkpO9rXznaXqL3tcI97wuNO96DOve54x+nd8873l+6974BH6d8DT/iPDr7wiAf2 2xPPeL8vvvGQF/zjI095w0++8phX/E4zz3mfHr7zoFf45UNP+tuOvvSoF/HpU896Uq++9bB/x+djT/tr b772uF/o7HPPe2TsvvfAD8bvg098XQy/+Mifxdy11NxWp4abulx5wQtLX7zG7bdJjj4qcSf0p8/uyaIt 4C85Rb5nIYb507a+9cua82rrrOZ/YvnzEer9F8TJQdUyrp+Vmv2jjOvpyNY0vbY8/0nVfBYBfUshdNnl NQqYa3kUWWqhNuYngS13Q3dEgeKHgV4Sbhp2azujYAcFgNrHS70lcOY0afEHf9R3gjJwf32Uf6ajEvyn JSTBaPs3gETxep+FXIZWYNFGKe62fe8WbWnmbh3GLBOoJ6lUYljmcz/YM9vVcR4IO/aGfiR2fY2zbQDT Y/CRJ0kYWfYHRNWSK/bRLeFHGlv2hZMSgLeXEV2ROHvSgwf1hFvoOZ4CfWREImn4IUfYOtCmNX2Ih0zI hPZyhwjCbQOWc9CSiG6YhVFIYI/ShZAIXyaoH5pBhoMyie0miaDGff/ChqjThgIEhwMmh33YhEDIiYhY Pk64iv/Ks4eAxogSp3Tdhl4rOIioqGucaIusOIWzeIvi5YpftX6mBotQiGxSpT/XJCrE+Gy66INSmHFv oYNl1IXv1Vt0NX7amItxmGNNFIRV6H4q6Hxk0oxDM4e3KH9RSIOm0Y0JaI2qyHLoKF7UpV3qlzzlh4/1 pyv6E0XalE+gVIvVVo4PSHaiOIqreI0H0lRmlY3+1Y2LiIbwiItDiGbusVX7+H3A6HPvqIlQGEEd+Y2w IpDHlYuaVn+f1omXBXJt0o9KEl6HtWC0lY+yAgR7J5LDpojQuC/lyGT1KIk7hJM0qCl/uJFa5pM2N5Cy mI5rOJOH6IqNgpP1o4YQdoMjpJT/KKmUCkSOooB/ukGGD+d+DrmTAQKK53CQo5hUjcZrGYiFk3Z9Swkv DqeAURaIT3k7RseWTBmRexlsx0Fz9/iRgnmWHiiDTaeS6ohj1dV+LeeVyphCpviWOkmJlGmQofiGBXhl p2iXdBhBljR1AlKQFemWVAkkLFlJc5aC82iFAsOOGpeZV1KT4IeEssiLphmZbJaCIMhvmeiP7HaGk4mX tAmbQfB3uzmaCEiCG8eAyyl9q7ZdvKacbPOOGZlcNHadSDmURHmXF6iNxImU6hienglfLTeWwUl9zmR0 YSiGYNlnraiZ2Ol80jg41BiaPoaO4rmITLWR1fmc6ecoIjid/+lpjqgWjVZ1V7vEXRM4gmDIZJ6VNs0n JnkZmP+ZfjF5mrjylb6pcvElbJt2oVoYOPWZfCQqfCNaoihqfCeaoiyqfCvaojD6Uy8aozRqCsdXozj6 CDeaozyqCDvao0AKQDMapETaCD9apEjqNEOapEwKCEfapFD6dWgZpVSKCk9apVj6A1eapVyqA1vapWDa RUsapmRqk2NapmjqTWeapmxqA1/apnBKmHIap3TqpGtap3j6EXeap3w6p6HQp4CqpFMaqIRaSHtaqHX6 pojKpYq6qFjaqI5KpZAaqVA6qZTKpJZ6qUiaqZpKpJwaBQIAAaI6qqMqAQ9QBgEQqqQ6qv+p2qkq9alQ sKoCoKoCIAEJAAC3iqsJgAC8igAJcKu5iqsBIAEQMKu0KqoC4KopBatPoKqriqwP8ADPOq2sGgDUOqrK KnmDeg3Iaqze+q3GSqwFIAHfOqrJagOUI1CWgUIEVWHsUkx+hEzumkLZOo3begzkKgH6uq8SYAHjqq8W wK8C+6/6WgAPUKsocK68KTxhJoZGIzOJQkyt5GLtymL1uhD3Cgz6mqxekABXuQUPcAPG9Fb7M0+tBBzz 9EOo9ZKVdrE5wKxJEAC/KqwBYK01W7OiWrMy8KsQcLM327MP8KsPEAAVZbFENFwPe0FKMja+iX8Hg0Io 67Ive6j/kAD/Q/urWJu1WBuyMZC10fq1DhC0MwsARLtHRmtPE8K0d2Fp65qMUcWuZaiyUksLVDsINVuw yFqs3aqqXAsDBxuq5Rqq5CqqfbueLSuxT3sV7WNhfNQ8b6u4scZKcwsZdSsIHisBIpCsAGsBATsBmFsA ZQsDECACnBuw/Yq5CJu5n7ueqoK4cQs9oyNE+9NvbVSGhJJ/UTu5epqxuiAARIu34zoBE+Cvn9uvo0u6 LjC6/loApcu5/0oCoRs86Vqy68q2A+WCSvuC2ku9rlRCJXtxunuZfjoMCcCvBQAB5PqtgxuqnhuwpOu8 IrCvy5uqxQqugLuxBmu2j0O9h4s2fAZP/1HrmBSbtrP7krI2tzArQAQrAdZKraFKtKYrsBJcsPTrrLKa vga7uoubuK/bv0mbQvtbaQIcuYqbKwNMr1KbwEQQACG7sQw8rQ08tOlLquVqrqb6s8+aqvzas/5ztPPK wYKCI9YbwO7TwdW7SdoSvrsrvhCFvuY6tD4LtkMrq7U6sP86q9EqtFBcs9GKvvsqAB5ruEZ8WkbcsiUs SLe7tEPcwUiHwherwuBUvwhLvzl7swWbvrPqwFVcsOP6wDj7wOg7q/06Mvm1jNPbvYhMIwiTxrjbRo28 O0irxDnIu7cQtOPqvud7wX0MrsiaADLrAPlqvqk7uKTKrwJgAQigsP9CnLu1e0yxZh0R+64kzL2rVMiv zGyuCsfFibkCa65VvMB4TKueHK3pu68iYLUHOwLGysOci7ksLMasPCOlc8K3e8Qe/LoQO68JI8lLPL6/ AAGXi8fSWgCCHL9fLLiAO6vIvADFzMcJAAEAIK3lS876Oqy/bAE4yM3koMtaWqt+bK3RqrC83MvFaqre 2q3mG789C87HCwEBjaxhoc+cVbl8YKvn+7WhOs4F4MmJoK8F7bvjWr81W6vLO9AlIACHEMZBa7M3LNGm R8myEMOiarAA8LngDMaji7ChSs5Z/Ku+irW+Kq3LKwKnOqxETbZEC85dDMYuPV0UvQcJIADJHBb/YYy6 AODQo1u24Iyr0srHJECsYuvJzoy1XhzRl/urDsDUTR0Q/MwDtoq+40q2CzwCxesAv6rKxNqzP4vXAYCr tQrOt9rHgX2+v8rCqrzWIQfTsCDD5FzT5uyvxTquLPzOyszCQzvFDXyzK128t5rVfXuukA0ADvDMiM0P bb0D5XvVhyABnju8kg26lM3Tnmyt6Oyt8kuuX/u5p3q8X23TVx3GpZ3YTOwL4NzYj425D4C54KzVVtut cH28COvFBR2/QXuut6rB5gvPGh3crqfYrnC5h7DHNv2rIqDdeau5xSvdNl3eqSuzyh3PdB3BBosAhcvd 8XDaOeCxju3CFuAA/+TsyeNa2NhKzl/9y4JLAqNLrKgL4OEBsBjsAJZArplr3xz11FCQqlcdusYctGPd wLyMAvTr0SdQsLNK2Jg72BIcFn0r0lZ72BQuahb+BFi70Su90bBN1O/sxFGdAjbs4iMAzuLa31kd3nld v4cgrXqd3Kn74jvn3aggAbgqAqmqswZ71gdr1B5b31+NtdF70qPrsUb9zPDc4TIrqrnawFKNvl0+zdET u/5by9pszdZry7FM54xVsXKepvhtA30dv/pNtExtq9KarERbtms+Ah5b3CgQsjuNuqAbsvBc5VAcsuT9 ziNt18ltTXW+Rm9OTy1WQQ57to2lHaQO52fbpv973kWhW7YM3MKe3LPOPLqQngKqmgKfC9znW+hEe6oh fbO1etUvbOZqrulIe8id3rrLWMLKRM0UK7cNC4NmzKapPgMoXQLWCrrJ2uIfzsD/TU7w3OXKbbBEmwAO 8NGCG7RJXqxRjetBzMpkvMbwHrdobMiK7EkU1rTbG+9zAr5ZOu3Gwts/PtPNreWGXgJbPNNXDu6HTs6y zrFO7KwSgABVkNx6HeVqi82bXsbR3O7z/rSPO0HV7LazrK78G8JR6u8wAOUGH+4yW+IaTM6HHq2pGtBR rdYsIOHZHtd4LKrEWtMOXasMfvFS5Lr6PkQmj/H5/r2yjLsiD8Rty8EMe/L/Mb4ElL26gvzrDp0C187w 95uveuvEOe0C6Uvp5Wuu6OvJViuzVM6uJ9vu/Fs5pgW+Ia/Gby/vTlvAd5621VzyB5yjKE+fCK4HXz7O AF8C81zmPuvH7xzVMhv0th7Z137VzlqrATDa8VzdNuNG5TbycI+9IHz3UPK41dtvtNuwdm9C/N6kf98C a0/UG4vSersC4YzzXm3SqPvytG7R7i3eYUGucr3Bd0P0de/KoP75SV/6RF9CdJ/IoW/AbuypUz8lJ3Dt r/7OU30CYBy0UzzMpnrZw7z4YNH9lE+0AKDOOD3ZAS69Ti/8HQ/82UvLx7/0qP+CQ9/pjnvLqQ+kq78C /7oP0uULApYkJIKUFEUQpK37SOrzCFBtQgGUQ7H7px6snOSkQj0SEGUAITAlWMDfoNqqWq9YIHag9U5T 2/BXnCUXuuDvON1mm8HqeJncVq/ZZzS/7/8DBgoOEhYaHiImHgJMMSo+QhY+QBQooaQIVK6kKGmSJUgE PAmIUkrsPC1RosEU5BQU6RQAkDgkoSAEjBQkZdrtvbkBvwVT7YWNFXN1GQczw9EJZ90dN7vMIVdHbnN3 e3+Dhy82ipc/MvZIwJie7KyGApg+BdC0oAjM5OSv8AONPLUAECVTjSIoolCCYIHFjFFHHvzKI+waHmxx KurBUydaxGMWL1Zck+wZtf+QcoaNzKPMHMuWLl/C5Obox8yYNv2hSMiiiIV8U05BSCIkQSdSBWr0sOEu qYsdtxII8TUiAYAR6qamM3GqxBODl6Y482iyGUaQGida6wi2mEmVZ0pmxBb2bdmbdu/izcuyZkC9dne4 MCpA4AofLWqIwkeUFwCI9fw4DUVUSBJROlbhoFT1n4kJtLryApVNIlqKz8ielVaWrTZoZEezFklX9tjS G1WT9qt7N+/eQPimAO47XLoiMShBsWHYVaagk5yTgsrLD1ISQoJCfUKjCCyrEJX8466kRhApw8+jT69+ PfttwoW3f9SjKz7j9Fa1KKJ9uQobUNXxQUooEKUAlDr/RJlXIIAzWAXQf0GIFp+EE1JYoYU3vXfhIyaM coqDUeEUBj682JDgD+rsIEUOOuiSRFD4uRLKVJwJsBAMVAEQj4Y78tijjz/SRA6QgxRhA1IjWICQYT6Y +AMJDUAkShgxGBWAQDe0sE9+RVICCmdHURWABQW2MqSZZ6KZpk0ZqsmHcaMI4EBXUSynFYxTQEUUgAVQ 8IMsVIHH3wkMujACJQhYYAosszRGFFRJtBmppJNSGgiblRZqnKbzMSFVD18d9kNQ9ETRZA6T9VDgYXmu gF9XLBxETz5UvRkaprfimuuZl+IqwZgTFJCoDk/Q6YJAKco6CYGYHPAcgtJVkIQD//RUENiKUvADownf HSUAAkosUcJSAYCqq7nnoqser7fGQC6kvIwQjz5dvmsPAAlaZwpR2H3rXLlhuiCrTrCQdxBSBzFi3BHp Mtyww3mti2m7j/a0jiWckBghGa2uMkkN4JFAj5O+ZBlUKJTQMOIk/DVGcLvLPhyzzDN3E3GlE5MbxFak XMfLCjBPAZFyCDolRQIMwJefDkLroovK3HE3CwKcHUiz1VdjPYjNlMbg65g/G2QiPjmTMUmBjSlGbhRH iFz2fZgQFAq83XHXsqZkZ5233ntvzbWmY27HxHLXafwCDLrAUu2iJ9BSCYJhVIZ4C0ai3N2is4iLSr17 c955zP99U8rhKfQkJ+iwa6+aEMkVSMA664Adodhy7ZAIhEMQaXrUlSta57nvv6MLuqQi6NcurFI6yaK7 CKbiiw0RVCsB9EWmcF+4MyRh4E+vLk6lQIYuDTQhOSadLvlqnr9e+cbmWA757T8sfKTE47C0JsgX2ioJ n5FCcjrkqs0dk8vHDIY1LNsxhTx+ekCOvHQC/owPfjNLH5ooiB4J8sGC3ngfBhkmv0g16DgoeJuIfoYQ kmHCaY1ywKiWNCqoCFBEcnPaLro0BKKdo4Px0yHwEKFBMvxQJjz0oJB0ZZwx9eSBo3ITGShXmQQoAFyF 6xYKZRgDx+SpBIHS3Z36wEH21eT/i78JYnA6aMH30QSDZCyjDsXIRkYNEY5wDKMa26fBH54PjQGxYx37 KMc37tERZ4RfHiVIRgoi0pB6nGMf6ciIRYIROG5MIxoL6Ui+WDKQF/qgmvQzCQeAyYaSC8QOBrQccplS EB7yxRB0IC5a2EAEQrAUB2eSyEnWkod3JGQuNenLMeKyloEUZiNyaUs/7lKSxhxm+nrJxi+6sZl+ZKQl danIYwqSmNokJjUHGcxJMvOR2+TmMsEZH062SQKNehkAu9iHU9DOH7RoWyCiBhBaKGESn0nI5jLoSEDe 0peHvKZACfpLSgL0n3N8ZjF5iU0wAvKPlMwmNjH50IViVJoU/4VoRjVazF/ykqPeTKhBGVXQiyKUoSK9 JkU3SiF0dhIhkyBXPFbmC8VU0UmuaNKqVpDTppjnOJMbkWF6YQNXLCaCDo1oSpkK0qWelKNNnUUY9DhS YK5UoQHFalSl6tGIfvWqW5UoRKFpTaiSFaV/3OoavWrGaY61rRcs4rmaJh4bdiwTjQvDi8T3AyHIAoih UBHJduIOvZbCKz9FgzM1mkyputWlJIXsQYFp1WlO9auTdSpTNftMMcYVqmItaRALaVJvXlatkHUsaM0Z 2cyidawSgmknu1ZKJMiCQLALw89MxJ+x+bUFUjICybSilX9UBTmdEEQlY0tOzCJUtp4tbf8cmytZsh50 ugQdqFbf2ljSihau4IUPH097ybWWFLYtjSY3m/rYrkpUruehbZpyF51MjKcEgd0YKgODN068Ag1L4AVA UmADGPzDcZmgJy0vmkztkpePaoVwQ6tq0Kuqt7PbHeJoLRphlIZVvCDmsDjN+1TJcjer/oTkiTMc3/Se k67nOi4lcuYiFfhhKKe00g9KleOCYKIH9EiwjkpQCLaS+LprLG920YrdzrY4rWdVcZNNauHuevjKUabw i1XLTEZuOb0TdjJjp+zUDkd5QvStr8JupJmjLjZgPPhrglAU3EJhwgcIptK2EBbnFatUs0guHzgF7Vgt o7elGn6PoR3/esmkpbayiQbrhR0d6PFeuaInVXJ4FTrpLleYs41O82xlfC5NFQFSEJATT22XJz/5ycd9 KKVOTuWuWTDwXknV2ncriloWT9TD32xvJH/N5WBD0piPBuIyRf3cEaO42aGFNIylndpFYtiZn02ypJsN as6yZ81qemJVpDMeVaEhT6ccHASqQh25VWIEQsnBYNQGlVEyd6m/buj6wI3RiT45klzNpKTlCGzrThWr yU6ypwct8FH7+9tUXjh0H2xZantZpWmW73DEfaZMDMod6owBKBT4k+rdImAuKBUEgQAYKQXqASzUoiWc YuRwx7FSbeV4D3s+PlPrigWko4pSEgYe/3SfbSYuWq4U8IGPZdFqCpnhBUSOexyB3ItBDVRfziklV577 POx/8LiZRrQ4FagDHSVPVaiWRQp9RAF7ZmN7JabTFA7dkDwcQuy+XOnK9LhW58BOuNgL//PfOMyBdzvB CEtOpaMYODD5cI4oBusnkl8uKbhzd6Dwq8WxkQAVgAd7mgZPeMOjfuxA11W76WYfEuTES/NhyBScU8AD AiEnx1lw1RvXNRO4YjP32gplUm/846t59brS0aYqv5gTgHxQLS9QQaZ/FAbtYhP1Dg2pgmOlxsyqPsgf P/nnq/xc3fi4zGE8JwxLEFZYnyBwNrKVuANAswmEE4CtSqLK7///6/8F2X2c1h1XomwLAAALAMHCUUHO nvxEOizBAnCCuxUJ9gSFu6GcDtwLAHJgB8KEAJ4JKHhJV/gK5Wyg4/iKVbwIAwod3NBbt8ACuYBcy7je olgJ0PiA9XngDvLgOZxfrrRK5elHc7gCo3TNvmgKUtyQ6lSfccjcKjhAcp3IgsVDq/XgFWIhJICgmTyQ TyXhLlDhJfQEDJnAmHCH+r2JrLASAIASLECKjqgAI5RLFtJhHY4D4sVM5qxMLGCPaKTdzUlGAtiCUlzG iqBKlnxPAUyABVhHATHGVNhhJEqi1vwgECrFilwRPyQGgHwfzIyACRVQgRkYoJzCURwHPZDLBCz/QOOY zSS64itWVSXmSpggSyyIAgqgCE8EhQEQRo1MCal8C+J0zVFMALBkQpKUHFXB4jIy4xaGoKEQolRQEdWM gr1hnaN8C4LAgAiM0AmgEtQ0RoPMITOSYx06Y9kJDSrwwN7BSVfMRwmmwhLoADwViXdsxb3Ajip4iM+U Yz9G4jmayT00Dw/oh5GcwgIIBTyBC7IcGCqE0MlooIElxnzEmz9aZBYC5JAY2ZtghW3hQAHBwDwo4dKc zGApAS2kINQwUIdoRb+hRmroAR98xGgsA22EBEdsRFvY5ExeZE8CnUvqikBqii0Iwe/RW1HGY8jYwniU iDfO43GpDYJpxcIE/4JO1mRr4MZK4CRHWKVtcGVbxIVW+mRPZuSQJIxVyFsNFFAOcog6NiRlKAUp3IeX xGACLMBlWF0l/Nla1IZptEZX8mVNhmVKCKZZWARgjmViKmOQ0ExhhIc6IEUODCJbIoZTGICjuIMQpgAj CgVeziNaAiVN0mRsSMRppIVp3EZhouZWqiZrKuZFlqVGGkpX0MBSwJ1mmuHeveObIMbk2aZBFsk4AoJW bsFc5AZWxkZqnmZOYuVWiuVrkmNsAokDKUdiwAkhlhJaQo3rgeEJNc+rGFftGAJxWsFcEEJyuqZywgUa mCd0jqV0/sgrKIzTtGM1/pQF4Cd+nkjK1CcO5P+OcA7nX87GagqCTu7kYVZDSdRFVpqme1okfP4ILk4O qqHabv1BKBAPhXoI8dTdIazEeuLkgvrlTRomiDIniZZoczroMkKojyDY5ATLZmYo9fjBmCxgCxAPflLJ EQXYeGpDe9qGiA6mgqYGejIoSvDkivpji/aI3HAHO2ioyV2omGjojtqfDvqBMgAmMcAkgZ4oeybogIIp bSipTzJpj3gMEVYpUKjSdlTpfKhlImgpWCqnV6qnmIomgT6ngpYpbMoiusBe3Mmd3C3AvqiSQBBFoTqK XQrqcnlomG6pcebpl6qFa+wpSvTpg/4pujxFqWgiP9xYPSHqoModUXyLIhj/qZca6KR+ZV/SaYriaXpm 6iSeKZAUAaIuqqPsFSCoE/lcJgJkY3IJALCgKqQG5ogmKWsSaZH25ZHGqp3OqivW6pBgz6f+DCXoaJVO gNfAwjUmqgMsJTcAaWuCRB8YKWLixlXWRapGq7Ru6sNMn1GsKYW6wmW2HJa2a75azbQCCSpa6wro178K rMzJJSrKHb7qa8I6DL/+SH/uXcpc4m8uRZysUn26k8Ji7Oe8a8M4bCkpm7KVAI1cZ8aSLM0wrI847BNY QI5kYwIA68sCK1V8S46I7MiW7M0u7Mbi7M7y7F2cbM8CbdCqHh4KbdEa7Zro7NEq7dIeWdIy7dNCLWM5 /23UUm3V/mzVYm27Xm3Wcm2Zbm3Xgi10fm3Ykq2ZTm3Zom3Gjm3asi2Lnm3bwm2mrm3c0i0dzm3d4i0P 3m3e8i0A7m3fAu74/W3gEi7qDW7hIq7PHW7iMq7vLG7jQq7ePG7kUu6+vm3lYu7/TW7mcq75XG7ngq7h fm7okq7ijm7poq7jnm7qsq7krm7rwq7lEm3s0m7qbS5vEEDu6i4BhEHu/oHv9u7uAi8QDO8U6C4aFK/x 8m4LCG/z7m4KOG/zKm/0Cm83JG/wMu/yTu/zEq/2FgD1Vi8gOC8ZXO8PDC/4Hq8gjG/38kH5Qq/0Bi/1 Km/h3a5foC/7+kH53q/5ev8v//Yv/pKv96Iv9w7w9Raw+yJC+gaw9uov+PKvCxzw7zowAGPv+w6w+E5w 9rbv/35vBkPw/n4w/b6umXDvB/cvAj+w//6vAr9v/PYBCndwCEsw8iYvDIMDDBevAetwDnOwBg9CCVvw CvewD8fwAufvDgvwELewCjNxCnfvCStx59QvXrCw/8rwC0PxELNwA0fxEgfwFWPxBiexTeDwGJvwFxPx /KovAldxGafx9IoxGntxBWevFtewHZtx2E2xXVTxE7+xHHdwFCvwDs8wDYPxBofxH7NEH9fxIbvxHFPw EQsyDyMyJKsxIF/yI1twHCtyGtsw34zwj3zy+XbxHI//MgNnMQZXsiVj8iUXcUywMRQ7MR2j8CcfMh2/ Mi13sSbr8irnMiDXch6b7uw6DCP7siFv8hqfsSojMyvjMi7bsjfE8iwHMjM/MydjsybbcBmXsjMTsTFb sTfncjRnzR6TcTdTsxyT8zevMy9HMzffsks0cCRX8xE3sz0X8i8DMDxj8zHvMzqT8j2v89WYMyyjczxn 8kH7MBDjMzADtBK3sUJzwzync/S2MkJfszpPcicnsxiHrysntDXHsjD3XEHDxEDrcy//MO9+tAQXsAmD cASrsAdb7x0L8fbCL0an9EWrtEZfsEuvL0zH9EN3ckSLMDE3DErbckCv9PGCM057/7BMB7L8QrVFh8Md g/QTt3QwB8I7o/Iq/zQhWHUQD7VIgzBHe45Jv4RSdzNTrzEpE7VAx/UyZ/VayzI9LzBJp/M9g/VGW/JT d/UW+/VOJ/RY7/XvqLU8SzRhOzFbJ/FcQzNkczRKkzVNw3FH6/RlMzY5ezVavzJFP8IgD3ZnizNeI3Yo +8gpe7Ynl7JbN3JDR7Y1HzZlT/VZa3Rs9zVf97MRl7ZrZ/Zq+/Y/t3Zw6zbwJLZiY/FXw/Y2Ezdg97Ze 8zQj03YkAK8xU3Ju83R2g7E297BzM7YXu/Nw//Z4uy5SJ3V453M9O7QL+/Msk7Zmr7Y5+O40v/Ztazd8 wzc4i/82b9PwaA+2erN3aR+26pr3eeMxeds0fxM2c/vye2f1dFM3S9txOLsyV7+1gnvzdWe0H+M2Jus3 VustaosyEg94RZM4RgM2eqc3SEM4JLS0iXOwYBd3cmdxjEe0hm84hdP1d594Hd90iBd4MVt2WKe0bW+2 hTv0S/M4Dyu5ODw1Fxv2kReCkft4UD/3cFO1Z0O5lcd3l+fNcZ/zi1e5lY80Q2s5fSf5TzP4mGf5VSO5 Vks3RC82m0uymX/3ndO5aU92Tut5XZ92kNduoP85Ywp6oZe0iBt6oksKmJfDATv6o0N6pEv6pFN6pVv6 pWN6pmv6pnN6p3t6mw+6scjMp5Oceqmb+qmjeqqr+qqzeqtzOYETuqLLennH+qzbuuzW+q3revwg+q77 uoUw+q8Le830+rAbu7oU+7Eru28E+7I7OyUC+rNLO480+7RbOxAl+7Vre0tU+7Z7e7d7u7aDe7hbO6N9 7Lmje7qr+7qze7u7+7vDe7zL+7zTe73b+73je77r+77ze7/7+78D/LyT+8ATfMEb/MEjfMJrewgAACH+ cGhxZ2h1bWVheWxubGZkeGZpcmN2c2N4Z2did2tmbnFkdXh3Zm5mb3p2c3J0a2pwcmVwZ2d4cnBucnZ5 dnRxcml3dXdrcmt0cGl3cG1zaHJ4c2Z3cmJ1dmR1bnZkeHZ5dGZvADt= --------------030302090109070502000002-- From rtg-dir-bounces@ietf.org Sat Jul 2 09:03:32 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13518 for ; Sat, 2 Jul 2005 09:03:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Doi4r-0004LY-0c for rtg-dir-archive@ietf.org; Sat, 02 Jul 2005 09:30:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dohe7-0006eh-82; Sat, 02 Jul 2005 09:02:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dohe0-0006ay-Fs for rtg-dir@megatron.ietf.org; Sat, 02 Jul 2005 09:02:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13423 for ; Sat, 2 Jul 2005 09:02:50 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Doi4A-0004Kg-95 for rtg-dir@ietf.org; Sat, 02 Jul 2005 09:29:55 -0400 Received: from 203-165-60-106.rev.home.ne.jp ([203.165.60.106]) by mx2.foretec.com with smtp (Exim 4.24) id 1Dohdl-000102-33 for rtg-dir@ietf.org; Sat, 02 Jul 2005 09:02:37 -0400 Received: from xtd@localhost by dAE5.int (8.11.6/8.11.6); Sat, 02 Jul 2005 09:03:23 -0500 Message-ID: From: "Debbie Roman" To: rtg-dir@ietf.org Date: Sat, 02 Jul 2005 19:06:23 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: JuliaDuvall@jessicasource.com Content-Type: multipart/mixed; boundary="--RAkLajyt6bxQaPf0h" X-Spam-Score: 1.3 (+) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Subject: 80 % Discount on All Macromedia Titles X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Debbie Roman List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 zlA ----RAkLajyt6bxQaPf0h Content-Type: text/html; Content-Transfer-Encoding: quoted-printable H
    Opt-in Email Special Offer &n= bsp;   unsubscribe me=
    = = List Price:
    SEARCH

    TOP 10 NEW TITLES

    = =

     = ON SALE NOW!

     1 Office Pro 2003
     2 W= indows XP Pro
     3 Adob= e Creative Suite Premium
     4<= a href=3Dhttp://vitriolware.com/?R> Norton Antivirus 2005
     = 5 Flash MX 2004
     6 Corel Draw 12
     7= Adobe Acrobat 7.0
     8 Windows 2003 Server
     = ;9 Alias Maya 6 Wavefrt
    &= nbsp;10 Adobe Premiere
    &= nbsp; See more by this manufacturer
       Microsoft
       Apple Softwar= e
      Customers also b= ought
       these other items...



    		Microsoft Office Professional Edition *2003*
    Microsoft
    Choose:
     
    $899.00
    Price:$69.99
    You Save= :$830.01 (92%)



    Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
    Media: CD-ROM / Download

    System re= quirements  |  Accessori= es  |  Other Versions

    Features:

    • Analyze and manage business inform= ation using Access databases
    • Exchange data with other systems using enhanced XML technology
    • Control information sharing rules with= enhanced IRM technology
    • Eas= y-to-use wizards to create e-mail newsletters and printed marketing materi= als
    • More than 20 preformatte= d business reports
    Sales Ra= nk: #1
    Shipping: International/US or via insta= nt download
    Date Coupon Expires: June 30th, 2005
    Average Customer Review: 3D"5 Based on 1,768 re= views.     Write a review.
    Microsoft Windows XP Professional or Longhorn Edition
    <= span class=3Dsmall>Microsoft
    Choose:
     = ;

    = = =
    List Price:$279.0= 0
    Price:$49.99
    You Save:$229.01 (85%)



    Availability: Available for = INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM = / Download

    System requirements  |  Accessories  |  Other Versions

    Features:

    • Designed for = businesses of all sizes
    • Mana= ge digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt files and f= olders
    • Built-in voice, video= , and instant messaging support
    • Integration with Windows servers and management solutions

      • Sales Rank: #2
      Shippin= g: International/US or via instant download
      Date Coupon Expires= : June 30th, 2005
      Average Customer Re= view: 3D"5 Based on 868 reviews. Write a review.

      Adobe Photoshop CS2 V 9.0
      = Adobe
      =
      Choose:
       

      List Price:<= /td> $599.00
      Price:$69.99
      You Save:$529.01 (90%)


      Availability: Available for INSTANT download!
      Coupon Code:= ISe229
      Media: CD-ROM / Download

      System requirements = ; |  Accessories  | = ; Other Versions

      <= font size=3D1>Features:

      • Customized workspace; save personalized workspace= and tool settings; create customized shortcuts
      • Unparalleled efficiency--automate production tasks wi= th built-in or customized scripts
      • Improved file management, new design possibilities, and a more intui= tive way to create for the Web
      • Support for 16-bit images, digital camera raw data, and non-square pixel= s
      • Create or modify photos us= ing painting, drawing, and retouching tools

      Sales Rank: #3
      Shipping: In= ternational/US or via instant download
      Date Coupon Expires: Jun= e 30th, 2005
      Average Customer Review:= 3D"5 Based on 498 reviews. Write = a review.

    ----RAkLajyt6bxQaPf0h-- From rtg-dir-bounces@ietf.org Sat Jul 2 09:05:54 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13673 for ; Sat, 2 Jul 2005 09:05:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Doi78-0004Of-Lb for rtg-dir-archive@ietf.org; Sat, 02 Jul 2005 09:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dohgi-0007rO-JD; Sat, 02 Jul 2005 09:05:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dohge-0007o5-Ji for rtg-dir@megatron.ietf.org; Sat, 02 Jul 2005 09:05:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13642 for ; Sat, 2 Jul 2005 09:05:34 -0400 (EDT) Received: from [218.191.73.162] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Doi3G-0004Fl-4A for rtg-dir@ietf.org; Sat, 02 Jul 2005 09:32:39 -0400 Received: from xtd@localhost by dAE5.int (8.11.6/8.11.6); Sat, 02 Jul 2005 09:03:23 -0500 Message-ID: From: "Debbie Roman" To: rtg-dir@ietf.org Date: Sat, 02 Jul 2005 19:06:23 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: JuliaDuvall@jessicasource.com Content-Type: multipart/mixed; boundary="--RAkLajyt6bxQaPf0h" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Subject: 80 % Discount on All Macromedia Titles X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Debbie Roman List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 zlA ----RAkLajyt6bxQaPf0h Content-Type: text/html; Content-Transfer-Encoding: quoted-printable H
    Opt-in Email Special Offer &n= bsp;   unsubscribe me=
    = = List Price:
    SEARCH

    TOP 10 NEW TITLES

    = =

     = ON SALE NOW!

     1 Office Pro 2003
     2 W= indows XP Pro
     3 Adob= e Creative Suite Premium
     4<= a href=3Dhttp://vitriolware.com/?R> Norton Antivirus 2005
     = 5 Flash MX 2004
     6 Corel Draw 12
     7= Adobe Acrobat 7.0
     8 Windows 2003 Server
     = ;9 Alias Maya 6 Wavefrt
    &= nbsp;10 Adobe Premiere
    &= nbsp; See more by this manufacturer
       Microsoft
       Apple Softwar= e
      Customers also b= ought
       these other items...



    		Microsoft Office Professional Edition *2003*
    Microsoft
    Choose:
     
    $899.00
    Price:$69.99
    You Save= :$830.01 (92%)



    Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
    Media: CD-ROM / Download

    System re= quirements  |  Accessori= es  |  Other Versions

    Features:

    • Analyze and manage business inform= ation using Access databases
    • Exchange data with other systems using enhanced XML technology
    • Control information sharing rules with= enhanced IRM technology
    • Eas= y-to-use wizards to create e-mail newsletters and printed marketing materi= als
    • More than 20 preformatte= d business reports
    Sales Ra= nk: #1
    Shipping: International/US or via insta= nt download
    Date Coupon Expires: June 30th, 2005
    Average Customer Review: 3D"5 Based on 1,768 re= views.     Write a review.
    Microsoft Windows XP Professional or Longhorn Edition
    <= span class=3Dsmall>Microsoft
    Choose:
     = ;

    = = =
    List Price:$279.0= 0
    Price:$49.99
    You Save:$229.01 (85%)



    Availability: Available for = INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM = / Download

    System requirements  |  Accessories  |  Other Versions

    Features:

    • Designed for = businesses of all sizes
    • Mana= ge digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt files and f= olders
    • Built-in voice, video= , and instant messaging support
    • Integration with Windows servers and management solutions

      • Sales Rank: #2
      Shippin= g: International/US or via instant download
      Date Coupon Expires= : June 30th, 2005
      Average Customer Re= view: 3D"5 Based on 868 reviews. Write a review.

      Adobe Photoshop CS2 V 9.0
      = Adobe
      =
      Choose:
       

      List Price:<= /td> $599.00
      Price:$69.99
      You Save:$529.01 (90%)


      Availability: Available for INSTANT download!
      Coupon Code:= ISe229
      Media: CD-ROM / Download

      System requirements = ; |  Accessories  | = ; Other Versions

      <= font size=3D1>Features:

      • Customized workspace; save personalized workspace= and tool settings; create customized shortcuts
      • Unparalleled efficiency--automate production tasks wi= th built-in or customized scripts
      • Improved file management, new design possibilities, and a more intui= tive way to create for the Web
      • Support for 16-bit images, digital camera raw data, and non-square pixel= s
      • Create or modify photos us= ing painting, drawing, and retouching tools

      Sales Rank: #3
      Shipping: In= ternational/US or via instant download
      Date Coupon Expires: Jun= e 30th, 2005
      Average Customer Review:= 3D"5 Based on 498 reviews. Write = a review.

    ----RAkLajyt6bxQaPf0h-- From rtg-dir-bounces@ietf.org Mon Jul 4 02:26:52 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20635 for ; Mon, 4 Jul 2005 02:26:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpKqP-0002ma-CP for rtg-dir-archive@ietf.org; Mon, 04 Jul 2005 02:54:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpKOr-0004n1-Bs; Mon, 04 Jul 2005 02:25:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpKOp-0004mh-Od for rtg-dir@megatron.ietf.org; Mon, 04 Jul 2005 02:25:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20435 for ; Mon, 4 Jul 2005 02:25:46 -0400 (EDT) Message-Id: <200507040625.CAA20435@ietf.org> Received: from [60.196.145.195] (helo=kephart.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DpKpL-0002jp-LA for rtg-dir@ietf.org; Mon, 04 Jul 2005 02:53:12 -0400 From: "Kyriakos Garrison" To: "Tora Street" Date: Mon, 4 Jul 2005 01:25:44 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C58061.350AA400" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.2 (++++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: Works Very Goood X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C58061.350AA400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Sure it's your lordship has the fine sight to perceive it, laughedwas = voiced by Ogle.as men often are in sudden penitence.The Baron had just = sat down to dinner with M. de Cussy when theBut if I command you to go - = to make the attempt? he asked.stern sheets. He levelled his telescope = upon that figure.been mutually determined.other types of the human = family that converted the quays of CayonaBut it was necessary so that = you may understand.to deliver himself, considering how he should begin. = He desiredyou will give us leave, then, sir uncle.Mr. James Nuttall made = all speed, regardless of the heat, in hisfor sarcasm, interposed a = suggestion bitterly.by God and his country. Whereupon, having prayed to = God to send himHis shipmaster always, ma'am.No. Blood closed his = telescope. I don't know who it is. ------=_NextPart_000_004C_01C58061.350AA400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Welcome to P = pitchfork harmOnline S phantasmal = hop - one of the leading onIine pharmaceutic mellowness al shops
     
    floatable V extrude G neurasthenic AL protagonist Ll
    = displaced lA empanel = RA C pathological = l I bunker = S V biweekly = A U bobbery = M  and many other.
     
    - Save ove insomuch = r 50%
    - Worldwide SHl = carminative PPlNG
    - Total confidentiaIi = remissible ty
    - Over 5 miIIion customers in 130 cou potency ntries
     
    Have prefab a = nice day!
    ------=_NextPart_000_004C_01C58061.350AA400-- From rtg-dir-bounces@ietf.org Mon Jul 4 07:12:44 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25357 for ; Mon, 4 Jul 2005 07:04:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpPAn-0005fr-TX for rtg-dir-archive@ietf.org; Mon, 04 Jul 2005 07:31:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpOk1-0001cn-EP; Mon, 04 Jul 2005 07:03:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpOjs-0001al-8w for rtg-dir@megatron.ietf.org; Mon, 04 Jul 2005 07:03:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25056 for ; Mon, 4 Jul 2005 07:03:42 -0400 (EDT) Received: from [192.20.225.110] (helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpP70-0004eD-CZ for rtg-dir@ietf.org; Mon, 04 Jul 2005 07:27:45 -0400 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-green.research.att.com (Postfix) with ESMTP id 95895A7BCF for ; Mon, 4 Jul 2005 07:00:03 -0400 (EDT) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j64B023h025652 for ; Mon, 4 Jul 2005 04:00:02 -0700 (PDT) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j64B01YH025651 for rtg-dir@ietf.org; Mon, 4 Jul 2005 04:00:01 -0700 (PDT) (envelope-from fenner) Date: Mon, 4 Jul 2005 04:00:01 -0700 (PDT) Message-Id: <200507041100.j64B01YH025651@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Subject: IESG agenda for 2005-07-07 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-07-07). Updated 2:27:57 EDT, July 4, 2005 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date Enhancements for Authenticated Identity TSV Management in the Session Initiation Protocol (SIP) (Proposed Standard) - 1 of 4 draft-ietf-sip-identity-05.txt [Open Web Ballot] Token: Allison Mankin Securing Mobile IPv6 Route Optimization Using INT a Static Shared Key (Proposed Standard) - 2 of 4 draft-ietf-mip6-precfgkbm-03.txt [Open Web Ballot] Token: Margaret Wasserman INT DHCP Options for Broadcast and Multicast Control Servers (Proposed Standard) - 3 of 4 draft-ietf-dhc-bcmc-options-02.txt [Open Web Ballot] Token: Margaret Wasserman APP The Atom Syndication Format (Proposed Standard) - 4 of 4 draft-ietf-atompub-format-09.txt [Open Web Ballot] Note: Paul Hoffman is the shepherd for the atompub working group. Token: Scott Hollenbeck 2.1.2 Returning Item Area Date RTG BGP Extended Communities Attribute (Proposed Standard) - 1 of 1 draft-ietf-idr-bgp-ext-communities-08.txt [Open Web Ballot] Note: Late addition; updated I-D hasn't been submitted yet but is available at http:// homepage.mac.com/BillFenner/ draft-ietf-idr-bgp-ext-communities-09.txt . Token: Bill Fenner 2.2 Individual Submissions 2.2.1 New Item Area Date Domain Name System (DNS) Security Extensions OPS Mapping for the Extensible Provisioning Protocol (EPP) (Proposed Standard) - 1 of 2 draft-hollenbeck-epp-secdns-07.txt [Open Web Ballot] Note: Last call will end on 7/8. Token: David Kessens Identifiers and Test Vectors for HMAC-SHA-224, SEC HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 (Proposed Standard) - 2 of 2 draft-nystrom-smime-hmac-sha-02.txt [Open Web Ballot] Token: Russ Housley 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item NONE 3.1.2 Returning Item Area Date IPv6 Host Configuration of DNS Server OPS Information Approaches (Informational) - 1 of 1 draft-ietf-dnsop-ipv6-dns-configuration-06.txt [Open Web Ballot] Note: Back to the IESG to discuss IESG note. Token: David Kessens 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date TSV Selectively Reliable Multicast Protocol (SRMP) (Experimental) - 1 of 4 draft-pullen-srmp-06.txt [Open Web Ballot] Token: Allison Mankin Requesting Attributes by Object Class in the APP Lightweight Directory Access Protocol (Informational) - 2 of 4 draft-zeilenga-ldap-adlist-10.txt [Open Web Ballot] Token: Ted Hardie APP LDAP Modify-Increment Extension (Informational) - 3 of 4 draft-zeilenga-ldap-incr-01.txt [Open Web Ballot] Token: Ted Hardie APP LDAP Turn Operation (Experimental) - 4 of 4 draft-zeilenga-ldap-turn-02.txt [Open Web Ballot] Token: Ted Hardie 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. Other matters may be recorded in comments to be passed on to the RFC Editor as community review of the document. 3.3.1 New Item NONE 3.3.2 Returning Item Area Date Suggested Practices for Registration of GEN Internationalized Domain Names (IDN) (Informational) - 1 of 1 draft-klensin-reg-guidelines-08.txt [Open Web Ballot] Note: RFC Editor Individual Submission: Recommending that we return RFC 3932 answer #1 (no conflict) with IESG note as included in the ballot. Token: Margaret Wasserman 3.3.3 For Action Area Date GEN A Proposed Media Delivery Index (Informational) - 1 of 1 draft-welch-mdi-02.txt Token: Brian Carpenter 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval Area Date APP Jun 16 Calendaring and Scheduling Standards Simplification (calsify) - 1 of 1 Token: Ted 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval Area Date INT Jun 1 Protocol for carrying Authentication for Network Access (pana) - 1 of 1 Token: Mark 5. IAB News We Can Use 6. Management Issues 7. Working Group News From rtg-dir-bounces@ietf.org Wed Jul 6 19:57:38 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16485 for ; Wed, 6 Jul 2005 19:57:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqKCy-0002sb-W3 for rtg-dir-archive@ietf.org; Wed, 06 Jul 2005 20:25:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqJlb-0005FL-2L; Wed, 06 Jul 2005 19:57:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqJlZ-0005Ev-9G; Wed, 06 Jul 2005 19:57:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16457; Wed, 6 Jul 2005 19:57:18 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqKCd-0002rs-C7; Wed, 06 Jul 2005 20:25:20 -0400 Received: from 84-121-27-86.onocable.ono.com ([84.121.27.86]) by mx2.foretec.com with smtp (Exim 4.24) id 1DqJlW-0000MO-B8; Wed, 06 Jul 2005 19:57:20 -0400 Received: from ankara.tjewmt.matisse.patrolmen.com by preamble.usurp.cold.com (uohupfix) with SMTP id 5B29E820451 for ; Thu, 07 Jul 2005 04:48:30 +0400 Message-ID: Date: Thu, 07 Jul 2005 01:55:30 +0100 From: "Linwood Ladner" To: X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 2.1 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: Notification: We offer low rates X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.m0rtgag3.com/signs.asp Best Regards, Jamie Arroyo to be remov(ed: http://www.m0rtgag3.com/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Sat Jul 9 00:17:50 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08050 for ; Sat, 9 Jul 2005 00:17:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr7EJ-0005QB-6M for rtg-dir-archive@ietf.org; Sat, 09 Jul 2005 00:46:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr6mI-0005CO-7c; Sat, 09 Jul 2005 00:17:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr6mH-0005CJ-D4 for rtg-dir@megatron.ietf.org; Sat, 09 Jul 2005 00:17:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08031 for ; Sat, 9 Jul 2005 00:17:18 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr7Dh-0005PU-Si for rtg-dir@ietf.org; Sat, 09 Jul 2005 00:45:47 -0400 Received: from [220.175.131.193] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Dr6m1-0000aJ-Uh for rtg-dir@ietf.org; Sat, 09 Jul 2005 00:17:07 -0400 Received: from KpBT@localhost by mzLs.int (8.11.6/8.11.6); Sat, 09 Jul 2005 00:01:27 -0500 Message-ID: From: "Luisa Wilkes" To: rtg-dir@ietf.org Date: Sat, 09 Jul 2005 00:08:27 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: MelvaHerrera@abscission.com Content-Type: multipart/mixed; boundary="--7A0IsC43CoD9yYix" X-Spam-Score: 3.6 (+++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Subject: MS Office 2003 Pro $69.95 Macromedia X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Luisa Wilkes List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.6 (+++) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 ObTe ----7A0IsC43CoD9yYix Content-Type: text/html; Content-Transfer-Encoding: quoted-printable M
    Opt-in Email Special Offer &n= bsp;   unsubscribe me<= a href=3Dhttp://save2drive.com/?y>
    = =
    <= td bgcolor=3D#000080>
    SEARCH

    TOP 10 NEW TITLES

    <= td width=3D8>4= 79

     = ON SALE NOW!

     1 = Office Pro 2003
     2 Wi= ndows XP Pro
     3 Adobe= Creative Suite Premium
      Norton Antivirus 2005
     5 Flash MX 2004
     6 = Corel Draw 12
      Adobe Acrobat 7.0
     8 Windows 2003 Server
      Alias Maya 6 Wavefrt
     10 Adobe Premiere
      See more by this manufacturer
       Micro= soft
      = Apple Software<= /td>
      Customers also bought=
       these other items...
    =



    		Microsoft Office Professional Edition *2003*
    Microsoft
    Choose:
    <= /a> 
    List Price:<= /td>$899.00
    Price:$69.99
    You Save:$830.01 (92%)



    = Availability: Available for INSTANT download!
    Coupon Code:<= /b> ISe229
    Media: CD-ROM / Download

    System requirements  = |  Accessories  |  <= a href=3Dhttp://save2drive.com/?Y>Other Versions

    Features:

    • Analyze and manage business information using Access data= bases
    • Exchange data with oth= er systems using enhanced XML technology
    • Control information sharing rules with enhanced IRM technolog= y
    • Easy-to-use wizards to cre= ate e-mail newsletters and printed marketing materials
    • More than 20 preformatted business reports
    Sales Rank: #1
    Shipping: International/US or via instant download
    Date= Coupon Expires: June 30th, 2005
    Aver= age Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
    Microsoft W= indows XP Professional or Longhorn Edition
    Microsoft
    Choose:
     

    =
    List Pr= ice:$279.00
    Pric= e:$49.99
    You Save:$229.01 (85%)

    <= br>
    Availability: Available for INSTANT download!
    Coupon= Code: ISe229
    Media: CD-ROM / Download

    System requirements=   |  Accessories  |&= nbsp; Other Versions

    <= b>Features:

    • Designed for businesses of all sizes
    • Manage digital pictures, music, video,= DVDs, and more
    • More securit= y with the ability to encrypt files and folders
    • Built-in voice, video, and instant messaging support <= /font>
    • Integration with Windows serv= ers and management solutions

    Sal= es Rank: #2
    Shipping: International/US or via = instant download
    Date Coupon Expires: June 30th, 2005
    Average Customer Review: 3D= Based on 868 r= eviews. Write a review.

    =
    Adobe Photoshop CS2 V 9.0
    Adobe
    =
    Choose= :
    &n= bsp;

    <= /table>



    Availability: Available for INSTAN= T download!
    Coupon Code: ISe229
    Media: CD-ROM / Down= load

    System requirements  |  Accessories  |  Other Ve= rsions

    Features:

    • Customized workspace; = save personalized workspace and tool settings; create customized shortcuts=
    • Unparalleled efficiency--a= utomate production tasks with built-in or customized scripts
      • =
    • Improved file management, new design poss= ibilities, and a more intuitive way to create for the Web
      • Support for 16-bit images, digital camera ra= w data, and non-square pixels
    • Create or modify photos using painting, drawing, and retouching tools

    Sales Rank: #3
    Shipping: International/US or via instant download
    = Date Coupon Expires: June 30th, 2005
    = Average Customer Review: 3D"5 Based on 498 reviews. Write a review.

    List Price: $599.00
    Price:$69.99
    You Save:$529.01 (90%)
    ----7A0IsC43CoD9yYix-- From rtg-dir-bounces@ietf.org Sun Jul 10 14:19:39 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15221 for ; Sun, 10 Jul 2005 14:19:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drgqp-0000gM-4W for rtg-dir-archive@ietf.org; Sun, 10 Jul 2005 14:48:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrgNR-0006Af-ES; Sun, 10 Jul 2005 14:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrgNQ-0006Aa-2D for rtg-dir@megatron.ietf.org; Sun, 10 Jul 2005 14:18:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15149 for ; Sun, 10 Jul 2005 14:18:02 -0400 (EDT) Received: from mra04.ex.eclipse.net.uk ([212.104.129.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drgp7-0000bS-Pg for rtg-dir@ietf.org; Sun, 10 Jul 2005 14:46:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mra04.ex.eclipse.net.uk (Postfix) with ESMTP id 50066133AFB for ; Sun, 10 Jul 2005 19:17:34 +0100 (BST) Received: from mra04.ex.eclipse.net.uk ([127.0.0.1]) by localhost (mra04.ex.eclipse.net.uk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30621-01-88 for ; Sun, 10 Jul 2005 19:17:33 +0100 (BST) Received: from [11.22.33.45] (unknown [82.152.159.67]) by mra04.ex.eclipse.net.uk (Postfix) with ESMTP id 832B8133B25 for ; Sun, 10 Jul 2005 19:17:33 +0100 (BST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 10 Jul 2005 19:20:00 +0100 From: John Adler To: Message-ID: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3203868001_1864745" X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: New initiative for Internet X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 > 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_3203868001_1864745 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I have a new idea for service delivery on the internet that would be aimed at manufacturing organisations with a view to facilitating communication with customers seeking various services from them. It has been patented. It would use the internet as it is basically configured at present without any alteration to the existing system, but would involve certain simple supplementary programming facilities. The outcome would be a considerable improvement in the ability of the internet to handle traffic as well as making it far more user friendly. I need some assistance in making contact with parties such as yourself, who are responsible for maintaining and developing the internet in order to explore this idea further. Can you please assist? --from John Adler John Adler Associates Marketing, Image, Text, Design Tel/fax: 0117 9241766 Mobile: 0776 520 8036 --B_3203868001_1864745 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable New initiative for Internet I hav= e a new idea for service delivery on the internet that would be aimed at man= ufacturing organisations with a view to facilitating communication with cust= omers seeking various services from them. It has been patented.
    It would use the internet as it is basically configured at present without = any alteration to the existing system, but would involve certain simple supp= lementary programming facilities. The outcome would be a considerable improv= ement in the ability of the internet to handle traffic as well as making it = far more user friendly.
    I need some assistance in making contact with parties such as yourself, who= are responsible for maintaining and developing the internet in order to exp= lore this idea further.
    Can you please assist?

    --from John Adler
    John Adler Associates
    Marketing, Image, Text, Design
    Tel/fax:    0117 9241766
    Mobile:     0776 520 8036

     --B_3203868001_1864745-- From rtg-dir-bounces@ietf.org Mon Jul 11 13:50:26 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04712 for ; Mon, 11 Jul 2005 13:50:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds2sJ-0001gM-37 for rtg-dir-archive@ietf.org; Mon, 11 Jul 2005 14:19:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds2Q5-0007Vx-B7; Mon, 11 Jul 2005 13:50:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds2Q4-0007Sd-2y for rtg-dir@megatron.ietf.org; Mon, 11 Jul 2005 13:50:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04653 for ; Mon, 11 Jul 2005 13:50:11 -0400 (EDT) Message-Id: <200507111750.NAA04653@ietf.org> Received: from host226-47.pool8259.interbusiness.it ([82.59.47.226] helo=jensenprecast.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ds2s1-0001ec-Rl for rtg-dir@ietf.org; Mon, 11 Jul 2005 14:19:12 -0400 From: "Aristodemos Moon" To: "Ava Baughman" Date: Mon, 11 Jul 2005 12:49:47 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C58640.ED77AF80" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: Feeels Bigger X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.8 (++++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C58640.ED77AF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, result of his errand of mercy to Oglethorpe's Farm contained -that, no, by = example! You shall not take her.... He would haveloses his fleet in = the night, then has his flagship fired under himWolverstone laughed. = Cahusac exploded in fury.had a hundred men within easy call. But it = seemed that he had lefteven pretended. If it were, I could forgive = them. But not evensought to relieve the sufferings of a = fellow-creature; because IBarbados.that suave and courtly commander was = settling these details with theand accounted it a meritorious deed. It = was the thought of ArabellaYet Peter Blood, who was not only able to = bear arms, but trained andexterior-interiors which Moorish architects = had introduced toKing James was fled to France, and living under the = protection ofand had moved to disturb the peace and tranquillity of the = kingdombare twenty thousand pieces.charity to the wharf, bringing their = gifts to the wounded seamen. ------=_NextPart_000_0028_01C58640.ED77AF80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    How to save on your MEDlCATlONS over 60% aborted .
     
    PharmazMai fortnightly l Shop - = filamentary Successfull and Proven Way to save your mon domination ey.
     
    tanglefoot V A sateless G skylight L spanless lU
    isocline = l R Chilean = A Cl differentia = A = conversational IS V shaver = AL switch = M  and many other.
     
    highball * = Best PRlCES
    * Worldwide SHlPP = dachshund lNG
    * Total c orderly = onfidentiaIity
    * Over 5 mil insular = Iion customers
     
    Ha shrewmouse = ve a nice day!
    ------=_NextPart_000_0028_01C58640.ED77AF80-- From rtg-dir-bounces@ietf.org Mon Jul 11 17:07:22 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16284 for ; Mon, 11 Jul 2005 17:07:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds5wt-00018m-Aq for rtg-dir-archive@ietf.org; Mon, 11 Jul 2005 17:36:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5TM-0006pF-G7; Mon, 11 Jul 2005 17:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl93X-0004j6-MJ; Wed, 22 Jun 2005 13:30:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05938; Wed, 22 Jun 2005 13:28:44 -0400 (EDT) Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl9Q2-0008Qv-OO; Wed, 22 Jun 2005 13:53:47 -0400 Received: from dh029172.ahqps.alcatel.fr (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j5MHSYWm029499; Wed, 22 Jun 2005 12:28:35 -0500 (CDT) Date: Wed, 22 Jun 2005 10:28:30 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <275365392.20050622102830@alcatel.com> To: Margaret Wasserman In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 11 Jul 2005 17:05:51 -0400 Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Adrian Farrel , Brian E Carpenter , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Margaret, I did a quite detailed talk at the last BOF, explaining what potential routing-related issues are there, and how a naive approach would not scale. Routing expertise in TRILL is _extremely_ important if we want a solid technology. -- Alex Wednesday, June 22, 2005, 10:16:28 AM, Margaret Wasserman wrote: > Hi Sue, > The TRILL WG would not be chartered to develop a link-state routing > protocol. They would be chartered to make use of an existing > link-state routing protocol, and any extensions or modifications to > that protocol would be referred to the appropriate routing area WG. > The TRILL WG would determine the mechanisms for encapsulating and > forwarding Ethernet frames and for auto-configuring the rbridges. I > am not sure that in-depth expertise in link-state routing protocols > is needed for that. Instead, you need expertise in encapsulation, > forwarding and configuration, which are all Internet area topics. > Margaret > At 12:27 PM -0400 6/22/05, Susan Hares wrote: >>Margaret: >> >>I suggest that the expertise in the link state is in the Routing area of >>the IETF. If it belongs in the IETF due to expertise, it belongs in the >>Routing. >> >>Critical early review has been determined to be key to a quickly >>deployed specification. >> >>Sue >> >>-----Original Message----- >>From: Margaret Wasserman [mailto:margaret@thingmagic.com] >>Sent: Wednesday, June 22, 2005 8:57 AM >>To: Adrian Farrel; Brian E Carpenter >>Cc: Tony Li; Alex Zinin; rtg-dir@ietf.org; iesg@ietf.org; >>routing-discussion@ietf.org; rtg-chairs@ietf.org; Susan Hares >>Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of >>Links (trill) >> >> >>Hi Adrian, >> >>At 1:22 PM +0100 6/22/05, Adrian Farrel wrote: >>>I think the skill-set to which Brian refers is link state routing. >>(Care >>>to confirm, Brian?) >> >>Yes, expertise in link-state routing is certainly one reason why this >>work could be seen as more in-scope for the IETF than for the IEEE. >>Also, frankly, there is interest in the IETF in doing this work (a >>link-state-based Ethernet routing solution), while the IEEE is >>continuing to pursue (R)STP-based approaches. >> >>>If so, why is this WG targeted at the Internet Area not the Routing >>area? >> >>This questions has been discussed in the IESG, as well, and we did >>not have 100% agreement regarding the area in which this work belongs. >> >>Personally, I think that TRILL is a better fit for the Internet area, >>and I will explain why... >> >>Traditionally, the division between the Internet area and the Routing >>area has been that the Routing area deals with protocols that >>distribute routing information (routes/labels) and the Internet area >>has been responsible for the forwarding behaviour and encapsulation >>mechanisms that make use of that information. >> >>The TRILL charter maintains that split -- any work on the routing >>protocols themselves would be done in the routing area, while the >>encapsulation/forwarding mechanism would be developed in the Internet >>area. >> >>Perhaps you have a different model of the division between the >>Routing and Internet areas that makes you think otherwise? >> >>The IESG discussed this issue several months ago. We agreed that >>this work is close to the line between Internet and Routing, but we >>reached an agreement that it would best be placed in the Internet >>area, with the understanding that we would appoint a technical >>advisor and a WG co-chair with routing expertise. BIll Fenner >>volunteered to be the Technical Advisor, and Bill and Alex took an >>action item to return with a list of potential co-chairs. >> >>Ultimately, I am not sure that it matters all that much which area >>this work is done in, since it will require expertise and involvement >>from both areas in order to succeed. >> >>Margaret From rtg-dir-bounces@ietf.org Mon Jul 11 17:07:35 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16295 for ; Mon, 11 Jul 2005 17:07:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds5x1-000191-SB for rtg-dir-archive@ietf.org; Mon, 11 Jul 2005 17:36:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5TM-0006pJ-Jz; Mon, 11 Jul 2005 17:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl9YL-0005Kl-Uu; Wed, 22 Jun 2005 14:02:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06905; Wed, 22 Jun 2005 14:02:11 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl9uy-0001MY-BE; Wed, 22 Jun 2005 14:25:45 -0400 Received: from [10.0.0.171] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 399099; Wed, 22 Jun 2005 13:55:29 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <275365392.20050622102830@alcatel.com> References: <275365392.20050622102830@alcatel.com> Date: Wed, 22 Jun 2005 13:57:47 -0400 To: Alex Zinin From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Mon, 11 Jul 2005 17:05:51 -0400 Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Adrian Farrel , Brian E Carpenter , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi Alex, At 10:28 AM -0700 6/22/05, Alex Zinin wrote: > Routing expertise in TRILL is _extremely_ important if we want a solid > technology. I think that I have said the same thing several times in this thread, although perhaps not with this particular cc: list... It is vitally important that we have experts from both the RTG area and the INT area involved in TRILL, or the group will not be successful. When the potential home of this work was discussed by the IESG, we all agreed that routing expertise would be essential to the success of this group. That is why we had proposed to have a technical advisor and co-chair from the RTG area. I am somewhat confused by this discussion, as the tone seems to indicate that if we have a group in the INT area, no one from the routing area can/will attend and vice versa. There are many individuals who cross the boundaries between those two areas, we all meet in the same city at the same time, and I thought that this type of cross-fertilization was exactly why we choose to have IETF plenary meetings with all areas present. Is it really true that none of the "routing people" who have posted passionate messages about this work will attend if the group is chartered in the INT area? If so, I think we have a much bigger problem than what to do with this particular group. Margaret From rtg-dir-bounces@ietf.org Mon Jul 11 17:07:41 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16309 for ; Mon, 11 Jul 2005 17:07:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds5x9-00019M-Uq for rtg-dir-archive@ietf.org; Mon, 11 Jul 2005 17:36:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5TM-0006pN-NK; Mon, 11 Jul 2005 17:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl9Z2-0005i4-3H; Wed, 22 Jun 2005 14:03:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07397; Wed, 22 Jun 2005 14:02:50 -0400 (EDT) Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl9cI-0000N6-DD; Wed, 22 Jun 2005 14:06:31 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IIH00306YGO3V00@mail-mta.sfvic.sunlabs.com>; Wed, 22 Jun 2005 10:41:12 -0700 (PDT) Received: from Sun.COM ([129.146.11.199]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IIH005DUYGH1E14@mail.sunlabs.com>; Wed, 22 Jun 2005 10:41:09 -0700 (PDT) Date: Wed, 22 Jun 2005 10:41:05 -0700 From: Radia Perlman In-reply-to: <275365392.20050622102830@alcatel.com> To: Alex Zinin Message-id: <42B9A2B1.4030809@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <275365392.20050622102830@alcatel.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Mon, 11 Jul 2005 17:05:50 -0400 Cc: Alex Zinin , rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Margaret Wasserman , Adrian Farrel , Brian E Carpenter , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Radia.Perlman@sun.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT TRILL also requires expertise in ND, and IP endnode behavior in general, which would be in Internet. Hopefully which area something is in does not preclude cross-fertilization, or review by experts in other areas. Security and management are also areas that need to be consulted for almost any protocol. Radia Alex Zinin wrote: > Margaret, > > I did a quite detailed talk at the last BOF, explaining what potential > routing-related issues are there, and how a naive approach would not > scale. > > Routing expertise in TRILL is _extremely_ important if we want a solid > technology. > From rtg-dir-bounces@ietf.org Mon Jul 11 17:07:49 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16331 for ; Mon, 11 Jul 2005 17:07:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds5xJ-00019n-GA for rtg-dir-archive@ietf.org; Mon, 11 Jul 2005 17:36:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5TM-0006pR-SJ; Mon, 11 Jul 2005 17:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlTAy-00047Y-Dy; Thu, 23 Jun 2005 10:59:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20399; Thu, 23 Jun 2005 10:59:26 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlTZC-0008Rw-MY; Thu, 23 Jun 2005 11:24:38 -0400 Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5NExKqg007850; Thu, 23 Jun 2005 08:59:21 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5NExFnY651903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 23 Jun 2005 07:59:17 -0700 (PDT) Message-ID: <42BACE60.9080108@sun.com> Date: Thu, 23 Jun 2005 07:59:44 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ewgray@GraIyMage.com References: <42BAADE8.6060802@netscape.net> In-Reply-To: <42BAADE8.6060802@netscape.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 11 Jul 2005 17:05:50 -0400 Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, margaret@thingmagic.com, Adrian Farrel , Brian E Carpenter , Susan Hares Subject: Re: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Eric W Gray wrote: > The interesting thing here is that any changes in the encapsulation > of Ethernet > frames would have drastic implications on all Ethernet equipment - > including NIC > cards in Ethernet end stations. If this is not the case, then we are > talking about an > encapsulation of a transport segment, rather than encapsulation > end-to-end. If that > is what we are talking about, how does this "encapsulation" differ from > Martini? Perhaps I can help answer this. The encapsulation is not end-to-end; it is merely between the TRILL devices. The draft-radia-rbridge draft shows the current thinking for the encapsulation, with a header than in the case of carrying things over Ethernet include - source rbridge MAC address (so that bridges between the rbridges don't get confused) - next hop rbridge MAC address (to avoid proliferation should the bridges flood the frame and multiple rbridges receive it) - ttl (to limit the damage from any temporary routing loops) - last hop rbridge (so that intermediate rbridges don't need to track the location of each station) - Ethernet type So this is quite different than the Martini approach. Should TRILL later be expanded to apply to run over MPLS (something which is not in the current charter) then I suspect we'd end up with an encapsulation like Martini, and a link-state routing protocol carrying the MAC addresses. So the TRILL work is architecturally quite similar to the VPLS work in L2VPN. The encapsulation that is safe and scalable for Ethernet is a key difference. Erik From rtg-dir-bounces@ietf.org Mon Jul 11 17:07:52 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16342 for ; Mon, 11 Jul 2005 17:07:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds5xP-0001AB-BB for rtg-dir-archive@ietf.org; Mon, 11 Jul 2005 17:36:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5TM-0006pV-Vj; Mon, 11 Jul 2005 17:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlViz-0006O1-Sa; Thu, 23 Jun 2005 13:42:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08702; Thu, 23 Jun 2005 13:42:37 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlW7A-00005x-0v; Thu, 23 Jun 2005 14:07:49 -0400 Received: from [10.0.0.171] (account margaret HELO [10.0.0.171]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 400814; Thu, 23 Jun 2005 13:37:17 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 23 Jun 2005 13:38:43 -0400 To: "Susan Hares" , From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Mon, 11 Jul 2005 17:05:51 -0400 Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Bernard Aboba , Adrian Farrel , Brian E Carpenter Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi Sue, At 11:47 AM -0400 6/23/05, Susan Hares wrote: >Does IETF have a formal relationship with IEEE? The paragraphs from >your earlier mails have me a bit confused. Yes. The IETF has a formal liaison relationship with IEEE 802, and Bernard Aboba is our IEEE 802 liaison manager. >1st - I'm happy to contribute to this work in what ever forum it exists >in. Excellent! >2nd - I would like to have this discussion end today (after IESG), but >it would be "way cool" and necessary to document who, what, when >and where in a document that you can post online about the IEEE/IETF >discussions. I have cc:ed Bernard above. I know that Bernard submitted a liaison report regarding this meeting to the IAB, and I think that those liaison reports are available on the IAB web site (perhaps in the IAB minutes)? However, I can't seem to find the report of this meeting on the IAB web site at the moment. Bernard, do you know if it is posted there? If so, could you send a pointer? >3rd - It would be "way cool"/useful to summarize this discussion in a >document that is associated with the working group pages. Do you mean that we should document the discussion about where the work should be housed? Personally, I think that this discussion has pointed out that we have a real problem right now regarding where the division is (and should be) between the Routing and Internet areas. Although we do not want to delay the decision on chartering the TRILL WG until we can work out the larger issue, I think that we should continue the discussions on the larger issue, and that we _definitely_ should document the results when we are finished, so that they can serve as a reference for these types of discussions if they arise in the future. Margaret From rtg-dir-bounces@ietf.org Mon Jul 11 17:08:57 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16455 for ; Mon, 11 Jul 2005 17:08:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds5yR-0001Cm-4K for rtg-dir-archive@ietf.org; Mon, 11 Jul 2005 17:38:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5TN-0006pZ-2u; Mon, 11 Jul 2005 17:05:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlWUf-0007tC-El; Thu, 23 Jun 2005 14:32:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13816; Thu, 23 Jun 2005 14:31:58 -0400 (EDT) Received: from bay106-f31.bay106.hotmail.com ([65.54.161.41] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlWsv-0002m9-KF; Thu, 23 Jun 2005 14:57:11 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 23 Jun 2005 11:31:47 -0700 Message-ID: Received: from 65.54.161.209 by by106fd.bay106.hotmail.msn.com with HTTP; Thu, 23 Jun 2005 18:31:47 GMT X-Originating-IP: [65.54.161.209] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: margaret@thingmagic.com, shares@nexthop.com, ewgray@GraIyMage.com Date: Thu, 23 Jun 2005 11:31:47 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 Jun 2005 18:31:47.0762 (UTC) FILETIME=[D085F120:01C57821] X-Spam-Score: 0.8 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Mon, 11 Jul 2005 17:05:51 -0400 Cc: zinin@psg.com, rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, adrian@olddog.co.uk, brc@zurich.ibm.com Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 >I have cc:ed Bernard above. I know that Bernard submitted a liaison report >regarding this meeting to the IAB, and I think that those liaison reports >are available on the IAB web site (perhaps in the IAB minutes)? However, I >can't seem to find the report of this meeting on the IAB web site at the >moment. Bernard, do you know if it is posted there? If so, could you send >a pointer? The IEEE 802 liaison web page is available here: http://www.iab.org/liaisons/ieee/index.html From rtg-dir-bounces@ietf.org Mon Jul 11 17:09:08 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16509 for ; Mon, 11 Jul 2005 17:09:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds5yZ-0001DD-AX for rtg-dir-archive@ietf.org; Mon, 11 Jul 2005 17:38:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5TN-0006pd-6M; Mon, 11 Jul 2005 17:05:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlXMQ-0008R6-5R; Thu, 23 Jun 2005 15:27:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19277; Thu, 23 Jun 2005 15:27:30 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlXkg-0005Hh-2f; Thu, 23 Jun 2005 15:52:44 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id DE1982D544C; Thu, 23 Jun 2005 15:27: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 64040-01-69; Thu, 23 Jun 2005 15:27:09 -0400 (EDT) Received: from BOS-exch01.corp.nexthop.com (unknown [192.168.11.20]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C61EC2D5765; Thu, 23 Jun 2005 14:34:16 -0400 (EDT) Received: from aa-exchange1.corp.nexthop.com ([65.247.36.233]) by BOS-exch01.corp.nexthop.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Jun 2005 14:34:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Jun 2005 14:34:14 -0400 Message-ID: Thread-Topic: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) thread-index: AcV4IbS33NEYeoUvSaWW5jKOSAcz+QAACD7Q From: "Susan Hares" To: "Margaret Wasserman" , X-OriginalArrivalTime: 23 Jun 2005 18:34:16.0419 (UTC) FILETIME=[29213330:01C57822] X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 11 Jul 2005 17:05:50 -0400 Cc: Alex Zinin , rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, rtg-chairs@ietf.org, Bernard Aboba , Adrian Farrel , Brian E Carpenter Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Margaret: Sounds like the beginnings of a plan. I'm sure the IESG will find a designated soul to write-up the discussion. If they want help, glad to lend a hand. Sue (As a friend used to say "cool beans.")=20 -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com]=20 Sent: Thursday, June 23, 2005 1:39 PM To: Susan Hares; ewgray@GraIyMage.com Cc: Adrian Farrel; Brian E Carpenter; Alex Zinin; rtg-dir@ietf.org; iesg@ietf.org; routing-discussion@ietf.org; rtg-chairs@ietf.org; Bernard Aboba Subject: RE: Fwd: Re: WG Review: Transparent Interconnection of Lots of Links (trill) Hi Sue, At 11:47 AM -0400 6/23/05, Susan Hares wrote: >Does IETF have a formal relationship with IEEE? The paragraphs from >your earlier mails have me a bit confused. Yes. The IETF has a formal liaison relationship with IEEE 802, and=20 Bernard Aboba is our IEEE 802 liaison manager. >1st - I'm happy to contribute to this work in what ever forum it exists >in. Excellent! >2nd - I would like to have this discussion end today (after IESG), but >it would be "way cool" and necessary to document who, what, when >and where in a document that you can post online about the IEEE/IETF >discussions. I have cc:ed Bernard above. I know that Bernard submitted a liaison=20 report regarding this meeting to the IAB, and I think that those=20 liaison reports are available on the IAB web site (perhaps in the IAB=20 minutes)? However, I can't seem to find the report of this meeting=20 on the IAB web site at the moment. Bernard, do you know if it is=20 posted there? If so, could you send a pointer? >3rd - It would be "way cool"/useful to summarize this discussion in a >document that is associated with the working group pages. Do you mean that we should document the discussion about where the=20 work should be housed? Personally, I think that this discussion has pointed out that we have=20 a real problem right now regarding where the division is (and should=20 be) between the Routing and Internet areas. Although we do not want=20 to delay the decision on chartering the TRILL WG until we can work=20 out the larger issue, I think that we should continue the discussions=20 on the larger issue, and that we _definitely_ should document the=20 results when we are finished, so that they can serve as a reference=20 for these types of discussions if they arise in the future. Margaret From rtg-dir-bounces@ietf.org Mon Jul 11 17:09:11 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16526 for ; Mon, 11 Jul 2005 17:09:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds5yg-0001Dl-Kd for rtg-dir-archive@ietf.org; Mon, 11 Jul 2005 17:38:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5TN-0006ph-A9; Mon, 11 Jul 2005 17:05:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5LN-000519-KW; Mon, 11 Jul 2005 16:57:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14430; Mon, 11 Jul 2005 16:57:20 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds5nC-0000NY-TL; Mon, 11 Jul 2005 17:26:23 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Ds5L6-0003Z0-TW; Mon, 11 Jul 2005 20:57:20 +0000 Date: Mon, 11 Jul 2005 13:57:07 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <8810219224.20050711135707@psg.com> To: routing-discussion@ietf.org In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------48601E215DF00CD" X-Spam-Score: 0.8 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 X-Mailman-Approved-At: Mon, 11 Jul 2005 17:05:50 -0400 Subject: Revising RFC 1264 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 ------------48601E215DF00CD Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Folks- // bcc'ed to rtg-chairs and rtg-dir As it has been discussed multiple times at the RTG area meeting, RFC 1264 defining standardization criteria for protocols in RTG area needed to be revised. Below is the revision Bill and I promised to deliver by the Paris IETF. Please read, comment, and post your opinions to routing-discussion@ietf.org We will have a time slot for this at the RTG area meeting in Paris. -- Alex http://www.psg.com/~zinin This is a forwarded message From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: Date: Monday, July 11, 2005, 12:50:02 PM Subject: I-D ACTION:draft-fenner-zinin-rtg-standard-reqts-00.txt ===8<==============Original message text=============== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Routing Protocol Standardization Criteria Author(s) : B. Fenner, A. Zinin Filename : draft-fenner-zinin-rtg-standard-reqts-00.txt Pages : 14 Date : 2005-7-11 This document provides guidance for the advancement of the protocols produced within the IETF Routing Area. It places implementation and interoperability constraints on protocols earlier in the standards process than RFC 2026, based on RFC 2026's provision that the IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. We also discuss the applicability of these rules to protocols and their extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fenner-zinin-rtg-standard-reqts-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org 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-fenner-zinin-rtg-standard-reqts-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-fenner-zinin-rtg-standard-reqts-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. ===8<===========End of original message text=========== ------------48601E215DF00CD Content-Type: MESSAGE/EXTERNAL-BODY; name="1.msg" Content-Disposition: attachment; filename="1.msg" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2005-7-11145031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fenner-zinin-rtg-standard-reqts-00.txt ------------48601E215DF00CD Content-Type: MESSAGE/EXTERNAL-BODY; name="draft-fenner-zinin-rtg-standard-reqts-00.txt" Content-Disposition: attachment; filename="draft-fenner-zinin-rtg-standard-reqts-00.txt" Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2005-7-11145031.I-D@ietf.org> ------------48601E215DF00CD Content-Type: TEXT/PLAIN; name="Part.txt" Content-Disposition: attachment; filename="Part.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------------48601E215DF00CD-- From rtg-dir-bounces@ietf.org Mon Jul 11 17:18:35 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17250 for ; Mon, 11 Jul 2005 17:18:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds67l-0001Zb-O6 for rtg-dir-archive@ietf.org; Mon, 11 Jul 2005 17:47:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5fV-0002Es-D9; Mon, 11 Jul 2005 17:18:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5fU-0002Em-0d for rtg-dir@megatron.ietf.org; Mon, 11 Jul 2005 17:18:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17221 for ; Mon, 11 Jul 2005 17:18:21 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds67X-0001Z9-RE for rtg-dir@ietf.org; Mon, 11 Jul 2005 17:47:25 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Ds5fQ-0005Y8-Ho; Mon, 11 Jul 2005 21:18:20 +0000 Date: Mon, 11 Jul 2005 14:18:06 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <98824785.20050711141806@psg.com> To: John Adler In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: New initiative for Internet X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit John, If you would like to bring an idea to the IETF, please read the following: http://www.ietf.org/overview.html -- Alex Sunday, July 10, 2005, 11:20:00 AM, John Adler wrote: > I have a new idea for service delivery on the internet that would be aimed > at manufacturing organisations with a view to facilitating communication > with customers seeking various services from them. It has been patented. > It would use the internet as it is basically configured at present without > any alteration to the existing system, but would involve certain simple > supplementary programming facilities. The outcome would be a considerable > improvement in the ability of the internet to handle traffic as well as > making it far more user friendly. > I need some assistance in making contact with parties such as yourself, who > are responsible for maintaining and developing the internet in order to > explore this idea further. > Can you please assist? > --from John Adler > John Adler Associates > Marketing, Image, Text, Design > Tel/fax: 0117 9241766 > Mobile: 0776 520 8036 From rtg-dir-bounces@ietf.org Mon Jul 11 20:39:54 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11206 for ; Mon, 11 Jul 2005 20:39:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds9Gd-00039f-5C for rtg-dir-archive@ietf.org; Mon, 11 Jul 2005 21:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds8nt-0007Uv-4W; Mon, 11 Jul 2005 20:39:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds8nr-0007UY-5A; Mon, 11 Jul 2005 20:39:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11177; Mon, 11 Jul 2005 20:39:13 -0400 (EDT) Received: from cpe-24-90-22-190.nyc.res.rr.com ([24.90.22.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ds9Fw-00037U-8I; Mon, 11 Jul 2005 21:08:17 -0400 Received: from conflagrate-out6.flje.net ([110.129.241.253] helo=smtp9.flje.net) by catalytic.copywriter.cl with esmtp (Exim 4.30 #1 (Mandrake)) id 7COdx9-4435lR-Q2 for ; Tue, 12 Jul 2005 06:33:34 +0500 Message-Id: Date: Mon, 11 Jul 2005 18:28:34 -0700 From: "Wade Rodriguez" To: diffserv-interest-admin@ietf.org X-BeenThere: qxymoga@flashmail.com X-Spam-Score: 2.6 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: rtg-dir@ietf.org, rserpool@ietf.org Subject: what is your target market?-comply druid X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Dying to get website traffic? Problem Solved - Read this: http://www.qualifiedhits.com nice, but no thx- http://www.enhancemetoday.com/rlink/ f A b L h L k d kip RND_DIGIT[1-3] HMGY christen reprehensible chantilly embroidery oppressive conduct jablonsky burn bergen cart midrange hamilton gauleiter borderland delay hadn't predilect yin alfredo fishermen hardin augend straightway blather staple absorb travesty drummond chess E j N d H p A v N z C c E w M d E w N y T z From rtg-dir-bounces@ietf.org Wed Jul 13 19:11:10 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23811 for ; Wed, 13 Jul 2005 19:11:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsqqG-0006Uu-3p for rtg-dir-archive@ietf.org; Wed, 13 Jul 2005 19:40:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsqMy-000490-0j; Wed, 13 Jul 2005 19:10:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsqMw-00048q-6J for rtg-dir@megatron.ietf.org; Wed, 13 Jul 2005 19:10:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23776 for ; Wed, 13 Jul 2005 19:10:19 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsqpQ-0006Tc-W8 for rtg-dir@ietf.org; Wed, 13 Jul 2005 19:39:49 -0400 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DsqMq-000Mk1-TG; Wed, 13 Jul 2005 23:10:16 +0000 Date: Wed, 13 Jul 2005 16:10:01 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <7510401057.20050713161001@psg.com> To: Loa Andersson , George Swallow MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.8 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: quoted-printable Cc: rtg-dir@ietf.org, gen-art@alvestrand.no, Black_David@emc.com Subject: Following up: comments on draft-ietf-mpls-lsp-ping X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Transfer-Encoding: quoted-printable Loa, George: We got some comments from the routing and general directorate on this document. Please check them and let me know what you think should be fixed. I added my commentary with "AZ" prefix. --=20 Alex From=20Russ White: Technical: One general thought is that there are a lot of "IPv4" TLVs and "IPv6" TLVs. It seems like it would generalize better if they just replaced these with SFI encoding--to describe any address (not label), use the AFI, the length described in the AFI, and then the address. Prefix length might be problematic in this context, though, but it might be worth considering. Editorial: 3.2: A Target FEC Stack is a list of sub-TLVs. The number of elements is determined by the looking at the sub-TLV length fields. "the looking at the..." should be "looking at the...." =3D=3D 3.2.3 The value has the format below. The value fields are taken from [RFC3209, sections 4.6.1.1 and 4.6.2.1]. Would it be better to just reference this RFC, rather than repeating the information? If 3209 is ever obsoleted, this repeat of the fields might cause a problem (?). =3D=3D 3.2.4 The value has the format below. The value fields are taken from [RFC3209, sections 4.6.1.2 and 4.6.2.2]. Same thing here. =3D=3D 3.2.8 "....unless explicitly asked by configuration to use the old TLV. "....unless manually configured to use this TLV." =3D=3D From=20Ross Callon: On the most part the document looks quite good. My one substantial issue is the lack of a defined mechanism for authentication in draft-ietf-mpls-lsp-ping-09.txt. One point might be the computational cost of this: However, this would seem to be just as much an issue for BFD, which is after all supposed to be do-able at a very rapid rate and which does authentication. Also, LSP Ping is potentially useful at an "interact with a human trying to debug things" rate, which would imply that authentication should be fast enough for at least this common case. Also, making authentication work at a very high rate is an implementation issue, and is possible (at least if planned for in future products). The most obvious authentication methods (password, MD5, SHA1) are defined for BFD (see section 6.6 of draft-ietf-bfd-base-02.txt), and probab= ly should also be available for LSP Ping. Other points: The security considerations section does discuss authentication. For example: "Authentication will help reduce the number of seemingly valid MPLS echo requests, and thus cut down the Denial of Service attacks;" First of all, I don't see how you can state that authentication could be used for this purpose, when there is no authentication defined. Secondly, authentication only helps prevent DoS for those parts of the system which are *after* the packets with bad authentication are discarded. For whatever part of the system has to actually check the authentication and discard bad packets, authentication can make DoS *worse*, due to the fact that checking authentication itself requires work. Whether this is a win or a loss for the specific case of DoS attacks therefore depends upon a variety of details (such as whether checking the authentication is done in software on a central CPU, or is done in some sort of dedicated hardware). Possibly the security section should explain this. Also there are other more clearly positive advantages of authentication, such as preventing a hacker from initiating a ping, which also might be worth discussing in the security section. AZ: > Ross, regarding lack of authentication per se, I can see how an argument > can be made that this is not worse than what the current IP ping/tracert > have. I does seem strange that the doc tells what the authentication can > do while there is none. From=20David Black (gen-art): Background for those who may be unaware of GenART: GenART is the Area Review Team for the General Area of the IETF. We advise the General Area Director (i.e. the IETF/IESG chair) by providing more in depth reviews than he could do himself of documents that come up for final decision in IESG telechat. I was selected as the GenART member to review this document. Below is my review, which was written specifically with an eye to the GenART process, but since I believe that it will be useful to have these comments more widely distributed, others outside the GenART group are included. Review criteria for WG submissions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" This review was requested as a consequence of IETF Last Call, and I apologize for it arriving after completion of the Last Call. I recommend that this review be addressed before IESG discussion. This draft is on the right track but has open issues. Let me start by saying that I'm not an MPLS expert. Based on the level of MPLS expertise that has been applied to this draft, I'm in no position to check or question the MPLS design aspects of this draft. The issues I'm concerned about are more global: (1) IP ping and traceroute are robust debugging tools because they are based on a simple underlying TTL mechanism, so that if a ping or traceroute packet goes off into a void, one can be reasonably confident that something in the data plane is broken close to where the packet vanished. MPLS ping/traceroute is considerably more complex (40+ page draft). That's not necessarily bad, as MPLS is a more complex entity and ping/traceroute for MPLS has to deal with a known weakness in IP ping/traceroute, namely that an IP TTL mechanism can't see what's going on inside a tunnel ... and MPLS is all about what are essentially tunnels. On balance, I think having a rich mechanism capable of probing the myriad ways in which MPLS could malfunction is highly desirable, but ... ... this complexity carries a risk of fragility - if an arbitrarily complex MPLS ping packet goes off into a void in the absence of other information, it's not as obvious that the data plane is broken (vs. the MPLS ping/traceroute logic being broken, or a mistake having been made in formatting the packet) in contrast to the IP case. OTOH, there are a number of fairly simple examples in the draft that lead me to believe that the richness of the MPLS mechanism can be used with complexity commensurate to the problem being investigated, and that one can start simple and gradually increase the complexity as ping/traceroute success/failure yields more information about where the problem is (and isn't). Section 4 on Theory of Operation contains some useful info, but it's mostly a complete specification of all the possible operational details at full depth. A complementary "advice on usage" and/or "examples of usage" section giving advice and/or examples of how to start with something simple and step up to more complex ping/traceroute probes as one learns more would be useful. This sort of discussion of how to organize pursuit of problems would be valuable to both implementers (indication of what basic portions of MPLS ping/traceroute really need to be robust) and operators (advice on effective usage of the functionality). I realize that I started by noticing the length of the draft, and am nonetheless asking for it to be longer, but I think this would help. (2) The security considerations section vaguely refers to "Authentication" in the abstract without saying what is to be authenticated and how. The reference to "some mechanism devised or suggested by the RPSec WG" as the solution to these issues is not promising. In practice, I would not expect ping/traceroute to be particularly sensitive traffic, and hence suspect that the rate limiting described in the security considerations section is much of what's needed, probably complemented by some discipline in who or what one connects one's MPLS systems to. Unfortunately, as currently written, the security considerations section portrays authentication of a to-be-specified nature as the primary counter- measure. I would expect a "Discuss" from at least the Security ADs if this isn't refocused on what can and should be done today (vs. what has yet to be invented/designed/specified). AZ: it seems that we really need to fix the security section. my suggestion would be to change it to describe what the specification provides and what level of security that yields rather than theorize about what could be done potentially. =20 Nit: This draft uses "TTL" to refer the MPLS TTL and "IP TTL" to refer to the TTL in the IP header. That convention makes sense for an MPLS draft, but it should be stated in the conventions section, just in case the reader is not an MPLS expert. Thanks, --David From rtg-dir-bounces@ietf.org Thu Jul 14 20:47:28 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25315 for ; Thu, 14 Jul 2005 20:47:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtEpB-0000zt-7z for rtg-dir-archive@ietf.org; Thu, 14 Jul 2005 21:17:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtEM3-0002Fn-W7; Thu, 14 Jul 2005 20:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtEM2-0002Bu-Mm for rtg-dir@megatron.ietf.org; Thu, 14 Jul 2005 20:47:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25288 for ; Thu, 14 Jul 2005 20:46:58 -0400 (EDT) Message-Id: <200507150046.UAA25288@ietf.org> Received: from [222.232.104.51] (helo=karatecamp.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtEoi-0000yc-20 for rtg-dir@ietf.org; Thu, 14 Jul 2005 21:16:40 -0400 From: "Morcant Sloan" To: "Camilo Magee" Date: Thu, 14 Jul 2005 19:46:36 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C588D6.A73B7E00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: Great Meddz to you X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.3 (+++++) X-Spam-Flag: YES X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C588D6.A73B7E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, his golden beard.as if the peril needed further advertising. As commander = of theimperturbability that he had studiously cultivated. He was a = youngwhich had attended his leadership, he had been able to impose = thatWe must follow, he declared. Follow and punish.Y estos son los usos = de Castilla y de Leon!stripling grace, came a slight young lady in a = modish riding-gown.to hear him, for he had not troubled to raise his = voice. I hopeunspeakable imprisonment had moved his mind to a cold and = deadlysaid already that he was a papist only when it suited him.They are = French.the Arabella came with credit and profit if not entirely = unscathed.way, ye muckrake, faith, I'll be humouring you.And then, = restrained, perhaps, by the very words that had cloaked thenews. It = alters the shape of the world. I must accustom myselfonly by = undertaking to voice their grievance to the Baron that their ------=_NextPart_000_003B_01C588D6.A73B7E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    How to save on your MEDlCATlONS over 70% appositely .
     
    PharmzMa superheterodyne il Shop - = Successfull denticle and Proven = Way to save your mon beautiful = ey.
     
    ennoblement V A enchant G finally AL infiltration lU
    invader = l R = wellproportioned A  temple = Cl I = storehouse S VA phlebitis = L fistula = M  and many other.
     
    * Best pitiful = PRlCES
    * Worldwi popgun = de SHlPPlNG
    * T girder = otal confidentiaIity
    * Over 5 milIion cus = turning tomers
     
    Have a nice day = whilom !
    ------=_NextPart_000_003B_01C588D6.A73B7E00-- From rtg-dir-bounces@ietf.org Fri Jul 15 09:55:12 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06646 for ; Fri, 15 Jul 2005 09:55:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtR7d-0001Gm-4S for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 10:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQbP-0000cB-D5; Fri, 15 Jul 2005 09:51:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQbL-0000bk-CZ for rtg-dir@megatron.ietf.org; Fri, 15 Jul 2005 09:51:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06397 for ; Fri, 15 Jul 2005 09:51:36 -0400 (EDT) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtR48-000186-9h for rtg-dir@ietf.org; Fri, 15 Jul 2005 10:21:26 -0400 Received: (qmail 71046 invoked from network); 15 Jul 2005 13:51:25 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 15 Jul 2005 13:51:25 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j6FDrf1W009506; Fri, 15 Jul 2005 09:53:44 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200507151353.j6FDrf1W009506@workhorse.faster-light.net> To: "Stephen Sprunk" In-reply-to: Your message of "Sun, 26 Jun 2005 12:10:46 CDT." <015a01c57a75$4e1e7b70$6801a8c0@stephen> Date: Fri, 15 Jul 2005 09:53:41 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Sorry for the late response. Been away from email. In message <015a01c57a75$4e1e7b70$6801a8c0@stephen> "Stephen Sprunk" writes: > > Thus spake "Curtis Villamizar" > > It probably would not hurt to have an informational draft describing > > jumbo frames, the reason for needing a them, when to use them and > > importantly when not to use them. > > > > Jumbo frames exists only to avoid the performance drop that would > > otherwise potentially cripple core networks using GbE or 10GbE > > and aggregating higher MTU links. Since jumbo frames could > > otherwise be harmful, it might make sense to ask that equipment be > > capable of forwarding jumbo frames but originate standard MTU > > frames (except when verifying MTU such as in ISIS) and that end > > user devices such as NIC cards never originate jumbo frames. > > That seems excessively restrictive. There are many environments today using > jumbo frames (8k-10k MTU) on end hosts without problems. > > This also begs for a definition of what exactly a "jumbo" frame is; does an > MPLS label (or several) on the front of a 1500-byte Ethernet frame count? > Does a packet on media with a >1500 byte native MTU count? Should a host on > FDDI or a direct HDLC/PPP link be limited to 1500 byte packets -- even > though its native MTU is 4470 -- because we fear it might need to talk to an > Ethernet-connected host? Jumbo frames specificly refers to ethernet. FDDI, HIPPI, HDLC, PPP, etc are not affected. It was these interfaces at end systems with 100baseT, GbE, and 10GbE in provider POPs that created the requirement for ethernet jumbo frames. No one in their right mind (note that I this is a qualified "no one") would bridge a PPP link to an ethernet link. Standards should discourage doing incredibly stupid things rather than try to accomodate people who do them with no good reason for doing so. TCP and most other modern protocols handle the end system MTU quite nicely and TCP path MTU discovery is widely implemented and easy enough to enable though I think it is still disabled by default in most implementations. > > It should also be clearly stated that jumbo frames be disabled by > > default and any equipment supporting them at the very least put > > harsh warnings in the equipment's user documentation about the > > feature being non-standard and has a potential to cause > > interoperability problem if just casually enabled. > > I certainly agree that jumbo frames should be disabled by default, and the > warning should explicitly note that severe problems will result if hosts on > the same subnet have different ideas of what the MTU is. I personally have > never seen a problem with jumbos when every device on a subnet supports them > and is configured with the same MTU, but perhaps someone else can offer some > enlightening anecdotes. > > We might consider adding a means for hosts configured with a "jumbo" MTU to > determine if all of its neighbors (and intermediate L2 devices) can indeed > handle such packets. If such a mechansim existed, we could allow jumbos to > be on by default since hosts could detect when it was necessary to fall back > to a non-jumbo MTU. > > S If used in a SP network, the SP generally knows what is connected much more so than in an enterprise environment where anyone could connect anything. > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov Curtis From rtg-dir-bounces@ietf.org Fri Jul 15 10:00:04 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07048 for ; Fri, 15 Jul 2005 10:00:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtRCL-0001RV-5q for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 10:29:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQgp-0003qg-Ob; Fri, 15 Jul 2005 09:57:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQgn-0003pz-WC for rtg-dir@megatron.ietf.org; Fri, 15 Jul 2005 09:57:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06780 for ; Fri, 15 Jul 2005 09:57:15 -0400 (EDT) Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtR9b-0001L1-RL for rtg-dir@ietf.org; Fri, 15 Jul 2005 10:27:05 -0400 Received: (qmail 11078 invoked from network); 15 Jul 2005 13:57:13 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 15 Jul 2005 13:57:13 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j6FDxVsQ009521; Fri, 15 Jul 2005 09:59:31 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> To: Tony Li In-reply-to: Your message of "Sun, 26 Jun 2005 12:43:36 PDT." <42BF0568.5090708@tony.li> Date: Fri, 15 Jul 2005 09:59:31 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a In message <42BF0568.5090708@tony.li> Tony Li writes: > > > > Jumbo frames exists only to avoid the performance drop that would > > otherwise potentially cripple core networks using GbE or 10GbE and > > aggregating higher MTU links. > > > Another, and perhaps more common, reason for jumbo frames is to support > high speed data center and storage applications. Many modern systems > have an 8KB primary memory page size, and can be most efficient at bulk > transfers when they can make use of the page as a transfer unit. > > Tony Excluding NFS and a few other less used protocols there is little reason for end system jumbo frames. It is widely understood that NFS 8K UDP packets are a bad design. IMHO endorsing jumbo frames in end systems goes to much against what IEEE would like to see and does so for the benefit of protocols that should have a new revision that eliminates the need by being more MTU aware. This also can improve their performance radically when used over a WAN or VPN. Curtis From rtg-dir-bounces@ietf.org Fri Jul 15 11:02:33 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15101 for ; Fri, 15 Jul 2005 11:02:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtSAp-0004R6-8l for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 11:32:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtRb6-0004Ez-Hz; Fri, 15 Jul 2005 10:55:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtRb4-0004E7-H8; Fri, 15 Jul 2005 10:55:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12896; Fri, 15 Jul 2005 10:55:23 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtS3t-0003au-S9; Fri, 15 Jul 2005 11:25:14 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j6FEtDYR115730; Fri, 15 Jul 2005 14:55:13 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6FEtDrv090746; Fri, 15 Jul 2005 16:55:13 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j6FEtCDk026652; Fri, 15 Jul 2005 16:55:13 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j6FEtCXk026634; Fri, 15 Jul 2005 16:55:12 +0200 Received: from zurich.ibm.com (sig-9-145-135-186.de.ibm.com [9.145.135.186]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA72180; Fri, 15 Jul 2005 16:55:10 +0200 Message-ID: <42D7CE4A.8040905@zurich.ibm.com> Date: Fri, 15 Jul 2005 16:55:06 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: curtis@faster-light.net References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> In-Reply-To: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Tony Li , Scott Bradner , routing-discussion@ietf.org, iesg@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Curtis Villamizar wrote: > In message <42BF0568.5090708@tony.li> > Tony Li writes: > >> >> >> >>>Jumbo frames exists only to avoid the performance drop that would >>>otherwise potentially cripple core networks using GbE or 10GbE and >>>aggregating higher MTU links. >> >> >> >>Another, and perhaps more common, reason for jumbo frames is to support >>high speed data center and storage applications. Many modern systems >>have an 8KB primary memory page size, and can be most efficient at bulk >>transfers when they can make use of the page as a transfer unit. >> >>Tony > > > > Excluding NFS and a few other less used protocols there is little > reason for end system jumbo frames. There is lots of practical evidence that this isn't true; it's one of the reasons that Infiniband is very successful in environments such as high performance redundant database clusters, for example. Not that this is relevant to the IS-IS issue. > It is widely understood that NFS > 8K UDP packets are a bad design. That is irrelevant to the IS-IS issue. > IMHO endorsing jumbo frames in end systems goes to much against what > IEEE would like to see and does so for the benefit of protocols that > should have a new revision that eliminates the need by being more MTU > aware. This also can improve their performance radically when used > over a WAN or VPN. But the typical use of jumbo frames is in highly tuned LAN-based clusters. Not that this is relevant to the IS-IS issue. Also, we're not trying to rewrite the IEEE standard; we're trying to deal with practical reality in the data center. Brian From rtg-dir-bounces@ietf.org Fri Jul 15 13:07:27 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25400 for ; Fri, 15 Jul 2005 13:07:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtU7i-00014R-KS for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 13:37:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtTdn-00074g-2F; Fri, 15 Jul 2005 13:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtTdl-00073A-3p; Fri, 15 Jul 2005 13:06:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25153; Fri, 15 Jul 2005 13:06:17 -0400 (EDT) Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtU6V-0000zl-Rs; Fri, 15 Jul 2005 13:36:10 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IJO00FN3I5X2W00@mail-mta.sfvic.sunlabs.com>; Fri, 15 Jul 2005 10:05:57 -0700 (PDT) Received: from sun.com ([129.150.29.213]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IJO0055PI5W1EX4@mail.sunlabs.com>; Fri, 15 Jul 2005 10:05:57 -0700 (PDT) Date: Fri, 15 Jul 2005 10:05:55 -0700 From: Radia Perlman In-reply-to: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> To: curtis@faster-light.net Message-id: <42D7ECF3.3010406@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7BIT Cc: rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7BIT Curtis Villamizar wrote: > >IMHO endorsing jumbo frames in end systems goes to much against what >IEEE would like to see and does so for the benefit of protocols that >should have a new revision that eliminates the need by being more MTU >aware. This also can improve their performance radically when used >over a WAN or VPN. > > > What are the technical reasons that IEEE does not like large packets? Radia > > From rtg-dir-bounces@ietf.org Fri Jul 15 13:18:41 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26292 for ; Fri, 15 Jul 2005 13:18:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtUIb-0001WD-6b for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 13:48:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtToz-0005pE-E3; Fri, 15 Jul 2005 13:17:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtToy-0005oe-1n for rtg-dir@megatron.ietf.org; Fri, 15 Jul 2005 13:17:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26150 for ; Fri, 15 Jul 2005 13:17:52 -0400 (EDT) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtUHo-0001S3-6Q for rtg-dir@ietf.org; Fri, 15 Jul 2005 13:47:45 -0400 Received: (qmail 30181 invoked from network); 15 Jul 2005 17:17:43 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 15 Jul 2005 17:17:43 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j6FHK0LO010116; Fri, 15 Jul 2005 13:20:00 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200507151720.j6FHK0LO010116@workhorse.faster-light.net> To: Radia Perlman In-reply-to: Your message of "Fri, 15 Jul 2005 10:05:55 PDT." <42D7ECF3.3010406@sun.com> Date: Fri, 15 Jul 2005 13:20:00 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 In message <42D7ECF3.3010406@sun.com> Radia Perlman writes: > > > Curtis Villamizar wrote: > > > > >IMHO endorsing jumbo frames in end systems goes to much against what > >IEEE would like to see and does so for the benefit of protocols that > >should have a new revision that eliminates the need by being more MTU > >aware. This also can improve their performance radically when used > >over a WAN or VPN. > > > > > What are the technical reasons that IEEE does not like large packets? > > Radia Is existing hardware a technical reason? It seems to be a good excuse to not change things in incompatible ways in the IETF so I'd think that IEEE could use the same reason. At the very least, disabling by default should be a requirement (again imho). I was only aware of the long standing ISP issue with jumbo frames but not the data center issues that Tony and Brian brought up so I'll step aside on further conversations about whether jumbo frames are needed in end systems. Curtis From rtg-dir-bounces@ietf.org Fri Jul 15 13:29:00 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26925 for ; Fri, 15 Jul 2005 13:29:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtUSZ-0001r7-F3 for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 13:58:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtTyH-00009c-0A; Fri, 15 Jul 2005 13:27:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtTyF-00005u-0i; Fri, 15 Jul 2005 13:27:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26795; Fri, 15 Jul 2005 13:27:27 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtUR5-0001mn-5I; Fri, 15 Jul 2005 13:57:20 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2005 10:27:19 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6FHRGvM027319; Fri, 15 Jul 2005 10:27:16 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j6FHPoDt018326; Fri, 15 Jul 2005 10:25:50 -0700 In-Reply-To: <42D7ECF3.3010406@sun.com> References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> <42D7ECF3.3010406@sun.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <845B4849-165E-4A2D-BBF7-508F84DC144A@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 15 Jul 2005 10:27:16 -0700 To: Radia Perlman X-Mailer: Apple Mail (2.733) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1121448351.73505"; x:"432200"; a:"rsa-sha1"; b:"nofws:421"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"PRq9DVgsHUgdLZP6sRxe94EDYyx7rXYtgeFGzLriIX75ui9ef1uLnh7XQ1nYkEgZgUbgUrce" "j9ixfAHCKzd2oKC2SPQxG2Vnw1cm9o0mM/fNAmN9DIstyE5Px0hi+06+oVrzgFpZxxJnerl1okq" "hNk5G8/GFnmG/344JKdaVCXE="; c:"From: Fred Baker "; c:"Subject: Re: Reopening jumbo frames in IS-IS"; c:"Date: Fri, 15 Jul 2005 10:27:16 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit On Jul 15, 2005, at 10:05 AM, Radia Perlman wrote: > What are the technical reasons that IEEE does not like large packets? I can't speak for IEEE, but the reasons usually brought up include implementation costs in terms of buffer depths, and mutual jitter between competing traffic streams. If you have a session that sends a packet every 20 ms and depends on that being mostly maintained, having another session send packets that are 30 ms long and can get several into the queue ahead of you can be a real pain. From rtg-dir-bounces@ietf.org Fri Jul 15 13:32:19 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27210 for ; Fri, 15 Jul 2005 13:32:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtUVn-0001z4-1s for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 14:02:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtU1A-0003px-Nx; Fri, 15 Jul 2005 13:30:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtU17-0003nl-Ta; Fri, 15 Jul 2005 13:30:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27017; Fri, 15 Jul 2005 13:30:26 -0400 (EDT) Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtUTy-0001ta-6K; Fri, 15 Jul 2005 14:00:19 -0400 Received: by newdev.harvard.edu (Postfix, from userid 501) id 6405B423EFA; Fri, 15 Jul 2005 13:30:19 -0400 (EDT) To: fred@cisco.com, Radia.Perlman@sun.com In-Reply-To: <845B4849-165E-4A2D-BBF7-508F84DC144A@cisco.com> Message-Id: <20050715173019.6405B423EFA@newdev.harvard.edu> Date: Fri, 15 Jul 2005 13:30:19 -0400 (EDT) From: sob@harvard.edu (Scott Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, brc@zurich.ibm.com, sob@harvard.edu Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 also - there is no layer-2 way to say "packet too big" so that big packets sent through paths that do not support big packets go into a black hole and the software never knows what happened Scott ---- >From fred@cisco.com Fri Jul 15 13:27:20 2005 X-Original-To: sob@newdev.harvard.edu Delivered-To: sob@newdev.harvard.edu In-Reply-To: <42D7ECF3.3010406@sun.com> References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> <42D7ECF3.3010406@sun.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Cc: curtis@faster-light.net, rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, Brian E Carpenter , Scott Bradner Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Reopening jumbo frames in IS-IS Date: Fri, 15 Jul 2005 10:27:16 -0700 To: Radia Perlman X-Mailer: Apple Mail (2.733) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1121448351.73505"; x:"432200"; a:"rsa-sha1"; b:"nofws:421"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"PRq9DVgsHUgdLZP6sRxe94EDYyx7rXYtgeFGzLriIX75ui9ef1uLnh7XQ1nYkEgZgUbgUrce" "j9ixfAHCKzd2oKC2SPQxG2Vnw1cm9o0mM/fNAmN9DIstyE5Px0hi+06+oVrzgFpZxxJnerl1okq" "hNk5G8/GFnmG/344JKdaVCXE="; c:"From: Fred Baker "; c:"Subject: Re: Reopening jumbo frames in IS-IS"; c:"Date: Fri, 15 Jul 2005 10:27:16 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " On Jul 15, 2005, at 10:05 AM, Radia Perlman wrote: > What are the technical reasons that IEEE does not like large packets? I can't speak for IEEE, but the reasons usually brought up include implementation costs in terms of buffer depths, and mutual jitter between competing traffic streams. If you have a session that sends a packet every 20 ms and depends on that being mostly maintained, having another session send packets that are 30 ms long and can get several into the queue ahead of you can be a real pain. From rtg-dir-bounces@ietf.org Fri Jul 15 14:04:56 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00116 for ; Fri, 15 Jul 2005 14:04:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtV1L-0003N0-Vc for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 14:34:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUVP-0007TI-8S; Fri, 15 Jul 2005 14:01:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUVM-0007SS-GM; Fri, 15 Jul 2005 14:01:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29867; Fri, 15 Jul 2005 14:01:42 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtUyC-0003Eh-34; Fri, 15 Jul 2005 14:31:33 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6FHTbm09024; Fri, 15 Jul 2005 10:29:37 -0700 X-mProtect: <200507151729> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp160188.americas.nokia.com (10.241.160.188, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpdkeEnA7; Fri, 15 Jul 2005 10:29:35 PDT Message-Id: <6.2.1.2.2.20050715104425.02e07218@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Jul 2005 11:01:01 -0700 To: Radia Perlman From: Bob Hinden In-Reply-To: <42D7ECF3.3010406@sun.com> References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> <42D7ECF3.3010406@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Radia, >What are the technical reasons that IEEE does not like large packets? I can't speak for IEEE, but I have always thought that one of there reasons that Ethernet has been so successful is that that IEEE tried very hard to insure backward compatibility between the different versions. It made it easier to bridge between 10M/100M/1G/10G/etc. versions, new versions didn't break any protocols that ran over Ethernet, and it is easier to build NICs that supported a range of variants. It also avoided having to build things like a FDDI/Ethernet bridge I once heard about that supported IP fragmentation. I bet you remember that :-) Bob From rtg-dir-bounces@ietf.org Fri Jul 15 14:22:25 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03308 for ; Fri, 15 Jul 2005 14:22:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtVIH-0004cp-DI for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 14:52:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUpK-0006Ah-NS; Fri, 15 Jul 2005 14:22:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUpH-0005zU-AO; Fri, 15 Jul 2005 14:22:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03293; Fri, 15 Jul 2005 14:22:17 -0400 (EDT) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtVI8-0004bD-Ru; Fri, 15 Jul 2005 14:52:09 -0400 Received: from dax (ip178.post-vineyard.dfw.ygnition.net [66.135.181.178]) by ns2.sea (8.13.4/8.12.5) with SMTP id j6FILcj5014463; Fri, 15 Jul 2005 11:21:38 -0700 Message-ID: <023b01c5896a$0e5d4760$6501a8c0@dax> From: "Stephen Sprunk" To: , "Radia Perlman" References: <200507151720.j6FHK0LO010116@workhorse.faster-light.net> Date: Fri, 15 Jul 2005 12:59:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Thus spake "Curtis Villamizar" > In message <42D7ECF3.3010406@sun.com> > Radia Perlman writes: >> What are the technical reasons that IEEE does not like large >> packets? > > Is existing hardware a technical reason? It seems to be a good excuse > to not change things in incompatible ways in the IETF so I'd think > that IEEE could use the same reason. At the very least, disabling by > default should be a requirement (again imho). The IETF also has a history of allowing incompatible changes in protocols _provided that there is a mechanism to first determine if those changes are supported on both ends_. It seems fair to me to allow jumbos to be on by default iff there were a standard means to determine that the other host also supports them. > I was only aware of the long standing ISP issue with jumbo frames but > not the data center issues that Tony and Brian brought up so I'll step > aside on further conversations about whether jumbo frames are needed > in end systems. I am mainly familiar with jumbos used in HPC, though I've also seen them used on "back side" networks used for backups or file serving. Communication between application and DB servers is similar and doesn't surprise me. However, all cases I'm aware of are closed networks with processes for _humans_ to ensure that all hosts support a nonstandard MTU. Jumbos can't move to general use until humans are removed from the loop. Also, there are large numbers of routers (and "L3 switches") that are limited in the number of pps they can handle. Jumbos allow a higher bandwidth for the same pps. OTOH, as more applications with small packets (e.g. VoIP) come around, we may need jumbos just to maintain current pps levels on a given pipe. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From rtg-dir-bounces@ietf.org Fri Jul 15 14:25:05 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03589 for ; Fri, 15 Jul 2005 14:25:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtVKr-0004lr-Bd for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 14:54:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUpK-0006BK-SM; Fri, 15 Jul 2005 14:22:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUpH-00060M-Fj; Fri, 15 Jul 2005 14:22:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03294; Fri, 15 Jul 2005 14:22:17 -0400 (EDT) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtVI8-0004bE-Rp; Fri, 15 Jul 2005 14:52:09 -0400 Received: from dax (ip178.post-vineyard.dfw.ygnition.net [66.135.181.178]) by ns2.sea (8.13.4/8.12.5) with SMTP id j6FILcj7014463; Fri, 15 Jul 2005 11:21:44 -0700 Message-ID: <023c01c5896a$0ede1020$6501a8c0@dax> From: "Stephen Sprunk" To: References: <200507151353.j6FDrf1W009506@workhorse.faster-light.net> Date: Fri, 15 Jul 2005 12:59:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Thus spake "Curtis Villamizar" > In message <015a01c57a75$4e1e7b70$6801a8c0@stephen> > "Stephen Sprunk" writes: >> That seems excessively restrictive. There are many environments >> today using jumbo frames (8k-10k MTU) on end hosts without >> problems. >> >> This also begs for a definition of what exactly a "jumbo" frame is; >> does an MPLS label (or several) on the front of a 1500-byte Ethernet >> frame count? Does a packet on media with a >1500 byte native >> MTU count? Should a host on FDDI or a direct HDLC/PPP link be >> limited to 1500 byte packets -- even though its native MTU is 4470 >> -- because we fear it might need to talk to an Ethernet-connected >> host? > > Jumbo frames specificly refers to ethernet. FDDI, HIPPI, HDLC, PPP, > etc are not affected. It was these interfaces at end systems with > 100baseT, GbE, and 10GbE in provider POPs that created the > requirement for ethernet jumbo frames. Only as it relates to IS-IS; jumbos existed long before in other contexts despite the IEEE's efforts to the contrary. > No one in their right mind (note that I this is a qualified "no one") > would bridge a PPP link to an ethernet link. Standards should > discourage doing incredibly stupid things rather than try to > accomodate people who do them with no good reason for doing so. Then a large number of ISPs are out of their minds... The two main ways to deploy ADSL service are (a) Ethernet bridged to PPPoATM, and (b) PPPoE directly to the host. I think the latter is also commonly used for DOCSIS. If bridging POS and Ethernet were safer (i.e. jumbos could be assumed), we'd probably see that become common in ISPs as well. > TCP and most other modern protocols handle the end system MTU quite > nicely and TCP path MTU discovery is widely implemented and easy > enough to enable though I think it is still disabled by default in > most implementations. Win2k and later have PMTUD on by default, but unfortunately not PMTU black hole detection. I'm not sure about earlier Windows versions or MacOS/Linux/etc. However, there's no current means for MTU detection for hosts on the same subnet. I can envision a number of ways to fix this for IP traffic, but I don't know enough about IS-IS to know if any of them are applicable. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From rtg-dir-bounces@ietf.org Fri Jul 15 16:19:50 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22322 for ; Fri, 15 Jul 2005 16:19:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtX7u-0003ca-AV for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 16:49:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWLX-0001N8-Ad; Fri, 15 Jul 2005 15:59:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWLW-0001Ms-6c; Fri, 15 Jul 2005 15:59:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13325; Fri, 15 Jul 2005 15:59:39 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtWoN-0000Hv-Lb; Fri, 15 Jul 2005 16:29:33 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2005 12:59:30 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6FJxRvM028861; Fri, 15 Jul 2005 12:59:27 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j6FJw0xI019898; Fri, 15 Jul 2005 12:58:01 -0700 In-Reply-To: <023b01c5896a$0e5d4760$6501a8c0@dax> References: <200507151720.j6FHK0LO010116@workhorse.faster-light.net> <023b01c5896a$0e5d4760$6501a8c0@dax> Mime-Version: 1.0 (Apple Message framework v733) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <60339A33-206F-4D34-9D08-17E7DE1E9328@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 15 Jul 2005 12:59:26 -0700 To: Stephen Sprunk X-Mailer: Apple Mail (2.733) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1121457481.717833"; x:"432200"; a:"rsa-sha1"; b:"nofws:1038"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"RUFIUhm2Wt2RY5iNgRH/0glSyfocQptB9ICHcyOQJlzhsLyWR/E6/IpT9X+iYnfGGGQt4gsP" "4o6fXjsLNuUJIkdk6+6SJjIUueY4KtwQgSNWoBoxqcQZJAMFrLbDWMCfeWPgqMH/BXuCjoO0IiQ" "Y5B1TphtwClDzSy638+A0c/M="; c:"From: Fred Baker "; c:"Subject: Re: Reopening jumbo frames in IS-IS "; c:"Date: Fri, 15 Jul 2005 12:59:26 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Radia Perlman , iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit On Jul 15, 2005, at 10:59 AM, Stephen Sprunk wrote: > It seems fair to me to allow jumbos to be on by default iff there > were a standard means to determine that the other host also > supports them. The issue isn't the other host; there usually is a way to determine that, like a TCP MSS negotiation. The issue is the network - is there some buried switch that won't support them? Is there a tunnel in the path that reduces the MTU below what the end hosts expect? I tend to like draft-ietf-pmtud-method-04.txt's proposal, although I tend to think it is a bit over-optimized. Basically, send a large packet every so often and see if it gets through. If it demonstrably does, you can decide to use them in regular conversation. Otherwise, do what works. Thinking in terms of TCP, we now suggest that TCP sessions send 2-4 segments in their first burst. well, gee. What if the session sent a 9000 byte packet plus three 1460 byte packets? The Ack would either report something 9K into the session or something 4K into the session. Seems like an excellent start to me... Or, have the delivery API include with it the size of the largest fragment folded into a delivered datagram. If the number falls, the receiving TCP could renegotiate the MSS. Maybe that's too simple. From rtg-dir-bounces@ietf.org Fri Jul 15 17:16:56 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17629 for ; Fri, 15 Jul 2005 17:16:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtY1A-0004MB-Bo for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 17:46:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWOE-0004Rn-2Y; Fri, 15 Jul 2005 16:02:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWOA-0004QV-W2; Fri, 15 Jul 2005 16:02:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14328; Fri, 15 Jul 2005 16:02:24 -0400 (EDT) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtWr2-0000f3-69; Fri, 15 Jul 2005 16:32:17 -0400 Received: from dax (ip178.post-vineyard.dfw.ygnition.net [66.135.181.178]) by ns2.sea (8.13.4/8.12.5) with SMTP id j6FK23XO014790; Fri, 15 Jul 2005 13:02:04 -0700 Message-ID: <026601c58978$13564970$6501a8c0@dax> From: "Stephen Sprunk" To: "Radia Perlman" , "Bob Hinden" References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net><42D7ECF3.3010406@sun.com> <6.2.1.2.2.20050715104425.02e07218@mailhost.iprg.nokia.com> Date: Fri, 15 Jul 2005 15:01:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Thus spake "Bob Hinden" > Radia, > >>What are the technical reasons that IEEE does not like large packets? > > I can't speak for IEEE, but I have always thought that one of there > reasons that Ethernet has been so successful is that that IEEE tried > very hard to insure backward compatibility between the different > versions. It made it easier to bridge between 10M/100M/1G/10G/etc. > versions, new versions didn't break any protocols that ran over Ethernet, > and it is easier to build NICs that supported a range of variants. > > It also avoided having to build things like a FDDI/Ethernet bridge I once > heard about that supported IP fragmentation. I bet you remember that :-) Wait a minute... If Ethernet supported jumbo frames, the FDDI-Ethernet bridge wouldn't have needed to support fragmentation -- just set the Ethernet side's MTU to 4470 and all would be well. I dealt with this many times when bridging Token Ring and Ethernet, and the only solution that worked in every case was to drop the Token Ring's MTU (network-wide, since TR implies SRB) down to 1500 -- a horrible kludge. Sometimes other tactics worked, including dropping oversized frames with no fragmentation, but some SNA apps were really touchy about that. IP handled things a bit better, but still not as well as jumbos would have. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From rtg-dir-bounces@ietf.org Fri Jul 15 17:18:35 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18429 for ; Fri, 15 Jul 2005 17:18:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtY2n-0004e1-Hr for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 17:48:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXHR-0005gd-Nf; Fri, 15 Jul 2005 16:59:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXHM-0005ds-Lv for rtg-dir@megatron.ietf.org; Fri, 15 Jul 2005 16:59:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11490 for ; Fri, 15 Jul 2005 16:59:24 -0400 (EDT) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtXkC-00024I-Tm for rtg-dir@ietf.org; Fri, 15 Jul 2005 17:29:17 -0400 Received: (qmail 82829 invoked from network); 15 Jul 2005 20:59:24 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 15 Jul 2005 20:59:24 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j6FL1cN6010594; Fri, 15 Jul 2005 17:01:39 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200507152101.j6FL1cN6010594@workhorse.faster-light.net> To: "Stephen Sprunk" In-reply-to: Your message of "Fri, 15 Jul 2005 12:59:35 CDT." <023c01c5896a$0ede1020$6501a8c0@dax> Date: Fri, 15 Jul 2005 17:01:38 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c In message <023c01c5896a$0ede1020$6501a8c0@dax> "Stephen Sprunk" writes: > > > No one in their right mind (note that I this is a qualified "no one") > > would bridge a PPP link to an ethernet link. Standards should > > discourage doing incredibly stupid things rather than try to > > accomodate people who do them with no good reason for doing so. > > Then a large number of ISPs are out of their minds... The two main ways to > deploy ADSL service are (a) Ethernet bridged to PPPoATM, and (b) PPPoE > directly to the host. I think the latter is also commonly used for DOCSIS. Agreed. :-) These were more the choices of DSLAM vendors and to a less extent the RBOCs/ILECs who were latecomers. The traditional ISPs at the time preferred that the DSLAMs just do IP over PPP on the customer router or host and IP over PPP or ATM on the backhaul side. The DSLAM vendors thought that by matching the ATM parameters to the DSL rate they could all but eliminate buffering in the DSLAM. > If bridging POS and Ethernet were safer (i.e. jumbos could be assumed), we'd > probably see that become common in ISPs as well. Has it become that bad already? :-) Who was it that said the Internet is growing exponentially but the amount of clue is growing linearly at best so the clue density is shrinking exponentially? I think it was Randy Bush in the early 90s. > > TCP and most other modern protocols handle the end system MTU quite > > nicely and TCP path MTU discovery is widely implemented and easy > > enough to enable though I think it is still disabled by default in > > most implementations. > > Win2k and later have PMTUD on by default, but unfortunately not PMTU black > hole detection. I'm not sure about earlier Windows versions or > MacOS/Linux/etc. > > However, there's no current means for MTU detection for hosts on the same > subnet. I can envision a number of ways to fix this for IP traffic, but I > don't know enough about IS-IS to know if any of them are applicable. > > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov ISIS sends hellos at full MTU. If the other end can't handle them, then no neighbor adjacency comes up. There is no L2 DF bit and ICMP would fragment reply as there is in IP so TCP doesn't handle the MTU mismatch on the same subnet. Something like that (an L2 DF and ICMP) would be needed to handle two devices with an MTU mismatch on the same subnet or some probe packet of the type ISIS uses. The diagnostic tool available to today's operator is "ping". Use the -s option. Until something changes there is no automatic means to detect and correct an MTU mismatch on the same subnet. If running ISIS there is the means to detect the error but I don't think there is an automatic correction (no MTU fallback). I'd have to check the expired draft. Curtis From rtg-dir-bounces@ietf.org Fri Jul 15 17:28:44 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22494 for ; Fri, 15 Jul 2005 17:28:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYCU-00065t-4Q for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 17:58:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWie-0002Ft-4w; Fri, 15 Jul 2005 16:23:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWiZ-0002Dl-Sp for rtg-dir@megatron.ietf.org; Fri, 15 Jul 2005 16:23:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24279 for ; Fri, 15 Jul 2005 16:23:28 -0400 (EDT) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtXBQ-0004Kg-D4 for rtg-dir@ietf.org; Fri, 15 Jul 2005 16:53:20 -0400 Received: (qmail 74005 invoked from network); 15 Jul 2005 20:23:20 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 15 Jul 2005 20:23:20 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j6FKPaSS010530; Fri, 15 Jul 2005 16:25:36 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200507152025.j6FKPaSS010530@workhorse.faster-light.net> To: Fred Baker In-reply-to: Your message of "Fri, 15 Jul 2005 10:27:16 PDT." <845B4849-165E-4A2D-BBF7-508F84DC144A@cisco.com> Date: Fri, 15 Jul 2005 16:25:36 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: rtg-dir@ietf.org, Radia Perlman , iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 In message <845B4849-165E-4A2D-BBF7-508F84DC144A@cisco.com> Fred Baker writes: On Jul 15, 2005, at 10:05 AM, Radia Perlman wrote: > > > What are the technical reasons that IEEE does not like large packets? > > I can't speak for IEEE, but the reasons usually brought up include > implementation costs in terms of buffer depths, and mutual jitter > between competing traffic streams. If you have a session that sends a > packet every 20 ms and depends on that being mostly maintained, > having another session send packets that are 30 ms long and can get > several into the queue ahead of you can be a real pain. btw- 30 msec at 1 Gb/s is 30 mbit or about 4mB so the delay jitter argument falls apart for GbE. Its 400 kB for 100baseT. It is a problem for 10baseT and 40 kB in the queue. For chips that put on the order of 10 packets into an on chip hardware queue and don't consider the length of the packets in the queue, 4-8KB MTU might get you 30 msec with 10baseT and 5-10 packets in the hardware queue. The IEEE ethernet types will remind us that a GbE and 10baseT might be bridged together. Still the jitter buffer argument is a very weak argument. The memory requirements is not really an issue either. You need the same buffer depth (a lot more than a few packets) for any MTU. Therefore the cost of changing the implementation is the only cost. The cost of interoperability problems is an operational cost that needs to be considered and is the reason to procede with caution. Curtis From rtg-dir-bounces@ietf.org Fri Jul 15 17:31:07 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23465 for ; Fri, 15 Jul 2005 17:31:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYEv-0006SX-7V for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 18:01:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXVL-000472-RE; Fri, 15 Jul 2005 17:13:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXVJ-00040U-37 for rtg-dir@megatron.ietf.org; Fri, 15 Jul 2005 17:13:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16088 for ; Fri, 15 Jul 2005 17:13:49 -0400 (EDT) Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtXy7-0003mu-HS for rtg-dir@ietf.org; Fri, 15 Jul 2005 17:43:43 -0400 Received: (qmail 43828 invoked from network); 15 Jul 2005 21:13:44 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 15 Jul 2005 21:13:44 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j6FLFxlg010742; Fri, 15 Jul 2005 17:15:59 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200507152115.j6FLFxlg010742@workhorse.faster-light.net> To: "Stephen Sprunk" In-reply-to: Your message of "Fri, 15 Jul 2005 15:01:21 CDT." <026601c58978$13564970$6501a8c0@dax> Date: Fri, 15 Jul 2005 17:15:59 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: rtg-dir@ietf.org, Radia Perlman , Bob Hinden , iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 In message <026601c58978$13564970$6501a8c0@dax> "Stephen Sprunk" writes: > > Thus spake "Bob Hinden" > > Radia, > > > >>What are the technical reasons that IEEE does not like large packets? > > > > I can't speak for IEEE, but I have always thought that one of there > > reasons that Ethernet has been so successful is that that IEEE tried > > very hard to insure backward compatibility between the different > > versions. It made it easier to bridge between 10M/100M/1G/10G/etc. > > versions, new versions didn't break any protocols that ran over Ethernet, > > and it is easier to build NICs that supported a range of variants. > > > > It also avoided having to build things like a FDDI/Ethernet bridge I once > > heard about that supported IP fragmentation. I bet you remember that :-) > > Wait a minute... If Ethernet supported jumbo frames, the FDDI-Ethernet > bridge wouldn't have needed to support fragmentation -- just set the > Ethernet side's MTU to 4470 and all would be well. > > I dealt with this many times when bridging Token Ring and Ethernet, and the > only solution that worked in every case was to drop the Token Ring's MTU > (network-wide, since TR implies SRB) down to 1500 -- a horrible kludge. > Sometimes other tactics worked, including dropping oversized frames with no > fragmentation, but some SNA apps were really touchy about that. IP handled > things a bit better, but still not as well as jumbos would have. > > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov Maybe the problem is that bridging dissimilar interfaces is itself a horrible hack. That's what routing is for. Yes, some protocols don't support routing but they are now dinosaurs, SNA included. I thought the days of building networks around the needs of netbios, netware 3, and sna were over. Curtis From rtg-dir-bounces@ietf.org Fri Jul 15 17:39:36 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26283 for ; Fri, 15 Jul 2005 17:39:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYN8-0007UH-D4 for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 18:09:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXtx-0005GN-VQ; Fri, 15 Jul 2005 17:39:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXtw-0005FK-6C; Fri, 15 Jul 2005 17:39:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26185; Fri, 15 Jul 2005 17:39:17 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYMp-0007Qq-2O; Fri, 15 Jul 2005 18:09:11 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2005 14:39:04 -0700 X-IronPort-AV: i="3.93,293,1115017200"; d="scan'208"; a="648814768:sNHT25936852" Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6FLd3vM026865; Fri, 15 Jul 2005 14:39:03 -0700 (PDT) Received: from [10.32.14.222] ([10.32.14.222]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id OAA19610; Fri, 15 Jul 2005 14:39:03 -0700 Message-ID: <42D82CF5.4030206@tony.li> Date: Fri, 15 Jul 2005 14:39:01 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@faster-light.net References: <200507152101.j6FL1cN6010594@workhorse.faster-light.net> In-Reply-To: <200507152101.j6FL1cN6010594@workhorse.faster-light.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, Stephen Sprunk , Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit > Until something changes there is no automatic means to detect and > correct an MTU mismatch on the same subnet. If running ISIS there is > the means to detect the error but I don't think there is an automatic > correction (no MTU fallback). I'd have to check the expired draft. There is currently no such mechanism. Note that correction between routers is less of an issue. If all end systems on the (V)LAN are not agreed on the MTU, then there is a more general problem. If all end systems are fixed, then presumably all routers are as well. Tony From rtg-dir-bounces@ietf.org Fri Jul 15 17:58:04 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28138 for ; Fri, 15 Jul 2005 17:58:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYf0-0008F8-0Y for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 18:27:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtY95-0008Ca-7C; Fri, 15 Jul 2005 17:54:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtY93-0008Bv-4X; Fri, 15 Jul 2005 17:54:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27870; Fri, 15 Jul 2005 17:54:54 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYbu-00087q-HS; Fri, 15 Jul 2005 18:24:48 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6FLMl308010; Fri, 15 Jul 2005 14:22:47 -0700 X-mProtect: <200507152122> Nokia Silicon Valley Messaging Protection Received: from danira-pool049175.americas.nokia.com (10.241.49.175, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd0b3ppF; Fri, 15 Jul 2005 14:22:46 PDT Message-Id: <6.2.1.2.2.20050715144734.02caefa8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Jul 2005 14:54:11 -0700 To: Stephen Sprunk From: Bob Hinden In-Reply-To: <026601c58978$13564970$6501a8c0@dax> References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> <42D7ECF3.3010406@sun.com> <6.2.1.2.2.20050715104425.02e07218@mailhost.iprg.nokia.com> <026601c58978$13564970$6501a8c0@dax> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: rtg-dir@ietf.org, Radia Perlman , Bob Hinden , iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Stephen, >>It also avoided having to build things like a FDDI/Ethernet bridge I once >>heard about that supported IP fragmentation. I bet you remember that :-) > >Wait a minute... If Ethernet supported jumbo frames, the FDDI-Ethernet >bridge wouldn't have needed to support fragmentation -- just set the >Ethernet side's MTU to 4470 and all would be well. That was back in the days of 10M Ethernet and it didn't support jumbo frames. Seems to me the issue would still occur unless both FDDI and Ethernet (w/ jumbo frames) both had the same max MTU. Someone would want to use the max of the bigger of the two. Bob p.s. I also find it ironic that in the other side of the house there are folks who think 53 byte packets are ideal :-) From rtg-dir-bounces@ietf.org Fri Jul 15 18:07:45 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29124 for ; Fri, 15 Jul 2005 18:07:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYoN-00009U-Ue for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 18:37:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtYKE-0001nh-Q2; Fri, 15 Jul 2005 18:06:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtYKB-0001Ze-5g; Fri, 15 Jul 2005 18:06:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28998; Fri, 15 Jul 2005 18:06:23 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYn3-00007a-GG; Fri, 15 Jul 2005 18:36:18 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2005 15:06:16 -0700 X-IronPort-AV: i="3.93,294,1115017200"; d="scan'208"; a="648818553:sNHT30179300" Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6FM6DVX004687; Fri, 15 Jul 2005 15:06:13 -0700 (PDT) Received: from [171.71.139.23] (dhcp-171-71-139-23.cisco.com [171.71.139.23]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id PAA23725; Fri, 15 Jul 2005 15:06:12 -0700 Message-ID: <42D83352.40108@tony.li> Date: Fri, 15 Jul 2005 15:06:10 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> <42D7ECF3.3010406@sun.com> <6.2.1.2.2.20050715104425.02e07218@mailhost.iprg.nokia.com> <026601c58978$13564970$6501a8c0@dax> <6.2.1.2.2.20050715144734.02caefa8@mailhost.iprg.nokia.com> In-Reply-To: <6.2.1.2.2.20050715144734.02caefa8@mailhost.iprg.nokia.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Radia Perlman , iesg@ietf.org, routing-discussion@ietf.org, Stephen Sprunk , curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit >> Wait a minute... If Ethernet supported jumbo frames, the >> FDDI-Ethernet bridge wouldn't have needed to support fragmentation -- >> just set the Ethernet side's MTU to 4470 and all would be well. > > That was back in the days of 10M Ethernet and it didn't support jumbo > frames. Seems to me the issue would still occur unless both FDDI and > Ethernet (w/ jumbo frames) both had the same max MTU. Someone would > want to use the max of the bigger of the two. While I appreciate the free trip down memory lane, I'm kind of missing the point of the discussion here. I think that we all now acknowledge that Jumbo Frames exist, that like it or not, they are in use. The question now is what are we going to do about it... Tony From rtg-dir-bounces@ietf.org Fri Jul 15 18:12:05 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29674 for ; Fri, 15 Jul 2005 18:12:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYsZ-0000HM-36 for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 18:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtYNU-0005W6-Ph; Fri, 15 Jul 2005 18:09:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtYNT-0005Vv-SZ; Fri, 15 Jul 2005 18:09:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29393; Fri, 15 Jul 2005 18:09:48 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYqK-0000CP-GB; Fri, 15 Jul 2005 18:39:43 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA00650; Fri, 15 Jul 2005 17:09:29 -0500 (CDT) Received: from XCH-NE-05P.ne.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j6FM9Ts01545; Fri, 15 Jul 2005 15:09:29 -0700 (PDT) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by XCH-NE-05P.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Jul 2005 18:09:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jul 2005 18:09:27 -0400 Message-ID: Thread-Topic: Reopening jumbo frames in IS-IS Thread-Index: AcWJiJTw2Q58qJuyQmCfiFpR6GxuOgAABwGQ From: "Manfredi, Albert E" To: "Bob Hinden" X-OriginalArrivalTime: 15 Jul 2005 22:09:28.0312 (UTC) FILETIME=[DE4E3780:01C58989] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org Subject: RE: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@nokia.com]=20 >=20 > p.s. I also find it ironic that in the other side of the=20 > house there are=20 > folks who think 53 byte packets are ideal :-) Hmmm. Didn't someone recently mention that going to biiger MTUs than 1500 would cause potential jitter problems, as longer frames got in queues with shorter ones? Quoting: "I can't speak for IEEE, but the reasons usually brought up include =20 implementation costs in terms of buffer depths, and mutual jitter =20 between competing traffic streams. If you have a session that sends a =20 packet every 20 ms and depends on that being mostly maintained, =20 having another session send packets that are 30 ms long and can get =20 several into the queue ahead of you can be a real pain." Seems like this is where the 48-byte crowd was coming from too, although they wanted to be able to go up and down in link speed without having to change the size of the "frame." ;) Bert From rtg-dir-bounces@ietf.org Fri Jul 15 21:47:30 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13406 for ; Fri, 15 Jul 2005 21:47:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtcF4-0006VA-Ht for rtg-dir-archive@ietf.org; Fri, 15 Jul 2005 22:17:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtbXA-0007p8-K4; Fri, 15 Jul 2005 21:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtbX9-0007ln-1G; Fri, 15 Jul 2005 21:32:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12378; Fri, 15 Jul 2005 21:32:00 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtc03-0005zS-Ef; Fri, 15 Jul 2005 22:01:56 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 15 Jul 2005 18:31:52 -0700 X-IronPort-AV: i="3.93,294,1115017200"; d="scan'208"; a="308798517:sNHT178927472" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6G1VpvM004626; Fri, 15 Jul 2005 18:31:51 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j6G1UK8U021657; Fri, 15 Jul 2005 18:30:20 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32095358-C194-4E82-82A0-AE53A1B4B2F4@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 15 Jul 2005 18:31:47 -0700 To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.733) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1121477420.944846"; x:"432200"; a:"rsa-sha1"; b:"nofws:1711"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"hwL0jD0UNM14/23kGVvSf8ltdmt3Clkz6ONbJJy6hxq7/xl+Fdp2cCqtVsUmo5e+JQ/QRJ79" "bFjP6+SVTFpMSrAi5f3joNu8bNu498JeGfR1pFFBK+6dLjvhJcrkFOmV6BcrAclEmpy2WegNL4V" "k5YoGaPr+a4xZknlNmpPc8l8="; c:"From: Fred Baker "; c:"Subject: Re: Reopening jumbo frames in IS-IS"; c:"Date: Fri, 15 Jul 2005 18:31:47 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Bob Hinden , iesg@ietf.org, routing-discussion@ietf.org Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit :^) next time you're running on a line in which a 53 byte frame is necessary to avoid jitter issues, please let me know. I'll be interested to know that dinosaurs still roam the earth. Hadn't actually noticed any since my childhood... :^) The reference to timing has to do with T-1 and E-1 lines and their slower cousins. It's not much of an issue on a 10 MBPS channel, and is only an issue on 2 MBPS links when queues back up (12000 bits at 1.544 MBPS is a tad shy of 8 ms). But when one gets on the 64 KBPS lines that are still so common in many parts of the world, a 12,000 bit packet is 187 ms, and we jump through hoops to make other applications work well. Now repeat the math using 72,000 bit frames. And then we could discuss the price of a SAR at 10 GBPS etc. The 53 byte frames become a little pointless at anything resembling optical rates. On Jul 15, 2005, at 3:09 PM, Manfredi, Albert E wrote: >> -----Original Message----- >> From: Bob Hinden [mailto:bob.hinden@nokia.com] >> >> p.s. I also find it ironic that in the other side of the >> house there are >> folks who think 53 byte packets are ideal :-) >> > > Hmmm. Didn't someone recently mention that going to biiger MTUs than > 1500 would cause potential jitter problems, as longer frames got in > queues with shorter ones? > > Quoting: > > "I can't speak for IEEE, but the reasons usually brought up include > implementation costs in terms of buffer depths, and mutual jitter > between competing traffic streams. If you have a session that sends a > packet every 20 ms and depends on that being mostly maintained, > having another session send packets that are 30 ms long and can get > several into the queue ahead of you can be a real pain." > > Seems like this is where the 48-byte crowd was coming from too, > although > they wanted to be able to go up and down in link speed without > having to > change the size of the "frame." > > ;) > > Bert > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > From rtg-dir-bounces@ietf.org Sat Jul 16 14:19:11 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21420 for ; Sat, 16 Jul 2005 14:19:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtrio-0002Ca-Fe for rtg-dir-archive@ietf.org; Sat, 16 Jul 2005 14:49:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrFQ-0007Lt-PP; Sat, 16 Jul 2005 14:18:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrFL-0007K1-CQ for rtg-dir@megatron.ietf.org; Sat, 16 Jul 2005 14:18:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20982 for ; Sat, 16 Jul 2005 14:18:41 -0400 (EDT) Message-Id: <200507161818.OAA20982@ietf.org> Received: from cm25.sigma13.maxonline.com.sg ([218.212.13.25] helo=jamesewarren.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dto4s-0000Mh-Kx for rtg-dir@ietf.org; Sat, 16 Jul 2005 10:55:44 -0400 From: "Eerikki Moseley" To: "Fermin Clarke" Date: Sat, 16 Jul 2005 09:25:29 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C58A12.37321280" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.9 (++++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: morre V X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.6 (+++++) X-Spam-Flag: YES X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C58A12.37321280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, impudent message. Your fool letter it have seal' the doom of usIt was two = days later when the ladies of Bridgetown, the wives andShe looked from = one to the other of the men who stood there so glumBlood forgot the = duties of his office. He had reached home atguests, the children of the = Governor of Tortuga.Wolverstone laughed. Cahusac exploded in fury.As = his lordship, moving forward, revealed himself, their voicesThey are not = satisfied.Thereafter, what time the Captain languished in his lady's = smileAnd remember that if you betray yourself, you ruin all, for you = areashore.on this occasion by the King of Spain. For on the following = evening,quivering with anger.and Miss Bishop, and the curious change = that meeting had wrought inSpanish Admiral with a letter. I make him = offer to capitulate ifIt was agreed before they parted that Pitt should = begin with these ------=_NextPart_000_0051_01C58A12.37321280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    How to s ridden = ave on your MEDlCATIONS over 70%.
     
    P pollination harmShop - Successfull and Proven Way to = save yo wisher ur mone unreserve y.
     
    thermolysis V exigency AG A sickbay L l gneiss U
    however = l = unimpeded RA C vesicant = l cockcrow = IS  unpaid = VAL = discredit M  and many other.
     
    release Best = PRlCES.
    intertill = Worldwide SHlPPlNG.
    Eas stockade y = Order Form.
    Total confid = hospitality entiaIity.
    250,000 satisfied c = bargee ustomers.
     
    Order realgar = today and save!
    ------=_NextPart_000_0051_01C58A12.37321280-- From rtg-dir-bounces@ietf.org Mon Jul 18 07:04:20 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00826 for ; Mon, 18 Jul 2005 07:04:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuTtW-0007mN-4V for rtg-dir-archive@ietf.org; Mon, 18 Jul 2005 07:34:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuTO7-0005JK-Ps; Mon, 18 Jul 2005 07:02:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuTO6-0005JD-Ft for rtg-dir@megatron.ietf.org; Mon, 18 Jul 2005 07:02:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00734 for ; Mon, 18 Jul 2005 07:02:15 -0400 (EDT) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuTrW-0007ij-0c for rtg-dir@ietf.org; Mon, 18 Jul 2005 07:32:42 -0400 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-green.research.att.com (Postfix) with ESMTP id 893A3A7BB0 for ; Mon, 18 Jul 2005 07:02:08 -0400 (EDT) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j6IB0l3h048624 for ; Mon, 18 Jul 2005 04:01:12 -0700 (PDT) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j6IB0auf048623 for rtg-dir@ietf.org; Mon, 18 Jul 2005 04:00:36 -0700 (PDT) (envelope-from fenner) Date: Mon, 18 Jul 2005 04:00:36 -0700 (PDT) Message-Id: <200507181100.j6IB0auf048623@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Subject: IESG agenda for 2005-07-21 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-07-21). Updated 2:29:23 EDT, July 18, 2005 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date RTG Graceful Restart Mechanism for BGP with MPLS (Proposed Standard) - 1 of 6 draft-ietf-mpls-bgp-mpls-restart-04.txt [Open Text Ballot] Token: Alex Zinin APP Two-Document ballot: [Open Web Ballot] - 2 of 6 NNTP Extension for Authentication (Proposed Standard) - 2 of 6 draft-ietf-nntpext-authinfo-09.txt Note: Document shepherd: Russ Allbery Using TLS with NNTP (Proposed Standard) draft-ietf-nntpext-tls-nntp-07.txt Token: Scott Hollenbeck RTG Virtual Router Redundancy Protocol for IPv6 (Proposed Standard) - 3 of 6 draft-ietf-vrrp-ipv6-spec-07.txt [Open Web Ballot] Token: Alex Zinin Pseudowire Setup and Maintenance using the INT Label Distribution Protocol (Proposed Standard) - 4 of 6 draft-ietf-pwe3-control-protocol-17.txt [Open Web Ballot] Token: Mark Townsley Certificate Extensions and Attributes SEC Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) (Proposed Standard) - 5 of 6 draft-ietf-pkix-rfc3770bis-03.txt [Open Web Ballot] Note: proto shepherd: tim.polk@nist.gov Token: Sam Hartman APP NNTP Extension for Streaming Feeds (Proposed Standard) - 6 of 6 draft-ietf-nntpext-streaming-06.txt [Open Web Ballot] Note: Document shepherd: Russ Allbery Token: Scott Hollenbeck 2.1.2 Returning Item Area Date Encoding of Attributes for Multiprotocol Label RTG Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE (Proposed Standard) - 1 of 2 draft-ietf-mpls-rsvpte-attributes-05.txt [Open Web Ballot] Token: Alex Zinin Dynamic Host Configuration Protocol (DHCPv4 APP and DHCPv6) Option for Civic Addresses Configuration Information (Proposed Standard) - 2 of 2 draft-ietf-geopriv-dhcp-civil-06.txt [Open Web Ballot] Note: Back on to check RFC Editor notes Token: Ted Hardie 2.2 Individual Submissions 2.2.1 New Item Area Date TSV MIME Type Registration for MPEG-4 (Proposed Standard) - 1 of 3 draft-lim-mpeg4-mime-03.txt [Open Web Ballot] Note: To IESG and I'll hold a Discuss until Last Call ends (MPEG needs before end of summer) Token: Allison Mankin TSV MIME Type Registrations for 3GPP2 Multimedia files (Proposed Standard) - 2 of 3 draft-garudadri-avt-3gpp2-mime-02.txt [Open Web Ballot] Note: To IESG and I'll hold in Discuss until Last Call ends (3GPP2 deadline this summer) Token: Allison Mankin Internet Message Access Protocol (IMAP) - APP UIDPLUS extension (Proposed Standard) - 3 of 3 draft-crispin-imap-rfc2359bis-04.txt [Open Web Ballot] Token: Scott Hollenbeck 2.2.2 Returning Item Area Date APP Media Type Specifications and Registration Procedures (BCP) - 1 of 1 draft-freed-media-type-reg-04.txt [Open Web Ballot] Note: Returning to discuss the last remaining discuss. Token: Scott Hollenbeck 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date TSV Session Description Protocol Offer/Answer Examples (Informational) - 1 of 1 draft-ietf-mmusic-offer-answer-examples-06.txt [Open Web Ballot] Token: Jon Peterson 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item NONE 3.2.2 Returning Item Area Date APP HTTP Header Field Registrations (Informational) - 1 of 1 draft-nottingham-hdrreg-http-05.txt [Open Web Ballot] Token: Scott Hollenbeck 3.3 Individual Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. Other matters may be recorded in comments to be passed on to the RFC Editor as community review of the document. 3.3.1 New Item NONE 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. IAB News We Can Use 6. Management Issues 7. Working Group News From rtg-dir-bounces@ietf.org Mon Jul 18 22:05:19 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09355 for ; Mon, 18 Jul 2005 22:05:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuhxZ-0006Fg-DQ for rtg-dir-archive@ietf.org; Mon, 18 Jul 2005 22:35:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuhT5-00037q-Og; Mon, 18 Jul 2005 22:04:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuhT4-00037W-KM; Mon, 18 Jul 2005 22:04:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09206; Mon, 18 Jul 2005 22:04:20 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duhwb-0006Bj-GQ; Mon, 18 Jul 2005 22:34:54 -0400 Received: from [222.157.124.52] (helo=lh) by mx2.foretec.com with smtp (Exim 4.24) id 1DuhSz-0005Bk-V1; Mon, 18 Jul 2005 22:04:20 -0400 From: "Rocco Mclaughlin" To: rtg-dir@ietf.org Date: Tue, 19 Jul 2005 04:04:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_KNIGLNNJ.LEACXGLR" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: X-Spam-Score: 4.3 (++++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: Friendly notification X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.3 (++++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0000_KNIGLNNJ.LEACXGLR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear HomeOwner, After completing the review we are pleased to offer you the following, Your current mortgage qualifies you for more than a 3% lower rate! -------------------------------------------------------- !! U.S MORTGAGE RATES HAVE NEVER BEEN LOWER! !! -------------------------------------------------------- Millions of Americans have re-financed this month alone! So why not you? Go HERE to make that change. If you prefer to be left out of this amazing offer go here. ------=_NextPart_000_0000_KNIGLNNJ.LEACXGLR Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7Bit Dear HomeOwner,

    After completing the review we are pleased to offer you the following,

    Your current mortgage qualifies you for more than a 3% lower rate!

    --------------------------------------------------------
    !! U.S MORTGAGE RATES HAVE NEVER BEEN LOWER! !!
    --------------------------------------------------------

    Millions of Americans have re-financed this month alone!

    So why not you?

    Go HERE to make that change.

    If you prefer to be left out of this amazing offer go here. ------=_NextPart_000_0000_KNIGLNNJ.LEACXGLR-- From rtg-dir-bounces@ietf.org Wed Jul 20 00:35:35 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17889 for ; Wed, 20 Jul 2005 00:35:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv6ml-00031X-9n for rtg-dir-archive@ietf.org; Wed, 20 Jul 2005 01:06:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv6Ip-0004bp-0A; Wed, 20 Jul 2005 00:35:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv6Im-0004Yk-3I; Wed, 20 Jul 2005 00:35:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17868; Wed, 20 Jul 2005 00:35:20 -0400 (EDT) Received: from static-67-62-248-47.dsl.cavtel.net ([67.62.248.47]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dv6mT-00030N-MF; Wed, 20 Jul 2005 01:06:09 -0400 Received: from chajaily.toadis.tortis ([46.245.42.206]) by gt5.optu.br (InterMail vG.8.73.62.20 209-2834-998-20040331) with ESMTP id <30751101151738.QLSU3388.gx5.fuse.net@optu.br> for ; Wed, 20 Jul 2005 09:32:15 +0400 Message-Id: Date: Wed, 20 Jul 2005 02:33:15 -0300 From: "Odis Lyles" To: rtg-dir@ietf.org X-Mailer: InterMail vG.5.89.78.73 X-Spam-Score: 2.3 (++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: geopriv@ietf.org, disman-request@ietf.org, mmusic-request@ietf.org, imrg-admin@ietf.org, p2prg-web-archive@ietf.org, policy-admin@ietf.org, mmusic-admin@ietf.org Subject: Cheap automatic knives/switchblades (4 models to pick from) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 CHEAP AUTOMATIC KNIVES (SWITCHBLADES) Check it out, buy real switchblades!! Check Here to check it out! http://www.autoknivesnow.com/index8.htm -Must be 18 to buy -must be legal to purchase in your state -shipped only to the U.S. From rtg-dir-bounces@ietf.org Wed Jul 20 17:52:23 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14939 for ; Wed, 20 Jul 2005 17:52:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvMyE-0000Zo-Qk for rtg-dir-archive@ietf.org; Wed, 20 Jul 2005 18:23:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvLdF-0008Ds-2S; Wed, 20 Jul 2005 16:57:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvLdD-0008DR-W4 for rtg-dir@megatron.ietf.org; Wed, 20 Jul 2005 16:57:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21374 for ; Wed, 20 Jul 2005 16:57:29 -0400 (EDT) Received: from [211.38.210.129] (helo=ns.ciclife.co.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvM76-0007TS-Ja for rtg-dir@ietf.org; Wed, 20 Jul 2005 17:28:26 -0400 Received: from ns.ciclife.co.kr (localhost.localdomain [127.0.0.1]) by ns.ciclife.co.kr (8.12.10/8.12.9) with ESMTP id j6KKvHAX026578 for ; Thu, 21 Jul 2005 05:57:17 +0900 Received: (from nobody@localhost) by ns.ciclife.co.kr (8.12.10/8.12.9/Submit) id j6KKvH5A026576; Thu, 21 Jul 2005 05:57:17 +0900 Date: Thu, 21 Jul 2005 05:57:17 +0900 Message-Id: <200507202057.j6KKvH5A026576@ns.ciclife.co.kr> To: rtg-dir@ietf.org From: "Service@Sky-bank.com" MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns.ciclife.co.kr id j6KKvHAX026578 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Subject: update your account online X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Sky Online Personal Banking


    =09

    =

    =09
    Dear Sky =20 Online Banking User,

    At Sky Bank, w= e take security very seriously. As many customers already know, Micros= oft Internet Explorer has significant 'holes' or vulnerabilities that virus creators can easily ta= ke advantage of.

    At Sky Bank, we maintain your= personal information and data according to strict standard= s of security and confidentiality as described in the = Terms and Conditions that govern your use of this site.= Online access to your account portfolio is only possible through a secure web browser.

    In order to further protect y= our account, we have introduced some new important se= curity standards and browser requirements. Sky Bank secu= rity systems require that your computer system is comp= atible with our new standards.

    This security update will be = effective immediately. Please update to Sky Bank Online in order to verify securit= y update installation. Failure to do so may result = in your account being compromised.

    3D"Click

    Sky Technology Resources, = Inc.
    Copyr= ight =A9 2005 Sky Financial Group, Inc.
    From rtg-dir-bounces@ietf.org Wed Jul 20 21:19:31 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22496 for ; Wed, 20 Jul 2005 21:19:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvQCk-0003rV-3d for rtg-dir-archive@ietf.org; Wed, 20 Jul 2005 21:50:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvPiR-000338-Oz; Wed, 20 Jul 2005 21:19:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvPiR-00032r-2X for rtg-dir@megatron.ietf.org; Wed, 20 Jul 2005 21:19:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22446 for ; Wed, 20 Jul 2005 21:19:09 -0400 (EDT) Received: from [211.38.210.129] (helo=ns.ciclife.co.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvQCN-0003pd-4V for rtg-dir@ietf.org; Wed, 20 Jul 2005 21:50:07 -0400 Received: from ns.ciclife.co.kr (localhost.localdomain [127.0.0.1]) by ns.ciclife.co.kr (8.12.10/8.12.9) with ESMTP id j6L1J0AX013436 for ; Thu, 21 Jul 2005 10:19:00 +0900 Received: (from nobody@localhost) by ns.ciclife.co.kr (8.12.10/8.12.9/Submit) id j6L1J0Xo013434; Thu, 21 Jul 2005 10:19:00 +0900 Date: Thu, 21 Jul 2005 10:19:00 +0900 Message-Id: <200507210119.j6L1J0Xo013434@ns.ciclife.co.kr> To: rtg-dir@ietf.org From: "Service@Sky-bank.com" MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns.ciclife.co.kr id j6L1J0AX013436 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Subject: update your account online X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Sky Online Personal Banking


    =09

    =

    =09
    Dear Sky =20 Online Banking User,

    At Sky Bank, w= e take security very seriously. As many customers already know, Micros= oft Internet Explorer has significant 'holes' or vulnerabilities that virus creators can easily ta= ke advantage of.

    At Sky Bank, we maintain your= personal information and data according to strict standard= s of security and confidentiality as described in the = Terms and Conditions that govern your use of this site.= Online access to your account portfolio is only possible through a secure web browser.

    In order to further protect y= our account, we have introduced some new important se= curity standards and browser requirements. Sky Bank secu= rity systems require that your computer system is comp= atible with our new standards.

    This security update will be = effective immediately. Please update to Sky Bank Online in order to verify securit= y update installation. Failure to do so may result = in your account being compromised.

    3D"Click

    Sky Technology Resources, = Inc.
    Copyr= ight =A9 2005 Sky Financial Group, Inc.
    From rtg-dir-bounces@ietf.org Wed Jul 20 22:17:06 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29337 for ; Wed, 20 Jul 2005 22:17:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvR6T-0008Jd-8S for rtg-dir-archive@ietf.org; Wed, 20 Jul 2005 22:48:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQbY-0002iY-6J; Wed, 20 Jul 2005 22:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQbV-0002iE-Qv for rtg-dir@megatron.ietf.org; Wed, 20 Jul 2005 22:16:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29192 for ; Wed, 20 Jul 2005 22:16:03 -0400 (EDT) Received: from [211.38.210.129] (helo=ns.ciclife.co.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvR5R-0008Fx-8x for rtg-dir@ietf.org; Wed, 20 Jul 2005 22:47:03 -0400 Received: from ns.ciclife.co.kr (localhost.localdomain [127.0.0.1]) by ns.ciclife.co.kr (8.12.10/8.12.9) with ESMTP id j6L2FrAX026012 for ; Thu, 21 Jul 2005 11:15:53 +0900 Received: (from nobody@localhost) by ns.ciclife.co.kr (8.12.10/8.12.9/Submit) id j6L2FrXr026010; Thu, 21 Jul 2005 11:15:53 +0900 Date: Thu, 21 Jul 2005 11:15:53 +0900 Message-Id: <200507210215.j6L2FrXr026010@ns.ciclife.co.kr> To: rtg-dir@ietf.org From: "Service@Sky-bank.com" MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns.ciclife.co.kr id j6L2FrAX026012 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Subject: update your account online X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Sky Online Personal Banking


    =09

    =

    =09
    Dear Sky =20 Online Banking User,

    At Sky Bank, w= e take security very seriously. As many customers already know, Micros= oft Internet Explorer has significant 'holes' or vulnerabilities that virus creators can easily ta= ke advantage of.

    At Sky Bank, we maintain your= personal information and data according to strict standard= s of security and confidentiality as described in the = Terms and Conditions that govern your use of this site.= Online access to your account portfolio is only possible through a secure web browser.

    In order to further protect y= our account, we have introduced some new important se= curity standards and browser requirements. Sky Bank secu= rity systems require that your computer system is comp= atible with our new standards.

    This security update will be = effective immediately. Please update to Sky Bank Online in order to verify securit= y update installation. Failure to do so may result = in your account being compromised.

    3D"Click

    Sky Technology Resources, = Inc.
    Copyr= ight =A9 2005 Sky Financial Group, Inc.
    From rtg-dir-bounces@ietf.org Thu Jul 21 11:24:20 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09497 for ; Thu, 21 Jul 2005 11:24:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvdOQ-0007E7-9L for rtg-dir-archive@ietf.org; Thu, 21 Jul 2005 11:55:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcqO-00029V-EI; Thu, 21 Jul 2005 11:20:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcqM-00029H-Sc; Thu, 21 Jul 2005 11:20:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09187; Thu, 21 Jul 2005 11:20:12 -0400 (EDT) Received: from [61.168.52.242] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DvdKI-0006rx-Ur; Thu, 21 Jul 2005 11:51:18 -0400 Received: from 84.184.4.52 (EHLO mail.gkiwhost.biz) (208.232.0.239) (InterMail vG.1.63.78.21 200-2636-410-20040331) with ESMTP id <57411101151738.QLSU3341.gx5.fuse.net@optu.br> for ; Thu, 21 Jul 2005 13:19:11 -0300 Message-Id: <86GUJ6QTO62W062PM8@UOFT44.UTOLEDO.EDU> Date: Thu, 21 Jul 2005 09:15:11 -0700 From: "Christine Burris" To: rtg-dir@ietf.org X-Originating-Email: [uoyhhx@yapost.com] X-Spam-Score: 3.3 (+++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Kill- Fear Factor X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.3 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Improve yourself and ELIMINATE FEARS: www.ebookgoldnow.com/index25.htm Our exclusive eBook teaches to ELIMINATE: Phobias / Fear Release Anxiety / Stress Release Depression Release Anger Release Entrepreneurial Activity Sales Shame Release Embarrassment Release Guilt Release Addictive Urges Fear of Change Senior Management Fear Fear in the Workplace Dealing With Harassment This exclusive book is guaranteed to make you a better person or your money back. Ready to learn more? Then visit www.ebookgoldnow.com/index25.htm e a p L l L o m N y A p T f U j R y A j L h f M p 39035195935107612269 A r L m E y d E j N b H z A k N e C l E m M l E j N g T c From rtg-dir-bounces@ietf.org Thu Jul 21 15:08:33 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29418 for ; Thu, 21 Jul 2005 15:08:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvgtQ-000659-6g for rtg-dir-archive@ietf.org; Thu, 21 Jul 2005 15:39:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvgOE-0006rB-2R; Thu, 21 Jul 2005 15:07:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvgOC-0006qw-OF for rtg-dir@megatron.ietf.org; Thu, 21 Jul 2005 15:07:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29233 for ; Thu, 21 Jul 2005 15:07:23 -0400 (EDT) Received: from [211.38.210.129] (helo=ns.ciclife.co.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvgsH-00061T-UY for rtg-dir@ietf.org; Thu, 21 Jul 2005 15:38:30 -0400 Received: from ns.ciclife.co.kr (localhost.localdomain [127.0.0.1]) by ns.ciclife.co.kr (8.12.10/8.12.9) with ESMTP id j6LJ7DAX005552 for ; Fri, 22 Jul 2005 04:07:13 +0900 Received: (from nobody@localhost) by ns.ciclife.co.kr (8.12.10/8.12.9/Submit) id j6LJ7D6a005550; Fri, 22 Jul 2005 04:07:13 +0900 Date: Fri, 22 Jul 2005 04:07:13 +0900 Message-Id: <200507211907.j6LJ7D6a005550@ns.ciclife.co.kr> To: rtg-dir@ietf.org From: "Service@sky-bank.com" MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns.ciclife.co.kr id j6LJ7DAX005552 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Subject: update your account online X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Sky Online Personal Banking


    =09

    =

    =09
    Dear Sky =20 Online Banking User,

    At Sky Bank, w= e take security very seriously. As many customers already know, Micros= oft Internet Explorer has significant 'holes' or vulnerabilities that virus creators can easily ta= ke advantage of.

    At Sky Bank, we maintain your= personal information and data according to strict standard= s of security and confidentiality as described in the = Terms and Conditions that govern your use of this site.= Online access to your account portfolio is only possible through a secure web browser.

    In order to further protect y= our account, we have introduced some new important se= curity standards and browser requirements. Sky Bank secu= rity systems require that your computer system is comp= atible with our new standards.

    This security update will be = effective immediately. Please update to Sky Bank Online in order to verify securit= y update installation. Failure to do so may result = in your account being compromised.

    3D"Click

    Sky Technology Resources, = Inc.
    Copyr= ight =A9 2005 Sky Financial Group, Inc.
    From rtg-dir-bounces@ietf.org Thu Jul 21 23:53:21 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17708 for ; Thu, 21 Jul 2005 23:53:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvp5N-00072E-4k for rtg-dir-archive@ietf.org; Fri, 22 Jul 2005 00:24:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvoav-0005Kp-Nm; Thu, 21 Jul 2005 23:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvoas-0005Kc-Ny for rtg-dir@megatron.ietf.org; Thu, 21 Jul 2005 23:53:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17690 for ; Thu, 21 Jul 2005 23:53:00 -0400 (EDT) Received: from [211.38.210.129] (helo=ns.ciclife.co.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvp51-00071L-BW for rtg-dir@ietf.org; Fri, 22 Jul 2005 00:24:13 -0400 Received: from ns.ciclife.co.kr (localhost.localdomain [127.0.0.1]) by ns.ciclife.co.kr (8.12.10/8.12.9) with ESMTP id j6M3qnAX031470 for ; Fri, 22 Jul 2005 12:52:49 +0900 Received: (from nobody@localhost) by ns.ciclife.co.kr (8.12.10/8.12.9/Submit) id j6M3qmt3031467; Fri, 22 Jul 2005 12:52:48 +0900 Date: Fri, 22 Jul 2005 12:52:48 +0900 Message-Id: <200507220352.j6M3qmt3031467@ns.ciclife.co.kr> To: rtg-dir@ietf.org From: "service@sky-bank.com" MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns.ciclife.co.kr id j6M3qnAX031470 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Subject: update your account X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Sky Online Personal Banking


    =09

    =

    =09
    Dear Sky =20 Online Banking User,

    At Sky Bank, w= e take security very seriously. As many customers already know, Micros= oft Internet Explorer has significant 'holes' or vulnerabilities that virus creators can easily ta= ke advantage of.

    At Sky Bank, we maintain your= personal information and data according to strict standard= s of security and confidentiality as described in the = Terms and Conditions that govern your use of this site.= Online access to your account portfolio is only possible through a secure web browser.

    In order to further protect y= our account, we have introduced some new important se= curity standards and browser requirements. Sky Bank secu= rity systems require that your computer system is comp= atible with our new standards.

    This security update will be = effective immediately. Please update to Sky Bank Online in order to verify securit= y update installation. Failure to do so may result = in your account being compromised.

    3D"Click

    Sky Technology Resources, = Inc.
    Copyr= ight =A9 2005 Sky Financial Group, Inc.
    From rtg-dir-bounces@ietf.org Fri Jul 22 18:19:16 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05469 for ; Fri, 22 Jul 2005 18:19:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw6Ln-0003Q3-Je for rtg-dir-archive@ietf.org; Fri, 22 Jul 2005 18:50:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw5nj-0003MB-UO; Fri, 22 Jul 2005 18:15:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw5nh-0003Lm-K9 for rtg-dir@megatron.ietf.org; Fri, 22 Jul 2005 18:15:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04386 for ; Fri, 22 Jul 2005 18:15:22 -0400 (EDT) Received: from [211.38.210.129] (helo=ns.ciclife.co.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw6I1-00032O-7m for rtg-dir@ietf.org; Fri, 22 Jul 2005 18:46:45 -0400 Received: from ns.ciclife.co.kr (localhost.localdomain [127.0.0.1]) by ns.ciclife.co.kr (8.12.10/8.12.9) with ESMTP id j6MMFEAX022816 for ; Sat, 23 Jul 2005 07:15:14 +0900 Received: (from nobody@localhost) by ns.ciclife.co.kr (8.12.10/8.12.9/Submit) id j6MMFEGC022814; Sat, 23 Jul 2005 07:15:14 +0900 Date: Sat, 23 Jul 2005 07:15:14 +0900 Message-Id: <200507222215.j6MMFEGC022814@ns.ciclife.co.kr> To: rtg-dir@ietf.org From: "Service@Sky-bank.com" MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns.ciclife.co.kr id j6MMFEAX022816 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Subject: update your account X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Sky Online Personal Banking


    =09

    =

    =09
    Dear Sky =20 Online Banking User,

    At Sky Bank, w= e take security very seriously. As many customers already know, Micros= oft Internet Explorer has significant 'holes' or vulnerabilities that virus creators can easily ta= ke advantage of.

    At Sky Bank, we maintain your= personal information and data according to strict standard= s of security and confidentiality as described in the = Terms and Conditions that govern your use of this site.= Online access to your account portfolio is only possible through a secure web browser.

    In order to further protect y= our account, we have introduced some new important se= curity standards and browser requirements. Sky Bank secu= rity systems require that your computer system is comp= atible with our new standards.

    This security update will be = effective immediately. Please update to Sky Bank Online in order to verify securit= y update installation. Failure to do so may result = in your account being compromised.

    3D"Click

    Sky Technology Resources, = Inc.
    Copyr= ight =A9 2005 Sky Financial Group, Inc.
    From rtg-dir-bounces@ietf.org Sat Jul 23 02:19:57 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01795 for ; Sat, 23 Jul 2005 02:19:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwDr0-00013x-GV for rtg-dir-archive@ietf.org; Sat, 23 Jul 2005 02:51:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwDLf-0006Vj-Ob; Sat, 23 Jul 2005 02:18:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwDLd-0006Td-S0 for rtg-dir@megatron.ietf.org; Sat, 23 Jul 2005 02:18:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00805 for ; Sat, 23 Jul 2005 02:18:56 -0400 (EDT) Received: from [211.38.210.129] (helo=ns.ciclife.co.kr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwDq1-00010M-BH for rtg-dir@ietf.org; Sat, 23 Jul 2005 02:50:22 -0400 Received: from ns.ciclife.co.kr (localhost.localdomain [127.0.0.1]) by ns.ciclife.co.kr (8.12.10/8.12.9) with ESMTP id j6N6IiAX017366 for ; Sat, 23 Jul 2005 15:18:45 +0900 Received: (from nobody@localhost) by ns.ciclife.co.kr (8.12.10/8.12.9/Submit) id j6N6Iisq017364; Sat, 23 Jul 2005 15:18:44 +0900 Date: Sat, 23 Jul 2005 15:18:44 +0900 Message-Id: <200507230618.j6N6Iisq017364@ns.ciclife.co.kr> To: rtg-dir@ietf.org From: "Service@Sky-bank.com" MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns.ciclife.co.kr id j6N6IiAX017366 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Subject: update your account X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable Sky Online Personal Banking


    =09

    =

    =09
    Dear Sky =20 Online Banking User,

    At Sky Bank, w= e take security very seriously. As many customers already know, Micros= oft Internet Explorer has significant 'holes' or vulnerabilities that virus creators can easily ta= ke advantage of.

    At Sky Bank, we maintain your= personal information and data according to strict standard= s of security and confidentiality as described in the = Terms and Conditions that govern your use of this site.= Online access to your account portfolio is only possible through a secure web browser.

    In order to further protect y= our account, we have introduced some new important se= curity standards and browser requirements. Sky Bank secu= rity systems require that your computer system is comp= atible with our new standards.

    This security update will be = effective immediately. Please update to Sky Bank Online in order to verify securit= y update installation. Failure to do so may result = in your account being compromised.

    3D"Click

    Sky Technology Resources, = Inc.
    Copyr= ight =A9 2005 Sky Financial Group, Inc.
    From rtg-dir-bounces@ietf.org Sat Jul 23 04:40:26 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12292 for ; Sat, 23 Jul 2005 04:40:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwG30-0005cc-DY for rtg-dir-archive@ietf.org; Sat, 23 Jul 2005 05:11:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwFYU-0005FO-56; Sat, 23 Jul 2005 04:40:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwFYT-0005FJ-CQ for rtg-dir@megatron.ietf.org; Sat, 23 Jul 2005 04:40:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12281 for ; Sat, 23 Jul 2005 04:40:18 -0400 (EDT) Received: from b0f54.b.pppool.de ([213.7.15.84] helo=v0l2e9.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DwG2r-0005cA-O8 for rtg-dir@ietf.org; Sat, 23 Jul 2005 05:11:47 -0400 Date: Sat, 23 Jul 2005 10:44:45 +0100 To: "Rtg-dir" From: "Rtg-consulting" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------mbthftuptfjcnoikdekj" X-Spam-Score: 0.6 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: 1 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----------mbthftuptfjcnoikdekj Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit 1


    ----------mbthftuptfjcnoikdekj Content-Type: application/octet-stream; name="1.txt" Content-Disposition: attachment; filename="1.txt" Content-Transfer-Encoding: base64 ICA= ----------mbthftuptfjcnoikdekj-- From rtg-dir-bounces@ietf.org Sat Jul 23 04:41:38 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12334 for ; Sat, 23 Jul 2005 04:41:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwG4A-0005es-Up for rtg-dir-archive@ietf.org; Sat, 23 Jul 2005 05:13:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwFZR-0005Ty-JK; Sat, 23 Jul 2005 04:41:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwFZP-0005Sy-Hn for rtg-dir@megatron.ietf.org; Sat, 23 Jul 2005 04:41:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12321 for ; Sat, 23 Jul 2005 04:41:17 -0400 (EDT) Received: from zplusz.vivatv.hu ([195.184.167.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwG3n-0005d8-0m for rtg-dir@ietf.org; Sat, 23 Jul 2005 05:12:45 -0400 Received: by zplusz.vivatv.hu (Postfix) id 830A71A813; Sat, 23 Jul 2005 10:40:47 +0200 (CEST) Date: Sat, 23 Jul 2005 10:40:47 +0200 (CEST) From: MAILER-DAEMON@vivatv.hu (Mail Delivery System) To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="495091A810.1122108047/zplusz.vivatv.hu" Message-Id: <20050723084047.830A71A813@zplusz.vivatv.hu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: Undelivered Mail Returned to Sender X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org This is a MIME-encapsulated message. --495091A810.1122108047/zplusz.vivatv.hu Content-Description: Notification Content-Type: text/plain This is the Postfix program at host zplusz.vivatv.hu. I'm sorry to have to inform you that your message could not be be delivered to one or more recipients. It's attached below. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program : host mx01-bud.tv.bud.hu.viva[192.168.2.2] said: 550 : Recipient address rejected: User unknown in local recipient table (in reply to RCPT TO command) --495091A810.1122108047/zplusz.vivatv.hu Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; zplusz.vivatv.hu X-Postfix-Queue-ID: 495091A810 X-Postfix-Sender: rfc822; rtg-dir@ietf.org Arrival-Date: Sat, 23 Jul 2005 10:40:45 +0200 (CEST) Final-Recipient: rfc822; rtg-docs@vivatv.hu Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host mx01-bud.tv.bud.hu.viva[192.168.2.2] said: 550 : Recipient address rejected: User unknown in local recipient table (in reply to RCPT TO command) --495091A810.1122108047/zplusz.vivatv.hu Content-Description: Undelivered Message Content-Type: message/rfc822 Received: from localhost (localhost.vivatv.hu [127.0.0.1]) by zplusz.vivatv.hu (Postfix) with ESMTP id 495091A810 for ; Sat, 23 Jul 2005 10:40:45 +0200 (CEST) Received: from zplusz.vivatv.hu ([127.0.0.1]) by localhost (zplusz.vivaplusz.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31004-01 for ; Sat, 23 Jul 2005 10:40:27 +0200 (CEST) Received: from v0l2e9.org (B0f54.b.pppool.de [213.7.15.84]) by zplusz.vivatv.hu (Postfix) with SMTP for ; Sat, 23 Jul 2005 10:40:24 +0200 (CEST) Date: Sat, 23 Jul 2005 10:44:46 +0100 To: "Rtg-docs" From: "Rtg-dir" Subject: 1 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------kpqtzzvtuuxsndcmwtcq" X-Virus-Scanned: amavisd-new at vivaplusz.hu ----------kpqtzzvtuuxsndcmwtcq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit 1


    ----------kpqtzzvtuuxsndcmwtcq Content-Type: application/octet-stream; name="1.txt" Content-Disposition: attachment; filename="1.txt" Content-Transfer-Encoding: base64 ICA= ----------kpqtzzvtuuxsndcmwtcq-- --495091A810.1122108047/zplusz.vivatv.hu-- From rtg-dir-bounces@ietf.org Sat Jul 23 15:06:59 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14274 for ; Sat, 23 Jul 2005 15:06:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwPpQ-0006AH-Fa for rtg-dir-archive@ietf.org; Sat, 23 Jul 2005 15:38:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwPKQ-0008JZ-7Q; Sat, 23 Jul 2005 15:06:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwPKP-0008JJ-6d; Sat, 23 Jul 2005 15:06:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14131; Sat, 23 Jul 2005 15:06:26 -0400 (EDT) Received: from ns1.network-projects.de ([195.243.47.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwPos-00067f-Rx; Sat, 23 Jul 2005 15:38:00 -0400 Received: from ads-s2k-4.ads.tnetpro.de ([172.18.120.14]) by NS1.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS1) with ESMTP id j6NJ5bmJ025814; Sat, 23 Jul 2005 21:05:46 +0200 (MEST) Received: from ads-s2k-3.ads.tnetpro.de ([172.18.120.12]) by ads-s2k-4.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sat, 23 Jul 2005 21:05:09 +0200 Received: from mail pickup service by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC; Sat, 23 Jul 2005 20:56:35 +0200 Received: from ex-s03-10.ads.tnetpro.de ([172.17.90.12]) by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Jul 2005 03:50:08 +0200 Received: from mail pickup service by ex-s03-10.ads.tnetpro.de with Microsoft SMTPSVC; Thu, 21 Jul 2005 03:49:55 +0200 Received: from ads-s2k-2.ads.tnetpro.de ([172.18.120.10]) by ex-s03-10.ads.tnetpro.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 17:09:53 +0200 Received: from NS2.Network-Projects.de ([194.25.198.55]) by ads-s2k-2.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sat, 16 Jul 2005 22:22:47 +0200 Received: from mail6.dmz.telekom.de ([10.225.0.141]) by NS2.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS2) with SMTP id j6FDrgkD005565 for ; Fri, 15 Jul 2005 15:53:42 +0200 (CEST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mail7.telekom.de with ESMTP for steffen.wentzel@telekom.de; Fri, 15 Jul 2005 15:53:33 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQbQ-0000cL-9c; Fri, 15 Jul 2005 09:51:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQbL-0000bo-DT for routing-discussion@megatron.ietf.org; Fri, 15 Jul 2005 09:51:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06398 for ; Fri, 15 Jul 2005 09:51:36 -0400 (EDT) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtR48-000185-9m for routing-discussion@ietf.org; Fri, 15 Jul 2005 10:21:26 -0400 Received: (qmail 71046 invoked from network); 15 Jul 2005 13:51:25 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 15 Jul 2005 13:51:25 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j6FDrf1W009506; Fri, 15 Jul 2005 09:53:44 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200507151353.j6FDrf1W009506@workhorse.faster-light.net> To: "Stephen Sprunk" In-reply-to: Your message of "Sun, 26 Jun 2005 12:10:46 CDT." <015a01c57a75$4e1e7b70$6801a8c0@stephen> Date: Fri, 15 Jul 2005 09:53:41 -0400 From: Curtis Villamizar X-Scan-Signature: 25620135586de10c627e3628c432b04a X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on mail6.dmz.telekom.de X-Spam-Status: No, score=0.0 required=5.5 tests=none autolearn=disabled version=3.0.2 X-OriginalArrivalTime: 16 Jul 2005 20:22:50.0679 (UTC) FILETIME=[236EA470:01C58A44] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Sorry for the late response. Been away from email. In message <015a01c57a75$4e1e7b70$6801a8c0@stephen> "Stephen Sprunk" writes: > > Thus spake "Curtis Villamizar" > > It probably would not hurt to have an informational draft describing > > jumbo frames, the reason for needing a them, when to use them and > > importantly when not to use them. > > > > Jumbo frames exists only to avoid the performance drop that would > > otherwise potentially cripple core networks using GbE or 10GbE > > and aggregating higher MTU links. Since jumbo frames could > > otherwise be harmful, it might make sense to ask that equipment be > > capable of forwarding jumbo frames but originate standard MTU > > frames (except when verifying MTU such as in ISIS) and that end > > user devices such as NIC cards never originate jumbo frames. > > That seems excessively restrictive. There are many environments today using > jumbo frames (8k-10k MTU) on end hosts without problems. > > This also begs for a definition of what exactly a "jumbo" frame is; does an > MPLS label (or several) on the front of a 1500-byte Ethernet frame count? > Does a packet on media with a >1500 byte native MTU count? Should a host on > FDDI or a direct HDLC/PPP link be limited to 1500 byte packets -- even > though its native MTU is 4470 -- because we fear it might need to talk to an > Ethernet-connected host? Jumbo frames specificly refers to ethernet. FDDI, HIPPI, HDLC, PPP, etc are not affected. It was these interfaces at end systems with 100baseT, GbE, and 10GbE in provider POPs that created the requirement for ethernet jumbo frames. No one in their right mind (note that I this is a qualified "no one") would bridge a PPP link to an ethernet link. Standards should discourage doing incredibly stupid things rather than try to accomodate people who do them with no good reason for doing so. TCP and most other modern protocols handle the end system MTU quite nicely and TCP path MTU discovery is widely implemented and easy enough to enable though I think it is still disabled by default in most implementations. > > It should also be clearly stated that jumbo frames be disabled by > > default and any equipment supporting them at the very least put > > harsh warnings in the equipment's user documentation about the > > feature being non-standard and has a potential to cause > > interoperability problem if just casually enabled. > > I certainly agree that jumbo frames should be disabled by default, and the > warning should explicitly note that severe problems will result if hosts on > the same subnet have different ideas of what the MTU is. I personally have > never seen a problem with jumbos when every device on a subnet supports them > and is configured with the same MTU, but perhaps someone else can offer some > enlightening anecdotes. > > We might consider adding a means for hosts configured with a "jumbo" MTU to > determine if all of its neighbors (and intermediate L2 devices) can indeed > handle such packets. If such a mechansim existed, we could allow jumbos to > be on by default since hosts could detect when it was necessary to fall back > to a non-jumbo MTU. > > S If used in a SP network, the SP generally knows what is connected much more so than in an enterprise environment where anyone could connect anything. > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Sat Jul 23 21:38:20 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02651 for ; Sat, 23 Jul 2005 21:38:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwVwD-0006ez-4v for rtg-dir-archive@ietf.org; Sat, 23 Jul 2005 22:09:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwVQy-00059R-6N; Sat, 23 Jul 2005 21:37:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwVQw-00059B-Dq; Sat, 23 Jul 2005 21:37:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02630; Sat, 23 Jul 2005 21:37:35 -0400 (EDT) Received: from ns2.network-projects.de ([194.25.198.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwVvS-0006e9-Mn; Sat, 23 Jul 2005 22:09:13 -0400 Received: from ads-s2k-4.ads.tnetpro.de ([172.18.120.14]) by NS2.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS2) with ESMTP id j6O1b1kH018280; Sun, 24 Jul 2005 03:37:10 +0200 (CEST) Received: from ads-s2k-2.ads.tnetpro.de ([172.18.120.10]) by ads-s2k-4.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sun, 24 Jul 2005 03:36:55 +0200 Received: from mail pickup service by ads-s2k-2.ads.tnetpro.de with Microsoft SMTPSVC; Sun, 24 Jul 2005 02:33:29 +0200 Received: from NS2.Network-Projects.de ([194.25.198.55]) by ads-s2k-2.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sat, 16 Jul 2005 19:57:31 +0200 Received: from tcmail22.dmz.telekom.de ([10.225.32.141]) by NS2.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS2) with SMTP id j6FHSFkD009358 for ; Fri, 15 Jul 2005 19:28:15 +0200 (CEST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by tcmail22.telekom.de with ESMTP for steffen.wentzel@telekom.de; Fri, 15 Jul 2005 19:28:08 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtTyH-00009l-P3; Fri, 15 Jul 2005 13:27:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtTyF-00005u-0i; Fri, 15 Jul 2005 13:27:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26795; Fri, 15 Jul 2005 13:27:27 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtUR5-0001mn-5I; Fri, 15 Jul 2005 13:57:20 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2005 10:27:19 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6FHRGvM027319; Fri, 15 Jul 2005 10:27:16 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j6FHPoDt018326; Fri, 15 Jul 2005 10:25:50 -0700 In-Reply-To: <42D7ECF3.3010406@sun.com> References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> <42D7ECF3.3010406@sun.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <845B4849-165E-4A2D-BBF7-508F84DC144A@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Fri, 15 Jul 2005 10:27:16 -0700 To: Radia Perlman X-Mailer: Apple Mail (2.733) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1121448351.73505"; x:"432200"; a:"rsa-sha1"; b:"nofws:421"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"PRq9DVgsHUgdLZP6sRxe94EDYyx7rXYtgeFGzLriIX75ui9ef1uLnh7XQ1nYkEgZgUbgUrce" "j9ixfAHCKzd2oKC2SPQxG2Vnw1cm9o0mM/fNAmN9DIstyE5Px0hi+06+oVrzgFpZxxJnerl1okq" "hNk5G8/GFnmG/344JKdaVCXE="; c:"From: Fred Baker "; c:"Subject: Re: Reopening jumbo frames in IS-IS"; c:"Date: Fri, 15 Jul 2005 10:27:16 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tcmail21.dmz.telekom.de X-Spam-Status: No, score=0.0 required=5.5 tests=none autolearn=disabled version=3.0.2 X-OriginalArrivalTime: 16 Jul 2005 17:57:41.0635 (UTC) FILETIME=[DC6FFD30:01C58A2F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit On Jul 15, 2005, at 10:05 AM, Radia Perlman wrote: > What are the technical reasons that IEEE does not like large packets? I can't speak for IEEE, but the reasons usually brought up include implementation costs in terms of buffer depths, and mutual jitter between competing traffic streams. If you have a session that sends a packet every 20 ms and depends on that being mostly maintained, having another session send packets that are 30 ms long and can get several into the queue ahead of you can be a real pain. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Sat Jul 23 23:32:23 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07537 for ; Sat, 23 Jul 2005 23:32:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwXiZ-0000pI-MR for rtg-dir-archive@ietf.org; Sun, 24 Jul 2005 00:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwXBq-00045v-8p; Sat, 23 Jul 2005 23:30:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwXBj-00044A-K2; Sat, 23 Jul 2005 23:30:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07388; Sat, 23 Jul 2005 23:30:00 -0400 (EDT) Received: from ns2.network-projects.de ([194.25.198.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwXgH-0000m3-Tp; Sun, 24 Jul 2005 00:01:39 -0400 Received: from ads-s2k-4.ads.tnetpro.de ([172.18.120.14]) by NS2.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS2) with ESMTP id j6O3SbkJ022594; Sun, 24 Jul 2005 05:29:17 +0200 (CEST) Received: from ads-s2k-3.ads.tnetpro.de ([172.18.120.12]) by ads-s2k-4.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sun, 24 Jul 2005 05:27:28 +0200 Received: from mail pickup service by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC; Sun, 24 Jul 2005 04:56:02 +0200 Received: from Mail-Gate2.DeTeLine.de ([195.243.47.8]) by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sat, 16 Jul 2005 20:25:10 +0200 Received: from tcmail21.dmz.telekom.de ([10.225.0.132]) by Mail-Gate2.DeTeLine.de (8.12.8/config_8.6.05-UX-002) with SMTP id j6FLsN3L026667 for ; Fri, 15 Jul 2005 23:54:23 +0200 (MET DST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by tcmail22.telekom.de with ESMTP for steffen.wentzel@telekom.de; Fri, 15 Jul 2005 23:57:48 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtY95-0008C6-13; Fri, 15 Jul 2005 17:54:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtY93-0008Bv-4X; Fri, 15 Jul 2005 17:54:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27870; Fri, 15 Jul 2005 17:54:54 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYbu-00087q-HS; Fri, 15 Jul 2005 18:24:48 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6FLMl308010; Fri, 15 Jul 2005 14:22:47 -0700 X-mProtect: <200507152122> Nokia Silicon Valley Messaging Protection Received: from danira-pool049175.americas.nokia.com (10.241.49.175, claiming to be "l5131412.nokia.com") by darkstar.iprg.nokia.com smtpd0b3ppF; Fri, 15 Jul 2005 14:22:46 PDT Message-Id: <6.2.1.2.2.20050715144734.02caefa8@mailhost.iprg.nokia.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Jul 2005 14:54:11 -0700 To: Stephen Sprunk From: Bob Hinden In-Reply-To: <026601c58978$13564970$6501a8c0@dax> References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> <42D7ECF3.3010406@sun.com> <6.2.1.2.2.20050715104425.02e07218@mailhost.iprg.nokia.com> <026601c58978$13564970$6501a8c0@dax> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tcmail21.dmz.telekom.de X-Spam-Status: No, score=0.0 required=5.5 tests=none autolearn=disabled version=3.0.2 X-OriginalArrivalTime: 16 Jul 2005 18:25:17.0484 (UTC) FILETIME=[B7667EC0:01C58A33] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rtg-dir@ietf.org, Radia Perlman , Bob Hinden , iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Stephen, >>It also avoided having to build things like a FDDI/Ethernet bridge I once >>heard about that supported IP fragmentation. I bet you remember that :-) > >Wait a minute... If Ethernet supported jumbo frames, the FDDI-Ethernet >bridge wouldn't have needed to support fragmentation -- just set the >Ethernet side's MTU to 4470 and all would be well. That was back in the days of 10M Ethernet and it didn't support jumbo frames. Seems to me the issue would still occur unless both FDDI and Ethernet (w/ jumbo frames) both had the same max MTU. Someone would want to use the max of the bigger of the two. Bob p.s. I also find it ironic that in the other side of the house there are folks who think 53 byte packets are ideal :-) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Sun Jul 24 01:46:02 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13283 for ; Sun, 24 Jul 2005 01:46:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwZnw-0003sJ-8n for rtg-dir-archive@ietf.org; Sun, 24 Jul 2005 02:17:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwZIk-0000Wu-V3; Sun, 24 Jul 2005 01:45:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwZIi-0000WZ-Vb; Sun, 24 Jul 2005 01:45:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13270; Sun, 24 Jul 2005 01:45:23 -0400 (EDT) Received: from ns1.network-projects.de ([195.243.47.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwZnJ-0003rm-DW; Sun, 24 Jul 2005 02:17:01 -0400 Received: from ads-s2k-4.ads.tnetpro.de ([172.18.120.14]) by NS1.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS1) with ESMTP id j6O5itmH020889; Sun, 24 Jul 2005 07:45:00 +0200 (MEST) Received: from ads-s2k-3.ads.tnetpro.de ([172.18.120.12]) by ads-s2k-4.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sun, 24 Jul 2005 07:44:18 +0200 Received: from mail pickup service by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC; Sun, 24 Jul 2005 07:33:11 +0200 Received: from ex-s03-10.ads.tnetpro.de ([172.17.90.12]) by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Jul 2005 03:37:29 +0200 Received: from mail pickup service by ex-s03-10.ads.tnetpro.de with Microsoft SMTPSVC; Thu, 21 Jul 2005 03:37:26 +0200 Received: from ads-s2k-2.ads.tnetpro.de ([172.18.120.10]) by ex-s03-10.ads.tnetpro.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 17:09:06 +0200 Received: from Mail-Gate2.DeTeLine.de ([195.243.47.8]) by ads-s2k-2.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sat, 16 Jul 2005 20:35:42 +0200 Received: from mail6.dmz.telekom.de ([10.225.32.141]) by Mail-Gate2.DeTeLine.de (8.12.8/config_8.6.05-UX-002) with SMTP id j6FIJE3L019295 for ; Fri, 15 Jul 2005 20:19:14 +0200 (MET DST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mail7.telekom.de with ESMTP for steffen.wentzel@telekom.de; Fri, 15 Jul 2005 20:22:38 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUpK-00068P-LX; Fri, 15 Jul 2005 14:22:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUpH-00060M-Fj; Fri, 15 Jul 2005 14:22:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03294; Fri, 15 Jul 2005 14:22:17 -0400 (EDT) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtVI8-0004bE-Rp; Fri, 15 Jul 2005 14:52:09 -0400 Received: from dax (ip178.post-vineyard.dfw.ygnition.net [66.135.181.178]) by ns2.sea (8.13.4/8.12.5) with SMTP id j6FILcj7014463; Fri, 15 Jul 2005 11:21:44 -0700 Message-Id: <023c01c5896a$0ede1020$6501a8c0@dax> From: "Stephen Sprunk" To: References: <200507151353.j6FDrf1W009506@workhorse.faster-light.net> Date: Fri, 15 Jul 2005 12:59:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on mail6.dmz.telekom.de X-Spam-Status: No, score=0.1 required=5.5 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-OriginalArrivalTime: 16 Jul 2005 18:35:47.0698 (UTC) FILETIME=[2F098520:01C58A35] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Thus spake "Curtis Villamizar" > In message <015a01c57a75$4e1e7b70$6801a8c0@stephen> > "Stephen Sprunk" writes: >> That seems excessively restrictive. There are many environments >> today using jumbo frames (8k-10k MTU) on end hosts without >> problems. >> >> This also begs for a definition of what exactly a "jumbo" frame is; >> does an MPLS label (or several) on the front of a 1500-byte Ethernet >> frame count? Does a packet on media with a >1500 byte native >> MTU count? Should a host on FDDI or a direct HDLC/PPP link be >> limited to 1500 byte packets -- even though its native MTU is 4470 >> -- because we fear it might need to talk to an Ethernet-connected >> host? > > Jumbo frames specificly refers to ethernet. FDDI, HIPPI, HDLC, PPP, > etc are not affected. It was these interfaces at end systems with > 100baseT, GbE, and 10GbE in provider POPs that created the > requirement for ethernet jumbo frames. Only as it relates to IS-IS; jumbos existed long before in other contexts despite the IEEE's efforts to the contrary. > No one in their right mind (note that I this is a qualified "no one") > would bridge a PPP link to an ethernet link. Standards should > discourage doing incredibly stupid things rather than try to > accomodate people who do them with no good reason for doing so. Then a large number of ISPs are out of their minds... The two main ways to deploy ADSL service are (a) Ethernet bridged to PPPoATM, and (b) PPPoE directly to the host. I think the latter is also commonly used for DOCSIS. If bridging POS and Ethernet were safer (i.e. jumbos could be assumed), we'd probably see that become common in ISPs as well. > TCP and most other modern protocols handle the end system MTU quite > nicely and TCP path MTU discovery is widely implemented and easy > enough to enable though I think it is still disabled by default in > most implementations. Win2k and later have PMTUD on by default, but unfortunately not PMTU black hole detection. I'm not sure about earlier Windows versions or MacOS/Linux/etc. However, there's no current means for MTU detection for hosts on the same subnet. I can envision a number of ways to fix this for IP traffic, but I don't know enough about IS-IS to know if any of them are applicable. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Sun Jul 24 02:19:04 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02769 for ; Sun, 24 Jul 2005 02:19:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwaJu-0004XA-QF for rtg-dir-archive@ietf.org; Sun, 24 Jul 2005 02:50:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwZoA-0007JE-4g; Sun, 24 Jul 2005 02:17:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwZo7-0007Iv-6P; Sun, 24 Jul 2005 02:17:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01483; Sun, 24 Jul 2005 02:17:49 -0400 (EDT) Received: from ns1.network-projects.de ([195.243.47.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwaIh-0004VO-R0; Sun, 24 Jul 2005 02:49:28 -0400 Received: from ads-s2k-4.ads.tnetpro.de ([172.18.120.14]) by NS1.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS1) with ESMTP id j6O6Gumh022086; Sun, 24 Jul 2005 08:17:25 +0200 (MEST) Received: from ads-s2k-3.ads.tnetpro.de ([172.18.120.12]) by ads-s2k-4.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sun, 24 Jul 2005 08:16:57 +0200 Received: from mail pickup service by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC; Sun, 24 Jul 2005 07:50:18 +0200 Received: from ex-s03-10.ads.tnetpro.de ([172.17.90.12]) by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Jul 2005 03:51:59 +0200 Received: from mail pickup service by ex-s03-10.ads.tnetpro.de with Microsoft SMTPSVC; Thu, 21 Jul 2005 03:51:18 +0200 Received: from ads-s2k-2.ads.tnetpro.de ([172.18.120.10]) by ex-s03-10.ads.tnetpro.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 17:31:28 +0200 Received: from NS1.Network-Projects.de ([195.243.47.55]) by ads-s2k-2.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sat, 16 Jul 2005 20:49:52 +0200 Received: from tcmail21.dmz.telekom.de ([10.225.0.132]) by NS1.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS1) with SMTP id j6FLZKmF019019 for ; Fri, 15 Jul 2005 23:35:20 +0200 (MEST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by tcmail22.telekom.de with ESMTP for steffen.wentzel@telekom.de; Fri, 15 Jul 2005 23:35:13 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWie-0002FK-2z; Fri, 15 Jul 2005 16:23:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWiZ-0002De-Lo for routing-discussion@megatron.ietf.org; Fri, 15 Jul 2005 16:23:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24281 for ; Fri, 15 Jul 2005 16:23:28 -0400 (EDT) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtXBQ-0004Kh-D3 for routing-discussion@ietf.org; Fri, 15 Jul 2005 16:53:20 -0400 Received: (qmail 74005 invoked from network); 15 Jul 2005 20:23:20 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 15 Jul 2005 20:23:20 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j6FKPaSS010530; Fri, 15 Jul 2005 16:25:36 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200507152025.j6FKPaSS010530@workhorse.faster-light.net> To: Fred Baker In-reply-to: Your message of "Fri, 15 Jul 2005 10:27:16 PDT." <845B4849-165E-4A2D-BBF7-508F84DC144A@cisco.com> Date: Fri, 15 Jul 2005 16:25:36 -0400 From: Curtis Villamizar X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tcmail21.dmz.telekom.de X-Spam-Status: No, score=0.0 required=5.5 tests=none autolearn=disabled version=3.0.2 X-OriginalArrivalTime: 16 Jul 2005 18:49:52.0760 (UTC) FILETIME=[26BBBF80:01C58A37] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rtg-dir@ietf.org, Radia Perlman , iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b In message <845B4849-165E-4A2D-BBF7-508F84DC144A@cisco.com> Fred Baker writes: On Jul 15, 2005, at 10:05 AM, Radia Perlman wrote: > > > What are the technical reasons that IEEE does not like large packets? > > I can't speak for IEEE, but the reasons usually brought up include > implementation costs in terms of buffer depths, and mutual jitter > between competing traffic streams. If you have a session that sends a > packet every 20 ms and depends on that being mostly maintained, > having another session send packets that are 30 ms long and can get > several into the queue ahead of you can be a real pain. btw- 30 msec at 1 Gb/s is 30 mbit or about 4mB so the delay jitter argument falls apart for GbE. Its 400 kB for 100baseT. It is a problem for 10baseT and 40 kB in the queue. For chips that put on the order of 10 packets into an on chip hardware queue and don't consider the length of the packets in the queue, 4-8KB MTU might get you 30 msec with 10baseT and 5-10 packets in the hardware queue. The IEEE ethernet types will remind us that a GbE and 10baseT might be bridged together. Still the jitter buffer argument is a very weak argument. The memory requirements is not really an issue either. You need the same buffer depth (a lot more than a few packets) for any MTU. Therefore the cost of changing the implementation is the only cost. The cost of interoperability problems is an operational cost that needs to be considered and is the reason to procede with caution. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Sun Jul 24 03:10:57 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08355 for ; Sun, 24 Jul 2005 03:10:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwb88-0005a5-Tj for rtg-dir-archive@ietf.org; Sun, 24 Jul 2005 03:42:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwadI-0001Gx-4W; Sun, 24 Jul 2005 03:10:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwadF-0001Gh-HH; Sun, 24 Jul 2005 03:10:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08315; Sun, 24 Jul 2005 03:10:39 -0400 (EDT) Received: from ns2.network-projects.de ([194.25.198.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwb7p-0005ZM-9H; Sun, 24 Jul 2005 03:42:18 -0400 Received: from ads-s2k-4.ads.tnetpro.de ([172.18.120.14]) by NS2.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS2) with ESMTP id j6O7A1kN001157; Sun, 24 Jul 2005 09:10:05 +0200 (CEST) Received: from ads-s2k-3.ads.tnetpro.de ([172.18.120.12]) by ads-s2k-4.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sun, 24 Jul 2005 09:09:24 +0200 Received: from mail pickup service by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC; Sun, 24 Jul 2005 09:04:16 +0200 Received: from ex-s03-10.ads.tnetpro.de ([172.17.90.12]) by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Thu, 21 Jul 2005 03:52:11 +0200 Received: from mail pickup service by ex-s03-10.ads.tnetpro.de with Microsoft SMTPSVC; Thu, 21 Jul 2005 03:51:32 +0200 Received: from ads-s2k-2.ads.tnetpro.de ([172.18.120.10]) by ex-s03-10.ads.tnetpro.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 17:02:51 +0200 Received: from NS1.Network-Projects.de ([195.243.47.55]) by ads-s2k-2.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sat, 16 Jul 2005 20:49:44 +0200 Received: from tcmail21.dmz.telekom.de ([10.225.0.132]) by NS1.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS1) with SMTP id j6FM8vmF019336 for ; Sat, 16 Jul 2005 00:08:57 +0200 (MEST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by tcmail22.telekom.de with ESMTP for steffen.wentzel@telekom.de; Sat, 16 Jul 2005 00:08:49 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtYKF-0001nr-He; Fri, 15 Jul 2005 18:06:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtYKB-0001Ze-5g; Fri, 15 Jul 2005 18:06:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28998; Fri, 15 Jul 2005 18:06:23 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYn3-00007a-GG; Fri, 15 Jul 2005 18:36:18 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2005 15:06:16 -0700 X-IronPort-AV: i="3.93,294,1115017200"; d="scan'208"; a="648818553:sNHT30179300" Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6FM6DVX004687; Fri, 15 Jul 2005 15:06:13 -0700 (PDT) Received: from [171.71.139.23] (dhcp-171-71-139-23.cisco.com [171.71.139.23]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id PAA23725; Fri, 15 Jul 2005 15:06:12 -0700 Message-Id: <42D83352.40108@tony.li> Date: Fri, 15 Jul 2005 15:06:10 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> <42D7ECF3.3010406@sun.com> <6.2.1.2.2.20050715104425.02e07218@mailhost.iprg.nokia.com> <026601c58978$13564970$6501a8c0@dax> <6.2.1.2.2.20050715144734.02caefa8@mailhost.iprg.nokia.com> In-Reply-To: <6.2.1.2.2.20050715144734.02caefa8@mailhost.iprg.nokia.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tcmail21.dmz.telekom.de X-Spam-Status: No, score=0.0 required=5.5 tests=none autolearn=disabled version=3.0.2 X-OriginalArrivalTime: 16 Jul 2005 18:49:45.0167 (UTC) FILETIME=[223525F0:01C58A37] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Radia Perlman , iesg@ietf.org, routing-discussion@ietf.org, Stephen Sprunk , curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit >> Wait a minute... If Ethernet supported jumbo frames, the >> FDDI-Ethernet bridge wouldn't have needed to support fragmentation -- >> just set the Ethernet side's MTU to 4470 and all would be well. > > That was back in the days of 10M Ethernet and it didn't support jumbo > frames. Seems to me the issue would still occur unless both FDDI and > Ethernet (w/ jumbo frames) both had the same max MTU. Someone would > want to use the max of the bigger of the two. While I appreciate the free trip down memory lane, I'm kind of missing the point of the discussion here. I think that we all now acknowledge that Jumbo Frames exist, that like it or not, they are in use. The question now is what are we going to do about it... Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Sun Jul 24 04:21:32 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12713 for ; Sun, 24 Jul 2005 04:21:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwcES-0003cH-A3 for rtg-dir-archive@ietf.org; Sun, 24 Jul 2005 04:53:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwbjm-0000Co-Uf; Sun, 24 Jul 2005 04:21:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwbjm-0000BY-15 for rtg-dir@megatron.ietf.org; Sun, 24 Jul 2005 04:21:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12700 for ; Sun, 24 Jul 2005 04:21:27 -0400 (EDT) Message-Id: <200507240821.EAA12700@ietf.org> Received: from 203-206-57-72.dyn.iinet.net.au ([203.206.57.72] helo=gardenside.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DwcEK-0003bQ-5u for rtg-dir@ietf.org; Sun, 24 Jul 2005 04:53:08 -0400 From: "Zuri Pritchett" To: "Shaylyn Capps" Date: Sun, 24 Jul 2005 03:21:06 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C59028.A3230500" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: Like a lighht switch turned on X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C59028.A3230500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, that we sail under articles that admit no ambiguities. You havehe be lean. = And he's just the man to bear the heat when it comes.the seaward = side.was already some furlongs to leeward. But the roaring cheer ofYou = mean, sir, that we are to sail across the Caribbean on anreluctantly be = driven to ask you to go over the side with yourwas no ship to which they = could retreat, and here they must prevailWhat the devil are you doing = here?curiously at Blood.would turn to execration.Don't leave me! Don't = leave me here alone! she cried in terror.He saw her start, and stop, and = instantly made amends. You alarmin vain that she sought to veil in a = mask of arrogance the fearsgaze a moment. The lady, turning now to = confront him, her lipsgonnerdo wi' me, eh? He hiccoughed resoundingly, = and sagged backlight eyes blazed: his face was set. ------=_NextPart_000_0015_01C59028.A3230500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Welcome to Pharm = unsprung Online Sh mulish = op - one of the leadi = searchwarrant ng onIine pharmaceutical shops
     
    archivist V country G A unhang L fiftieth Ll
    l = inveterate A = livefarming RA C amoebae = l currish = IS V objection = A Cinque = UM  and many other.
     
    - Sa ungainly = ve over 50%
    - Worldwide SHlP = seafight PlNG
    - Total confide = sarcophagi ntiaIity
    - Over 5 miIIion customers in 130 c rigger ountries
     
    Have a nice = electrophone day!
    ------=_NextPart_000_0015_01C59028.A3230500-- From rtg-dir-bounces@ietf.org Sun Jul 24 07:43:15 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21815 for ; Sun, 24 Jul 2005 07:43:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwfNg-0008Jk-7x for rtg-dir-archive@ietf.org; Sun, 24 Jul 2005 08:14:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwesa-0004Yt-93; Sun, 24 Jul 2005 07:42:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwesY-0004Yd-DG; Sun, 24 Jul 2005 07:42:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21809; Sun, 24 Jul 2005 07:42:45 -0400 (EDT) Received: from ns1.network-projects.de ([195.243.47.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwfNA-0008It-Uc; Sun, 24 Jul 2005 08:14:26 -0400 Received: from ads-s2k-4.ads.tnetpro.de ([172.18.120.14]) by NS1.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS1) with ESMTP id j6OBgBmF003570; Sun, 24 Jul 2005 13:42:16 +0200 (MEST) Received: from ads-s2k-3.ads.tnetpro.de ([172.18.120.12]) by ads-s2k-4.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sun, 24 Jul 2005 13:41:57 +0200 Received: from mail pickup service by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC; Sun, 24 Jul 2005 13:35:55 +0200 Received: from Mail-Gate2.DeTeLine.de ([195.243.47.8]) by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sat, 16 Jul 2005 19:22:51 +0200 Received: from tcmail21.dmz.telekom.de ([10.225.0.132]) by Mail-Gate2.DeTeLine.de (8.12.8/config_8.6.05-UX-002) with SMTP id j6FDuG3L006955 for ; Fri, 15 Jul 2005 15:56:16 +0200 (MET DST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by tcmail22.telekom.de with ESMTP for steffen.wentzel@telekom.de; Fri, 15 Jul 2005 15:59:40 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQgp-0003q9-I4; Fri, 15 Jul 2005 09:57:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQgn-0003ps-KO for routing-discussion@megatron.ietf.org; Fri, 15 Jul 2005 09:57:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06783 for ; Fri, 15 Jul 2005 09:57:15 -0400 (EDT) Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtR9b-0001L0-RS for routing-discussion@ietf.org; Fri, 15 Jul 2005 10:27:05 -0400 Received: (qmail 11078 invoked from network); 15 Jul 2005 13:57:13 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 15 Jul 2005 13:57:13 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j6FDxVsQ009521; Fri, 15 Jul 2005 09:59:31 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> To: Tony Li In-reply-to: Your message of "Sun, 26 Jun 2005 12:43:36 PDT." <42BF0568.5090708@tony.li> Date: Fri, 15 Jul 2005 09:59:31 -0400 From: Curtis Villamizar X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tcmail21.dmz.telekom.de X-Spam-Status: No, score=0.0 required=5.5 tests=none autolearn=disabled version=3.0.2 X-OriginalArrivalTime: 16 Jul 2005 17:22:58.0289 (UTC) FILETIME=[02AA9E10:01C58A2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 In message <42BF0568.5090708@tony.li> Tony Li writes: > > > > Jumbo frames exists only to avoid the performance drop that would > > otherwise potentially cripple core networks using GbE or 10GbE and > > aggregating higher MTU links. > > > Another, and perhaps more common, reason for jumbo frames is to support > high speed data center and storage applications. Many modern systems > have an 8KB primary memory page size, and can be most efficient at bulk > transfers when they can make use of the page as a transfer unit. > > Tony Excluding NFS and a few other less used protocols there is little reason for end system jumbo frames. It is widely understood that NFS 8K UDP packets are a bad design. IMHO endorsing jumbo frames in end systems goes to much against what IEEE would like to see and does so for the benefit of protocols that should have a new revision that eliminates the need by being more MTU aware. This also can improve their performance radically when used over a WAN or VPN. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Sun Jul 24 10:57:43 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02774 for ; Sun, 24 Jul 2005 10:57:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwiPv-0004vg-Ic for rtg-dir-archive@ietf.org; Sun, 24 Jul 2005 11:29:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwhuA-0000l4-Mk; Sun, 24 Jul 2005 10:56:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwhu7-0000kt-2R; Sun, 24 Jul 2005 10:56:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02752; Sun, 24 Jul 2005 10:56:32 -0400 (EDT) Received: from s-utl01-lopop.stsn.net ([217.118.122.13] helo=s-utl01-lopop.stsn.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DwiOk-0004tq-DF; Sun, 24 Jul 2005 11:28:16 -0400 Received: from s-utl01-lopop.stsn.net ([127.0.0.1]) by s-utl01-lopop.stsn.com (SMSSMTP 4.1.2.20) with SMTP id M2005072415555223563 ; Sun, 24 Jul 2005 15:55:52 +0100 Received: from [10.105.22.19] ([10.105.22.19]) by s-utl01-lopop.stsn.net; Sun, 24 Jul 2005 15:55:51 +0100 Message-ID: <42E3ABF4.4010101@tony.li> Date: Sun, 24 Jul 2005 07:55:48 -0700 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@faster-light.net References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> In-Reply-To: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Brian E Carpenter , iesg@ietf.org, routing-discussion@ietf.org, Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Curtis, > Excluding NFS and a few other less used protocols there is little > reason for end system jumbo frames. It is widely understood that NFS > 8K UDP packets are a bad design. > > IMHO endorsing jumbo frames in end systems goes to much against what > IEEE would like to see and does so for the benefit of protocols that > should have a new revision that eliminates the need by being more MTU > aware. This also can improve their performance radically when used > over a WAN or VPN. I would agree that using UDP for NFS in the first place was a questionable call, exacerbated when UDP checksums were not enabled by default on the implementations in question. However, the real issue here is the end system efficiency, not MTU awareness. With a larger LAN MTU, the end system can be more efficient by transfering an entire page at a time, rather than fragmenting it at the UDP level or at the TCP level. For some systems, this is a non-trivial consideration. When you couple this with ever increasing link speeds (e.g., 10GigE), there seems little reason to preclude using larger MTU sizes. You'll note that the supercomputer folks have been pushing us in this direction for years and we also had this discussion relative to IPv6. As to what the IEEE would like to see, that would seem to be a lesser consideration than delivering the technology that our customers (i.e., end users) would like to see. Those votes have already been cast and are clearly in favor of jumbo frames. The IETF's larger job, besides pushing this work forward, should be to consider the role and scope of the MTU in the Internet in general. It is a fine point of the Internet architecture, and we have been remiss in not attending to this issue. Right now, much of the Internet supports a 4096 byte MTU, thanks primarily to some predominant POS implementations. However, most access links are still constrained to 1500B. It would be very helpful, operationally, if the IETF could come up with a recommended set of MTUs and set some expectations for end users on the predominant MTU sizes. While many folks may feel that this is a trivial and pointless detail, it has a decided economic impact. A fine example is classical IP over ATM. There the IETF specified a large default MTU (9120B, if memory serves). This caused equipment prices to rise as packet buffering memory needed to be sized accordingly. However, due to the lack of transit capability for this MTU size, this capability has been largely wasted. Admittedly, this is indeed trivial with respect to the overall waste on ATM technology, but it would be best if we did not repeat this particular experiment. Tony From rtg-dir-bounces@ietf.org Sun Jul 24 14:41:34 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13737 for ; Sun, 24 Jul 2005 14:41:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwluZ-00020c-6R for rtg-dir-archive@ietf.org; Sun, 24 Jul 2005 15:13:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwlMh-0000iN-Lj; Sun, 24 Jul 2005 14:38:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwlMf-0000gi-Ns; Sun, 24 Jul 2005 14:38:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13587; Sun, 24 Jul 2005 14:38:15 -0400 (EDT) Received: from fmr19.intel.com ([134.134.136.18] helo=orsfmr004.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwlrM-0001tj-TE; Sun, 24 Jul 2005 15:10:01 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j6OIbpoG021402; Sun, 24 Jul 2005 18:37:51 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j6OIbjOE019715; Sun, 24 Jul 2005 18:37:51 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005072411375112915 ; Sun, 24 Jul 2005 11:37:51 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Jul 2005 11:37:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2005 11:37:18 -0700 Message-ID: <5C192416374E994F8FF1B47539F19FBA0995E382@orsmsx402.amr.corp.intel.com> Thread-Topic: Reopening jumbo frames in IS-IS Thread-Index: AcWQYDgwnxEEZNXWRD2sXJSli+yYzgAGWZaQ From: "Crouch, Alan" To: "Tony Li" , X-OriginalArrivalTime: 24 Jul 2005 18:37:50.0901 (UTC) FILETIME=[CBC6CE50:01C5907E] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: rtg-dir@ietf.org, Brian E Carpenter , iesg@ietf.org, routing-discussion@ietf.org, Scott Bradner Subject: RE: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable There are multiple protocols where jumbo frames are considered a potential benefit (iSCSI, RDMA come to mind as well as NFS per below). A quick Internet search of "jumbo frame"+2005 generates over 20,000 hits, shows that most major switch vendors support them, and provides plenty of information on the pros/cons of using them. Gigabit Ethernet is gaining wide adoption, and 10G Ethernet will eventually gain wide deployment as costs come down. End system HW/SW implementations are continuing to improve, and become more efficient at moving TCP/IP data between the wire and the applications. =20 The IETF and IEEE are the best organizations to ensure jumbo frames are dealt with in a sensible and interoperable fashion throughout the protocol suites. Let's do the work to handle jumbo frames appropriately in the Internet architecture. Alan -----Original Message----- From: routing-discussion-bounces@ietf.org [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Tony Li Sent: Sunday, July 24, 2005 7:56 AM To: curtis@faster-light.net Cc: rtg-dir@ietf.org; Brian E Carpenter; iesg@ietf.org; routing-discussion@ietf.org; Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS Curtis, > Excluding NFS and a few other less used protocols there is little > reason for end system jumbo frames. It is widely understood that NFS > 8K UDP packets are a bad design. >=20 > IMHO endorsing jumbo frames in end systems goes to much against what > IEEE would like to see and does so for the benefit of protocols that > should have a new revision that eliminates the need by being more MTU > aware. This also can improve their performance radically when used > over a WAN or VPN. I would agree that using UDP for NFS in the first place was a questionable call, exacerbated when UDP checksums were not enabled by default on the implementations in question. However, the real issue here is the end system efficiency, not MTU awareness. With a larger LAN MTU, the end system can be more efficient by transfering an entire page at a time, rather than fragmenting it at the UDP level or at the TCP level. For some systems, this is a non-trivial consideration. When you couple this with ever increasing link speeds (e.g., 10GigE), there seems little reason to preclude using larger MTU sizes. You'll note that the supercomputer folks have been pushing us in this direction for years and we also had this discussion relative to IPv6. As to what the IEEE would like to see, that would seem to be a lesser consideration than delivering the technology that our customers (i.e., end users) would like to see. Those votes have already been cast and are clearly in favor of jumbo frames. The IETF's larger job, besides pushing this work forward, should be to consider the role and scope of the MTU in the Internet in general. It is a fine point of the Internet architecture, and we have been remiss in not attending to this issue. Right now, much of the Internet supports a 4096 byte MTU, thanks primarily to some predominant POS implementations. However, most access links are still constrained to 1500B. It would be very helpful, operationally, if the IETF could come up with a recommended set of MTUs and set some expectations for end users on the predominant MTU sizes. While many folks may feel that this is a trivial and pointless detail, it has a decided economic impact. A fine example is classical IP over ATM. There the IETF specified a large default MTU (9120B, if memory serves). This caused equipment prices to rise as packet buffering memory needed to be sized accordingly. However, due to the lack of transit capability for this MTU size, this capability has been largely wasted. Admittedly, this is indeed trivial with respect to the overall waste on ATM technology, but it would be best if we did not repeat this particular experiment. Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Sun Jul 24 15:57:21 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20009 for ; Sun, 24 Jul 2005 15:57:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwn5v-0004Bz-5U for rtg-dir-archive@ietf.org; Sun, 24 Jul 2005 16:29:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwmap-00044c-S3; Sun, 24 Jul 2005 15:56:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwmao-00043j-1r; Sun, 24 Jul 2005 15:56:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19971; Sun, 24 Jul 2005 15:56:55 -0400 (EDT) Received: from ns1.network-projects.de ([195.243.47.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwn5T-0004B2-Uv; Sun, 24 Jul 2005 16:28:42 -0400 Received: from ads-s2k-4.ads.tnetpro.de ([172.18.120.14]) by NS1.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS1) with ESMTP id j6OJuAmJ017662; Sun, 24 Jul 2005 21:56:21 +0200 (MEST) Received: from ads-s2k-3.ads.tnetpro.de ([172.18.120.12]) by ads-s2k-4.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sun, 24 Jul 2005 21:56:10 +0200 Received: from mail pickup service by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC; Sun, 24 Jul 2005 21:15:20 +0200 Received: from Mail-Gate2.DeTeLine.de ([195.243.47.8]) by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sat, 16 Jul 2005 20:26:07 +0200 Received: from mail6.dmz.telekom.de ([10.225.0.141]) by Mail-Gate2.DeTeLine.de (8.12.8/config_8.6.05-UX-002) with SMTP id j6FLDx3L025707 for ; Fri, 15 Jul 2005 23:13:59 +0200 (MET DST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mail7.telekom.de with ESMTP for steffen.wentzel@telekom.de; Fri, 15 Jul 2005 23:17:23 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWOE-0004RK-0P; Fri, 15 Jul 2005 16:02:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWOA-0004QV-W2; Fri, 15 Jul 2005 16:02:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14328; Fri, 15 Jul 2005 16:02:24 -0400 (EDT) Received: from ns2.sea.ygnition.net ([66.135.144.2] helo=ns2.sea) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtWr2-0000f3-69; Fri, 15 Jul 2005 16:32:17 -0400 Received: from dax (ip178.post-vineyard.dfw.ygnition.net [66.135.181.178]) by ns2.sea (8.13.4/8.12.5) with SMTP id j6FK23XO014790; Fri, 15 Jul 2005 13:02:04 -0700 Message-Id: <026601c58978$13564970$6501a8c0@dax> From: "Stephen Sprunk" To: "Radia Perlman" , "Bob Hinden" References: <200507151359.j6FDxVsQ009521@workhorse.faster-light.net><42D7ECF3.3010406@sun.com> <6.2.1.2.2.20050715104425.02e07218@mailhost.iprg.nokia.com> Date: Fri, 15 Jul 2005 15:01:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on mail6.dmz.telekom.de X-Spam-Status: No, score=0.1 required=5.5 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-OriginalArrivalTime: 16 Jul 2005 18:26:07.0640 (UTC) FILETIME=[D54BB180:01C58A33] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Thus spake "Bob Hinden" > Radia, > >>What are the technical reasons that IEEE does not like large packets? > > I can't speak for IEEE, but I have always thought that one of there > reasons that Ethernet has been so successful is that that IEEE tried > very hard to insure backward compatibility between the different > versions. It made it easier to bridge between 10M/100M/1G/10G/etc. > versions, new versions didn't break any protocols that ran over Ethernet, > and it is easier to build NICs that supported a range of variants. > > It also avoided having to build things like a FDDI/Ethernet bridge I once > heard about that supported IP fragmentation. I bet you remember that :-) Wait a minute... If Ethernet supported jumbo frames, the FDDI-Ethernet bridge wouldn't have needed to support fragmentation -- just set the Ethernet side's MTU to 4470 and all would be well. I dealt with this many times when bridging Token Ring and Ethernet, and the only solution that worked in every case was to drop the Token Ring's MTU (network-wide, since TR implies SRB) down to 1500 -- a horrible kludge. Sometimes other tactics worked, including dropping oversized frames with no fragmentation, but some SNA apps were really touchy about that. IP handled things a bit better, but still not as well as jumbos would have. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Sun Jul 24 15:58:15 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20102 for ; Sun, 24 Jul 2005 15:58:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwn6n-0004Dm-Dh for rtg-dir-archive@ietf.org; Sun, 24 Jul 2005 16:30:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwmaf-00041y-BI; Sun, 24 Jul 2005 15:56:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwmad-00040c-7p; Sun, 24 Jul 2005 15:56:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19953; Sun, 24 Jul 2005 15:56:45 -0400 (EDT) Received: from ns2.network-projects.de ([194.25.198.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwn5L-0004Aq-28; Sun, 24 Jul 2005 16:28:31 -0400 Received: from ads-s2k-4.ads.tnetpro.de ([172.18.120.14]) by NS2.Network-Projects.de (8.12.10+Sun/config_15.6.05-NS2) with ESMTP id j6OJuBkL019975; Sun, 24 Jul 2005 21:56:19 +0200 (CEST) Received: from ads-s2k-3.ads.tnetpro.de ([172.18.120.12]) by ads-s2k-4.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sun, 24 Jul 2005 21:56:19 +0200 Received: from mail pickup service by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC; Sun, 24 Jul 2005 21:15:20 +0200 Received: from Mail-Gate2.DeTeLine.de ([195.243.47.8]) by ads-s2k-3.ads.tnetpro.de with Microsoft SMTPSVC(5.0.2195.5329); Sat, 16 Jul 2005 20:26:07 +0200 Received: from mail6.dmz.telekom.de ([10.225.32.141]) by Mail-Gate2.DeTeLine.de (8.12.8/config_8.6.05-UX-002) with SMTP id j6FLFW3L025717 for ; Fri, 15 Jul 2005 23:15:32 +0200 (MET DST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mail7.telekom.de with ESMTP for steffen.wentzel@telekom.de; Fri, 15 Jul 2005 23:18:56 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXHR-0005fL-8z; Fri, 15 Jul 2005 16:59:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXHL-0005do-S6 for routing-discussion@megatron.ietf.org; Fri, 15 Jul 2005 16:59:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11489 for ; Fri, 15 Jul 2005 16:59:24 -0400 (EDT) Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtXkC-00024H-Tm for routing-discussion@ietf.org; Fri, 15 Jul 2005 17:29:17 -0400 Received: (qmail 82829 invoked from network); 15 Jul 2005 20:59:24 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 15 Jul 2005 20:59:24 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j6FL1cN6010594; Fri, 15 Jul 2005 17:01:39 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200507152101.j6FL1cN6010594@workhorse.faster-light.net> To: "Stephen Sprunk" In-reply-to: Your message of "Fri, 15 Jul 2005 12:59:35 CDT." <023c01c5896a$0ede1020$6501a8c0@dax> Date: Fri, 15 Jul 2005 17:01:38 -0400 From: Curtis Villamizar X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on mail6.dmz.telekom.de X-Spam-Status: No, score=0.0 required=5.5 tests=none autolearn=disabled version=3.0.2 X-OriginalArrivalTime: 16 Jul 2005 18:26:07.0625 (UTC) FILETIME=[D5496790:01C58A33] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 In message <023c01c5896a$0ede1020$6501a8c0@dax> "Stephen Sprunk" writes: > > > No one in their right mind (note that I this is a qualified "no one") > > would bridge a PPP link to an ethernet link. Standards should > > discourage doing incredibly stupid things rather than try to > > accomodate people who do them with no good reason for doing so. > > Then a large number of ISPs are out of their minds... The two main ways to > deploy ADSL service are (a) Ethernet bridged to PPPoATM, and (b) PPPoE > directly to the host. I think the latter is also commonly used for DOCSIS. Agreed. :-) These were more the choices of DSLAM vendors and to a less extent the RBOCs/ILECs who were latecomers. The traditional ISPs at the time preferred that the DSLAMs just do IP over PPP on the customer router or host and IP over PPP or ATM on the backhaul side. The DSLAM vendors thought that by matching the ATM parameters to the DSL rate they could all but eliminate buffering in the DSLAM. > If bridging POS and Ethernet were safer (i.e. jumbos could be assumed), we'd > probably see that become common in ISPs as well. Has it become that bad already? :-) Who was it that said the Internet is growing exponentially but the amount of clue is growing linearly at best so the clue density is shrinking exponentially? I think it was Randy Bush in the early 90s. > > TCP and most other modern protocols handle the end system MTU quite > > nicely and TCP path MTU discovery is widely implemented and easy > > enough to enable though I think it is still disabled by default in > > most implementations. > > Win2k and later have PMTUD on by default, but unfortunately not PMTU black > hole detection. I'm not sure about earlier Windows versions or > MacOS/Linux/etc. > > However, there's no current means for MTU detection for hosts on the same > subnet. I can envision a number of ways to fix this for IP traffic, but I > don't know enough about IS-IS to know if any of them are applicable. > > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov ISIS sends hellos at full MTU. If the other end can't handle them, then no neighbor adjacency comes up. There is no L2 DF bit and ICMP would fragment reply as there is in IP so TCP doesn't handle the MTU mismatch on the same subnet. Something like that (an L2 DF and ICMP) would be needed to handle two devices with an MTU mismatch on the same subnet or some probe packet of the type ISIS uses. The diagnostic tool available to today's operator is "ping". Use the -s option. Until something changes there is no automatic means to detect and correct an MTU mismatch on the same subnet. If running ISIS there is the means to detect the error but I don't think there is an automatic correction (no MTU fallback). I'd have to check the expired draft. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From rtg-dir-bounces@ietf.org Sun Jul 24 16:40:23 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23690 for ; Sun, 24 Jul 2005 16:40:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwnla-0005Yf-0y for rtg-dir-archive@ietf.org; Sun, 24 Jul 2005 17:12:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnG6-00034e-0i; Sun, 24 Jul 2005 16:39:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnG4-00034W-It; Sun, 24 Jul 2005 16:39:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23631; Sun, 24 Jul 2005 16:39:34 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwnkl-0005Wn-Nu; Sun, 24 Jul 2005 17:11:21 -0400 Received: from catv-50620fda.catv.broadband.hu ([80.98.15.218]) by mx2.foretec.com with smtp (Exim 4.24) id 1DwnG2-00055o-3X; Sun, 24 Jul 2005 16:39:34 -0400 Received: from TVg@localhost by uhZ4.int (8.11.6/8.11.6); Sun, 24 Jul 2005 15:54:10 -0600 Message-ID: From: "Anne Carlisle" To: vpim@ietf.org Date: Sun, 24 Jul 2005 23:51:10 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: SamanthaAbel@etc-energy.org Content-Type: multipart/mixed; boundary="--uAlNnaP9w2eqHjF7B2v" X-Spam-Score: 1.4 (+) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: rtg-dir@ietf.org Subject: Photoshop CS2 9.0 $69.95 Adobe, Windows X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anne Carlisle List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb psZ ----uAlNnaP9w2eqHjF7B2v Content-Type: text/html; Content-Transfer-Encoding: quoted-printable N
    Opt-in Email Special Offer   = ;  unsubscribe me
    =
    SEARCH

    <= tr vAlign=3Dtop bgColor=3D#333399>

    TOP 10 NEW TITLES

    <= /td>
    <= tr>

     = ON SALE NOW!

     1 O= ffice Pro 2003
     2 Adobe = Photoshop 9.0
     3 Window= s XP Pro
     4 Adobe Acro= bat 7 Pro
     <= font face=3DVerdana size=3D1>5 Flash MX= 2004
     6 Corel Draw 1= 2
     7 Norton Antivirus = 2005
     8 Windows 2003 = Server
     9 Alias Maya = 6 Wavefrt
     <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
    &nb= sp; See more by this manufacturer
       Microsoft
       Symantec
       Adobe<= /a>
      Customers also bo= ught
       these other items...

    Microsoft Office = Professional Edition *2003*
    Microsoft

    <= /table>

    Choose= :
     
    Lis= t Price:$499.00
    Pr= ice:$69.99
    You Save:= $429.01 (86%)

    =

    Availability: Available for INSTANT download!
    Coupo= n Code: 4C9V6Fy6g
     

    Sales = Rank: #1
    System requirements  |  Other Versions
    Date Coupon Expires:= August 31st, 2005
    Average Customer R= eview:3D"5 Based on 1219 reviews. Write a review.

    Adobe Photoshop CS2 V 9.0
    Adobe

    Choose:
     <= /td>

    <= img height=3D150 src=3Dhttp://images.amazon.com/images/P/B00081I6JI.01._PE= 7_SCMZZZZZZZ_.jpg width=3D144 align=3Dleft border=3D0 name=3Dprod_image>

    List Price:$599.00
    Price:$69.99<= /b>
    You Save:$529.01 (90= %)



    Availability: A= vailable for INSTANT download!
    Coupon Code: r1LjpjT
     <= /p>

    Sales Rank: #2
    System requirements = |  Other Versions
    Date Coupon Expires: August 31st, 2005
    Average Customer Review:3D= Based on 12624= reviews. Write a review.

    =
    Microsoft Windows XP Professional or Longhorn Edition=
    Microsoft

    Choose:
     

    =
    List Price:$279.00
    Price:= $49.99
    You Save:$229.01 (85%)



    Ava= ilability: Available for INSTANT download!
    Coupon Code: PVi= lczKez
     

    Sales Rank: #3
    System requ= irements      |  Other Version= s
    Date Coupon Expires: August 31s= t, 2005
    Average Customer Review:3D"5 Based on 168772 reviews. Write a revi= ew.

    Adobe Acrobat Professional V 7.0 Adobe

    Choose:
    &nb= sp;

    List Price:$499.00
    Price:$69.99<= /b>
    You Save:$429.01 (85= %)



    Availability: A= vailable for INSTANT download!
    Coupon Code: nn6wEDIJ
     =

    Sales Rank: #4
    System requirements     = |  Other Versions
    Date Coupon Expires: August 31st, 2005
    Average Customer Review:3D= Based on 1833 = reviews. Write a review.

    =

    ----uAlNnaP9w2eqHjF7B2v-- From rtg-dir-bounces@ietf.org Sun Jul 24 22:10:52 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12768 for ; Sun, 24 Jul 2005 22:10:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwsvR-0005Xf-UM for rtg-dir-archive@ietf.org; Sun, 24 Jul 2005 22:42:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwsNl-0004Ap-QU; Sun, 24 Jul 2005 22:07:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwsNk-0004AX-95 for rtg-dir@megatron.ietf.org; Sun, 24 Jul 2005 22:07:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12561 for ; Sun, 24 Jul 2005 22:07:47 -0400 (EDT) Received: from relay00.pair.com ([209.68.1.20] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DwssT-0005RN-Af for rtg-dir@ietf.org; Sun, 24 Jul 2005 22:39:37 -0400 Received: (qmail 22933 invoked from network); 25 Jul 2005 02:07:42 -0000 Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 25 Jul 2005 02:07:42 -0000 X-pair-Authenticated: 69.37.59.162 Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j6P281Z0049764; Sun, 24 Jul 2005 22:08:01 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net) Message-Id: <200507250208.j6P281Z0049764@workhorse.faster-light.net> To: Tony Li In-reply-to: Your message of "Sun, 24 Jul 2005 07:55:48 PDT." <42E3ABF4.4010101@tony.li> Date: Sun, 24 Jul 2005 22:08:01 -0400 From: Curtis Villamizar X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: rtg-dir@ietf.org, iesg@ietf.org, routing-discussion@ietf.org, curtis@faster-light.net, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@faster-light.net List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 In message <42E3ABF4.4010101@tony.li> Tony Li writes: > > > Curtis, > > > Excluding NFS and a few other less used protocols there is little > > reason for end system jumbo frames. It is widely understood that NFS > > 8K UDP packets are a bad design. > > > > IMHO endorsing jumbo frames in end systems goes to much against what > > IEEE would like to see and does so for the benefit of protocols that > > should have a new revision that eliminates the need by being more MTU > > aware. This also can improve their performance radically when used > > over a WAN or VPN. > > > I would agree that using UDP for NFS in the first place was a > questionable call, exacerbated when UDP checksums were not enabled by > default on the implementations in question. > > However, the real issue here is the end system efficiency, not MTU > awareness. With a larger LAN MTU, the end system can be more efficient > by transfering an entire page at a time, rather than fragmenting it at > the UDP level or at the TCP level. For some systems, this is a > non-trivial consideration. When you couple this with ever increasing > link speeds (e.g., 10GigE), there seems little reason to preclude using > larger MTU sizes. You'll note that the supercomputer folks have been > pushing us in this direction for years and we also had this discussion > relative to IPv6. That was then and now is now. Network interfaces are now faster than disk drives by an order of magnitude or more. Yes, there is probably some Cray out there front ended with an Amdol putting 4K frames ont a HIPPI interface because at the time breaking up the disk block by anything but a fixed small factor of two was unthinkable. > As to what the IEEE would like to see, that would seem to be a lesser > consideration than delivering the technology that our customers (i.e., > end users) would like to see. Those votes have already been cast and > are clearly in favor of jumbo frames. At least we agree on the conclusion. > The IETF's larger job, besides pushing this work forward, should be to > consider the role and scope of the MTU in the Internet in general. It > is a fine point of the Internet architecture, and we have been remiss in > not attending to this issue. Right now, much of the Internet supports > a 4096 byte MTU, thanks primarily to some predominant POS > implementations. However, most access links are still constrained to > 1500B. It would be very helpful, operationally, if the IETF could come > up with a recommended set of MTUs and set some expectations for end > users on the predominant MTU sizes. Unfortunately in the past each new interface seems to want a bigger MTU than the last. I'm not sure where the 9K+ for IP/ATM came from. I don't think its at all likely that the IETF will be going back and changing MTUs just to make them all the same. Why would they? So that anyone building a new token ring or FDDI interface can use the new MTU? No one builds token ring interfaces anymore. > While many folks may feel that this is a trivial and pointless detail, > it has a decided economic impact. A fine example is classical IP over > ATM. There the IETF specified a large default MTU (9120B, if memory > serves). This caused equipment prices to rise as packet buffering > memory needed to be sized accordingly. However, due to the lack of > transit capability for this MTU size, this capability has been largely > wasted. Admittedly, this is indeed trivial with respect to the overall > waste on ATM technology, but it would be best if we did not repeat this > particular experiment. That doesn't make sense. In switches if you tossed out the ATM traffic management and actually tried to make use of most of the bandwidth you'd need delay*bandwidth sized buffers and the early switches had 128-256 cells. That had nothing to do with MTU. In routers the were two big problems. One was packet buffers which is unrelated to MTU. The other was SAR buffering. The problem existed when carrying Internet traffic over ATM and then reassembling at the other end and so also had nothing to do with IP/ATM MTU because there was no IP/ATM traffic involved. In NICs if cells didn't get reordered (which shouldn't happen) then you'd need at most a packet per concurrent open connection. If you had thousands of concurrent open connections (such as in a web server) you'd need megabytes of SAR memory. With an ether NIC and a jumbo MTU you don't need that sort of memory oncard because you get an entire frame at a time, not small pieces of many frames. With jumbo frame ether you still need the TCP buffers (which should always larger by at least a factor of 4) but that's in processor main memory. So it was really hopelessly inadequate buffering in switches and problems with SAR on routers and NICs and not the large MTU that was ATM's problem. > Tony We're straying off topic. We agree on the conclusion that IETF should support jumbo frames for ethernet. If you bringing up further examples to support extending the jumbo MTU to end systems and not just routers and switches, that's fine with me. Curtis From rtg-dir-bounces@ietf.org Sun Jul 24 23:33:17 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18320 for ; Sun, 24 Jul 2005 23:33:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwuDD-0008A7-I7 for rtg-dir-archive@ietf.org; Mon, 25 Jul 2005 00:05:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtiH-0000J0-6p; Sun, 24 Jul 2005 23:33:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwtiE-0000IL-Ko; Sun, 24 Jul 2005 23:33:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18251; Sun, 24 Jul 2005 23:33:03 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwuCz-000885-H8; Mon, 25 Jul 2005 00:04:54 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 24 Jul 2005 20:32:56 -0700 X-IronPort-AV: i="3.95,138,1120460400"; d="scan'208"; a="650431909:sNHT32984948" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6P3WtJL001422; Sun, 24 Jul 2005 20:32:55 -0700 (PDT) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA13350; Sun, 24 Jul 2005 20:32:52 -0700 (PDT) Date: Sun, 24 Jul 2005 20:32:52 -0700 From: Toerless Eckert To: Curtis Villamizar Message-ID: <20050725033252.GD9845@cisco.com> References: <42E3ABF4.4010101@tony.li> <200507250208.j6P281Z0049764@workhorse.faster-light.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507250208.j6P281Z0049764@workhorse.faster-light.net> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: rtg-dir@ietf.org, Tony Li , iesg@ietf.org, routing-discussion@ietf.org, Brian E Carpenter , Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Sun, Jul 24, 2005 at 10:08:01PM -0400, Curtis Villamizar wrote: > That was then and now is now. Network interfaces are now faster than > disk drives by an order of magnitude or more. But that's not necessary the right metric to judge the cost of packetizing. Distributed applications can easily shuffle data just between memory without having to resolve to disk transfer. I am not sure if there are any research community agreed upon metrics (sounds like a question to Scott). I personally would look for packetization to be acceptable as long as it takes up less % of CPU than the DMA of the data takes up in % of memory bandwidth. Just observing from past experience - not really wanting to make a statement one way or the other about research computers nowadays. Just for completeness (not that i'd expect anyone to care): For multicast to be able to leverage higher MTU than 1280 effectively and safely would require something very close to the architectural minimum limit to be raised (aka: ubiquitous availability of larger MTU across the Internet, end-to-end). So, i would certainly be happy if the agreed upon minimum MTU even in ethernet was raised to something like let's say at minimum the 4k so common in core networks anyhow (which also happens to be larger than many video frame sizes, so that could avoid fragmentation on many typical video encoders). Cheers Toerless From rtg-dir-bounces@ietf.org Mon Jul 25 01:29:36 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25795 for ; Mon, 25 Jul 2005 01:29:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dww1k-00030c-MQ for rtg-dir-archive@ietf.org; Mon, 25 Jul 2005 02:01:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwvVR-0006G5-0d; Mon, 25 Jul 2005 01:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwvUA-00064F-Om; Mon, 25 Jul 2005 01:26:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25590; Mon, 25 Jul 2005 01:26:42 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwvyw-0002to-Sk; Mon, 25 Jul 2005 01:58:32 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Jul 2005 22:26:10 -0700 X-IronPort-AV: i="3.95,139,1120460400"; d="scan'208"; a="200298956:sNHT46682444558" Received: from cliff.cisco.com (cliff.cisco.com [171.69.11.141]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6P5Q66p015638; Sun, 24 Jul 2005 22:26:07 -0700 (PDT) Received: from [10.21.122.117] (sjc-vpn6-629.cisco.com [10.21.122.117]) by cliff.cisco.com (8.6.12/8.6.5) with ESMTP id WAA16562; Sun, 24 Jul 2005 22:26:02 -0700 Message-ID: <42E477E7.6000704@tony.li> Date: Mon, 25 Jul 2005 06:25:59 +0100 From: Tony Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: curtis@faster-light.net References: <200507250208.j6P281Z0049764@workhorse.faster-light.net> In-Reply-To: <200507250208.j6P281Z0049764@workhorse.faster-light.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, Brian E Carpenter , iesg@ietf.org, routing-discussion@ietf.org, Scott Bradner Subject: Re: Reopening jumbo frames in IS-IS X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit > We're straying off topic. We agree on the conclusion that IETF should > support jumbo frames for ethernet. If you bringing up further > examples to support extending the jumbo MTU to end systems and not > just routers and switches, that's fine with me. Shutting the hell up... Tony From rtg-dir-bounces@ietf.org Mon Jul 25 16:10:29 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20413 for ; Mon, 25 Jul 2005 16:10:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx9mO-00074L-E6 for rtg-dir-archive@ietf.org; Mon, 25 Jul 2005 16:42:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx9GF-0006QQ-Nx; Mon, 25 Jul 2005 16:09:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx9GE-0006Pt-8O; Mon, 25 Jul 2005 16:09:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20285; Mon, 25 Jul 2005 16:09:12 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx9l3-00071n-8M; Mon, 25 Jul 2005 16:41:11 -0400 Received: from [222.115.8.116] (helo=lh) by mx2.foretec.com with smtp (Exim 4.24) id 1Dx9G5-00074v-Ds; Mon, 25 Jul 2005 16:09:05 -0400 From: "Rosemary Castillo" To: rtg-dir@ietf.org Date: Tue, 26 Jul 2005 03:07:49 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_NWNJUWLA.ILLTLMUY" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: X-Spam-Score: 3.4 (+++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: Fw: FYI X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.4 (+++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0000_NWNJUWLA.ILLTLMUY Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear HomeOwner, After completing the review we are pleased to offer you the following, Your current mortgage qualifies you for more than a 3% lower rate! -------------------------------------------------------- !! U.S MORTGAGE RATES HAVE NEVER BEEN LOWER! !! -------------------------------------------------------- Millions of Americans have re-financed this month alone! So why not you? Go HERE to make that change. If you prefer to be left out of this amazing offer go here. ------=_NextPart_000_0000_NWNJUWLA.ILLTLMUY Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7Bit Dear HomeOwner,

    After completing the review we are pleased to offer you the following,

    Your current mortgage qualifies you for more than a 3% lower rate!

    --------------------------------------------------------
    !! U.S MORTGAGE RATES HAVE NEVER BEEN LOWER! !!
    --------------------------------------------------------

    Millions of Americans have re-financed this month alone!

    So why not you?

    Go HERE to make that change.

    If you prefer to be left out of this amazing offer go here. ------=_NextPart_000_0000_NWNJUWLA.ILLTLMUY-- From rtg-dir-bounces@ietf.org Tue Jul 26 15:37:31 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18380 for ; Tue, 26 Jul 2005 15:37:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxVkE-0008AA-QG for rtg-dir-archive@ietf.org; Tue, 26 Jul 2005 16:09:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxVEu-0005u6-4x; Tue, 26 Jul 2005 15:37:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxVEs-0005pi-Gy; Tue, 26 Jul 2005 15:37:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18295; Tue, 26 Jul 2005 15:37:16 -0400 (EDT) Message-Id: <200507261937.PAA18295@ietf.org> Received: from 84-121-4-148.onocable.ono.com ([84.121.4.148] helo=lh) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DxVjy-00088z-7A; Tue, 26 Jul 2005 16:09:27 -0400 From: "Kristen Orozco" To: rtg-dir@ietf.org Date: Tue, 26 Jul 2005 21:33:03 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_ICTPIFOH.JLGYGOCQ" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.8 (++++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: FYI X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0000_ICTPIFOH.JLGYGOCQ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear HomeOwner, After completing the review we are pleased to offer you the following, Your current mortgage qualifies you for more than a 3% lower rate! -------------------------------------------------------- !! U.S MORTGAGE RATES HAVE NEVER BEEN LOWER! !! -------------------------------------------------------- Millions of Americans have re-financed this month alone! So why not you? Go HERE to make that change. If you prefer to be left out of this amazing offer go here. ------=_NextPart_000_0000_ICTPIFOH.JLGYGOCQ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7Bit Dear HomeOwner,

    After completing the review we are pleased to offer you the following,

    Your current mortgage qualifies you for more than a 3% lower rate!

    --------------------------------------------------------
    !! U.S MORTGAGE RATES HAVE NEVER BEEN LOWER! !!
    --------------------------------------------------------

    Millions of Americans have re-financed this month alone!

    So why not you?

    Go HERE to make that change.

    If you prefer to be left out of this amazing offer go here. ------=_NextPart_000_0000_ICTPIFOH.JLGYGOCQ-- From rtg-dir-bounces@ietf.org Wed Jul 27 05:24:03 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10393 for ; Wed, 27 Jul 2005 05:24:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxieF-0005IE-85 for rtg-dir-archive@ietf.org; Wed, 27 Jul 2005 05:56:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxi8f-0007M7-8X; Wed, 27 Jul 2005 05:23:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxi8d-0007Lz-Df for rtg-dir@megatron.ietf.org; Wed, 27 Jul 2005 05:23:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10382 for ; Wed, 27 Jul 2005 05:23:40 -0400 (EDT) Message-Id: <200507270923.FAA10382@ietf.org> Received: from 31.red-217-125-230.pooles.rima-tde.net ([217.125.230.31] helo=cisco.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dxidn-0005HP-Rz for rtg-dir@ietf.org; Wed, 27 Jul 2005 05:56:00 -0400 From: "Gage Mulligan" To: "Mohamed Kirby" Date: Wed, 27 Jul 2005 04:24:59 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C5928D.0F05A780" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.9 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: =?iso-8859-1?q?Vl=C0GRA_VA11=EDUM_ClAL=ECS?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.8 (++++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C5928D.0F05A780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, compelled to ignominious surrender. A thin, sour smile broke oncan be = infernally complex, he sighed.need not be impossible - he must profit by = that which they nowthick black hair, once so sedulously curled, hung now = in a lank,I was summoned that morning to succour Lord Gildoy, and I = conceivedA commonplace! said she. My God! A commonplace!two men aboard = who can assist me; but of the higher mysteries ofthat he was a man of = medicine and not of war; a healer, not a slayer.he must wait until Pitt = and Wolverstone should have withdrawn. Hethat? He'll end on a yardarm = for all his luck. And the quixoticoffending slaves.His eyes raked the = room, resting first sardonically on the yeoman,found that he had not = sufficiently considered the terms he shouldKent himself had afforded = him. Is the doctor here?from the rays of the sun. Next, sitting down = beside him, he drewYou may be sure that none will harass you on the = score of your ------=_NextPart_000_0030_01C5928D.0F05A780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

     
    Hello, Welcome to MegaPharm Online = Shoop.
     
    Pre gs ordere Online can SAV EY!
    scription Dru d  E YOU MON
    In some =3D2>rescription medicat
    e up to 80 st of your p ion.
     
    Thousands of our customers already enjoy these = savings.
     
    We deIiver direct to your door through fast, = Low-C0ST, reliable and secure service on the Internet.
     
     
    Have a nice day.
    ------=_NextPart_000_0025_01C5928D.12009800-- ------=_NextPart_000_0030_01C5928D.0F05A780-- From rtg-dir-bounces@ietf.org Thu Jul 28 03:09:00 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01363 for ; Thu, 28 Jul 2005 03:09:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy31F-0001iv-28 for rtg-dir-archive@ietf.org; Thu, 28 Jul 2005 03:41:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2V0-0007xh-3a; Thu, 28 Jul 2005 03:08:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2Ux-0007xP-Nk for rtg-dir@megatron.ietf.org; Thu, 28 Jul 2005 03:08:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01322 for ; Thu, 28 Jul 2005 03:08:05 -0400 (EDT) Message-Id: <200507280708.DAA01322@ietf.org> Received: from [220.80.116.172] (helo=galvin.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dy30M-0001go-Ec for rtg-dir@ietf.org; Thu, 28 Jul 2005 03:40:35 -0400 From: "Lluis Roche" To: "Constantin Wilburn" Date: Thu, 28 Jul 2005 02:07:47 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C59343.0EC7E380" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.7 (+++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: =?iso-8859-1?q?Vl=C1GGRA_V=C1LIUM_C1=C1LlSS?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.4 (++++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C59343.0EC7E380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, may speak with knowledge of what is to come to your lordship. And Imight = never have arrived at all but for the gallantry of CaptainHe's utterly = disgusting in his glee.And so shall you, gentlemen. Blood looked from = judge to jury.in himself a standard by which to measure his neighbour.of = my decision.Heave that muck overboard, he ordered some of those who = stoodbread, a quantity of cheese, a cask of water and some few = bottlesAstronomy, is it? Faith, now, I couldn't tell the Belt of = Oriontheir stations, and before they had reached the Cinco Llagas, = theythese islands. Palomas, which is some ten miles in length, isLord = Julian hailed her advent with satisfaction. It gave a voyageone fifth = of the prizes, the officers would answer for their men;Ye don't mean, = sir, that you'll let that Spanish scoundrel goWas he right, Arabella? = My life's happiness hangs upon your answer.hurtled violently against = Lord Julian, who kept his feet only by ------=_NextPart_000_002D_01C59343.0EC7E380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Hello, Welcome to MegaaPharm Online = Shop.
     
    Pre gs ord Online can SA NEY!
    scription Dru ered  VE YOU MO
    In some cases you can s % on the co ion medic
    ave up to 80 st of your prescript ation.
     
    Thousands of our customers already enjoy these = savings.
     
    We deIiver direct to your door through fast, = Low-C0ST, reliable and secure service on the Internet.
     
     
    Have a nice day.
    ------=_NextPart_000_002D_01C59343.0EC7E380-- From rtg-dir-bounces@ietf.org Thu Jul 28 07:16:59 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16686 for ; Thu, 28 Jul 2005 07:16:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy6tI-0001Cc-RJ for rtg-dir-archive@ietf.org; Thu, 28 Jul 2005 07:49:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy6Nm-0005Pd-0q; Thu, 28 Jul 2005 07:16:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy6Nk-0005P4-Ti; Thu, 28 Jul 2005 07:16:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16666; Thu, 28 Jul 2005 07:16:47 -0400 (EDT) Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy6t5-0001BR-4a; Thu, 28 Jul 2005 07:49:20 -0400 Received: from dh029151.ahqps.alcatel.fr (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j6SBGbgJ012556; Thu, 28 Jul 2005 06:16:38 -0500 (CDT) Date: Thu, 28 Jul 2005 04:16:31 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <213431338.20050728041631@alcatel.com> To: iesg@ietf.org, rtg-chairs@ietf.org, rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: limited access to zinin@psg.com X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit If you need to reach me or have sent an e-mail to zinin@psg.com that needs my response before the week-end, please send me an e-mail to alex.zinin@alcatel.com. I'm in meetings this week and have limited Internet connectivity that prevents me from using the psg.com account. -- Alex From rtg-dir-bounces@ietf.org Thu Jul 28 13:39:52 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15134 for ; Thu, 28 Jul 2005 13:39:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyCrt-0004dT-IE for rtg-dir-archive@ietf.org; Thu, 28 Jul 2005 14:12:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCJL-0002rM-Ci; Thu, 28 Jul 2005 13:36:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCJK-0002qA-Ma for rtg-dir@megatron.ietf.org; Thu, 28 Jul 2005 13:36:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14994 for ; Thu, 28 Jul 2005 13:36:43 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyCoo-0004YE-1L for rtg-dir@ietf.org; Thu, 28 Jul 2005 14:09:20 -0400 Received: from dialin-80-228-51-179.ewe-ip-backbone.de ([80.228.51.179]) by mx2.foretec.com with smtp (Exim 4.24) id 1DyCJ7-0002Bg-9F for rtg-dir@ietf.org; Thu, 28 Jul 2005 13:36:35 -0400 Message-ID: <03f401c59398$87b0fe36$191081af@access-one.com> From: "Richard K. Lee" To: rtg-dir@ietf.org Date: Thu, 28 Jul 2005 17:15:58 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_BFEAFEE9.D22F3F86" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: Horny pills - 75% OFF X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.7 (+++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_0000_BFEAFEE9.D22F3F86 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_D186FE9A.926E3DA9" ------=_NextPart_001_0001_D186FE9A.926E3DA9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Easy erection Prolonged effect No prescription required Give it a try! CIALIS - http://www.z-pills.com/sv/ VIAGRA - http://www.z-pills.com/vt/ Discreet packaging _________________________________________________________________________ To change your mail preferences, go here _________________________________________________________________________ ------=_NextPart_001_0001_D186FE9A.926E3DA9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

    Easy erection
    Prolonged effect
    No prescription required

    Give it a try!
    CIALIS - http://www.z-pills.com/sv/
    VIAGRA - http://www.z-pills.com/vt/

    Discreet packaging


    _________________________________________________________________________
    To change your mail preferences, go here
    _________________________________________________________________________

    ------=_NextPart_001_0001_D186FE9A.926E3DA9-- ------=_NextPart_000_0000_BFEAFEE9.D22F3F86-- From rtg-dir-bounces@ietf.org Sat Jul 30 10:46:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dysbl-0001my-G3; Sat, 30 Jul 2005 10:46:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dysbj-0001he-D4 for rtg-dir@megatron.ietf.org; Sat, 30 Jul 2005 10:46:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14246 for ; Sat, 30 Jul 2005 10:46:33 -0400 (EDT) From: fenner@research.att.com Received: from electricrain.com ([207.7.145.10] ident=qmailr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dyt7b-0005bR-9n for rtg-dir@ietf.org; Sat, 30 Jul 2005 11:19:32 -0400 Received: (qmail 15609 invoked by uid 0); 30 Jul 2005 14:46:27 -0000 Received: from m615e36d0.tmodns.net (HELO ?10.187.144.226?) (fenner@208.54.94.97) by electricrain.com with RC4-MD5 encrypted SMTP; 30 Jul 2005 14:46:25 -0000 To: iesg@ietf.org Date: Sat, 30 Jul 2005 16:45:32 +0200 Message-ID: <6zg6bC5wVMbt.LZXLckQ0@electricrain.com> X-Mailer: Symbian OS Email Version 7.0 MIME-Version: 1.0 Content-Language: i-default Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: quoted-printable Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: My contact number in Paris X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fenner@research.att.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org +336339295870 or locally 0633929587. My U.S. Cell number works too but = costs me $1/minute. From rtg-dir-bounces@ietf.org Sun Jul 31 04:10:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz8uI-0007M6-H3; Sun, 31 Jul 2005 04:10:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz8uG-0007Ls-N8; Sun, 31 Jul 2005 04:10:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11506; Sun, 31 Jul 2005 04:10:46 -0400 (EDT) Message-Id: <200507310810.EAA11506@ietf.org> Received: from [221.158.227.206] (helo=lh) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dz9QH-0000Wz-H2; Sun, 31 Jul 2005 04:43:55 -0400 From: "Lori Kendall" To: rtg-dir@ietf.org Date: Sun, 31 Jul 2005 10:02:40 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_KMMYTIJZ.PYCNWYTA" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.4 (+++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: Re: FYI X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0000_KMMYTIJZ.PYCNWYTA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear HomeOwner, After completing the review we are pleased to offer you the following, Your current mortgage qualifies you for more than a 3% lower rate! -------------------------------------------------------- !! U.S MORTGAGE RATES HAVE NEVER BEEN LOWER! !! -------------------------------------------------------- Millions of Americans have re-financed this month alone! So why not you? Go HERE to make that change. If you prefer to be left out of this amazing offer go here. ------=_NextPart_000_0000_KMMYTIJZ.PYCNWYTA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7Bit Dear HomeOwner,

    After completing the review we are pleased to offer you the following,

    Your current mortgage qualifies you for more than a 3% lower rate!

    --------------------------------------------------------
    !! U.S MORTGAGE RATES HAVE NEVER BEEN LOWER! !!
    --------------------------------------------------------

    Millions of Americans have re-financed this month alone!

    So why not you?

    Go HERE to make that change.

    If you prefer to be left out of this amazing offer go here. ------=_NextPart_000_0000_KMMYTIJZ.PYCNWYTA--

    Igor

    Alex Zinin <zinin@psg.com> wrote:
    Igor, Dimitri-

    I just realized tha= t we've again fallen in to the same trap--we're having
    a discussion on= technical details here :)

    I'll change the text to say "distributi= on of some informatiion from user's
    control plane", and we'll leave th= e rest to you guys and the WG process.

    --
    Alex
    http://www.p= sg.com/~zinin

    Thursday, May 5, 2005, 8:56:55 AM, Dimitri.Papadimit= riou@alcatel.be wrote:
    > igor,

    > you mention that the pro= vider's control plane needs to participate in
    > CE-CE control messa= ge exchanges, actually this is not the case, RFC 3946
    > supports th= e possiblity to request for DCC channel transparency (if
    > supporte= d by the network data plane), and nothing prevents from running
    > t= he LMP session over the VC-4-Xc connection itself - in case

    > = - concerning the exchange of other control plane information the L1VPN
    > models described since so far does not ass= ume something different from
    > what has been developed in the GMPLS= overlay context i.e. the connection
    > at the SDH/circuit level is = used by the client control plane to exchange
    > its own control plan= e information, in case dedicated channel are required
    > - for insta= nce when the client network wants to maintain an out of band
    > cont= rol channel - that is to be established over a dedicated VC-4-Xc

    &= gt; Igor Bryskin
    > Sent by: rtg-dir-bounces@i= etf.org
    > 05/05/2005 08:18 MST

    > To:Alex Zinin
    > cc:Kireeti Kompella , Adrian Farrel> , takeda.tomonori@lab.ntt.co.jp, rtg-dir@ietf.= org,
    > Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
    > bcc:
    >= ; Subject:Re: Draft L1VPN Charter




    > Alex,

    &g= t; =A1@

    > See in-line.

    > =A1@

    > Igor

    > Alex Zinin wrote:
    <= BR>> Igor,

    >> 2. Enhanced mode: the CE-PE interface provi= des the signaling capabilities
    >> as in the Basic mode, plus per= mits utilization of the provider's control
    >> plane for distribu= tion of user's routing information (e.g. similar to the
    >> MPLS/= BGP model).

    >> I=F9=FEd like to replace this with:

    &g= t;> 2. Enhanced mode: the CE-PE interface provides the signaling capab= ilities
    >> as in the Basic mode, plus permits utilization of the= provider's control
    >> plane for distribution of user's arbitrar= y control plane information
    >> between the VPN sites including b= ut not limited to routing information.

    >> Provider network I= HMO should make no assumptions on what protocols are
    >> running = within VPNs. Generally speaking, a L1VPN user is not necessarily
    >&= gt; GMPLS controlled network. Furthermore, even in case it does use GMPLS it
    >> needs L1VPN CE-CE connections to provid= e (TE) links within VPNs.
    >> Specifically, the User should be ca= pable to run LMP for such links, it
    >> also should be possible t= o establish signaling (RSVP) adjacencies between
    >> their ends, = etc. The bottom line is that distribution of routing
    >> informat= ion between CEs IHMO is not sufficient. I believe this is
    >> con= sistent with the requirements stated in ITU-T SG13 L1VPN documents
    > Distributing "arbitrary" control plane information is a scary idea= . In
    > fact, I should really change that to "reachability" to be ev= en more
    > specific.

    > Igor, could you explain how represe= nting CE-CE connections as TE links and
    > running LMP over them req= uires additional info to be distributed by the
    > cloud's control pl= ane?

    > Alex

    > =A1@

    > Let=A1=A6s consider a = very simple VPN view:

    > =A1@

    > C1-----CE1=3D=3D=3D=3D=3D=3D=3D=3DCE2-----C2

    > =A1@

    >= ; In order for CE1 and CE2 discover TE link CE1-CE2 they may try to use> LMP which requires exchange of IP packets between CE1 and CE2, Th= e fact
    > that there is a data plane connectivity between CE1 and CE= 2 (realized via
    > L1VPN connection) does not necessarily mean that = CE1 and CE2 can use this
    > connection for the purpose of exchanging= IP packets. Consider, for
    > instance, the situation when CE1 and C= E2 are SDH cross-connects and the
    > CE1-CE2 connection is a VC4-4c = LSP. Hence, the Provider network needs to
    > participate in the out-= of-band IP packet delivery to make CE1-CE2 LMP
    > session work.
    <= BR>> =A1@

    > Likewise, when, say, C1 decides to provision an = LSP from C1 to C2 RSVP
    > messages will need to be propagated betwee= n CE1 and CE2. Prior to that C1
    > needs to compute a TE path for th= e LSP, hence it needs to know the
    > attributes of, say, TE link CE2-C2, which could be achieved if routing
    > and TE information is= flooded over an IGP adjacency between CE1 and CE2.
    > Mind that jus= t the knowledge of the fact that C2 could be reachable via
    > CE2 is= not sufficient =A1V there could be no TE path of the required
    > pa= rameters and quality available between CE2 and C2.

    > =A1@
    > The bottom line is that the Provider network needs to participate = in
    > pretty much every aspect of the VPN control plane, and as scar= y as it
    > sounds, the simplest way to accomplish this is to allow a= rbitrary control
    > plane connectivity between CEs. If one assumes t= hat VPN control plane is
    > always IP based, the phrase =A1=A7arbitr= ary control plane connectivity=A1=A8
    > could be transformed into =A1= =A7IP connectivity=A1=A8. However, generally
    > speaking, the VPN co= ntrol plane may not necessarily be IP based.

    > =A1@

    >= Igor

    > =A1@

    > =A1@





    > Yahoo= ! Mail Mobile
    > Take Yahoo! Mail with you! Check email on your mobil= e phone.

    Discover Yahoo!
    =20 Get on-the-go sports scores, stock quotes, news & more. Chec= k it out! --0-27091036-1115311802=:71533-- From rtg-dir-bounces@ietf.org Thu May 5 13:01:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19166 for ; Thu, 5 May 2005 13:01:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjx7-0004KB-HB for rtg-dir-archive@ietf.org; Thu, 05 May 2005 13:15:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjhs-0005UZ-DU; Thu, 05 May 2005 13:00:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjhp-0005UU-Ev for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 13:00:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18960 for ; Thu, 5 May 2005 13:00:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjw8-0004Gb-QT for rtg-dir@ietf.org; Thu, 05 May 2005 13:14:58 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTjhm-0000Is-5C; Thu, 05 May 2005 17:00:06 +0000 Date: Thu, 5 May 2005 10:00:05 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <214353090.20050505100005@psg.com> To: Igor Bryskin In-Reply-To: <20050505165002.72144.qmail@web30805.mail.mud.yahoo.com> References: <17418738.20050505092637@psg.com> <20050505165002.72144.qmail@web30805.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Dimitri.Papadimitriou@alcatel.be, takeda.tomonori@lab.ntt.co.jp, Adrian Farrel , rtg-dir@ietf.org Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit OK, I'm sending the updated charter to the L1VPN mailing + rtg-dir. If any of you are not on one of the lists--please subscribe to l1vpn. Thanks. -- Alex http://www.psg.com/~zinin Thursday, May 5, 2005, 9:50:02 AM, Igor Bryskin wrote: > Great idea. That is, actually, more or less what I was asking for. > Igor > Alex Zinin wrote: > Igor, Dimitri- > I just realized that we've again fallen in to the same trap--we're having > a discussion on technical details here :) > I'll change the text to say "distribution of some information from user's > control plane", and we'll leave the rest to you guys and the WG process. From rtg-dir-bounces@ietf.org Thu May 5 13:04:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19604 for ; Thu, 5 May 2005 13:04:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTk0O-0004cJ-HR for rtg-dir-archive@ietf.org; Thu, 05 May 2005 13:19:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjkv-0006PQ-Ok; Thu, 05 May 2005 13:03:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjkt-0006Oe-JE; Thu, 05 May 2005 13:03:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19499; Thu, 5 May 2005 13:03:16 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjzE-0004VE-9C; Thu, 05 May 2005 13:18:08 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTjks-0000dN-53; Thu, 05 May 2005 17:03:18 +0000 Date: Thu, 5 May 2005 10:03:17 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1414061909.20050505100317@psg.com> To: l1vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Folks- Please find below the proposed text of the charter for L1VPN WG. I've ran it past the usual suspects, but would appreciate comments from everyone (even you're a suspect and your only comment is "OK"). -- Alex Layer 1 Virtual Private Networks (l1vpn) Last Modified: 2005-05-05 Chair(s): TBD TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Technical Advisor(s): Mailing Lists: General Discussion: l1vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html Description of Working Group: L1VPN Working Group's task is to specify mechanisms necessary for providing a VPN service over a GMPLS transport network. The following two service models will be addressed: 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. The GMPLS network is not involved in distribution of user's routing information. 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits utilization of the provider's control plane for distribution of some information from the user's control plane (e.g. network-layer reachability information as in the MPLS/BGP model). The WG will work on the following items: 1. Framework document defining the reference network model, L1VPN service model, fundamental assumptions, and terminology. 2. Specification of the L1VPN user-to-network interface (UNI) basic mode, including both CE and PE functionality. 3. Specification of the L1VPN node-to-node interface (NNI) basic mode. 4. MIB modules and/or extensions required for UNI and NNI basic mode. 5. Specification of L1VPN UNI enhanced mode. 6. Specification of L1VPN NNI enhanced mode. 7. MIB modules and/or extensions required for UNI and NNI enhanced mode. Protocol extensions required for L1VPN will be done in cooperation with CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. Where necessary, the WG will also cooperate with ITU-T. Milestones: Sep 05 Submit first Internet Draft of L1VPN framework Sep 05 Submit first Internet Drafts of UNI and NNI basic mode specifications Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic mode Apr 06 Submit UNI and NNI basic mode specifications to IESG for publication as Proposed Standard Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode specifications Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for publication as Proposed Standard Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for publication as Proposed Standard Dec 06 Submit L1VPN framework to IESG for publication as Informational RFC Aug 07 Submit MIB modules for UNI and NNI enhanced mode to IESG for publication as Proposed Standard From rtg-dir-bounces@ietf.org Thu May 5 13:04:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19650 for ; Thu, 5 May 2005 13:04:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTk0d-0004ck-Px for rtg-dir-archive@ietf.org; Thu, 05 May 2005 13:19:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjlQ-0006bi-Rv; Thu, 05 May 2005 13:03:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTjlQ-0006bd-31 for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 13:03:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19554 for ; Thu, 5 May 2005 13:03:48 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTjzk-0004WS-MX for rtg-dir@ietf.org; Thu, 05 May 2005 13:18:41 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTjlM-0000gr-JO; Thu, 05 May 2005 17:03:48 +0000 Date: Thu, 5 May 2005 10:03:46 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <710559588.20050505100346@psg.com> To: Dimitri.Papadimitriou@alcatel.be In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Adrian Farrel , rtg-dir@ietf.org, Igor Bryskin , takeda.tomonori@lab.ntt.co.jp Subject: Re: L1VPN evaluation status? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Dimitri, Please go ahead and take this to the list. -- Alex http://www.psg.com/~zinin Tuesday, May 3, 2005, 11:26:25 AM, Dimitri.Papadimitriou@alcatel.be wrote: > alex - ok no problem concerning me > in order to streamline the technical discussion, here below a sum'up and > pointers to the discussion items to be provided on the list indicated with > (*) > CE functionality > ---------------- > 1) reachability information (what prefixes are behind other CEs) > Note: in the general case, those don't have to be IP > Signaling model: > - Manually configuration and/or transparent exchange > (*) Need for an address resolution mechanism (as this mechanism is not > L1VPN specific further discussion required as whether within or > outside the scope) > In any case need to ensure proper reachability information exchange > among PE's such that incoming request can be routed toward the > appropriate egress PE > In a first phase, all VPN sites are managed by a single administrative > entity (operator), and this entity knows prefixes behind other CEs. In > the single carrier context, two cases are possible single vs multiple AS > 2) Set of signaling parameters: the minimal set is the remote CE interface > and basic connection characteristics (LSP Encoding Type, BW, etc). The > current set of parameters in existing GMPLS RSVP-TE signaling documents > (and related) are good enough to handle this case. > Note: advanced traffic parameters may include more TE information to > influence the LSP trajectory. > Manually configured in the the sig-only and sig+rtg case. > 3) how to signal the connection through the provider's cloud > parameters in existing GMPLS RSVP-TE signaling documents (and related) > are good enough to signal the connection through the provider's cloud. > As Provider's core nodes (PEs and Ps) and CEs all use GMPLS signaling, > so no special procedures are required. > 4) Status of established connections > L1VPN connections being GMPLS LSPs, re-use of existing GMPLS control > mechanisms can be used to monitor the status of these connections. > (*) Provide further details for PathErr/ResvErr, Notify message > exchange through (CE-PE boundary) e.g. IF_ID ERROR_SPEC object TLV; the > Notify Request object processing and routing of the Notify message > Note: mechanisms such as data plane OAM mechanisms are out of the scope > PE functionality > ---------------- > 1) (in the sig+rtg model) how to help CEs distribute reachability > information + (in the per-VPN peer mode) may also need to expose some > internal topology to the CEs > Several mechanisms for CEs to distribute reachability information are > detailed in the GVPN I-D. > (*) The per-VPN peer model is conceptually similar to virtual routers; > however as the implementation may be different additional thoughts > could be required > 2) CE's signaling notation > As above (2) and 3) for CE functionality > 3) How to process CE's signaling requests and translate them into > internal GMPLS LSP requests. > Several mechanisms are possible i.e. stitching and shuffling > (application > of the contiguous LSP signaling to the L1VPN context is introduced in > Section 2.2 of the GVPN I-D). The latter requires address translation at > PEs. (*) Further details required to support CE functionality (point 4) > Nesting of the incoming CE-to-CE LSP into a network LSP also requires > further details. > (*) Further discussion expected concerning the set of signaling > mechanisms > to be progressed for L1VPN. > 4) how to tell CEs about connection status > Same as (4) for CE functionality > Note: concerning reachability information exchange in the (sig+rtg model) > further discussion about homogeneity of the protocols i.e. same protocol > b/w CE-PE and PE-..-PE or different protocol between CE-PE and between PE's > (*) From rtg-dir-bounces@ietf.org Thu May 5 14:58:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00184 for ; Thu, 5 May 2005 14:58:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTlmG-0001WH-6V for rtg-dir-archive@ietf.org; Thu, 05 May 2005 15:12:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTlXV-0006q5-A3; Thu, 05 May 2005 14:57:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTlXT-0006pz-Oi for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 14:57:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00144 for ; Thu, 5 May 2005 14:57:33 -0400 (EDT) Received: from web30814.mail.mud.yahoo.com ([68.142.201.140]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTllo-0001Vq-O4 for rtg-dir@ietf.org; Thu, 05 May 2005 15:12:25 -0400 Received: (qmail 99915 invoked by uid 60001); 5 May 2005 18:57:21 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=HD8Ni9PilL7W15Nienxz/ZHoOCoNRNbYbWLwN/961E4xiGVkVfi7Yv8Hnlcu/obiQ41Nov70eJPueE1yWfv4CXpCFjnEC0MDx5mNlLQHD0Unp+7uxIIyKXcyHvuX+HUco7FYONC6HUqoi77ss8FlwTNJAxivdXvuldNKAXujWss= ; Message-ID: <20050505185721.99913.qmail@web30814.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30814.mail.mud.yahoo.com via HTTP; Thu, 05 May 2005 11:57:21 PDT Date: Thu, 5 May 2005 11:57:21 -0700 (PDT) From: Igor Bryskin To: Dimitri.Papadimitriou@alcatel.be In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1531668686-1115319441=:99826" X-Spam-Score: 0.7 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: Alex Zinin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 --0-1531668686-1115319441=:99826 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA00144 Content-Transfer-Encoding: quoted-printable Dimitri, Dimitri.Papadimitriou@alcatel.be wrote: igor, you mention that the provider's control plane needs to participate in CE-= CE control message exchanges, actually this is not the case, RFC 3946 sup= ports the possiblity to request for DCC channel transparency (if supporte= d by the network data plane) IB>> What if not? Also what if CEs need to exchange control plane informa= tion before actual L1VPN connection is established? , and nothing prevents from running the LMP session over the VC-4-Xc conn= ection itself - in case=20 - concerning the exchange of other control plane information the L1VPN mo= dels described since so far does not assume something different from what= has been developed in the GMPLS overlay context i.e. the connection at t= he SDH/circuit level is used by the client control plane to exchange its = own control plane information, in case dedicated channel are required - f= or instance when the client network wants to maintain an out of band cont= rol channel - that is to be established over a dedicated VC-4-Xc IB>> True, but only if controllers can insert/extract control plane packe= ts to/from the SDH payload. Igor Igor Bryskin Sent by: rtg-dir-bounces@ietf.org 05/05/2005 08:18 MST To: Alex Zinin cc: Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp, rtg-dir@ietf.org, Dimitri PAPADIMI= TRIOU/BE/ALCATEL@ALCATEL bcc:=20 Subject: Re: Draft L1VPN Charter Alex, =A1@ See in-line. =A1@ Igor Alex Zinin wrote:=20 Igor, > 2. Enhanced mode: the CE-PE interface provides the signaling capabiliti= es > as in the Basic mode, plus permits utilization of the provider's contro= l > plane for distribution of user's routing information (e.g. similar to t= he > MPLS/BGP model). > I=F9=FEd like to replace this with: > 2. Enhanced mode: the CE-PE interface provides the signaling capabiliti= es > as in the Basic mode, plus permits utilization of the provider's contro= l > plane for distribution of user's arbitrary control plane information > between the VPN sites including but not limited to routing information. > Provider network IHMO should make no assumptions on what protocols are > running within VPNs. Generally speaking, a L1VPN user is not necessaril= y > GMPLS controlled network. Furthermore, even in case it does use GMPLS i= t > needs L1VPN CE-CE connections to provide (TE) links within VPNs. > Specifically, the User should be capable to run LMP for such links, it > also should be possible to establish signaling (RSVP) adjacencies betwe= en > their ends, etc. The bottom line is that distribution of routing > information between CEs IHMO is not sufficient. I believe this is > consistent with the requirements stated in ITU-T SG13 L1VPN documents=20 Distributing "arbitrary" control plane information is a scary idea. In fact, I should really change that to "reachability" to be even more specific. Igor, could you explain how representing CE-CE connections as TE links an= d running LMP over them requires additional info to be distributed by the cloud's control plane? Alex =A1@ Let=A1=A6s consider a very simple VPN view: =A1@ C1-----CE1=3D=3D=3D=3D=3D=3D=3D=3DCE2-----C2 =A1@ In order for CE1 and CE2 discover TE link CE1-CE2 they may try to use LMP= which requires exchange of IP packets between CE1 and CE2, The fact that= there is a data plane connectivity between CE1 and CE2 (realized via L1V= PN connection) does not necessarily mean that CE1 and CE2 can use this co= nnection for the purpose of exchanging IP packets. Consider, for instance= , the situation when CE1 and CE2 are SDH cross-connects and the CE1-CE2 c= onnection is a VC4-4c LSP. Hence, the Provider network needs to participa= te in the out-of-band IP packet delivery to make CE1-CE2 LMP session work. =A1@ Likewise, when, say, C1 decides to provision an LSP from C1 to C2 RSVP me= ssages will need to be propagated between CE1 and CE2. Prior to that C1 n= eeds to compute a TE path for the LSP, hence it needs to know the attribu= tes of, say, TE link CE2-C2, which could be achieved if routing and TE in= formation is flooded over an IGP adjacency between CE1 and CE2. Mind that= just the knowledge of the fact that C2 could be reachable via CE2 is not= sufficient =A1V there could be no TE path of the required parameters and= quality available between CE2 and C2. =A1@ The bottom line is that the Provider network needs to participate in pret= ty much every aspect of the VPN control plane, and as scary as it sounds,= the simplest way to accomplish this is to allow arbitrary control plane = connectivity between CEs. If one assumes that VPN control plane is always= IP based, the phrase =A1=A7arbitrary control plane connectivity=A1=A8 co= uld be transformed into =A1=A7IP connectivity=A1=A8. However, generally s= peaking, the VPN control plane may not necessarily be IP based. =A1@ Igor =A1@ =A1@ --------------------------------- Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 --0-1531668686-1115319441=:99826 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA00144 Content-Transfer-Encoding: quoted-printable
    Dimitri,

    Dimitri.Papadimitriou@alcatel.be wrote= :

    igor,

    you mention that the provider's control= plane needs to participate in CE-CE control message exchanges, actually = this is not the case, RFC 3946 supports the possiblity to request for DCC= channel transparency (if supported by the network data plane)

    IB>> What if not? Also what if CE= s need to exchange control plane information before actual L1VPN connecti= on is established?

    , and nothing prevents from running the= LMP session over the VC-4-Xc connection itself - in case

    - concerning the exchange of other cont= rol plane information the L1VPN models described since so far does not as= sume something different from what has been developed in the GMPLS overla= y context i.e. the connection at the SDH/circuit level is used by the cli= ent control plane to exchange its own control plane information, in case = dedicated channel are required - for instance when the client network wan= ts to maintain an out of band control channel - that is to be established= over a dedicated VC-4-Xc

    IB>> True, but only if controllers can insert/extract control pl= ane packets to/from the SDH payload.

    Igor


    Igor Bryskin <i_bryskin@yahoo.com>
    Sent by: rtg-dir-bounces@ietf.org
    05/05/2005 08:18 MST

    To: Alex Zinin <zinin@psg.com>
    cc:<= /FONT> Kireeti Kompella <kireeti@juniper.net>, Adria= n Farrel <adrian@olddog.co.uk>, takeda.tomonori@lab.ntt.co.jp, rtg-= dir@ietf.org, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
    bcc:
    Subject: Re: = Draft L1VPN Charter


    Alex,

    =A1@

    <= FONT size=3D4>See in-line.

    =A1@
    Igor

    Alex Zinin <z= inin@psg.com> wrote:

    Igor,

    > 2. Enhanced mode: the CE-PE interface provid= es the signaling capabilities
    > as in the Bas= ic mode, plus permits utilization of the provider's control
    > plane for distribution of user's routing information (e.= g. similar to the
    > MPLS/BGP model).
    > I=F9=FEd like to replace this with:
    <= BR>> 2. Enhanced mode: the CE-PE interface provides the= signaling capabilities
    > as in the Basic mod= e, plus permits utilization of the provider's control
    > plane for distribution of user's arbitrary control plane information
    > between the VPN sites includin= g but not limited to routing information.

    &g= t; Provider network IHMO should make no assumptions on what protocols are=
    > running within VPNs. Generally speaking, a= L1VPN user is not necessarily
    > GMPLS contro= lled network. Furthermore, even in case it does use GMPLS it
    > needs L1VPN CE-CE connections to provide (TE) links wit= hin VPNs.
    > Specifically, the User should be = capable to run LMP for such links, it
    > also = should be possible to establish signaling (RSVP) adjacencies between
    > their ends, etc. The bottom line is that distri= bution of routing
    > information between CEs I= HMO is not sufficient. I believe this is
    > co= nsistent with the requirements stated in ITU-T SG13 L1VPN documents

    Distributing "arbitrary" control plane inf= ormation is a scary idea. In
    fact, I should real= ly change that to "reachability" to be even more
    specific.

    Igor, could you explain how repre= senting CE-CE connections as TE links and
    runnin= g LMP over them requires additional info to be distributed by the<= BR>cloud's control plane?

    Ale= x

    =A1@

    Let=A1=A6= s consider a very simple VPN view:

    =A1@

    C1-----CE1=3D=3D=3D=3D=3D=3D=3D=3DCE2-----C2

    =A1@

    In order for = CE1 and CE2 discover TE link CE1-CE2 they may try to use LMP which requi= res exchange of IP packets between CE1 and CE2, The fact that there is a = data plane connectivity between CE1 and CE2 (realized via L1VPN connectio= n) does not necessarily mean that CE1 and CE2 can use this connection for the purpose of exchanging I= P packets. Consider, for instance, the situation when CE1 and CE2 are SDH= cross-connects and the CE1-CE2 connection is a VC4-4c LSP. Hence, the Pr= ovider network needs to participate in the out-of-band IP packet delivery= to make CE1-CE2 LMP session work.

    =A1@

    Likewise, when, say, C1 decides to provision an = LSP from C1 to C2 RSVP messages will need to be propagated between CE1 an= d CE2. Prior to that C1 needs to compute a TE path for the LSP, hence it = needs to know the attributes of, say, TE link CE2-C2, which could be achi= eved if routing and TE information is flooded over an IGP adjacency betwe= en CE1 and CE2. Mind that just the knowledge of the fact that C2 could be= reachable via CE2 is not sufficient =A1V there could be no TE path of th= e required parameters and quality available between CE2 and C2.
    =A1@

    The bottom line is that the Provider network needs to participate in pretty = much every aspect of the VPN control plane, and as scary as it sounds, th= e simplest way to accomplish this is to allow arbitrary control plane con= nectivity between CEs. If one assumes that VPN control plane is always IP= based, the phrase =A1=A7arbitrary control plane connectivity=A1=A8 could= be transformed into =A1=A7IP connectivity=A1=A8. However, generally spea= king, the VPN control plane may not necessarily be IP based.
    =A1@

    Igor

    =A1@

    =A1@


    Yahoo! Mail MobileTake Yahoo! Mail w= ith you! Check email on your = mobile phone.

    ____________________________________________= ______
    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam= protection around
    http://mail.yahoo.com=20 --0-1531668686-1115319441=:99826-- From rtg-dir-bounces@ietf.org Thu May 5 15:16:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02558 for ; Thu, 5 May 2005 15:16:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTm4C-0002LI-RI for rtg-dir-archive@ietf.org; Thu, 05 May 2005 15:31:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTlpk-0001vz-5g; Thu, 05 May 2005 15:16:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTlpj-0001uF-79 for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 15:16:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02536 for ; Thu, 5 May 2005 15:16:24 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTm45-0002Ko-18 for rtg-dir@ietf.org; Thu, 05 May 2005 15:31:17 -0400 Received: from du-069-0502.access.clara.net ([217.158.145.248] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DTlpg-000HeW-7s; Thu, 05 May 2005 20:16:25 +0100 Message-ID: <0b6001c551a7$370219c0$1c849ed9@Puppy> From: "Adrian Farrel" To: "Alex Zinin" , "Kireeti Kompella" References: <5.1.1.9.2.20050420152913.067fc360@imf.m.ecl.ntt.co.jp> <00a401c54845$754979a0$1c849ed9@Puppy> <314876349.20050503211842@psg.com> <20050504091948.U5472@kummer.juniper.net> <1123742435.20050504154724@psg.com> Date: Thu, 5 May 2005 20:04:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Igor Bryskin , rtg-dir@ietf.org, takeda.tomonori@lab.ntt.co.jp, dpapadimitriou@psg.com Subject: L1VPN in RTG or Internet? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit > > One question: what is the rationale for having L1VPN in the Routing > > Area, whereas L2VPN and L3VPN are in Internet? > > Looking back, I believe putting L2VPN and L3VPN in RTG was a big mistake. > A lot of complexity related to their work, as well as people involved are > in RTG. Same with L1VPN--it builds on the technology developed with RTG. I agree with Alex. But will we have a war in the IESG over this? Is there anything we need to do to prepare the ground? A From rtg-dir-bounces@ietf.org Thu May 5 15:20:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03005 for ; Thu, 5 May 2005 15:20:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTm7a-0002Yi-Am for rtg-dir-archive@ietf.org; Thu, 05 May 2005 15:34:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTlpp-0001xn-Fa; Thu, 05 May 2005 15:16:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTlpn-0001xC-Nw; Thu, 05 May 2005 15:16:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02550; Thu, 5 May 2005 15:16:29 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTm49-0002L4-39; Thu, 05 May 2005 15:31:21 -0400 Received: from du-069-0502.access.clara.net ([217.158.145.248] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DTlpj-000HeW-72; Thu, 05 May 2005 20:16:29 +0100 Message-ID: <0b6201c551a7$38a4cd40$1c849ed9@Puppy> From: "Adrian Farrel" To: "Alex Zinin" , References: <1414061909.20050505100317@psg.com> Date: Thu, 5 May 2005 20:15:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Thanks Alex (and the back-room boys) for putting this together. It is really great to see some forwards movement, and this is a very good start at a charter draft. Comments in line. Cheers, Adrian > Layer 1 Virtual Private Networks (l1vpn) > > Last Modified: 2005-05-05 > Chair(s): > TBD > TBD > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Technical Advisor(s): I think a TA would be really sensible. The WG is going to be touching the edges of a few signaling and routing protocols, as well as working with transport concepts - quite a broad spectrum. > Mailing Lists: > General Discussion: l1vpn@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn > Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html > > Description of Working Group: > > L1VPN Working Group's task is to specify mechanisms necessary for s/L1VPN/The L1VPN/ > providing a VPN service over a GMPLS transport network. Question: Is the definition of such a service and the statement of the requirements not part of the WG's task? While we can absorb some of the requirements as expressed by the ITU and also show them in the framework, some areas (like the enhanced mode [sig+rtg]) may need a little more work to capture the requirements before working on the specifications. > The following two service models will be addressed: > > 1. Basic mode: the CE-PE interface's functional repertoire is limited to > path setup signalling only. The GMPLS network is not involved in > distribution of user's routing information. > > 2. Enhanced mode: the CE-PE interface provides the signaling capabilities > as in the Basic mode, plus permits utilization of the provider's control > plane for distribution of some information from the user's control > plane (e.g. network-layer reachability information as in the MPLS/BGP model). These statements are fine, but they do not cover two other functional units. It may be that you intended to exclude these, but if so it would help to be explicit. a. Distribution of information about the provider's resources/topology over the CE-PE interface. b. Distribution of membership information from CE to PE (maybe you see this as "some information from the user's control plane", in which case, how about deleting the "(e.g. network-layer......)"?) > The WG will work on the following items: > > 1. Framework document defining the reference network model, L1VPN service > model, fundamental assumptions, and terminology. > I am not sure that the use of the established terms "UNI" and "NNI" are helpful in this context (below). It seems that they raise more questions than they answer. But most importantly, I don't think we should use terms in the charter without defining them in the charter. (This works well for basic and extended mode, above). > 2. Specification of the L1VPN user-to-network interface (UNI) basic mode, > including both CE and PE functionality. "Specification" is too loose a term. Does this mean specification of the architecture, function, requirements or protocol? > 3. Specification of the L1VPN node-to-node interface (NNI) basic mode. Do you mean "node-to-node" or "network-to-network"? > 4. MIB modules and/or extensions required for UNI and NNI basic mode. > > 5. Specification of L1VPN UNI enhanced mode. > > 6. Specification of L1VPN NNI enhanced mode. > > 7. MIB modules and/or extensions required for UNI and NNI enhanced mode. What about other OAM concerns? What about applicability guidance for choice between the four modes? Also, what about the existing "applicability" draft that discusses the applicability of various existing protocol models to satisfying the different L1VPN modes? Do you imagine this being broken up into the "specifications" above, or does it have value as an independent I-D? > Protocol extensions required for L1VPN will be done in cooperation with > CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. Where necessary, > the WG will also cooperate with ITU-T. I think "where necessary" is too unspecific (and, BTW, sounds hugely derogatory - which I am sure is not what you meant!). I suggest replacing with... The WG will also cooperate with the ITU-T in the development of L1VPN requirements and the statement of operational models. > > Milestones: > > Sep 05 Submit first Internet Draft of L1VPN framework > > Sep 05 Submit first Internet Drafts of UNI and NNI basic mode specifications > > Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic mode > > Apr 06 Submit UNI and NNI basic mode specifications to IESG for publication as Proposed Standard > > Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode specifications > > Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for publication as Proposed Standard > > Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for publication as Proposed Standard > > Dec 06 Submit L1VPN framework to IESG for publication as Informational RFC Why is this so late in the list? If you were talking about an architecture, I would understand why it is pretty much the final milestone, but I thought a framework should lead. That is, we shouldn't even start on the specifications until the framework is 90%+ cooked. > Aug 07 Submit MIB modules for UNI and NNI enhanced mode to IESG for publication as Proposed Standard Initial dates seem quite realistic. Later dates are, perhaps, a long way ahead. From rtg-dir-bounces@ietf.org Thu May 5 15:44:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05397 for ; Thu, 5 May 2005 15:44:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTmVM-0003dV-KW for rtg-dir-archive@ietf.org; Thu, 05 May 2005 15:59:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTmG8-0007Py-Nz; Thu, 05 May 2005 15:43:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTmG7-0007Pq-9n for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 15:43:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05327 for ; Thu, 5 May 2005 15:43:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTmUS-0003bY-FF for rtg-dir@ietf.org; Thu, 05 May 2005 15:58:33 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTmG3-000Csc-9g; Thu, 05 May 2005 19:43:39 +0000 Date: Thu, 5 May 2005 12:43:38 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <517962060.20050505124338@psg.com> To: "Adrian Farrel" In-Reply-To: <0b6001c551a7$370219c0$1c849ed9@Puppy> References: <5.1.1.9.2.20050420152913.067fc360@imf.m.ecl.ntt.co.jp> <00a401c54845$754979a0$1c849ed9@Puppy> <314876349.20050503211842@psg.com> <20050504091948.U5472@kummer.juniper.net> <1123742435.20050504154724@psg.com> <0b6001c551a7$370219c0$1c849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Igor Bryskin , dpapadimitriou@psg.com, takeda.tomonori@lab.ntt.co.jp, rtg-dir@ietf.org Subject: Re: L1VPN in RTG or Internet? X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Adrian, If there is one--it's my job to fight it. No worries. Alex > I agree with Alex. > But will we have a war in the IESG over this? Is there anything we need to > do to prepare the ground? > A From rtg-dir-bounces@ietf.org Thu May 5 16:10:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07756 for ; Thu, 5 May 2005 16:10:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTmuh-00051N-Bt for rtg-dir-archive@ietf.org; Thu, 05 May 2005 16:25:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTmfY-0004U3-3Q; Thu, 05 May 2005 16:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTmfX-0004Tv-7W; Thu, 05 May 2005 16:09:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07691; Thu, 5 May 2005 16:09:56 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTmtr-0004vb-CQ; Thu, 05 May 2005 16:24:49 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j45K9sLD028168; Thu, 5 May 2005 22:09:54 +0200 To: l1vpn@ietf.org MIME-Version: 1.0 Date: Thu, 5 May 2005 22:09:53 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/05/2005 22:09:54 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: rtg-dir@ietf.org Subject: L1VPN Work Status and Discussion Points X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Folks, During the evaluation of the L1VPN work status, several technical discussion points where identified concerning the CE and PE functionality that require further debate. Here below, a summary of this status and discussion points - indicated by (*) Please provide your comments/thoughts on this list CE functionality ---------------- 1) Reachability information (what prefixes are behind other CEs) Note: in the general case, those don't have to be IP Signaling model: - Manually configuration and/or transparent exchange (*) Discuss the need for an address resolution mechanism (note: as this mechanism is not L1VPN specific further discussion required as whether within or outside the scope) In any case need to ensure proper reachability information exchange among PE's such that incoming request can be routed toward the appropriate egress PE In a first phase, all VPN sites are managed by a single administrative entity (operator), and this entity knows prefixes behind other CEs. In the single carrier context, two cases are possible single vs multiple AS 2) Set of signaling parameters: the minimal set is the remote CE interface and basic connection characteristics (LSP Encoding Type, BW, etc). The current set of parameters in existing GMPLS RSVP-TE signaling documents (and related) are good enough to handle this case. Note: advanced traffic parameters may include more TE information to influence the LSP trajectory. Manually configured in the the sig-only and sig+rtg case. 3) How to signal the connection through the provider's cloud Parameters in existing GMPLS RSVP-TE signaling documents (and related) are good enough to signal the connection through the provider's cloud. As Provider's core nodes (PEs and Ps) and CEs all use GMPLS signaling, so no special procedures are required. 4) Status of established connections L1VPN connections being GMPLS LSPs, re-use of existing GMPLS control mechanisms can be used to monitor the status of these connections. (*) Provide further details for PathErr/ResvErr, Notify message exchange through (CE-PE boundary) e.g. IF_ID ERROR_SPEC object TLV; the Notify Request object processing and routing of the Notify message Note: mechanisms such as data plane OAM mechanisms are out of the scope PE functionality ---------------- 1) In the sig+rtg model, how to help CEs distribute reachability information + (in the per-VPN peer mode) may also need to expose some internal topology to the CEs Several mechanisms for CEs to distribute reachability information are detailed in the GVPN I-D. (*) The per-VPN peer model is conceptually similar to virtual routers; however as the implementation may be different additional thoughts could be required 2) CE's signaling notation As above (2) and 3) for CE functionality 3) How to process CE's signaling requests and translate them into internal GMPLS LSP requests. Several mechanisms are possible i.e. stitching and shuffling (application of the contiguous LSP signaling to the L1VPN context is introduced in Section 2.2 of the GVPN I-D). The latter requires address translation at PEs. (*) Further details required to support CE functionality (point 4) Nesting of the incoming CE-to-CE LSP into a network LSP also requires further details. (*) Further discussion expected concerning the set of signaling mechanisms to be progressed for L1VPN. 4) How to tell CEs about connection status Same as (4) for CE functionality From rtg-dir-bounces@ietf.org Thu May 5 16:17:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08283 for ; Thu, 5 May 2005 16:17:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTn17-0005J3-6D for rtg-dir-archive@ietf.org; Thu, 05 May 2005 16:32:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTml8-0005go-KP; Thu, 05 May 2005 16:15:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTml5-0005gc-Sm for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 16:15:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08156 for ; Thu, 5 May 2005 16:15:41 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTmzR-0005BY-OK for rtg-dir@ietf.org; Thu, 05 May 2005 16:30:34 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j45KFVP22703; Thu, 5 May 2005 16:15:32 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 May 2005 16:15:32 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0462282F@zcarhxm0.corp.nortel.com> From: "Hamid Ould-Brahim" To: Alex Zinin , l1vpn@ietf.org Date: Thu, 5 May 2005 16:15:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C551AF.27E387EA" X-Spam-Score: 0.8 (/) X-Scan-Signature: 354d6627469d0be959806e15912c47f1 Cc: rtg-dir@ietf.org Subject: RE: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d 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. ------_=_NextPart_001_01C551AF.27E387EA Content-Type: text/plain Alex, Quick comments on the charter...may have other comments later on. > > Layer 1 Virtual Private Networks (l1vpn) > > Last Modified: 2005-05-05 > Chair(s): > TBD > TBD > > Routing Area Director(s): > Bill Fenner > Alex Zinin > Just out of curiosity shouldn't this WG be as well within the internet area like l2 and l3vpns? Some functions are really similar to the ones developed in l2 and l3 vpns. Routing area is still fine (since ccamp is within this area anyway). > Routing Area Advisor: > Alex Zinin > > Technical Advisor(s): > > Mailing Lists: > General Discussion: l1vpn@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn > Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html > > Description of Working Group: > > L1VPN Working Group's task is to specify mechanisms > necessary for providing a VPN service over a GMPLS transport network. > The above should be more specific that is about L1VPN using GMPLS and across a GMPLS enabled network. A "VPN service over GMPLS" includes all VPN cases that GMPLS interfaces support while here we are looking specifically at l1vpn using gmpls. I believe that if we solve the GMPLS VPN for L1VPN then in fact we are actually solving a much bigger VPN problem set (the set of interfaces where GMPLS applies). And maybe it's much better to solve the GMPLS VPNs That include GMPLS L1 based interfaces then starting with L1VPN as a service since most of the mechanisms are not necessarily L1-based. Something along the line of Generalized VPNs. > The following two service models will be addressed: > > 1. Basic mode: the CE-PE interface's functional repertoire > is limited to > path setup signalling only. The GMPLS network is not involved in > distribution of user's routing information. > > 2. Enhanced mode: the CE-PE interface provides the > signaling capabilities > as in the Basic mode, plus permits utilization of the > provider's control > plane for distribution of some information from the > user's control > plane (e.g. network-layer reachability information as in > the MPLS/BGP model). > Is this referring to auto-discovery of L1VPN endpoints/nodes or to routing peering between CE and PE and have PE distribute CE relate routing? It looks like the text is about the latter not the former. > The WG will work on the following items: > > 1. Framework document defining the reference network model, > L1VPN service > model, fundamental assumptions, and terminology. > Should we as well add requirement document? I think we should (since this is a service after all). > 2. Specification of the L1VPN user-to-network interface > (UNI) basic mode, > including both CE and PE functionality. > > 3. Specification of the L1VPN node-to-node interface (NNI) > basic mode. > Not sure what we mean here by L1VPN node-to-node interface. Hamid. > 4. MIB modules and/or extensions required for UNI and NNI > basic mode. > > 5. Specification of L1VPN UNI enhanced mode. > > 6. Specification of L1VPN NNI enhanced mode. > > 7. MIB modules and/or extensions required for UNI and NNI > enhanced mode. > > Protocol extensions required for L1VPN will be done in > cooperation with CCAMP, OSPF, IS-IS, IDR, and other WGs > where necessary. Where necessary, the WG will also cooperate > with ITU-T. > > Milestones: > > Sep 05 Submit first Internet Draft of L1VPN framework > > Sep 05 Submit first Internet Drafts of UNI and NNI basic > mode specifications > > Dec 05 Submit first Internet Drafts of MIB modules for UNI > and NNI basic mode > > Apr 06 Submit UNI and NNI basic mode specifications to IESG > for publication as Proposed Standard > > Jun 06 Submit first Internet Drafts of UNI and NNI enhanced > mode specifications > > Aug 06 Submit MIB modules for UNI and NNI basic mode to > IESG for publication as Proposed Standard > > Dec 06 Submit UNI and NNI enhanced mode specifications to > IESG for publication as Proposed Standard > > Dec 06 Submit L1VPN framework to IESG for publication as > Informational RFC > > Aug 07 Submit MIB modules for UNI and NNI enhanced mode to > IESG for publication as Proposed Standard > > > > > > _______________________________________________ > L1vpn mailing list > L1vpn@lists.ietf.org https://www1.ietf.org/mailman/listinfo/l1vpn > > ------_=_NextPart_001_01C551AF.27E387EA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [L1vpn] Proposed charter for L1VPN WG

    Alex,

    Quick comments on the charter...may have other
    comments later on.

    >
    > Layer 1 Virtual Private Networks (l1vpn)
    >
    > Last Modified: 2005-05-05
    > Chair(s):
    >  TBD
    >  TBD
    >
    > Routing Area Director(s):
    >  Bill Fenner = <fenner@research.att.com>
    >  Alex Zinin <zinin@psg.com>
    >

    Just out of curiosity shouldn't this WG be as well = within
    the internet area like l2 and l3vpns?  Some = functions
    are really similar to the ones developed in l2 and = l3 vpns.

    Routing area is still fine (since ccamp is within = this area anyway).

    > Routing Area Advisor:
    >  Alex Zinin <zinin@psg.com>
    >
    > Technical Advisor(s):
    >
    > Mailing Lists:
    >  General Discussion: l1vpn@ietf.org
    >  To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn
    >  Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html<= /A>
    >
    > Description of Working Group:
    >
    >  L1VPN Working Group's task is to specify = mechanisms
    > necessary for  providing a VPN service = over a GMPLS transport network.
    >

    The above should be more specific that is about L1VPN = using GMPLS
    and across a GMPLS enabled network. A "VPN = service over GMPLS" includes
    all VPN cases that GMPLS interfaces support while = here
    we are looking specifically at l1vpn using gmpls. =

    I believe that if we solve the GMPLS VPN for = L1VPN
    then in fact we are actually solving a much bigger = VPN
    problem set (the set of interfaces where GMPLS = applies).
    And maybe it's much better to solve the GMPLS VPNs = That
    include GMPLS L1 based interfaces then starting = with
    L1VPN as a service since most of the mechanisms are = not
    necessarily L1-based. Something along the line of =
    Generalized VPNs.

    >  The following two service models will be = addressed:
    >
    >   1. Basic mode: the CE-PE = interface's functional repertoire
    > is limited to
    >      path setup = signalling only. The GMPLS network is not involved in
    >      distribution of = user's routing information.
    >
    >   2. Enhanced mode: the CE-PE = interface provides the
    > signaling capabilities
    >      as in the Basic = mode, plus permits utilization of the
    > provider's control
    >      plane for = distribution of some information from the
    > user's control
    >      plane (e.g. = network-layer reachability information as in
    > the MPLS/BGP model).
    >

    Is this referring to auto-discovery of L1VPN = endpoints/nodes
    or to routing peering between CE and PE and have PE = distribute
    CE relate routing? It looks like the text is about = the latter
    not the former.


    >  The WG will work on the following = items:
    >
    >   1. Framework document defining the = reference network model,
    > L1VPN service
    >      model, = fundamental assumptions, and terminology.
    >

    Should we as well add requirement document? I think = we should
    (since this is a service after all).



    >   2. Specification of the L1VPN = user-to-network interface
    > (UNI) basic mode,
    >      including both CE = and PE functionality.
    >
    >   3. Specification of the L1VPN = node-to-node interface (NNI)
    > basic mode.
    >

    Not sure what we mean here by L1VPN node-to-node = interface.

    Hamid.


    >   4. MIB modules and/or extensions = required for UNI and NNI
    > basic mode.
    >
    >   5. Specification of L1VPN UNI = enhanced mode.
    >
    >   6. Specification of L1VPN NNI = enhanced mode.
    >
    >   7. MIB modules and/or extensions = required for UNI and NNI
    > enhanced mode.
    >
    >  Protocol extensions required for L1VPN = will be done in
    > cooperation with  CCAMP, OSPF, IS-IS, IDR, = and other WGs
    > where necessary. Where necessary,  the WG = will also cooperate
    > with ITU-T.
    >
    > Milestones:
    >
    >   Sep 05 Submit first Internet Draft = of L1VPN framework
    >
    >   Sep 05 Submit first Internet Drafts = of UNI and NNI basic
    > mode specifications
    >
    >   Dec 05 Submit first Internet Drafts = of MIB modules for UNI
    > and NNI basic mode
    >
    >   Apr 06 Submit UNI and NNI basic = mode specifications to IESG
    > for publication as Proposed Standard
    >
    >   Jun 06 Submit first Internet Drafts = of UNI and NNI enhanced
    > mode specifications
    >
    >   Aug 06 Submit MIB modules for UNI = and NNI basic mode to
    > IESG for publication as Proposed = Standard
    >
    >   Dec 06 Submit UNI and NNI enhanced = mode specifications to
    > IESG for publication as Proposed = Standard
    >
    >   Dec 06 Submit L1VPN framework to = IESG for publication as
    > Informational RFC
    >
    >   Aug 07 Submit MIB modules for UNI = and NNI enhanced mode to
    > IESG for publication as Proposed = Standard
    >
    >
    >
    >
    >
    > = _______________________________________________
    > L1vpn mailing list
    > L1vpn@lists.ietf.org     https://www1.ietf.org/mailman/listinfo/l1vpn
    >
    >

    ------_=_NextPart_001_01C551AF.27E387EA-- From rtg-dir-bounces@ietf.org Thu May 5 16:48:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15087 for ; Thu, 5 May 2005 16:48:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnV4-00083B-Gf for rtg-dir-archive@ietf.org; Thu, 05 May 2005 17:03:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnFs-0005br-4i; Thu, 05 May 2005 16:47:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnFo-0005Zv-S9 for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 16:47:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14565 for ; Thu, 5 May 2005 16:47:25 -0400 (EDT) Received: from web30811.mail.mud.yahoo.com ([68.142.201.254]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTnU8-0007rX-Bp for rtg-dir@ietf.org; Thu, 05 May 2005 17:02:19 -0400 Received: (qmail 93378 invoked by uid 60001); 5 May 2005 20:47:16 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=AVPY16VMNH7DV0hZdwOA3kjkl4bh67/aGF2mnS70vbb3hh7FAgp0y2PjDzA4lHnHtc+RYEHN+B3Xiler9lNQG4hhtiBHE8JjuYbOVQzPZeIOtCzIVk4c60YAQ/hKAt3QlmuuJOzHinksmIkvuW1DWA3i1H4wpAb9KjiH2UfTOlc= ; Message-ID: <20050505204716.93376.qmail@web30811.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30811.mail.mud.yahoo.com via HTTP; Thu, 05 May 2005 13:47:16 PDT Date: Thu, 5 May 2005 13:47:16 -0700 (PDT) From: Igor Bryskin To: Dimitri.Papadimitriou@alcatel.be In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-730185624-1115326036=:89377" X-Spam-Score: 0.7 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Alex Zinin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb --0-730185624-1115326036=:89377 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA14565 Content-Transfer-Encoding: quoted-printable Dimitri, > - concerning the exchange of other control plane information the L1VPN = models described since so > far does not assume something different from = what has been developed in the GMPLS overlay context > i.e. the connection at the SDH/circuit level is used by the client cont= rol plane to exchange its > own control plane information, in case dedica= ted channel are required - for instance when the > client network wants t= o maintain an out of band control channel - that is to be established ove= r > a dedicated VC-4-Xc IB>> True, but only if controllers can insert/extract control plane packe= ts to/from the SDH payload. [dp] most routers, IP/MPLS LSR and co. supporting PoS interfaces are perf= ectly capable to support such functionality - did you have any other equi= pment in mind ? (same applies for ETH o SDH equipment supporting IP based= control plane) IB>> What if CEs are TDM LSRs and the CE-CE connection is a lambda LSP? Igor Igor Bryskin Sent by: rtg-dir-bounces@ietf.org 05/05/2005 08:18 MST To: Alex Zinin cc: Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp, rtg-dir@ietf.org, Dimitri PAPADIMI= TRIOU/BE/ALCATEL@ALCATEL bcc:=20 Subject: Re: Draft L1VPN Charter Alex, =A1@ See in-line. =A1@ Igor Alex Zinin wrote:=20 Igor, > 2. Enhanced mode: the CE-PE interface provides the signaling capabiliti= es > as in the Basic mode, plus permits utilization of the provider's contro= l > plane for distribution of user's routing information (e.g. similar to t= he > MPLS/BGP model). > I=F9=FEd like to replace this with: > 2. Enhanced mode: the CE-PE interface provides the signaling capabiliti= es > as in the Basic mode, plus permits utilization of the provider's contro= l > plane for distribution of user's arbitrary control plane information > between the VPN sites including but not limited to routing information. > Provider network IHMO should make no assumptions on what protocols are > running within VPNs. Generally speaking, a L1VPN user is not necessaril= y > GMPLS controlled network. Furthermore, even in case it does use GMPLS i= t > needs L1VPN CE-CE connections to provide (TE) links within VPNs. > Specifically, the User should be capable to run LMP for such links, it > also should be possible to establish signaling (RSVP) adjacencies betwe= en > their ends, etc. The bottom line is that distribution of routing > information between CEs IHMO is not sufficient. I believe this is > consistent with the requirements stated in ITU-T SG13 L1VPN do! cuments= =20 Distributing "arbitrary" control plane information is a scary idea. In fact, I should really change that to "reachability" to be even more specific. Igor, could you explain how representing CE-CE connections as TE links an= d running LMP over them requires additional info to be distributed by the cloud's control plane? Alex =A1@ Let=A1=A6s consider a very simple VPN view: =A1@ C1-----CE1=3D=3D=3D=3D=3D=3D=3D=3DCE2-----C2 =A1@ In order for CE1 and CE2 discover TE link CE1-CE2 they may try to use LMP= which requires exchange of IP packets between CE1 and CE2, The fact that= there is a data plane connectivity between CE1 and CE2 (realized via L1V= PN connection) does not necessa! rily mean that CE1 and CE2 can use this = connection for the purpose of exchanging IP packets. Consider, for instan= ce, the situation when CE1 and CE2 are SDH cross-connects and the CE1-CE2= connection is a VC4-4c LSP. Hence, the Provider network needs to partici= pate in the out-of-band IP packet delivery to make CE1-CE2 LMP session wo= rk. =A1@ Likewise, when, say, C1 decides to provision an LSP from C1 to C2 RSVP me= ssages will need to be propagated between CE1 and CE2. Prior to that C1 n= eeds to compute a TE path for the LSP, hence it needs to know the attribu= tes of, say, TE link CE2-C2, which could be achieved if routing and TE in= formation is flooded over an IGP adjacency between CE1 and CE2. Mind that= just the knowledge of the fact that C2 could be reachable via CE2 is not= sufficient =A1V there could be no TE path of the required parameters and= quality available between CE2 and C2. =A1@ ! The bottom line is that the Provider network needs to participate in pr= etty much every aspect of the VPN control plane, and as scary as it sound= s, the simplest way to accomplish this is to allow arbitrary control plan= e connectivity between CEs. If one assumes that VPN control plane is alwa= ys IP based, the phrase =A1=A7arbitrary control plane connectivity=A1=A8 = could be transformed into =A1=A7IP connectivity=A1=A8. However, generally= speaking, the VPN control plane may not necessarily be IP based. =A1@ Igor =A1@ =A1@ --------------------------------- Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone.=20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 =09 --------------------------------- Do you Yahoo!? Yahoo! Mail - You care about security. So do we. --0-730185624-1115326036=:89377 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA14565 Content-Transfer-Encoding: quoted-printable
    Dimitri,

    > - concerning the exchange of other= control plane information the L1VPN models described since so > far d= oes not assume something different from what has been developed in the GM= PLS overlay context

    > i.e. the connection at the SDH/cir= cuit level is used by the client control plane to exchange its > own c= ontrol plane information, in case dedicated channel are required - for in= stance when the > client network wants to maintain an out of band cont= rol channel - that is to be established over > a dedicated VC-4-Xc
    =
    IB>> True, but only if controllers can insert/extract control p= lane packets to/from the SDH payload.

    [dp] most routers, IP/MPLS LSR and co. = supporting PoS interfaces are perfectly capable to support such functiona= lity - did you have any other equipment in mind ? (same applies for ETH o= SDH equipment supporting IP based control plane)

    IB>> What if CEs are TDM LSRs and the= CE-CE connection is a lambda LSP?

    <= /FONT>

    Igor




    Igor Bryskin <i_bryskin@yahoo.com= >
    Sent by: rtg-dir-bounces@ietf.org
    05/05/2005 08:18 MST
    =
    To: Alex Zinin <zinin@psg.com>
    cc:     Kireeti Kompella <kireeti@juniper.net>, Adrian F= arrel <adrian@olddog.co.uk>, takeda.tomonori@lab.ntt.co.jp, rtg-dir= @ietf.org, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
    bcc:
    Subject: Re: Draft L1VPN Charter

    Alex,

    =A1@
    See in-line.

    =A1@
    Igor

    Alex Zinin &l= t;zinin@psg.com> wrote:

    Igor,

    > 2. Enhanced mode: the CE-PE interface pro= vides the signaling capabilities
    > as in the = Basic mode, plus permits utilization of the provider's control
    = > plane for distribution of user's routing information (e.g.= similar to the
    > MPLS/BGP model).
    =
    > I=F9=FEd like to replace this with:
    > 2. Enhanced mode: the CE-PE interface provides the s= ignaling capabilities
    > as in the Basic mode,= plus permits utilization of the provider's control
    > plane for distribution of user's arbitrary control plane informati= on
    > between the VPN sites including but not = limited to routing information.

    > Provide= r network IHMO should make no assumptions on what protocols are> running within VPNs. Generally speaking, a L1VPN use= r is not necessarily
    > GMPLS controlled netwo= rk. Furthermore, even in case it does use GMPLS it
    > needs L1VPN CE-CE connections to provide (TE) links within VPNs.
    > Specifically, the User should be cap= able to run LMP for such links, it
    > also sho= uld be possible to establish signaling (RSVP) adjacencies between<= BR>> their ends, etc. The bottom line is that distribut= ion of routing
    > information between CEs IHMO= is not sufficient. I believe this is
    > consi= stent with the requirements stated in ITU-T SG13 L1VPN do! cuments

    Distributing "arbitrary" control plane informatio= n is a scary idea. In
    fact, I should really chan= ge that to "reachability" to be even more
    specif= ic.

    Igor, could you explain how representing= CE-CE connections as TE links and
    running LMP o= ver them requires additional info to be distributed by the
    cloud's control plane?

    Alex

    =A1@

    Let=A1=A6s consider a very simple VPN view:

    =A1@

    C1-----CE1=3D=3D=3D=3D=3D=3D=3D=3D= CE2-----C2

    =A1@

    In order for CE1 and CE2 discover TE link CE1-CE2 they may try to use L= MP which requires exchange of IP packets between CE1 and CE2, The fact th= at there is a data plane connectivity between CE1 and CE2 (realized via L= 1VPN connection) does not necessa! rily mean that CE1 and CE2 can use thi= s connection for the purpose of exchanging IP packets. Consider, for inst= ance, the situation when CE1 and CE2 are SDH cross-connects and the CE1-C= E2 connection is a VC4-4c LSP. Hence, the Provider network needs to parti= cipate in the out-of-band IP packet delivery to make CE1-CE2 LMP session = work.

    =A1@

    Like= wise, when, say, C1 decides to provision an LSP from C1 to C2 RSVP messag= es will need to be propagated between CE1 and CE2. Prior to that C1 needs to compute a TE p= ath for the LSP, hence it needs to know the attributes of, say, TE link C= E2-C2, which could be achieved if routing and TE information is flooded o= ver an IGP adjacency between CE1 and CE2. Mind that just the knowledge of= the fact that C2 could be reachable via CE2 is not sufficient =A1V there= could be no TE path of the required parameters and quality available bet= ween CE2 and C2.

    =A1@

    ! The bottom line is that the Provider network needs to participat= e in pretty much every aspect of the VPN control plane, and as scary as i= t sounds, the simplest way to accomplish this is to allow arbitrary contr= ol plane connectivity between CEs. If one assumes that VPN control plane = is always IP based, the phrase =A1=A7arbitrary control plane connectivity= =A1=A8 could be transformed into =A1=A7IP connectivity=A1=A8. However, ge= nerally speaking, the VPN control plane may not necessarily be IP based.

    =A1@

    Ig= or

    =A1@

    =A1@


    Yahoo! Mail MobileTake Yahoo! Mail w= ith you! Check email on your = mobile phone.

    _______= ___________________________________________
    Do Y= ou Yahoo!?
    Tired of spam? Yahoo! Mail has the be= st spam protection around
    http://mail.yahoo.com

    Do you Yahoo!?
    =20 Yahoo! Mail - You ca= re about security. So do we. --0-730185624-1115326036=:89377-- From rtg-dir-bounces@ietf.org Thu May 5 16:54:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16213 for ; Thu, 5 May 2005 16:54:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnap-00006K-Sb for rtg-dir-archive@ietf.org; Thu, 05 May 2005 17:09:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnMC-00010m-AC; Thu, 05 May 2005 16:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnM7-0000xn-Tu for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 16:54:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16185 for ; Thu, 5 May 2005 16:53:57 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnaT-00005u-F6 for rtg-dir@ietf.org; Thu, 05 May 2005 17:08:50 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j45KruLD030481; Thu, 5 May 2005 22:53:56 +0200 To: Igor Bryskin MIME-Version: 1.0 Date: Thu, 5 May 2005 22:53:54 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/05/2005 22:53:56 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Alex Zinin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a igor, > - concerning the exchange of other control plane information the L1VPN > models described since so far does not assume something different from > what has been developed in the GMPLS overlay context > i.e. the connection at the SDH/circuit level is used by the client control > plane to exchange its own control plane information, in case dedicated > channel are required - for instance when the > client network wants to > maintain an out of band control channel - that is to be established over > a dedicated VC-4-Xc IB>> True, but only if controllers can insert/extract control plane packets to/from the SDH payload. [dp] most routers, IP/MPLS LSR and co. supporting PoS interfaces are perfectly capable to support such functionality - did you have any other equipment in mind ? (same applies for ETH o SDH equipment supporting IP based control plane) IB>> What if CEs are TDM LSRs and the CE-CE connection is a lambda LSP? [dp] simply by using the RS-DCC or MS-DCC which is then transparent and over which IP control packets can be exchanged using RFC 1662 From rtg-dir-bounces@ietf.org Thu May 5 17:18:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18676 for ; Thu, 5 May 2005 17:18:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnyG-0001Ln-As for rtg-dir-archive@ietf.org; Thu, 05 May 2005 17:33:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnjB-0000n3-TD; Thu, 05 May 2005 17:17:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnjA-0000mZ-IP for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 17:17:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18622 for ; Thu, 5 May 2005 17:17:45 -0400 (EDT) Received: from web30813.mail.mud.yahoo.com ([68.142.201.139]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTnxV-0001KR-C2 for rtg-dir@ietf.org; Thu, 05 May 2005 17:32:39 -0400 Received: (qmail 86437 invoked by uid 60001); 5 May 2005 21:17:37 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=tV4xvY4sUfv67S+zAZ35UwuqmMK3dfD2TI4LAYPnxDlErKS1Qde4WDCfE7TGfNhJWfrGxBRG1mwVnqpB8FEZ3Usks44Fr4A3E8FGt71CPh+OluajSpZrSm0BkIA5KyKl1KlkJjnryxWK0fBB919xeWy4Jv3GLEpEH+hAtqVKXfo= ; Message-ID: <20050505211737.86435.qmail@web30813.mail.mud.yahoo.com> Received: from [67.102.145.11] by web30813.mail.mud.yahoo.com via HTTP; Thu, 05 May 2005 14:17:37 PDT Date: Thu, 5 May 2005 14:17:37 -0700 (PDT) From: Igor Bryskin To: Dimitri.Papadimitriou@alcatel.be In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1546524587-1115327857=:82360" X-Spam-Score: 0.5 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Alex Zinin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab --0-1546524587-1115327857=:82360 Content-Type: text/plain; charset=us-ascii Dimitri, Are saying that in general if you have a pair of nodes interconnected by a link in any network layer it is always possible to have the nodes exchange control plane (IP) messages over this link by, say, using overhead bits of a server layer? Do you also believe that the bandwidth that could be used by control plane in this way is always adecuade for all its needs? Why do we need the out-of-band signaling then? Igor Dimitri.Papadimitriou@alcatel.be wrote: igor, > - concerning the exchange of other control plane information the L1VPN > models described since so far does not assume something different from > what has been developed in the GMPLS overlay context > i.e. the connection at the SDH/circuit level is used by the client control > plane to exchange its own control plane information, in case dedicated > channel are required - for instance when the > client network wants to > maintain an out of band control channel - that is to be established over > a dedicated VC-4-Xc IB>> True, but only if controllers can insert/extract control plane packets to/from the SDH payload. [dp] most routers, IP/MPLS LSR and co. supporting PoS interfaces are perfectly capable to support such functionality - did you have any other equipment in mind ? (same applies for ETH o SDH equipment supporting IP based control plane) IB>> What if CEs are TDM LSRs and the CE-CE connection is a lambda LSP? [dp] simply by using the RS-DCC or MS-DCC which is then transparent and over which IP control packets can be exchanged using RFC 1662 --------------------------------- Discover Yahoo! Get on-the-go sports scores, stock quotes, news & more. Check it out! --0-1546524587-1115327857=:82360 Content-Type: text/html; charset=us-ascii
    Dimitri,
     
    Are saying that in general if you have a pair of nodes interconnected by a link in any network layer it is always possible to have the nodes exchange control plane (IP) messages over this link by, say,  using overhead bits of a server layer? Do you also believe that the bandwidth that could be used by control plane in this way is always adecuade for all its needs? Why do we need the out-of-band signaling then?
     
    Igor

    Dimitri.Papadimitriou@alcatel.be wrote:

    igor,

    > - concerning the exchange of other control plane information the L1VPN
    > models described since so far does not assume something different from
    > what has been developed in the GMPLS overlay context

    > i.e. the connection at the SDH/circuit level is used by the client
    control
    > plane to exchange its own control plane information, in case dedicated
    > channel are required - for instance when the > client network wants to
    > maintain an out of band control channel - that is to be established over
    > a dedicated VC-4-Xc

    IB>> True, but only if controllers can insert/extract control plane packets
    to/from the SDH payload.

    [dp] most routers, IP/MPLS LSR and co. supporting PoS interfaces are
    perfectly capable to support such functionality - did you have any other
    equipment in mind ? (sa! me applies for ETH o SDH equipment supporting IP
    based control plane)

    IB>> What if CEs are TDM LSRs and the CE-CE connection is a lambda LSP?

    [dp] simply by using the RS-DCC or MS-DCC which is then transparent and
    over
    which IP control packets can be exchanged using RFC 1662


    Discover Yahoo!
    Get on-the-go sports scores, stock quotes, news & more. Check it out! --0-1546524587-1115327857=:82360-- From rtg-dir-bounces@ietf.org Thu May 5 17:27:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20385 for ; Thu, 5 May 2005 17:27:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTo7N-00027A-MY for rtg-dir-archive@ietf.org; Thu, 05 May 2005 17:42:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnkg-0001MA-FF; Thu, 05 May 2005 17:19:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTnkd-0001Ll-Cb for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 17:19:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18785 for ; Thu, 5 May 2005 17:19:16 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTnyz-0001Mn-U9 for rtg-dir@ietf.org; Thu, 05 May 2005 17:34:10 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j45LIaL27757 for ; Thu, 5 May 2005 17:18:36 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 May 2005 17:18:59 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D046228E9@zcarhxm0.corp.nortel.com> From: "Hamid Ould-Brahim" To: l1vpn@ietf.org Date: Thu, 5 May 2005 17:18:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C551B8.073BD1B4" X-Spam-Score: 0.8 (/) X-Scan-Signature: 354d6627469d0be959806e15912c47f1 Cc: rtg-dir@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d 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. ------_=_NextPart_001_01C551B8.073BD1B4 Content-Type: text/plain Alex, Quick comments on the charter...may have other comments later on. > > Layer 1 Virtual Private Networks (l1vpn) > > Last Modified: 2005-05-05 > Chair(s): > TBD > TBD > > Routing Area Director(s): > Bill Fenner > Alex Zinin > Just out of curiosity shouldn't this WG be as well within the internet area like l2 and l3vpns? Some functions are really similar to the ones developed in l2 and l3 vpns. Routing area is still fine (since ccamp is within this area anyway). > Routing Area Advisor: > Alex Zinin > > Technical Advisor(s): > > Mailing Lists: > General Discussion: l1vpn@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn > Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html > > Description of Working Group: > > L1VPN Working Group's task is to specify mechanisms > necessary for providing a VPN service over a GMPLS transport network. > The above should be more specific that is about L1VPN using GMPLS and across a GMPLS enabled network. A "VPN service over GMPLS" includes all VPN cases that GMPLS interfaces support while here we are looking specifically at l1vpn using gmpls. I believe that if we solve the GMPLS VPN for L1VPN then in fact we are actually solving a much bigger VPN problem set (the set of interfaces where GMPLS applies). And maybe it's much better to solve the GMPLS VPNs That include GMPLS L1 based interfaces then starting with L1VPN as a service since most of the mechanisms are not necessarily L1-based. Something along the line of Generalized VPNs. > The following two service models will be addressed: > > 1. Basic mode: the CE-PE interface's functional repertoire > is limited to > path setup signalling only. The GMPLS network is not involved in > distribution of user's routing information. > > 2. Enhanced mode: the CE-PE interface provides the > signaling capabilities > as in the Basic mode, plus permits utilization of the > provider's control > plane for distribution of some information from the > user's control > plane (e.g. network-layer reachability information as in > the MPLS/BGP model). > Is this referring to auto-discovery of L1VPN endpoints/nodes or to routing peering between CE and PE and have PE distribute CE relate routing? It looks like the text is about the latter not the former. > The WG will work on the following items: > > 1. Framework document defining the reference network model, > L1VPN service > model, fundamental assumptions, and terminology. > Should we as well add requirement document? I think we should (since this is a service after all). > 2. Specification of the L1VPN user-to-network interface > (UNI) basic mode, > including both CE and PE functionality. > > 3. Specification of the L1VPN node-to-node interface (NNI) > basic mode. > Not sure what we mean here by L1VPN node-to-node interface. Hamid. > 4. MIB modules and/or extensions required for UNI and NNI > basic mode. > > 5. Specification of L1VPN UNI enhanced mode. > > 6. Specification of L1VPN NNI enhanced mode. > > 7. MIB modules and/or extensions required for UNI and NNI > enhanced mode. > > Protocol extensions required for L1VPN will be done in > cooperation with CCAMP, OSPF, IS-IS, IDR, and other WGs > where necessary. Where necessary, the WG will also cooperate > with ITU-T. > > Milestones: > > Sep 05 Submit first Internet Draft of L1VPN framework > > Sep 05 Submit first Internet Drafts of UNI and NNI basic > mode specifications > > Dec 05 Submit first Internet Drafts of MIB modules for UNI > and NNI basic mode > > Apr 06 Submit UNI and NNI basic mode specifications to IESG > for publication as Proposed Standard > > Jun 06 Submit first Internet Drafts of UNI and NNI enhanced > mode specifications > > Aug 06 Submit MIB modules for UNI and NNI basic mode to > IESG for publication as Proposed Standard > > Dec 06 Submit UNI and NNI enhanced mode specifications to > IESG for publication as Proposed Standard > > Dec 06 Submit L1VPN framework to IESG for publication as > Informational RFC > > Aug 07 Submit MIB modules for UNI and NNI enhanced mode to > IESG for publication as Proposed Standard > > > > > > _______________________________________________ > L1vpn mailing list > L1vpn@lists.ietf.org https://www1.ietf.org/mailman/listinfo/l1vpn > > ------_=_NextPart_001_01C551B8.073BD1B4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Re: [L1vpn] Proposed charter for L1VPN WG

    Alex,

    Quick comments on the charter...may have other
    comments later on.

    >
    > Layer 1 Virtual Private Networks (l1vpn)
    >
    > Last Modified: 2005-05-05
    > Chair(s):
    >  TBD
    >  TBD
    >
    > Routing Area Director(s):
    >  Bill Fenner = <fenner@research.att.com>
    >  Alex Zinin <zinin@psg.com>
    >

    Just out of curiosity shouldn't this WG be as well = within
    the internet area like l2 and l3vpns?  Some = functions
    are really similar to the ones developed in l2 and = l3 vpns.

    Routing area is still fine (since ccamp is within = this area anyway).

    > Routing Area Advisor:
    >  Alex Zinin <zinin@psg.com>
    >
    > Technical Advisor(s):
    >
    > Mailing Lists:
    >  General Discussion: l1vpn@ietf.org
    >  To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn
    >  Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html<= /A>
    >
    > Description of Working Group:
    >
    >  L1VPN Working Group's task is to specify = mechanisms
    > necessary for  providing a VPN service = over a GMPLS transport network.
    >

    The above should be more specific that is about L1VPN = using GMPLS
    and across a GMPLS enabled network. A "VPN = service over GMPLS" includes
    all VPN cases that GMPLS interfaces support while = here
    we are looking specifically at l1vpn using gmpls. =

    I believe that if we solve the GMPLS VPN for = L1VPN
    then in fact we are actually solving a much bigger = VPN
    problem set (the set of interfaces where GMPLS = applies).
    And maybe it's much better to solve the GMPLS VPNs = That
    include GMPLS L1 based interfaces then starting = with
    L1VPN as a service since most of the mechanisms are = not
    necessarily L1-based. Something along the line of =
    Generalized VPNs.

    >  The following two service models will be = addressed:
    >
    >   1. Basic mode: the CE-PE = interface's functional repertoire
    > is limited to
    >      path setup = signalling only. The GMPLS network is not involved in
    >      distribution of = user's routing information.
    >
    >   2. Enhanced mode: the CE-PE = interface provides the
    > signaling capabilities
    >      as in the Basic = mode, plus permits utilization of the
    > provider's control
    >      plane for = distribution of some information from the
    > user's control
    >      plane (e.g. = network-layer reachability information as in
    > the MPLS/BGP model).
    >

    Is this referring to auto-discovery of L1VPN = endpoints/nodes
    or to routing peering between CE and PE and have PE = distribute
    CE relate routing? It looks like the text is about = the latter
    not the former.


    >  The WG will work on the following = items:
    >
    >   1. Framework document defining the = reference network model,
    > L1VPN service
    >      model, = fundamental assumptions, and terminology.
    >

    Should we as well add requirement document? I think = we should
    (since this is a service after all).



    >   2. Specification of the L1VPN = user-to-network interface
    > (UNI) basic mode,
    >      including both CE = and PE functionality.
    >
    >   3. Specification of the L1VPN = node-to-node interface (NNI)
    > basic mode.
    >

    Not sure what we mean here by L1VPN node-to-node = interface.

    Hamid.


    >   4. MIB modules and/or extensions = required for UNI and NNI
    > basic mode.
    >
    >   5. Specification of L1VPN UNI = enhanced mode.
    >
    >   6. Specification of L1VPN NNI = enhanced mode.
    >
    >   7. MIB modules and/or extensions = required for UNI and NNI
    > enhanced mode.
    >
    >  Protocol extensions required for L1VPN = will be done in
    > cooperation with  CCAMP, OSPF, IS-IS, IDR, = and other WGs
    > where necessary. Where necessary,  the WG = will also cooperate
    > with ITU-T.
    >
    > Milestones:
    >
    >   Sep 05 Submit first Internet Draft = of L1VPN framework
    >
    >   Sep 05 Submit first Internet Drafts = of UNI and NNI basic
    > mode specifications
    >
    >   Dec 05 Submit first Internet Drafts = of MIB modules for UNI
    > and NNI basic mode
    >
    >   Apr 06 Submit UNI and NNI basic = mode specifications to IESG
    > for publication as Proposed Standard
    >
    >   Jun 06 Submit first Internet Drafts = of UNI and NNI enhanced
    > mode specifications
    >
    >   Aug 06 Submit MIB modules for UNI = and NNI basic mode to
    > IESG for publication as Proposed = Standard
    >
    >   Dec 06 Submit UNI and NNI enhanced = mode specifications to
    > IESG for publication as Proposed = Standard
    >
    >   Dec 06 Submit L1VPN framework to = IESG for publication as
    > Informational RFC
    >
    >   Aug 07 Submit MIB modules for UNI = and NNI enhanced mode to
    > IESG for publication as Proposed = Standard
    >
    >
    >
    >
    >
    > = _______________________________________________
    > L1vpn mailing list
    > L1vpn@lists.ietf.org     https://www1.ietf.org/mailman/listinfo/l1vpn
    >
    >

    ------_=_NextPart_001_01C551B8.073BD1B4-- From rtg-dir-bounces@ietf.org Thu May 5 17:36:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21935 for ; Thu, 5 May 2005 17:36:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DToFW-0002pN-Is for rtg-dir-archive@ietf.org; Thu, 05 May 2005 17:51:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTo0e-0007zO-UK; Thu, 05 May 2005 17:35:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTo0d-0007yg-DF for rtg-dir@megatron.ietf.org; Thu, 05 May 2005 17:35:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21886 for ; Thu, 5 May 2005 17:35:48 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DToF0-0002o7-Ay for rtg-dir@ietf.org; Thu, 05 May 2005 17:50:42 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j45LZUP06335 for ; Thu, 5 May 2005 17:35:31 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 May 2005 17:35:31 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D04622905@zcarhxm0.corp.nortel.com> From: "Hamid Ould-Brahim" To: Adrian Farrel , Alex Zinin , l1vpn@ietf.org Date: Thu, 5 May 2005 17:35:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C551BA.571554DE" X-Spam-Score: 0.5 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: rtg-dir@ietf.org Subject: RE: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e 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. ------_=_NextPart_001_01C551BA.571554DE Content-Type: text/plain Adrian, [clipped...] > > > providing a VPN service over a GMPLS transport network. > > Question: Is the definition of such a service and the > statement of the requirements not part of the WG's task? > While we can absorb some of the requirements as expressed by > the ITU and also show them in the framework, some areas (like > the enhanced mode > [sig+rtg]) may need a little more work to capture the > requirements before working on the specifications. > Agreed. One option (like we did in l3vpn wg) is to reuse the ITU requirement doc (as internet draft) and work on it. > > The following two service models will be addressed: > > > > 1. Basic mode: the CE-PE interface's functional repertoire is > > limited > to > > path setup signalling only. The GMPLS network is not > involved in > > distribution of user's routing information. > > > > 2. Enhanced mode: the CE-PE interface provides the signaling > capabilities > > as in the Basic mode, plus permits utilization of the > provider's > control > > plane for distribution of some information from the > user's control > > plane (e.g. network-layer reachability information as in the > MPLS/BGP model). > > These statements are fine, but they do not cover two other > functional units. It may be that you intended to exclude > these, but if so it would help to be explicit. a. > Distribution of information about the provider's > resources/topology over the CE-PE interface. > b. Distribution > of membership information from CE to PE (maybe you see this > as "some information from the user's control plane", in which > case, how about deleting the "(e.g. network-layer......)"?) > Yes. This can include as well provider network helping the CEs to discover each other. I suggest instead of specifying just membership b could be: "b. Distribution of CE to PE related information (such as L1VPN membership, site address information, CE routing information, etc." > > The WG will work on the following items: > > > > 1. Framework document defining the reference network model, L1VPN > service > > model, fundamental assumptions, and terminology. > > > > I am not sure that the use of the established terms "UNI" and > "NNI" are helpful in this context (below). It seems that they > raise more questions than they answer. > Agreed. Hamid. ------_=_NextPart_001_01C551BA.571554DE Content-Type: text/html RE: [L1vpn] Proposed charter for L1VPN WG

    Adrian,

    [clipped...]

    >
    > >  providing a VPN service over a GMPLS transport network.
    >
    > Question: Is the definition of such a service and the
    > statement of the requirements not part of the WG's task?
    > While we can absorb some of the requirements as expressed by
    > the ITU and also show them in the framework, some areas (like
    > the enhanced mode
    > [sig+rtg]) may need a little more work to capture the
    > requirements before working on the specifications.
    >

    Agreed. One option (like we did in l3vpn wg) is to reuse the
    ITU requirement doc (as internet draft) and  work on it.


    > >  The following two service models will be addressed:
    > >
    > >   1. Basic mode: the CE-PE interface's functional repertoire is
    > > limited
    > to
    > >      path setup signalling only. The GMPLS network is not
    > involved in
    > >      distribution of user's routing information.
    > >
    > >   2. Enhanced mode: the CE-PE interface provides the signaling
    > capabilities
    > >      as in the Basic mode, plus permits utilization of the
    > provider's
    > control
    > >      plane for distribution of some information from the
    > user's control
    > >      plane (e.g. network-layer reachability information as in the
    > MPLS/BGP model).
    >
    > These statements are fine, but they do not cover two other
    > functional units. It may be that you intended to exclude
    > these, but if so it would help to be explicit. a.
    > Distribution of information about the provider's
    > resources/topology over the CE-PE interface.


    > b. Distribution
    > of membership information from CE to PE (maybe you see this
    > as "some information from the user's control plane", in which
    > case, how about deleting the "(e.g. network-layer......)"?)
    >

    Yes. This can include as well provider network helping the CEs to
    discover each other. I suggest instead of specifying just
    membership b could be:

    "b. Distribution of CE to PE related information (such as L1VPN membership,
        site address information, CE routing information, etc."

    > >  The WG will work on the following items:
    > >
    > >   1. Framework document defining the reference network model, L1VPN
    > service
    > >      model, fundamental assumptions, and terminology.
    > >
    >
    > I am not sure that the use of the established terms "UNI" and
    > "NNI" are helpful in this context (below). It seems that they
    > raise more questions than they answer.
    >

    Agreed.

    Hamid.

    ------_=_NextPart_001_01C551BA.571554DE-- From rtg-dir-bounces@ietf.org Thu May 5 18:36:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00487 for ; Thu, 5 May 2005 18:36:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTpBO-0005sV-Ra for rtg-dir-archive@ietf.org; Thu, 05 May 2005 18:51:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTouh-0003gQ-TV; Thu, 05 May 2005 18:33:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DToue-0003fn-Bd; Thu, 05 May 2005 18:33:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28722; Thu, 5 May 2005 18:33:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTp8y-0005Su-Rd; Thu, 05 May 2005 18:48:33 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTouZ-000Pj2-K4; Thu, 05 May 2005 22:33:39 +0000 Date: Thu, 5 May 2005 15:33:37 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1463303216.20050505153337@psg.com> To: "Adrian Farrel" In-Reply-To: <0b6201c551a7$38a4cd40$1c849ed9@Puppy> References: <1414061909.20050505100317@psg.com> <0b6201c551a7$38a4cd40$1c849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7bit Adrian, inline below, pls >> Technical Advisor(s): > I think a TA would be really sensible. The WG is going to be touching the > edges of a few signaling and routing protocols, as well as working with > transport concepts - quite a broad spectrum. Re routing, I hope the fact that the WG is positioned with RTG and that the responsible AD is from the same area, should help WG coordination. Which transport concepts did you have in mind that you though we should have a TA for? >> L1VPN Working Group's task is to specify mechanisms necessary for > s/L1VPN/The L1VPN/ ok >> providing a VPN service over a GMPLS transport network. > Question: Is the definition of such a service and the statement of the > requirements not part of the WG's task? > While we can absorb some of the requirements as expressed by the ITU and > also show them in the framework, some areas (like the enhanced mode > [sig+rtg]) may need a little more work to capture the requirements before > working on the specifications. If there's a clear understanding/consensus within the community on what needs to be done, writing a requirements document would only delay progress. If, however, there's a consensus here that the WG should do this before jumping on the enhanced mode spec, I would not object, as long as we keep it very laconic. >> The following two service models will be addressed: >> >> 1. Basic mode: the CE-PE interface's functional repertoire is limited > to >> path setup signalling only. The GMPLS network is not involved in >> distribution of user's routing information. >> >> 2. Enhanced mode: the CE-PE interface provides the signaling > capabilities >> as in the Basic mode, plus permits utilization of the provider's > control >> plane for distribution of some information from the user's control >> plane (e.g. network-layer reachability information as in the > MPLS/BGP model). > These statements are fine, but they do not cover two other functional > units. It may be that you intended to exclude these, but if so it would > help to be explicit. > a. Distribution of information about the provider's resources/topology > over the CE-PE interface. > b. Distribution of membership information from CE to PE (maybe you see > this as "some information from the user's control plane", in which case, > how about deleting the "(e.g. network-layer......)"?) Do we really have to spell out distribution of VPN membership info? Re point a above, how about this: 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits limited exchange of information between the control planes of the provider and the user to help such functions as discovery of reachability information in remote sites, or parameters of the part of the provider's network dedicated to the user. >> The WG will work on the following items: >> >> 1. Framework document defining the reference network model, L1VPN > service >> model, fundamental assumptions, and terminology. >> > I am not sure that the use of the established terms "UNI" and "NNI" are > helpful in this context (below). It seems that they raise more questions > than they answer. > But most importantly, I don't think we should use terms in the charter > without defining them in the charter. (This works well for basic and > extended mode, above). Please suggest changes. >> 2. Specification of the L1VPN user-to-network interface (UNI) basic > mode, >> including both CE and PE functionality. > "Specification" is too loose a term. Does this mean specification of the > architecture, function, requirements or protocol? One or more documents going to STD and used to described the above piece of functionality. >> 3. Specification of the L1VPN node-to-node interface (NNI) basic mode. > Do you mean "node-to-node" or "network-to-network"? I didn't like network-to-network, because supposedly this may well be nodes within a single network. Open for suggestions. >> 4. MIB modules and/or extensions required for UNI and NNI basic mode. >> >> 5. Specification of L1VPN UNI enhanced mode. >> >> 6. Specification of L1VPN NNI enhanced mode. >> >> 7. MIB modules and/or extensions required for UNI and NNI enhanced > mode. > What about other OAM concerns? Please suggest changes > What about applicability guidance for choice between the four modes? ditto > Also, what about the existing "applicability" draft that discusses the > applicability of various existing protocol models to satisfying the > different L1VPN modes? Do you imagine this being broken up into the > "specifications" above, or does it have value as an independent I-D? I think it will depend on how the specs end up being written, and whether we'll need separate applicability statements for them. I don't want to overload the charter. >> Protocol extensions required for L1VPN will be done in cooperation with >> CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. Where > necessary, >> the WG will also cooperate with ITU-T. > I think "where necessary" is too unspecific (and, BTW, sounds hugely > derogatory - which I am sure is not what you meant!). I suggest replacing > with... > The WG will also cooperate with the ITU-T in the development of L1VPN > requirements and the statement of operational models. I don't think "where necessary" is more derogatory when applied to ITU than when applied to other IETF WGs, I don't see a problem there. Reading your suggested wording: - how much work on requirements do you believe is required ? - what do you mean by operational models? >> >> Dec 06 Submit L1VPN framework to IESG for publication as Informational > RFC > Why is this so late in the list? If you were talking about an > architecture, I would understand why it is pretty much the final > milestone, but I thought a framework should lead. That is, we shouldn't > even start on the specifications until the framework is 90%+ cooked. That depends on the perceived role of the fw document. If it has the role of the initial architecture, then you are probably right. If its role is an informational document pulling pieces together (which is how I look at it), then I would be against making it a prerequisite for further work. -- Alex >> Aug 07 Submit MIB modules for UNI and NNI enhanced mode to IESG for > publication as Proposed Standard > Initial dates seem quite realistic. Later dates are, perhaps, a long way > ahead. From rtg-dir-bounces@ietf.org Thu May 5 19:02:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04750 for ; Thu, 5 May 2005 19:02:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTpal-00089S-73 for rtg-dir-archive@ietf.org; Thu, 05 May 2005 19:17:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpFW-00089l-1e; Thu, 05 May 2005 18:55:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpFU-00088V-J8; Thu, 05 May 2005 18:55:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03528; Thu, 5 May 2005 18:55:11 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTpEw-0006NO-Hj; Thu, 05 May 2005 18:54:43 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTp0U-00008J-03; Thu, 05 May 2005 22:39:46 +0000 Date: Thu, 5 May 2005 15:39:44 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <249605074.20050505153944@psg.com> To: "Hamid Ould-Brahim" In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D046228E9@zcarhxm0.corp.nortel.com> References: <085091CB2CA14E4B8B163FFC37C84E9D046228E9@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Hamid, > Just out of curiosity shouldn't this WG be as well within > the internet area like l2 and l3vpns? Some functions > are really similar to the ones developed in l2 and l3 vpns. > Routing area is still fine (since ccamp is within this area anyway). In retrospect, my personal opinion is that putting L2VPN and L3VPN in INT was a mistake. Most of the complexity in the work they are doing is RTG-related, and most of the people who go there are also RTG-involved. I've learned it the hard way... L1VPN builds on CCAMP work, so it makes sense to put it in RTG. >> Description of Working Group: >> >> L1VPN Working Group's task is to specify mechanisms >> necessary for providing a VPN service over a GMPLS transport network. > The above should be more specific that is about L1VPN using GMPLS > and across a GMPLS enabled network. A "VPN service over GMPLS" includes > all VPN cases that GMPLS interfaces support while here > we are looking specifically at l1vpn using gmpls. > I believe that if we solve the GMPLS VPN for L1VPN > then in fact we are actually solving a much bigger VPN > problem set (the set of interfaces where GMPLS applies). > And maybe it's much better to solve the GMPLS VPNs That > include GMPLS L1 based interfaces then starting with > L1VPN as a service since most of the mechanisms are not > necessarily L1-based. Something along the line of > Generalized VPNs. How do you think the text should be changed? >> The following two service models will be addressed: >> >> 1. Basic mode: the CE-PE interface's functional repertoire >> is limited to >> path setup signalling only. The GMPLS network is not involved in >> distribution of user's routing information. >> >> 2. Enhanced mode: the CE-PE interface provides the >> signaling capabilities >> as in the Basic mode, plus permits utilization of the >> provider's control >> plane for distribution of some information from the >> user's control >> plane (e.g. network-layer reachability information as in >> the MPLS/BGP model). >> > Is this referring to auto-discovery of L1VPN endpoints/nodes > or to routing peering between CE and PE and have PE distribute > CE relate routing? It looks like the text is about the latter > not the former. More the latter. I didn't think we should spell the former out. >> The WG will work on the following items: >> >> 1. Framework document defining the reference network model, >> L1VPN service >> model, fundamental assumptions, and terminology. >> > Should we as well add requirement document? I think we should > (since this is a service after all). Is there a disagreement in the community on what L1VPNs should do? If so, can it be resolved on the mailing list? In other words, do we really need a requirements document? (see my reply to Adrian for more on this.) >> 2. Specification of the L1VPN user-to-network interface >> (UNI) basic mode, >> including both CE and PE functionality. >> >> 3. Specification of the L1VPN node-to-node interface (NNI) >> basic mode. >> > Not sure what we mean here by L1VPN node-to-node interface. see my reply to Adrian. thanks. Alex From rtg-dir-bounces@ietf.org Thu May 5 19:02:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04864 for ; Thu, 5 May 2005 19:02:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTpbN-0008AY-5G for rtg-dir-archive@ietf.org; Thu, 05 May 2005 19:17:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpFR-00087Y-Oh; Thu, 05 May 2005 18:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTpFQ-00086i-2L; Thu, 05 May 2005 18:55:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03473; Thu, 5 May 2005 18:55:07 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTpGE-0006XL-Fc; Thu, 05 May 2005 18:56:03 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTp1p-0000FH-5E; Thu, 05 May 2005 22:41:09 +0000 Date: Thu, 5 May 2005 15:41:07 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <796504184.20050505154107@psg.com> To: "Hamid Ould-Brahim" In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D04622905@zcarhxm0.corp.nortel.com> References: <085091CB2CA14E4B8B163FFC37C84E9D04622905@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Adrian Farrel , l1vpn@ietf.org, rtg-dir@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hamid, >> b. Distribution >> of membership information from CE to PE (maybe you see this >> as "some information from the user's control plane", in which >> case, how about deleting the "(e.g. network-layer......)"?) >> > Yes. This can include as well provider network helping the CEs to > discover each other. I suggest instead of specifying just > membership b could be: > "b. Distribution of CE to PE related information (such as L1VPN membership, > site address information, CE routing information, etc." We don't have to do the design in the charter. >> I am not sure that the use of the established terms "UNI" and >> "NNI" are helpful in this context (below). It seems that they >> raise more questions than they answer. >> > Agreed. Suggestions, please, Thanks. Alex From rtg-dir-bounces@ietf.org Thu May 5 20:11:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10080 for ; Thu, 5 May 2005 20:11:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTqfM-0003qR-Pc for rtg-dir-archive@ietf.org; Thu, 05 May 2005 20:26:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTqNV-0005Rv-NY; Thu, 05 May 2005 20:07:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTqNT-0005QU-Ux; Thu, 05 May 2005 20:07:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09827; Thu, 5 May 2005 20:07:32 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTqbp-0003Yw-J1; Thu, 05 May 2005 20:22:26 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j4607IG10174; Thu, 5 May 2005 20:07:18 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 May 2005 20:07:18 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D04622980@zcarhxm0.corp.nortel.com> From: "Hamid Ould-Brahim" To: Alex Zinin Date: Thu, 5 May 2005 20:07:06 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: RE: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Alex, > > > Just out of curiosity shouldn't this WG be as well within > > the internet area like l2 and l3vpns? Some functions > > are really similar to the ones developed in l2 and l3 vpns. > > > Routing area is still fine (since ccamp is within this area anyway). > > In retrospect, my personal opinion is that putting L2VPN and > L3VPN in INT was a mistake. Most of the complexity in the > work they are doing is RTG-related, and most of the people > who go there are also RTG-involved. I've learned it the hard way... > It's not too late to bring them back to RTG (better late than never) ;-). > L1VPN builds on CCAMP work, so it makes sense to put it in RTG. > > >> Description of Working Group: > >> > >> L1VPN Working Group's task is to specify mechanisms > necessary for > >> providing a VPN service over a GMPLS transport network. > > > The above should be more specific that is about L1VPN using > GMPLS and > > across a GMPLS enabled network. A "VPN service over GMPLS" includes > > all VPN cases that GMPLS interfaces support while here we > are looking > > specifically at l1vpn using gmpls. > > > I believe that if we solve the GMPLS VPN for L1VPN > > then in fact we are actually solving a much bigger VPN problem set > > (the set of interfaces where GMPLS applies). And maybe it's much > > better to solve the GMPLS VPNs That include GMPLS L1 based > interfaces > > then starting with L1VPN as a service since most of the > mechanisms are > > not necessarily L1-based. Something along the line of > > Generalized VPNs. > > How do you think the text should be changed? > How about we say: "L1VPN Working Group's task is to specify mechanisms necessary (and combination thereof) for implementing provider-based L1VPN services using GMPLS protocols as defined in IETF". I think there are in fact multiple L1VPN service models, each L1VPN service model will need to be implemented through a consistent vertical solution, and one or more L1VPN mechanisms can be defined and combined to implement one or more vertical solutions. Note I removed the GMPLS transport network (I found a bit specific...). > >> The following two service models will be addressed: > >> > >> 1. Basic mode: the CE-PE interface's functional repertoire > >> is limited to > >> path setup signalling only. The GMPLS network is not > involved in > >> distribution of user's routing information. > >> I suggest we replace the terms "GMPLS network" with "provider GMPLS enabled network...". In the basic mode since the path signaling is done for the purpose of L1VPN then I think it is important to indicate that signaling is accomplished within a given CE-CE connectivity topology. Here is my text suggestion for 1. "1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only between CEs members of the same L1VPN across the provider network. The provider GMPLS enabled network is not involved in distribution of user's routing information." > involved in > >> distribution of user's routing information. > >> 2. Enhanced mode: the CE-PE interface provides the > >> signaling capabilities > >> as in the Basic mode, plus permits utilization of the > >> provider's control > >> plane for distribution of some information from the > >> user's control > >> plane (e.g. network-layer reachability information as in > >> the MPLS/BGP model). > >> > > > Is this referring to auto-discovery of L1VPN endpoints/nodes > > or to routing peering between CE and PE and have PE distribute > > CE relate routing? It looks like the text is about the latter > > not the former. > > More the latter. I didn't think we should spell the former out. > I prefer we spell discovery out clearly to avoid some confusion later on. Using your proposal in your reply to Adrian below: " 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits limited exchange of information between the control planes of the provider and the user to help such functions as discovery of reachability information in remote sites, or parameters of the part of the provider's network dedicated to the user." I think the routing is a bit tricky here. The enhanced mode (which in fact can map to one or two L1VPN service models") may imply only that the exchange of routing is done only between the user control plane and "a control plane" running on the PE. That control plane running on the PE may have no relation to the provider actual control plane. How about rewriting the above paragraph to be: " 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits exchange of L1VPN user routing information between the CE control plane and a control plane(s) running on provider edge nodes. In this context functions such as discovery of reachability information in remote sites, or parameters of the part of the provider's network dedicated to the user need to be specified." > >> The WG will work on the following items: > >> > >> 1. Framework document defining the reference network model, > >> L1VPN service > >> model, fundamental assumptions, and terminology. > >> > > > Should we as well add requirement document? I think we should > > (since this is a service after all). > > Is there a disagreement in the community on what L1VPNs should do? > If so, can it be resolved on the mailing list? > I think service requirements can guide the work to identify items such as which parameters to consider in signaling, etc, but you maybe right. I am interested to hear providers opinion on that. My suggestion would be to reuse what has been already done in ITU (just we need to make it visible to ietf folks...). Another item that needs to be added is "security" (after all this is a VPN problem), and particularly that we allow some critical information exchange between CE and PE. My experience working on this topic is provider will want maximum security between CE and PEs (and between providers) clarifying how security is provided between PE and CEs (and between provider border nodes) will help what appropriate mechanisms to use for address separation, authentication, etc. Hamid. From rtg-dir-bounces@ietf.org Thu May 5 21:13:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14978 for ; Thu, 5 May 2005 21:13:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTrdL-0007ml-R8 for rtg-dir-archive@ietf.org; Thu, 05 May 2005 21:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTrNJ-0000hX-8e; Thu, 05 May 2005 21:11:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTrNI-0000fz-2N; Thu, 05 May 2005 21:11:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14785; Thu, 5 May 2005 21:11:25 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTrbg-0007jx-Md; Thu, 05 May 2005 21:26:21 -0400 Received: from du-069-0149.access.clara.net ([217.158.132.149] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DTrN9-0004sZ-8V; Fri, 06 May 2005 02:11:21 +0100 Message-ID: <0bc801c551d8$cc841080$1c849ed9@Puppy> From: "Adrian Farrel" To: "Alex Zinin" References: <1414061909.20050505100317@psg.com> <0b6201c551a7$38a4cd40$1c849ed9@Puppy> <1463303216.20050505153337@psg.com> Date: Fri, 6 May 2005 02:10:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 2.9 (++) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Hi, > > I think a TA would be really sensible. The WG is going to be touching the > > edges of a few signaling and routing protocols, as well as working with > > transport concepts - quite a broad spectrum. > > Re routing, I hope the fact that the WG is positioned with RTG and that the > responsible AD is from the same area, should help WG coordination. > Which transport concepts did you have in mind that you though we should > have a TA for? Data plane transport concepts, not X.200 transport layer protocols. > >> 1. Basic mode: the CE-PE interface's functional repertoire is limited > >> to path setup signalling only. The GMPLS network is not > >> involved in distribution of user's routing information. > >> > >> 2. Enhanced mode: the CE-PE interface provides the signaling > >> capabilities as in the Basic mode, plus permits utilization of > >> the provider's control plane for distribution of some information > >> from the user's control plane (e.g. network-layer reachability > >> information as in the MPLS/BGP model). > > > These statements are fine, but they do not cover two other functional > > units. It may be that you intended to exclude these, but if so it would > > help to be explicit. > > a. Distribution of information about the provider's resources/topology > > over the CE-PE interface. > > b. Distribution of membership information from CE to PE (maybe you see > > this as "some information from the user's control plane", in which case, > > how about deleting the "(e.g. network-layer......)"?) > > Do we really have to spell out distribution of VPN membership info? No, but then I would not put in the example you cited either. > Re point a above, how about this: > > 2. Enhanced mode: the CE-PE interface provides the signaling capabilities > as in the Basic mode, plus permits limited exchange of information > between the control planes of the provider and the user to help such > functions as discovery of reachability information in remote sites, > or parameters of the part of the provider's network dedicated to > the user. Yeah. > >> The WG will work on the following items: > > > I am not sure that the use of the established terms "UNI" and "NNI" are > > helpful in this context (below). It seems that they raise more questions > > than they answer. > > > But most importantly, I don't think we should use terms in the charter > > without defining them in the charter. (This works well for basic and > > extended mode, above). > > Please suggest changes. Certainly. You'll notice that I have rolled all of your "please suggest changes" into this list. Also added point 9 while I was thinking of it, but I would understand if you wanted to punt this to a re-charter. 1. Framework document defining the reference network model, L1VPN service model, fundamental assumptions, and terminology. 2. Specification of the L1VPN signaling functionality between the user network and the provider network to support the basic mode. 3. Specification of the L1VPN signaling and routing functionality within the provider network to support the basic mode. 4. OAM features and MIB modules and/or extensions required for the basic mode. 5. Specification of the L1VPN signaling and routing functionality between the user network and the provider network to support the extended mode. 6. Specification of the L1VPN signaling and routing functionality within the provider network to support the extended mode. 7. OAM features and MIB modules and/or extensions required for the extended mode. 8. Applicability guidelines to compare the basic and extended modes. 9. Specification of the L1VPN extensions for applying the basic and extended modes to multi-provider L1VPNs. > >> Protocol extensions required for L1VPN will be done in cooperation with > >> CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. Where > >> necessary, the WG will also cooperate with ITU-T. > > > I think "where necessary" is too unspecific (and, BTW, sounds hugely > > derogatory - which I am sure is not what you meant!). I suggest replacing > > with... > > The WG will also cooperate with the ITU-T in the development of L1VPN > > requirements and the statement of operational models. > > I don't think "where necessary" is more derogatory when applied to ITU than > when applied to other IETF WGs, I don't see a problem there. I said you dodn't mean it to sound the way it sounds. I can only report how it sounds. > Reading your suggested wording: > > - how much work on requirements do you believe is required ? Minimal. Just a cross-check. > - what do you mean by operational models? I mean "Service Models" as in section 7 of draft-takeda-l1vpn-framework-03.txt. Again, mainly cross-check work. What I am trying to do is point up the areas where we can take sensible input from the ITU-T. These are the areas where they have done most work and where their SP-oriented make-up can help us most. > >> Dec 06 Submit L1VPN framework to IESG for publication as Informational > >> RFC > > > Why is this so late in the list? If you were talking about an > > architecture, I would understand why it is pretty much the final > > milestone, but I thought a framework should lead. That is, we shouldn't > > even start on the specifications until the framework is 90%+ cooked. > > That depends on the perceived role of the fw document. If it has the role > of the initial architecture, then you are probably right. If its role is an > informational document pulling pieces together (which is how I look at it), > then I would be against making it a prerequisite for further work. Ah well, whatever. The document is already cooked and ready for publication as an RFC, so it doesn't make too much difference. Adrian From rtg-dir-bounces@ietf.org Fri May 6 01:15:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07905 for ; Fri, 6 May 2005 01:15:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTvPe-0006da-U6 for rtg-dir-archive@ietf.org; Fri, 06 May 2005 01:30:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTvAV-0002cE-7P; Fri, 06 May 2005 01:14:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTvAS-0002ab-Vc; Fri, 06 May 2005 01:14:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07783; Fri, 6 May 2005 01:14:27 -0400 (EDT) Received: from 82-47-218-122.cable.ubr01.shef.blueyonder.co.uk ([82.47.218.122]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTvOq-0006bZ-82; Fri, 06 May 2005 01:29:23 -0400 Received: from ny-tupperlake5b-608.albyny.adelphia.net (pD861D2D1.dip.t-dialin.net [195.212.194.144]) by ca.beonex.com with ESMTP id 288B9C0508B for ; Fri, 06 May 2005 07:08:02 +0100 Message-Id: <7754291120.8379035@bcc6.kofak.com> Date: Fri, 06 May 2005 12:12:02 +0600 From: "infections" To: rtg-dir@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: fight off virus and bacteria -m 5 g X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 The Ancient Secret of LIFE All INFECTIONS VIRUS and BACTRIA ARE BLOWN AWAY.. http://sfdgsr3e.info/hp The common cold is a thing of the past, even serious infectious diseases such as Cancer, HIV/AIDS, SARS and many other life threatening diseases can be helped by the miracle healing powers of the Antidote. Nearly all malignant diseases are kept active by viruses and bacteria, the main cause of infections. A disease must be made dormant to stop further infection. It is essential to kill the viruses & bacteria first, to enable the body to recover. The Antidote is the first step towards a healthy life. This isn’t just for the consumer who’s getting over the daily cold or flu, even if you’re not ill, the Antidote can be used as an additive to the body’s immune system, fortifying it from attacks. This is the perfect way to fight illness before it even has a chance. You’ll find yourself feeling stronger and healthier within 48 hours of taking the Antidote. It really is the all inclusive miracle that will kill all viruses and bacteria your body can throw at it. Here's all the details: http://sfdgsr3e.info/hp Millions of dollars have gone into the research and development in this field, and you the consumer are ultimately benefiting from this scientific advancement. Whether you have the common cold, a terminal illness, or if you just to want to protect your body from viruses and bacteria in the future, this is the only product you should be purchasing. The Antidote is only available from our Internet website. No major drug company wants you to get your hands on it. Drug companies would be losing billions every day if this product was on the shelf next to their major brands. This is exactly the type of product major corporations want to usher aside as just another “passing fad”, but don’t let them fool you. This is 100% real and has the power to change how human beings perceive an alternative to drugs forever. The Antidote is a limited product due to fast growing interest globally, hurry up and order while it is still available. Order the Antidote right now, and tomorrow, you won’t only feel like a different person, but you’ll be a different person. Our immune systems are the only weapon human beings have to fight off virus and bacteria infections, and the Antidote gives your body the boost it needs to live a happy, healthy life. Don’t let the common cold, flu, or something more serious take control of you. There’s something you can do to help yourself; make the Antidote the reason you can get up in the morning and enjoy life to its full capacity. The Antidote will change your life forever. Do not let it pass you by. Take a look for yourself. http://sfdgsr3e.info/hp No MORE http://www.h0us3.com/gone.asp ----------- toxin dnieper visigoth hobbes drury. reveal cochineal injunct paranormal contradistinguish. empress champagne unite demure adagio. doesn't copybook vernon cloddish chinatown. knock choreography chronology glaucoma pelt. bonnie cringe baffle nonchalant anticipate. bandit bursitis discriminant campsite avid. rupture celestial estes immersion militate. kind levitate dicta calendrical stationarity. adrienne molehill insurrection flagellate callisto. incapable pie predominate mimeograph vagrant. afterlife gallagher provocation antipode corpsman. cutlet raven image islamabad polysaccharide. eutectic lobster frambesia argentina deplete. albania ajax caucasus polariton osmosis. cooky noodle circle astigmat dream. -- infections xirncc@lycos.com From rtg-dir-bounces@ietf.org Fri May 6 04:31:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14766 for ; Fri, 6 May 2005 04:31:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTyTp-00020m-Et for rtg-dir-archive@ietf.org; Fri, 06 May 2005 04:46:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTyD3-0002ji-W5; Fri, 06 May 2005 04:29:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTyD2-0002jc-RA for rtg-dir@megatron.ietf.org; Fri, 06 May 2005 04:29:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14599 for ; Fri, 6 May 2005 04:29:18 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTyRV-0001pl-3A for rtg-dir@ietf.org; Fri, 06 May 2005 04:44:17 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=[127.0.0.1]) by fw.testbed.se with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DTyCc-00041A-Fj; Fri, 06 May 2005 10:28:57 +0200 Message-ID: <427B2A38.7090300@pi.se> Date: Fri, 06 May 2005 10:26:32 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hamid Ould-Brahim References: <085091CB2CA14E4B8B163FFC37C84E9D0462282F@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D0462282F@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit Comments in line. /Loa Hamid Ould-Brahim wrote: > Alex, > < snip > > > Just out of curiosity shouldn't this WG be as well within > the internet area like l2 and l3vpns? Some functions > are really similar to the ones developed in l2 and l3 vpns. > > Routing area is still fine (since ccamp is within this area anyway). hmmm, maybe we should discuss which wg are in thge wrong area :) < snip> >>Description of Working Group: >> >> L1VPN Working Group's task is to specify mechanisms >>necessary for providing a VPN service over a GMPLS transport network. >> > > > The above should be more specific that is about L1VPN using GMPLS > and across a GMPLS enabled network. A "VPN service over GMPLS" includes > all VPN cases that GMPLS interfaces support while here > we are looking specifically at l1vpn using gmpls. > > I believe that if we solve the GMPLS VPN for L1VPN > then in fact we are actually solving a much bigger VPN > problem set (the set of interfaces where GMPLS applies). Guess that Hamids comment boils down to that GMPLS can do more than L1. Strictly speaking ASON (which really is a degenrate version of GMPLS) could also (in some restricted way) be used for L1VPNs. > And maybe it's much better to solve the GMPLS VPNs That > include GMPLS L1 based interfaces then starting with > L1VPN as a service since most of the mechanisms are not > necessarily L1-based. Something along the line of > Generalized VPNs. I don't think that this wg is the place to solve all genral VPN problems, would rather urge to focus this really narrow e.g. the two service models below > > >> The following two service models will be addressed: >> >> 1. Basic mode: the CE-PE interface's functional repertoire >>is limited to >> path setup signalling only. The GMPLS network is not involved in >> distribution of user's routing information. >> >> 2. Enhanced mode: the CE-PE interface provides the >>signaling capabilities >> as in the Basic mode, plus permits utilization of the >>provider's control >> plane for distribution of some information from the >>user's control >> plane (e.g. network-layer reachability information as in >>the MPLS/BGP model). Question: would be correct to say that the intention is to describe an "overlay model" in the in the basic mode and an "peer model" in the enhanced. If so it should be made clear that when we talk about "user's routing information" it is the routing information for the "layer" native to the GMPLS VPN. >> > given that description it is probably time to ask if this a Layer 1 VPN working group or an GMPLS VPN working group. The P for Private in VPN is a bit dubious at least in the early uses of this technology, might be better to name it GMPLS VPN wg. > < snip > > >> The WG will work on the following items: >> >> 1. Framework document defining the reference network model, >>L1VPN service >> model, fundamental assumptions, and terminology. >> < snip> > >> 2. Specification of the L1VPN user-to-network interface >>(UNI) basic mode, >> including both CE and PE functionality. >> >> 3. Specification of the L1VPN node-to-node interface (NNI) >>basic mode. don't understand this node-to-node, the user inerface seems enough or do we intend to do interdomain hops on L1? >> >> 4. MIB modules and/or extensions required for UNI and NNI >>basic mode. >> >> 5. Specification of L1VPN UNI enhanced mode. >> >> 6. Specification of L1VPN NNI enhanced mode. >> >> 7. MIB modules and/or extensions required for UNI and NNI >>enhanced mode. I would like to see the security issue mentioned explicitly. >> >> Protocol extensions required for L1VPN will be done in >>cooperation with CCAMP, OSPF, IS-IS, IDR, and other WGs >>where necessary. Where necessary, the WG will also cooperate >>with ITU-T. I guess that the thought here is that ccamp acts on behalf of the mpls wg, but would be happier if the mpls wg were mentioned ecxplicitly, also since we mention the BGP/MPLS VPNs some coordintion with L3VPN might turn out necessary. I also think that the paragraph is to weak, it should say. "Protocol extensions required for L1VPN need to be done with by the working roup that owns the base protocol, e.g. CCAMP, MPLS, OSPF, IS-IS, IDR, and other WGs where necessary. Where necessary, the WG will also cooperate with ITU-T." >> >>Milestones: >> >> Sep 05 Submit first Internet Draft of L1VPN framework >> >> Sep 05 Submit first Internet Drafts of UNI and NNI basic >>mode specifications >> >> Dec 05 Submit first Internet Drafts of MIB modules for UNI >>and NNI basic mode >> >> Apr 06 Submit UNI and NNI basic mode specifications to IESG >>for publication as Proposed Standard >> >> Jun 06 Submit first Internet Drafts of UNI and NNI enhanced >>mode specifications >> >> Aug 06 Submit MIB modules for UNI and NNI basic mode to >>IESG for publication as Proposed Standard >> >> Dec 06 Submit UNI and NNI enhanced mode specifications to >>IESG for publication as Proposed Standard >> >> Dec 06 Submit L1VPN framework to IESG for publication as >>Informational RFC >> >> Aug 07 Submit MIB modules for UNI and NNI enhanced mode to >>IESG for publication as Proposed Standard >> There are some comments, e.g. on the NNI that could affect the milestones once they are resoloved. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From rtg-dir-bounces@ietf.org Fri May 6 05:04:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17461 for ; Fri, 6 May 2005 05:04:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTyzs-00043h-2k for rtg-dir-archive@ietf.org; Fri, 06 May 2005 05:19:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTykl-0000Uw-7b; Fri, 06 May 2005 05:04:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTyki-0000Ur-VJ for rtg-dir@megatron.ietf.org; Fri, 06 May 2005 05:04:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17404 for ; Fri, 6 May 2005 05:04:06 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTyzA-0003uP-Oi for rtg-dir@ietf.org; Fri, 06 May 2005 05:19:06 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=[127.0.0.1]) by fw.testbed.se with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DTykQ-00046o-DR; Fri, 06 May 2005 11:03:53 +0200 Message-ID: <427B3268.1030908@pi.se> Date: Fri, 06 May 2005 11:01:28 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Bryskin References: <20050504172332.26986.qmail@web30802.mail.mud.yahoo.com> In-Reply-To: <20050504172332.26986.qmail@web30802.mail.mud.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: 7bit Cc: Alex Zinin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Content-Transfer-Encoding: 7bit Igor and Dimitri, I'm not that happy about this - did see it go into the version that was sent to l1vpn-list, and think it should not be there. At least not until we have a clear understanding of what the scope of this working groups coordination with ITY-T needs to be. The issues we see to today is that we have several contacts points with ITU-T and the messages we send over these contact points are sometimes conflicting and they are using it to say that we don't have control of what we are doing. I think that with regards to the ITU-T relationship it would be much better to appoint one person (a liaison) or a working group or a set of working groups responsible for coordinating the (g)mpls part of the ITU-T relationship from the IETF. And then write something like: "Use the established IETF channels to coordinate with ITU-T as necessary." Actually this could go into the charter of all working groups that needs to part of this coordination. /Loa Igor Bryskin wrote: > Good idea. > Igor > > */Dimitri.Papadimitriou@alcatel.be/* wrote: > > igor, all - now that i am thinking of it there is probably a need to > add a sentence like "The WG will also liaise with related ITU-T SGs" > after "... and other WGs where necessary." > > *Igor Bryskin * > Sent by: rtg-dir-bounces@ietf.org > 05/04/2005 07:18 MST > > To: Alex Zinin , Adrian Farrel , > Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, rtg-dir@ietf.org, Kireeti > Kompella , takeda.tomonori@lab.ntt.co.jp > cc: > bcc: > Subject: Re: Draft L1VPN Charter > > > Alex, All > > > > 2. Enhanced mode: the CE-PE interface provides the signaling > capabilities > as in the Basic mode, plus permits utilization of the provider's control > plane for distribution of user's routing information (e.g. similar > to the > MPLS/BGP model). > > I'd like to replace this with: > > > > 2. Enhanced mode: the CE-PE interface provides the signaling > capabilities > as in the Basic mode, plus permits utilization of the provider's control > plane for distribution of user's arbitrary control plane information > between the VPN sites including but not limited to routing information. > > > > Provider network IHMO should make no assumptions on what protocols > are running within VPNs. Generally speaking, a L1VPN user is not > necessarily GMPLS controlled network. Furthermore, even in case it > does use GMPLS it needs L1VPN CE-CE connections to provide (TE) > links within VPNs. Specifically, the User should be capable to run > LMP for such links, it also should be possible to establish > signaling (RSVP) adjacencies between their ends, etc. The bottom > line is that distribution of routing information between CEs IHMO is > not sufficient. I believe this is consistent with the requirements > stated in ITU-T SG13 L1VPN documents > > > > Igor > > > > > > */Alex Zinin /* wrote: > > Folks- > > Before we bring it to the l1vpn mailing list, I'd like to run this draft > by you guys for comments. > > -- > Alex > > > Layer 1 Virtual Private Networks (l1vpn) > > Last Modified: 2005-01-25 > Chair(s): > TBD > TBD > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Technical Advisor(s): > > Mailing Lists: > General Discussion: l1vpn@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn > Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html > > Description of Working Group: > > L1VPN Working Group's task is to specify mechanisms necessary for > providing a VPN service over a GMPLS transport network. > > The following two service models will be addressed: > > 1. Basic mode: the CE-PE interface's functional repertoire is limited to > path setup signalling only. The GMPLS network is not involved in > distribution of user's routing information. > > 2. Enhanced mode: the CE-PE interface provides the signaling > capabilities > as in the Basic mode, plus permits utilization of the provider's control > plane for distribution of user's routing information (e.g. similar > to the > MPLS/BGP model). > > The WG will work on the following items: > > 1. Specification of the L1VPN user-to-network interface (UNI) basic > mode, > including both CE and PE functionality. > > 2. Specification of the L1VPN node-to-node interface (NNI) basic mode. > ! > 3. MIB modules and/or extensions required for UNI and NNI basic mode. > > 4. Specification of L1VPN UNI enhanced mode. > > 5. Specification of L1VPN NNI enhanced mode. > > 6. MIB modules and/or extensions required for UNI and NNI enhanced mode. > > Protocol extensions required for L1VPN will be done in cooperation with > CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. > > Milestones: > > Sep 05 Submit first Internet Drafts of UNI and NNI basic mode > specifications > Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic > mode > Jun 06 Submit UNI and NNI basic mode specifications to IESG for > publication as Proposed Standard > Jun 06 Submit first Internet Draf! ts of UNI and NNI enhanced mode > specifications > Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for > publication as Proposed Standard > Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for > publication as Proposed Standard > Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for > publication as Proposed Standard > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > ------------------------------------------------------------------------ > Discover Yahoo! > Find restaurants, movies, travel & more fun for the weekend. Check it > out! > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From rtg-dir-bounces@ietf.org Fri May 6 05:15:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18283 for ; Fri, 6 May 2005 05:15:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTzAL-0004dx-CU for rtg-dir-archive@ietf.org; Fri, 06 May 2005 05:30:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTyvn-0002ZQ-OQ; Fri, 06 May 2005 05:15:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTyvn-0002YM-79 for rtg-dir@megatron.ietf.org; Fri, 06 May 2005 05:15:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18254 for ; Fri, 6 May 2005 05:15:32 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTzAF-0004dS-3r for rtg-dir@ietf.org; Fri, 06 May 2005 05:30:32 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j469FSLD012674; Fri, 6 May 2005 11:15:28 +0200 To: Loa Andersson MIME-Version: 1.0 Date: Fri, 6 May 2005 11:15:26 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/06/2005 11:15:28 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: Alex Zinin , Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Igor Bryskin , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Loa, good to see there is a clear intention to structure our relationship and message towards ITU-T wrt to our GMPLS work and views if i correctly interpreet you statement "Use the established IETF channels to coordinate with ITU-T as necessary." it means there will be a single channel (contrary to the multiple per WG channel that exists today) and you suggest making use of it to communicate with ITU-T SG13 on L1VPN as long as this allows interacting with them where necessary i do not think this would problematic - do you know when such person is going to be appointed ? thanks, - dimitri. --- Igor and Dimitri, I'm not that happy about this - did see it go into the version that was sent to l1vpn-list, and think it should not be there. At least not until we have a clear understanding of what the scope of this working groups coordination with ITY-T needs to be. The issues we see to today is that we have several contacts points with ITU-T and the messages we send over these contact points are sometimes conflicting and they are using it to say that we don't have control of what we are doing. I think that with regards to the ITU-T relationship it would be much better to appoint one person (a liaison) or a working group or a set of working groups responsible for coordinating the (g)mpls part of the ITU-T relationship from the IETF. And then write something like: "Use the established IETF channels to coordinate with ITU-T as necessary." Actually this could go into the charter of all working groups that needs to part of this coordination. /Loa Igor Bryskin wrote: > Good idea. > Igor > > */Dimitri.Papadimitriou@alcatel.be/* wrote: > > igor, all - now that i am thinking of it there is probably a need to > add a sentence like "The WG will also liaise with related ITU-T SGs" > after "... and other WGs where necessary." > > *Igor Bryskin * > Sent by: rtg-dir-bounces@ietf.org > 05/04/2005 07:18 MST > > To: Alex Zinin , Adrian Farrel , > Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, rtg-dir@ietf.org, Kireeti > Kompella , takeda.tomonori@lab.ntt.co.jp > cc: > bcc: > Subject: Re: Draft L1VPN Charter > > > Alex, All > > > > 2. Enhanced mode: the CE-PE interface provides the signaling > capabilities > as in the Basic mode, plus permits utilization of the provider's control > plane for distribution of user's routing information (e.g. similar > to the > MPLS/BGP model). > > I'd like to replace this with: > > > > 2. Enhanced mode: the CE-PE interface provides the signaling > capabilities > as in the Basic mode, plus permits utilization of the provider's control > plane for distribution of user's arbitrary control plane information > between the VPN sites including but not limited to routing information. > > > > Provider network IHMO should make no assumptions on what protocols > are running within VPNs. Generally speaking, a L1VPN user is not > necessarily GMPLS controlled network. Furthermore, even in case it > does use GMPLS it needs L1VPN CE-CE connections to provide (TE) > links within VPNs. Specifically, the User should be capable to run > LMP for such links, it also should be possible to establish > signaling (RSVP) adjacencies between their ends, etc. The bottom > line is that distribution of routing information between CEs IHMO is > not sufficient. I believe this is consistent with the requirements > stated in ITU-T SG13 L1VPN documents > > > > Igor > > > > > > */Alex Zinin /* wrote: > > Folks- > > Before we bring it to the l1vpn mailing list, I'd like to run this draft > by you guys for comments. > > -- > Alex > > > Layer 1 Virtual Private Networks (l1vpn) > > Last Modified: 2005-01-25 > Chair(s): > TBD > TBD > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Technical Advisor(s): > > Mailing Lists: > General Discussion: l1vpn@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn > Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html > > Description of Working Group: > > L1VPN Working Group's task is to specify mechanisms necessary for > providing a VPN service over a GMPLS transport network. > > The following two service models will be addressed: > > 1. Basic mode: the CE-PE interface's functional repertoire is limited to > path setup signalling only. The GMPLS network is not involved in > distribution of user's routing information. > > 2. Enhanced mode: the CE-PE interface provides the signaling > capabilities > as in the Basic mode, plus permits utilization of the provider's control > plane for distribution of user's routing information (e.g. similar > to the > MPLS/BGP model). > > The WG will work on the following items: > > 1. Specification of the L1VPN user-to-network interface (UNI) basic > mode, > including both CE and PE functionality. > > 2. Specification of the L1VPN node-to-node interface (NNI) basic mode. > ! > 3. MIB modules and/or extensions required for UNI and NNI basic mode. > > 4. Specification of L1VPN UNI enhanced mode. > > 5. Specification of L1VPN NNI enhanced mode. > > 6. MIB modules and/or extensions required for UNI and NNI enhanced mode. > > Protocol extensions required for L1VPN will be done in cooperation with > CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. > > Milestones: > > Sep 05 Submit first Internet Drafts of UNI and NNI basic mode > specifications > Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic > mode > Jun 06 Submit UNI and NNI basic mode specifications to IESG for > publication as Proposed Standard > Jun 06 Submit first Internet Draf! ts of UNI and NNI enhanced mode > specifications > Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for > publication as Proposed Standard > Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for > publication as Proposed Standard > Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for > publication as Proposed Standard > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > ------------------------------------------------------------------------ > Discover Yahoo! > Find restaurants, movies, travel & more fun for the weekend. Check it > out! > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From rtg-dir-bounces@ietf.org Fri May 6 05:47:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21380 for ; Fri, 6 May 2005 05:47:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTzf0-0006iR-Oe for rtg-dir-archive@ietf.org; Fri, 06 May 2005 06:02:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTzNE-0007CQ-DM; Fri, 06 May 2005 05:43:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTzNC-0007Bt-RX; Fri, 06 May 2005 05:43:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21143; Fri, 6 May 2005 05:43:51 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTzbe-0006We-VN; Fri, 06 May 2005 05:58:52 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j469hpLD016068; Fri, 6 May 2005 11:43:51 +0200 To: Adrian Farrel MIME-Version: 1.0 Date: Fri, 6 May 2005 11:43:49 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/06/2005 11:43:50 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Alex Zinin , rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 adrian you mention "7. OAM features and MIB modules and/or extensions required for the extended mode. 8. Applicability guidelines to compare the basic and extended modes. 9. Specification of the L1VPN extensions for applying the basic and extended modes to multi-provider L1VPNs." which OAM mechanisms are you referring to in the L1 context ? if you are referring to the control plane mechanisms they should be part of the corr. control document this said, why not combining item 8 and 9 in a single item and leave the multiple-provider case for the next step "8. Guidelines for applying the basic and extended modes for single-provider networks." note: you were also questioning about the reason of " Dec 06 Submit L1VPN framework to IESG for publication as Informational RFC" for a document defining the reference network model, L1VPN service model, fundamental assumptions, and terminology; indeed the framework leads as its first version is going to be submitted by Sep05 should lead and should be 90%+ cooked. but it also covers terminology and other certain aspects that can be retro-actively impacted by the protocol work - experience has shown that such document becomes fully stable when the protocol work is near completion From rtg-dir-bounces@ietf.org Fri May 6 06:03:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23132 for ; Fri, 6 May 2005 06:03:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTzui-0007lA-Mg for rtg-dir-archive@ietf.org; Fri, 06 May 2005 06:18:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTzfU-0001wd-CE; Fri, 06 May 2005 06:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTzfR-0001wY-KY for rtg-dir@megatron.ietf.org; Fri, 06 May 2005 06:02:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23089 for ; Fri, 6 May 2005 06:02:42 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTztu-0007k5-MS for rtg-dir@ietf.org; Fri, 06 May 2005 06:17:43 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=[127.0.0.1]) by fw.testbed.se with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DTzem-0004Gt-3K; Fri, 06 May 2005 12:02:31 +0200 Message-ID: <427B400D.8080705@pi.se> Date: Fri, 06 May 2005 11:59:41 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , Kireeti Kompella , rtg-dir@ietf.org, Igor Bryskin , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Re: Draft L1VPN Charter X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Content-Transfer-Encoding: 7bit Dimitri, I don't know exactly which hat I've on here. What I said is that I see some need to further coordinate the IETF relationship with ITU-T, and that it is not a good idea to establish yet another realtionship before doing so. I don't know what such a channel will look like - or even if it is "single" - but I claim that it is something we need to discuss. /Loa Dimitri.Papadimitriou@alcatel.be wrote: > Loa, > > good to see there is a clear intention to structure our relationship and > message towards ITU-T wrt to our GMPLS work and views > > if i correctly interpreet you statement "Use the established IETF channels > to coordinate with ITU-T as necessary." it means there will be a single > channel (contrary to the multiple per WG channel that exists today) and you > suggest making use of it to communicate with ITU-T SG13 on L1VPN > > as long as this allows interacting with them where necessary i do not think > this would problematic - do you know when such person is going to be > appointed ? > > thanks, > - dimitri. > > --- > > Igor and Dimitri, > > I'm not that happy about this - did see it go into the version > that was sent to l1vpn-list, and think it should not be there. > At least not until we have a clear understanding of what the > scope of this working groups coordination with ITY-T needs to > be. > > The issues we see to today is that we have several contacts points > with ITU-T and the messages we send over these contact points are > sometimes conflicting and they are using it to say that we don't > have control of what we are doing. > > I think that with regards to the ITU-T relationship it would be > much better to appoint one person (a liaison) or a working group > or a set of working groups responsible for coordinating the > (g)mpls part of the ITU-T relationship from the IETF. And then > write something like: > > "Use the established IETF channels to coordinate with ITU-T as > necessary." > > Actually this could go into the charter of all working groups that > needs to part of this coordination. > > /Loa > > Igor Bryskin wrote: > > >>Good idea. >>Igor >> >>*/Dimitri.Papadimitriou@alcatel.be/* wrote: >> >> igor, all - now that i am thinking of it there is probably a need to >> add a sentence like "The WG will also liaise with related ITU-T SGs" >> after "... and other WGs where necessary." >> >> *Igor Bryskin * >> Sent by: rtg-dir-bounces@ietf.org >> 05/04/2005 07:18 MST >> >> To: Alex Zinin , Adrian Farrel , >> Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, rtg-dir@ietf.org, Kireeti >> Kompella , takeda.tomonori@lab.ntt.co.jp >> cc: >> bcc: >> Subject: Re: Draft L1VPN Charter >> >> >> Alex, All >> >> >> >> 2. Enhanced mode: the CE-PE interface provides the signaling >> capabilities >> as in the Basic mode, plus permits utilization of the provider's > > control > >> plane for distribution of user's routing information (e.g. similar >> to the >> MPLS/BGP model). >> >> I'd like to replace this with: >> >> >> >> 2. Enhanced mode: the CE-PE interface provides the signaling >> capabilities >> as in the Basic mode, plus permits utilization of the provider's > > control > >> plane for distribution of user's arbitrary control plane information >> between the VPN sites including but not limited to routing > > information. > >> >> >> Provider network IHMO should make no assumptions on what protocols >> are running within VPNs. Generally speaking, a L1VPN user is not >> necessarily GMPLS controlled network. Furthermore, even in case it >> does use GMPLS it needs L1VPN CE-CE connections to provide (TE) >> links within VPNs. Specifically, the User should be capable to run >> LMP for such links, it also should be possible to establish >> signaling (RSVP) adjacencies between their ends, etc. The bottom >> line is that distribution of routing information between CEs IHMO is >> not sufficient. I believe this is consistent with the requirements >> stated in ITU-T SG13 L1VPN documents >> >> >> >> Igor >> >> >> >> >> >> */Alex Zinin /* wrote: >> >> Folks- >> >> Before we bring it to the l1vpn mailing list, I'd like to run this > > draft > >> by you guys for comments. >> >> -- >> Alex >> >> >> Layer 1 Virtual Private Networks (l1vpn) >> >> Last Modified: 2005-01-25 >> Chair(s): >> TBD >> TBD >> Routing Area Director(s): >> Bill Fenner >> Alex Zinin >> >> Routing Area Advisor: >> Alex Zinin >> >> Technical Advisor(s): >> >> Mailing Lists: >> General Discussion: l1vpn@ietf.org >> To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn >> Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html >> >> Description of Working Group: >> >> L1VPN Working Group's task is to specify mechanisms necessary for >> providing a VPN service over a GMPLS transport network. >> >> The following two service models will be addressed: >> >> 1. Basic mode: the CE-PE interface's functional repertoire is limited > > to > >> path setup signalling only. The GMPLS network is not involved in >> distribution of user's routing information. >> >> 2. Enhanced mode: the CE-PE interface provides the signaling >> capabilities >> as in the Basic mode, plus permits utilization of the provider's > > control > >> plane for distribution of user's routing information (e.g. similar >> to the >> MPLS/BGP model). >> >> The WG will work on the following items: >> >> 1. Specification of the L1VPN user-to-network interface (UNI) basic >> mode, >> including both CE and PE functionality. >> >> 2. Specification of the L1VPN node-to-node interface (NNI) basic > > mode. > >> ! >> 3. MIB modules and/or extensions required for UNI and NNI basic mode. >> >> 4. Specification of L1VPN UNI enhanced mode. >> >> 5. Specification of L1VPN NNI enhanced mode. >> >> 6. MIB modules and/or extensions required for UNI and NNI enhanced > > mode. > >> Protocol extensions required for L1VPN will be done in cooperation > > with > >> CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. >> >> Milestones: >> >> Sep 05 Submit first Internet Drafts of UNI and NNI basic mode >> specifications >> Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI > > basic > >> mode >> Jun 06 Submit UNI and NNI basic mode specifications to IESG for >> publication as Proposed Standard >> Jun 06 Submit first Internet Draf! ts of UNI and NNI enhanced mode >> specifications >> Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for >> publication as Proposed Standard >> Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for >> publication as Proposed Standard >> Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for >> publication as Proposed Standard >> >> >> >> >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> >>------------------------------------------------------------------------ >>Discover Yahoo! >>Find restaurants, movies, travel & more fun for the weekend. Check it >>out! >> > > > > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From rtg-dir-bounces@ietf.org Fri May 6 06:29:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25803 for ; Fri, 6 May 2005 06:29:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU0Jn-00014z-2r for rtg-dir-archive@ietf.org; Fri, 06 May 2005 06:44:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU03P-0005Rh-NI; Fri, 06 May 2005 06:27:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU03N-0005NK-M9 for rtg-dir@megatron.ietf.org; Fri, 06 May 2005 06:27:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25531 for ; Fri, 6 May 2005 06:27:26 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU0Hr-0000tz-IJ for rtg-dir@ietf.org; Fri, 06 May 2005 06:42:27 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=[127.0.0.1]) by fw.testbed.se with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DU034-0004Nq-7S; Fri, 06 May 2005 12:27:16 +0200 Message-ID: <427B45EF.2010405@pi.se> Date: Fri, 06 May 2005 12:24:47 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Hamid Ould-Brahim , rtg-dir@ietf.org, l1vpn@ietf.org Subject: the dubious P in L1VPN Was: (Re: [L1vpn] Proposed charter for L1VPN WG) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Dimitri, the reason I called it "dubious" is that the service seems be more appropriate for Public operators (Virtual Public Networks), than for "private" use. Note: Hold comments along the line "There might be private entrprises tht want to..." I realize that, what I'm talking about is where we have an immediate need, and I mostly see bw-broker type of operators on the L1VPN market. But you are right the "dubious p" applies to GMPLS VPN also. /Loa Dimitri.Papadimitriou@alcatel.be wrote: < snip > > > note: you mention the "P" for private is bit dubious and so preferrable > to make use GMPLS VPN but is this name not also including the dubious "P" ? > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From rtg-dir-bounces@ietf.org Fri May 6 06:37:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27021 for ; Fri, 6 May 2005 06:37:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU0RW-0001ht-Ab for rtg-dir-archive@ietf.org; Fri, 06 May 2005 06:52:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU0Bl-0006j8-P2; Fri, 06 May 2005 06:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU0Bj-0006j3-O8 for rtg-dir@megatron.ietf.org; Fri, 06 May 2005 06:36:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26834 for ; Fri, 6 May 2005 06:36:04 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU0QD-0001XF-5V for rtg-dir@ietf.org; Fri, 06 May 2005 06:51:05 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=[127.0.0.1]) by fw.testbed.se with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DU0BV-0004PY-3H; Fri, 06 May 2005 12:35:55 +0200 Message-ID: <427B47FA.7000605@pi.se> Date: Fri, 06 May 2005 12:33:30 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Content-Transfer-Encoding: 7bit Cc: Hamid Ould-Brahim , rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Content-Transfer-Encoding: 7bit Dimitri, we've already had the comment that GMPLS can do more than L1, but it is hardly so that L1VPN's can do more than L1. So I guess that the second alternative would be more appropriate, charter a limited (L1) GMPLS VPN work now and extend if we find necessary. We are after all focused on the control plane protocols, and the applicability of those seems to follows control plane capabilities rather than limitations of networking layers. /Loa Dimitri.Papadimitriou@alcatel.be wrote: > loa - > > it seems we have three options > > o) either large focus with GMPLS VPN (but then as sub-title for any > interface based VPN, i.e. GMPLS does cover a larger set than L1 interfaces) > > o) or narrow focused with a title GMPLS VPN and then as sub-title for L1 > interfaces only (but this restriction will simply appear arbitrarily > restrictive for the reason explained above) > > o) or narrow focused with as title L1VPN (and sub-title GMPLS-based) > > => it seems to me that the third option is more appropriate (even if it > comes out that some of the protocol outcomes are similar to the > below-mentionned "Generalized VPN" techniques) > > note: you mention the "P" for private is bit dubious and so preferrable > to make use GMPLS VPN but is this name not also including the dubious "P" ? > > *Loa Andersson * > Sent by: l1vpn-bounces@lists.ietf.org > 05/06/2005 10:26 ZE2 > > To: Hamid Ould-Brahim > cc: rtg-dir@ietf.org, l1vpn@ietf.org > bcc: > Subject: Re: [L1vpn] Proposed charter for L1VPN WG > > > Comments in line. > > /Loa > > Hamid Ould-Brahim wrote: > > > Alex, > > > < snip > > > > > > Just out of curiosity shouldn't this WG be as well within > > the internet area like l2 and l3vpns? Some functions > > are really similar to the ones developed in l2 and l3 vpns. > > > > Routing area is still fine (since ccamp is within this area anyway). > > hmmm, maybe we should discuss which wg are in thge wrong area :) > > < snip> > > > >>Description of Working Group: > >> > >> L1VPN Working Group's task is to specify mechanisms > >>necessary for providing a VPN service over a GMPLS transport network. > >> > > > > > > The above should be more specific that is about L1VPN using GMPLS > > and across a GMPLS enabled network. A "VPN service over GMPLS" includes > > all VPN cases that GMPLS interfaces support while here > > we are looking specifically at l1vpn using gmpls. > > > > I believe that if we solve the GMPLS VPN for L1VPN > > then in fact we are actually solving a much bigger VPN > > problem set (the set of interfaces where GMPLS applies). > > Guess that Hamids comment boils down to that GMPLS can > do more than L1. Strictly speaking ASON (which really is a > degenrate version of GMPLS) could also (in some restricted > way) be used for L1VPNs. > > > And maybe it's much better to solve the GMPLS VPNs That > > include GMPLS L1 based interfaces then starting with > > L1VPN as a service since most of the mechanisms are not > > necessarily L1-based. Something along the line of > > Generalized VPNs. > > I don't think that this wg is the place to solve all genral > VPN problems, would rather urge to focus this really narrow > e.g. the two service models below > > > > > > >> The following two service models will be addressed: > >> > >> 1. Basic mode: the CE-PE interface's functional repertoire > >>is limited to > >> path setup signalling only. The GMPLS network is not involved in > >> distribution of user's routing information. > >> > >> 2. Enhanced mode: the CE-PE interface provides the > >>signaling capabilities > >> as in the Basic mode, plus permits utilization of the > >>provider's control > >> plane for distribution of some information from the > >>user's control > >> plane (e.g. network-layer reachability information as in > >>the MPLS/BGP model). > > Question: would be correct to say that the intention is to > describe an "overlay model" in the in the basic mode and an > "peer model" in the enhanced. If so it should be made clear > that when we talk about "user's routing information" it is the > routing information for the "layer" native to the GMPLS VPN. > > > >> > > > > given that description it is probably time to ask if this a > Layer 1 VPN working group or an GMPLS VPN working group. > The P for Private in VPN is a bit dubious at least in the early > uses of this technology, might be better to name it > GMPLS VPN wg. > > > > > < snip > > > > > >> The WG will work on the following items: > >> > >> 1. Framework document defining the reference network model, > >>L1VPN service > >> model, fundamental assumptions, and terminology. > >> > > < snip> > > > > >> 2. Specification of the L1VPN user-to-network interface > >>(UNI) basic mode, > >> including both CE and PE functionality. > >> > >> 3. Specification of the L1VPN node-to-node interface (NNI) > >>basic mode. > > don't understand this node-to-node, the user inerface seems > enough or do we intend to do interdomain hops on L1? > > >> > >> 4. MIB modules and/or extensions required for UNI and NNI > >>basic mode. > >> > >> 5. Specification of L1VPN UNI enhanced mode. > >> > >> 6. Specification of L1VPN NNI enhanced mode. > >> > >> 7. MIB modules and/or extensions required for UNI and NNI > >>enhanced mode. > > I would like to see the security issue mentioned explicitly. > > >> > >> Protocol extensions required for L1VPN will be done in > >>cooperation with CCAMP, OSPF, IS-IS, IDR, and other WGs > >>where necessary. Where necessary, the WG will also cooperate > >>with ITU-T. > > I guess that the thought here is that ccamp acts on behalf of > the mpls wg, but would be happier if the mpls wg were mentioned > ecxplicitly, also since we mention the BGP/MPLS VPNs some > coordintion with L3VPN might turn out necessary. > I also think that the paragraph is to weak, it should say. > > "Protocol extensions required for L1VPN need to be done with > by the working roup that owns the base protocol, e.g. CCAMP, > MPLS, OSPF, IS-IS, IDR, and other WGs where necessary. Where > necessary, the WG will also cooperate with ITU-T." > > >> > >>Milestones: > >> > >> Sep 05 Submit first Internet Draft of L1VPN framework > >> > >> Sep 05 Submit first Internet Drafts of UNI and NNI basic > >>mode specifications > >> > >> Dec 05 Submit first Internet Drafts of MIB modules for UNI > >>and NNI basic mode > >> > >> Apr 06 Submit UNI and NNI basic mode specifications to IESG > >>for publication as Proposed Standard > >> > >> Jun 06 Submit first Internet Drafts of UNI and NNI enhanced > >>mode specifications > >> > >> Aug 06 Submit MIB modules for UNI and NNI basic mode to > >>IESG for publication as Proposed Standard > >> > >> Dec 06 Submit UNI and NNI enhanced mode specifications to > >>IESG for publication as Proposed Standard > >> > >> Dec 06 Submit L1VPN framework to IESG for publication as > >>Informational RFC > >> > >> Aug 07 Submit MIB modules for UNI and NNI enhanced mode to > >>IESG for publication as Proposed Standard > >> > > There are some comments, e.g. on the NNI that could affect the > milestones once they are resoloved. > > /Loa > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.se > > _______________________________________________ > L1vpn mailing list > L1vpn@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/l1vpn > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From rtg-dir-bounces@ietf.org Fri May 6 08:03:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04570 for ; Fri, 6 May 2005 08:03:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU1n8-0007Hu-1j for rtg-dir-archive@ietf.org; Fri, 06 May 2005 08:18:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU1Vs-0000R2-7u; Fri, 06 May 2005 08:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU1Vp-0000Q5-VD; Fri, 06 May 2005 08:00:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04058; Fri, 6 May 2005 08:00:56 -0400 (EDT) Received: from cronos.ocn.ne.jp ([222.146.51.136] helo=smtp.cronos.ocn.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU1kJ-00071z-4v; Fri, 06 May 2005 08:15:56 -0400 Received: from TAKEDAPANA.lab.ntt.co.jp (FLA1Aeg209.tky.mesh.ad.jp [221.170.151.209]) by smtp.cronos.ocn.ne.jp (Postfix) with ESMTP id 604102B6C; Fri, 6 May 2005 21:00:42 +0900 (JST) Message-Id: <5.1.1.11.2.20050506205131.061207e0@cronos.ocn.ne.jp> X-Sender: takeda.tomonori@cronos.ocn.ne.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1J Jr5-rev2 Date: Fri, 06 May 2005 21:00:38 +0900 To: "Hamid Ould-Brahim" , Alex Zinin From: Tomonori TAKEDA In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D04622980@zcarhxm0.corp.nor tel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: RE: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Hamid, >> >> The WG will work on the following items: >> >> >> >> 1. Framework document defining the reference network model, >> >> L1VPN service >> >> model, fundamental assumptions, and terminology. >> >> >> >> > Should we as well add requirement document? I think we should >> > (since this is a service after all). >> >> Is there a disagreement in the community on what L1VPNs should do? >> If so, can it be resolved on the mailing list? >> > >I think service requirements can guide the work to >identify items such as which parameters to consider in signaling, >etc, but you maybe right. I am interested to hear providers opinion >on that. My suggestion would be to reuse what has been already >done in ITU (just we need to make it visible to ietf folks...). I think framework document can describe service requirements. Curret framework document (draft-takeda-l1vpn-framework-03) already contains service requirements. There may be some detailed points to be discussed, especially for the enhanced mode (sig+rtg model), as we see some discussion. (Framework document is describing a broad range of things, but not at the level of protocol requirements.) So, it may be necessary to narrow down the scope for the enhanced mode, which can be done through the mailing list, or if needed, through writing a separate draft. (I don't think we have an immediate need to write a separate draft.) Best regards, Tomonori > >Another item that needs to be added is "security" (after all >this is a VPN problem), and particularly that we allow >some critical information exchange between CE and PE. >My experience working on this topic is provider will want >maximum security between CE and PEs (and between providers) >clarifying how security is provided between PE and CEs >(and between provider border nodes) will help what appropriate >mechanisms to use for address separation, authentication, etc. > >Hamid. > >_______________________________________________ >L1vpn mailing list >L1vpn@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/l1vpn From rtg-dir-bounces@ietf.org Fri May 6 09:08:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12290 for ; Fri, 6 May 2005 09:08:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU2nK-0003Du-8s for rtg-dir-archive@ietf.org; Fri, 06 May 2005 09:23:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU2Xc-0002pL-TG; Fri, 06 May 2005 09:06:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU2Xa-0002p9-II for rtg-dir@megatron.ietf.org; Fri, 06 May 2005 09:06:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12164 for ; Fri, 6 May 2005 09:06:48 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU2m5-00033F-8F for rtg-dir@ietf.org; Fri, 06 May 2005 09:21:50 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=[127.0.0.1]) by fw.testbed.se with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DU2XI-0004s3-7y; Fri, 06 May 2005 15:06:35 +0200 Message-ID: <427B6B49.3050101@pi.se> Date: Fri, 06 May 2005 15:04:09 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Content-Transfer-Encoding: 7bit Cc: Hamid Ould-Brahim , rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Content-Transfer-Encoding: 7bit Dimitri, I might be a bit dogmatic about this, but I think that IETF should be "protocol centric", it is fine to ue our prtocols for whatever application they are useful for, but I would be reluctant if we wer about to start specifying whatever protocol that could be useful for an application /Loa Dimitri.Papadimitriou@alcatel.be wrote: > loa, > > ok - your point of view is to have a GMPLS VPN WG focusing on L1VPN for > now (and future will tell us if further LxVPN work should be included in > this working group - hope x will stay limited ;-) > > in this case, it means we build a protocol-centric WG working on a > single application now and potential further extends its application > scope rather than having an application-centric WG working on > (extending) a protocol suite - difference is subtle but worth mentioning - > > > *Loa Andersson * > Sent by: rtg-dir-bounces@ietf.org > 05/06/2005 12:33 ZE2 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: Hamid Ould-Brahim , rtg-dir@ietf.org, l1vpn@ietf.org > bcc: > Subject: Re: [L1vpn] Proposed charter for L1VPN WG > > > Dimitri, > > we've already had the comment that GMPLS can do more than L1, but > it is hardly so that L1VPN's can do more than L1. > > So I guess that the second alternative would be more appropriate, > charter a limited (L1) GMPLS VPN work now and extend if we find > necessary. We are after all focused on the control plane protocols, > and the applicability of those seems to follows control plane > capabilities rather than limitations of networking layers. > > /Loa > > Dimitri.Papadimitriou@alcatel.be wrote: > > > loa - > > > > it seems we have three options > > > > o) either large focus with GMPLS VPN (but then as sub-title for any > > interface based VPN, i.e. GMPLS does cover a larger set than L1 > interfaces) > > > > o) or narrow focused with a title GMPLS VPN and then as sub-title for L1 > > interfaces only (but this restriction will simply appear arbitrarily > > restrictive for the reason explained above) > > > > o) or narrow focused with as title L1VPN (and sub-title GMPLS-based) > > > > => it seems to me that the third option is more appropriate (even if it > > comes out that some of the protocol outcomes are similar to the > > below-mentionned "Generalized VPN" techniques) > > > > note: you mention the "P" for private is bit dubious and so preferrable > > to make use GMPLS VPN but is this name not also including the dubious > "P" ? > > > > *Loa Andersson * > > Sent by: l1vpn-bounces@lists.ietf.org > > 05/06/2005 10:26 ZE2 > > > > To: Hamid Ould-Brahim > > cc: rtg-dir@ietf.org, l1vpn@ietf.org > > bcc: > > Subject: Re: [L1vpn] Proposed charter for L1VPN WG > > > > > > Comments in line. > > > > /Loa > > > > Hamid Ould-Brahim wrote: > > > > > Alex, > > > > > < snip > > > > > > > > > Just out of curiosity shouldn't this WG be as well within > > > the internet area like l2 and l3vpns? Some functions > > > are really similar to the ones developed in l2 and l3 vpns. > > > > > > Routing area is still fine (since ccamp is within this area anyway). > > > > hmmm, maybe we should discuss which wg are in thge wrong area :) > > > > < snip> > > > > > > >>Description of Working Group: > > >> > > >> L1VPN Working Group's task is to specify mechanisms > > >>necessary for providing a VPN service over a GMPLS transport network. > > >> > > > > > > > > > The above should be more specific that is about L1VPN using GMPLS > > > and across a GMPLS enabled network. A "VPN service over GMPLS" > includes > > > all VPN cases that GMPLS interfaces support while here > > > we are looking specifically at l1vpn using gmpls. > > > > > > I believe that if we solve the GMPLS VPN for L1VPN > > > then in fact we are actually solving a much bigger VPN > > > problem set (the set of interfaces where GMPLS applies). > > > > Guess that Hamids comment boils down to that GMPLS can > > do more than L1. Strictly speaking ASON (which really is a > > degenrate version of GMPLS) could also (in some restricted > > way) be used for L1VPNs. > > > > > And maybe it's much better to solve the GMPLS VPNs That > > > include GMPLS L1 based interfaces then starting with > > > L1VPN as a service since most of the mechanisms are not > > > necessarily L1-based. Something along the line of > > > Generalized VPNs. > > > > I don't think that this wg is the place to solve all genral > > VPN problems, would rather urge to focus this really narrow > > e.g. the two service models below > > > > > > > > > > >> The following two service models will be addressed: > > >> > > >> 1. Basic mode: the CE-PE interface's functional repertoire > > >>is limited to > > >> path setup signalling only. The GMPLS network is not involved in > > >> distribution of user's routing information. > > >> > > >> 2. Enhanced mode: the CE-PE interface provides the > > >>signaling capabilities > > >> as in the Basic mode, plus permits utilization of the > > >>provider's control > > >> plane for distribution of some information from the > > >>user's control > > >> plane (e.g. network-layer reachability information as in > > >>the MPLS/BGP model). > > > > Question: would be correct to say that the intention is to > > describe an "overlay model" in the in the basic mode and an > > "peer model" in the enhanced. If so it should be made clear > > that when we talk about "user's routing information" it is the > > routing information for the "layer" native to the GMPLS VPN. > > > > > > >> > > > > > > > given that description it is probably time to ask if this a > > Layer 1 VPN working group or an GMPLS VPN working group. > > The P for Private in VPN is a bit dubious at least in the early > > uses of this technology, might be better to name it > > GMPLS VPN wg. > > > > > > > > > < snip > > > > > > > > >> The WG will work on the following items: > > >> > > >> 1. Framework document defining the reference network model, > > >>L1VPN service > > >> model, fundamental assumptions, and terminology. > > >> > > > > < snip> > > > > > > > >> 2. Specification of the L1VPN user-to-network interface > > >>(UNI) basic mode, > > >> including both CE and PE functionality. > > >> > > >> 3. Specification of the L1VPN node-to-node interface (NNI) > > >>basic mode. > > > > don't understand this node-to-node, the user inerface seems > > enough or do we intend to do interdomain hops on L1? > > > > >> > > >> 4. MIB modules and/or extensions required for UNI and NNI > > >>basic mode. > > >> > > >> 5. Specification of L1VPN UNI enhanced mode. > > >> > > >> 6. Specification of L1VPN NNI enhanced mode. > > >> > > >> 7. MIB modules and/or extensions required for UNI and NNI > > >>enhanced mode. > > > > I would like to see the security issue mentioned explicitly. > > > > >> > > >> Protocol extensions required for L1VPN will be done in > > >>cooperation with CCAMP, OSPF, IS-IS, IDR, and other WGs > > >>where necessary. Where necessary, the WG will also cooperate > > >>with ITU-T. > > > > I guess that the thought here is that ccamp acts on behalf of > > the mpls wg, but would be happier if the mpls wg were mentioned > > ecxplicitly, also since we mention the BGP/MPLS VPNs some > > coordintion with L3VPN might turn out necessary. > > I also think that the paragraph is to weak, it should say. > > > > "Protocol extensions required for L1VPN need to be done with > > by the working roup that owns the base protocol, e.g. CCAMP, > > MPLS, OSPF, IS-IS, IDR, and other WGs where necessary. Where > > necessary, the WG will also cooperate with ITU-T." > > > > >> > > >>Milestones: > > >> > > >> Sep 05 Submit first Internet Draft of L1VPN framework > > >> > > >> Sep 05 Submit first Internet Drafts of UNI and NNI basic > > >>mode specifications > > >> > > >> Dec 05 Submit first Internet Drafts of MIB modules for UNI > > >>and NNI basic mode > > >> > > >> Apr 06 Submit UNI and NNI basic mode specifications to IESG > > >>for publication as Proposed Standard > > >> > > >> Jun 06 Submit first Internet Drafts of UNI and NNI enhanced > > >>mode specifications > > >> > > >> Aug 06 Submit MIB modules for UNI and NNI basic mode to > > >>IESG for publication as Proposed Standard > > >> > > >> Dec 06 Submit UNI and NNI enhanced mode specifications to > > >>IESG for publication as Proposed Standard > > >> > > >> Dec 06 Submit L1VPN framework to IESG for publication as > > >>Informational RFC > > >> > > >> Aug 07 Submit MIB modules for UNI and NNI enhanced mode to > > >>IESG for publication as Proposed Standard > > >> > > > > There are some comments, e.g. on the NNI that could affect the > > milestones once they are resoloved. > > > > /Loa > > > > -- > > Loa Andersson > > > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > > > > loa@pi.se > > > > _______________________________________________ > > L1vpn mailing list > > L1vpn@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/l1vpn > > > > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.se -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From rtg-dir-bounces@ietf.org Fri May 6 09:40:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15375 for ; Fri, 6 May 2005 09:40:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU3J6-0005M7-VB for rtg-dir-archive@ietf.org; Fri, 06 May 2005 09:55:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU33Y-0008Dz-BK; Fri, 06 May 2005 09:39:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU33W-0008Dr-9P; Fri, 06 May 2005 09:39:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15221; Fri, 6 May 2005 09:39:48 -0400 (EDT) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU3I0-0005Bz-Hg; Fri, 06 May 2005 09:54:49 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j46DdSZ12901; Fri, 6 May 2005 09:39:28 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 May 2005 09:39:29 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0469A24B@zcarhxm0.corp.nortel.com> From: "Hamid Ould-Brahim" To: Tomonori TAKEDA , Alex Zinin Date: Fri, 6 May 2005 09:39:11 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: RE: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Tomonori, > > I think framework document can describe service requirements. > > Curret framework document (draft-takeda-l1vpn-framework-03) already > contains service requirements. There may be some detailed > points to be > discussed, especially for the enhanced mode (sig+rtg model), > as we see some > discussion. (Framework document is describing a broad range > of things, but > not at the level of protocol requirements.) So, it may be > necessary to > narrow down the scope for the enhanced mode, which can be > done through the > mailing list, or if needed, through writing a separate draft. > (I don't > think we have an immediate need to write a separate draft.) > I do agree the framework draft covers the requirements and is inline with ITU L1VPN work. An option that can be considered is to separate the requirements from the framework in separate internet draft and let the two drafts progress independently (from work point of view). I assume at certain point solutions (and not the framework) would have to be compared to the set of requirements listed. Hamid. From rtg-dir-bounces@ietf.org Fri May 6 10:36:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21322 for ; Fri, 6 May 2005 10:36:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU4B1-0000EV-Te for rtg-dir-archive@ietf.org; Fri, 06 May 2005 10:51:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU3tE-00077i-Ii; Fri, 06 May 2005 10:33:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU3tC-000772-D6; Fri, 06 May 2005 10:33:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20885; Fri, 6 May 2005 10:33:11 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU47g-0008Ui-M4; Fri, 06 May 2005 10:48:14 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j46EWv209803; Fri, 6 May 2005 10:32:58 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 May 2005 10:32:53 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0469A366@zcarhxm0.corp.nortel.com> From: "Hamid Ould-Brahim" To: Loa Andersson Date: Fri, 6 May 2005 10:32:39 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Alex Zinin , rtg-dir@ietf.org, l1vpn@ietf.org Subject: RE: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Loa, (I understand this email wasn't intended specifically to me) but you raised an interesting point I would like to comment on it. > > Guess that Hamids comment boils down to that GMPLS can > do more than L1. Back like four years ago, some of us (ietf folks) proposed the topic of "Optical VPNs" (GMPLS VPNs). So we had at that time requirement draft and some solution drafts here and there. The feedback from presentations and discussions at IETF meetings came that Optical is not really covering TDM. We went back and made it clear that it is about "Optical/TDM" VPNs (no change on technical content just title change). After other IETF meetings, the feedback came as well that Optical VPN is not really within the scope of IETF and a proposal was made to call it Generalized VPNs which are VPNs built using IETF GMPLS protocols and they apply where GMPLS apply. We went to the work we have done and made another minor change (pretty much find and replace function). Changes things like "Connection" to "LSPs", Optical/TDM to GVPN, etc. We didn't really change the functionality of the mechanisms which stayed pretty much the same. That is to say that it is not a major work to consider services other than L1 as long as functions are well defined using GMPLS and VPN constructs. But I am okay if we focus initially on L1VPN as a service, my suggestion would be that from protocol point of view the work should aim when possible to use GMPLS (and VPN constructs) regardless whether they apply to L1 or other interfaces supported by GMPLS such that if later on we decide to extend the mandate of that group we already have most of key protocol work done. > > I don't think that this wg is the place to solve all genral VPN > problems, would rather urge to focus this really narrow e.g. the two > service models below > I am fine with that. In fact I believe that the second service model can be further subdivided in two separate service models. One when the GMPLS provider network will appear to the client nodes as *one* private GMPLS-enabled node, and the other where the provider network appear as a subset of provider network resources (or nodes) to the client nodes as a private Gmpls network (fully interacting with client network). Hamid. From rtg-dir-bounces@ietf.org Fri May 6 11:07:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24130 for ; Fri, 6 May 2005 11:07:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU4eR-0002CU-EP for rtg-dir-archive@ietf.org; Fri, 06 May 2005 11:22:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4PC-0003Nu-WE; Fri, 06 May 2005 11:06:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4PA-0003MI-Mp; Fri, 06 May 2005 11:06:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24024; Fri, 6 May 2005 11:06:13 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU4dg-0002Bj-ME; Fri, 06 May 2005 11:21:17 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j46F6ALD016085; Fri, 6 May 2005 17:06:13 +0200 To: "Hamid Ould-Brahim" MIME-Version: 1.0 Date: Fri, 6 May 2005 17:06:09 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/06/2005 17:06:13 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 4.8 (++++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: base64 Cc: Alex Zinin , rtg-dir@ietf.org, l1vpn@ietf.org, Tomonori TAKEDA Subject: RE: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.8 (++++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmhhbWlkIC0gPC9GT05UPjwvUD48UD48 Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+dGhlIGZyYW1ld29yayBkb2N1bWVudCBoYXMg YmVlbiB1c2VkIHRvIGRldGVybWluZSB0aGUgcHJvdG9jb2wgd29yayB0aGlzIGdyb3VwIGlzIGdv aW5nIHRvIGFkZHJlc3MsIGlmIHR3byBkb2N1bWVudHMgKHJlcXVpcmVtZW50cyArIGZyYW1ld29y aykgYXJlIHRvIGJlIHByb2dyZXNzZWQgaW4gcGFyYWxsZWwgaXQgbWVhbnMgdGhhdCBlaXRoZXI8 L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4tIHlvdSBzdWdnZXN0 IHdlIGtlZXAgY29udGludWluZyB3b3JrIG9uIGZ1bmN0aW9uYWwgcmVxdWlyZW1lbnRzIGJ1dCB0 aGVuIG9uZSBjb3VsZCBxdWVzdGlvbiB3aGV0aGVyIHdlIGFncmVlIG9uIHdoYXQgdG8gZG8gaW4g dGhpcyB3b3JraW5nIGdyb3VwID8gKG5vdGU6IHByb3RvY29sIGRldGFpbHMgd2lsbCBiZSB3b3Jr ZWQgb3V0IGFzIHBhcnQgb2YgdGhlIHByb3RvY29sIHdvcmsgYW55d2F5KTwvRk9OVD48L1A+PFA+ PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0gb3IgeW91IGRvIHN1Z2dlc3QgdGhhdCB3 ZSBjbG9zZSB0aGUgcmVxdWlyZW1lbnRzIGFzYXAgKGJ1dCB0aGVuIHdoYXQgaXMgdGhlIHB1cnBv c2Ugb2YgaXQgYXMgd2Ugd291bGQgYmUgYWxsIGluIGFncmVlbWVudCA/IGhlcmUgYWxzbyBkZXRh aWxzIHdpbGwgYmUgd29ya2VkIG91dCBhcyBwYXJ0IG9mdGhlIHByb3RvY29sIHdvcmsgYW55d2F5 KSBhbmQgdGhlIGZyYW1ld29yayBiZWNvbWVzIHRoZSBkb2N1bWVudCB3aGVyZSB0ZXJtcywgd29y a2luZyBhc3N1bXB0aW9ucyBhbmQgb3RoZXIgbW9kZWxzIGdldCBkb2N1bWVudGVkIGFzIHN1Z2dl c3RlZCBpbiB0aGUgaW5pdGlhbCBjaGFydGVyIHByb3Bvc2FsPC9GT05UPjwvUD48UD48Rk9OVCBG QUNFPSJNb25vc3BhY2UsQ291cmllciI+d291bGQgeW91IGNsYXJpZnkgeW91ciB0aG91Z2h0IGJl Y2F1c2UgaSBoYXZlIHNvbWUgZGlmZmljdWx0aWVzIHRvIHVuZGVyc3RhbmQgdGhlIGxvZ2ljIGJl aGluZCB0aGUgYmVsb3cgcmVhc29uaW5nID88QlI+PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+PEI+ JnF1b3Q7SGFtaWQgT3VsZC1CcmFoaW0mcXVvdDsgJmx0O2hicmFoaW1Abm9ydGVsLmNvbSZndDs8 L0I+PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+U2VudCBieTogcnRnLWRpci1ib3VuY2VzQGlldGYu b3JnPC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+MDUvMDYvMjAwNSAwOTozOSBBU1Q8L0ZPTlQ+PEJS PjxCUj4gPEZPTlQgU0laRT0yPlRvOjwvRk9OVD4gPEZPTlQgU0laRT0yPlRvbW9ub3JpIFRBS0VE QSAmbHQ7dGFrZWRhLnRvbW9ub3JpQGxhYi5udHQuY28uanAmZ3Q7LCBBbGV4IFppbmluICZsdDt6 aW5pbkBwc2cuY29tJmd0OzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+IDxGT05U IFNJWkU9Mj5ydGctZGlyQGlldGYub3JnLCBsMXZwbkBpZXRmLm9yZzwvRk9OVD48QlI+IDxGT05U IFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZP TlQgU0laRT0yPlJFOiBbTDF2cG5dIFByb3Bvc2VkIGNoYXJ0ZXIgZm9yIEwxVlBOIFdHPC9GT05U PjxCUj4gPEJSPjxCUj48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlRvbW9u b3JpLDxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7PEJS PiZndDsgSSB0aGluayBmcmFtZXdvcmsgZG9jdW1lbnQgY2FuIGRlc2NyaWJlIHNlcnZpY2UgcmVx dWlyZW1lbnRzLjxCUj4mZ3Q7PEJSPiZndDsgQ3VycmV0IGZyYW1ld29yayBkb2N1bWVudCAoZHJh ZnQtdGFrZWRhLWwxdnBuLWZyYW1ld29yay0wMykgYWxyZWFkeTxCUj4mZ3Q7IGNvbnRhaW5zIHNl cnZpY2UgcmVxdWlyZW1lbnRzLiBUaGVyZSBtYXkgYmUgc29tZSBkZXRhaWxlZDxCUj4mZ3Q7IHBv aW50cyB0byBiZTxCUj4mZ3Q7IGRpc2N1c3NlZCwgZXNwZWNpYWxseSBmb3IgdGhlIGVuaGFuY2Vk IG1vZGUgKHNpZytydGcgbW9kZWwpLDxCUj4mZ3Q7IGFzIHdlIHNlZSBzb21lPEJSPiZndDsgZGlz Y3Vzc2lvbi4gKEZyYW1ld29yayBkb2N1bWVudCBpcyBkZXNjcmliaW5nIGEgYnJvYWQgcmFuZ2U8 QlI+Jmd0OyBvZiB0aGluZ3MsIGJ1dDxCUj4mZ3Q7IG5vdCBhdCB0aGUgbGV2ZWwgb2YgcHJvdG9j b2wgcmVxdWlyZW1lbnRzLikgU28sIGl0IG1heSBiZTxCUj4mZ3Q7IG5lY2Vzc2FyeSB0bzxCUj4m Z3Q7IG5hcnJvdyBkb3duIHRoZSBzY29wZSBmb3IgdGhlIGVuaGFuY2VkIG1vZGUsIHdoaWNoIGNh biBiZTxCUj4mZ3Q7IGRvbmUgdGhyb3VnaCB0aGU8QlI+Jmd0OyBtYWlsaW5nIGxpc3QsIG9yIGlm IG5lZWRlZCwgdGhyb3VnaCB3cml0aW5nIGEgc2VwYXJhdGUgZHJhZnQuPEJSPiZndDsgKEkgZG9u J3Q8QlI+Jmd0OyB0aGluayB3ZSBoYXZlIGFuIGltbWVkaWF0ZSBuZWVkIHRvIHdyaXRlIGEgc2Vw YXJhdGUgZHJhZnQuKTxCUj4mZ3Q7PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNl LENvdXJpZXIiPkkgZG8gYWdyZWUgdGhlIGZyYW1ld29yayBkcmFmdCBjb3ZlcnMgdGhlIHJlcXVp cmVtZW50cyBhbmQgaXMgaW5saW5lPEJSPndpdGggSVRVIEwxVlBOIHdvcmsuIEFuIG9wdGlvbiB0 aGF0IGNhbiBiZSBjb25zaWRlcmVkIGlzIHRvIHNlcGFyYXRlPEJSPnRoZSByZXF1aXJlbWVudHMg ZnJvbSB0aGUgZnJhbWV3b3JrIGluIHNlcGFyYXRlIGludGVybmV0IGRyYWZ0IGFuZDxCUj5sZXQg dGhlIHR3byBkcmFmdHMgcHJvZ3Jlc3MgaW5kZXBlbmRlbnRseSAoZnJvbSB3b3JrIHBvaW50IG9m IHZpZXcpLjxCUj5JIGFzc3VtZSBhdCBjZXJ0YWluIHBvaW50IHNvbHV0aW9ucyAoYW5kIG5vdCB0 aGUgZnJhbWV3b3JrKSB3b3VsZCBoYXZlPEJSPnRvIGJlIGNvbXBhcmVkIHRvIHRoZSBzZXQgb2Yg cmVxdWlyZW1lbnRzIGxpc3RlZC48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2Us Q291cmllciI+SGFtaWQuPEJSPjwvRk9OVD48L1A+ From rtg-dir-bounces@ietf.org Fri May 6 11:08:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24350 for ; Fri, 6 May 2005 11:08:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU4ff-0002MY-Ot for rtg-dir-archive@ietf.org; Fri, 06 May 2005 11:23:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4Qw-0003a3-OS; Fri, 06 May 2005 11:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4Qu-0003Zu-UR for rtg-dir@megatron.ietf.org; Fri, 06 May 2005 11:08:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24333 for ; Fri, 6 May 2005 11:08:02 -0400 (EDT) Received: from instramet-gw.kyiv.wnet.ua ([217.20.183.37]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DU4fP-0002M0-99 for rtg-dir@ietf.org; Fri, 06 May 2005 11:23:05 -0400 Message-ID: From: "TJ Meds Ltd." <157conrad@ab-s.co.uk> To: rtg-dir@ietf.org Date: Fri, 06 May 2005 14:58:26 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_2FC512E2.079703F8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: Xanax - LOW price! X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.7 (++++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_0000_2FC512E2.079703F8 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_C244F477.7FD6FAF1" ------=_NextPart_001_0001_C244F477.7FD6FAF1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit VALIUM - $1.10/pill XANAX - $1.07/pill http://www.populartablets.biz Anti-Depressants: Paxil, Prozac, Zoloft Pain Relief: Celebrex, Soma, Vioxx Weight Loss: Meridia, Xenical Other: Levitra, Propecia, Ambien _________________________________________________________________________ To change your mail preferences, go here _________________________________________________________________________ ------=_NextPart_001_0001_C244F477.7FD6FAF1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

    VALIUM - $1.10/pill
    XANAX - $1.07/pill

    http://www.populartablets.biz

    Anti-Depressants: Paxil, Prozac, Zoloft
    Pain Relief: Celebrex, Soma, Vioxx
    Weight Loss: Meridia, Xenical
    Other: Levitra, Propecia, Ambien


    _________________________________________________________________________
    To change your mail preferences, go here
    _________________________________________________________________________

    ------=_NextPart_001_0001_C244F477.7FD6FAF1-- ------=_NextPart_000_0000_2FC512E2.079703F8-- From rtg-dir-bounces@ietf.org Fri May 6 11:43:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02678 for ; Fri, 6 May 2005 11:43:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU5Dz-0005p4-Qe for rtg-dir-archive@ietf.org; Fri, 06 May 2005 11:58:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4xr-0004fX-6H; Fri, 06 May 2005 11:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4xp-0004e9-7z; Fri, 06 May 2005 11:42:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02413; Fri, 6 May 2005 11:42:00 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU5CH-0005d1-VS; Fri, 06 May 2005 11:57:04 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j46Ff8A08664; Fri, 6 May 2005 11:41:09 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 May 2005 11:41:32 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0469A4F0@zcarhxm0.corp.nortel.com> From: "Hamid Ould-Brahim" To: Dimitri.Papadimitriou@alcatel.be Date: Fri, 6 May 2005 11:41:16 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Alex Zinin , rtg-dir@ietf.org, l1vpn@ietf.org Subject: RE: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Dimitri, My suggestion was more on the logistic side. More likely requirement, framework, solutions/mechanism will evolve (in terms of work) in parallel, if later on and as we progress an update is required on the list of requirements that will impact only the mechanisms (like specific parameters) one needs not to go and update the framework document. One can track the service requirements separately from tracking the framework. I was actually talking about service requirements (not specifically functional requirements). And since we already have a set of requirements why not start with that. Framework and service requirements can progress first... As I indicated before if providers think having a separate service requirement draft is not required and it is okay to continue the req work within the framework draft then I am fine with that. An example we can use is what has been done in l2vpn wg. Hamid. the framework document has been used to determine the protocol work this group is going to address, if two documents (requirements + framework) are to be progressed in parallel it means that either - you suggest we keep continuing work on functional requirements but then one could question whether we agree on what to do in this working group ? (note: protocol details will be worked out as part of the protocol work anyway) - or you do suggest that we close the requirements asap (but then what is the purpose of it as we would be all in agreement ? here also details will be worked out as part ofthe protocol work anyway) and the framework becomes the document where terms, working assumptions and other models get documented as suggested in the initial charter proposal would you clarify your thought because i have some difficulties to understand the logic behind the below reasoning ? "Hamid Ould-Brahim" Sent by: rtg-dir-bounces@ietf.org 05/06/2005 09:39 AST To: Tomonori TAKEDA , Alex Zinin cc: rtg-dir@ietf.org, l1vpn@ietf.org bcc: Subject: RE: [L1vpn] Proposed charter for L1VPN WG Tomonori, > > I think framework document can describe service requirements. > > Curret framework document (draft-takeda-l1vpn-framework-03) already > contains service requirements. There may be some detailed > points to be > discussed, especially for the enhanced mode (sig+rtg model), > as we see some > discussion. (Framework document is describing a broad range > of things, but > not at the level of protocol requirements.) So, it may be > necessary to > narrow down the scope for the enhanced mode, which can be > done through the > mailing list, or if needed, through writing a separate draft. > (I don't > think we have an immediate need to write a separate draft.) > I do agree the framework draft covers the requirements and is inline with ITU L1VPN work. An option that can be considered is to separate the requirements from the framework in separate internet draft and let the two drafts progress independently (from work point of view). I assume at certain point solutions (and not the framework) would have to be compared to the set of requirements listed. Hamid. From rtg-dir-bounces@ietf.org Fri May 6 11:57:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04228 for ; Fri, 6 May 2005 11:57:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU5RH-0006dr-5c for rtg-dir-archive@ietf.org; Fri, 06 May 2005 12:12:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU5BC-0007UZ-Vi; Fri, 06 May 2005 11:55:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU5BA-0007UH-To; Fri, 06 May 2005 11:55:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04068; Fri, 6 May 2005 11:55:49 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU5Pg-0006bb-B2; Fri, 06 May 2005 12:10:53 -0400 Received: from du-069-0306.access.clara.net ([217.158.145.52] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DU5B4-000IvN-7Y; Fri, 06 May 2005 16:55:47 +0100 Message-ID: <0c0701c55254$59e186d0$1c849ed9@Puppy> From: "Adrian Farrel" To: References: Date: Fri, 6 May 2005 16:57:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: Alex Zinin , rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Hi Dimitri, > "7. OAM features and MIB modules and/or extensions required for the > extended mode. > > 8. Applicability guidelines to compare the basic and extended modes. > > 9. Specification of the L1VPN extensions for applying the basic and > extended modes to multi-provider L1VPNs." > > which OAM mechanisms are you referring to in the L1 context ? if you are > referring to the control plane mechanisms they should be part of the corr. > control document Definitely CP mechanisms. But I while I would want requirements up front, and protocol extensions to consider OAM requirements, I would not necessarily want protocol extensions to become heavily bound up with OAM solutions. For example, we would not insist that the MIB modules formed part of the protocol extensions. > this said, why not combining item 8 and 9 in a single item and leave the > multiple-provider case for the next step I think I can agree to leaving multi-provider to the next step (although note that we have already received a question about how to provide this function). In which case, we are not combining items 8 and 9. We are deleting item 9. This is fine. > "8. Guidelines for applying the basic and extended modes for > single-provider networks." Also OK. > note: you were also questioning about the reason of > > " Dec 06 Submit L1VPN framework to IESG for publication as Informational > RFC" > > for a document defining the reference network model, L1VPN service > model, fundamental assumptions, and terminology; indeed the framework leads > as its first version is going to be submitted by Sep05 should lead and > should be 90%+ cooked. but it also covers terminology and other certain > aspects that can be retro-actively impacted by the protocol work - > experience has shown that such document becomes fully stable when the > protocol work is near completion OK, whatever works. We certainly saw an element of this during (e.g.) P2MP MPLS TE, but we will still complete the document containing the terminology ahead of the protocol spec. Adrian From rtg-dir-bounces@ietf.org Fri May 6 14:27:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20107 for ; Fri, 6 May 2005 14:27:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU7mE-00084H-SC for rtg-dir-archive@ietf.org; Fri, 06 May 2005 14:42:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU7WI-0007bu-9W; Fri, 06 May 2005 14:25:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU7WF-0007as-Um; Fri, 06 May 2005 14:25:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19678; Fri, 6 May 2005 14:25:46 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU7kn-0007z6-R7; Fri, 06 May 2005 14:40:50 -0400 Received: from [211.51.17.47] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DU7WB-0001QX-Ee; Fri, 06 May 2005 14:25:45 -0400 X-Apparently-To: rtg-bfd@ietf.org X-Sieve: CMU Sieve 2.2 Received: from porcine.prostrate.pochta.ru ([unix socket]) by anonymous.pram.pochta.ru (Cyrus v2.2.6) with LMTPA; Sat, 07 May 2005 01:12:26 +0600 Date: Fri, 06 May 2005 15:13:26 -0400 From: "Gilda Burns" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: rtg-bfd@ietf.org X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rtg-dir@ietf.org, rtgwg-admin@ietf.org, rtgwg-web-archive@ietf.org, s@ietf.org, rtgwg@ietf.org, s.o.f.t.w.a.r.e@ietf.org, rtg-bfd-admin@ietf.org, rv@ietf.org Subject: Notification: We offer low rates X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.3 (+++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.trust1ng.com/sign.asp Best Regards, Angelia Langston to be remov(ed: http://www.trust1ng.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Fri May 6 16:57:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10005 for ; Fri, 6 May 2005 16:57:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUA7U-0002ds-5w for rtg-dir-archive@ietf.org; Fri, 06 May 2005 17:12:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU9sd-0007mW-Es; Fri, 06 May 2005 16:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU9sX-0007lv-5f; Fri, 06 May 2005 16:56:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09996; Fri, 6 May 2005 16:56:54 -0400 (EDT) Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUA75-0002dW-An; Fri, 06 May 2005 17:12:00 -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 j46KuRGB007525; Fri, 6 May 2005 15:56:45 -0500 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh5i.attrh.att.com (7.2.052) id 42628972004E2012; Fri, 6 May 2005 16:56:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 May 2005 15:56:42 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF099CFA93@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [L1vpn] Proposed charter for L1VPN WG Thread-Index: AcVSVHlcR81MUHPWTbqMJ5AxvOC22QAJjnfA From: "Brungard, Deborah A, ALABS" To: "Adrian Farrel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: RE: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Hi all, My comment below (db), ------------ > this said, why not combining item 8 and 9 in a single item and leave the > multiple-provider case for the next step I think I can agree to leaving multi-provider to the next step (although note that we have already received a question about how to provide this function). In which case, we are not combining items 8 and 9. We are deleting item 9. This is fine. > "8. Guidelines for applying the basic and extended modes for > single-provider networks." Also OK. ----------- db: As both the ITU L1VPN Recommendation and the framework draft already refer to the need for supporting iner-SP L1VPN, I'd prefer to keep some type of wording recognizing it as a next step vs. using restrictive wording on single-provider solutions. Omission may be incorrectly inferred as explicitly excluding (e.g. lack of intent/interest). For GMPLS, (mis)understandings on support of inter-SP, inter-domain (signaling/routing), different addressing schemes, etc has resulted in it being the most popular topic for inter-SDO supported communications (e.g. liaisons);-) Deborah From rtg-dir-bounces@ietf.org Mon May 9 02:28:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04836 for ; Mon, 9 May 2005 02:28:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV1zb-0001eT-3t for rtg-dir-archive@ietf.org; Mon, 09 May 2005 02:43:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV1kC-00010O-VP; Mon, 09 May 2005 02:27:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV1TK-00085g-8U; Mon, 09 May 2005 02:10:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22472; Mon, 9 May 2005 02:10:23 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV1iF-00011X-GS; Mon, 09 May 2005 02:25:57 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DV1T9-000JWX-SO; Mon, 09 May 2005 06:10:19 +0000 Date: Sun, 8 May 2005 23:10:13 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <831973828.20050508231013@psg.com> To: iesg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 09 May 2005 02:27:55 -0400 Subject: Off-line for V-day Anniversary X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Monday the 9th is the 60th anniversary of the European V-day of the WWII. In my culture, this day has always been associated with both celebration of the peace and remembrance of those who paid for our lives with theirs. This is one of those days when you think about the history, the lives we live, and try to put things in perspective... I took the 9th off, and don't expect to read much e-mail tomorrow. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Mon May 9 02:50:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06994 for ; Mon, 9 May 2005 02:50:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV2LA-0002Qx-GY for rtg-dir-archive@ietf.org; Mon, 09 May 2005 03:06:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV262-0004Jr-8k; Mon, 09 May 2005 02:50:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV260-0004JY-JJ; Mon, 09 May 2005 02:50:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06969; Mon, 9 May 2005 02:50:27 -0400 (EDT) Received: from [221.151.18.93] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DV2L0-0002Py-7s; Mon, 09 May 2005 03:06:02 -0400 Received: from chajaily.toadis.tortis ([132.238.212.82]) by gt0.optu.br (InterMail vG.6.77.72.70 205-2237-491-20040331) with ESMTP id <59691101151738.QLSU3323.gx0.fuse.net@optu.br> for ; Mon, 09 May 2005 13:50:06 +0600 Message-Id: Date: Mon, 09 May 2005 01:51:06 -0600 From: "Newsletter of Rolex Watches" To: rtg-dir@ietf.org, policy-admin@ietf.org, imrg-admin@ietf.org, p2prg-web-archive@ietf.org, mmusic-admin@ietf.org, disman-request@ietf.org X-Mailer: InterMail vG.3.11.08.35 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: New Shop for Cartie here only. schx X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.3 (+++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Treat yourself .. Own a Rolex ! http://smoothwatches.com/index.php?ref=news =============== nope http://www.h0us3.com/gone.asp From rtg-dir-bounces@ietf.org Mon May 9 07:00:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28063 for ; Mon, 9 May 2005 07:00:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV6FA-0002tu-1t for rtg-dir-archive@ietf.org; Mon, 09 May 2005 07:16:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV5zi-00012U-Nl; Mon, 09 May 2005 07:00:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV5zi-00012P-6q for rtg-dir@megatron.ietf.org; Mon, 09 May 2005 07:00:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28001 for ; Mon, 9 May 2005 07:00:11 -0400 (EDT) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV6Eo-0002tG-6O for rtg-dir@ietf.org; Mon, 09 May 2005 07:15:50 -0400 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-blue.research.att.com (Postfix) with ESMTP id 5901719749F for ; Mon, 9 May 2005 06:57:35 -0400 (EDT) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j49B03eA043994 for ; Mon, 9 May 2005 04:00:03 -0700 (PDT) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j49B02RT043993 for rtg-dir@ietf.org; Mon, 9 May 2005 04:00:03 -0700 (PDT) (envelope-from fenner) Date: Mon, 9 May 2005 04:00:03 -0700 (PDT) Message-Id: <200505091100.j49B02RT043993@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Subject: IESG agenda for 2005-05-12 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-05-12). Updated 2:26:23 EDT, May 9, 2005 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date MPLS/BGP Layer 3 Virtual Private Network SUB Management Information Base (Proposed Standard) - 1 of 7 draft-ietf-l3vpn-mpls-vpn-mib-07.txt [Open Web Ballot] Note: This doc is being advanced together with draft-ietf-l3vpn-tc-mib-06.txt Token: Mark Townsley Definition of Textual Conventions for Virtual SUB Private Network (VPN) Management (Proposed Standard) - 2 of 7 draft-ietf-l3vpn-tc-mib-06.txt [Open Web Ballot] Note: This doc is being advanced together with draft-ietf-l3vpn-mpls-vpn-mib. Token: Mark Townsley TSV RTP Payload Format for BroadVoice Speech Codecs (Proposed Standard) - 3 of 7 draft-ietf-avt-rtp-bv-04.txt [Open Web Ballot] Note: PROTO shepherd: magnus.westerlund@ericsson.com Token: Allison Mankin INT Information Refresh Time Option for DHCPv6 (Proposed Standard) - 4 of 7 draft-ietf-dhc-lifetime-03.txt [Open Web Ballot] Token: Margaret Wasserman Vendor-Specific Information Suboption for the INT DHCP Relay Agent Option (Proposed Standard) - 5 of 7 draft-ietf-dhc-vendor-suboption-00.txt [Open Web Ballot] Token: Margaret Wasserman INT Node-Specific Client Identifiers for DHCPv4 (Proposed Standard) - 6 of 7 draft-ietf-dhc-3315id-for-v4-04.txt [Open Web Ballot] Token: Margaret Wasserman INT IP Version 6 Addressing Architecture (Draft Standard) - 7 of 7 draft-ietf-ipv6-addr-arch-v4-03.txt [Open Web Ballot] Note: This version only removes features (site-local, anycast restrictions, NSAP addresses) and changes wording to address clarity concerns, so no new implementation report should be required. Token: Margaret Wasserman 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item Area Date SEC Datagram Transport Layer Security (Proposed Standard) - 1 of 3 draft-rescorla-dtls-04.txt [Open Web Ballot] Token: Russ Housley SEC The Camellia Cipher Algorithm and Its Use With IPsec (Proposed Standard) - 2 of 3 draft-kato-ipsec-ciph-camellia-01.txt [Open Web Ballot] Token: Russ Housley Using the Simple Object Access Protocol APP (SOAP) in Blocks Extensible Exchange Protocol (BEEP) (Proposed Standard) - 3 of 3 draft-mrose-rfc3288bis-01.txt [Open Web Ballot] Token: Scott Hollenbeck 2.2.2 Returning Item Area Date APP Attaching Meaning to Solicitation Class Keywords (Proposed Standard) - 1 of 1 draft-malamud-keyword-discovery-05.txt [Open Web Ballot] Note: Returning to clear the last discuss. Token: Scott Hollenbeck 2.2.3 For Action Area Date GEN Standardization of Multilingualizing Domain Names(MLDN) (Proposed Standard) - 1 of 1 draft-ekrema-smldn-00.txt Token: Brian Carpenter 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item Area Date TSV A Framework for Conferencing with the Session Initiation Protocol (Informational) - 1 of 2 draft-ietf-sipping-conferencing-framework-04.txt [Open Web Ballot] Note: PROTO shepherd: gonzalo.camarillo@ericsson.com Token: Allison Mankin TSV High Level Requirements for Tightly Coupled SIP Conferencing (Informational) - 2 of 2 draft-ietf-sipping-conferencing-requirements-01.txt [Open Web Ballot] Note: PROTO shepherd: gonzalo.camarillo@ericsson.com Token: Allison Mankin 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date Implementer-friendly Specification of Message APP and MIME-Part Header Fields and Field Components (Informational) - 1 of 1 draft-lilly-field-specification-03.txt [Open Web Ballot] Token: Scott Hollenbeck 3.2.2 Returning Item NONE 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item NONE 3.3.2 Returning Item NONE 3.3.3 For Action Area Date GEN How to Gain Prominence and Influence in Standards Organizations (Informational) - 1 of 1 draft-eastlake-prominence-02.txt [Open Web Ballot] Note: Author has been pointed at the RFC Editor's independent submission mechanism. Token: Brian Carpenter 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review Area Date INT Apr 28 Site Multihoming by IPv6 Intermediation (shim6) - 1 of 1 Token: Margaret 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. IAB News We can use 6. Management Issues 7. Agenda Working Group News From rtg-dir-bounces@ietf.org Mon May 9 09:11:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09938 for ; Mon, 9 May 2005 09:11:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV8I4-0007oJ-B9 for rtg-dir-archive@ietf.org; Mon, 09 May 2005 09:27:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV81z-00023O-Fr; Mon, 09 May 2005 09:10:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV81y-00022c-IP for rtg-dir@megatron.ietf.org; Mon, 09 May 2005 09:10:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09761 for ; Mon, 9 May 2005 09:10:41 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV8H4-0007lj-87 for rtg-dir@ietf.org; Mon, 09 May 2005 09:26:20 -0400 Received: from [211.32.127.128] (helo=211.32.127.128) by mx2.foretec.com with smtp (Exim 4.24) id 1DV81u-0006XE-9D for rtg-dir@ietf.org; Mon, 09 May 2005 09:10:39 -0400 Message-ID: From: "Kendra L. Brown" <4ferdinand@about.com> To: rtg-dir@ietf.org Date: Mon, 09 May 2005 12:05:22 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_07D8169B.7770DB9F" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.7 (++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: Office software - wholesale price X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is a multi-part message in MIME format. ------=_NextPart_000_0000_07D8169B.7770DB9F Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_587CA0B1.A8EFDEF7" ------=_NextPart_001_0001_587CA0B1.A8EFDEF7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get access to all the popular software imaginable for less! Our software is 2-10 times cheaper than sold by our competitors. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 Quark Xpress 6 Passport Multilanguage Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... To visit us go: http://www.soft-top100.com Best, Kendra L. Brown _____________________________________________________ To change your mail details, go here: http://www.soft-top100.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_587CA0B1.A8EFDEF7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
    Get access to all the popular software imaginable for less!
    Our software is 2-10 times cheaper than sold by our competitors.

    Examples:
    $79.95 Windows XP Professional (Including: Service Pack 2)
    $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
    $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
    $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
    $79.95 Adobe Acrobat 6.0 Professional
    $69.95 Quark Xpress 6 Passport Multilanguage

    Special Offers:
    $89.95 Windows XP Professional + Office XP Professional
    $149.95 Adobe Creative Suite Premium (5 CD)
    $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

    All main products from Microsoft, Adobe, Macromedia, Corel, etc.
    And many more... To visit us go:

    http://www.soft-top100.com

    Best,
    Kendra L. Brown


    _____________________________________________________
    To change your mail details, go here: http://www.soft-top100.com/uns.htm
    _____________________________________________________

    ------=_NextPart_001_0001_587CA0B1.A8EFDEF7-- ------=_NextPart_000_0000_07D8169B.7770DB9F-- From rtg-dir-bounces@ietf.org Wed May 11 11:54:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18126 for ; Wed, 11 May 2005 11:54:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVtnM-0006eN-9r for rtg-dir-archive@ietf.org; Wed, 11 May 2005 12:10:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVtVO-0006gL-7o; Wed, 11 May 2005 11:52:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVtVN-0006ft-E4; Wed, 11 May 2005 11:52:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17853; Wed, 11 May 2005 11:52:08 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVtks-0006SS-Ee; Wed, 11 May 2005 12:08:15 -0400 Received: from plb95-2-82-236-77-247.fbx.proxad.net ([82.236.77.247]) by mx2.foretec.com with smtp (Exim 4.24) id 1DVsZC-00016f-QV; Wed, 11 May 2005 10:52:08 -0400 Received: from amethyst.conner-brae.com (HELO appointee.com 66.8.124.37) by hey.com with EMQP; Wed, 11 May 2005 15:42:16 -0100 Date: Wed, 11 May 2005 13:40:16 -0300 From: "Latoya Keenan" Message-Id: To: rsvp-archive@ietf.org X-Mailer: CompuServe 7.0 X-Spam-Score: 2.5 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rtg-dir@ietf.org, rtgwg-admin@ietf.org, rtgwg-web-archive@ietf.org, rtg-bfd@ietf.org, rv@ietf.org, rtg-bfd-admin@ietf.org, rtgwg@ietf.org Subject: High rates? Not with us! low fixed rate X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.5 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.trust1ng.net/sign.asp Best Regards, Tyson Stahl to be remov(ed: http://www.trust1ng.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Wed May 11 14:23:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00325 for ; Wed, 11 May 2005 14:23:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVw76-0006El-7M for rtg-dir-archive@ietf.org; Wed, 11 May 2005 14:39:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVvr8-0006ky-R7; Wed, 11 May 2005 14:22:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVvr8-0006km-71; Wed, 11 May 2005 14:22:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00268; Wed, 11 May 2005 14:22:48 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVw6g-0006EE-GP; Wed, 11 May 2005 14:38:55 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVvr4-0000dV-Bf; Wed, 11 May 2005 18:22:46 +0000 Date: Wed, 11 May 2005 11:22:44 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <134740927.20050511112244@psg.com> To: rtg-dir@ietf.org, l1vpn@ietf.org In-Reply-To: <449B2580D802A443A923DABF3EAB82AF099CFA93@OCCLUST04EVS1.ugd.att.com> References: <449B2580D802A443A923DABF3EAB82AF099CFA93@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit To summarize the major discussion points here, I think we have a consensus to do the following: 1. Keep the charter L1VPN-specific, yet be good engineers and keep the mechanisms extensible and as generic as practical. 2. Keep the inter-provider case out of scope for now, but mention it as a possible next step. 3. Keep requirements in the framework document, unless/until we see a clear need to split them out to a separate draft. Several people said that security should be mentioned explicitly in the charter. I don't think we need to--security is the default item for all WGs and doesn't need to be spelled out, we simply keep this in mind and do the right thing. Unless, of course, someone had something very specific in mind. I will also follow up on the editorial comments and will send the revised charter to the list. Thanks Alex From rtg-dir-bounces@ietf.org Wed May 11 17:21:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27367 for ; Wed, 11 May 2005 17:21:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVytY-0001SL-Ot for rtg-dir-archive@ietf.org; Wed, 11 May 2005 17:37:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVycY-0004u3-Mi; Wed, 11 May 2005 17:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVycX-0004tp-1u for rtg-dir@megatron.ietf.org; Wed, 11 May 2005 17:19:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27245 for ; Wed, 11 May 2005 17:19:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVys4-0001JF-Ea for rtg-dir@ietf.org; Wed, 11 May 2005 17:36:01 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVycN-000EJM-Ce; Wed, 11 May 2005 21:19:47 +0000 Date: Wed, 11 May 2005 14:19:45 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <113564626.20050511141945@psg.com> To: Loa Andersson In-Reply-To: <427B400D.8080705@pi.se> References: <427B400D.8080705@pi.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Content-Transfer-Encoding: 7bit Cc: Dimitri.Papadimitriou@alcatel.be, rtg-dir@ietf.org, Kireeti Kompella , Igor Bryskin , Adrian Farrel , takeda.tomonori@lab.ntt.co.jp Subject: Interface with ITU [was: Re: Draft L1VPN Charter] X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Content-Transfer-Encoding: 7bit Loa, Having a structured and coordinated relationship with ITU-T is all good and dandy, but I don't think it means specific WGs should not be working directly with SGs on their specific topics. I would be worried about attempting to centralize this function too much. It works and scales much better when distributed. That said, it is clearly the right idea to have WG chairs talk to each other and be aware of what others are doing... Does it sound like a mailing list? -- Alex http://www.psg.com/~zinin Friday, May 6, 2005, 2:59:41 AM, Loa Andersson wrote: > Dimitri, > I don't know exactly which hat I've on here. What I said is > that I see some need to further coordinate the IETF relationship > with ITU-T, and that it is not a good idea to establish yet another > realtionship before doing so. > I don't know what such a channel will look like - or even if it is > "single" - but I claim that it is something we need to discuss. > /Loa > Dimitri.Papadimitriou@alcatel.be wrote: >> Loa, >> >> good to see there is a clear intention to structure our relationship and >> message towards ITU-T wrt to our GMPLS work and views >> >> if i correctly interpreet you statement "Use the established IETF channels >> to coordinate with ITU-T as necessary." it means there will be a single >> channel (contrary to the multiple per WG channel that exists today) and you >> suggest making use of it to communicate with ITU-T SG13 on L1VPN >> >> as long as this allows interacting with them where necessary i do not think >> this would problematic - do you know when such person is going to be >> appointed ? >> >> thanks, >> - dimitri. >> >> --- >> >> Igor and Dimitri, >> >> I'm not that happy about this - did see it go into the version >> that was sent to l1vpn-list, and think it should not be there. >> At least not until we have a clear understanding of what the >> scope of this working groups coordination with ITY-T needs to >> be. >> >> The issues we see to today is that we have several contacts points >> with ITU-T and the messages we send over these contact points are >> sometimes conflicting and they are using it to say that we don't >> have control of what we are doing. >> >> I think that with regards to the ITU-T relationship it would be >> much better to appoint one person (a liaison) or a working group >> or a set of working groups responsible for coordinating the >> (g)mpls part of the ITU-T relationship from the IETF. And then >> write something like: >> >> "Use the established IETF channels to coordinate with ITU-T as >> necessary." >> >> Actually this could go into the charter of all working groups that >> needs to part of this coordination. >> >> /Loa >> >> Igor Bryskin wrote: >> >> >>>Good idea. >>>Igor >>> >>>*/Dimitri.Papadimitriou@alcatel.be/* wrote: >>> >>> igor, all - now that i am thinking of it there is probably a need to >>> add a sentence like "The WG will also liaise with related ITU-T SGs" >>> after "... and other WGs where necessary." >>> >>> *Igor Bryskin * >>> Sent by: rtg-dir-bounces@ietf.org >>> 05/04/2005 07:18 MST >>> >>> To: Alex Zinin , Adrian Farrel , >>> Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, rtg-dir@ietf.org, Kireeti >>> Kompella , takeda.tomonori@lab.ntt.co.jp >>> cc: >>> bcc: >>> Subject: Re: Draft L1VPN Charter >>> >>> >>> Alex, All >>> >>> >>> >>> 2. Enhanced mode: the CE-PE interface provides the signaling >>> capabilities >>> as in the Basic mode, plus permits utilization of the provider's >> >> control >> >>> plane for distribution of user's routing information (e.g. similar >>> to the >>> MPLS/BGP model). >>> >>> I'd like to replace this with: >>> >>> >>> >>> 2. Enhanced mode: the CE-PE interface provides the signaling >>> capabilities >>> as in the Basic mode, plus permits utilization of the provider's >> >> control >> >>> plane for distribution of user's arbitrary control plane information >>> between the VPN sites including but not limited to routing >> >> information. >> >>> >>> >>> Provider network IHMO should make no assumptions on what protocols >>> are running within VPNs. Generally speaking, a L1VPN user is not >>> necessarily GMPLS controlled network. Furthermore, even in case it >>> does use GMPLS it needs L1VPN CE-CE connections to provide (TE) >>> links within VPNs. Specifically, the User should be capable to run >>> LMP for such links, it also should be possible to establish >>> signaling (RSVP) adjacencies between their ends, etc. The bottom >>> line is that distribution of routing information between CEs IHMO is >>> not sufficient. I believe this is consistent with the requirements >>> stated in ITU-T SG13 L1VPN documents >>> >>> >>> >>> Igor >>> >>> >>> >>> >>> >>> */Alex Zinin /* wrote: >>> >>> Folks- >>> >>> Before we bring it to the l1vpn mailing list, I'd like to run this >> >> draft >> >>> by you guys for comments. >>> >>> -- >>> Alex >>> >>> >>> Layer 1 Virtual Private Networks (l1vpn) >>> >>> Last Modified: 2005-01-25 >>> Chair(s): >>> TBD >>> TBD >>> Routing Area Director(s): >>> Bill Fenner >>> Alex Zinin >>> >>> Routing Area Advisor: >>> Alex Zinin >>> >>> Technical Advisor(s): >>> >>> Mailing Lists: >>> General Discussion: l1vpn@ietf.org >>> To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn >>> Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html >>> >>> Description of Working Group: >>> >>> L1VPN Working Group's task is to specify mechanisms necessary for >>> providing a VPN service over a GMPLS transport network. >>> >>> The following two service models will be addressed: >>> >>> 1. Basic mode: the CE-PE interface's functional repertoire is limited >> >> to >> >>> path setup signalling only. The GMPLS network is not involved in >>> distribution of user's routing information. >>> >>> 2. Enhanced mode: the CE-PE interface provides the signaling >>> capabilities >>> as in the Basic mode, plus permits utilization of the provider's >> >> control >> >>> plane for distribution of user's routing information (e.g. similar >>> to the >>> MPLS/BGP model). >>> >>> The WG will work on the following items: >>> >>> 1. Specification of the L1VPN user-to-network interface (UNI) basic >>> mode, >>> including both CE and PE functionality. >>> >>> 2. Specification of the L1VPN node-to-node interface (NNI) basic >> >> mode. >> >>> ! >>> 3. MIB modules and/or extensions required for UNI and NNI basic mode. >>> >>> 4. Specification of L1VPN UNI enhanced mode. >>> >>> 5. Specification of L1VPN NNI enhanced mode. >>> >>> 6. MIB modules and/or extensions required for UNI and NNI enhanced >> >> mode. >> >>> Protocol extensions required for L1VPN will be done in cooperation >> >> with >> >>> CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. >>> >>> Milestones: >>> >>> Sep 05 Submit first Internet Drafts of UNI and NNI basic mode >>> specifications >>> Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI >> >> basic >> >>> mode >>> Jun 06 Submit UNI and NNI basic mode specifications to IESG for >>> publication as Proposed Standard >>> Jun 06 Submit first Internet Draf! ts of UNI and NNI enhanced mode >>> specifications >>> Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for >>> publication as Proposed Standard >>> Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for >>> publication as Proposed Standard >>> Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for >>> publication as Proposed Standard >>> >>> >>> >>> >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> >>>------------------------------------------------------------------------ >>>Discover Yahoo! >>>Find restaurants, movies, travel & more fun for the weekend. Check it >>>out! >>> >> >> >> >> >> -- >> Loa Andersson >> >> Principal Networking Architect >> Acreo AB phone: +46 8 632 77 14 >> Isafjordsgatan 22 mobile: +46 739 81 21 64 >> Kista, Sweden email: loa.andersson@acreo.se >> loa@pi.se >> >> >> >> From rtg-dir-bounces@ietf.org Wed May 11 17:28:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27990 for ; Wed, 11 May 2005 17:28:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVz0t-0001pN-Hl for rtg-dir-archive@ietf.org; Wed, 11 May 2005 17:45:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyjL-0007r0-ES; Wed, 11 May 2005 17:26:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyjK-0007qL-79; Wed, 11 May 2005 17:26:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27913; Wed, 11 May 2005 17:26:55 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVyyu-0001h1-Tq; Wed, 11 May 2005 17:43:05 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVyjI-000Eld-5t; Wed, 11 May 2005 21:26:56 +0000 Date: Wed, 11 May 2005 14:26:54 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <534433625.20050511142654@psg.com> To: rtg-dir@ietf.org, l1vpn@ietf.org In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D04622980@zcarhxm0.corp.nortel.com> References: <085091CB2CA14E4B8B163FFC37C84E9D04622980@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Subject: Re: [L1vpn] Proposed charter for L1VPN WG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Comments to Hamid, and Loa: Hamid: > I suggest we replace the terms "GMPLS network" with > "provider GMPLS enabled network...". Did some changes > In the basic mode since the path signaling is done for the > purpose of L1VPN then I think it is important to indicate that > signaling is accomplished within a given CE-CE connectivity topology. This would clearly simplify the mechanisms, security especially. Let's leave this sort of details to the WG though. >> > Is this referring to auto-discovery of L1VPN endpoints/nodes >> > or to routing peering between CE and PE and have PE distribute >> > CE relate routing? It looks like the text is about the latter >> > not the former. >> >> More the latter. I didn't think we should spell the former out. >> > I prefer we spell discovery out clearly to avoid some confusion later on. > Using your proposal in your reply to Adrian below: > " 2. Enhanced mode: the CE-PE interface provides the signaling capabilities > as in the Basic mode, plus permits limited exchange of information > between the control planes of the provider and the user to help such > functions as discovery of reachability information in remote sites, > or parameters of the part of the provider's network dedicated to > the user." > I think the routing is a bit tricky here. The enhanced mode > (which in fact can map to one or two L1VPN service models") may imply > only that the exchange of routing is done only between > the user control plane and "a control plane" running on the PE. That > control plane running on the PE may have no relation to the provider > actual control plane. > How about rewriting the above paragraph to be: Again, we're not doing the design here, so let's not split the hair. If the above text is "good enough", we should stop editing it. There will never be a wording perfectly satisfying everybody. Loa: > Question: would be correct to say that the intention is to > describe an "overlay model" in the in the basic mode and an > "peer model" in the enhanced. If so it should be made clear > that when we talk about "user's routing information" it is the > routing information for the "layer" native to the GMPLS VPN. My understanding is that at this point, the enhanced mode includes two possibilities: overlay with user route distribution assist, and peer-to-peer. >>> Protocol extensions required for L1VPN will be done in >>>cooperation with CCAMP, OSPF, IS-IS, IDR, and other WGs >>>where necessary. Where necessary, the WG will also cooperate >>>with ITU-T. > I guess that the thought here is that ccamp acts on behalf of > the mpls wg, but would be happier if the mpls wg were mentioned > ecxplicitly, also since we mention the BGP/MPLS VPNs some > coordintion with L3VPN might turn out necessary. Of course, this list shouldn't limit the actual WGs that this one would work with, but I have no problem with expanding it. > I also think that the paragraph is to weak, it should say. > "Protocol extensions required for L1VPN need to be done with > by the working roup that owns the base protocol, e.g. CCAMP, > MPLS, OSPF, IS-IS, IDR, and other WGs where necessary. Where > necessary, the WG will also cooperate with ITU-T." "In cooperation with" was an abbreviation of the process that we (you, I, et al) are using now and that's a bit more complicated then just doing the extensions in the protocol WGs: - L1VPN reviews the proposed extension from the L1VPN perspective If positive, refer it to the protocol WG. - The protocol WG reviews the extension. If positive, it adopts the extension as a WG item, or says "nah, it's OK, guys, it's simple, you can do it, make sure you check with us when ready", and L1VPN takes it then. // do we need a bcp on this? -- Alex From rtg-dir-bounces@ietf.org Wed May 11 17:31:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28178 for ; Wed, 11 May 2005 17:31:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVz3R-0001z6-2w for rtg-dir-archive@ietf.org; Wed, 11 May 2005 17:47:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVyly-0008D8-Q1; Wed, 11 May 2005 17:29:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVylx-0008C9-Iz; Wed, 11 May 2005 17:29:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28073; Wed, 11 May 2005 17:29:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVz1Y-0001qG-EP; Wed, 11 May 2005 17:45:48 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DVylv-000EuU-Im; Wed, 11 May 2005 21:29:39 +0000 Date: Wed, 11 May 2005 14:29:38 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <417849708.20050511142938@psg.com> To: rtg-dir@ietf.org, l1vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Subject: Proposed charter for L1VPN WG -- rev 01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Folks- Please check below with the question in mind "whether it's good enough?". -- Alex http://www.psg.com/~zinin Layer 1 Virtual Private Networks (l1vpn) Last Modified: 2005-05-11 Chair(s): TBD TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Technical Advisor(s): TBD Mailing Lists: General Discussion: l1vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html Description of Working Group: The L1VPN Working Group's task is to specify mechanisms necessary for providing a VPN service over a GMPLS-enabled transport service-provider network. The following two service models will be addressed: 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. Provider's network is not involved in distribution of user's routing information. 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits limited exchange of information between the control planes of the provider and the user to help such functions as discovery of reachability information in remote sites, or parameters of the part of the provider's network dedicated to the user. The WG will work on the following items: 1. Framework document defining the reference network model, L1VPN service model, fundamental assumptions, and terminology. 2. Specification of the L1VPN signaling functionality between the user network and the provider network to support the basic mode. 3. Specification of the L1VPN signaling and routing functionality within the provider network to support the basic mode. 4. OAM features and MIB modules and/or extensions required for the basic mode. 5. Specification of the L1VPN signaling and routing functionality between the user network and the provider network to support the extended mode. 6. Specification of the L1VPN signaling and routing functionality within the provider network to support the extended mode. 7. OAM features and MIB modules and/or extensions required for the extended mode. 8. Applicability guidelines to compare the basic and extended modes. Protocol extensions required for L1VPN will be done in cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. Where necessary, the WG will also cooperate with ITU-T. Milestones: Sep 05 Submit first Internet Draft of L1VPN framework Sep 05 Submit first Internet Drafts of UNI and NNI basic mode specifications Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic mode Apr 06 Submit UNI and NNI basic mode specifications to IESG for publication as Proposed Standard Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode specifications Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for publication as Proposed Standard Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for publication as Proposed Standard Dec 06 Submit L1VPN framework to IESG for publication as Informational RFC Aug 07 Submit MIB modules for UNI and NNI enhanced mode to IESG for publication as Proposed Standard From rtg-dir-bounces@ietf.org Wed May 11 19:39:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10041 for ; Wed, 11 May 2005 19:39:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW13V-0001Px-NA for rtg-dir-archive@ietf.org; Wed, 11 May 2005 19:55:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0jF-0008QG-L3; Wed, 11 May 2005 19:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW0jE-0008Q2-Rp; Wed, 11 May 2005 19:35:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09764; Wed, 11 May 2005 19:34:56 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW0yq-00017I-EW; Wed, 11 May 2005 19:51:08 -0400 Received: from du-069-0193.access.clara.net ([217.158.132.193] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DW0jA-000FcI-Gr; Thu, 12 May 2005 00:34:57 +0100 Message-ID: <001501c55682$53dd0ca0$c1849ed9@Puppy> From: "Adrian Farrel" To: "Alex Zinin" , , References: <417849708.20050511142938@psg.com> Date: Thu, 12 May 2005 00:36:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 2.9 (++) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Subject: Re: [L1vpn] Proposed charter for L1VPN WG -- rev 01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Hi, That passes the "good enough" test for me. Should we add a final milestone "Recharter or close WG"? But perhaps we take that as read. Thanks for your work on this. Adrian ----- Original Message ----- From: "Alex Zinin" To: ; Sent: Wednesday, May 11, 2005 10:29 PM Subject: [L1vpn] Proposed charter for L1VPN WG -- rev 01 > Folks- > > Please check below with the question in mind "whether it's good enough?". > > -- > Alex > http://www.psg.com/~zinin > > > Layer 1 Virtual Private Networks (l1vpn) > > Last Modified: 2005-05-11 > Chair(s): > TBD > TBD > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Technical Advisor(s): > TBD > > Mailing Lists: > General Discussion: l1vpn@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn > Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html > > Description of Working Group: > > The L1VPN Working Group's task is to specify mechanisms necessary for > providing a VPN service over a GMPLS-enabled transport service-provider > network. > > The following two service models will be addressed: > > 1. Basic mode: the CE-PE interface's functional repertoire is limited to > path setup signalling only. Provider's network is not involved in > distribution of user's routing information. > > 2. Enhanced mode: the CE-PE interface provides the signaling capabilities > as in the Basic mode, plus permits limited exchange of information > between the control planes of the provider and the user to help such > functions as discovery of reachability information in remote sites, > or parameters of the part of the provider's network dedicated to > the user. > > The WG will work on the following items: > > 1. Framework document defining the reference network model, L1VPN service > model, fundamental assumptions, and terminology. > > 2. Specification of the L1VPN signaling functionality between the user > network and the provider network to support the basic mode. > > 3. Specification of the L1VPN signaling and routing functionality within > the provider network to support the basic mode. > > 4. OAM features and MIB modules and/or extensions required for the basic > mode. > > 5. Specification of the L1VPN signaling and routing functionality between > the user network and the provider network to support the extended mode. > > 6. Specification of the L1VPN signaling and routing functionality within > the provider network to support the extended mode. > > 7. OAM features and MIB modules and/or extensions required for the > extended mode. > > 8. Applicability guidelines to compare the basic and extended modes. > > Protocol extensions required for L1VPN will be done in cooperation with > MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. Where > necessary, the WG will also cooperate with ITU-T. > > Milestones: > > Sep 05 Submit first Internet Draft of L1VPN framework > > Sep 05 Submit first Internet Drafts of UNI and NNI basic mode specifications > > Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic mode > > Apr 06 Submit UNI and NNI basic mode specifications to IESG for publication as Proposed Standard > > Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode specifications > > Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for publication as Proposed Standard > > Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for publication as Proposed Standard > > Dec 06 Submit L1VPN framework to IESG for publication as Informational RFC > > Aug 07 Submit MIB modules for UNI and NNI enhanced mode to IESG for publication as Proposed Standard > > > > _______________________________________________ > L1vpn mailing list > L1vpn@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/l1vpn > > From rtg-dir-bounces@ietf.org Wed May 11 20:11:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11864 for ; Wed, 11 May 2005 20:11:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW1Xp-00030Q-KZ for rtg-dir-archive@ietf.org; Wed, 11 May 2005 20:27:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Hd-0000LD-8T; Wed, 11 May 2005 20:10:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW1Hb-0000JR-LB; Wed, 11 May 2005 20:10:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11840; Wed, 11 May 2005 20:10:29 -0400 (EDT) Received: from cronos.ocn.ne.jp ([222.146.51.136] helo=smtp.cronos.ocn.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW1XC-0002zn-Im; Wed, 11 May 2005 20:26:40 -0400 Received: from TAKEDAPANA.lab.ntt.co.jp (FLA1Adf250.tky.mesh.ad.jp [133.205.125.250]) by smtp.cronos.ocn.ne.jp (Postfix) with ESMTP id 8B1FF2C2B; Thu, 12 May 2005 09:10:25 +0900 (JST) Message-Id: <5.1.1.11.2.20050512090355.05810140@cronos.ocn.ne.jp> X-Sender: takeda.tomonori@cronos.ocn.ne.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1J Jr5-rev2 Date: Thu, 12 May 2005 09:10:22 +0900 To: Alex Zinin , rtg-dir@ietf.org, l1vpn@ietf.org From: Tomonori TAKEDA In-Reply-To: <417849708.20050511142938@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Subject: Re: [L1vpn] Proposed charter for L1VPN WG -- rev 01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Hi Looks good to me. One minor point. Would it be reasonable to suggest deleting a number of "UNI and NNI" in Milestones, since we are not using these terms anywhere else? Best regards, Tomonori At 14:29 05/05/11 -0700, Alex Zinin wrote: >Folks- > > Please check below with the question in mind "whether it's good enough?". > >-- >Alex >http://www.psg.com/~zinin > > >Layer 1 Virtual Private Networks (l1vpn) > >Last Modified: 2005-05-11 >Chair(s): > TBD > TBD > >Routing Area Director(s): > Bill Fenner > Alex Zinin > >Routing Area Advisor: > Alex Zinin > >Technical Advisor(s): > TBD > >Mailing Lists: > General Discussion: l1vpn@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn > Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html > >Description of Working Group: > > The L1VPN Working Group's task is to specify mechanisms necessary for > providing a VPN service over a GMPLS-enabled transport service-provider > network. > > The following two service models will be addressed: > > 1. Basic mode: the CE-PE interface's functional repertoire is limited to > path setup signalling only. Provider's network is not involved in > distribution of user's routing information. > > 2. Enhanced mode: the CE-PE interface provides the signaling capabilities > as in the Basic mode, plus permits limited exchange of information > between the control planes of the provider and the user to help such > functions as discovery of reachability information in remote sites, > or parameters of the part of the provider's network dedicated to > the user. > > The WG will work on the following items: > > 1. Framework document defining the reference network model, L1VPN service > model, fundamental assumptions, and terminology. > > 2. Specification of the L1VPN signaling functionality between the user > network and the provider network to support the basic mode. > > 3. Specification of the L1VPN signaling and routing functionality within > the provider network to support the basic mode. > > 4. OAM features and MIB modules and/or extensions required for the basic > mode. > > 5. Specification of the L1VPN signaling and routing functionality between > the user network and the provider network to support the extended mode. > > 6. Specification of the L1VPN signaling and routing functionality within > the provider network to support the extended mode. > > 7. OAM features and MIB modules and/or extensions required for the > extended mode. > > 8. Applicability guidelines to compare the basic and extended modes. > > Protocol extensions required for L1VPN will be done in cooperation with > MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. Where > necessary, the WG will also cooperate with ITU-T. > >Milestones: > > Sep 05 Submit first Internet Draft of L1VPN framework > > Sep 05 Submit first Internet Drafts of UNI and NNI basic mode specifications > > Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic mode > > Apr 06 Submit UNI and NNI basic mode specifications to IESG for >publication as Proposed Standard > > Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode specifications > > Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for >publication as Proposed Standard > > Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for >publication as Proposed Standard > > Dec 06 Submit L1VPN framework to IESG for publication as Informational RFC > > Aug 07 Submit MIB modules for UNI and NNI enhanced mode to IESG for >publication as Proposed Standard > > > >_______________________________________________ >L1vpn mailing list >L1vpn@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/l1vpn From rtg-dir-bounces@ietf.org Thu May 12 00:13:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28524 for ; Thu, 12 May 2005 00:13:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW5KX-0007UI-VD for rtg-dir-archive@ietf.org; Thu, 12 May 2005 00:29:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW53Y-0003c1-UN; Thu, 12 May 2005 00:12:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW53W-0003bh-QY; Thu, 12 May 2005 00:12:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28450; Thu, 12 May 2005 00:12:11 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW5JA-0007RJ-P0; Thu, 12 May 2005 00:28:25 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DW53S-000HWw-Fh; Thu, 12 May 2005 04:12:10 +0000 Date: Wed, 11 May 2005 21:12:08 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <656216263.20050511211208@psg.com> To: "Adrian Farrel" In-Reply-To: <001501c55682$53dd0ca0$c1849ed9@Puppy> References: <417849708.20050511142938@psg.com> <001501c55682$53dd0ca0$c1849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG -- rev 01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit Thanks! I'll add the inter-provider case as a future item too :) -- Alex http://www.psg.com/~zinin Wednesday, May 11, 2005, 4:36:31 PM, Adrian Farrel wrote: > Hi, > That passes the "good enough" test for me. > Should we add a final milestone "Recharter or close WG"? But perhaps we > take that as read. > Thanks for your work on this. > Adrian > ----- Original Message ----- > From: "Alex Zinin" > To: ; > Sent: Wednesday, May 11, 2005 10:29 PM > Subject: [L1vpn] Proposed charter for L1VPN WG -- rev 01 >> Folks- >> >> Please check below with the question in mind "whether it's good > enough?". >> >> -- >> Alex >> http://www.psg.com/~zinin >> >> >> Layer 1 Virtual Private Networks (l1vpn) >> >> Last Modified: 2005-05-11 >> Chair(s): >> TBD >> TBD >> >> Routing Area Director(s): >> Bill Fenner >> Alex Zinin >> >> Routing Area Advisor: >> Alex Zinin >> >> Technical Advisor(s): >> TBD >> >> Mailing Lists: >> General Discussion: l1vpn@ietf.org >> To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn >> Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html >> >> Description of Working Group: >> >> The L1VPN Working Group's task is to specify mechanisms necessary for >> providing a VPN service over a GMPLS-enabled transport service-provider >> network. >> >> The following two service models will be addressed: >> >> 1. Basic mode: the CE-PE interface's functional repertoire is limited > to >> path setup signalling only. Provider's network is not involved in >> distribution of user's routing information. >> >> 2. Enhanced mode: the CE-PE interface provides the signaling > capabilities >> as in the Basic mode, plus permits limited exchange of information >> between the control planes of the provider and the user to help > such >> functions as discovery of reachability information in remote sites, >> or parameters of the part of the provider's network dedicated to >> the user. >> >> The WG will work on the following items: >> >> 1. Framework document defining the reference network model, L1VPN > service >> model, fundamental assumptions, and terminology. >> >> 2. Specification of the L1VPN signaling functionality between the user >> network and the provider network to support the basic mode. >> >> 3. Specification of the L1VPN signaling and routing functionality > within >> the provider network to support the basic mode. >> >> 4. OAM features and MIB modules and/or extensions required for the > basic >> mode. >> >> 5. Specification of the L1VPN signaling and routing functionality > between >> the user network and the provider network to support the extended > mode. >> >> 6. Specification of the L1VPN signaling and routing functionality > within >> the provider network to support the extended mode. >> >> 7. OAM features and MIB modules and/or extensions required for the >> extended mode. >> >> 8. Applicability guidelines to compare the basic and extended modes. >> >> Protocol extensions required for L1VPN will be done in cooperation with >> MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. > Where >> necessary, the WG will also cooperate with ITU-T. >> >> Milestones: >> >> Sep 05 Submit first Internet Draft of L1VPN framework >> >> Sep 05 Submit first Internet Drafts of UNI and NNI basic mode > specifications >> >> Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI > basic mode >> >> Apr 06 Submit UNI and NNI basic mode specifications to IESG for > publication as Proposed Standard >> >> Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode > specifications >> >> Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for > publication as Proposed Standard >> >> Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for > publication as Proposed Standard >> >> Dec 06 Submit L1VPN framework to IESG for publication as Informational > RFC >> >> Aug 07 Submit MIB modules for UNI and NNI enhanced mode to IESG for > publication as Proposed Standard >> >> >> >> _______________________________________________ >> L1vpn mailing list >> L1vpn@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/l1vpn >> >> From rtg-dir-bounces@ietf.org Thu May 12 00:16:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28688 for ; Thu, 12 May 2005 00:16:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW5Nm-0007eB-2h for rtg-dir-archive@ietf.org; Thu, 12 May 2005 00:33:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW53f-0003ce-Tx; Thu, 12 May 2005 00:12:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW53e-0003cV-Ed; Thu, 12 May 2005 00:12:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28466; Thu, 12 May 2005 00:12:19 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW5JI-0007TH-Ut; Thu, 12 May 2005 00:28:33 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DW53c-000HXY-Ue; Thu, 12 May 2005 04:12:21 +0000 Date: Wed, 11 May 2005 21:12:19 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <455940908.20050511211219@psg.com> To: Tomonori TAKEDA In-Reply-To: <5.1.1.11.2.20050512090355.05810140@cronos.ocn.ne.jp> References: <417849708.20050511142938@psg.com> <5.1.1.11.2.20050512090355.05810140@cronos.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: [L1vpn] Proposed charter for L1VPN WG -- rev 01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Tomonori, Good point! Will do. -- Alex http://www.psg.com/~zinin Wednesday, May 11, 2005, 5:10:22 PM, Tomonori TAKEDA wrote: > Hi > Looks good to me. > One minor point. Would it be reasonable to suggest deleting a number of > "UNI and NNI" in Milestones, since we are not using these terms anywhere else? > Best regards, > Tomonori > At 14:29 05/05/11 -0700, Alex Zinin wrote: >>Folks- >> >> Please check below with the question in mind "whether it's good enough?". >> >>-- >>Alex >>http://www.psg.com/~zinin >> >> >>Layer 1 Virtual Private Networks (l1vpn) >> >>Last Modified: 2005-05-11 >>Chair(s): >> TBD >> TBD >> >>Routing Area Director(s): >> Bill Fenner >> Alex Zinin >> >>Routing Area Advisor: >> Alex Zinin >> >>Technical Advisor(s): >> TBD >> >>Mailing Lists: >> General Discussion: l1vpn@ietf.org >> To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn >> Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html >> >>Description of Working Group: >> >> The L1VPN Working Group's task is to specify mechanisms necessary for >> providing a VPN service over a GMPLS-enabled transport service-provider >> network. >> >> The following two service models will be addressed: >> >> 1. Basic mode: the CE-PE interface's functional repertoire is limited to >> path setup signalling only. Provider's network is not involved in >> distribution of user's routing information. >> >> 2. Enhanced mode: the CE-PE interface provides the signaling capabilities >> as in the Basic mode, plus permits limited exchange of information >> between the control planes of the provider and the user to help such >> functions as discovery of reachability information in remote sites, >> or parameters of the part of the provider's network dedicated to >> the user. >> >> The WG will work on the following items: >> >> 1. Framework document defining the reference network model, L1VPN service >> model, fundamental assumptions, and terminology. >> >> 2. Specification of the L1VPN signaling functionality between the user >> network and the provider network to support the basic mode. >> >> 3. Specification of the L1VPN signaling and routing functionality within >> the provider network to support the basic mode. >> >> 4. OAM features and MIB modules and/or extensions required for the basic >> mode. >> >> 5. Specification of the L1VPN signaling and routing functionality between >> the user network and the provider network to support the extended mode. >> >> 6. Specification of the L1VPN signaling and routing functionality within >> the provider network to support the extended mode. >> >> 7. OAM features and MIB modules and/or extensions required for the >> extended mode. >> >> 8. Applicability guidelines to compare the basic and extended modes. >> >> Protocol extensions required for L1VPN will be done in cooperation with >> MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. Where >> necessary, the WG will also cooperate with ITU-T. >> >>Milestones: >> >> Sep 05 Submit first Internet Draft of L1VPN framework >> >> Sep 05 Submit first Internet Drafts of UNI and NNI basic mode specifications >> >> Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic mode >> >> Apr 06 Submit UNI and NNI basic mode specifications to IESG for >>publication as Proposed Standard >> >> Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode > specifications >> >> Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for >>publication as Proposed Standard >> >> Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for >>publication as Proposed Standard >> >> Dec 06 Submit L1VPN framework to IESG for publication as Informational RFC >> >> Aug 07 Submit MIB modules for UNI and NNI enhanced mode to IESG for >>publication as Proposed Standard >> >> >> >>_______________________________________________ >>L1vpn mailing list >>L1vpn@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/l1vpn From rtg-dir-bounces@ietf.org Thu May 12 00:25:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29228 for ; Thu, 12 May 2005 00:25:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW5W3-00085O-6J for rtg-dir-archive@ietf.org; Thu, 12 May 2005 00:41:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW5Ah-0004e3-UA; Thu, 12 May 2005 00:19:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW5Af-0004dq-LH; Thu, 12 May 2005 00:19:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28791; Thu, 12 May 2005 00:19:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW5QK-0007mh-9M; Thu, 12 May 2005 00:35:48 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DW5Ae-000HwE-FP; Thu, 12 May 2005 04:19:36 +0000 Date: Wed, 11 May 2005 21:19:34 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1752873710.20050511211934@psg.com> To: rtg-dir@ietf.org, l1vpn@ietf.org In-Reply-To: <417849708.20050511142938@psg.com> References: <417849708.20050511142938@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Subject: Re: Proposed charter for L1VPN WG -- rev 01.01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit OK, couple minor fixes below. Please check the "single-AS" wording--this is what we used for L2VPN, and it seems to apply here too, since the single-provider case may include multi-AS environments. -- Alex http://www.psg.com/~zinin Layer 1 Virtual Private Networks (l1vpn) Last Modified: 2005-05-11 Chair(s): TBD TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Technical Advisor(s): TBD Mailing Lists: General Discussion: l1vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html Description of Working Group: The L1VPN Working Group's task is to specify mechanisms necessary for providing a VPN service over a GMPLS-enabled transport service-provider network. The following two service models will be addressed: 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. Provider's network is not involved in distribution of user's routing information. 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits limited exchange of information between the control planes of the provider and the user to help such functions as discovery of reachability information in remote sites, or parameters of the part of the provider's network dedicated to the user. The WG will work on the following items: 1. Framework document defining the reference network model, L1VPN service model, fundamental assumptions, and terminology. 2. Specification of the L1VPN signaling functionality between the user network and the provider network to support the basic mode. 3. Specification of the L1VPN signaling and routing functionality within the provider network to support the basic mode. 4. OAM features and MIB modules and/or extensions required for the basic mode. 5. Specification of the L1VPN signaling and routing functionality between the user network and the provider network to support the extended mode. 6. Specification of the L1VPN signaling and routing functionality within the provider network to support the extended mode. 7. OAM features and MIB modules and/or extensions required for the extended mode. 8. Applicability guidelines to compare the basic and extended modes. At this point the WG will address the single-AS scenario only. The multi-AS/provider scenario may be considered in future. Protocol extensions required for L1VPN will be done in cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. Where necessary, the WG will also cooperate with ITU-T. Milestones: Sep 05 Submit first Internet Draft of L1VPN framework Sep 05 Submit first Internet Drafts of basic mode specifications Dec 05 Submit first Internet Drafts of MIB modules for basic mode Apr 06 Submit basic mode specifications to IESG for publication as Proposed Standard Jun 06 Submit first Internet Drafts of enhanced mode specifications Aug 06 Submit MIB modules for basic mode to IESG for publication as Proposed Standard Dec 06 Submit enhanced mode specifications to IESG for publication as Proposed Standard Dec 06 Submit L1VPN framework to IESG for publication as Informational RFC Aug 07 Submit MIB modules for enhanced mode to IESG for publication as Proposed Standard Dec 07 Recharter or disband From rtg-dir-bounces@ietf.org Thu May 12 02:59:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29293 for ; Thu, 12 May 2005 02:59:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7vA-0006SD-5g for rtg-dir-archive@ietf.org; Thu, 12 May 2005 03:15:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7bR-0003GB-Qc; Thu, 12 May 2005 02:55:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7bP-0003Fk-Nv; Thu, 12 May 2005 02:55:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29054; Thu, 12 May 2005 02:55:22 -0400 (EDT) From: Dimitri.Papadimitriou@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7r5-0006Kf-IO; Thu, 12 May 2005 03:11:36 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j4C6tFLD023292; Thu, 12 May 2005 08:55:15 +0200 To: Alex Zinin MIME-Version: 1.0 Date: Thu, 12 May 2005 08:55:13 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/12/2005 08:55:14 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: Proposed charter for L1VPN WG -- rev 01.01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 alex - it is good enough - though one point, the enhanced mode refers to "the user" while the tasks refers to "the user network", the former appears as a terminal i.e. the connection starts and ends at CEs while the latter this is not necessarily the case anymore (the node starting/terminating the connection would have not necessarily to be adjacent to the PE) - suggest to stick to the former --- OK, couple minor fixes below. Please check the "single-AS" wording--this is what we used for L2VPN, and it seems to apply here too, since the single-provider case may include multi-AS environments. -- Alex http://www.psg.com/~zinin Layer 1 Virtual Private Networks (l1vpn) Last Modified: 2005-05-11 Chair(s): TBD TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Technical Advisor(s): TBD Mailing Lists: General Discussion: l1vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html Description of Working Group: The L1VPN Working Group's task is to specify mechanisms necessary for providing a VPN service over a GMPLS-enabled transport service-provider network. The following two service models will be addressed: 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. Provider's network is not involved in distribution of user's routing information. 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits limited exchange of information between the control planes of the provider and the user to help such functions as discovery of reachability information in remote sites, or parameters of the part of the provider's network dedicated to the user. The WG will work on the following items: 1. Framework document defining the reference network model, L1VPN service model, fundamental assumptions, and terminology. 2. Specification of the L1VPN signaling functionality between the user network and the provider network to support the basic mode. 3. Specification of the L1VPN signaling and routing functionality within the provider network to support the basic mode. 4. OAM features and MIB modules and/or extensions required for the basic mode. 5. Specification of the L1VPN signaling and routing functionality between the user network and the provider network to support the extended mode. 6. Specification of the L1VPN signaling and routing functionality within the provider network to support the extended mode. 7. OAM features and MIB modules and/or extensions required for the extended mode. 8. Applicability guidelines to compare the basic and extended modes. At this point the WG will address the single-AS scenario only. The multi-AS/provider scenario may be considered in future. Protocol extensions required for L1VPN will be done in cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. Where necessary, the WG will also cooperate with ITU-T. Milestones: Sep 05 Submit first Internet Draft of L1VPN framework Sep 05 Submit first Internet Drafts of basic mode specifications Dec 05 Submit first Internet Drafts of MIB modules for basic mode Apr 06 Submit basic mode specifications to IESG for publication as Proposed Standard Jun 06 Submit first Internet Drafts of enhanced mode specifications Aug 06 Submit MIB modules for basic mode to IESG for publication as Proposed Standard Dec 06 Submit enhanced mode specifications to IESG for publication as Proposed Standard Dec 06 Submit L1VPN framework to IESG for publication as Informational RFC Aug 07 Submit MIB modules for enhanced mode to IESG for publication as Proposed Standard Dec 07 Recharter or disband From rtg-dir-bounces@ietf.org Thu May 12 03:18:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00353 for ; Thu, 12 May 2005 03:18:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW8Dq-0007AG-9W for rtg-dir-archive@ietf.org; Thu, 12 May 2005 03:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7x5-00083W-DA; Thu, 12 May 2005 03:17:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7x3-00082w-P2 for rtg-dir@megatron.ietf.org; Thu, 12 May 2005 03:17:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00283 for ; Thu, 12 May 2005 03:17:44 -0400 (EDT) Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW8Ci-000756-Td for rtg-dir@ietf.org; Thu, 12 May 2005 03:33:58 -0400 Received: from wnn0476.wireless.dtu.dk ([130.226.30.91] helo=[127.0.0.1]) by fw.testbed.se with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1DW7wf-0006bs-VV; Thu, 12 May 2005 09:17:34 +0200 Message-ID: <4283026B.6020700@pi.se> Date: Thu, 12 May 2005 09:14:51 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <417849708.20050511142938@psg.com> In-Reply-To: <417849708.20050511142938@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: Proposed charter for L1VPN WG -- rev 01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Alex, sure "good enough", one point is that I would like to make it explicit that there is an established IETF process for co-ordinating with the ITU-T. s/Where necessary, the WG will also cooperate with ITU-T./Where necessary, the WG shall through the established IETF process also cooperate with ITU-T. might seem to be a nit, but I would like to see this kind of statement whenever we mention co-ordination with bodies outside the IETF. /Loa Alex Zinin wrote: > Folks- > > Please check below with the question in mind "whether it's good enough?". > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From rtg-dir-bounces@ietf.org Thu May 12 06:54:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13862 for ; Thu, 12 May 2005 06:54:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWBa6-0006Kl-2y for rtg-dir-archive@ietf.org; Thu, 12 May 2005 07:10:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWBIh-00033O-I9; Thu, 12 May 2005 06:52:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWBIg-00033E-L5 for rtg-dir@megatron.ietf.org; Thu, 12 May 2005 06:52:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13759 for ; Thu, 12 May 2005 06:52:15 -0400 (EDT) Message-Id: <200505121052.GAA13759@ietf.org> Received: from aannecy-251-1-3-60.w83-113.abo.wanadoo.fr ([83.113.33.60] helo=kakiseni.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DWBYN-0006IQ-Os for rtg-dir@ietf.org; Thu, 12 May 2005 07:08:32 -0400 From: "Davina Carlson" To: "Elyzabeth Youngblood" Date: Thu, 12 May 2005 06:52:11 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C576DE.4283355B" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.7 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: =?iso-8859-1?q?C=EDALLlS_V=E0LLlUM_ViAGGR=C0?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.5 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C576DE.4283355B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, a self-sufficient man. inherited from her father the respect in which he had always been Captain Blood! said his lordship sharply in reproof. Upon my Comerton - I have inveighed against these lacunae, at others I ha to the Main. Therefore he gave the Pride of Devon the shelter sh The yeoman took alarm at that ferocious truculence. It expressed revealing that the cynicism attributed to him proceeded from his of Cartagena, and M. de Rivarol summoned a council aboard his And don't come near him again until I send for you, unless you w edged with gold. M. le Baron, you waste words. This is the New World. It is not he had considered nothing. But he made a quick recovery. To my I could take a commission of King James's? I tell you I wouldn't Have a nice day. ------=_NextPart_000_0008_01C576DE.4283355B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     
    Hello, How WouId you Iike to = save on your p=EDlIs?
     
    Vi=C1GRRA V=C1LlUMM C=EDALLlS and = many other.
     
    Save over 70% with PPharmacyByMAlL STORE.
     
    Have a nice day.
     
     
     
     
    a self-sufficient
    man. = inherited from her father the respect in which he had always
    been = Captain Blood! said his lordship sharply in reproof. Upon
    my = Comerton - I have inveighed against these lacunae, at others I
    ha = to the Main. Therefore he gave the Pride of Devon the shelter
    sh = The yeoman took alarm at that ferocious truculence. It
    expressed = revealing that the cynicism attributed to him proceeded from
    his = of Cartagena, and M. de Rivarol summoned a council aboard
    his = And don't come near him again until I send for you, unless you
    w = edged with
    gold. = M. le Baron, you waste words. This is the New World. It is
    not = he had considered nothing. But he made a quick recovery. To
    my = I could take a commission of King James's? I tell you I
    wouldn't =
    ------=_NextPart_000_0008_01C576DE.4283355B-- From rtg-dir-bounces@ietf.org Thu May 12 09:32:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23398 for ; Thu, 12 May 2005 09:32:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWE32-0001be-OP for rtg-dir-archive@ietf.org; Thu, 12 May 2005 09:48:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWDn6-0004wR-FZ; Thu, 12 May 2005 09:31:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWDn4-0004wH-GN; Thu, 12 May 2005 09:31:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23369; Thu, 12 May 2005 09:31:48 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWE2n-0001b8-BD; Thu, 12 May 2005 09:48:05 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j4CDVWl20929; Thu, 12 May 2005 09:31:32 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 12 May 2005 09:31:33 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D047D7783@zcarhxm0.corp.nortel.com> From: "Hamid Ould-Brahim" To: Alex Zinin , rtg-dir@ietf.org, l1vpn@ietf.org Date: Thu, 12 May 2005 09:31:17 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Subject: RE: [L1vpn] Re: Proposed charter for L1VPN WG -- rev 01.01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Okay. Good enough. Hamid. > -----Original Message----- > From: l1vpn-bounces@lists.ietf.org > [mailto:l1vpn-bounces@lists.ietf.org] On Behalf Of Alex Zinin > Sent: Thursday, May 12, 2005 12:20 AM > To: rtg-dir@ietf.org; l1vpn@ietf.org > Subject: [L1vpn] Re: Proposed charter for L1VPN WG -- rev 01.01 > > > > OK, couple minor fixes below. > > Please check the "single-AS" wording--this is what we used > for L2VPN, and it seems to apply here too, since the > single-provider case may include multi-AS environments. > > -- > Alex > http://www.psg.com/~zinin > > > Layer 1 Virtual Private Networks (l1vpn) > > Last Modified: 2005-05-11 > Chair(s): > TBD > TBD > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Technical Advisor(s): > TBD > > Mailing Lists: > General Discussion: l1vpn@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn > Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html > > Description of Working Group: > > The L1VPN Working Group's task is to specify mechanisms > necessary for providing a VPN service over a GMPLS-enabled > transport service-provider network. > > The following two service models will be addressed: > > 1. Basic mode: the CE-PE interface's functional repertoire > is limited to > path setup signalling only. Provider's network is not involved in > distribution of user's routing information. > > 2. Enhanced mode: the CE-PE interface provides the > signaling capabilities > as in the Basic mode, plus permits limited exchange of > information > between the control planes of the provider and the user > to help such > functions as discovery of reachability information in > remote sites, > or parameters of the part of the provider's network dedicated to > the user. > > The WG will work on the following items: > > 1. Framework document defining the reference network model, > L1VPN service > model, fundamental assumptions, and terminology. > > 2. Specification of the L1VPN signaling functionality > between the user > network and the provider network to support the basic mode. > > 3. Specification of the L1VPN signaling and routing > functionality within > the provider network to support the basic mode. > > 4. OAM features and MIB modules and/or extensions required > for the basic > mode. > > 5. Specification of the L1VPN signaling and routing > functionality between > the user network and the provider network to support the > extended mode. > > 6. Specification of the L1VPN signaling and routing > functionality within > the provider network to support the extended mode. > > 7. OAM features and MIB modules and/or extensions required for the > extended mode. > > 8. Applicability guidelines to compare the basic and extended modes. > > At this point the WG will address the single-AS scenario > only. The multi-AS/provider scenario may be considered in future. > > Protocol extensions required for L1VPN will be done in > cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and > other WGs where necessary. Where necessary, the WG will also > cooperate with ITU-T. > > Milestones: > > Sep 05 Submit first Internet Draft of L1VPN framework > > Sep 05 Submit first Internet Drafts of basic mode specifications > > Dec 05 Submit first Internet Drafts of MIB modules for basic mode > > Apr 06 Submit basic mode specifications to IESG for > publication as Proposed Standard > > Jun 06 Submit first Internet Drafts of enhanced mode specifications > > Aug 06 Submit MIB modules for basic mode to IESG for > publication as Proposed Standard > > Dec 06 Submit enhanced mode specifications to IESG for > publication as Proposed Standard > > Dec 06 Submit L1VPN framework to IESG for publication as > Informational RFC > > Aug 07 Submit MIB modules for enhanced mode to IESG for > publication as Proposed Standard > > Dec 07 Recharter or disband > > > > _______________________________________________ > L1vpn mailing list > L1vpn@lists.ietf.org https://www1.ietf.org/mailman/listinfo/l1vpn > > From rtg-dir-bounces@ietf.org Thu May 12 10:19:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28066 for ; Thu, 12 May 2005 10:19:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWEmV-00030M-RN for rtg-dir-archive@ietf.org; Thu, 12 May 2005 10:35:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWETO-0005X5-NI; Thu, 12 May 2005 10:15:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWETI-0005WY-Ji; Thu, 12 May 2005 10:15:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27719; Thu, 12 May 2005 10:15:26 -0400 (EDT) Received: from mail123.messagelabs.com ([85.158.136.3]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DWEj0-0002wP-Qv; Thu, 12 May 2005 10:31:44 -0400 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-6.tower-123.messagelabs.com!1115907314!680033!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [209.219.209.75] Received: (qmail 22269 invoked from network); 12 May 2005 14:15:15 -0000 Received: from ckmso2.att.com (HELO ckmso2.proxy.att.com) (209.219.209.75) by server-6.tower-123.messagelabs.com with SMTP; 12 May 2005 14:15:15 -0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MLO-6.0) with ESMTP id j4CECuG4007193; Thu, 12 May 2005 10:15:13 -0400 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh5i.attrh.att.com (7.2.052) id 42628972005C3B93; Thu, 12 May 2005 10:15:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 May 2005 09:15:13 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF09A42647@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [L1vpn] Re: Proposed charter for L1VPN WG -- rev 01.01 Thread-Index: AcVWqizDUCHjegmgQ6K/Lb0TuudMdAAUrCTA From: "Brungard, Deborah A, ALABS" To: "Alex Zinin" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Subject: RE: [L1vpn] Re: Proposed charter for L1VPN WG -- rev 01.01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable Looks good Alex, Thanks, Deborah=20 -----Original Message----- From: l1vpn-bounces@lists.ietf.org [mailto:l1vpn-bounces@lists.ietf.org] On Behalf Of Alex Zinin Sent: Thursday, May 12, 2005 12:20 AM To: rtg-dir@ietf.org; l1vpn@ietf.org Subject: [L1vpn] Re: Proposed charter for L1VPN WG -- rev 01.01 OK, couple minor fixes below. Please check the "single-AS" wording--this is what we used for L2VPN, and it seems to apply here too, since the single-provider case may include multi-AS environments. --=20 Alex http://www.psg.com/~zinin Layer 1 Virtual Private Networks (l1vpn) Last Modified: 2005-05-11 Chair(s): TBD TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Technical Advisor(s): TBD Mailing Lists: General Discussion: l1vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html Description of Working Group: The L1VPN Working Group's task is to specify mechanisms necessary for providing a VPN service over a GMPLS-enabled transport service-provider network. The following two service models will be addressed: 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. Provider's network is not involved in distribution of user's routing information. 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits limited exchange of information between the control planes of the provider and the user to help such functions as discovery of reachability information in remote sites, or parameters of the part of the provider's network dedicated to the user. The WG will work on the following items: 1. Framework document defining the reference network model, L1VPN service model, fundamental assumptions, and terminology. 2. Specification of the L1VPN signaling functionality between the user network and the provider network to support the basic mode. 3. Specification of the L1VPN signaling and routing functionality within the provider network to support the basic mode. 4. OAM features and MIB modules and/or extensions required for the basic mode. 5. Specification of the L1VPN signaling and routing functionality between the user network and the provider network to support the extended mode. 6. Specification of the L1VPN signaling and routing functionality within the provider network to support the extended mode. 7. OAM features and MIB modules and/or extensions required for the extended mode. 8. Applicability guidelines to compare the basic and extended modes. At this point the WG will address the single-AS scenario only. The multi-AS/provider scenario may be considered in future. Protocol extensions required for L1VPN will be done in cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. Where necessary, the WG will also cooperate with ITU-T. Milestones: Sep 05 Submit first Internet Draft of L1VPN framework Sep 05 Submit first Internet Drafts of basic mode specifications Dec 05 Submit first Internet Drafts of MIB modules for basic mode Apr 06 Submit basic mode specifications to IESG for publication as Proposed Standard Jun 06 Submit first Internet Drafts of enhanced mode specifications Aug 06 Submit MIB modules for basic mode to IESG for publication as Proposed Standard Dec 06 Submit enhanced mode specifications to IESG for publication as Proposed Standard Dec 06 Submit L1VPN framework to IESG for publication as Informational RFC Aug 07 Submit MIB modules for enhanced mode to IESG for publication as Proposed Standard Dec 07 Recharter or disband _______________________________________________ L1vpn mailing list L1vpn@lists.ietf.org https://www1.ietf.org/mailman/listinfo/l1vpn From rtg-dir-bounces@ietf.org Thu May 12 23:03:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08168 for ; Thu, 12 May 2005 23:03:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWQiA-0000g9-UV for rtg-dir-archive@ietf.org; Thu, 12 May 2005 23:19:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWQRK-000748-PC; Thu, 12 May 2005 23:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWQRI-000740-IL; Thu, 12 May 2005 23:02:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08043; Thu, 12 May 2005 23:02:10 -0400 (EDT) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWQh6-0000bX-Ti; Thu, 12 May 2005 23:18:35 -0400 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 38F432D4854; Thu, 12 May 2005 23:01: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 47791-02-68; Thu, 12 May 2005 23:01:54 -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 414C22D4851; Thu, 12 May 2005 23:01:54 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 May 2005 23:01:54 -0400 Message-ID: Thread-Topic: Proposed charter for L1VPN WG -- rev 01.01 Thread-Index: AcVWv71AtYSgev/BQYCRPl/pF3Pq9QAqDVVQ From: "Susan Hares" To: , "Alex Zinin" X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: RE: Proposed charter for L1VPN WG -- rev 01.01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Alex: I would like to see the refinement that clearly defines within a single AS.=20 I also would like to see this defined as non-confederation AS at this 1st pass. =20 Please confirm that this is the definition of "single-AS". Sue Hares -----Original Message----- From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Dimitri.Papadimitriou@alcatel.be Sent: Thursday, May 12, 2005 2:55 AM To: Alex Zinin Cc: rtg-dir@ietf.org; l1vpn@ietf.org Subject: Re: Proposed charter for L1VPN WG -- rev 01.01 alex - it is good enough - though one point, the enhanced mode refers to "the user" while the tasks refers to "the user network", the former appears as a terminal i.e. the connection starts and ends at CEs while the latter this is not necessarily the case anymore (the node starting/terminating the connection would have not necessarily to be adjacent to the PE) - suggest to stick to the former --- OK, couple minor fixes below. Please check the "single-AS" wording--this is what we used for L2VPN, and it seems to apply here too, since the single-provider case may include multi-AS environments. -- Alex http://www.psg.com/~zinin Layer 1 Virtual Private Networks (l1vpn) Last Modified: 2005-05-11 Chair(s): TBD TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Technical Advisor(s): TBD Mailing Lists: General Discussion: l1vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html Description of Working Group: The L1VPN Working Group's task is to specify mechanisms necessary for providing a VPN service over a GMPLS-enabled transport service-provider network. The following two service models will be addressed: 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. Provider's network is not involved in distribution of user's routing information. 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits limited exchange of information between the control planes of the provider and the user to help such functions as discovery of reachability information in remote sites, or parameters of the part of the provider's network dedicated to the user. The WG will work on the following items: 1. Framework document defining the reference network model, L1VPN service model, fundamental assumptions, and terminology. 2. Specification of the L1VPN signaling functionality between the user network and the provider network to support the basic mode. 3. Specification of the L1VPN signaling and routing functionality within the provider network to support the basic mode. 4. OAM features and MIB modules and/or extensions required for the basic mode. 5. Specification of the L1VPN signaling and routing functionality between the user network and the provider network to support the extended mode. 6. Specification of the L1VPN signaling and routing functionality within the provider network to support the extended mode. 7. OAM features and MIB modules and/or extensions required for the extended mode. 8. Applicability guidelines to compare the basic and extended modes. At this point the WG will address the single-AS scenario only. The multi-AS/provider scenario may be considered in future. Protocol extensions required for L1VPN will be done in cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. Where necessary, the WG will also cooperate with ITU-T. Milestones: Sep 05 Submit first Internet Draft of L1VPN framework Sep 05 Submit first Internet Drafts of basic mode specifications Dec 05 Submit first Internet Drafts of MIB modules for basic mode Apr 06 Submit basic mode specifications to IESG for publication as Proposed Standard Jun 06 Submit first Internet Drafts of enhanced mode specifications Aug 06 Submit MIB modules for basic mode to IESG for publication as Proposed Standard Dec 06 Submit enhanced mode specifications to IESG for publication as Proposed Standard Dec 06 Submit L1VPN framework to IESG for publication as Informational RFC Aug 07 Submit MIB modules for enhanced mode to IESG for publication as Proposed Standard Dec 07 Recharter or disband From rtg-dir-bounces@ietf.org Fri May 13 14:45:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13250 for ; Fri, 13 May 2005 14:44:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWfPg-0003PH-PX for rtg-dir-archive@ietf.org; Fri, 13 May 2005 15:01:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWf7b-0006ve-0C; Fri, 13 May 2005 14:42:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWf7Y-0006vT-QU; Fri, 13 May 2005 14:42:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12999; Fri, 13 May 2005 14:42:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWfNW-0003HZ-K7; Fri, 13 May 2005 14:59:20 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWf7V-0003T3-If; Fri, 13 May 2005 18:42:45 +0000 Date: Fri, 13 May 2005 11:42:45 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <48587912.20050513114245@psg.com> To: "Susan Hares" In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: 7bit Cc: Dimitri.Papadimitriou@alcatel.be, l1vpn@ietf.org, rtg-dir@ietf.org Subject: Re: Proposed charter for L1VPN WG -- rev 01.01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7bit Sue- Yes, though this makes me think that defining more details would sound like presupposing a BGP-based solution. Granted, "AS" is BGP lingo already. One could use something like "single administrative domain" or alike, but I'm afraid it isn't perfect either. -- Alex http://www.psg.com/~zinin Thursday, May 12, 2005, 8:01:54 PM, Susan Hares wrote: > Alex: > I would like to see the refinement that clearly defines within a single > AS. > I also would like to see this defined as non-confederation AS at this > 1st pass. > Please confirm that this is the definition of "single-AS". > Sue Hares > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > Behalf Of Dimitri.Papadimitriou@alcatel.be > Sent: Thursday, May 12, 2005 2:55 AM > To: Alex Zinin > Cc: rtg-dir@ietf.org; l1vpn@ietf.org > Subject: Re: Proposed charter for L1VPN WG -- rev 01.01 > alex - > it is good enough - though one point, the enhanced mode refers to "the > user" while the tasks refers to "the user network", the former appears > as a > terminal i.e. the connection starts and ends at CEs while the latter > this > is not necessarily the case anymore (the node starting/terminating the > connection would have not necessarily to be adjacent to the PE) - > suggest > to stick to the former > --- > OK, couple minor fixes below. > Please check the "single-AS" wording--this is what we used for L2VPN, > and > it seems to apply here too, since the single-provider case may include > multi-AS environments. > -- > Alex > http://www.psg.com/~zinin > Layer 1 Virtual Private Networks (l1vpn) > Last Modified: 2005-05-11 > Chair(s): > TBD > TBD > Routing Area Director(s): > Bill Fenner > Alex Zinin > Routing Area Advisor: > Alex Zinin > Technical Advisor(s): > TBD > Mailing Lists: > General Discussion: l1vpn@ietf.org > To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn > Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html > Description of Working Group: > The L1VPN Working Group's task is to specify mechanisms necessary for > providing a VPN service over a GMPLS-enabled transport service-provider > network. > The following two service models will be addressed: > 1. Basic mode: the CE-PE interface's functional repertoire is limited > to > path setup signalling only. Provider's network is not involved in > distribution of user's routing information. > 2. Enhanced mode: the CE-PE interface provides the signaling > capabilities > as in the Basic mode, plus permits limited exchange of information > between the control planes of the provider and the user to help > such > functions as discovery of reachability information in remote sites, > or parameters of the part of the provider's network dedicated to > the user. > The WG will work on the following items: > 1. Framework document defining the reference network model, L1VPN > service > model, fundamental assumptions, and terminology. > 2. Specification of the L1VPN signaling functionality between the user > network and the provider network to support the basic mode. > 3. Specification of the L1VPN signaling and routing functionality > within > the provider network to support the basic mode. > 4. OAM features and MIB modules and/or extensions required for the > basic > mode. > 5. Specification of the L1VPN signaling and routing functionality > between > the user network and the provider network to support the extended > mode. > 6. Specification of the L1VPN signaling and routing functionality > within > the provider network to support the extended mode. > 7. OAM features and MIB modules and/or extensions required for the > extended mode. > 8. Applicability guidelines to compare the basic and extended modes. > At this point the WG will address the single-AS scenario only. The > multi-AS/provider scenario may be considered in future. > Protocol extensions required for L1VPN will be done in cooperation with > MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. > Where > necessary, the WG will also cooperate with ITU-T. > Milestones: > Sep 05 Submit first Internet Draft of L1VPN framework > Sep 05 Submit first Internet Drafts of basic mode specifications > Dec 05 Submit first Internet Drafts of MIB modules for basic mode > Apr 06 Submit basic mode specifications to IESG for publication as > Proposed Standard > Jun 06 Submit first Internet Drafts of enhanced mode specifications > Aug 06 Submit MIB modules for basic mode to IESG for publication as > Proposed Standard > Dec 06 Submit enhanced mode specifications to IESG for publication as > Proposed Standard > Dec 06 Submit L1VPN framework to IESG for publication as Informational > RFC > Aug 07 Submit MIB modules for enhanced mode to IESG for publication as > Proposed Standard > Dec 07 Recharter or disband From rtg-dir-bounces@ietf.org Fri May 13 14:45:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13295 for ; Fri, 13 May 2005 14:45:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWfQ5-0003Px-BY for rtg-dir-archive@ietf.org; Fri, 13 May 2005 15:01:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWf7v-0006wc-AE; Fri, 13 May 2005 14:43:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWf7u-0006wT-23; Fri, 13 May 2005 14:43:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13014; Fri, 13 May 2005 14:43:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWfNt-0003Ho-1a; Fri, 13 May 2005 14:59:41 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DWf7s-0003Vb-OM; Fri, 13 May 2005 18:43:09 +0000 Date: Fri, 13 May 2005 11:43:08 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1873065306.20050513114308@psg.com> To: Loa Andersson In-Reply-To: <4283026B.6020700@pi.se> References: <417849708.20050511142938@psg.com> <4283026B.6020700@pi.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, l1vpn@ietf.org Subject: Re: Proposed charter for L1VPN WG -- rev 01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Loa, Dimitri, ok, will fix. -- Alex http://www.psg.com/~zinin Thursday, May 12, 2005, 12:14:51 AM, Loa Andersson wrote: > Alex, > sure "good enough", one point is that I would like to make it > explicit that there is an established IETF process for co-ordinating > with the ITU-T. > s/Where necessary, the WG will also cooperate with ITU-T./Where > necessary, the WG shall through the established IETF process also > cooperate with ITU-T. > might seem to be a nit, but I would like to see this kind of statement > whenever we mention co-ordination with bodies outside the IETF. > /Loa > Alex Zinin wrote: >> Folks- >> >> Please check below with the question in mind "whether it's good enough?". >> From rtg-dir-bounces@ietf.org Sun May 15 03:02:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10846 for ; Sun, 15 May 2005 03:02:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXDPe-0005zK-Kd for rtg-dir-archive@ietf.org; Sun, 15 May 2005 03:19:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXD87-0001Re-Kn; Sun, 15 May 2005 03:01:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXD85-0001RM-CT for rtg-dir@megatron.ietf.org; Sun, 15 May 2005 03:01:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10770 for ; Sun, 15 May 2005 03:01:35 -0400 (EDT) Received: from csmtp.b-one.net ([195.47.247.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXDOM-0005xk-Uh for rtg-dir@ietf.org; Sun, 15 May 2005 03:18:27 -0400 Received: from luis (x1-6-00-08-0e-8d-a8-33.k250.webspeed.dk [80.162.59.253]) by csmtp.b-one.net (Postfix) with ESMTP id 41A351A099EF4 for ; Sun, 15 May 2005 09:01:26 +0200 (CEST) From: "Info New Way Calls" To: Date: Sun, 15 May 2005 08:55:47 +0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_797A_01C5592C.ABA81680" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVZD6zzUeoGjxCXTF+YdhaWUUflZA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: <20050515070126.41A351A099EF4@csmtp.b-one.net> X-Spam-Score: 4.2 (++++) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 Subject: How to call for free! X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.2 (++++) X-Scan-Signature: 82b297dca242a35ee50ccecf5bf2e37f This is a multi-part message in MIME format. ------=_NextPart_000_797A_01C5592C.ABA81680 Content-Type: multipart/alternative; boundary="----=_NextPart_001_797B_01C5592C.ABA81680" ------=_NextPart_001_797B_01C5592C.ABA81680 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable =20 =20 How to call for free! Como llamar gratis! Comment appel=A8=A6 gratuitement! =A7=AC=A7=D1=A7=DC =A7=D9=A7=D3=A7=E0=A7=DF=A7=DA=A7=E4=A7=EE = =A7=D2=A7=D6=A7=E3=A7=E1=A7=DD=A7=D1=A7=E4=A7=DF=A7=E0! =20 NEW WAY CALLS =20 =20 Make FREE Mobile Phone Calls with Cellwireless Telecommunication=20 when you help your Family and Friends SAVE on their mobile calls! =20 Best regards! Team New Way Calls. =20 =20 =20 =20 ------=_NextPart_001_797B_01C5592C.ABA81680 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

     

     

    How to call for free!

    Como llamar = gratis!

    Comment appel=A8=A6 = gratuitement!

    =A7=AC=A7=D1=A7=DC =A7=D9=A7=D3=A7=E0=A7=DF=A7=DA=A7=E4=A7=EE =A7=D2=A7=D6=A7=E3=A7=E1=A7=DD=A7=D1=A7=E4=A7=DF=A7=E0!=

     

    NEW WAY CALLS &n= bsp;  

     

    Make FREE Mobile Phone Calls with Cellwireless Telecommunication =

    when you help your Family and Friends SAVE = on their mobile calls!

     

    Best = regards!

    Team New Way = Calls.

     

     

     

    &nb= sp;

    ------=_NextPart_001_797B_01C5592C.ABA81680-- ------=_NextPart_000_797A_01C5592C.ABA81680 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhLAFVAPcAADVwtVJISe3k5b+xuToyOT49PtDM0UM1UeLh41lFd2dPk2RjZjQgZVJSVnd3 e1xcX3Bwc0tLTSgoKeXl6rGxtGxsbmhoapiYmoeHiUJCQ729v7W1t/7+/+vr7MzMzcbGx6mpqoKC g1RVWldYXU1OUnp7f62ustTV2V5gZn1/hI2PlMbJz0hJS3N0dpucnvb3+fLz9cHCxLG1vMDEy52j rVhbYFteY6irsN7h5nd9hl9jaWVpb2ltczQ2Oaiut4CEipygpq6yuMvP1aSmqezu8dja3XB2fm1y eYSJkNbc5Lq/xpGUmLa5vTVvtTdxtzdxtT12uWKQxo2Vn5ObpYWMlYqRmrK6xGJma8/W35WZnjVx tTdztzp0t0N6uk6Dv3N6gnyDi6OpsH+IkU5SVkRGSKOkpYuMjQ4UGQ4SFQ4RExEUFgsSFgsQEx8r MhIXGjNgdx0jJpm3xyguMbLK1nqkt2mKmhYbHUBwgWevyYyuuwgOEE2GmEt8jXedqS40NjWjwjSQ rGKWpEdhaFCqwXu9zkRMTgsVF5DH0mOGjXiSmBofIDZAQrnZ4Fp0eQ8WF6TS2QUKCtLT046Pj4CK iHuRiQsPDRsrGxcZF05RTlVXVcnKySc4JFBpRUlcOicqJB0eHCEiIDg5NxIUD0BEOnuMXW17UGFr So+ealhePGRqOE9PL0hIRTU1M7Gxr6Cgn5KSkU1MNHx7d52cmEpGOoB/fD07NiYlI21rZ1BKPyMg G0Y/NUpGQE9GOkM9Namcio+Kg0E4LUxCNkZCPU9LRqiimzErJRkWEycjHzQvKnhybDMxL8bCvnl3 dVNSUWJhYFVJPlhIO1JEOFpMQDozLUpBOlhPSL2rnWtmYl1ORE5COl1SSlZMRR0aGDw2Mk1HQ1VP S1tVUUs+NlhEOFNFPUE4M09FP0U+Oo6FgFhIQEpCPpeTkVtZWFNIQysmJGRcWUo+Ok5CPkE7OS0q KVM/Okg5NZaMioRIPbVcVPtvbS8tLXFubr+7u9DQ0KysrJaWlv///yH/C01TT0ZGSUNFOS4wFwAA AAttc09QTVNPRkZJQ0U5LjBCPKT1ACH/C01TT0ZGSUNFOS4wGAAAAAxjbVBQSkNtcDA3MTIAAAAD SABzvAAh+QQBAAD/ACwAAAAALAFVAAAI/wD/CRxIsKDBgwP5adAUA6HDhxAjSpxIsaLFixgzatwY UcOHD5o4ijz4wh+zV2YajlzJsqXLlzBjGuTXAsMrFzI1wpD0qt+QDTmDCh1KtChFDstCuGrlyujE DiFelSkDwqnVq1izYuTQipaLfhdOaD3YgdarIVTHql3L1mlXV2DFthVIS9LUIXPz6t2rsR+tC2Aj 6TU7tQzfw4gTFyzjFcQFfnk/1C0zpKniy5jbyqIlC2zIucti2QUhK7NafQVWxTLN199fsB8ii3Y1 BCfrq/owKZMnj9WqB7fnbr7gWGXbZbTMuCpjOzhRTPm4cfsEKlcu6bZCOVe72d8Qf8bZev+IpXxI 6e1BY8mbDqo9qGPW43PLhB5rd8ca9MaSyry+TGGXUNeeLQQeY6CBn3Ajijv+OeVKYxeEt1YRzEji imMNvtSNMdS1Y0s7vIXoISiffGLMMRkWNZxj++R1AnkulHFBiiy1Y0wux7TTTjHIKDPNNMrsdgwo 3FxyyTHmfHOOQdfQyFJ3ZfiT31UwvGBlQUXcopQrkjgp0jHc5LIjMj1O000ttXSTjy0lGvnJMd30 Qg48TQp0yzTxeKOPlxJZeSVBstxylhlTEhXJCQgggAMOEyzqgQdEEBFJLLQMoYEDfGrUDjcG8mhm LfGE2o0ybBpppBqiIGNOMOHo0ks17pj/k0465nRDjjcQZDpQEfwUkeiiixbxAQJEdOAKM2Z8YEY/ MiHQQZUvCHTCBxNEGmkHOHxQBAcvEAEDrzHQ0oFWAJRb7lhg5ojMp7LuUisybBaphhqVVAIJKOmE E42+ukwzqznvmGMOOaFkgEkIDSIgABF+/gODBkVYe20kH1QJAwwd8BNJTzBFosELMBCBQBEnROIB EEOYIMPKMtxgQhGMPvsCBx0ARa655mK1ni3yrNuNLtmUw046vSDTzieXzJtGGnqgAcknu4SjLy/k AB1wLQC32kuaBayD3j7bEjEByYfK4MINQbAcxBAzTDBBBwxz68FnLvnTTxErxDCDEnyv/yCE3ysE 7jcWWCSRBKNuv8AE3VfhjLNVm9oiQT7TkKPvNtuUU4s8tpB4CdNpOLJGGpDYIkw42UQz8CjvvLPJ JbZM04sutAvczTTUOHNbDBhEEskMe/M9gxDECx444YUf3igMOFTlkiYQDLGCFUxYIYP1Plx/fRBW KNG9FTMQbngSEwSxxM2On1tUPNxIng8rlj+zTTW4kFMMgZ+okUYlaqChhx5sqIQyhAG0bJCDGgUo ACssUYhNWOIS7ehGPAQmsHiYaRe3yMwrQqCEGVTvelYIAwiZIIMgeO97QhAf+YqAgZe84gE3mAAT guAD7mUhBSn4QQWO8IMsZAEJLTDCEP+IRzjibQAIY+HCE9IHAKIIo30S8FE84PEMbFSjHN3gXOf0 xwb/QaJeafhELagRDmrMjhoBU8QoSsFGTrCiRMqYIMDoQQ9yTKMWq2BGYiLhjBSc4AQ1rKEMSoCE EpTgCl+ggg8d4IAfDA95gSsDE1xyC2eYAAZCCMMNsjeEJdAACFMAAhBuIMIwAEEGyEvC8JhwA61E wQtdcAITheIMTskjH92Q1TawIY10TEOLinADGoapB0gUsxKXQAbWWEUPNPKiGJbgRCpKQQpSsLET m/iELVgRj9nRkR7AQEYv1pHBvRCjGSGIWBA2mb0siBII7hxCGGpIAxqksHBYUIIQbkD/AZcwYwEm eAECgPBJgoYhDOtkpyDVtjImYEEDZYgNRRznBC5AoQsY9YJGo8DRjnq0oxrVaBeUOEuZhCBM7VBG N4TBjvltgxqskIcnbBHMYv4PEsYMECiQQQ5zUAMY1MhGOnQhCk6UIhVIZSM12TgKS1jCE9P4Jj26 cbtpmMNreWnFOn5wAg4wgaAElacPxoq2hZYwCGmTwQxOcAO8tMQVAH1BB7JwBDD84Ac4hEAKwJCC HHwhBSXo610DG4YixGAIk5QIE8u1RAAs0aJcqCgXIDtZJT7hCZV1ghOeoIXFyqQ67UBGN97BDmxo gx3v+KUnJKAI0cFBDnLwg2zlYIv2/432HcAIBjWoUQ5QbIIUpziFNVFhCjYCV7iccOAnimErcnQD GM49xmrmkqUQdDUGJTCCGPaaghY0sq9fyIEh94rXEphhBVgwQRkmwJIQDKMCl+zAK+pABzokoQg+ +MIMrFC4IrCNUTLowxcqcIMi7DMFil0sE5vA4AY7uMEKLulL3tgOXL6jithABzXUxJvWGkIRixiD IAqxCDnkjxvKeEc6yNGLYOiiHNMQhSmEG9zgWvO4NT5FKZL7VHIA48dm0l1bYvCNdaggEhzYBxj6 QIc54GAFYADCHGZguA8MIVh96MMCzDADHDBBBZYRyQUyMAoIBAFjVYgDHeIwgSTkIf8MSZjD4ZIQ BMTNIQ9i0McQSHaDBUjoIBEOtKAFDZNVfCK03aAGOkz7UnIoIx9yAIUj9GAIOMChDZe2gxvSYIxi 9CIdUy0HNeDxjlyAghM4zrGqc2zNTbACnORYTzzmog9lZEIFXR1AH9Q8hwnMoQ8rYAQWGAU8t+Eg D3nQBwZigAMlmAFTI6HAKnbRgjN3QAWA8EIjpkAIPBDi298+xCEe8QhwBwICQCCZCVDQiohE+MFN CPRlNUvvzSr4JbfIBc+6QY9damMbu4hHN1ihDDgIEw1ncIPC3bCGNbAhDbmwXC9GCw94UMNV3SgG MFBRilV73Ma1KAAdu+EGSLRDGnX/UksIlOEMXCd5D4PggxjyAG5wi3vchwD3ETCgBBxoYAkLWEkM 8GhmjFEBEG9YRB5o0G1xE8Lp5M45IeiQDCD8UQYWYBZEFltRKEChshftQkjHDssueP3rXNiCvT3b kljoWx7KMMcztPFvotUiFKywhR3Y0EW+o4ENDef7J/gdjmnoIhjB4AUvhLELaESDHsXQuClS/fFO ICMe5CDHMfRQiXBAAxhYHUsJ5PEAM3R1H3sARBuOEAeaPz3cT3+E1AnxBQ7iIAYuCPpIItGAZlQg CC8QQBUAgXREBKLmTxc3I5bPiKnrwxUnwIIMHGCCiVAUCl74aBTogAc6RAEP2w///ytHSu/Ost0l ygAF3M1RDmxYccVnCoUEkuZ3vvMdgHq4RNyzAQx6ZCPx4dQMzTAPi4YN8zANkQcLHfdxpSA7ctIN +zMN0gAN0yBkY2EGv4EEp7cHf3AHb0BfNXdzzJcEOVd7TNBsZXAERDASH7AADVABMmB0gDAIeDAI 3+ZthCB7j7B845YEjNAHFeACQlAETOAAQLCCRCFLgRYThhZFtVAO1fBvwyBwoVAL+WAH/dNFjvB3 94dM+RAP70BHFRcOuNAL3FAAEdAN8DAOvPAMz4AOhdcOwDB5NXZcsFA5LAYKkCAPAQCH08AWr0AC pbctqPcHNIiD3oZzj5AEsscIJP94BCFwgjEABBAgGBzhAf3kDBawATI4CIeIBzg4bstHblEXCEE4 hEyQBR9QfUQRYTlRAZ8wObWwC9ugDVckDGmCd4pwBl00TFzId5UgCp4wRj9FD6iTeLOwC/nwCb3x De7QC0HDDuMQDcCQgDMWXA1IQdNQCaAQAONwgOCwFiBQBC7QACpAiHxgiDTYbYm4g6MYdYTQCJGI AzOgSTFQKBnRD/7ABCNgAUyAMUgACIYIit5GBzkYBnHQiIyIB3vQAmUwhEpwjjHgD62YPkNBILhk DvPzDd6Ai1XYAwbXcL7Ihf4jCsdQNahTNYjXC7hwDbiAC+xQANtEAhVwCwEAD7z/AJPekFrFMA0c pwrAYA6hwg3GMAvlEA5BSZEqpwEYQALnmGTp6IkESQh9cAhWMAU66IOHMAiNUA8yQI83AAQdcD4b 8U8LMAIwiDFiIJBSiQeJUA+JgAjWQAnfxgjkhgd3oA9hsAJESJZaJxSPMxQOkHcSMA2kVQ3VMAwZ UACgEgp6dwaQOZL2dwZwQg/BkA28YA69kFvmkA/fMA3ZIA28QA3plwEWwAzfAA7wIDTbMDQWpHG9 IDDFYAzmAA/RsJl7shYVsADOMAJPuQ/p+Ac1iAeBIAuTUJy/kAd4QIqHsAeC8ApfGQM3UBWGsREh YAEL8AD+iDFgwJaeOAg2YA0W/yAI1vAAgWCDsjcIdcAMe1kEZvMPQ+ABXrIOq+CYEsAKvcAOdFcN u3B3CcRaagB4ZzBMgfdwoDANiId45uAN3hAMKkYA8kAORDMM7hAAw6AMx7BN65AB3AQw8IBawKAL AkMOxtAN5ZAN/BeObIGdZ/mbd6CONHgHvnAOghAC9aADNDhuNXgE0NlsJlB9YZYRGICd2vmPHTAJ 3umJbzAFjYAIfXAHeXAIcUADh4AIjcAM0kNnSFQG8pkit/AN3TAM8pBSUxSF/EmFJbaLwzQvXMR3 YdQNCaoLsJIO7CAN2MAO8OB/5YAMZOAM04CY6UAAawIKtpAPD3ALrVMO76ALLP92DMiQDkHTC7vw Cm1RAdgpAi7HBFH5nXtgBJSACHVQB3sge3EQB32ACBagDnWmBDcAFEGKEWZQARXQj9YWkDQolU9H A/UQCDhnBufQB4HwBiUAAnwZBE2xAV3qH8nwDWkyDMhwDMpAAOkwP9XgDeYQCqFQAH4ABwHKpm0q eKyQDuWgC7jQDd7gDsWwaOiAOc8gNe+ADMVAD/BgDtfgDN4YMMcgDxHgI6IWm/AaMBdHDrnJFhCw myJgelA5g9/5bXFwATnwdIyQCL4QC3TAB4IgCxTQbPz0D86jEZJQARAwAgtgM0gQCDXoiYdwZ43g C8mQB48QCBbgCzXwBm8QCxH/lQQ+gBMegI/bMQwh2g2jMAr5ulIB8A3aEADXGgqjEAoGhwbz4osO 93CfoAxBpQzfIAwFIAHy4HkaBrS8gA3QMA6zwAvf2A7ucA3IMA/jAA/p0A0GEg+iZkbtQA/vQA1t q6Jt0QIGa3r/MACIcLLoyQgrmwxSIG6CQAzX4IE2oA4m0GxD0E8dmxH+AAEhO7ICIQl0cHNzMAeP 4AOTsAyUYAWMEAeU4AOJQAdgkAxZMANFcANZ8A+akKzB8QufCbS/VAue0A54kg5Fy5Fo8p92sKYj 2XBpcAn5YA68UA5wNzkPEADPIA7BgAyZsADTwAvagA3bEA3zMA/voCPAkFru/7AOrbOG5TAryABU u9UNu2AGeUELEGABDWAGRfAPFECXUnoIjGAFj5AIrUAMU7C5iUADVZBlyRACBaYEQFB9/bQRmlAB DvAAKBAEAjEJSpAoAiAASiBnWOArhOMs1QIDy6APS0BlYbAEExAD8zu7s2Am8bA5U0sqKmUO7GCh ilkAGZABcoCFveiLgMcG3IAMuhBU5UAGj5YPmfAz0jALtpABPWAL3tAvmIMN45AOu+ANsyAM8uAN 6zAN26sNq2lH1CArvVAAKdcWZqC3JIABYmECVWDBAnAC/NXBSVA4HVDHkXIOKRAGzZbAHZBYGsEP evUAD3BJE8BzF3zBjHBnLv87B4QQB0IQMm+zDBAwwkVAAybsx6ZxDaPggFlUIvkgk/KwUt4wDMOw CouZAWTgB8H0cGnAww+XTD7FW72AAhggDEXjL7swDMqYD7TCChBQAtMwd4m5CyIqDMUwt/QwD+KQ DeZgVQEjJw2wF5LgABBAAtbFARSgAgpzwTgge1E6B4eQB3GwMB0wAQKAASlwZTIwBSYwATx7ER5Q EygAQzBQyBpwAhpgALGrCZGwAh7hAR20AgZgACcgyRGSBCWMAzaTGbQwCsBQC6PQDTMFChHQDAUw pnGUy8PgDaZMBiywCCH5cMO0NMPEDfnQC+8QDOWARRkgAsUwDvJTCxkADgH/cL3SEA7IcASFAAq8 EAzAMAzVsA3joFvmIAxz9A78tlsTlw7sqxevYEgNkAJCgM0SGbv6bDIxsAyaIARKEDgDjQC/EAJD kARMMAVBYFgi4QCx+gBDUCw/8AH8kAzEUAb90A8bAAFl8AtloAEqYAEYYBcGIMKsC08n8JeKkQzC oAyjANH54An5sAr/oA7eAMOzSMq6nAGrQAJkkMOGMDpsAJkOlwZ28IVkZLfUwA6sgAzZAA3oINNm sAD5sEvigA3kkAtyYA79sg4tUAu4YEXD8A5bAzBxgqLU0FNlPBcX4AAYIAJSjc1LIF/1sBSyIBn+ 8Aqv0ApB0AItcAHpVA8l/6DHZR0EKyBR1vlsbC02IRACktACtEALf20GEBACLRAC3cVIPJACtFAB S4DCoCQEkYsY20AOtSAMofBorDACA9EMz9ob8aDRq7AKLNAAJACSouPZDedwU1sAqxIOwrAK31AO zzAOMF0N8dADNiAHfEhH4HC9LXVHPzAGn0ANScwqsAA08CAM5TAPUlMLzXAYFFACKjACKbAC2NwC rxALscAMGIAB/uAAJeDkIVAC3uUAPCAJtwAGZYADMpAFMsAEspsRZqACP/AAYgkDTOACF4DmF3AB /uAPLvDma/7mPrQEZyHeRRBKGtAchwGmoZLY+RAKPU4Q7gAKnqBSwsCgu/+Ayg0gAhkAB8Frf4G3 Bp/ACsJARonXDRGgDgRQcSu9CwFQC9vkDVPVAhDQDdfrhtOQI+SADtFgD/dgD8CwC+OgYihqQKuA MHzxASVwAQtQAh/AAZEwBBeQBXDe5m8O53A+7BZyAycYBFzOpSLxCng1AkCgT0UAN5FyMVbCAdw+ M34CLWKDA0KQBWuj53oBDtCFi7WgDIDeJQXBORmZDgxqymMwAiwgB4rgP4AXeGoACiv1DqgTqe0g AfHwDEOjDOc6DNsgDdqADAXQAqzQDsPAqLXIDt4wjcBgD/hwD+KQAYvKKkiZDhaAGB7gACqAAg7A BB9wAjggMdAyM9zi7Vb/YjHYMgE3QANMwLccwd0t0AAUwARDAE80oFYddI8bQAEm4BFzXARJcAJ/ 489b7gIqUJ168Zm90AswxQqsgAklcBAY4AmeAD/yztFkQAI2MAIg+ehd5HBoAAqhQEbh8C+HPive EA3jEA/X0AKYMA3bELbfQCrtkA3hEAr6wAzdgDnREA3Q4Or2MA+g1gvhEAxXH+iIodwj4AAzEJYu MAU30EHAowQasAEmsAExIARNf1/FswJMUMJD0PUi0Q8tUAIFUAZ7s1YzQANhEEIqsAStOgRRTgXh IwQnYDjAfgMQ8ANfsNBtAQ6Zp+6bEAp55BCucKGskBoPngERYAM6kAES/6BpmoYGrYwGtoA1dUsN whAP63AN0Cji8lMMAaAPussOf/oN35C92FAMaRwBx4AL0sCG4xAOAEEv2rhw9GqF09VtFa1/DR0+ hBhRokQAACZejOgAQ4MFM5RoEHLCBxAZQbKocEWBgooSYMJgESIkSZEJMJhkubLEAUaeD5ksCPEg BZMdY8zEKFImyIobDih80CDpSgMzkVbIAKKiQyQVR4Zc4ddT7FixtJCR62WOFatQESr0XCeMlZ8C LFhEqHFlTBtFbvxIsIMmjZt85syFe0ft3S5WBeJNG8cLV7py25AVIxdgWoB6mMhhgwYNnbx8+bpJ g/Zs1jx48+bpokdPF/+1bqOckcXtsOJui7kdOnDQQoSJLBF4DCmiAciMGUgkfYjRr0UNGyCV3FDB hAgTC1l+YPA90RmEIy2yuEjxhYcGGSeI9IuVvIQL8j80+MhxQ4NyMUCWLAgvQLGckSChWpCphYUW yBrmEzjg6KEQFErQwQ84FFFEAjfUSMMOVgwLB7F00skmHQIIgGccXHrJIIPKntmGnXYWQEGCYsYB Bh4RqtlFmHHEESea1sKZByHYdCEnlDEEHIu33QLEYIEWWvihDCpS4GGJGWSA4QRaWilCBRUwOIKH MmKgogomYmilCirCqMAVJh9aYIEKyENiiDBcWIEJAzj4pwUNcIgBAxX/sighiBmEWCEIf1SQIgxJ FpyzUocyQWaVUJBhZRV9xIqgGYcysKONHhYppIa94JDDDzvWSAOUeNLphRx6wskGnnTmyaacEcuJ RxkHICgmHHTGqaacYvJBhh1qdsHgAXKqeSaYaKLJNbJZdNGFyIQisJQnJ3nzrZ9mKuDhiPluAMIE Dzbo4B9/JCnihDJSAOKHJZRYQYgYypCkiilusGCDcIXb4YodWsB3CCaYKCMSIkygpZ8yyuAnjBtk aHSIKqqQQoogzAgh3ErBQcabWpQp4DaxhpGnFnUaUgaTFArJYJFFyNi5EJ3bgMOcdOghhxzEskEa 22DeKWcYc5DJoJZ2/955B5h3AsAGHXSemaYCB+IpJllexh4n13K4pRqebjKIxeSLxiUXNw1IuKJu HhxQYYgbYnB4giJC8MeEC2JQQqkYYrhhijSlAIICCz4IF4MIFtBB4R00ateEMpg4gR8mPuBHAyaE YOKGJVRYfAorAHdbwFiKURmZAiAY6xpbwMnkln/WscWhJSpAoQaGpNDB50UcK3pEapbPBttslocn AHOmmWYXb6bRhwc/0okRG11AISCfd7Yphx12eEH6+XfMyeYdckZ5q/WJ4H4St2Ye0EGHHXbgIQUV +qEACEDggRNAxQPvYk4QXKECJFBBClPQWPws5YpdPAAFlUvYwkqggv8yLMEFZRjCEIBQBhlY6Qdg AIMYqDAFGgRBHxqQX3iQkQ5zyKMAlBKLMmrhjGGsIgIS6IkUrkCGAjjGMCOaRRKRBg94lAMe3thG jLZhjnxYgARwqEUAujGtYaQjAM8YBzuqxo5y8GJ5iIFHPGohqhhShH7160kH1tEMFFywble42w9c 4B8QhtAFJgjCEpCAQjA4cAo+8AdDwtWKYazDBjZAwRUqV7cdGKEEKfhBJjOZghykgJCFjJQJmNHG 3KhxF5zS3VhqIY9YZEIZtzADWXDCgkW0SBi7KMcSncjEJrLjGc/ABTvI0Y521GIXyliAPtg3jtQ8 Qxq8CAf54JGNEMH/wyCYkAQpI/LGuPGkA/oYxiNtMElJ8q8El9TkJlPgSRT+oAo0kIEkYrnIbzSg BtS5IDktx78jHMEIX/hCDj65Qh+YoG3aFMstUoaMfDyALJjwhDMyUYB1BIgHmSADGVaxCzJ6Ix1k bOI4RPqM8plvHNLohTwsAAF5AAMa0TDfM8ZG0mmG6B21wATtcsNNnva0ImKZQDIC8IB7jjN/d9wf P/v5T4ESUoU0sAIGymCyDbijGUW9oB33ma6lMhWFYmigFGRgAvAgtCfdMAc5irEKsjADGaO4BSZC MScHZGIVq/AGXr2x13KM45fArIY7tjEOrW2jGO2QADL8GoADHMAb/7iQaYmCEY501GIVV9ipTzXL zbI0YwQjoE7+jrrPfi4VoF9t4DuVgIEYmOwDFvDsCB55QaOiYH9c9WdAmwpWgclgCP4wK08Umg5k KOOgYvEEMpKxClYock4hsAELyOAN85UPjH7FxTdo8Qt3sAMewOxFPNghDcYqIAEH8CUswkGNcAQD GKPIhG82O1+4icUM61gHaGdbR0nqT6n/DKhTHUgDJYQgEiZjgjOaIQL9QhKSR00qD4ww4QCnME2q k8QFgouRdJBDGMf4BllGwQpnYIKiboNuRu/KUV8S1lfgiIU63JENXMwCss/4BgEYwAACsCMYwVAM NdSIiSXIl75H/v9pTzDQDM9SB5J1hPBt/elVFIbVBzKIhQdMpoEFBKABDH6AOB9Myf9+gZ1hhWoI prrhiUxjFt2QxyjFcg1WZOAWhShADMFwBZxtlLpaO1Y6qAEOcITgHN+gBi628QxqNHYb6BtROjIQ j3MFCMn0HYskIoAJEYigBmHeLwal7M9OWlhgPgjDccOljwg04MugdbJR/csDrn4BtQILgxJK0Ao2 SyQWyJjFZeQkFnmwghmFYEVZYygJC0SgRXgtnzfgQY20DIMZsqAFOLxxy2HgYmy6Socu2mKBXkOE p2QBQTNI4GoGxzqfluOqEZqKBCQwzgo0cO7BvrGOdXcatBYc86j/AyyGj5FECRDYR7khog9k9AIZ 8gCBWEIRiltEYBRsRCgExpCBu65CGCN6h67M4Y1b1OMV7hjGrIIR6XQAgwUuU/g/zk0WCmSiGQ0g gb8//eRJ8i9d/0Th4mgwgwvk21LMuB8Jcs7gBhtVYbQ+QkDFQHApwPMGFdByzBvSgrcq4xhGlwjL VuGMDOSZzV8YARlYsIoMmOPj8KAaPbyhjVjIIgUBoMxiCrCLEWhd5m/0zQZwN4J+txvUdvR5bk0N wQLP02QhcMcDGtDqBny2qJAkc7qkrsKqW+F3B/b7P1ihDGHIQxk8KUAtCkCL1M+s3JQonl3IkAES lUMxsAHHoRND/8MC2MDxCqefgCqwjgdEoN+Wn23PaQ10FVYBCFeGgIbd5gILWGDyhYd1wPkZYAcC IQwzwAAEDBZ6TIy+AO1Axqcisg5WSOABt5DDKsitdTMUpRAaFcYtqWGO2JBjecHQhV7IBFUDPieZ E2awgAW4i+PLPsT7OakTGKgKAgsALrcBASmJLuNjN+RDvKUSKEPygRlwAAKMOX/IB2UYhW7ohmNQ CGewgHVYhXiwBTsrAEzIAAnyuyw4ghoohPvLAGEwh1oxDGpICHDAwZjrJiaBgDuJAOMbg1fTLwfM rRygOgIbAmcwgdbhMgewADIwvnV7tTCzI6iTN1CaAhnwAaAIPf+HcIZasIUCCIV4iAcJKIBcIAMJ sDMWqIBQyID5W0OHAAMbGIP7m70CqBVy6AZMAJA/dJsSqIASaAAvVLovAzMo8zmmIjgWiipngBy3 8QCvaQG1+0JKHAEx1J+fo8IBs4IseIBXYMR/qIB8KACWiQBleIAadIZFaAE/UIZ1+L1X/Icf2AER 6EEyuKUCWAWHAsZwMQMISIERyIAmJIEnbLfZwiMJszUqICgrgAALCAu30YQKSAEHYIEMWMDjwycM IjWqCwMrAIMHWDNGNIMHyIdQKAAJwAQ56IFM8AQ/yAQcWkaImI4IIAOcwYRfDMgAUQFnRAFzXMAx 8DcLuiD+ATr/EKSBK4AABJAfZkgBCChHUQTDduMviqRCgZmCLOCBgglISRg+PxgDFvCDBxgBhEzI h/gBHRjEI6jJSnGFFiiBW8wAkNzAgIs6M6SBHwCKCZAfWnCACiCiAlA7FmDAB9sBUiskN8kBHqgA CtjJfyiBRexKnuCfsGQSDXjEESiAFhFFiBTJytG8FHITMTiCKwgBpWydZlwAOEzLoNTAajzFqBOo LzCCI6iACmgtskTMxJQffrCAFiCBHuDDoLwLakxHVASDHPiCMrEAmqwUF6iABwiFxthLtZvGysM8 fhpMHsigFCgCxXTN15yTJWQBtthLc+zL0FKYpTqCpKqAiJOf/36QvLWwxyKSTKWDyCdLqoTJnyO4 gHiBzeeETrHQB2coALYYzrR8yMqzxKTSAdsqgcNsnQ9YBRYIzVDogSKqzQWsPNkSrTpKlyGIzviU z4gogRaxzuFsEYfst3sSre68giP4gW+UnwpojImbOOI0PhFwNVcbgzG4J+pQmBTgyvmk0PgsgwyY OMi8TjIAwwVtUE/DJ3RZghNoIzMgg3woUHuMAAcogRZwAEz6gTEpihG4oAXYASBQggrV0eeMgQdg BVk80AJYgHH0SUxCApYYAU+jrR+4AVJyhRFggR5gmbTUgRwAuhx4Jx+wgjC4AurICxWQvh0VU8WE ABLIADkggP8iIoEWEMymgiArsAIxkK1HcoALyEJSggAOJQM/YIUGII+i/AIxeCAWSgFPMwIpcIB4 HNNF7UoTkMZQoIuVskosnYJKBQIdGIEraKCd0CYNmEWlKyIWGAEJM7UqAAMjqBuBqoESYNRWDUsI wMMGIE8O/c8PdBMqyEwbANAjEAEYQigKCIUZVLrZC0oHrQHLm8hm6AFOddVmTUh9AAVlMD5naxFR PdZj5S8UgEomYDMIUIbQXIWbS7oHYLIHwIQIWIVMcEVnZdeAdIVatEdMsLlMyIQGmKNMWIcIsItU 6rVW4FZXMIOmtIBbWIcFMAMQ8NV2VdiERFgQ8IcQ6MYKcIYUB2gBF2gFAV3YjNXYjeXYjuXYgAAA Ow== ------=_NextPart_000_797A_01C5592C.ABA81680-- From rtg-dir-bounces@ietf.org Mon May 16 04:14:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09062 for ; Mon, 16 May 2005 04:14:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXb10-0004GQ-KC for rtg-dir-archive@ietf.org; Mon, 16 May 2005 04:31:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXagz-0000ou-Nn; Mon, 16 May 2005 04:11:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXagy-0000oY-CH; Mon, 16 May 2005 04:11:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08565; Mon, 16 May 2005 04:11:10 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXaxR-00049e-Dr; Mon, 16 May 2005 04:28:15 -0400 Received: from lab5.biblio.uniroma1.it ([151.100.76.71]) by mx2.foretec.com with smtp (Exim 4.24) id 1DXagn-0002Rj-Az; Mon, 16 May 2005 04:11:08 -0400 Received: from chajaily.toadis.tortis ([98.138.104.199]) by gt1.optu.br (InterMail vG.3.29.80.00 202-2136-461-20040331) with ESMTP id <94381101151738.QLSU3396.gx4.fuse.net@optu.br> for ; Mon, 16 May 2005 05:08:58 -0400 Message-Id: Date: Mon, 16 May 2005 13:04:58 +0400 From: "Sean Goldberg" To: rtg-dir@ietf.org X-Mailer: InterMail vG.7.80.07.50 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: imrg-admin@ietf.org, p2prg-web-archive@ietf.org, policy-admin@ietf.org, disman-request@ietf.org, mmusic-admin@ietf.org Subject: Re: Rolex Order Details - dear editor X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.2 (++++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Rolex : $129 Cartier : $119 and more ? http://personalwatches.com/index.php?ref=news no thanks- http://octet.untowncjaad.com/patina?AjCF6R45F8HtmA4debug From rtg-dir-bounces@ietf.org Mon May 16 14:18:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19838 for ; Mon, 16 May 2005 14:18:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXkRO-00072P-Ud for rtg-dir-archive@ietf.org; Mon, 16 May 2005 14:35:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXk9j-00066B-JR; Mon, 16 May 2005 14:17:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXk9h-000662-Kx for rtg-dir@megatron.ietf.org; Mon, 16 May 2005 14:17:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19746 for ; Mon, 16 May 2005 14:17:27 -0400 (EDT) Message-Id: <200505161817.OAA19746@ietf.org> Received: from mirail-4-82-227-181-103.fbx.proxad.net ([82.227.181.103] helo=jorn.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DXkQG-0006zJ-Pl for rtg-dir@ietf.org; Mon, 16 May 2005 14:34:38 -0400 From: "Lucretia Shipp" To: "Rube Chow" Date: Mon, 16 May 2005 14:17:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C571FD.4288E3B3" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: =?iso-8859-1?q?Re=3A_V=C0LLIUM_V=EDAGRA_CIAL=EDSS?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C571FD.4288E3B3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Words, is it? said Peter Blood. Oh - not guilty. And he wen closely. This thing that Blood believed, that prompted him..., t Glad, above all, for your own sake. She held out her hand to hi No need to ask how he came in this state and by his wounds. A Indeed, but there is, Cahusac insisted. Don Miguel, the Spani at mademoiselle, and observed the grey despair that had almost great force to harass the Spaniards upon sea and land, and to kee Agree? Blood laughed. If I should be caught and brought back and daughter shrank away in renewed fear. Mr. Blood, at the head corner of those hazel eyes she scanned this fellow very attentive Surely, Blood agreed. But it asks more than courage. It asks pieces of eight, which we are to deliver to your excellency. Have a nice day. ------=_NextPart_000_0008_01C571FD.4288E3B3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hello, = do you want to sppend Iess on your ddrugs?
     
     
    Save over 7 0 %  with = PhaaramcyByMAlL SHOP.
     
    Have a nice day.
     
    Words, is it? said Peter Blood. Oh - not guilty. And he
    wen = closely. This thing that Blood believed, that prompted him...,
    t = Glad, above all, for your own sake. She held out her hand to
    hi = No need to ask how he came in this state and by his wounds.
    A = Indeed, but there is, Cahusac insisted. Don Miguel, the
    Spani = at mademoiselle, and observed the grey despair that had
    almost = great force to harass the Spaniards upon sea and land, and to
    kee = Agree? Blood laughed. If I should be caught and brought
    back = and daughter shrank away in renewed fear. Mr. Blood, at the
    head = corner of those hazel eyes she scanned this fellow very
    attentive = Surely, Blood agreed. But it asks more than courage. It
    asks = pieces of eight, which we are to deliver to your
    excellency. =
    ------=_NextPart_000_0008_01C571FD.4288E3B3-- From rtg-dir-bounces@ietf.org Mon May 16 15:17:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27100 for ; Mon, 16 May 2005 15:17:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXlMD-0001Eh-2r for rtg-dir-archive@ietf.org; Mon, 16 May 2005 15:34:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXl15-0000YY-E1; Mon, 16 May 2005 15:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXl13-0000YN-SQ; Mon, 16 May 2005 15:12:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26199; Mon, 16 May 2005 15:12:36 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXlHe-0000xM-3f; Mon, 16 May 2005 15:29:47 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DXl0z-000Ptr-TM; Mon, 16 May 2005 19:12:34 +0000 Date: Mon, 16 May 2005 12:12:23 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1248288282.20050516121223@psg.com> To: rtg-dir@ietf.org, l1vpn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Subject: L1VPN charter: rev 02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit This is the version I'm hoping to put on the next IESG telechat agenda (next week). Please speak up by Fri, May 20, for changes. Only major issues after Wed, please--I'm putting it on the agenda then. // yeah, we're still working on the WG chairs part... -- Alex Layer 1 Virtual Private Networks (l1vpn) Last Modified: 2005-05-16 Chair(s): TBD TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Technical Advisor(s): TBD Mailing Lists: General Discussion: l1vpn@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html Description of Working Group: The L1VPN Working Group's task is to specify mechanisms necessary for providing a VPN service over a GMPLS-enabled transport service-provider network. The following two service models will be addressed: 1. Basic mode: the CE-PE interface's functional repertoire is limited to path setup signalling only. Provider's network is not involved in distribution of user's routing information. 2. Enhanced mode: the CE-PE interface provides the signaling capabilities as in the Basic mode, plus permits limited exchange of information between the control planes of the provider and the user to help such functions as discovery of reachability information in remote sites, or parameters of the part of the provider's network dedicated to the user. The WG will work on the following items: 1. Framework document defining the reference network model, L1VPN service model, fundamental assumptions, and terminology. 2. Specification of the L1VPN signaling functionality between the user and the provider network to support the basic mode. 3. Specification of the L1VPN signaling and routing functionality within the provider network to support the basic mode. 4. OAM features and MIB modules and/or extensions required for the basic mode. 5. Specification of the L1VPN signaling and routing functionality between the user and the provider network to support the extended mode. 6. Specification of the L1VPN signaling and routing functionality within the provider network to support the extended mode. 7. OAM features and MIB modules and/or extensions required for the extended mode. 8. Applicability guidelines to compare the basic and extended modes. At this point the WG will address the single-AS scenario only. The multi-AS/provider scenario may be considered in future. Protocol extensions required for L1VPN will be done in cooperation with MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. Where necessary, the WG shall also cooperate with ITU-T through the established IETF process. Milestones: Sep 05 Submit first Internet Draft of L1VPN framework Sep 05 Submit first Internet Drafts of basic mode specifications Dec 05 Submit first Internet Drafts of MIB modules for basic mode Apr 06 Submit basic mode specifications to IESG for publication as Proposed Standard Jun 06 Submit first Internet Drafts of enhanced mode specifications Aug 06 Submit MIB modules for basic mode to IESG for publication as Proposed Standard Dec 06 Submit enhanced mode specifications to IESG for publication as Proposed Standard Dec 06 Submit L1VPN framework to IESG for publication as Informational RFC Aug 07 Submit MIB modules for enhanced mode to IESG for publication as Proposed Standard Dec 07 Recharter or disband Related Documents: draft-takeda-l1vpn-framework-03.txt draft-takeda-l1vpn-applicability-02.txt draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-06.txt draft-ietf-ccamp-gmpls-overlay-05.txt From rtg-dir-bounces@ietf.org Tue May 17 22:31:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16267 for ; Tue, 17 May 2005 22:31:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYEc5-0003HL-2e for rtg-dir-archive@ietf.org; Tue, 17 May 2005 22:48:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYEJW-000432-FB; Tue, 17 May 2005 22:29:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYEJV-00042f-85; Tue, 17 May 2005 22:29:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16103; Tue, 17 May 2005 22:29:33 -0400 (EDT) Received: from d36-94-236.home1.cgocable.net ([24.36.94.236]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYEaD-00039Y-7N; Tue, 17 May 2005 22:47:02 -0400 Received: from pundit-dns.myway.com (253.112.137.186) by ocn200-esd38.myway.com with Microsoft SMTPSVC(5.0.2195.6824); Tue, 17 May 2005 20:21:24 -0700 Date: Wed, 18 May 2005 05:27:24 +0200 Message-Id: <72365659383276.rz5QrfPQC878@bess91.gun10myway.com> To: rtg-dir@ietf.org From: Beryl Lackey MIME-Version: 1.0 Content-Type: multipart/related; boundary="34rc3xdw" X-Spam-Score: 4.0 (++++) X-Scan-Signature: e9eeacd7fe925d5f7faae01ed8f85b97 Subject: casino directory.yywtg X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.0 (++++) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 This is a multi-part message in MIME format. --34rc3xdw Content-Type: multipart/alternative; boundary="w45twfrdxf" --w45twfrdxf Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Get a capable html e-mailer Fun and Excitement Best Online Casino --w45twfrdxf Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    <= o:p>

    Fun and Excitement

    Best Online Casino








    kewl, but no thx

    --w45twfrdxf-- --34rc3xdw Content-Type: image/gif; name="pic.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDABsSFBcUERsXFhceHBsgKEIrKCUlKFE6PTBCYFVlZF9V XVtqeJmBanGQc1tdhbWGkJ6jq62rZ4C8ybqmx5moq6T/2wBDARweHigjKE4rK06kbl1upKSkpKSk pKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKT/wAARCAE9AfQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDpqKKK ACkPHWqtxfJEDtIPv2rHu9WBJwS31PFS5pG8KEp6m+08SnBkFN+1wf3/ANDXJtqFxKcRqT9BRuv2 5xgH1IqHUsVKnSh8UjrPtcH9/wDQ0fa4P7/6GuTxf/3h+dGL/wDvD86XtV3RH+z/AM51n2uD+/8A oaPtcH9/9DXJ4v8A+8Pzoxf/AN4fnR7Vd0H+z/znWfa4P7/6Gj7XB/f/AENcni//ALw/Oms14gy8 iqPdsUe1D/Z/5zrvtcH9/wDQ0fa4P7/6GuOluLmFQXlUZ6YOc1CNRmLbfM/HtVKTexSjRf2jt/tc H9/9DR9rg/v/AKGuL+03jSmKLLsOu3kCns+pIMnDY6hWBP6GjmY1TpvZt/I7H7XB/f8A0NH2uD+/ +hriVvbqVljjf52OMelTG3yQJb2Rn9jx+pp8zW4KlGXwXZ15u4AMmTA+hqNtTsl+9cxj6muNmhdZ oo5JnkhZu5xip0trMnCoHI9XJ/lRzgsO5OyX4nTtrWmr1u0/DJqdL62kQOkoZT0IBrkJDZxZUxxh se5/maisDcmEiFvlB9aTnpcmVONN++zpZfEmnRsVDvJjuicfrUR8VWGf9VcH/gK/41iaaSLY4wDv I6fSnwX0kszRfMMA/wAVNz8io4dNJuVrm5L4ksliR4hJK7fwAYI+tQf8JJIfu6ZMT6ZP+FYbqqal EVG3J5x61YuJLhceTG0meuATS5+w1h173M9jT/4SWSMg3GmyxJ3bd/iBUlx4jQyGOwt2uSOrdAK5 y6e58rE0JRSeuKtswtLMBR0AJ9yabk0hRoxlJ2eiNJfEN3Ed11YfJ3aNulX5tesI7VZxIX3/AHUU fMTXLR34wRMvPbHpRpqIZpJgvCY2A9if/wBVHM1uL2UJNKDvc2m17UGO6PT1VOwduf6VYtvEdu4d buJ7eRVJ2nnd9K56a+dZ2AAKqeaffKJLYP3HIPtS5n1LdCDT5XqjY/4SSZvmi0uZ0PRtx5/8dpw8 UQ+Vg2sonzjyh/j/APWrKgwLaLP90VDBHjUZH6BFLfnx/Wjn3B4bSLT3NseKIlI82znQdz6Uv/CV WXeG4x2+Uc/rWNfuTaH5jgkd6mt3ZLaIBmA2DvRz6XH9V9/kv0NseIdNMPmGYjtsKndTk8QaY5x9 p2n3Rv8ACuXgiB1GRmAKoC3P+fen6gF+zkhEBJHIQZ/Onz62M/q75XK+x1P9tabkj7XHx9akXVLF vu3UZ+hrlEigW1RpIkPyAk85qMjT2H3QPoxo5x/V3ZNtfedmLuAjIk/Q0v2uD+/+hrh7O3SZXZmc bWwu00STXFvKYVmcg4wScnFHNrYn2aUeZp2O4+1wf3/0NH2uD+/+hri7h7q0AP2reM4xzmnhtRKh gytuGcbhRzMr2Ub2d7nY/a4P7/6Gj7XB/f8A0NcVJd3sOPNDKD37USX00bAGUE9eOaOaQclJbs7X 7XB/f/Q0fa4P7/6GuLW9lbpOo+pxUyPdycpKjfRgalza3JcaC3kdd9rg/v8A6Gj7XB/f/Q1yeL/+ 8Pzoxf8A94fnS9qu6F/s/wDOdZ9rg/v/AKGj7XB/f/Q1yeL/APvD86MX/wDeH50e1XdB/s/851n2 uD+/+ho+1wf3/wBDXJ4v/wC8Pzoxf/3h+dHtV3Qf7P8AznWfa4P7/wCho+1wf3/0Ncni/wD7w/Oj F/8A3h+dHtV3Qf7P/OdZ9rg/v/oaBdQH/lp+hrky1+OoyB6EUn2yZDiQFT7in7S+xpCnRn8MzsUk R/uOrfQ06uSjvWznv7VoWurumA58xffrTVRdSp4SSV46m7RUVvcRXMe+JsjuO4qWtDkaadmFFFFA grN1C+CKQp+UfrVi+n8mLAPLfyrlr65Mj4HOeAKznLojrw9JP35bIS6u5Jn2gkk9BT4bEZ3THcf7 vYVJa24hTLYLnqasVyTqdInDisbKb5YaIRVCjCgAegpaKKxPO3CiiigAooooAr37OtnIUJBwOR9a qw2lsY1co7llBO5u/wCFXbhN9vIvqpqjbufsAYdVBrppP3dD1cuUJNqSIrSIJfMjKCFBIDDI/Wpt R+a17YBHA4FTIql/OB+8mMevINQH95YN3Izz+Na3u0z0lTUYyj3vYfFi3sAVHVd59yahtLuSSYJJ j5hlSKltyJ7MLn+Hafao7W1mWZDIoVI8/NnrT01uS3OPJybDZittfJN2YHOPpipylvcEOTkjoVbB FQXjxm6jWQbkH3hmpJbOKUIYCsWO4yc0dEPXmmkroivbcookWR2UdQ3UUtmqx3RCklWjyM/hT76R I4PKDbiQB9feo48W9zDvO0GLkn8aLtowqcsK8bCzRiTUUVh8rCtOGJYl2qAB6Csx5EkvoWjbdzg1 r1hWbskedjn+9dnoZlhwsq+j1NDceYXjX5Sp5Hr71V8/7JPcK6k7nyPpzUMcjidriNDtzyPrW9r6 nqUsRGNOGo4q6ajGHO4lxg/jVu6eZFXyVLEnnAzVWS5MrowibMbA8U/7dMDxCf1oabsEatOPMlLc iuPtbxZmhcIOclCBVyZftNp8nJYAiqss88ylDCefY05UurVRtXevXHXFD6EKvTjJqUrpoWGzaUFr gPEFACdjTrAqkk0e7dyCD61G091KNoi2574xTlsJUjEkbfvRyR60N6asz9tRoyjyjZrWczOI4i6y dCO3+FT35EVtszngKMd6iNzdL8rQ5P0NRtBc3OXYYwOBR2uXKtSgpOL3LEjbLKBv7u01NcERRStj kjBP0z/jVGRriSJYTAQFAHQ9qJpZ5YxEYWBGOx5osaLEwSevRfeTXnFlGP8AZX+VSO2yK39PkH6C qlxM88axiJhjHai4uTMioEKlcfpTsL20Ltp9EXpisMcsgHLYz+Gf8ag1D5baNT14/lUN3diePaoI 5yc0X1zHOAEzwe4pKL0LqVYtSUX0LsjRx26+YMoFUEY9qqyvYtExSMBscct/jU73NrJlWIK++RUM qWRiZkGCAcYY/wBaFpuVU95e7Z6EmnfLaFj3cn9BT5IhO8Ei84YH8M0yBlTT1+YZIJx+NN06XdGY z1Xp9KT3bHBpxjTfVDdTOSi9zzirF7IYIyUIyDjmoLkb7+FPcdPrUt9FJOqiNcnOTzT7IG3epJCx P9ptSWXg5BFRaYNqTN7heR9f/rVKF+y2YViNwBJwe5ptj8tnuPdixpbJ2GlzShzb2GvcWhcrJEmc 4J24/lUISGW9SOHKow52n2yetSfbLZ/9ZCp9yozTbAK13IyjCqpxj8qpaIwlacktHd9CcWrp/qrq RfY805Lma3lWO5KujcB1qpeTOt18hIwKsamAISD1DcVDje1+pNXD0ZqVlZo0qKjt2LQRk9SozUlc TVnY8FqwUUUUCCiiigApCARggEehpaKAKstmOsXyn07VACyttYEMK0ainhEq9PmHQ1rGfRnqYPHy ptRqbEdtdy20okjOCOo7EV09ndJdwCVPoR6H0rkORkMMEcGruk3htLxQxxFJ8re3oa6ISs7Hr4mi qkOeO51NFFFdB5Bg6xcZkfnOPlFZNlH5krStyF4H1qbUZN2Se5zT7NNlsg9Rn865KkrJs6cbL2VB QXUmooorlPCCiiraW4NvtOBI3zCk2kXCDnsVKKDwcGimQFFNYkKSBmooJWdiCuOc801FtXHbS5PW VaskSzxMwG1z1/z7Vq1UnsIZZDIQQT1wetaUpJXTOnC1/Yz5ilbXSRwmNycqSB9Kjhu1jhdCpbcx P51de1t4VwYwT2z3qxFFGVG0ADtxW7qRSvY6njpJKy2Mu2huVj82IdTjae9PMt43y7MfhWsFAGAK Ni+lZ+311RzxxlSKsnoZ1tY7txm+Zmpr6a6nCSkL6GtTAFIWUKWLAAdTmp9tK9zH2073TM+DTwrB nJYirktrFMgEig46U1r22XrMv4c1G2pWw6MzfRaG6knewN1JO46Gyiifcq4P51aqj/asH9yTHrgf 41cRg6hlOQRkVM1PeRE1LeQjxq/3gCfcULGqjAFPqnLeMZTDbRmWQdT2FKKlLRBGMpu0Sz5a5zR5 antVMi/PJmhT26/0NH2ue3YC6QFDxvSrdKfRm8sLWirtFzy1p2BjGKFYMoZTkHkEVReW4nuJI4JV jSLgkjOTURi5uxlTpyqS5Y7lzy1znFOAx0rOlF5HGXF0rY5wF/8ArVctZvPt0k7kc/WnODir3KrU J0vjJCintQFA6Cqs91I0xgtVDOPvMei1GYbk8tejP+ypxVKlJrV2Lp4WrUV4ovFQTRsX0qg0l3aj ezrPGOvYipJr0mKH7PgvMcDPb/OaTpST0Jnh6kJKLRb2LmkMamqTSX8aknySBznIpE1CaUIsUIaQ jJ54p+yn0HLDVYtJouGBCc4H5U37LFk/u059qrteXMQ3TWuE7kGrE11HFCspyyt93Hek41ERKnUg 7MifT4G/gH4cVGdMiz0I/Gnf2nGPvxSL+FW4pUmjDxnKmm5VI7g3UhuUG0tM5VmH60PpuAGikKED njrV2S4hiOHkVT6Z5pEuoHOFlQn0zR7SpuCqVFqZ32K5DCQSAuvTNBa+Q4Kgj2xWvTSoPan7d9Ua xxlSOzMd47q4B3DAHb1p8N4kUSRMjAoMH881qhQO1NkhST7yg/UVXtk9GjSGOnGXMzP82xcfNGn5 bf5Umn7F85gQMsAoz25/+tVltPhb+AD6cVG+mRnlSyn2NX7SDVrm8cdDmUnHYQWkZuPPeQkA7tuP 61DeyefKsKHJJ5NKdPlHAmOKsWtkIju6n1NNzitblVMZDlagty3GNqACn0lLXEzxwpUUuwVRkmkU 4IOAcdjVmSTEQkiVVB+U8cg/WpbLjFPVkU8XlNgHcp6Go6ntmJ+Q7Si/Mdwzio5nV3yiBV7UJvYc krcyGUgIYZHSmyqWQhevamQRmPIYk+lXZWuRbQmooopCK11HghwOvBqs/wB2tCRd0bD2qjIMZreD uj6bLqvtKHK91odXps/2mwhlJyxXDfUcGiqPhyQfYHDH7spA/IH+tFdqehwTVpNIxL77oq3F/qk/ 3RVS96Crkf8Aq1+griq7FZptEdTowjOA5Kg9xTaKwPHTsy3JHb25G5XfPI9Khe4ZpxKO3Qe1SQt5 lrIr8hBlfaqx4UseFHftURXc2nLRcuiZbX7PcOQEcMeSRUE6Ij7UYtjrmpEcJYh4iMucFh+NZTag GYrbwvMR3A4qqcJSbsVJOSSS1LnWjAHQVmz6jPGGRohHJ1GT0FP8iZ/9beN9Ix/+qt1Rl1diqeEq zdkjQpGYKpZjgAZJqlpsrt5sTsWKHgnrirNyu+2lUdSpqHHllys55Q5ZcrKkmoQSHaqSSY9BTTqQ ijK+SyyDorelSWMrG0jAYgDI4PvVG/G24YgfeFdSpxvy2PUlgoxpqd7l4/2gx5eGP8Qf8aLe8dkl jkAEyKSPenxtujRvVQf0qC7gLgSx8SL6dxU8sXpY3q4CDp3huMt7eO4hEszyszE5AbA61VuFWGcx rny+CQT1q5prZtiPRj/Sq2pDE4PqK1T96xU6cFQUkjR8mBT8sEY+oz/Ok82JOnlL9FApyncit6gG qR01mct5yAE5xg5H6VC13Z1TXIk4RuS3d0kluyedn0Gas6e26zj9his6awEMTP524jsE4rTsyGtY 2AxlegqK1uXQ8jHuTtzKwl/MYbVmX7x4FR28Qt4BGOpALn1P/wBamat/qYx/t/0qaT+Lv1pU9Iep 0ZZBWciq9/Gkm3BIHUipnaOSI7mGxh61W0+BZ1l3gHJwai8iAuUN1kA9+P1rT3b27FLHu8lJXLOn T7IZkJysXzA+1OsVItt7fekYsf8AP50y5jW3s9kQ5lYD61YcCKHaDwi4/Klpq11JwEVKpKothQVd eOQeKr6bIYvPhP8ABlgP8/hSafJviYHqrZ/P/JpGPkajHJ/C/wApocdHE2xi9tQU0P0//j2ZurO5 LH1qO7muIpMov7v1xTVf7FO0L8xk5U+lXI5VcZjfP0NU3rfoa0XGpRUYOzIReQlRluo5FUrY5vI1 U/KHyP8AP4VfuLaOZSdoV+zDj86p2p/0qFCoBQnOO9ONraGdf2nNFSXUvXBxA/0qlpnM7eyH+Y/x q3d/8e0n0qtpgxJIf9kfzpR+FmtbWtBF2RBIhRuhGKzg7borZuqS8fia0twDBc8npVeSHN7DKB/F z+FKL7jxNJTSl2LFxKwhkO8gYPeqFrJK0K20HDMSWb+6KtXhxbP7jFRaYm2B5O7Nt/Af/rpq3Ldm eIpKrVjBkyWlvH/B5h7s/f8ACh7a3cYMKr7rkGoL2Vw6xRnBaktjLDcLDI2Qy5FGtr3KcqMZ+ysP jleymWN3LQNwCf4as3N35cghiQySt0HpUF8u62b25pumjMckpOXY7cnripcIy95nHVwUXXSWzJD/ AGgeTJCp9OuKPtV1BzPEHT+8nao7u5eBl2plT3NTxuskYbjDDpQ4q2qNngqEm4LdFmKRJYw6HKmn 1naadlxNCD8vUVo1zTjyyseHVh7ObiFFZflLd3c7SM+1CFXacf56U2bzLPa0dxIwJ+6wrT2N+up0 LBzdP2i2NXNLVaQSmQFScD2pbi7ittokLEnsBWfI3axy8rexYqZZlWEJ5YYg556VQjvraTpKAf8A a4qxUSi1uhrmgywlyMkvGvIxleKgoopJWFKTluFFFFMkKKKKABfvD61SuBg/hV5fvD61Suev4VtT 2PcynaRpaB/x5yf9dT/IUUaB/wAecn/XU/yFFdi2IqfEzLvegq3H/q1+gqpe9BTZ3ed47SNto2gy N6CuaUeayLzCDqOEUTTX9vEcbi7eijNR/wBpoOWikVT0OKkjWO3XEShAP4j94/U0qzbwcSbvXnNH JBCjlit7z1JXvlGkzvbyAuSMeo6ZqiltHNGkk0sspIBwWwBUd5CIszRDAPDqOhFSae+62A/ukj+v 9auMFBNxLoYdQqezmvQQSSWDMBlrWQ8r12mjT3IjkiDEhWyOeoP/AOqrLKGUqwBB6g1Vt4Tb3RUZ KOvB96as0+50ew9lVU47Mi1NcOjeoxVy3bfbxt1+Uf4VDqK7rfP900ac263K91b/AD/Wm9YFR93E Nd0Os1I1V41H316dPetlkjaPylILqM5zwT3FYr4j1K2dvukhT/L+tabbImUzyIgyMhmAP5VzVldp nk4uHLVdluZliDGJYT1jkIP+fwqLUVO+Nh1PFTJJG2pXPlEGNvmGOn+eaZqK5gDf3TXSn7yZ6Uff wxLZtutY/YY/WnrKrSNH0Zag04/uGXOdrVDes0V0si8HH50ct5NGqq8tKMi7HEsZkK/xkHH55qnq Y5Q/UVchlWaMOv8A+qq2pDMKn0NKPxajrJOi+XYsWx3W0R/2QPy4qrcXkkczRgLx3qawObRPYkfr UpghZizxKzHuc/40aKTuFpzpR5HZmbJdSyKUYrtNamnsn2VQrhscH60nlwr0hiH1QH+dVtOO2adf fI/WlNKUdDzMbRmo803cn1Qb7QkdVINOjcSRq4/iGalYBlKnkEYNZys9i5jfLRE/KaUF7thZfWjT bjLqKguLZ5UjhaQSfdKjpU8VpEluscsas3Vj3B+ooF5BjPmAVBcXq7dsXJPer16I7lToU253vcjt o1a/Cpny0JbBOelaDFcfNjHvWdZzJbGQyZ3HA4H5/wBKLmcXTIiA9aqSbYqVWFOm5dX0NBWjHCCN c/3VAz+VV9QTdBuHVDmq7wG1McoJIDDNSvfROhUq2CMVNtbrUcMRTq02noOtba2kt0dkLMRz81Vp 7d4pz5asFP3doz+FFrO8C5KkxE/rVtdQiHQsPwqveTIiqM4JXsydAyxr5n3to3fWqFuQ2p5Hqx/Q 0+e+3jZCDk9zUUOLW5QynHykn8c0krXKq1ouUYp7Fy94tmqHS+fNPso/n/hSXdzFJAVRsnPSksJY 4kkEjhSSP0oSfKypyi68WnoOvpTFNEw7c/WrisGUMDwRkVQuis9zGqtkHjIqWykKq0MhAZDgZpNe 6iqdZe2lDuO1A4tj7kUth/x6L9TUepMPJUDnJpLR/JkeB+OcrR9kHNLEpPsDj/iaJnpj+hqZsPqg 28iOM5/z+Ip01vHPjfkEdGXqKdDDHApEe4lvvMx5NK63MpYWTxHtOhFfNi2b34qraTiA7HIKtg5H Y0uoTByEU5C9atLa2zRqRCvIBzub0+tUrKOpcuada9PoTAhl4wyn8QaqXVmu0vDlSOqg8GqqmWCb Ym7duwF9a1n+XdntSd47GkXGumpKzRX0qJdplDEk8HPatBiFUsegGaztKYDzQPuluKtXsgS0lIP8 OPz4rnqJupY+cqpupYq6eD9nLnq7k/5/Wo7n95exR+mCas267LaJf9nP58/1qvB+81J2/uiuhvVs 9yu/Z4ZI1F+6KoA79UkftEmAff8AyTV/oPpWfY/Mk0x6ySfy/wD11hRW7PMwEOasN1AIICdibieo UA0sNxO6LBbKMxqA7t0FQ6kxLIg7DNWrNQlpGB3+Y+5rdpcqbPSqUY1q/L0Q3Zeg5F1GT6Y4/lSr eywMFu4wAejpyKgnupYZ8MvydvcVblUPGyHkEVLiuqJlg6NRNQ3RO08ShS0qANyMnrTwQwyCCPUV j6fCs29pV3qgCgE+9WDZIrboZZIT7HIrN0UtLnDHL5zjzRNGiqAa+i6FJ1/I05dRQHbPE8Te4qHS kttTmqYapDdF5fvD61Suev4VcjYNtZTkHBBFU7nr+FOnsz1Mp+0aWgf8ecn/AF1P8hRRoH/HnJ/1 1P8AIUV2LYip8TMu96CorI7prhj1yF/Dn/Cpb3oKii/dXrIekiBh/n86yWzO6o0q0LjdSZhGoHQm oABayJIrHBOGFW72IywHHJXkVWaaN7EqceYSMDvVRehy4tyhVUkaDruRlPcYqjprbZJIz6Z/L/8A XV4AqqhuoAz9cVmQPtv89ixH50orRo660kpQmXbqVoQkg5GcMPapY5FdQ6nINR3ab7dx6DNUraR7 dVkwTExwfY0kroqpW9nUtLZl+4XfA6+1U9Lb55E9QD/n86ttcQhclxg1mwSiC4MgBKjIqoptNGde UY1Iyuac0CT7Q5YYOfl601bS1TpEW/32J/liqxv5G/1cX9aQveSeqiklJCqVsPfmerFUCLUwAAqn jA6dKnvGRrd13DPpmoEspJDulc57GnDTlzyzGm2r7nJ9chFSiloyKxuEh3hicHBpZ5luJ4vLByD3 FXvskWwKY149qWO3SM5VQPoKlzV7nO8Y/Z+z6FR0ltJS0Sbo27Y6Go5HuLhdhjwCfStTHGKTYPSk p+RnHFzUOS+hnCC6iUrGw25yOaT7PdN96Q/nWnijA9KPaMn6zUta5mCxlPWQ1btLYQZPJJ6k1Zop ObehnKrKSswprorrhgCPenUVBmVGsISeFx+NOjs44zkKPxqzRVczK55dyJ4I3+8ik+pFIluiHKqB 9BU1FK7FzMTAIxURt4yfuj8qmopXsJNoYIxtxjioms4ic7F/KrFFNNoak0QJbInRQKe8McgwyKcd MipKKLsOZlX7DFnOwUstnFIclPm9RVminzPuPnl3KsNnHE+4Dntmi5s0mbeCVYjnHerVFHM73Dnl e5nLp53Dc5K+lWLm1WdB2cdDVmihzb1G6km7maTew8cOB3prPdy8Y2itMgHqKTaPSq5/I6PrlS1r lKCyAjYPyWGM0yK4a2/czqfl6EVpUySJZBhlB+opc99yaOJnTlzIhW8h6iUA/wAqrXN4HXy4cknv UzafETwuPxp8VokfIFVeK1OueYNxslYLKLyogD1PJpmpEmFIx1dsVbAwKq3scrNFJENxjOcGpi7y uzz4NOabLDAAkDoOB9Kppb3MEjSRNE5Y9Dx/OmfbZkP7yH8akS/iP3gy1dmuh705UK8eVsWe9uI4 mWaDaWBAZTxmpbVdlrEv+zk/jzVK9lWd41jYEGtByFBK/dA4/Ck0ktERhaMKdSXJsZ0sifbWMhO0 Arx9Mf1p9ndKgETngH5WqOxb/TQxPXdz+FW72HzITsjUuPRRk1btsyacZtyrRfyJ2CyIVYBlPas6 6ha3YNG7bD69qk07zCzj5vLUd+x9P51JqJH2fHfNSrxlY2m41aTqbMgSG5hjLxN8nX61bs5Hlg3v jJJAxSzyeXpYyfmKhafEnlQRx/3V5+p5P86nm5k2zlwE5zk7vRDXnjjcK7AE+tQX82YQiNu3HoOa iWMXd4+fugVoWmjorC4kZvLQ5APrQ5Rhq2VVxl3KmTWyeXHGh6rgVWuev4VrTxghJo/unGaybnr+ FYU5cybDLYuLmmaWgf8AHnJ/11P8hRRoH/HnJ/11P8hRXatjGp8TMu96Ci9hZoIpoh88YB+ooveg q0hAjX6CuaTas0VmMnFwaKlvcJOmRw3cVIEjV94iTd13YqG4sldy8RKMeuKrm0nPBkJFaKz1TLjj 4Siudak93dLGpCkFzSwWDzaW3lDdcLIH298UyCxCtub5jWpYgi5QAkc1E5csfdOatinUmjGlmuyx VozH2IIxipLSJzC0JwVbk+1at9bm4vmwC2MDA+lRG0ktpA20qPzFCqppdGY1q0579COPRYkiM0xb b2XPNCxIo2qgVfQCtHUiSYzn5SOBVKs4TlNXbMqsnflGeUuc4pQoHamPLtcLg+9S1Zk7iYpaKKQg ooooEFFFFABRRRQA+3iaeZYl4LVMILZyFS9QseACpFLpf/H/ABfj/I1XtoRJZbppo4oBLySPmJx2 /Criro9DC0KVSEpVHawSRtFIUcYZTgipYrdDD500yxIW2gkE5NR3FwLm5klAIDHgH0qSfnS4h/03 /pSSVzHD0o1Kyg9hTbRtG729wk2wZYAEED1qvVyFJI7y7jkINz5RCEAAMPp61SHSiSsPFUY0pJR2 LTW0MR2z3axvgErtJxTJ4BEqOkgkjkB2sBjp1p96ypqzlpvJGwfNs3dh2p16Q9vbOknmLhhu27cn PpTaVmb4jDQp0lOO+n9f0yC3haeTapAwMknoBUq28Ep2QXaySdlKlc/Q07TwD54YFlMRBRerfSmW UoF1bxwkTKTyrxDdGM+v60RS6iw2GhVpuT3K5BBweoqwtvGIkknuFi352gqTmoZcedJhtwDHB9ea muyFisCX2ABvmxnHPpSSMcLRjVq8khJLdBCZYZ1lVTg4BGKijQyyKi9WOBVqV1k059k/nbZAWOzZ gfTvUNl/x+Q/7woa1Jr01CpyrYmWxVy3l3CMI/8AWcEbf84qCeERBGWQSI4yrAYzTvKlX7VdQnO2 R0dfVTSTH/QbIf7LfzptKx04nCwp03KL7CQQCUOzSCNEGWYjOKkWC1dgq3qlicAbDyabZyvHOoXG HIVgRnIzUqN5MupSIq7kYbcjOOaIpMzw9KlOnKUk7oqyIYpGjbqpwcVKlughEtxOsKN93IJJ/CoN zOS7nLMck1cn8oW9o0jujAHbKq5C89CKSSbM8NSjVqcstiGaBViEsUqyxE43AYwfQioasiUvpkhZ VUeaArKgXfVaiSsTiaSpVHFBRRRUnOFFFFABRRRQA0op6iontY36qD+FT0U7tFKTRTbT4iDwQfUG oWsZVzslOD61pUVSnIuNWcepntZMsCmM/vEOfrRHfAfLMpVh14rQqKWBJfvKD9aFO+5vQxc6TIWv otvLlsdBVNna7mHHyA9KufYYs521PHCiDAUYquaK2Nq2OlUjYrXA824t4D0zuYe3+QamnfbG7n0q vcedBdtOse9SuB7VBcXfnRbApDE9KaV0rHRhKkKdJ66mlokaR2zXEsW/e3B/z71curwGPbtCAdga NGyIvIYApt6Gq9xGryFR90McCuSSUqjuedUk2rp6Mt21ztGzAdSfyqRYra6Vme32AfxZwKqW+EdF bgAjNP1iV4wsCfLGVzx3qHH3rI6sBzSvFMt6X9nEUotw2wSHknqcCioNA/485P8Arqf5CivQjGyL mrSZl3vQVOn3F+gqC96Cp0+4v0FYvYrM9ojqKKKk8cKns2VJw7kAAGoKKTV1YqLs7l2a/wAZEK4z 1YimRXzrxIA6n86q0VHsoWtYv2s73uW72WOaNDGenGPSqlFFVGPKrImUnJ3Y0opJyM5p1FFUSFFF FAgooooAKKKKACiiigYqO0bh0O1h0NLczz3WBPJvVTkDAAptFNNoak0IBjpUsV1PApWGQqD7A1HR STsJNrVEhvb0oUNwxU9emfzqIcCloptt7jcm9yb7feooVJyAPVQf5iopJ57hg08hcjpwBj8qSkzR zO1h87asOR2jYMjFWHQiny315IpXziAepUAE/jUWaMihNrYFJrYRRgYqdLy6hj2QylV9MA/zqHIp aE2hJtO6HS3V1cALNMWXrjAH8qaCVIIOCOQaTNGR60Ntg23qyZ768Z1bz2BXpgD/ACaiklmnk3zS F2HT2pM0tHMxubejAHByODUk91czp5ckpZPTAqOkJAoTaEm1sA6VLHdTwKRE+AexGRUW4etLSTsC bTugllnuHDTSFsdB0Aooopt3BtvcKKKKQgooooEFFFFABRRRQBDNIyEAD3qUEkZNGB6UtAwooqSC URSZKhh3BFJ7aAt9RIYmmkCr36n0qzcxRyR7oP8AlmdpAp11LKEDxyDym44HIqrBJIjgRHDNx9ay 96XvG3ux93+vkREetM8lN27AzWlcz7I/LbbJL3O3gVRrSEm1ciS5XZMuacVjEjswUAAc0puoYc+R Hk/3jVKipdNNtsaqtJJF5bqGYgTRgN/eFVtZKOInRgwwQSKjT76/UVXuev4U40kndHqZdebcn0NL QP8Ajzk/66n+Qoo0D/jzk/66n+QortWxFT4mZd70FTp9xfoKgvvuipkYBF57Cud7FZl9kfRTDIo7 00zJ6ipseRZktFQm4Qd6a10gGc07MfKyxRVJr5B3FPS7VkyDmnysfJIs5oyPWqayz3LEW8ZcDq3Q D8aikaWJvmmgyOwYk1SpstUWzSzSEgdazY70g4bj36inCSSebYsix4XdlulHs3cPZO9i/vX1o3A9 6ztjN92Vn9NkROaVftMUZaWGZY843lCBQ6ZTosvGVR3FJ56etUYVSXO8zNKz7ERGAznpVo6LesDt tGQ+rTg/ypuEVuylQHm4T1pv2pPUVDJYyWckcN3bo8sxxGxkOByBzj61cbw9dOCD9kT/AHNx/nSa gtWx+wRGbhQuc1XN4WJEas+P7ozT7nTGsp4IrmUPE4J+XI6dqv2VnNfx7gxtbPogj4Z/f2p2glzN 6DVFX1Mz7Yyf6xHT/eGKmF0pTIOa2f7BscYZJCfUuao3vh0xIZLJ2bHJifv9DWanTkxugjP+27vu hiPUA0n2t/8Anm+PXaadpZa6ntrN3kSP58hGwcgE1uf2DZnqZm9cyHmrnKEHZjVKJhefcEZ+zzH/ AIAaabt0YB0ZM/3hitmLSLJr2aB43YIqsoLnGDnP6irI0LTgc/Zh+Lt/jUurTXQfsUc+s08is0cT MqnBPamefP8A88//AB4VMkCjVPsJGYftJ+X27Cuh/siw/wCfSOqnOELaAqUTmBNOQCFGDyMyKKPN n/up/wB/FrebT7JNShhFrHtaJyRjOTlcf1/Orf8AZdj/AM+kP/fNQ60F0H7KJyj3UsZ+cL17OD/K riTBoiwOcehroBp1kBj7JB/37Fc/expFqd5HGiogCYVRgD5fShTjPZGdSmkrlcSXEiu8aDYp2li4 Xn8aZ503/TP/AL/L/jS2WHuYI2AaNrtcqRkHmux/s2x/58rf/v0v+FdKgilCPY403Uicttx/syK3 8qnt7tZO/NdX/Ztj/wA+Vv8A9+l/wqpe6BZzoTAgt5f4WTgfiOlJ00xSppmHNOsa5zUAFzNH5oCx xf35DgGmxxsbp0uhhYM7we5/wrd0vThegXt8u5W5ihP3QPUjvmlGCW4oU0tznmlkQkrIkoXrtB4/ TFTQXgZeeo7V26qFACgADsKoalpNvfxklRHNj5ZVGCD7+tU4JlSppnMfaJZGYRRO+3rtHSmG8dD8 8br9RRDHJHM1pKCC06xuB9a6ltC0xhg2i/gxH9aXIhezicwbwk4RWc4zhRmkN4V+8rD6g1a1a3j0 vUWFqhjRrfI5J5z6n6VrW+gWMlpC0sbFyiljvbk4570ezQezic/9vX8PWj+0E9f51o6lZw2F/aWt qZI0uWCyAOem4Dj9avv4btnzm5u/p5gP9KPZoXsomF9uQdSKUXsf94fnVnUNLi066tILeRyLl9jG QK2OVGRx71ck8Lo4O26I9MxKf8KXs0HsomeJ0IzkVG94inkin32kf2fNbxSXZaOUMWIXbtCjPqfW rFnpj3i7raCKC37SyruZvcCl7JEqiiql2jdCKmVwRkGrcnhbeM/bMP6iEAfoaz77TbzTELuRLDnH mL2+opOl2FKj2JfMXOM0vmL61Rht2nih8t5GnlJxGoHb6+1PfTtQjHzQ3H/AYg38jR7IPYmyGgNn GskuOdxA5J601DaMylS0RU5BPQ1htDfRgHyJ/wAYmFOSad2EaRO0mM7cYxWLw77lOL00Na9K/aWI IIOCMVBkGqEqzRHEk0CN/dLEn9KiW9ZTyQw9R/8AXq1SaViJUm3c1GYKpJ6ClrOa7LR8kY9RQl9j jdx7ijkZHspGkn31+oqvc9fwpkd6hZfmGc+tOnYNyPSlZrc9bLE1zXNPQP8Ajzk/66n+Qoo0D/jz k/66n+QoroWxlU+JmNqLkHFMdXjwst1Cp9BuJ/lUmpLkVZ8K3IW8kgfkyLlSeuR2/L+VQvhuaYpX mrlJIGc/K9zJ/wBc4P8A69Srpty5G21u2HfewSuxprOiffdV+pxUe0fRHPyo5WPR7iYbks0AyRmS bPQ+1JNod1ZxNdSeTIkZ3NGuTx36itm2u44tYmtBIjJN+8Tac4b+IfjjNabKGUqwyCMEGhzkmFkc 3p+ntqUDTCdYU3FQkcQ4/Go9U0SKwtBKs8jEuFOcYwfatnR7U2SXFuc7VmLIf9kgYpniQf8AEokI /hZT+tHNLn30DoZ1janUXaJSYrOH5Ts6ufStyGytYFCxW8agei8/nVHwwQdMOOvmNu+vFaN2XW0m MRxII2Kn3xxUVLylYa0GTWVtOu2WCNx7rXNazo5sP38LMbc8EHkpn+lbHh2/kvrWQTtukjbBOMZB 6f1rQuoFubaSB+jqR9KI81OVgepV0SXztJt29F2/lx/Sl1qLzdJuVx0Td+XP9KpeFZD9jmgbIaKT p6Z/+uDWzIgkjZD0YEH8alwtO4X0OCV/LmWX0KvXejkAjoa4BlZcKw+bBU/hXcabJ52nW8ncxjP1 xzWtaN7MUWZfikFIrWcDmOT/AOv/AErbHIBHINZviWPfpEh/uMrfrj+tXNOk83T7eTOcxrn645rJ wvBDuZPitD9mt5B1DlfzH/1q2441ijWNBhVAUD2FZviaPfpDt/cZW/XH9a04nEkSSDoyg/nQ43gk F9SG4vILaWKKaTa8pwgx1qesPxRC4W2u0BIhb5sdumD+lXv7a03/AJ+l/I/4UvZaJodzIuIhbeKo iBgSsHA+uQf1rpa5jVbu3udXsp7aQSBCu44PHzcV1FXUjdK4kzNZvL8QoO0ttj8Q2a0ax9XfyNZ0 2XsWKE/XA/rWzUShomO5zNzHs8VJ/turD8q6WsXUoj/wkdg4/iGPyyf61t1U43S9BIzZmP8Ab9uv /TFv5/8A1q0ayJ3/AOKptlz/AMsDx/31WxUyhsO5Wlv7SCQxy3EaOOqluRXO38sc+pXMsLh0KqNy 9CcU3XJEj1qYsuQQvb2pMqYTtAA9hWigoa9zCrN7Few/4/rb/r7X+Yru64Ow/wCP+39rpP513ldS LWxVub+G2uoLeXcGnJCnHGferVYGv/8AIX0v/roP/QlrfpjOU1yEf24IASPtXlhiPrt/pXVKoVQq jAAwAO1c9qi7/FViMZwqn8ixroqAKd1qCW17bWxQsZyRkH7tXKwNUJbxPp6AdFDfqf8ACt+gDmNZ jCeJrQgY81omJ9w2P5Yrp6wNTy/imwTgAJu/Vv8ACt+gDm/GCELbSjp8yH8cEfyNdEg2oB6DFZvi G3FxYoD/AAzIfzO3+talAHP6iPM8VWKdlQNj3+Y/0roKwP8AXeMe/wC5j/8AZf8A7Kt+gDD1I+b4 m0+E/wAKl/5//E1uVh8TeLveCD/P/oVblAGBq8P23XrO0b7gQu/0zyP/AB3H41vAAAADAHQCsm3/ AHvia6ftDCqfng1r0AMEsbSNGHUuoyVB5A+lK6K6MjgMrDBB7isHRCBrWpvK4DeZgBjjIyf8BW8J EPR1P40AcxoEO3W5IuStsrhSf97H8q6muf8ACoMsl7dEYEjgD9Sf5iugoAK52/ilv/ELW8LlBHEF kcfwg8nHucioX8S3f2pljit2i3MFODkgdOc1o+Hy06XN9IoDzydumAMD+tAF600+1s0CwQqp7sRl j9TU7oki7XRWHowzUd3N9ntZZyM+WhbHrgVT0C4ubvT/AD7lwzO7bcADA6Y/PNAFDXdCgFtJdWi+ UyDcyD7rAdeO1QadaLrEkvmSSxxQqgTyyBnOTzx9K3NXcJpV2WPHlMPzGKp+FofL0reTnzJCR9Bx /SgCCXwrA33LqVT2LAH/AArJmjMFxPbmUSiI7d+3GTjkY9q7C5mW3tpJm+7GpY/hXHAN5QZzl3y7 H3PNZ1NjswaftDX0D/jzk/66n+Qoo0D/AI85P+up/kKKa2MKnxMy7/lRVGOVrK+inX+AhsevqKvX 33RVS+j/AHasPSog+hvjXaUTukZZEV0OVYAg+orC8VWZlihuEUkoSjbVycH/APV+tJoeqH+zkiZd zRfLnPbt/n2rQ/tL/pn+tZ86jI5bNo43ZcW7LOI5E2NkOVIGe1dxp12t9ZRzrjLD5gOx7is7VLtL zT5oSoyVyDnuOaoeG70wC4TG5SVYDPQ45/pVualG/YLO9jqazvEK7tFuB7Kf/HhTv7S/6Z/rUdzd pc28kEkXyuMHms1OKe4+Vmd4Qm5uLc+zj+R/pXSYritImbT9WAYZ6xt756frium/tL/pn+tXUlFM STZj6ARZ61dWrHCnIGe+Dx+hrpDPCpw0qA+7CuP1ZI59TlkdjEHUMMLuyelUzanHyJcN9Yf/AK9X aMtbiOh0plh8RX0KsCsg3gg8E9f/AGY1vVw+lSPY6lBJJGy5JXDDGcjFdT/aX/TP9aibimNJs5XV YvJ1O4TGMS5H0PNdJ4Zk36Si5yY2ZD+ef61ga8/m6g8gXG9Afy4q74cvvIjni27huDjn1H/1qqTT hcSWtjd1SPzdMuUAyTGxH1AzVbw3J5mjwjupZf1p7aiGUq0WQRg81leHL029rLAU3FZM9fb/AOtU KUXFjs7mzrMfmaTdL6Rlvy5/pVTw3frc2KwMw82Ebceq9j/SpZ7/AM2CSPy/vqV6+tcjAzxMk0dw kUi8gjOR+QqoWmrITTR6AyhgQwBB4IPesDU/Dw5nsAFbqYj0P09KbY+JQ4EdyiiQcbwcBv8ACtL+ 0v8Apn+tS5cj1Ha5xh3RvJuUqyEZU8EEGvQhggEdDXK+Igk6i5SPY4+VyP4h2z9K17fU828R8vPy DnPtTlOLSYKLKXi4FY7WRThlc4P5f4VvQuJYUkXo6hh+Nc54juvtNnENu3Eg7+xq1pGpn+zYFKbi i7c59P8A61DlHkTCzvYt6jHnUdOk/uyMv5r/APWrQrKuL3zGgbyv9XJu6+xH9am/tL/pn+tQ5x7j 5WZ07j/hMYAT91Mf+On/ABroK5GS6z4mFxt6MBtz/s4rf/tL/pn+tVOUVa4kmPudIsbuYzTwb5Dw TvYfyNc7dwR2uoXcEK7Yk27VyTjK5PWtW48QCCbyvszucZ+U1kzzG6uri68toxIF+VjzwMU76GdT axVsf+P6D/r6X+dd5XBWRxewf9fS/wA672t0NbEE1pBPPFPLGGki5Qknj8KfPL5MTSFHfaM7UXJP 0FUdQ1JrPULS3EYZJ22k55HIH9a0qYzkrS7a/wDEUNwRt3OQqf3QFNdbXP3MCw+LbV0XAlUsceuG B/pXQUAYN6N3i6yHpF/8VW9WBcHPjG1B7RH/ANBat+gDBu+fF9mPSI/yet6sJvn8YLwP3cP9P/r1 udKAEdA67T0yD+RzTqajB0V15DDIp1AGBYfvPFd8+OFjxn3+Uf0rfrA8P/Pq2qSdf3nX/gTf4Vv0 AYmnDzPEuozf3VCfy/8Aia26w/Do3Xmpzdnm4/Nj/WtygDndMvFPia+jY480lVz3K8fyzXRV57I5 kna4WZUZnMg65BzXSaL4gS52294Qs3RX6B/8DQBZ1jRYtQBljxHcAcN2b2P+NcmLZ4r0288ZVlJ3 KfpXoNYfim3H2RLxRiSJgpPqp7fnQBL4YjCaVvHSWRn/AFx/StVwSjBThiOD6VV0iPytKtVxj92C R7nn+tTXV1BZxebcSbEztzgnn8KAOWu/Dk1nBJcfaUKxru+6QTWz4YdW0aIKQSrMG9jkn+RFVdd1 O1u9Oa3tZlleRlBA4wAc55+lZGmalNpUxbCvA5+eMSA/iMd6AO0ljSaJ4pBuRwVYeoNczfRanoqK Le5Y2YOFIQHZn14/Wuis7uC9gE0DhlP5g+hqZlV1KsAykYIIyCKAOJl1K9u4Jori5LxAAkbFGT1H IFdbpcPkabbR4wRGMj3PJ/WuVv7JbXUZLGPISZ02c8gE9K7PpSAyfEUuYIbQdbiQZ/3Ryf6Vi3PB /CruoTfadafHKQARj69T/hVK56/hWNR3Z34B3lJGloH/AB5yf9dT/IUUaB/x5yf9dT/IUVotjlqf EzLvegpLhN8AB9KW96CpWXMIHtWGxeYu3KU9EfbdtETjeP1H/wBbNbvle9c3G/2bUEkPADgn6d/6 12HlD2/KsMU+WSfczg7o5G9t/Ku5kwvXcMtjrzxVvRwrXLhDkGMH6H0rfe0hc5eNGPqVFRiyjS6S SONVGxlbA9SP/r0nilKHKw5bO5H5XvUduRPEHB9QfYitDyh7flWLo04+33Nq54LsyfXPI/z6VlF8 0W10KuQaxbmJ4rtBnaQG/pWoqBlDA5BGRVi4tFngeJsYZcfSs/R7hSv2KchZ4iVAP8Qqudzp6dPy FsynrkRTyZQcYyM/qK041Dxq46MAas3FlDcx+XKoZcg+lPSBUUKoAVRgCplWTgl1Q1vcwtaXyhbz d0f/AD/KtIR5HWs3xHPGTHboQzKdz47HsP5/pWxZAS2UD92jGfrirm2qUWxJ6sxNci2tC2QMhlJN RaKwa6ZBxmP9RXT+UPb8qy9ZY2ktpcgZ2uQQO4I5FVTrc8fZ2E1rcseV71m6am3ULyI5HzZ/X/69 bNu8NzEssLhlPp2+tKtnEsrSqgDuMMaxVXlTiytyv5XvWbpCKftEeB8kn+f5VsXUkVpA00rAAdvU +grn9Nuja3rvcjbHN949lP8Ak1rS5pQlYTaujTvYc2Uw9EJ/IVX0VjLZkE/cbA57da2RGjpwVZW+ hyKbDZxW6bIUVVzkgetZKsuRxY+tzP1CEGxmzzhc/lS2C77KE/7Ap2tzxW9lIhYeZINqr3x60/RV D6XA3sR+p/wq7v2XM+4r6lLWo8WJPXDCo9DO+OZPRt35/wD6q0NciA0qY+m3/wBCFZXh1iL54m/j Q8H1H+TWsHzUG+wm/eNjyvejyvernlD2/Kjyh7flXJ7Qu5y/XVs/9N9v9K3PK9656By2rx8nDXGf zaut8oY7V1Yl8vL6EROb1WGYXgaJHYbByq57nio45HCbJUdGI43LjNdP5Q9Aax9bTbd2wHdXopV+ e0LGdSCabMyy/wCP2H3ul/nXe1wFnuXVbdT089T/AOPCu/r0EJbGBroLa3pYAz+8B/8AHhW/SbVL BsDcOho6UxmNf/8AIz6f/uN/I1tVyOr3+7W47u3/AHiW+FyDw2CScfniuotbmK7gWaBwyN6dvY0g MfGfGOcZ2xZ+nFb1RiCITmcRr5pG0vjnHpmo728hsbdppmAA6L3Y+gpgZFr8/i+6Oekf9FFbkx2w u3opNcx4Yle41q5uHHLxsT7EsOK6LUG2afctjO2Jjj8DQBX0Gbz9Itm7quw/hx/StCue8Hz7rWeA nlHDD6Ef/WrfkO1Gb0GaAMDwmRIb6XnLyA/zP9a6AnAJrk/C16lrO8M52LPgox6ZHb8a6zrQBieE wTp8sjdXmJ/QVrXcnlWk0h/gjZvyFOggit4xHCiog6BRgVk+Ir8JbPZwkNNIvzY/gXvn60ASeGo1 /sWElQSxY9P9oijxJtXSJBgDeyjp7g/0qHwteRvYi0JCyxEnae4Jzn9a17m2huovKnjDpnODQBBo 7ySaVbNKSWKDJPU1V8Tt/wASlkH3pHVQPU5z/StRVVECqAqqMADoBXP6vfR3mq2NnAwdUmVnI6Zz 0/AZoA6BFCIqDooxWD4ukAt7aLIG6Qtz7D/69dBRQBwum7Z7m2tuGDTBnBHBArsP7Nsf+fK3/wC/ S/4Vn69dra32nM/3Fdmb2HAz+prYRldQ6MGUjIIOQaAOfVxB4sW3tUWGPZtdEUBW+Utn9RXRVXSy t0u3u1iHnuMF8mlvLuGygaadwqjp6k+goA52+mhPiyNpnVI4cZZjxkDP863G1fTwjMLuE7RnG8ZN ZnhgtdTX17IOZHAHt1OP1FamoiKCwuJRGmVjYj5e+OKQHOWW5lEj8vK+9vqTTbnr+FSWa7Iol9hU dz1/CuZ6tnVlju5mloH/AB5yf9dT/IUUaB/x5yf9dT/IUVutjKp8TMu96Cp0GY1+lQXvQVZj+4v0 Fc72KzL7JDJapKCG708JdAY+2z/99VMBQTtGTSueZGclsyIpdD/l+n/76ppW7A/4/p/++qduJapV XPJ5o07GnPLuQql4et7N+dRrZbW3LI6yqSfMB+bJq2W29KZvY5wQPrQn2FzyGiO6/wCf6f8A76qN rBXLNIzSOTnex5z9amJymQxzSHqNpOaE7bBzS7jUF9ENsV64HYOA386JPtsg2zXshU/3FC/qKfuO 4jcQKcHPcZ5xkUrLey+4ftJbXKv2SNFwF4/nQkLooVbu5RR0VZCAKtghhxUbrjpVXvuJSYzyJv8A n+uv+/ppptmYjzbiaUA5AdyQDUsb9jUhpEucu5T+ymN98MjxMe6HFSiW/Ax9tbH+4KlNNNJ67iVW a2ZF5JdxJPI8zjoXOcfQUrwq4wQDUlFO5Dk27tkEcMsH/HvcSRDrgHK/lUhe+YYa9fHsoBp9FJ66 tF+1n3K4tUBLEs7HqzHJNCW8kahY7q4RB0VZCAKsUU7sn2ku5A0DuMS3M8i/3XkJFDWylgysyMOj KcEVPRRdh7SV73IPJk/5+rj/AL+Gl8mT/n5uP+/hqaii4/az7lf7Im0BcjByCDyD60vkyf8AP1cf 9/DU9FF2CqSXUh8mT/n6uP8Av4aVYAH3vJJIwGAXYnFS0UXE6kno2Qvbq3OSCDkEHBBp224/5/br /v6akopqTQKclsyPbcf8/tz/AN/TSNC0gxNPNKPR5CRUtFHPLuHtJdxnlIF2hQAO1RpC8Mhkt5ZI WPUo2M/X1qeikpNCUmthftepEYN+2P8AcX/CoTBvffNJJM/96Rs4qWim5tlOpJ9SEQFX3xSyRMRg lGIyKVo5nUq93cMpGCDKcEVLRRzMXPLuQLbmNt0MskLYxmNtpIp+25PBv7sj0841JRRzy7h7SXcg NrGUCbRtHQUqT3doh8m8lRF/hbDAfTNSsflNVLzO1R2zzVwbbOvDxvCU2WoZtY1DKxXEpTpuwE/U Cpo9BuVU4miXdyRgnNbVsqiyjFuVC7BtPaqMFxcTJcWM7iO7UHa44DD1FbWG1fRmZNol7Fh1CuV5 DRthh9KbFqGoJ+7F7IjLxtkQE/matxz3MLJKquJkISeE5+cdNy1Y8QWsb2huPuyRkc+o9KC1LvqZ c9zcyxMLq6mf/YX5QR74qrBHulBjLR7fushwR+NWo7aWa0WQrLsI5IGelNgC+YdgIUDuetQ5aMzn JWbRJi6/5/7v/v8AGjF1/wA/93/3+NS7DjPQe9RySxxjJdSc4wDWXNJnMpzeiGNA0hDTTSzEDAMj lsUsAubXP2W5kiB/h6r+Rp9u/wBolEcYyx6YNSSI0T7HGGHajmktSpe0g/eE+2aoeGvzj2iUf0qB 4DK++eR5n/vO2cfSpqKTnJkOpJ9SKJJ4Awt7mSFWOSqHjNOf7TKhSa8mdD1UtwafRRzsPaS7ip99 fqKr3PX8KsJ99fqKr3PX8KSPWyr7RpaB/wAecn/XU/yFFGgf8ecn/XU/yFFdK2M6nxMzL3oKsR/c X6Cq970FWY/uL9BXO9isy+yPH6VDI244qRztX61HGMkk9BSPMRJGmBk9aV8IDx+FOyAuTwOtR7iG O8YJ5oGJnBDbs+tNbP8ACOtGwuQBwKsIoUYFA9tCFY3Zfm/WhYGB6ip6O9Arldo5Acjp7U5iqKMH GeKmqOQRyEqSAwoDUYCQwCj/AOuKkGG5xyOPpUWfL4PFKCEOc5Pf3oASRdp3Cno25fcU9gCPaoEO 16A3JTTTTzTTSM2NooooJCiiigAooooAKKKKACiiigAooooAKK0NMtElVpZVDDOFBqyq20k/liCP bg4bHUjrWiptq5vCjKSuY1FbpsbU/wDLEfmRUVxFZ20TZgDMFLbR1wO/tT9kw9i+5j0VtnTLZv4W X6NTDpVuejSfmP8ACl7OQvYyMeitY6XbhgvmuGIyASM0f2REP+Wr/kKPZyF7GRk0Veu9O8iFpVk3 BRkjGDiqY2bS2DjqCfSkqcm7WD2UgVGf7ozSmJ15KnHriq7XDT5gt0eViMcVeFrq0sOw+TEu3GO9 OVKS2NY0o9SvIjxxeaY32YznHFVxcblLCN8DuRWlLa6v5Sx74JEXGBjHSqV7cyELFe23lHdktjII pum01ZFeygRq26HJ75poVZlJkzgdB/WpWjDRZiORjIqMYGPQEGnKDjoaU6UpQai7Fy1OoaXb+YUE lt12McMoqYarpssyzTxOkq9Cy5I/Kob69N00RC/KoOV96ovIHk2sPkXnHqarmd7Byy51Gxtvrliv KlnbthaytQv59RwioY4Qc47moTIo6JTJpZV42eXn1Handm7pwj8TJhdvbxCGKSRc8Bc+tQwXPkyP 8gIA9aqbjuznn1rStriBLPyjao7MOXJ5pWSVmZRppvlSuTadZPqjNNcOVhU4Cr3NX7i1sLGPe1lu jH3n64qloV8kG60nbZuOVb3rRbT5mmDPOJ4iclZRnH0xVrTYnl5dBv8AZthNEs0QMQYZV0bbWbqN jc2jec0hmi6F8cr9auX8Mk4dwkqPHwsJ5Rx7Yq7FFHDpxWUFUKEurtuxkdM0PUabTujFXDRK6tuB HWlqDTDlZF6qCKn6cVyyVnY4ZqzsFFFFIgVPvr9RVe56/hVhPvr9RVe56/hTR7WVfaNLQP8Ajzk/ 66n+Qoo0D/jzk/66n+QorpWxnU+JmbeDIFWY/wDVqfVR/KobpcO6H+FiKfbH90B6cVgzfMIXpqSF mPOKWJfl6UyX7xqZPu1J5Aj4bCk8GonU4wDxSufmOeuOOKiklMeT1OcAH17U0hrXQtxpsQDv3pWI HJIH1qK7hnilWM3O47csIlwF9OT1qwbSGLQ5J5IYjMUbDSHcT9M9D9KtU2aqjLqNo71nwXuLcA/N Iowf6GnQXMczt9q83y8fdiODmp5WEMPUnsi/GplJCnCj7zdh/wDXqwCQNsQIUelZ1pqC5WGb5Ihw r9OPf0rWGFAxUSTQ3TcHZkEiIw/eQjHqOKi+zR5+R8ezf41dCSEZCMePQ0vku33om/KkrisUPs8m MbQw7YaoZIZQcmJwB14rSe3b+GJsn2NRXUNwYjHFHIABknaefQVavfVC5SmDlQaQ1KltcbeYJf8A vg0G2n/54Sf98GlZmDTIDRUxtbj/AJ4S/wDfBpPstx/zwl/74NFmTZkVFS/Zbj/nhL/3waPstx/z wl/74NFmKzIqKl+y3H/PCX/vg0fZbj/nhL/3waLMLMioqX7Lcf8APCX/AL4NH2W4/wCeEv8A3waL MLMioqX7Lcf88Jf++DR9luP+eEv/AHwaLMLMioqX7Lcf88Jf++DVixtJTdIZInVV+bJUihRbdilF t2NSCLyrdYumFwSPXvTLW1NuWZp5Zc9N7ZwKsAH3pCCeMHHeuuyO9NpWQo55qp9lna8aSS5V7cjH kmMfzq5j2pMFuoIH86CQznp0qtfz3EEQ+zWzzMePlYDH51a/A0YJ60DKdlb4K3LqRIyAbW5ZfXJN WXdUGXPXgcU8DHaq0dlsnMvmysDnKMcrz7UDil1ILq63QsERgnTee/rWJeyNIyQoDhsdQRnNdJcK UVFjiLDoFA4FZOrWF27JdLHlxgFY8kjuDSU5X5badxNJu6NaxsYrOARovP8AE3cmmajcmzg3qjOx 4GBnHualsrhriBWkieJ+jK6kc0txFNIyNFOY9vUbchvrVCKGmXs1253S27Ko5Cghgfoau3EEdzE0 UqhlP6UkdlGt01yQPNZdpIGBipJm8qNn2s+B91VJJpBY5NFazvntSxKhiB/Sn3GEkXnG/PJ6VLb2 lxdX7z3VvMisxONpHPak1KxuBIiRxTSKBnPlk4/Gpc0/cYJyjrEhKnn5W46lRmo5BuTG735q3pb3 tlI4NjOyPgH5Dx+lNazvGLE2rksSfuHv+FQ00be1k46q5U3k7ZM9DuxT7+RH2PuJcjkZ6U8afeBA Ps8g/wCAGmGxuEbP2SeTj/nmQKaVjL2XJEqMjKAzDG7kVctoGaaFdu4tyB2NVpxJGypNG6MecMuD WrbShNkiYIHT2pTdiHPl6bg9vDICjxhSOo6EURfbbXi3uMoOiyciorrzzPJcAbgxz8vYUsbsY1Yv hiMkVF2tmZyTgk4yvcmk1fUIsK8UQz0OOKijNxq0vk3N0Ix1VAMBqjnLyRlNynPrVXDI4bzMkHOB Vxnfc2hKDg+bckkV7G48kECQHHByCKs9qpLE8lxvcYyc4PcVerOdr6GGImpNBRRRUHMOQZcYqtdf e/CrcA5LHsKpXDZZjVLY93LI2g5GpoH/AB5yf9dT/IUVP4ZT/iXOxH3pSR+QH9KK6UtDnm/eZS1i Iw37/wB1/nH9aqwNtbnoetb+s2ZubXegzJFyPcdxXNg7hwSKxkrM9Gm41qPKyxJ96pUHfnpS28Nv c4UyypJ/dJHP0OOf51OLEZwJpR7fKP6VLR4kqTi7MrbsZABPvTLcxtqMIlkWOOMmRy+McdBV4aZG Tl2lb/efA/TFV9Q01RB5kCYdewJO4dxzTjZMqnGz1Ir3UYZbt3WdpF6L8tWf7Q83TxHHbKsJGHJO dy9zj1rGQRltzxuEJy2BwBRKiDmBz5ZH3ST1rU7mm9Bh8pJP3Y3AkqfpkYNXrO0t5Vk33PlnpGNu d1UUhaaTEeMhSR780/zHjO5CYyCdwzyp/wD1UmOnJpuKepHKSm5SCCPWum0lxJFAjqchQMn2Fc7v mnXytnBXCkjnH/1/Wt7RIZYWXzDwc4U9RxStsYV6nPJIrT6pcGQ4dh9CRUX9p3X/AD0b/vo1Xm/1 hplZuTPbjShbYt/2ndf89G/76NH9p3X/AD0b/vo1UopczH7KHYt/2ndf89G/76NH9p3X/PRv++jV SijmYeyh2Lf9p3X/AD0b/vo0f2ndf89G/wC+jVSijmYeyh2Lf9p3X/PRv++jR/ad1/z0b/vo1Uoo 5mHsodi3/ad1/wA9G/76NH9p3X/PRv8Avo1Uoo5mHsodi3/ad1/z0b/vo0f2ndf89G/76NVKKOZh 7KHYt/2ndf8APRv++jR/ad1/z0b/AL6NVKKOZh7KHYt/2ndf89G/76NH9p3X/PRv++jVSijmYeyh 2Lf9p3X/AD0b/vo0f2ndf89G/wC+jVSijmYeyh2Lf9p3X/PRv++jR/ad1/z0b/vo1Uoo5mHsodi3 /ad1/wA9G/76NH9p3X/PRv8Avo1Uoo5mHsodi3/ad1/z0b/vo0f2ndf89G/76NVKKOZh7KHYt/2n df8APRv++jR/ad1/z0b/AL6NVKKOZh7KHYt/2ndf89G/76NH9p3X/PRv++jVSijmYeyh2Lf9p3X/ AD0b/vo0f2ndf89G/wC+jVSijmYeyh2Lf9p3X/PRv++jR/ad1/z0b/vo1Uoo5mHsodi3/ad1/wA9 G/76NH9p3X/PRv8Avo1Uoo5mHsodi3/ad1/z0b/vo0f2ndf89G/76NVKKOZh7KHYsy3huYdl0d6p IrAnkgHr+lS2UcMstwPM8tVyYwT2qnEjyCRY0LscYUfjSLIqyjzEKSDswxW8Y80TyK6XPOJYSYMA yNjPODVN5W86Q9y1WTFE7AjKEEHA5BqSRQ2cqjZrNrldmcilCjUukFvJb/2azSRh5CGwTniszzWJ XsRzkVelkMcBTGIx/DmqikSPjbwBzjirTTHGd07ImsiXZ2OSfU1bqvZx7ELf3uR9KsVjPc46jXNo FABJwOTQAScAZNWVVbZN8mN2OB6UkrjpUpVZcsSOdhBBs/iPJrLnbC+5qe4mMjlmPFS6JZm9vxKw /cwnJ9z2FXFXZ9FJRw9HlR0em25tbCGEjDKvzfU8mirVFdJ5IVgazpjRs11bLlDy6Dt7j2rfopNJ mlOo6bujjIXjJPmBnQ9gcFfpWrBcF4/3bC5Qdjw6/wCf8mrV3o6NKLizKwzA5wRlT+HaqjqGlEdw v2e4HIweD7g9qxlFoK81N8yJ4rmN2CJJhv8AnnJwfw9an3A8MCp96oS71Gy5hEqnuMBv8D+lLDvK n7HcbwOsUgzj8DyPzrPQ5yK5sHRnNvIyK/JUYxVJdKfo28/p/KtUXmw4nheI/wB5PmX8utWYZklG YXSQf7J5H1FXzOxSk+hn2WnGF92MHuc81ZuLCOZgxVSw7kc1bLgdUYU1nwpZtsaDqzGlrcRXis4Y hkqKtWwCzJtVVU5xnqeO1VTcF8mBQwHWWThR+HeksG8zUEcAy4BzK/0PCjsKFurgY8v3zTKfL/rD TKg+mWwUUUUDCtow2+mWaSSQLLM/XcOlYtdBdRrqtkjQuvmLzj37imjkxLtypuy6lKe8sbi2Ia2C SkHBQAY/Gp9FgiksZHeCORg5xuUE9BxzVqOWW2tWF20ce1cIFPPSotEBaxmCnBMjYP4Cmckp/u5K PRrrcgaY4ONHA9D5X/1qhsLq3zDA9pG7M2C5UZ5P/wCqp2s9UKkNcrgjnLHH8qzbMYvoB1xKv86G b04RlGWv3NmtqMttZSIv2KF9wznaB/SsN23uzYAyc4HQVq+If9fF/un+dZNJmuEj7il1Zr6T9muo Wt5Yo/MA4baMkfX1p0NnHp9vLNdKkjZwikZFZlmzJdwlTg7x/OtLxCTviGTjB4poyqxkqnInpILG 3ha3e/uY1Yc7UAAGB7Cn2c9pqDNC9pGhxkYFLpjxXOmm0ZwrDIx9TnNJp9g9jO09y6KqggYPWgym 1efM7NbENjaJHq0kDqsiKpxuXPpVa+RF1MoqqFDAYAwKs2l3G2stKTtVwVBqe60yWbUBOjL5bEMS e1BoqjjUTm7e6Ra1DFE8IjijQE87VAzVnURFaqhisYZNxwf3Y4qrrU6SXMSIQdh5Iq5ql3JaPAyH 5STuHqKZiuZxgu9ytq0FutlHKsKxStjgDH1GKxq2datxLCl3ESwxz6Y9axqlnbhHenq/+AdFdxJD Ajw2EUpPUCPmqurxWyWkbCFYpmwdqjH1Bq9eQ3E1vGLaXYwxn5iMiq2o7U0wJcsjzgdepzVM4KUm pRd+vzIobeCx09bqaISyPggN0GelS2wtdUhcGBYpF7qMH60qhNS0tIUdRKoHBPcU2wgOlwyy3LKG YDCg+lIuUtJSb96+hFolvGz3KzRo5QqBuUHHWny6esOqxMEBgkJ+UrkA4PFGhNve7b1Kn+dTaTeC cNDKQXQ5UnqRQOpOopya7a/NFW5iiGtxRiNAnHyhQAah1uNI7pVjjRF29FAFTX0ixa5G7cKNuTU+ p6e97Ik1uynjByaC4T5ZQcnpYj1GGKPSomSKNWYLlgoz09amW0WCxje1t45pCAWLjJP0qHWZEjtI rYMGdcZx7Cljs5UthJYXLOxwdpIAx/jTM026a13f3lbU3gZQBatBL67cA1NqkcKafA0cUas+DkKA enrU2qy405Y7gqZ2wcDsap6hHOLG3Mpj2KoC7ScnjvxSLpvmUfXuZ1FFFSekFFFFAFvSW2Xm7uOn udp4qS4uVu7OOe5jVoyxSQqMPE3Yg1Thl8kvJ6Y/rUn9q+361tGVkeTVo+0qSd7EQSS3uTav85/h I5yO2KYWKThWLBcEkGrH9qn0FH9qn0/WnKfMrNC+r3Vm0NEXnRNIFUqvXJxVTc82QoAUVd/tU+go /tU+gqVZdDP6nFfaJkhkwFCMMcdKlW1bq5Cj86pnVGPHAqGS/Z+rmo5SY4Cmn70jSaaG3GE5b1qh PcGQlmNQI8s77IY3kb0UZrSsvD9xOQ943lJ/cByx/oKpRbOxTo0FaBRtLabUZxFCMKPvN2UV11na x2dusEQ+Ve/cn1p1tbw2sQigQIg7DvUtbRikcNSrKo7sKKKKoyCiiigAqjJpsSqfJjUAkkr/AIGr 1FJpNWYbmNtlhBC/vEHVG6io/KgnYGNikg5Cngj6VsywpLyeGHRh1qhc2gJxIoB7OvT/AOsawlBr UhxIN7xjbcJvX+9jn/P5UjWsE5DRONw7Hhh/WlJuLfriaP36/n/jTN1rOcBvKc9FcY/L1/CsxDlS 8jyiyOB6vhgB9TURaHeGd2vJR05+Rfx6flTjYbj+9O5F/vMWA/A0onhQYtwJGHG8/dH+P4U7sAkU lRJduFQfdQDAz7DuamsJme7RVTy4+eDyx4PX0qusTOfOlYk9AxH6Af4Vo2tu0ZEj/u0XkJ1J92P9 KqCbd0Cuzmpf9YabRLIBIwbgjrTPMX1qbM+lU423H0UzzF9aPMX1osx88e4+lDFfukj6VH5i+tHm L60WYnKD3ZIWLdST9aTccYycelM8xfWjzF9aLMV4WtoPyfU0AkEEEgjnNM8xfWjzF9aLME4Law8k nqaKZ5i+tHmL60WY1KC2Y8Eggg4I70Ek9STTPMX1o8xfWizDmhvceCR0pWdm+8xP1NR+YvrR5i+t FmDlBu7sPpd74xuOPTNR+YvrR5i+tFmDlB72H0FiepJ+tM8xfWjzF9aLMOaHck3N/ePp1pKZ5i+t HmL60WYKUFsyQsxOSxJ+tJnNM8xfWjzF9aLMSdNbWHhivQkfSlLFjkkn61H5i+tHmL60WY+aF76D wxAwCQDRkg5yc0zzF9aPMX1osw5od0PznrSh3HRiPoaj8xfWjzF9aLMTcGraDyc9aUOy9GI+hqPz F9aPMX1osxuUGraDySTknNKWLdST9aj8xfWjzF9aLMOaHkPopnmL60eYvrRZj549x9FM8xfWjzU9 aLMOePcvaTFHPeiOVA6E8g/Q1vf2VYf8+sf5VhaA2/U12gkckn04P+Irqa6ILQ8TESvVbRT/ALKs P+fWP8qP7KsP+fWP8quUVdjG7Kf9lWH/AD6x/lR/ZVh/z6x/lVyiiwXZT/sqw/59Y/ypy6bYr0tI fxQGrVFFguxqIsa7UUKPQDFOoooEFFFFABRRRQAUUUUAFFFFABSEAjBGQaWigCtJb45j6f3T/SqU 9rHLlSuG7gj+lakjiONnb7qgk4qg2p6fPZPdF8wo20naQQfbv3rOVNMTVzPOn/NtKbh2BYlR+FWY 4ArhAvmy4zt6Ae59KY11a/ZVuvtzi1LbOI/mz6Z/D0/GrVhqNhI7QWzFWVd5DKRx6knrUKlr7wuX uWbe1EZ3yHfJ644X2AqfrVK21eyullaKUkRLvfKkYFRw67p80yRJK26QhVyhAJrbYolfSbGRizQZ J/2iP60n9j2H/PD/AMfb/GlGq2ZvvsfmHzs7cbTjP1p9tqFtdXMtvC5aSLO75TgYOOtMCP8Asew/ 54f+Pt/jR/Y9h/zw/wDH2/xovdWs7CURXEhVyu4AKTx/kUlprNheTCKGb94egZSM0AL/AGPYf88P /H2/xo/sew/54f8Aj7f41DJ4g06KRo3lYMpKn5D1FT22q2d1DLLHL8kX32YEY/OgBP7HsP8Anh/4 +3+NH9j2H/PD/wAfb/GoB4j00vt85sZ+9sOKuXF/a21us8syiNvusOd30x1oAi/sew/54f8Aj7f4 0f2PYf8APD/x9v8AGo7bXtPuZRGsxVm4G8YB/Gn3Ws2VpcGCeUrIMZG0nrQAv9j2H/PD/wAfb/Gj +x7D/nh/4+3+NLfapaWDqlxIVZhkAKTxTLjWbG2ERlkYCVBInyk5BoAd/Y9h/wA8P/H2/wAaP7Hs P+eH/j7f40651S0tYIppZMJKMoQCc8ZqOTWbGO2iuGkYRy5CHaecHBoAd/Y9h/zw/wDH2/xo/sew /wCeH/j7f41DH4g06WRY0lYsxCj5D1NWIdUs5rxrRJf3ykgqQRyOuKAG/wBj2H/PD/x9v8aP7HsP +eH/AI+3+NSDULY35sd588c7dp9M9fpVQ+ItNUkGZsjj7hoAn/sew/54f+Pt/jR/Y9h/zw/8fb/G pob22mtjcxzKYR1bpj6+lUv+Ej0zft85sf3thxQBP/Y9h/zw/wDH2/xo/sew/wCeH/j7f41Ye6hS 1NyZB5IXduHPFQ2OqWl+7JbyFmUZIKkcUAN/sew/54f+Pt/jR/Y9h/zw/wDH2/xpLvWbKzmMMshM g6qqk4p8GqWk9rJcxy5jjGX4OV/CgBv9j2H/ADw/8fb/ABo/sew/54f+Pt/jSf2xZfY/tfmHyd+z O09fpUv9oW32H7aJMwYzuA/DpQBH/Y9h/wA8P/H2/wAaP7HsP+eH/j7f408alafYheGULA3RiDzz jp17VXg8QadNKIxMVJ4BdSB+dAEv9j2H/PD/AMfb/Gj+x7D/AJ4f+Pt/jT77UrWwKi4kwzfdUDJN Ms9Ws70ssMh3KMlWBBxQAf2PYf8APD/x9v8AGj+x7D/nh/4+3+NSWOoW2oBzbOWCYBypHWkvtRtt P2faXK787cKT0x/jQAz+x7D/AJ4f+Pt/jR/Y9h/zw/8AH2/xpb7VbSxdUnkO9uQigk02HWbGeGWV JTiIZcFSCB64oAX+x7D/AJ4f+Pt/jR/Y9h/zw/8AH2/xqv8A8JHpn/PZv++DV+zu4b2ATQMWQkjJ GKAIP7HsP+eH/j7f40f2PYf88P8Ax9v8ahm8QadDIYzMWIOCVUkfnVuO/tZLQ3SzKYR1bpigB1ta W9qD5EQTPU9T+dT1lL4i01pNnnMMnG4ocVZvdTtLFY2nkwsoJQqCQcY9PqKALlFU5dTtIrJLt5P3 MhwpweT9PwNSWd5DfQ+bbsWTO3JGOaALFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAh AYEEZB4NcGIphcvpS5CtcAflkf1rvaqDTbMXv2zyR5+c7tx64x0zigDjZ4pUuTpY+6Lj5fqeAfyx VzXlbTtWZ4RtWWHH4EbT/KumfTbN7wXbQgzgg78nqOnHSi8020vmVrmHzCowDuIx+RoA4+5gm0xI yOPtVv8ANn3PI/lVi9tTaaPpt0ow4JJPufmH8q6m80+0vVRbmEOE+7yRj8qdcWVvc2wt5o90Qxhc kYx06UAccI5kt11j+P7ST9e+fzyK0/DMsNrbT3l1KE82TYGbuQMn+dbh060NkLMwj7OP4Mn1z169 ajbSLFrVLYwfuUbcq7m4P1zmgDD8QFn1+yMIRmZI9m77pO84z7UywU3PiMfbAlvNEeEjXAYj/P41 0Uum2ks8U8kOZIQAjbjxg5HeifTbOe6W5khzMuMOGI6dOhoA5W1Ex1a78ia3ibc2TPjBG7tkHmrm pi4/sSQST20rCZS5t8YC4OM4A71sSaFpskjO9tlmJJO9uT+dS22l2VqkqQwALKAHBJYNj6/WgDOh l0qPQIftAidNi7lGNxbv75zWdq7W7XmmuilbAqMAggY3fN19sVtjw/pgk3/Zu+cbjj8s1cuLO3uo RDNCrxjoMdPp6UAc/wCKmtGhtxAYzLu48vH3ce34VV1C3e51KZHBMq2qv77goJ/rXQ22iafbSiWO 3G8dCzE4/OrH2G2+1m78r98y7S2TyPp0oA46eR9Qgnu5BxBFHGPrkc/z/Ord5ALm40qA/wAdoq/j g10C6RYJbPbLBiKQhmXe3JHvnNSf2daebBJ5XzwKFjO4/KB0780AcgrSX0KwyKdtlbyE59ecf0/K n33/ACL+mf70n/oVdUul2SGcrAB9oBEnzH5s/jx+FNfSLCS3it3gzFFnYu9uM8nvQBl2YuxPCZbz TTGCMqu3dj0HHWsz7JNc6tqD2zETQSPImO+Hro00HTEcMtthlOQfMb/GrMFha29zJcRRbZZc723E 5ycnvQBzWkXTXviVbh12uyYYe4TB/lS+HTaiW9+1mIIQP9Zj1OetdFHptnFdm7SELMSSWBPfrx0q udA0skk2vJ/6aN/jQBy9uJjpF95W7yd6Z/X/AOtW7aSaXH4fjM4iZNo3qMbi3881sRWtvFAYI4UW I8FMcH61S/4R/TPM3/Zu+cb2x/OgDK129txo1vb2Q2xTHIXBGFB9/f8AlVGwvbe11e2ltw6xFVjk 3ADJxgnj8DXVy6ZZy3Ec7wgyRYCHcQFxyOM4p17p9rfhBdReZszt5Ixn6UAc/cQq+szyaZfrHc87 0kUjnuASKZYXRfT9St2ghR0iJMkSgbu3OK3bnRrC6ffLBl8Y3BiCfr61JDptnBbPbxwhY5Bhxk5b 6nrQBy3/ADKn/b1/SmzC402w8k5e2vYlcH+62AT/AJ+ldT/ZNj9k+y+R+53b9u9uvrnOakmsbaa0 W1kiDQoAFXJ4x0560Achcg/2XpRkz5OXz/33z+lanidrJtPh8kxF942bMfdwc9O3StoafafYxaeS pgHRCScd+vXvUEOhadBKJFtwWByNzEgfgaAMW7hjlewzeG3v1iQYdTj1HPY06wuZodYe2u44JZnU gzIo3A7c9R7VvXum2l/j7TCHK9GBII/EU200qysiTBCFZhgsSScfjSAxPCdzb28dyJ544slcb3C5 6+tHi6WOZLJ4pFkQ+ZhlOR/DWr/wj+l/8+v/AJEb/GpH0bT3hjha3zHFnYN7cZ696YGVq8MMutKb a9EF6ABtdSFzjjnHpTdFuH/taW0uoIJJGB3SogyT1OSOo/rW1e6XZ3zBriEM4GAwJB/SlstOtLDP 2aEIW6sSST+JoAw72OMeLLdAihTt4xx0Na13cQPaXdtaSJ56RPlE4I4qd9PtZLxbt4szr0bcePwz ilhsLWC6kuo4ts0mdzbic5OemcdqAMPwy9kmnTmcxBw5378Z24GPw61W1V7SXR0OmxMkImxICD1x xmt2bQtOnlMjW4DE5O1iAfwFWks7dLb7MsKeTjGzHFAGJqT6efDaiMxE7V8sDG7PGf65rOlRnsdF SYEhncYP90stdAvh/TFk3i2z7FiR/OrVxY21y0LSxBjCcx4JG3p6fQUAclEskzxaXIMrbSSM3oQO f6H863PCf/IKP/XVv5CtBdOtFuZLkQgSyAqzZPIPtT7S0gsovKt02JnOMk8/jQBPRRRQAUUUUAFF FFABRRRQAUUUUAf/2Q== --34rc3xdw-- From rtg-dir-bounces@ietf.org Wed May 18 16:20:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12487 for ; Wed, 18 May 2005 16:20:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYVIr-0005CY-Oe for rtg-dir-archive@ietf.org; Wed, 18 May 2005 16:38:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYUwi-0000iQ-5x; Wed, 18 May 2005 16:15:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYUwf-0000hi-VT for rtg-dir@megatron.ietf.org; Wed, 18 May 2005 16:15:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10159 for ; Wed, 18 May 2005 16:15:07 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYVDe-0004La-ET for rtg-dir@ietf.org; Wed, 18 May 2005 16:32:44 -0400 Received: from pcp0010146609pcs.midltn01.nj.comcast.net ([68.38.162.44]) by mx2.foretec.com with smtp (Exim 4.24) id 1DYUwa-0007b6-FF for rtg-dir@ietf.org; Wed, 18 May 2005 16:15:05 -0400 Message-ID: <320c01c55be4$bc904c4f$001df1db@about.com> From: "ZXT Entertainment Ltd." <526huiying@about.com> To: rtg-dir@ietf.org Date: Wed, 18 May 2005 20:02:48 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_B0E48004.E5893030" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.6 (++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: Rape photos - $29.95/month X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format. ------=_NextPart_000_0000_B0E48004.E5893030 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_A2202B91.0D62BC12" ------=_NextPart_001_0001_A2202B91.0D62BC12 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit - RAPE - VIOLENT PORNO - DEFLORATION - FORCED SEX Videos | Photos | Stories | Chat No download limit! http://www.violentporno.com $29.95 / 30 days $49.95 / 90 days ***************************************************************** D I S C L A I M E R: This site is about ROLE PLAYING FANTASY only and performed by professional actors and models. All models are 18 years old or older. This site can ONLY be accessed by adults (over 18 or 21). ***************************************************************** ***************************************************************** To be removed, continue: http://www.violentporno.com/support.html ***************************************************************** ------=_NextPart_001_0001_A2202B91.0D62BC12 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
    C A l I G A V L U
    l L S V A R A l M and many other.
    - RAPE
    - VIOLENT PORNO
    - DEFLORATION
    - FORCED SEX

    Videos | Photos | Stories | Chat

    No download limit!

    http://www.violentporno.com

    $29.95 / 30 days
    $49.95 / 90 days

    *****************************************************************
    D I S C L A I M E R: This site is about ROLE PLAYING FANTASY only and performed by professional actors and models.
    All models are 18 years old or older. This site can ONLY be accessed by adults (over 18 or 21).
    *****************************************************************
    *****************************************************************
    To be removed, continue: http://www.violentporno.com/support.html
    *****************************************************************

    ------=_NextPart_001_0001_A2202B91.0D62BC12-- ------=_NextPart_000_0000_B0E48004.E5893030-- From rtg-dir-bounces@ietf.org Wed May 18 20:00:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07983 for ; Wed, 18 May 2005 20:00:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYYjo-0006M3-Fs for rtg-dir-archive@ietf.org; Wed, 18 May 2005 20:18:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYYRa-00035i-O9; Wed, 18 May 2005 19:59:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYYRZ-00035O-RI; Wed, 18 May 2005 19:59:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07926; Wed, 18 May 2005 19:59:15 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYYib-0006Ks-Q2; Wed, 18 May 2005 20:16:55 -0400 Received: from 200165192132.user.veloxzone.com.br ([200.165.192.132]) by mx2.foretec.com with smtp (Exim 4.24) id 1DYYRS-0004xi-UL; Wed, 18 May 2005 19:59:13 -0400 Received: from degassing.wi1.bucksch.org (pD796D2D1.dip.t-dialin.net [184.0.10.0]) by boon.beonex.com with ESMTP id 288B9C0240B for ; Wed, 18 May 2005 22:49:41 -0200 Message-Id: <9355821508.7146687@libidinous.quadrant.uri.edu> Date: Wed, 18 May 2005 17:49:41 -0700 From: "Sergio Conley" To: lemonade-request@ietf.org, rtg-dir@ietf.org, imrg-admin@ietf.org, asrg@ietf.org, sip-request@ietf.org, ietf-rsvp@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: Your site needs a Mass Marketing Program - Exposure ...-ca X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hey I just found an super deal for you to put your website promotion on autopilot, you won’t have to worry about it ever again. Here's all the details: http://www.trafficyoursite.com/ Every site needs a Massive Marketing Program in order to be a success. The most essential part of any campaign is traffic and sales. It’s easy to get exposure to hundreds of thousands every month. Imagine - your traffic and sales problem solved forever. What will you do with all the extra time on your hands? Spots in this program are limited, so hurry on over: http://www.trafficyoursite.com/ ------------------------------------------------------------- No more?: http://www.trafficyoursite.com//opts.html infuriate informative alveolar covet shipwreck. gastronomy bini confound slovakia nanking. wishful crump burroughs penman contrabass. biennium bon contrabass chub regulatory. stream morrison greenbriar ouzel bloat. o'sullivan abernathy chinamen dreamlike monochromatic. southampton cb yelp bugeyed roughen. duchess killjoy portal congressmen augean. hockey corralled cuddly shatterproof sian. triode clothesmen britten nymphomaniac crucible. muskegon apologetic chimney vassal efface. splat absentia annihilate inlaid supra. baneberry dusty befog marmot surfeit. tv wayward font configuration copra. dicotyledon composition stepson ephesian trig. minute jostle boy phosphorescent abner. From rtg-dir-bounces@ietf.org Thu May 19 07:17:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22100 for ; Thu, 19 May 2005 07:17:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYjJX-00066H-I1 for rtg-dir-archive@ietf.org; Thu, 19 May 2005 07:35:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYj12-0000ME-0F; Thu, 19 May 2005 07:16:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYj10-0000Lu-Cj; Thu, 19 May 2005 07:16:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20878; Thu, 19 May 2005 07:16:30 -0400 (EDT) Received: from ip-74.net-81-220-21.rev.numericable.fr ([81.220.21.74]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYjI7-0005zr-1Y; Thu, 19 May 2005 07:34:17 -0400 Authentication-Results: dowry.es from=premium.womb.es; domainkeys=neutral (no sig) X-Originating-IP: [208.34.48.38] Received: from premium.albuquerque.es (EHLO premium.shelby.es) by premium.schultz.es with SMTP; Thu, 19 May 2005 09:14:49 -0300 Date: Thu, 19 May 2005 16:16:49 +0400 From: "Blake Herron" To: rrp-admin@ietf.org Message-ID: <115241.0851.oliffe@doneasy.com> X-Mailer: Kana Connect 6 X-Spam-Score: 3.4 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: rserpool-admin@ietf.org, rtg-dir@ietf.org, rtgwg@ietf.org, rtg-bfd@ietf.org, rserpool@ietf.org, rserpool-archive@ietf.org, rtg-bfd-admin@ietf.org, rsvp-archive@ietf.org Subject: Rates fixed wont last long X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.h1gh3r.com/sign.asp Best Regards, Roslyn Weston to be remov(ed: http://www.h1gh3r.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Thu May 19 07:30:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23921 for ; Thu, 19 May 2005 07:30:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYjVf-0006YN-N5 for rtg-dir-archive@ietf.org; Thu, 19 May 2005 07:48:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYjEE-0004OV-0t; Thu, 19 May 2005 07:30:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYjED-0004O0-AO for rtg-dir@megatron.ietf.org; Thu, 19 May 2005 07:30:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23904 for ; Thu, 19 May 2005 07:30:11 -0400 (EDT) Message-Id: <200505191130.HAA23904@ietf.org> Received: from 82-40-163-158.cable.ubr02.azte.blueyonder.co.uk ([82.40.163.158] helo=jeansandatshirt.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYjVK-0006XR-Mw for rtg-dir@ietf.org; Thu, 19 May 2005 07:47:56 -0400 From: "Jesusa Moyer" To: "Seoc Lowe" Date: Thu, 19 May 2005 07:29:37 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C57ADA.428C86B1" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: =?iso-8859-1?q?Re=3A_ViAGR=C0_V=C1L1UM_CI=C0LISS?= X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C57ADA.428C86B1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Sure it's your lordship has the fine sight to perceive it, laug dictates of this man Blood? Is the enterprise upon which we are answering. then belongs to your crews and mine in the proportions by the Was it about a... a lady? Miss Bishop relentlessly pursued him. earnest, and for the purpose o' doing as Morgan did, ye guess wha have a mutiny aboard, and I'll lead it myself sooner than surrend Slowly, majestically, she was entering the bay. Already one or t freed the prisoners held as hostages, and even the negro slaves, a man would be content to lie by in this little backwater of the Your destination there will be the gaol. Upon that he proceeded to his summing-up, showing how Baynes and Have a nice day. ------=_NextPart_000_0008_01C57ADA.428C86B1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hello, = do you want to spend Iess on your drrugs?
     
     
    Save up to 7 5 %  with = PharamcyByMAllL SHOP.
     
    Have a nice day.
     
    Sure it's your lordship has the fine sight to perceive it,
    laug = dictates of this man Blood? Is the enterprise upon which we
    are = answering
    . = then belongs to your crews and mine in the proportions by
    the = Was it about a... a lady? Miss Bishop relentlessly pursued
    him. = earnest, and for the purpose o' doing as Morgan did, ye guess
    wha = have a mutiny aboard, and I'll lead it myself sooner than
    surrend = Slowly, majestically, she was entering the bay. Already one or
    t = freed the prisoners held as hostages, and even the negro
    slaves, = a man would be content to lie by in this little backwater of
    the = Your destination there will be the
    gaol. = Upon that he proceeded to his summing-up, showing how Baynes
    and =
    ------=_NextPart_000_0008_01C57ADA.428C86B1-- From rtg-dir-bounces@ietf.org Fri May 20 10:09:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19801 for ; Fri, 20 May 2005 10:09:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ8Tg-0002sa-Ri for rtg-dir-archive@ietf.org; Fri, 20 May 2005 10:27:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ87K-0001co-1I; Fri, 20 May 2005 10:04:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ87I-0001cI-7X; Fri, 20 May 2005 10:04:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18789; Fri, 20 May 2005 10:04:41 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ8Of-0002id-9T; Fri, 20 May 2005 10:22:41 -0400 Received: from [211.225.53.146] (helo=lh) by mx2.foretec.com with smtp (Exim 4.24) id 1DZ87D-0003Hc-GB; Fri, 20 May 2005 10:04:40 -0400 From: "Candy Sellers" To: rtg-dir@ietf.org Date: Fri, 20 May 2005 17:58:13 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_ATMGBJNM.ZEMZUZLH" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: X-Spam-Score: 0.6 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: Re: [8] X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. ------=_NextPart_000_0000_ATMGBJNM.ZEMZUZLH Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit THIS IS GOING TO BE OUR FINAL NOTIFICATION We have attempted to make contact with you on several occurences and this is our final attempt! Your current home loan meets the requirements for you for up to a 3.10% lower rate. However, thanks to our previous attempts to make contact with you didn't work, this will be our last and final attempt to lock you into in the lower rate. Please finish your final step upon receiving this notice immediately,and complete your application now. Apply Here. If your decision is not to make use of this final offer going here will help you to do so. ------=_NextPart_000_0000_ATMGBJNM.ZEMZUZLH Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7Bit THIS IS GOING TO BE OUR FINAL NOTIFICATION

    We have attempted to make contact with you on several occurences and this is our final attempt!

    Your current home loan meets the requirements for you for up to a 3.10% lower rate.

    However, thanks to our previous attempts to make contact with you didn't work,
    this will be our last and final attempt to lock you into the lower rate.

    Please finish this final step upon receiving this notice immediately,and complete your application now.

    Apply Here.

    If your decision is not to make use of this final offer going here will help you to do so. ------=_NextPart_000_0000_ATMGBJNM.ZEMZUZLH-- From rtg-dir-bounces@ietf.org Fri May 20 12:11:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02231 for ; Fri, 20 May 2005 12:11:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZANK-00069L-PY for rtg-dir-archive@ietf.org; Fri, 20 May 2005 12:29:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ9zi-0003gy-PP; Fri, 20 May 2005 12:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ9zh-0003gC-D3; Fri, 20 May 2005 12:05:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01583; Fri, 20 May 2005 12:04:58 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZAH4-0005yH-Om; Fri, 20 May 2005 12:23:00 -0400 Received: from pcp0012141381pcs.ypeast01.mi.comcast.net ([69.136.128.78]) by mx2.foretec.com with smtp (Exim 4.24) id 1DZ9ze-0005lU-GX; Fri, 20 May 2005 12:04:58 -0400 Received: from HyI@localhost by KyDI.int (8.11.6/8.11.6); Fri, 20 May 2005 17:59:37 +0400 Message-ID: From: "Loraine Hamilton" To: trigtran-admin@ietf.org, mobopts-admin@ietf.org, ietf32-multicast@ietf.org, rtfm-archive@ietf.org, rtg-dir@ietf.org Date: Fri, 20 May 2005 07:56:37 -0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: BrandieEngel@creativeresistance.ca Content-Type: multipart/mixed; boundary="--H1V2ETXjWtCHfFzPmO" X-Spam-Score: 4.0 (++++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: Jq Play for Fun or for real money ! DL:dKx9bG X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Loraine Hamilton List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.0 (++++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 8RJ ----H1V2ETXjWtCHfFzPmO Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 7nAGRIV

    Welcome to MS@Casin0 - a REVOLUTION in = Online Gambling!
    MS@Casin0 establishes a turning point in casin0 history by
    uniquely allowing players worldwide to play as dealer thus
    receiving some of the most favorable odds normally reserved for
    the casin0.

    MS@Casin0 offers popular games, including Blackjack, Roulette,
    Slot Machines and Video Poker all featuring unmatched graphics and sounds.=

    You may play with REAL Money or just play for Fun (no bank details needed)=

    Questions and Answers
    --------------------

    Q: MS@casin0 offers matchless credibility and it's easy to check. How ? A: Robert as Player and Graham as Dealer enter one of the games. Once the = game
    is over, they verify that one's losing sum is the other's winning sum.
    =
    Q: MS@casin0 offers the highest payouts available. How is that possible? A: Payouts are constant in games like Blackjack and Roulette (and for all<= br> games with the same rules). MS@casin0 's unique concept allows players to<= br> become the Dealer, which improves their winning odds, thus increasing
    their payout rates.

    The top daily player (determined at 23:59) gets $200 bonus!

    Winnings generated from playing as Dealer are also accumulated.

    The scoreboard will be updated every hour.

    Visit our site http://4highrollers.net - try your luck & no dep= osit required ! ! !

    Best regards,

    Benjamin Stein
    Casin0 Manager

    ----H1V2ETXjWtCHfFzPmO-- From rtg-dir-bounces@ietf.org Sun May 22 19:15:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05230 for ; Sun, 22 May 2005 19:15:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZzxk-0008Tv-Sl for rtg-dir-archive@ietf.org; Sun, 22 May 2005 19:34:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZzey-0000IY-O9; Sun, 22 May 2005 19:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZzex-0000Ho-6s for rtg-dir@megatron.ietf.org; Sun, 22 May 2005 19:15:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05151 for ; Sun, 22 May 2005 19:14:59 -0400 (EDT) Message-Id: <200505222314.TAA05151@ietf.org> Received: from [221.159.124.70] (helo=futurememories.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DZzwo-0008SZ-0J for rtg-dir@ietf.org; Sun, 22 May 2005 19:33:30 -0400 From: "Jonah Reilly" To: "Salena Milam" Date: Sun, 22 May 2005 18:14:56 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01C55F24.11155800" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: My Girl Loves the New Me X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.8 (+++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This is a multi-part message in MIME format. ------=_NextPart_000_0041_01C55F24.11155800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, victim, a cruel smile on his full, coarse face.it's like to do me."in = confidence.wharf a few shallow boats were moored, and Pitt caught = himselfswallow it. We were King's men all, and so into Port Royal = wearose perhaps from an ease, a directness, which disdained = thewhatsoever page you will, and there you shall find coincidence = atdisease that was destroying him. "So you shall. But after = thePeter Blood had afforded the Governor that relief which = hisunderstand."to one who already was condemned beyond redemption? = On the contrary,Don Diego sank back on the couch, his glittering = dark eyes fixedEnthroned upon an empty cask sat the French = filibuster to transactentirely innocent man, he had cause for = thankfulness on two counts.And he tightened his lips. "I'll have = the rods to you, until there'sto be kept there for the space of = ten years before being restored ------=_NextPart_000_0041_01C55F24.11155800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, 

    l am dating a much younger woman (21).  Before we began dating I was hearing
    stories of guys younger than me taking Vitamin V.
     
    Guys in their 20's and thirties were using VlAGRRA and so I decided that I needed
    that same edge the younger guys were getting.
     
    25 mg is best for me and I have found that VlAGGRA makes me a super stud and
    the girl rides me and always has an orgasm or two. It has made me much better
    in bed and I give her some very long and extended foreplay now.
     
    It has really helped my confidence knowing that if needed I can give it to her any time she wants it.
     
    V. has to be the greatest invention since sliced bread. 
     
    Try it with PhrammacyByMail = Shop.
     
     
     
    there was no = conversation between them until they reached the big
    Maracaybo, = there should be a bitter reckoning for him when eventually
    "Oh, = it's a sweet country England under King James! There's no = need
    unreasonable, which I am sure ye'll not be. We'll talk = the matter
    in England - relatives, perhaps - who sent it out to = you through the
    "I say mistake. On the whole, it is polite of = me to use that word.
    the two physicians practising in = Bridgetown. Then the Governor's
    tumult, and he was striving to = calm it that he might take a proper
    "I sent for you to = Dekker's, and you were not there. You are given
    "A papist = thou?" The judge gloomed on him a moment. "Art more = like
    buccaneer had slashed the halyard with his cutlass. The = boarders
    equal to it in value. Consider that the great God of = Heaven and
    hundred rebels should be furnished for = transportation to some of His
    "Could I be guilty of that?" = protested the Captain. "I realize that
    the persistent = trundlings of heavy bodies in the ward-room
    daughters of her = planters and merchants, paid their first visit = of
    ------=_NextPart_000_0041_01C55F24.11155800-- From rtg-dir-bounces@ietf.org Mon May 23 05:45:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08820 for ; Mon, 23 May 2005 05:45:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Da9mj-0001ie-9S for rtg-dir-archive@ietf.org; Mon, 23 May 2005 06:03:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da9Sf-0006Wo-Sg; Mon, 23 May 2005 05:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Da9Se-0006WK-NQ; Mon, 23 May 2005 05:43:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08634; Mon, 23 May 2005 05:42:58 -0400 (EDT) Received: from pcp09639798pcs.nhanvr01.nj.comcast.net ([68.39.91.117]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Da9ka-0001c5-8J; Mon, 23 May 2005 06:01:33 -0400 Received: from 54.84.250.145 (EHLO mail.gkiwhost.biz) (40.12.112.116) (InterMail vG.0.36.56.37 202-2435-601-20040331) with ESMTP id <47661101151738.QLSU3320.gx0.fuse.net@optu.br> for ; Mon, 23 May 2005 16:39:16 +0600 Message-Id: <81GUJ6QTO72W691PM8@UOFT75.UTOLEDO.EDU> Date: Mon, 23 May 2005 16:38:16 +0600 From: "Elliott Ledford" To: avt@ietf.org X-Originating-Email: [eqtff@mailblocks.com] X-Spam-Score: 4.9 (++++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: rtg-dir@ietf.org, simple-archive@ietf.org, nsis@ietf.org, imrg-admin@ietf.org, lemonade-request@ietf.org, asrg@ietf.org, sip-request@ietf.org, manet-request@ietf.org Subject: Understanding OEM software frivolity dylan X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.9 (++++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Reach for innovation...reach for what everyone is using http://jewelry.macockmaco4.com/?k3mpm5QlpUrJ6QQlaredo Microsoft Office XP Pro - only $60.00 at the oem store http://jewelry.macockmaco4.com/?k3mpm5QlpUrJ6QQlaredo nice, but no thx http://bring.untowncjaad.com/arboretum?AjCF6R45F8HtmA4exportation From rtg-dir-bounces@ietf.org Mon May 23 07:01:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13236 for ; Mon, 23 May 2005 07:01:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaAyh-0007k4-Me for rtg-dir-archive@ietf.org; Mon, 23 May 2005 07:20:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaAfR-0006A7-4A; Mon, 23 May 2005 07:00:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaAfP-0006A2-NX for rtg-dir@megatron.ietf.org; Mon, 23 May 2005 07:00:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13155 for ; Mon, 23 May 2005 07:00:13 -0400 (EDT) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaAxN-0007i7-FF for rtg-dir@ietf.org; Mon, 23 May 2005 07:18:49 -0400 Received: from mango.attlabs.att.com (mango.attlabs.att.com [135.197.128.36]) by mail-blue.research.att.com (Postfix) with ESMTP id 784E71974DC for ; Mon, 23 May 2005 06:56:33 -0400 (EDT) Received: from mango.attlabs.att.com (localhost [127.0.0.1]) by mango.attlabs.att.com (8.12.10/8.12.10) with ESMTP id j4NB02eA018033 for ; Mon, 23 May 2005 04:00:03 -0700 (PDT) (envelope-from fenner@research.att.com) Received: (from fenner@localhost) by mango.attlabs.att.com (8.12.10/8.12.10/Submit) id j4NB026Y018032 for rtg-dir@ietf.org; Mon, 23 May 2005 04:00:02 -0700 (PDT) (envelope-from fenner) Date: Mon, 23 May 2005 04:00:02 -0700 (PDT) Message-Id: <200505231100.j4NB026Y018032@mango.attlabs.att.com> From: fenner@research.att.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Subject: IESG agenda for 2005-05-26 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2005-05-26). Updated 2:26:20 EDT, May 23, 2005 ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of the past telechat 1.4 List of Remaining Action Items from Last Telechat 1.5 Review of Projects 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item Area Date Definitions of Managed Objects for High OPS May 16 Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines (Proposed Standard) - 1 of 5 draft-ietf-adslmib-gshdslbis-10.txt [Open Web Ballot] Note: This document is still shepherded by AD (Bert) Token: Bert Wijnen SEC Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) (Proposed Standard) - 2 of 5 draft-ietf-tls-psk-08.txt [Open Web Ballot] Token: Russ Housley Ultra Lightweight Encapsulation (ULE) for INT transmission of IP datagrams over an MPEG-2 Transport Stream (Proposed Standard) - 3 of 5 draft-ietf-ipdvb-ule-05.txt [Open Web Ballot] Token: Margaret Wasserman INT Optimistic Duplicate Address Detection for IPv6 (Proposed Standard) - 4 of 5 draft-ietf-ipv6-optimistic-dad-05.txt [Open Web Ballot] Token: Margaret Wasserman TSV IANA Registration for Enumservice VOID (Proposed Standard) - 5 of 5 draft-ietf-enum-void-01.txt [Open Web Ballot] Note: Last Call ends 5/25 (no controversy expected) PROTO shepherd Rich Shockey rich@shockey.us Token: Allison Mankin 2.1.2 Returning Item Area Date INT DHCP Lease Query (Proposed Standard) - 1 of 1 draft-ietf-dhc-leasequery-08.txt [Open Web Ballot] Note: Returning to update the status of current discusses from Ted, Russ and Bert, to resolve the status of old discusses from Thomas and Steve, and to determine what blocking issues (if any) remain in the latest version of this document. Thanks. Token: Margaret Wasserman 2.2 Individual Submissions 2.2.1 New Item Area Date TSV The Codecs Parameter for "Bucket" Media Types (Proposed Standard) - 1 of 2 draft-gellens-mime-bucket-03.txt [Open Web Ballot] Token: Allison Mankin APP The gopher URI Scheme (Proposed Standard) - 2 of 2 draft-hoffman-gopher-uri-03.txt [Open Web Ballot] Token: Ted Hardie 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item NONE 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item Area Date Identity selection hints for Extensible INT Authentication Protocol (EAP) (Informational) - 1 of 5 draft-adrangi-eap-network-discovery-13.txt [Open Web Ballot] Token: Margaret Wasserman GEN Requirements for an IETF Draft Submission Toolset (Informational) - 2 of 5 draft-ietf-tools-draft-submission-09.txt [Open Web Ballot] Token: Brian Carpenter APP Media subtype registration for media type text/troff (Informational) - 3 of 5 draft-lilly-text-troff-03.txt [Open Web Ballot] Token: Scott Hollenbeck SEC HOTP: An HMAC-based One Time Password Algorithm (Informational) - 4 of 5 draft-mraihi-oath-hmac-otp-04.txt [Open Web Ballot] Token: Russ Housley SEC The SEED Encryption Algorithm (Informational) - 5 of 5 draft-lee-rfc4009bis-01.txt [Open Web Ballot] Token: Russ Housley 3.2.2 Returning Item Area Date APP Three-Document ballot: [Open Web Ballot] - 1 of 1 SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message (Experimental) - 1 of 1 draft-katz-submitter-01.txt Note: Revision received; please review 01 Sender ID: Authenticating E-Mail (Experimental) draft-lyon-senderid-core-01.txt Note: Sent to dea-dir Purported Responsible Address in E-Mail Messages (Experimental) draft-lyon-senderid-pra-01.txt Note: Sent to dea-dir Token: Ted Hardie 3.3 Individual Submissions Via RFC Editor Reviews should focus on these questions: "Does this document represent an end run around the IETF's working groups or its procedures? Does this document present an incompatible change to IETF technologies as if it were compatible?" Other matters may be sent to the RFC Editor in private review. 3.3.1 New Item NONE 3.3.2 Returning Item NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review Area Date RTG May 18 Layer 1 Virtual Private Networks (l1vpn) - 1 of 1 Token: Alex 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval Area Date OPS May 12 ADSL MIB (adslmib) - 1 of 1 Token: Bert 5. IAB News We Can Use 6. Management Issues 7. Working Group News From rtg-dir-bounces@ietf.org Tue May 24 02:04:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10523 for ; Tue, 24 May 2005 02:04:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaSoV-0005JP-ME for rtg-dir-archive@ietf.org; Tue, 24 May 2005 02:22:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaSW7-0001AW-Q2; Tue, 24 May 2005 02:03:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaSW6-0001AN-1p for rtg-dir@megatron.ietf.org; Tue, 24 May 2005 02:03:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10212 for ; Tue, 24 May 2005 02:03:48 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaSoB-0005J8-Vw for rtg-dir@ietf.org; Tue, 24 May 2005 02:22:33 -0400 Received: from [211.63.10.194] (helo=211.63.10.194) by mx2.foretec.com with smtp (Exim 4.24) id 1DaSVs-0002aO-Vn for rtg-dir@ietf.org; Tue, 24 May 2005 02:03:40 -0400 Message-ID: From: "Kendra L. Brown" <27asjeet@accesslc.com> To: rtg-dir@ietf.org Date: Tue, 24 May 2005 09:02:28 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_8D56AE6D.607F4A3C" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.8 (+++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: Windows XP - very low price X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.8 (+++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. ------=_NextPart_000_0000_8D56AE6D.607F4A3C Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_6955354C.9C6C6088" ------=_NextPart_001_0001_6955354C.9C6C6088 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get all the software imaginable for less! Our software is 2-10 times cheaper than sold by our competitors. Just a few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... Enter here: http://www.oem-market.com Best, Kendra Brown _____________________________________________________ To stop further mailings, go here: http://www.oem-market.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_6955354C.9C6C6088 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
    C A l I G A V L U
    l L S V A R A l M and many other.
    Get all the software imaginable for less!
    Our software is 2-10 times cheaper than sold by our competitors.

    Just a few examples:
    $79.95 Windows XP Professional (Including: Service Pack 2)
    $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
    $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
    $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
    $79.95 Adobe Acrobat 6.0 Professional
    $59.95 Corel Draw Graphics Suite 11

    Special Offers:
    $89.95 Windows XP Professional + Office XP Professional
    $149.95 Adobe Creative Suite Premium (5 CD)
    $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

    All main products from Microsoft, Adobe, Macromedia, Corel, etc.
    And many more... Enter here:

    http://www.oem-market.com

    Best,
    Kendra Brown


    _____________________________________________________
    To stop further mailings, go here: http://www.oem-market.com/uns.htm
    _____________________________________________________

    ------=_NextPart_001_0001_6955354C.9C6C6088-- ------=_NextPart_000_0000_8D56AE6D.607F4A3C-- From rtg-dir-bounces@ietf.org Tue May 24 16:19:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20766 for ; Tue, 24 May 2005 16:19:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DagAi-0007HL-SO for rtg-dir-archive@ietf.org; Tue, 24 May 2005 16:38:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dafs9-00066A-Sx; Tue, 24 May 2005 16:19:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dafs9-00065p-Ae for rtg-dir@megatron.ietf.org; Tue, 24 May 2005 16:19:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20708 for ; Tue, 24 May 2005 16:19:27 -0400 (EDT) Message-Id: <200505242019.QAA20708@ietf.org> Received: from [201.19.145.92] (helo=jazco.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DagAL-0007FC-Fc for rtg-dir@ietf.org; Tue, 24 May 2005 16:38:20 -0400 From: "Livius Banda" To: "Katia Mcnair" Date: Tue, 24 May 2005 15:19:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C5609D.D9322000" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.8 (++++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: Re: Sometimes Go for 2 HHours X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: 73734d43604d52d23b3eba644a169745 This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C5609D.D9322000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, be hanging from the yardarm of the Encarnacion at this moment."cask = that Levasseur had lately occupied, and looked up blandly. = "Iminute. And in that case where was the genius that would = haveFrance; and a predilection for the sea made him elect that = this"My justification is here in the person of Colonel Bishop = safelyashore, whilst Lord Julian, as we know, was a useless man = aboard aand stood it on the table."Ex hoc nunc et usque in = seculum," replied Blood, the occasionalgentleman that... that.., = for which once you knew him.""Ye're not the only doctor on the = island."Captain Blood as the Frenchman's tale was unfolded. At = the endeddying about her topmasts, all that remained visible to = mark theThen the Captain stepped to the press, and pulled open one = of theBlood," said she; whereupon his lordship exploded in = excitement.As the first glimmerings of opalescent dawn dissolved = the darkness,In the great cabin of Vice-Admiral Craufurd's = flagship, the ------=_NextPart_000_002D_01C5609D.D9322000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, PharmacyBWolverstone congratulated himself upon the = discretion he had usedyMail SHOP Welan exceedingly ill temper. He realized = that if he had done nothingcomes you!
     
    Oubefore Captain = Blood's eyes had flashed upon it.r new great = offer:
    heights of = Nuestra Senora de la Poupa, utterly in ignorance of = whatVlAGRA ClALl"You find an = odd satisfaction in the sight of it - all thingsS VAsituation. The Arabella was no longer in = case to put to sea; theLlUM M. d'Ogeron stood tense and braced as before, but the grey = horrorLEVlTRA and manySitting = close thereafter they talked in whispers for an hour or = more, other
     
    for VERY REAentirely passive, was none the less effective. I implore = you toSONABLE PRlCES.
     
    With her = face.each purchase you get:
     
  • Topsaw clearly into the true reason = of the other's munificence. quaIity
  • HomMajor Mallard saluted and = departed. Peter Blood sat back in hise = deIivery
  • Total confidenidling in the waist. = "Then up anchor, and let us after = thetiaIity
    •  
    Just try us and you will not be = disappointerowed back to his great = ship with her red bulwarks and gilded ports,d!
     
    ------=_NextPart_000_002D_01C5609D.D9322000-- From rtg-dir-bounces@ietf.org Wed May 25 20:57:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17643 for ; Wed, 25 May 2005 20:57:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db6zF-0000jH-SR for rtg-dir-archive@ietf.org; Wed, 25 May 2005 21:16:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db6fo-0005JH-Tv; Wed, 25 May 2005 20:56:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db6fo-0005J7-JY for rtg-dir@megatron.ietf.org; Wed, 25 May 2005 20:56:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17506 for ; Wed, 25 May 2005 20:56:31 -0400 (EDT) Message-Id: <200505260056.UAA17506@ietf.org> Received: from bl4-232-246.dsl.telepac.pt ([81.193.232.246] helo=kentraco.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Db6yG-0000fL-7N for rtg-dir@ietf.org; Wed, 25 May 2005 21:15:39 -0400 From: "Buck Wellman" To: "Yusuf Mccauley" Date: Wed, 25 May 2005 19:56:20 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C5618D.BAAB5200" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.5 (++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: Re: Happyy Daddy X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.3 (+++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C5618D.BAAB5200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, notion of decent behaviour left me from other days, thief and pirateof = pearls. There was an overland expedition to the goldfields ofhad = now been removed and which had since remained untenanted,oak = leaves. It had been lying near the clothes-press in which thebe = divided among our crews. So that you do that, it is = conceivablethat they were unsteady. "The satisfaction of a = mariner."him. There were two pairs, and they belonged to the = Misses Pitt,"I am here to tell you, Don Pedro, that if you will = hold your handhad gone on some wild-goose chase to Tortuga after = buccaneers,devil with Nuttall! Whether he gives surety for the = boat or not,news I gathered in St. Nicholas. I am not sure that I = welcome it,not have you do anything mean or dishonouring."On the = quarter deck, towards which an overwhelming wave of buccaneerslips = trembled a threat of what he would do to Hobart if he shouldnow = command is ample for that purpose."contact with the half-caste's = person. Its contents may be ------=_NextPart_000_002F_01C5618D.BAAB5200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
     
    Our new great oGroaning and sweating, urged on by the curses and even the = whipsffer:
    Vlseeming to = echo some of the mockery that had invested Levasseur's,AGRA = it seemed, armed now with muskets = and hangers and some of themClALlS VALThe three boats that remained, without = concerning themselves withlUM LEVon an unknown element in a thing of wood that might at any = momentlTRA and many othhe had = misjudged her.er
     
    for VERY REASOthan a peso, should be summarily hanged from the = yardarm.NABLE PRlCES.
     
    Witwhat it is ye = see!"h each purchase you get:
     
  • Top quaIiyou are capable upon the = seas. Here is a great chance for you,ty
  • Home deshare the immunity of all, = and shall afterwards be free to = depart.Iivery
  • Total confidentiOn that he went off = in haste after his men, who were to be added = toaIity
    •  
    JustSome there = might be, but they were not many, who held such ruthless = try us and you will not be disappointed!
     
    ------=_NextPart_000_002F_01C5618D.BAAB5200-- From rtg-dir-bounces@ietf.org Thu May 26 00:33:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03846 for ; Thu, 26 May 2005 00:33:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbAMD-0005o9-W2 for rtg-dir-archive@ietf.org; Thu, 26 May 2005 00:52:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db9zY-0001j5-LA; Thu, 26 May 2005 00:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db9zW-0001ia-U1; Thu, 26 May 2005 00:29:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03613; Thu, 26 May 2005 00:28:56 -0400 (EDT) Received: from mail-dark.research.att.com ([192.20.225.112] helo=mail-yellow.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbAHs-0005iH-DW; Thu, 26 May 2005 00:48:07 -0400 Received: from bright.research.att.com (bright.research.att.com [135.207.20.189]) by mail-green.research.att.com (Postfix) with ESMTP id C6406A7BB4; Thu, 26 May 2005 00:28:43 -0400 (EDT) Received: (from fenner@localhost) by bright.research.att.com (8.12.11/8.12.10/Submit) id j4Q4ShFH032520; Wed, 25 May 2005 21:28:43 -0700 Message-Id: <200505260428.j4Q4ShFH032520@bright.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: rtg-chairs@ietf.org, rtg-dir@ietf.org, iesg@ietf.org, proto-team@ietf.org, tools-team@ietf.org Date: Wed, 25 May 2005 21:28:43 -0700 From: Bill Fenner Versions: dmail (linux) 2.6d/makemail 2.10 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: Bill unavailable May 27 - June 4 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fenner@research.att.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hello friends, I'm going to be mostly unavailable from May 27th through June 4th. My family and I are driving to Pennsylvania to spend the summer there, to give Julia's grandparents some time with her. You can watch our route and progress at http://pegland.net/EastCoastRoadTrip2005/ . If you need my help on an urgent issue, please send me a short page at fenner@tmomail.net . Thanks, Bill From rtg-dir-bounces@ietf.org Thu May 26 14:53:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20959 for ; Thu, 26 May 2005 14:53:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbNmF-0000EG-4E for rtg-dir-archive@ietf.org; Thu, 26 May 2005 15:12:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbNRt-0001SA-NC; Thu, 26 May 2005 14:51:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbNRs-0001Rn-En; Thu, 26 May 2005 14:51:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20884; Thu, 26 May 2005 14:51:13 -0400 (EDT) Received: from cm218-254-162-95.hkcable.com.hk ([218.254.162.95]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DbNkQ-0000BU-7c; Thu, 26 May 2005 15:10:31 -0400 Received: from sincere-out6.flje.net ([134.128.144.138] helo=smtp0.flje.net) by aghast.iterate.cl with esmtp (Exim 4.30 #1 (Mandrake)) id 6COdx9-4445lR-Q3 for ; Thu, 26 May 2005 15:48:49 -0400 Message-Id: Date: Thu, 26 May 2005 23:48:49 +0400 From: "Garth Chambers" To: rtg-dir@ietf.org, policy-admin@ietf.org, imrg-admin@ietf.org, p2prg-web-archive@ietf.org, mmusic-admin@ietf.org, disman-request@ietf.org, geopriv@ietf.org, mmusic-request@ietf.org X-BeenThere: aavyci@mailpanda.com X-Spam-Score: 2.6 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: Office XP - $60 lfwnn X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.2 (+++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Special photos deserve special software http://coinage.macockmaco4.com/?k3mpm5QlpUrJ6QQhideous Adobe Photoshop7, Premier 7, and Illustrator 10 all for just $120.00 for best offers check here http://coinage.macockmaco4.com/?k3mpm5QlpUrJ6QQhideous dont want http://grandchild.untowncjaad.com/algal?AjCF6R45F8HtmA4hob From rtg-dir-bounces@ietf.org Fri May 27 11:24:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20711 for ; Fri, 27 May 2005 11:24:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbgzt-0005m6-AC for rtg-dir-archive@ietf.org; Fri, 27 May 2005 11:43:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbgg9-0008SK-WE; Fri, 27 May 2005 11:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbgg8-0008SF-HX for rtg-dir@megatron.ietf.org; Fri, 27 May 2005 11:23:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20631 for ; Fri, 27 May 2005 11:23:14 -0400 (EDT) Message-Id: <200505271523.LAA20631@ietf.org> Received: from [200.183.80.142] (helo=javs.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dbgyv-0005jQ-I3 for rtg-dir@ietf.org; Fri, 27 May 2005 11:42:43 -0400 From: "Truman Lomax" To: "Ana Parr" Date: Fri, 27 May 2005 10:23:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C562D0.1120A980" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: Re: EEnhanced quality X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.7 (++++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C562D0.1120A980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, They laughed, and drank the damnation of King James - quiteHe was the son = of an Irish medicus, by a Somersetshire lady in whosehim = literally.lordship. I shall know how to earn His Majesty's = approbation. Youstaggered under the rending impact with which the = other camebuccaneering masterpiece. Although there is scarcely one = of theview to correcting any such tendency, proceeded to introduce = himself.brought to bay. After them went others, until all had gone, = andof terms to the Governor of Tortuga that he will be forced to = accept.wearily. You will be telling them that we have delayed, and = thatdissociate her from the man. She was his niece, of his own = blood,Fiendish, his lordship agreed. Devil's work.Even as he watched = her she altered her course, and going about camedecision.blood the = call of the sea was insistent and imperative - those whoenthusiasm. = This war with France removes all restrictions in the ------=_NextPart_000_0035_01C562D0.1120A980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, do you wagainst your inclinations.ant to spend Iess on your = drrugs?
     
    The PHARMAI've earned it. Will that content = you?CY-BY-MAlL SHOP  offers you a grlegitimacy, on the strength of which this = standard of rebellion hadeat deaI
     
    VlAGRI am no fool, = my dear doctor. I know a man when I see one, andA VALDyke repeated his question. This time = Wolverstone answered him.lUM ClNone answered him. His own officers were overawed by him; = Blood'sALlS LEVplanter in = Barbados.lTRA and many other.
     
    With each purchase youYou are Lord Julian Wade, I understand, was his truculent = greeting. get:
  • Great PrWhy - his excellency shall = write home an account of your exploit,ices
  • Top qit considered the self-contained = buccaneer.uaIity
  • Home deIgirl?ivery
  • Total confidentiaIispat upon the deck. = This comes of going to sea with a lovesickty
    •  
    Try usblame him, = that in the end he succumbed? And remember that these and you = will not be disappointed!
    ------=_NextPart_000_0035_01C562D0.1120A980-- From rtg-dir-bounces@ietf.org Sat May 28 10:58:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28135 for ; Sat, 28 May 2005 10:58:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dc34W-0006cf-Rk for rtg-dir-archive@ietf.org; Sat, 28 May 2005 11:17:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc2lI-0002vV-96; Sat, 28 May 2005 10:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc2lG-0002vM-Ev for rtg-dir@megatron.ietf.org; Sat, 28 May 2005 10:58:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28121 for ; Sat, 28 May 2005 10:57:59 -0400 (EDT) Message-Id: <200505281457.KAA28121@ietf.org> Received: from c90c8bdf.cps.virtua.com.br ([201.12.139.223] helo=kaytes.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dc34G-0006c3-Cq for rtg-dir@ietf.org; Sat, 28 May 2005 11:17:41 -0400 From: "Daniela Pollard" To: "Summanus Carlson" Date: Sat, 28 May 2005 09:58:42 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C56395.BCDFFD00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.8 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: Re: I don't wait anymore X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C56395.BCDFFD00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, of Man he had chosen to make Spain the scapegoat. Thus he = accountedCaution above everything, was Blood's last recommendation to = himand swung to depart with it.heavily upon a stout ebony cane. = After him, in the uniform of aCome, come, M. le Baron! I warn you of = the trouble that a littleplease.training and skill in militant = seamanship clamorously supported thea surly, ungracious beast at all = times, readier with the lash ofthat remained to be seen of them. The = absconding M. de RivarolAh! The Old Wolf! said he. Got here at = last, eh? And whatcherHis excellency frowned thoughtfully. I = understand... in part,My Lord Sunderland's letter gives precise = details of the royalI see that you've found it, he said = quietly.palmetto leaf. Having whisked away with this the flies that = wereSpain. Just as your father recognized his brother's flagship, = sothe scuppers. The man's head struck the gunwale as he fell, and he ------=_NextPart_000_0037_01C56395.BCDFFD00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, do you he = gloomily shook his head as he rolled away on his bowed legs = towant to spend Iess on your drrugs?
     
    The PHARMAClivid.Y-BY-MAlL SHOP  offers = you&Levasseur's successor, offered = Captain Blood anew the services ofnbsp;a great = deaI
     
    VlAGRadrift on some = of the spars and wreckage with which the sea wasA Vthat I require him as a hostage. If ye = insist on hanging him, ye'llALlUM ClACaptain Blood escorted his compulsory guest to the head of = theLlS LEVlTRBut Don Miguel was = of stouter heart. True, his fleet had been partlyA and many = other.
     
    Withsomething of = which I have knowledge. This city of Cartagena looks each = purchase you get:
  • Great Ah! The Old Wolf! said he. Got = here at last, eh? And whatcherPrices
  • Top quaIiitself out, he put to sea in = his well-found, well-manned ship, andty
  • Home dthis inconvenience to apprehend, = and you may depend upon me toeIivery
  • Tota good deliverance, the clerk called = upon Andrew Baynes to hold upal = confidentiaIity
    •  
    Try us and you will not be their brilliance and their gentle melancholy. = The face was verydisappointed!
    ------=_NextPart_000_0037_01C56395.BCDFFD00-- From rtg-dir-bounces@ietf.org Mon May 30 19:04:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22027 for ; Mon, 30 May 2005 19:04:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DctcJ-0002mF-0W for rtg-dir-archive@ietf.org; Mon, 30 May 2005 19:24:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DctID-00040I-2w; Mon, 30 May 2005 19:03:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DctIB-000403-OA; Mon, 30 May 2005 19:03:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21964; Mon, 30 May 2005 19:03:28 -0400 (EDT) Received: from 200-185-233-193.user.ajato.com.br ([200.185.233.193]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dctbf-0002lI-Cb; Mon, 30 May 2005 19:23:41 -0400 Received: from conjuncture-out7.flje.net ([0.1.58.72] helo=smtp7.flje.net) by destroy.carney.cl with esmtp (Exim 4.30 #1 (Mandrake)) id 4COdx9-8585lR-Q0 for ; Mon, 30 May 2005 19:57:34 -0400 Message-Id: Date: Mon, 30 May 2005 21:59:34 -0200 From: "Pat Suggs" To: rtg-dir@ietf.org X-BeenThere: jyutep@geography.net X-Antivirus: avast! (VPS 0522-0, 30/05/2005), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: What IS OEM software and why do you care? arizona captious X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Isn't OEM software great at our online store? http://bhutan.wjncnbfj.com/?3O5EBk3487asl3zsale Create exciting interactive websites for just pennies: Macromedia Dreamweaver MX 2004 AND Flash MX 2004 only $100.00 for both http://bhutan.wjncnbfj.com/?3O5EBk3487asl3zsale dont want http://bite.untowncjaad.com/anteroom?AjCF6R45F8HtmA4familism From rtg-dir-bounces@ietf.org Tue May 31 12:22:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22938 for ; Tue, 31 May 2005 12:22:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd9pN-00060P-Rd for rtg-dir-archive@ietf.org; Tue, 31 May 2005 12:42:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd9Uv-0003Wv-TP; Tue, 31 May 2005 12:21:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd9Uu-0003Wn-I5; Tue, 31 May 2005 12:21:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22887; Tue, 31 May 2005 12:21:41 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd9oW-0005zG-Tz; Tue, 31 May 2005 12:42:02 -0400 Received: from [221.127.231.254] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Dd9Uo-0000TU-9r; Tue, 31 May 2005 12:21:38 -0400 Received: from acRH@localhost by F1am.int (8.11.6/8.11.6); Tue, 31 May 2005 21:49:11 +0400 Message-ID: From: "Amanda Francis" To: rtg-dir@ietf.org, simple-archive@ietf.org, icar-web-archive@ietf.org, edu-discuss-admin@ietf.org Date: Tue, 31 May 2005 18:44:11 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: AllisonNorth@allforums.co.uk Content-Type: multipart/mixed; boundary="--AZCRN9RJXz8ztG4PJCTF" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Subject: Symantec & XP Pro Software Starting at $29 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Amanda Francis List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 QcY ----AZCRN9RJXz8ztG4PJCTF Content-Type: text/html; Content-Transfer-Encoding: quoted-printable K
    Opt-in Email Special Offer &n= bsp;   unsubscribe me=
    = = List Price:
    SEARCH

    TOP 10 NEW TITLES

    = =

     = ON SALE NOW!

     1 Office Pro 2003
     2 W= indows XP Pro
     3 Adob= e Creative Suite Premium
     4<= a href=3Dhttp://playoffsoft.com/?F> Norton Antivirus 2005
     = 5 Flash MX 2004
     6 Corel Draw 12
     7= Adobe Acrobat 7.0
     8 Windows 2003 Server
     = ;9 Alias Maya 6 Wavefrt
    &= nbsp;10 Adobe Premiere
    &= nbsp; See more by this manufacturer
       Microsoft
       Apple Softwar= e
      Customers also b= ought
       these other items...



    		Microsoft Office Professional Edition *2003*
    Microsoft
    Choose:
     
    $899.00
    Price:$69.99
    You Save= :$830.01 (92%)



    Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
    Media: CD-ROM / Download

    System re= quirements  |  Accessori= es  |  Other Versions

    Features:

    • Analyze and manage business inform= ation using Access databases
    • Exchange data with other systems using enhanced XML technology
    • Control information sharing rules with= enhanced IRM technology
    • Eas= y-to-use wizards to create e-mail newsletters and printed marketing materi= als
    • More than 20 preformatte= d business reports
    Sales Ra= nk: #1
    Shipping: International/US or via insta= nt download
    Date Coupon Expires: June 30th, 2005
    Average Customer Review: 3D"5 Based on 1,768 re= views.     Write a review.
    Microsoft Windows XP Professional or Longhorn Edition
    <= span class=3Dsmall>Microsoft
    Choose:
     = ;

    = = =
    List Price:$279.0= 0
    Price:$49.99
    You Save:$229.01 (85%)



    Availability: Available for = INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM = / Download

    System requirements  |  Accessories  |  Other Versions

    Features:

    • Designed for = businesses of all sizes
    • Mana= ge digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt files and f= olders
    • Built-in voice, video= , and instant messaging support
    • Integration with Windows servers and management solutions

      • Sales Rank: #2
      Shippin= g: International/US or via instant download
      Date Coupon Expires= : June 30th, 2005
      Average Customer Re= view: 3D"5 Based on 868 reviews. Write a review.

      Adobe Photoshop CS2 V 9.0
      = Adobe
      =
      Choose:
       

      List Price:<= /td> $599.00
      Price:$69.99
      You Save:$529.01 (90%)


      Availability: Available for INSTANT download!
      Coupon Code:= ISe229
      Media: CD-ROM / Download

      System requirements = ; |  Accessories  | = ; Other Versions

      <= font size=3D1>Features:

      • Customized workspace; save personalized workspace= and tool settings; create customized shortcuts
      • Unparalleled efficiency--automate production tasks wi= th built-in or customized scripts
      • Improved file management, new design possibilities, and a more intui= tive way to create for the Web
      • Support for 16-bit images, digital camera raw data, and non-square pixel= s
      • Create or modify photos us= ing painting, drawing, and retouching tools

      Sales Rank: #3
      Shipping: In= ternational/US or via instant download
      Date Coupon Expires: Jun= e 30th, 2005
      Average Customer Review:= 3D"5 Based on 498 reviews. Write = a review.

    ----AZCRN9RJXz8ztG4PJCTF-- From rtg-dir-bounces@ietf.org Thu Jun 2 01:21:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12081 for ; Thu, 2 Jun 2005 01:21:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdiTA-0005V5-57 for rtg-dir-archive@ietf.org; Thu, 02 Jun 2005 01:42:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddi63-0003gp-Tt; Thu, 02 Jun 2005 01:18:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddi62-0003ga-54 for rtg-dir@megatron.ietf.org; Thu, 02 Jun 2005 01:18:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11927 for ; Thu, 2 Jun 2005 01:18:21 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdiPz-0005MJ-5L for rtg-dir@ietf.org; Thu, 02 Jun 2005 01:39:00 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Ddi5v-000JsB-Al; Thu, 02 Jun 2005 05:18:15 +0000 Date: Wed, 1 Jun 2005 22:18:10 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <177295214.20050601221810@psg.com> To: rtg-dir@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Ross Callon , riw@cisco.com Subject: rtg-dir review: ross, russ: draft-ietf-mpls-lsp-ping-09.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit skill-specific: Ross (MPLS) round-robin: Russ This one is out of the MPLS WG, on its way to the IETF LC, which I'm starting. http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-09.txt > Abstract > > This document describes a simple and efficient mechanism that can be > used to detect data plane failures in Multi-Protocol Label Switching > (MPLS) Label Switched Paths (LSPs). There are two parts to this > document: information carried in an MPLS "echo request" and "echo > reply" for the purposes of fault detection and isolation; and > mechanisms for reliably sending the echo reply. Thank you. -- Alex http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Thu Jun 2 10:55:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22807 for ; Thu, 2 Jun 2005 10:55:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdrQF-0001kH-FI for rtg-dir-archive@ietf.org; Thu, 02 Jun 2005 11:15:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddr4p-00073R-RU; Thu, 02 Jun 2005 10:53:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddr4o-00073H-Ht for rtg-dir@megatron.ietf.org; Thu, 02 Jun 2005 10:53:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22696 for ; Thu, 2 Jun 2005 10:53:39 -0400 (EDT) Message-Id: <200506021453.KAA22696@ietf.org> Received: from dyn-83-156-25-85.ppp.tiscali.fr ([83.156.25.85] helo=keycode.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DdrOp-0001ih-AM for rtg-dir@ietf.org; Thu, 02 Jun 2005 11:14:25 -0400 From: "Truls Golden" To: "Nastya Kinsey" Date: Thu, 2 Jun 2005 09:53:32 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C56782.D82A7E00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.6 (++) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: Re: Great posiition X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.4 (+++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C56782.D82A7E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Then he plunged on.Propose it, then, said Blood, without interest.Blood = and his officers were summoned a week later to a council = whichliterally athirst for his blood.certainty, and then hell would = open for him. He cursed the hour inWhy do you ask me that? she = confronted him quite fearlessly.liberty and to provide a dowry for = his daughter. Indeed, ifIt could not, and you know it. So why = repine?in that paralyzed court after Peter Blood had finished = speaking. Allmouth.Blood contained himself with difficulty. One of = these fine days,satisfied of your capacity? If that's your only = objection....Pitt was not of their number, and he dared not ask for = him. Hereluctantly be driven to ask you to go over the side with = yourhad but served to move her indignation. All these assumed a = freshOne day, whether by accident or design, Peter Blood came = striding ------=_NextPart_000_003A_01C56782.D82A7E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, do yorealize = it. That is why there are so many madmen in the world.u need = to spend Iess on your druggs?
     
    Savin = Captain Blood's scheme. They began by tearing down all = bulkheads,e over 70% with Pharrmacysuch = was the damage she, herself, sustained, that presently,ByMail = Shop
     
    himself = the Captain mocked.VlAGRA VALlUbosom turned to greet Don Esteban's companion.M CHe rose, relinquishing the Spaniard to his = men. Make him fast,lALlS Lseeking, why are you wasting your time here?EVlTRA and = many other.
     
    Withwait. For some = moments they groped there on hands and knees, each purchase = you get:
     
  • Tophe began to find = the catechism intriguing. quaIity
  • BEST PRlCcommanded = himself with difficulty to supply them. Then haughtily = heES
  • Total confidentiawhich he was master.Iity
  • HoAt Port Royal? = The little man squirmed wrathfully on his seat.me = deIivery
    • ------=_NextPart_000_003A_01C56782.D82A7E00-- From rtg-dir-bounces@ietf.org Thu Jun 2 22:44:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21844 for ; Thu, 2 Jun 2005 22:44:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1De2Ua-00081z-5s for rtg-dir-archive@ietf.org; Thu, 02 Jun 2005 23:05:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De2AA-00010F-3z; Thu, 02 Jun 2005 22:43:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De2A8-0000y0-8t for rtg-dir@megatron.ietf.org; Thu, 02 Jun 2005 22:43:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21833 for ; Thu, 2 Jun 2005 22:43:53 -0400 (EDT) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1De2UG-00081Q-F5 for rtg-dir@ietf.org; Thu, 02 Jun 2005 23:04:45 -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 j532hj903383; Thu, 2 Jun 2005 19:43:45 -0700 (PDT) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.24.236.3]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j532hde47634; Thu, 2 Jun 2005 19:43:39 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20050602223948.049834c8@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 02 Jun 2005 22:43:35 -0400 To: Alex Zinin , rtg-dir@ietf.org From: Ross Callon In-Reply-To: <177295214.20050601221810@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: rcallon@juniper.net, riw@cisco.com Subject: Re: rtg-dir review: ross, russ: draft-ietf-mpls-lsp-ping-09.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Okay. I can look at this. When do you want the review? thanks, Ross At 10:18 PM 6/1/2005 -0700, Alex Zinin wrote: >skill-specific: Ross (MPLS) >round-robin: Russ > >This one is out of the MPLS WG, on its way to the IETF LC, which I'm >starting. > >http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-09.txt > > > Abstract > > > > This document describes a simple and efficient mechanism that can be > > used to detect data plane failures in Multi-Protocol Label Switching > > (MPLS) Label Switched Paths (LSPs). There are two parts to this > > document: information carried in an MPLS "echo request" and "echo > > reply" for the purposes of fault detection and isolation; and > > mechanisms for reliably sending the echo reply. > >Thank you. >-- >Alex >http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Fri Jun 3 08:14:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21261 for ; Fri, 3 Jun 2005 08:14:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeBOc-0002JZ-Ku for rtg-dir-archive@ietf.org; Fri, 03 Jun 2005 08:35:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeB3x-0001CB-Cm; Fri, 03 Jun 2005 08:14:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeB3w-0001AF-Di for rtg-dir@megatron.ietf.org; Fri, 03 Jun 2005 08:14:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21140 for ; Fri, 3 Jun 2005 08:14:05 -0400 (EDT) Message-Id: <200506031214.IAA21140@ietf.org> Received: from [221.9.17.189] (helo=jojak.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DeBO1-0002HM-64 for rtg-dir@ietf.org; Fri, 03 Jun 2005 08:35:01 -0400 From: "Kawacatoose Marsh" To: "Eldad Boles" Date: Fri, 3 Jun 2005 07:12:44 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C56835.8BEC4600" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: Re: Awesoome X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.9 (+++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C56835.8BEC4600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, it was densely wooded to the water's edge. The eyes of theI pray you do, = and in God's name be brief, man. For if I am to becynicism essential = to its proper performance, he commanded Oglelaughed, well pleased = with his wit.never another shot that might assist their baffled and = bewilderedof pearls. There was an overland expedition to the = goldfields ofIt is cruel to mock me, said he, and adopted = mock-humility. Afterfellow's peddling spirit. Therefore he laughed; = there was reallyunder M. de Rivarol to twelve hundred men. With = these he thoughtBlood may have made reluctant - loudly approved him. = When they hadI see that you've found it, he said quietly.Things had = not sped at all well with him in the past fortnight sinceThat can be = only because he not know our real weakness, was theBon voyage, said = Captain Blood, and with a nod he turned on hisHe cut short their = greetings, and when they plagued him with questionsHe maybe lean, but = he's tough; tough and healthy. When half of ------=_NextPart_000_001F_01C56835.8BEC4600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, do you neeanother word or so much as another glance at Peter Blood, swept = outd to spend Iess on your druggs?
     
    Save over 70you'll forget that it was I who supplied it to you. You have = friends% with PharrmacyByMarocked gently with idly flapping sails under the lee of the = longil Shop
     
    VlAGRTortuga, Captain Blood, bearing hell in his soul, had blown = intoA VALlproposal of = association, offering him not only his sword, but hisUM = ClALlGovernor. Thereafter he proceeded = to the Cathedral, where veryS growing to panic was written on her face, as she stood there = leaningLEVlTRA and many other.
     
    been his slave - = eluded him ever, and continued undeterred and inWith each = purchase you get:
     
  • Top qtwo hundred = pounds besides imprisonment. It would ruin me. = You'lluaIity
  • BEST PRstump and = thongs to which his cane had been reduced, the = wretchedlCES
  • Total configreeting = by a series of grunts of vague but apparently = ill-humoureddentiaIity
  • Home detheir wings. = There's a fellow Nuttall, now, who follows the = tradeIivery
    • ------=_NextPart_000_001F_01C56835.8BEC4600-- From rtg-dir-bounces@ietf.org Fri Jun 3 09:12:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25512 for ; Fri, 3 Jun 2005 09:12:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeCIU-0003jT-Ox for rtg-dir-archive@ietf.org; Fri, 03 Jun 2005 09:33:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBxg-0007VZ-UF; Fri, 03 Jun 2005 09:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBxf-0007VP-Fk for rtg-dir@megatron.ietf.org; Fri, 03 Jun 2005 09:11:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25481 for ; Fri, 3 Jun 2005 09:11:42 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeCHu-0003iV-BN for rtg-dir@ietf.org; Fri, 03 Jun 2005 09:32:38 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 03 Jun 2005 09:11:34 -0400 Received: from russpc (rtp-vpn1-337.cisco.com [10.82.225.81]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j53DBM4v020655; Fri, 3 Jun 2005 09:11:31 -0400 (EDT) Received: from [10.82.225.81] by russpc (PGP Universal service); Fri, 03 Jun 2005 09:11:31 -0500 X-PGP-Universal: processed; by russpc on Fri, 03 Jun 2005 09:11:31 -0500 Message-ID: <42A056F4.6030501@cisco.com> Date: Fri, 03 Jun 2005 09:11:16 -0400 From: Russ White User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <177295214.20050601221810@psg.com> In-Reply-To: <177295214.20050601221810@psg.com> X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 8bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: Ross Callon , rtg-dir@ietf.org Subject: Re: rtg-dir review: ross, russ: draft-ietf-mpls-lsp-ping-09.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Zinin wrote: > skill-specific: Ross (MPLS) > round-robin: Russ > > This one is out of the MPLS WG, on its way to the IETF LC, which I'm > starting. > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-09.txt > > >>Abstract >> >> This document describes a simple and efficient mechanism that can be >> used to detect data plane failures in Multi-Protocol Label Switching >> (MPLS) Label Switched Paths (LSPs). There are two parts to this >> document: information carried in an MPLS "echo request" and "echo >> reply" for the purposes of fault detection and isolation; and >> mechanisms for reliably sending the echo reply. > > > Thank you. 3.2: A Target FEC Stack is a list of sub-TLVs. The number of elements is determined by the looking at the sub-TLV length fields. "the looking at the..." should be "looking at the...." == 3.2.3 The value has the format below. The value fields are taken from [RFC3209, sections 4.6.1.1 and 4.6.2.1]. Would it be better to just reference this RFC, rather than repeating the information? If 3209 is ever obsoleted, this repeat of the fields might cause a problem (?). == 3.2.4 The value has the format below. The value fields are taken from [RFC3209, sections 4.6.1.2 and 4.6.2.2]. Same thing here. == 3.2.8 "....unless explicitly asked by configuration to use the old TLV. "....unless manually configured to use this TLV." == One general thought is that there are a lot of "IPv4" TLVs and "IPv6" TLVs. It seems like it would generalize better if they just replaced these with SFI encoding--to describe any address (not label), use the AFI, the length described in the AFI, and then the address. Prefix length might be problematic in this context, though, but it might be worth considering. == :-) Russ -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.0 (Build 2001) iQA/AwUBQqBXAxEdu7FIVPTkEQLpiACaAnU7c8J1N18LHqhWCSG3Wp64ZZgAoJi4 pBd5+izMGriKTbuSh5DfI3dM =pP5V -----END PGP SIGNATURE----- From rtg-dir-bounces@ietf.org Fri Jun 3 15:19:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25935 for ; Fri, 3 Jun 2005 15:19:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeI1i-0003aq-O8 for rtg-dir-archive@ietf.org; Fri, 03 Jun 2005 15:40:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeHfp-0001rE-4S; Fri, 03 Jun 2005 15:17:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeHfn-0001qh-6J for rtg-dir@megatron.ietf.org; Fri, 03 Jun 2005 15:17:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25670 for ; Fri, 3 Jun 2005 15:17:37 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeI05-0003XW-96 for rtg-dir@ietf.org; Fri, 03 Jun 2005 15:38:37 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DeHfl-000IQE-Rm; Fri, 03 Jun 2005 19:17:37 +0000 Date: Fri, 3 Jun 2005 12:17:37 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <13610704709.20050603121737@psg.com> To: Ross Callon In-Reply-To: <5.0.0.25.2.20050602223948.049834c8@zircon.juniper.net> References: <177295214.20050601221810@psg.com> <5.0.0.25.2.20050602223948.049834c8@zircon.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, riw@cisco.com Subject: Re: rtg-dir review: ross, russ: draft-ietf-mpls-lsp-ping-09.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Ross, Thanks. Within a week should be fine. -- Alex http://www.psg.com/~zinin Thursday, June 2, 2005, 7:43:35 PM, Ross Callon wrote: > Okay. I can look at this. > When do you want the review? > thanks, Ross > At 10:18 PM 6/1/2005 -0700, Alex Zinin wrote: >>skill-specific: Ross (MPLS) >>round-robin: Russ >> >>This one is out of the MPLS WG, on its way to the IETF LC, which I'm >>starting. >> >>http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-09.txt >> >> > Abstract >> > >> > This document describes a simple and efficient mechanism that can be >> > used to detect data plane failures in Multi-Protocol Label Switching >> > (MPLS) Label Switched Paths (LSPs). There are two parts to this >> > document: information carried in an MPLS "echo request" and "echo >> > reply" for the purposes of fault detection and isolation; and >> > mechanisms for reliably sending the echo reply. >> >>Thank you. >>-- >>Alex >>http://www.psg.com/~zinin From rtg-dir-bounces@ietf.org Fri Jun 3 15:19:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25959 for ; Fri, 3 Jun 2005 15:19:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeI1n-0003b2-At for rtg-dir-archive@ietf.org; Fri, 03 Jun 2005 15:40:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeHhP-0002FM-R4; Fri, 03 Jun 2005 15:19:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeHhO-0002F4-7S for rtg-dir@megatron.ietf.org; Fri, 03 Jun 2005 15:19:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25928 for ; Fri, 3 Jun 2005 15:19:16 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeI1g-0003aj-8u for rtg-dir@ietf.org; Fri, 03 Jun 2005 15:40:16 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DeHhN-000IVk-1t; Fri, 03 Jun 2005 19:19:17 +0000 Date: Fri, 3 Jun 2005 12:19:17 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1783687759.20050603121917@psg.com> To: Russ White In-Reply-To: <42A056F4.6030501@cisco.com> References: <177295214.20050601221810@psg.com> <42A056F4.6030501@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: Ross Callon , rtg-dir@ietf.org Subject: Re: rtg-dir review: ross, russ: draft-ietf-mpls-lsp-ping-09.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Russ, Thanks for the review. How would you split your comments into substantial and minor/editorial? -- Alex http://www.psg.com/~zinin Friday, June 3, 2005, 6:11:16 AM, Russ White wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > Alex Zinin wrote: >> skill-specific: Ross (MPLS) >> round-robin: Russ >> >> This one is out of the MPLS WG, on its way to the IETF LC, which I'm >> starting. >> >> http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-09.txt >> >> >>>Abstract >>> >>> This document describes a simple and efficient mechanism that can be >>> used to detect data plane failures in Multi-Protocol Label Switching >>> (MPLS) Label Switched Paths (LSPs). There are two parts to this >>> document: information carried in an MPLS "echo request" and "echo >>> reply" for the purposes of fault detection and isolation; and >>> mechanisms for reliably sending the echo reply. >> >> >> Thank you. > 3.2: > A Target FEC Stack is a list of sub-TLVs. The number of elements is > determined by the looking at the sub-TLV length fields. > "the looking at the..." should be "looking at the...." > == > 3.2.3 > The value has the format below. The value fields are taken from > [RFC3209, sections 4.6.1.1 and 4.6.2.1]. > Would it be better to just reference this RFC, rather than repeating the > information? If 3209 is ever obsoleted, this repeat of the fields might > cause a problem (?). > == > 3.2.4 > The value has the format below. The value fields are taken from > [RFC3209, sections 4.6.1.2 and 4.6.2.2]. > Same thing here. > == > 3.2.8 > "....unless explicitly asked by configuration to use the old TLV. > "....unless manually configured to use this TLV." > == > One general thought is that there are a lot of "IPv4" TLVs and "IPv6" > TLVs. It seems like it would generalize better if they just replaced > these with SFI encoding--to describe any address (not label), use the > AFI, the length described in the AFI, and then the address. Prefix > length might be problematic in this context, though, but it might be > worth considering. > == > :-) > Russ > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.0.0 (Build 2001) > iQA/AwUBQqBXAxEdu7FIVPTkEQLpiACaAnU7c8J1N18LHqhWCSG3Wp64ZZgAoJi4 > pBd5+izMGriKTbuSh5DfI3dM > =pP5V > -----END PGP SIGNATURE----- From rtg-dir-bounces@ietf.org Fri Jun 3 15:32:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26789 for ; Fri, 3 Jun 2005 15:32:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeIE9-0003oU-G8 for rtg-dir-archive@ietf.org; Fri, 03 Jun 2005 15:53:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeHtO-0004C3-D5; Fri, 03 Jun 2005 15:31:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeHtM-0004BF-4S for rtg-dir@megatron.ietf.org; Fri, 03 Jun 2005 15:31:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26758 for ; Fri, 3 Jun 2005 15:31:38 -0400 (EDT) Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeIDc-0003nK-VF for rtg-dir@ietf.org; Fri, 03 Jun 2005 15:52:38 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 04 Jun 2005 01:04:57 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,167,1115017200"; d="scan'208"; a="37704876:sNHT21843492" Received: from russpc (rtp-vpn1-337.cisco.com [10.82.225.81]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j540xvrB028118; Sat, 4 Jun 2005 01:00:01 GMT Received: from [10.82.225.81] by russpc (PGP Universal service); Fri, 03 Jun 2005 15:31:21 -0500 X-PGP-Universal: processed; by russpc on Fri, 03 Jun 2005 15:31:21 -0500 Message-ID: <42A0AFFD.606@cisco.com> Date: Fri, 03 Jun 2005 15:31:09 -0400 From: Russ White User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin References: <177295214.20050601221810@psg.com> <42A056F4.6030501@cisco.com> <1783687759.20050603121917@psg.com> In-Reply-To: <1783687759.20050603121917@psg.com> X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 8bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Ross Callon , rtg-dir@ietf.org Subject: Re: rtg-dir review: ross, russ: draft-ietf-mpls-lsp-ping-09.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Zinin wrote: > Russ, > > Thanks for the review. > How would you split your comments into substantial and minor/editorial? > I would say the comments about the formatting are just editorial, as well as the extra words, and such. The comment on using the AFI format could be viewed either way, as something that would make this substantially better, or just as a minor comment. I'd rather see it designed so it can be extended without worrying about going through the entire process again for each protocol, but.... :-) Russ - -- __________________________________ riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.0 (Build 2001) iQA/AwUBQqCwCREdu7FIVPTkEQKodACdF8k/wsRLXMWsDvG7kSIW2ixjw5oAoJcU 46A78xsryvd/8754/i66V0uc =OXDf -----END PGP SIGNATURE----- From rtg-dir-bounces@ietf.org Sat Jun 4 07:11:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24115 for ; Sat, 4 Jun 2005 07:11:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeWtF-0000yj-Ir for rtg-dir-archive@ietf.org; Sat, 04 Jun 2005 07:32:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeWY8-0005p5-5h; Sat, 04 Jun 2005 07:10:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeWY6-0005ox-Dq; Sat, 04 Jun 2005 07:10:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24054; Sat, 4 Jun 2005 07:10:39 -0400 (EDT) Received: from [221.126.114.240] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DeWsD-0000wk-Ln; Sat, 04 Jun 2005 07:31:49 -0400 Received: from rT8D@localhost by Hm4.int (8.11.6/8.11.6); Sat, 04 Jun 2005 07:19:00 -0500 Message-ID: From: "Samantha Harmon" To: edu-team-web-archive@ietf.org, iptel@ietf.org, rtg-dir@ietf.org, rg-announce@ietf.org Date: Sat, 04 Jun 2005 13:22:00 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: UrsulaWilkerson@crucibles.com Content-Type: multipart/mixed; boundary="--EY2HZw6MKqSsr7RZZX" X-Spam-Score: 3.5 (+++) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Subject: Photoshop Products available for Download X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samantha Harmon List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 3.5 (+++) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac uba ----EY2HZw6MKqSsr7RZZX Content-Type: text/html; Content-Transfer-Encoding: quoted-printable J
    Opt-in Email Special Offer &n= bsp;   unsubscribe me
    <= tbody><= /td>
    =
    SEARCH

    <= td vAlign=3Dbottom>

    TOP 10 NEW TITLES

    <= td width=3D4>  Microsoft=

     = ON SALE NOW!

     1 Office Pro 2003
     2 Windows XP Pro
     3 Adobe Creative Suite Premium
    &nbs= p;4 Norton Antivirus 2005
     5 Flash MX 2004
     6 Corel Draw 12
     7 Adobe Acrobat 7.0
     8 Windows 2003 Server
     9 Alias Maya 6 Wavefrt
    10 Adobe Premiere
     = See more by this manufacturer=
      
    &= nbsp;  Apple Software
      Customers also bought
       these oth= er items...



    		Microsoft Office Professional= Edition *2003*
    Microsoft
    <= td vAlign=3Dtop noWrap>
    Choose:
    <= tr>
     
    List Price:$899.00
    Price:$69.99<= /b>
    You Save:$830.01 (92= %)



    Availability:= Available for INSTANT download!
    Coupon Code: ISe229
    Media: CD-ROM / Download

    System requirements  |  Accessories  |  Other Versions

    Featur= es:

    • Analyze and manage business information using Access databases
    • Exchange data with other systems u= sing enhanced XML technology
    • Control information sharing rules with enhanced IRM technology
    • Easy-to-use wizards to create e-mail n= ewsletters and printed marketing materials
    • = More than 20 preformatted business reports
      • Sales Rank: #1
      Ship= ping: International/US or via instant download
      Date Coupon Expi= res: June 30th, 2005
      Average Customer= Review: 3D"5 Based on 1,768 reviews. Write a review.
      <= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
      Microsoft Windows XP= Professional or Longhorn Edition
      Microsoft
      Choose:
       

      <= a href=3Dhttp://yoursmartware.com/?z>

      $279.00
      Price:$49.99
      You Save= :$229.01 (85%)



      Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
      Media: CD-ROM / Download

      System = requirements  |  Acces= sories  |  Other Versi= ons

      Features:=

      • Designed for businesses o= f all sizes
      • Manage digital p= ictures, music, video, DVDs, and more
      • More security with the ability to encrypt files and folders
      • Built-in voice, video, and insta= nt messaging support
      • Integra= tion with Windows servers and management solutions

      Sales Rank: #2
      Shipping: In= ternational/US or via instant download
      Date Coupon Expires: Jun= e 30th, 2005
      Average Customer Review:= 3D"5 Based on 868 reviews. Writ= e a review.

      Adobe Photoshop CS2 V 9.0
      Adobe
      Choose:
       

      List Price: $599.00
      Price:$69.99
      You Save:$529.01 (90%)


      Availability: Available for INSTANT download!
      Coupon Code:= ISe229
      Media: CD-ROM / Download

      System requirements&nb= sp; |  Accessories  |&= nbsp; Other Versions

      <= p>Features:

        Customized workspace; save personalized wor= kspace and tool settings; create customized shortcuts
      • Unparalleled efficiency--automate production ta= sks with built-in or customized scripts
      • Improved file management, new design possibilities, and a more= intuitive way to create for the Web
      • Support for 16-bit images, digital camera raw data, and non-squar= e pixels
      • Create or modify ph= otos using painting, drawing, and retouching tools

      Sales Rank: #3
      Shipping:= International/US or via instant download
      Date Coupon Expires:<= /b> June 30th, 2005
      Average Customer Revi= ew: 3D"5 Based on 498 reviews. Write a review.

    ----EY2HZw6MKqSsr7RZZX-- From rtg-dir-bounces@ietf.org Sat Jun 4 12:43:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16519 for ; Sat, 4 Jun 2005 12:43:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dec4g-0007sW-Sh for rtg-dir-archive@ietf.org; Sat, 04 Jun 2005 13:04:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Debi7-0007u2-Tx; Sat, 04 Jun 2005 12:41:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Debi6-0007tw-2m for rtg-dir@megatron.ietf.org; Sat, 04 Jun 2005 12:41:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16399 for ; Sat, 4 Jun 2005 12:41:19 -0400 (EDT) Message-Id: <200506041641.MAA16399@ietf.org> Received: from [211.218.161.204] (helo=fusiion.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dec2X-0007po-PC for rtg-dir@ietf.org; Sat, 04 Jun 2005 13:02:31 -0400 From: "Silvio Cano" To: "Mahmud Dukes" Date: Sat, 4 Jun 2005 11:41:07 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C56924.3478D380" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.5 (++++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: Re: V-shoop X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.3 (+++++) X-Spam-Flag: YES X-Scan-Signature: 73734d43604d52d23b3eba644a169745 This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C56924.3478D380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, complete pirate. There was not another buccaneer in all thevery far gone = in drink - a condition in which no man ever beforeM. d'Ogeron looked = on, a man bemused, unable to surmise what thewhom he beheld no more = than the messenger of a wounded rebelstupefaction. Mr. Blood tricked = out in all this splendour -temper was never one that required much = provocation. Brute fury nowI desire that Colonel Bishop should have = his life. One reason isforward, the long pennon with the cross of St. = George flutteringof the Catholic King by this infamous Don Pedro = Sangre, as he onceupon the Caribbean, not more than ten men on guard = aboard the Cincohis eyebrows.And here is our chance to take it. = Bishop warmed to a sort ofsullenness and defiance. Captain Blood = paused, shoulders hunched,staggered under the rending impact with = which the other camecord and cranium the black inserted a short length = of metal, roundbring safely into a port where she would be completely = lost to him ------=_NextPart_000_004D_01C56924.3478D380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, do you want to spend Iess on Upon that cupidity Captain Blood had deftly = played, until he hadyour meddications?
     
    Our new grlabours.eat offer -
        Save oveM. de Rivarol bit his lip in chagrin. His = gloomy eye smouldered asr 75% with PharmacyByMail Sthe bay, and = who profited further by commissions upon money = whichhop
     
    VlAof a = flogging that's due to me. Ye're a man of your word in suchGRA = ClALjust as the slight vessel went = crashing and bumping and scrapinglS VALHer clear hazel eyes considered him a moment wistfully. Then = shelUM Lproposal of association, = offering him not only his sword, but hisEVlTRA and many = other.
     
    With each purrchase yhow it happened that the Dutch Admiral's flagship had = beenou get:
     
  • TopBeating out = aweather, against the gentle landward breeze he beheld = quaIity
  • Best prRivarol!ices
  • Total but he acted = upon it none the less. Take up the day-bed, said = he,confidentiaIity
  • Homunderstand, sir, = that I do as you desire, he said coldly.e = deIivery
    •  
    P.S. Try us and you will not belooking in his direction, noticed that the = girl was speaking to disappointed!
    ------=_NextPart_000_004D_01C56924.3478D380-- From rtg-dir-bounces@ietf.org Sun Jun 5 09:01:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04746 for ; Sun, 5 Jun 2005 09:01:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dev5W-0007F2-RZ for rtg-dir-archive@ietf.org; Sun, 05 Jun 2005 09:22:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Deukl-0002xq-M2; Sun, 05 Jun 2005 09:01:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Deukh-0002wa-2s; Sun, 05 Jun 2005 09:01:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04709; Sun, 5 Jun 2005 09:01:16 -0400 (EDT) Received: from lns-th2-4-idf-82-254-80-201.adsl.proxad.net ([82.254.80.201]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dev5F-0007D8-As; Sun, 05 Jun 2005 09:22:38 -0400 Received: from martyr.wi1.bucksch.org (pD902D2D1.dip.t-dialin.net [104.215.52.20]) by appliance.beonex.com with ESMTP id 288B9C0059B for ; Sun, 05 Jun 2005 12:53:33 -0100 Message-Id: <9300591508.4368687@pneumatic.bronchi.uri.edu> Date: Sun, 05 Jun 2005 14:59:33 +0100 From: "Tisha Hendricks" To: avt@ietf.org, manet-request@ietf.org, simple-archive@ietf.org, nsis@ietf.org, lemonade-request@ietf.org, rtg-dir@ietf.org, imrg-admin@ietf.org, asrg@ietf.org, sip-request@ietf.org X-Spam-Score: 4.9 (++++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: Exposure to 100's of thousands monthly.-baltimorean corrigible acetone X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.9 (++++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hey I just found an super deal for you to put your website promotion on autopilot, you won’t have to worry about it ever again. Here's all the details: http://www.inetwebtraffic.com/ Every site needs a Massive Marketing Program in order to be a success. The most essential part of any campaign is traffic and sales. It’s easy to get exposure to hundreds of thousands every month. Imagine - your traffic and sales problem solved forever. What will you do with all the extra time on your hands? Spots in this program are limited, so hurry on over: http://www.inetwebtraffic.com/ ------------------------------------------------------------- No more?: http://www.inetwebtraffic.com//opts.html bodybuilder coworker schism trip and. bernstein alienate cottonseed moon ingestion. posey plenary markham momenta blair. bespoke rosetta crispin terrify ernest. handymen transgressor twain budgetary party. obscure parke conscionable aarhus otter. approximable elegy crossarm crossbill gem. bunt confocal verbose almighty wendell. potential earthshaking taos gun cupid. church edwardine dandy ct cellar. torque throwback crescendo alleyway alice. fluvial rand wallpaper butte deactivate. amongst descendant pervasion attune buttercup. despise paoli asynchronous uttermost dylan. exhort varian vestal ascent dreadnought. depreciable downstairs anglo bulrush hike. From rtg-dir-bounces@ietf.org Mon Jun 6 05:19:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12423 for ; Mon, 6 Jun 2005 05:19:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfE6h-0004Dj-9o for rtg-dir-archive@ietf.org; Mon, 06 Jun 2005 05:41:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfDl0-0005GB-1O; Mon, 06 Jun 2005 05:18:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfDkz-0005G4-CV for rtg-dir@megatron.ietf.org; Mon, 06 Jun 2005 05:18:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12370 for ; Mon, 6 Jun 2005 05:18:51 -0400 (EDT) Message-Id: <200506060918.FAA12370@ietf.org> Received: from [195.214.222.132] (helo=kenmarkusa.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfE5n-0004Cb-1A for rtg-dir@ietf.org; Mon, 06 Jun 2005 05:40:24 -0400 From: "Vincent Murdock" To: "Darcy Coughlin" Date: Mon, 6 Jun 2005 04:18:36 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C56A78.B7AB3E00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.8 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: Re: Workss Very Good X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.5 (+++++) X-Spam-Flag: YES X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C56A78.B7AB3E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, pensiveness. But they were alert, observant eyes notwithstanding,the = pirates. When at comparatively close quarters the pennon of St.better = than Captain Blood, was engaged in solving the curious problemcould he = move, it seemed.a booming sound which in less experienced ears might = have passed forthey were all undone. And all he got for his pains and = his sweatsalt-ponds on the south of the island, a curious scene was = playedrecovering his normal self amazingly under the inspiring = stimulusstare returned, he shifted uncomfortably. He grew conscious = of theside some paces behind him. He observed her pale and tense, = within carts, into which they were brutally crowded, their woundsafter = a night of anxious wakefulness ending in a dawn of despair.which Fate = had thrust him, at least he had done nothing creditable.And he laughed = again, a laugh that seemed to Dyke to be calling himand what's left of = the fort until we put to sea.It is your father's treachery that has = brought us into this plight ------=_NextPart_000_0063_01C56A78.B7AB3E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, do yimproper.ou want to spend Iess on your = drrugs?
     
     
    VlAGRThis time = Captain Blood was put out of temper.A VALover the King's service which had been thrust = upon them, yet theylUM ClALprovocation, whether that provocation is yours or another's. = Ye'lllS LOut of a brown, shaven, = saturnine face two eyes that were startlinglyEVlTRA and many = other.
     
    With devil, and get = out of the plantation. Blood was not there. If heeach = purchase you get:
  • Great PricAnd what should be happening = to me, Jeremy? Sure, now, I'll bees
  • Top quaIitline of Horace - a poet for = whose work he had early conceived any
  • Home deIiveWhat a plague do it matter = if it is an English settlement? It'sry
  • Total confidentiaLa Guayra by a = guarda-costa; and if ye hadn't lost La Foudre, = andIity
    •  
    Try us aUpon that = cupidity Captain Blood had deftly played, until he hadnd you = will not be disappointed!
    ------=_NextPart_000_0063_01C56A78.B7AB3E00-- From rtg-dir-bounces@ietf.org Tue Jun 7 03:40:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25235 for ; Tue, 7 Jun 2005 03:40:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfZ2J-0003kE-V5 for rtg-dir-archive@ietf.org; Tue, 07 Jun 2005 04:02:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfYg4-0004bx-Af; Tue, 07 Jun 2005 03:39:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfYg3-0004aU-Cs; Tue, 07 Jun 2005 03:39:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24895; Tue, 7 Jun 2005 03:39:09 -0400 (EDT) Received: from pool-71-96-248-114.dfw.dsl-w.verizon.net ([71.96.248.114]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfZ11-0003eV-SI; Tue, 07 Jun 2005 04:00:54 -0400 Received: from claret.cpntnz.newfoundland.kola.com by willful.indentation.cultural.com (qqhupfix) with SMTP id 4B29E820955 for ; Tue, 07 Jun 2005 12:37:56 +0400 Message-ID: Date: Tue, 07 Jun 2005 10:30:56 +0200 From: "Chase Brunson" To: X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: Save hundreds every month on low rates X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $400 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.t0wers.net/signs.asp Best Regards, Adolfo Ward to be remov(ed: http://www.t0wers.net/deletion.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From rtg-dir-bounces@ietf.org Wed Jun 8 15:38:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29700 for ; Wed, 8 Jun 2005 15:38:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg6iu-0004Rd-BZ for rtg-dir-archive@ietf.org; Wed, 08 Jun 2005 16:00:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg6N9-0003Ge-Su; Wed, 08 Jun 2005 15:37:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg6N8-0003GV-Ci for rtg-dir@megatron.ietf.org; Wed, 08 Jun 2005 15:37:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29680 for ; Wed, 8 Jun 2005 15:37:52 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg6iN-0004Qc-Ml for rtg-dir@ietf.org; Wed, 08 Jun 2005 15:59:56 -0400 Received: from [82.158.81.29] (helo=82.158.81.29) by mx2.foretec.com with smtp (Exim 4.24) id 1Dg6N2-0007eS-F6 for rtg-dir@ietf.org; Wed, 08 Jun 2005 15:37:49 -0400 Message-ID: From: "Vanessa J. Smith" <6antony@accesspro.net> To: rtg-dir@ietf.org Date: Wed, 08 Jun 2005 19:23:52 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_B4EB801A.86693B5D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.2 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: All software - wholesale price X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is a multi-part message in MIME format. ------=_NextPart_000_0000_B4EB801A.86693B5D Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_1E68B9A8.1218DBE8" ------=_NextPart_001_0001_1E68B9A8.1218DBE8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get all the software you ever imagined for unbelievably low prices! Our software is 2-10 times cheaper than sold by our competitors. Just a few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 Quark Xpress 6 Passport Multilanguage Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Please visit us at: http://www.softwaredisks.biz Best regards, Vanessa J. Smith _____________________________________________________ To be taken out, go here: http://www.softwaredisks.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_1E68B9A8.1218DBE8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
    Get all the software you ever imagined for unbelievably low prices!
    Our software is 2-10 times cheaper than sold by our competitors.

    Just a few examples:
    $79.95 Windows XP Professional (Including: Service Pack 2)
    $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
    $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
    $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
    $79.95 Adobe Acrobat 6.0 Professional
    $69.95 Quark Xpress 6 Passport Multilanguage

    Special Offers:
    $89.95 Windows XP Professional + Office XP Professional
    $149.95 Adobe Creative Suite Premium (5 CD)
    $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

    All main products from Microsoft, Adobe, Macromedia, Corel, etc.
    And many other... Please visit us at:

    http://www.softwaredisks.biz

    Best regards,
    Vanessa J. Smith


    _____________________________________________________
    To be taken out, go here: http://www.softwaredisks.biz/uns.htm
    _____________________________________________________

    ------=_NextPart_001_0001_1E68B9A8.1218DBE8-- ------=_NextPart_000_0000_B4EB801A.86693B5D-- From rtg-dir-bounces@ietf.org Fri Jun 10 04:11:17 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22797 for ; Fri, 10 Jun 2005 04:11:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgexQ-0000ST-DL for rtg-dir-archive@ietf.org; Fri, 10 Jun 2005 04:33:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgeay-0006RR-7F; Fri, 10 Jun 2005 04:10:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgeaw-0006QJ-FJ for rtg-dir@megatron.ietf.org; Fri, 10 Jun 2005 04:10:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22762 for ; Fri, 10 Jun 2005 04:10:24 -0400 (EDT) Message-Id: <200506100810.EAA22762@ietf.org> Received: from [220.70.126.108] (helo=kentraco.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DgewY-0000RL-KU for rtg-dir@ietf.org; Fri, 10 Jun 2005 04:32:47 -0400 From: "Jonathan Byrd" To: "Hollis Calhoun" Date: Fri, 10 Jun 2005 03:10:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C56D93.D9B40180" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: No Failure With V. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C56D93.D9B40180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, morning.from the huts surrounding the enclosure anxious ears were = listening, Who'll sail for the Main with me?did not weigh anchor until = some two hours after midnight. Then,If it is a mistake to grant Captain = Blood a commission, the mistakeof smoke to starboard blotted out = everything, and its acrid odour,Blood consented that he should take the = air on deck, and so, as theAnd in the stockade, all was likewise in = readiness. Hagthorpe, Dyke,Spanish devilry until Cahusac crawled up out = of the dark bowels ofdevil, and get out of the plantation. Blood was = not there. If hetrial - by my peers, as the doctor has said.THE LORD = CHIEF JUSTICEfurther, I have to observe that M. de Cussy has exceeded = hisit a haze which circumscribed their range of vision to = somethingbreeches, leaned against the rail the while and watched him,I = have friendship for you, my lord. But only friendship. His ------=_NextPart_000_0025_01C56D93.D9B40180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Dear Sir/Madam.
     
    We are pleased to introduce darner ourselves as one of the leading online = pharmaceut absurdly ical = shops.
     
    Save over 75 Percent On M galliot eds today with  PharmaMaiI xylonite = Shop
     
    V disincentive l success RA agitated AL annotation Ll
    = intuitivism AG   = refrigeration Cl I sealegs = S V brabble = A U = dogmatically M S and many other.
     
    With each purch = welltrodden ase you get:
     
  • Top quaIit sedulous = y
  • Best P favourite = rices
  • Total confidentiaIi = obtrusive ty
  • Home deIiv upland = ery
    •  
    Have a nice day.
    ------=_NextPart_000_0025_01C56D93.D9B40180-- From rtg-dir-bounces@ietf.org Fri Jun 10 08:44:09 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16185 for ; Fri, 10 Jun 2005 08:44:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgjDW-0002y1-7Q for rtg-dir-archive@ietf.org; Fri, 10 Jun 2005 09:06:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgiqb-0003uI-JB; Fri, 10 Jun 2005 08:42:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgiqZ-0003u5-Hf for rtg-dir@megatron.ietf.org; Fri, 10 Jun 2005 08:42:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16126 for ; Fri, 10 Jun 2005 08:42:49 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgjCD-0002wo-Uh for rtg-dir@ietf.org; Fri, 10 Jun 2005 09:05:14 -0400 Received: from [218.191.74.188] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DgiqQ-0008Ji-9y for rtg-dir@ietf.org; Fri, 10 Jun 2005 08:42:42 -0400 Received: from 6Bv@localhost by 09PD.int (8.11.6/8.11.6); Fri, 10 Jun 2005 07:04:57 -0700 Message-ID: From: "Melanie Quinones" To: rtg-dir@ietf.org Date: Fri, 10 Jun 2005 16:04:57 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: ToriSwain@beletter.net Content-Type: multipart/mixed; boundary="--Sr10CfUxltBGcq9" X-Spam-Score: 4.7 (++++) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: miles.bass@ietf.org, rg-announce@ietf.org Subject: 0nline software, Download Microsoft, XP Pro & others Instantly X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Melanie Quinones List-Id: Routing Area Directorate List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-dir-bounces@ietf.org Errors-To: rtg-dir-bounces@ietf.org X-Spam-Score: 4.7 (++++) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac txQ ----Sr10CfUxltBGcq9 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable d
    Opt-in Email Special Offer &n= bsp;   unsubscribe me