From idr-bounces@ietf.org Thu Dec 01 00:44:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhhEg-0005lv-5I; Thu, 01 Dec 2005 00:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhhEd-0005lq-7Y for idr@megatron.ietf.org; Thu, 01 Dec 2005 00:44:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21944 for ; Thu, 1 Dec 2005 00:43:12 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhhZ2-0007es-G5 for idr@ietf.org; Thu, 01 Dec 2005 01:05:05 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jB15hVQ29688; Thu, 1 Dec 2005 07:43:32 +0200 Date: Thu, 1 Dec 2005 07:43:31 +0200 (EET) From: Pekka Savola To: Tony Li Subject: Re: [Idr] AS hopcount draft In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Wed, 30 Nov 2005, Tony Li wrote: > Against: > Pekka Savola (Vendor) For the record, I represent a service provider :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Dec 01 01:36:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehi3p-00030M-V6; Thu, 01 Dec 2005 01:36:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehi3o-00030F-CV for idr@megatron.ietf.org; Thu, 01 Dec 2005 01:36:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26677 for ; Thu, 1 Dec 2005 01:36:05 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhiOB-0000p9-Qt for idr@ietf.org; Thu, 01 Dec 2005 01:57:59 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2005120106363301200arhoue>; Thu, 1 Dec 2005 06:36:39 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] AS hopcount draft Date: Wed, 30 Nov 2005 22:36:31 -0800 To: Pekka Savola X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > On Wed, 30 Nov 2005, Tony Li wrote: >> Against: >> Pekka Savola (Vendor) > > For the record, I represent a service provider :) Corrected, thanks. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Dec 01 09:02:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehp0b-0000Ly-Kt; Thu, 01 Dec 2005 09:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehp0a-0000L6-9b for idr@megatron.ietf.org; Thu, 01 Dec 2005 09:02:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23603 for ; Thu, 1 Dec 2005 09:01:12 -0500 (EST) Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhpL0-0006YS-KY for idr@ietf.org; Thu, 01 Dec 2005 09:23:11 -0500 Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v38_r6.3.) id i.19.1362dbd9 (22681); Thu, 1 Dec 2005 09:01:36 -0500 (EST) Received: from [192.168.3.101] (c-24-128-207-21.hsd1.nh.comcast.net [24.128.207.21]) by air-in04.mx.aol.com (v107.13) with ESMTP id MAILININ42-5899438f02401b7; Thu, 01 Dec 2005 09:01:36 -0500 Message-ID: <438F023A.8010602@netscape.net> Date: Thu, 01 Dec 2005 09:01:30 -0500 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 Subject: Re: [Idr] AS hopcount draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 24.128.207.21 X-Mailer: Unknown (No Version) X-Spam-Flag: NO X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Yes, this should be a WG draft. Tony Li wrote: > > Hi all, > > On the AS hopcount draft, we're in the middle of polling interest on > having this > draft as a WG item. This expires on Monday. If you have an opinion, > please voice > it now to the list. > > Here's my summary of where we are, with both people and their > affiliations. If > any of these need correction, please unicast to me. > > Authors: > Myself (SP) > Rex Fernando (Vendor emeritus) > Joe Abley (SP) > > For: > Curtis Villamizar (Vendor?) > Paul Jakma (SP?) > Elmar Bins (SP?) > Robert Raszuk (Vendor) > Enke Chen (Vendor) > Kanchei Loa (SP/End user) > Geoff Huston (SP) > Danny McPherson (Vendor) > > Against: > Pekka Savola (Vendor) > > > Tony > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Dec 01 09:06:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehp5B-0007DM-R3; Thu, 01 Dec 2005 09:06:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehp5A-0007BL-Qr for idr@megatron.ietf.org; Thu, 01 Dec 2005 09:06:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24244 for ; Thu, 1 Dec 2005 09:05:56 -0500 (EST) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhpPd-0006lj-9X for idr@ietf.org; Thu, 01 Dec 2005 09:27:55 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id 9C86A163BCD; Thu, 1 Dec 2005 14:06:15 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 488JLaogm0263Mo2; Thu, 01 Dec 2005 14:06:13 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 483JLaogL0279Mo2; Thu, 01 Dec 2005 14:06:11 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Thu, 01 Dec 2005 14:06:11 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com gw3.EXCHPROD.USA.NET X-USANET-MsgId: XID973JLaogL8871Xo2 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by gw3.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Dec 2005 07:06:00 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Idr] AS hopcount draft Date: Thu, 1 Dec 2005 07:05:23 -0700 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F02024DC38C@VS4.EXCHPROD.USA.NET> Thread-Topic: [Idr] AS hopcount draft Thread-Index: AcX2f/xnYl9Wwo0SQf+RFQ8VWJBd7QAAENlw From: "Susan Hares" To: , "Tony Li" X-OriginalArrivalTime: 01 Dec 2005 14:06:00.0554 (UTC) FILETIME=[5BC0DCA0:01C5F680] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Thanks for the note. sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Eric W Gray Sent: Thursday, December 01, 2005 9:02 AM To: Tony Li Cc: idr@ietf.org Subject: Re: [Idr] AS hopcount draft Yes, this should be a WG draft. Tony Li wrote: > > Hi all, > > On the AS hopcount draft, we're in the middle of polling interest on =20 > having this > draft as a WG item. This expires on Monday. If you have an opinion, > please voice > it now to the list. > > Here's my summary of where we are, with both people and their =20 > affiliations. If > any of these need correction, please unicast to me. > > Authors: > Myself (SP) > Rex Fernando (Vendor emeritus) > Joe Abley (SP) > > For: > Curtis Villamizar (Vendor?) > Paul Jakma (SP?) > Elmar Bins (SP?) > Robert Raszuk (Vendor) > Enke Chen (Vendor) > Kanchei Loa (SP/End user) > Geoff Huston (SP) > Danny McPherson (Vendor) > > Against: > Pekka Savola (Vendor) > > > Tony > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Dec 05 02:43:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjB0i-0000QB-Mi; Mon, 05 Dec 2005 02:43:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjB0f-0000Q1-62 for idr@megatron.ietf.org; Mon, 05 Dec 2005 02:43:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11276 for ; Mon, 5 Dec 2005 02:42:50 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjBLt-0005u3-Nm for idr@ietf.org; Mon, 05 Dec 2005 03:05:39 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0E79D3326D3; Sun, 4 Dec 2005 23:43:26 -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 19643-02; Sun, 4 Dec 2005 23:43:25 -0800 (PST) Received: from lyon.redback.com (lyon.redback.com [155.53.44.198]) by prattle.redback.com (Postfix) with ESMTP id 464623326D2; Sun, 4 Dec 2005 23:43:25 -0800 (PST) Subject: Re: [Idr] AS hopcount draft (redux) From: Albert Tian To: raszuk@cisco.com In-Reply-To: <437C68A5.4050307@cisco.com> References: <5350312E-7FAA-46BA-A657-91D72795B2BA@tony.li> <437C68A5.4050307@cisco.com> Content-Type: text/plain Message-Id: <1133768605.18112.3914.camel@lyon.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Dec 2005 23:43:25 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, Tony Li , Paul Jakma , Pekka Savola X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi Tony/Robert, Yes I see this can be a simple and useful tool, and I support it to become a WG draft. Wondering would it be helpful if we allow the hopcount to be decremented by a configurable "peering-distance" rather than a fixed number "one" for ebgp. The default peering-distance can be zero for ibgp, one for ebgp. On Thu, 2005-11-17 at 03:25, Robert Raszuk wrote: > Pekka, > > > While I can see it seems simple, I don't see how it would be very > > useful. As the mesh of interconnections gets more and more dense, I > > don't believe it's really a sufficient mechanism to express (the > > intended) policy. > > Your doubts that the idea may not address few possible interconnect > topologies and may not be the universal solution for limiting update > propagation for generations to come is IMHO not a sufficient argument > not to progress with the draft and make it a WG doc to address all other > much more controled AS meshes. > > Imagine there is a network operator who owns number of ASes and wants to > limit some information distribution in one of BGP SAFIs just to his > domain. The usual topology is one AS in the core surranded by reginal > ASes. If he configured AS_HOPCOUNT to 3 and do not peer (by design) from > the core AS his problem is easily solved. In this example, he can even peer from the core AS, if that peer is configured with a peering-distance of 3. Thanks, Albert > Cheers, > R. > > > That is, is there any real examples of applicability of AS hopcount with > > value >= 3 ? I'd certainly be interested in hearing about it and the > > policy goal behind such use. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Dec 13 17:22:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIXQ-0005Wm-9M; Tue, 13 Dec 2005 17:22:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIXO-0005WG-4I for idr@megatron.ietf.org; Tue, 13 Dec 2005 17:22:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07714 for ; Tue, 13 Dec 2005 17:21:24 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmIYT-0005CC-25 for idr@ietf.org; Tue, 13 Dec 2005 17:23:29 -0500 Received: from zcp4hxm0.corp.nortel.com (zcp4hxm0.corp.nortel.com [47.152.152.59]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jBDMMA716095 for ; Tue, 13 Dec 2005 17:22:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Dec 2005 06:22:09 +0800 Message-ID: <4691C3907CF6C54191CCC45F390B86755A36BD@zcp4hxm0.corp.nortel.com> Thread-Topic: About the bgp aggregate route-map command of Cisco. Thread-Index: AcYALJaECnIJhmniSmuIMbOuO+3IkwABtXwQ From: "Hongyan Ma" To: X-Spam-Score: 0.9 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Idr] About the bgp aggregate route-map command of Cisco. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0966333142==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============0966333142== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C60033.A8408AA0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C60033.A8408AA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable > Hi experts, >=20 > = /************************************************************************= ********************************/ > router bgp 300=20 > neighbor 2.2.2.2 remote-as 100=20 > neighbor 3.3.3.3 remote-as 200=20 > neighbor 4.4.4.4 remote-as 400=20 > aggregate-address 160.0.0.0 255.0.0.0 as-set attribute-map Map=20 >=20 > !--- Use of the attribute-map argument allows > !--- you to change the community of the aggregate. > =20 > !=20 > route-map Map permit 10=20 > set community none=20 >=20 > = /************************************************************************= ****/ >=20 > I want to know if the command line of "aggregate-address 160.0.0.0 = 255.0.0.0 as-set attribute-map Map" only changes community of the = aggregate route, and does not affect the community of sub route like = 160.1.0.0/16. >=20 >=20 > Thanks a lot. > a new guy for bgp >=20 >=20 ------_=_NextPart_001_01C60033.A8408AA0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable About the bgp aggregate route-map command of Cisco.

Hi experts,

/*********************************************************= ***********************************************/
router bgp 300
  neighbor 2.2.2.2 remote-as 100
  neighbor 3.3.3.3 remote-as 200
  neighbor 4.4.4.4 remote-as 400
  aggregate-address 160.0.0.0 255.0.0.0 as-set attribute-map = Map

!--- Use = of the attribute-map argument allows
!--- you to change the community of the aggregate.

 !
 route-map Map permit 10
  set community none

/********************************************************= ********************/

I want to know if the command line of = "aggregate-address 160.0.0.0 = 255.0.0.0 as-set attribute-map Map" only changes community of the aggregate route, = and does not affect the community of sub route like = 160.1.0.0/16.


Thanks a = lot.
a new guy for = bgp


------_=_NextPart_001_01C60033.A8408AA0-- --===============0966333142== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============0966333142==-- From idr-bounces@ietf.org Wed Dec 14 10:37:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYgj-0008I8-7h; Wed, 14 Dec 2005 10:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYgg-0008Fc-82 for idr@megatron.ietf.org; Wed, 14 Dec 2005 10:37:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11561 for ; Wed, 14 Dec 2005 10:35:56 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmYhj-0003ZX-52 for idr@ietf.org; Wed, 14 Dec 2005 10:38:10 -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 jBEFafBm052499; Wed, 14 Dec 2005 07:36:41 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jBEFaX514243; Wed, 14 Dec 2005 07:36:33 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200512141536.jBEFaX514243@merlot.juniper.net> To: idr@ietf.org Subject: Re: [Idr] 4 octet AS extended communities as an IDR WG document In-Reply-To: Your message of "Tue, 22 Nov 2005 11:43:05 PST." <200511221943.jAMJh5566155@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6842.1134574593.1@juniper.net> Date: Wed, 14 Dec 2005 07:36:33 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: skh@nexthop.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, Due to the lack of sufficient interest draft-rekhter-as4octet-ext-community-00.txt is not going to be accepted at the *present* time as an IDR WG document. For the time being the authors agreed to maintain this document as an individual contribution. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Dec 14 18:06:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emfhk-0005L8-TX; Wed, 14 Dec 2005 18:06:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emfhh-0005If-K1 for idr@megatron.ietf.org; Wed, 14 Dec 2005 18:06:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10291 for ; Wed, 14 Dec 2005 18:05:27 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emfiq-0005TH-Lh for idr@ietf.org; Wed, 14 Dec 2005 18:07:46 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Dec 2005 00:06:15 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBEN6AFZ014468; Thu, 15 Dec 2005 00:06:11 +0100 (MET) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Dec 2005 00:06:10 +0100 Received: from [127.0.0.1] ([10.25.90.226]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Dec 2005 15:06:09 -0800 Message-ID: <43A0A562.1030607@cisco.com> Date: Wed, 14 Dec 2005 15:06:10 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: [Idr] 4 octet AS extended communities as an IDR WG document References: <200512141536.jBEFaX514243@merlot.juniper.net> In-Reply-To: <200512141536.jBEFaX514243@merlot.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scan-Module: SMTP[2005.12.08 (2005.06.03)] X-OriginalArrivalTime: 14 Dec 2005 23:06:09.0960 (UTC) FILETIME=[F8A28280:01C60102] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: skh@nexthop.com, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi Yakov, Just out of curiosity ... what do you call a "lack of sufficient interest" ? I counted about 8 positive feedbacks and 0 negative. I think there is no more 20 folks who constructively participate in IDR WG so that makes 40% of support. More then sufficient IMHO. Btw since we are at it ... even more folks supported AS hopcount. Is this also going to remain an individual contribution ? Cheers, R. PS. IMHO if criteria like those continue we will be force to define some new way (web based voting) on the WG drafts acceptance where majority of votes wins even if majority means 2 for and 1 against vote. > Folks, > > Due to the lack of sufficient interest > draft-rekhter-as4octet-ext-community-00.txt is not going to > be accepted at the *present* time as an IDR WG document. For > the time being the authors agreed to maintain this document > as an individual contribution. > > Yakov. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Dec 14 18:26:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emg0t-0003WJ-7P; Wed, 14 Dec 2005 18:26:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emg0m-0003MG-NB for idr@megatron.ietf.org; Wed, 14 Dec 2005 18:26:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12178 for ; Wed, 14 Dec 2005 18:25:17 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emg22-0006CJ-FW for idr@ietf.org; Wed, 14 Dec 2005 18:27:36 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <20051214232555012007pj5re>; Wed, 14 Dec 2005 23:25:56 +0000 In-Reply-To: <43A0A562.1030607@cisco.com> References: <200512141536.jBEFaX514243@merlot.juniper.net> <43A0A562.1030607@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <242008D3-B8C4-4EA7-B608-C69BF66DD0DE@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] 4 octet AS extended communities as an IDR WG document Date: Wed, 14 Dec 2005 15:25:53 -0800 To: raszuk@cisco.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: skh@nexthop.com, Yakov Rekhter , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > Btw since we are at it ... even more folks supported AS hopcount. > Is this also going to remain an individual contribution ? AS hopcount was accepted and is on my plate to submit a revised WG draft. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Dec 15 09:35:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmuCZ-0002CJ-Jh; Thu, 15 Dec 2005 09:35:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmuCX-0002BU-8z for idr@megatron.ietf.org; Thu, 15 Dec 2005 09:35:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14559 for ; Thu, 15 Dec 2005 09:34:13 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmuDn-0004A3-MG for idr@ietf.org; Thu, 15 Dec 2005 09:36:41 -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 jBFEYv066482; Thu, 15 Dec 2005 06:35:01 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jBFEYq518124; Thu, 15 Dec 2005 06:34:52 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200512151434.jBFEYq518124@merlot.juniper.net> To: raszuk@cisco.com Subject: Re: [Idr] 4 octet AS extended communities as an IDR WG document In-Reply-To: Your message of "Wed, 14 Dec 2005 15:06:10 PST." <43A0A562.1030607@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15726.1134657292.1@juniper.net> Date: Thu, 15 Dec 2005 06:34:52 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: skh@nexthop.com, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Robert, > Hi Yakov, > > Just out of curiosity ... what do you call a "lack of sufficient > interest" ? I counted about 8 positive feedbacks and 0 negative. I think > there is no more 20 folks who constructively participate in IDR WG so > that makes 40% of support. More then sufficient IMHO. Compare this with the AS hopcount document. For that document we got 15 folks supporting it (excluding authors). > Btw since we are at it ... even more folks supported AS hopcount. Is > this also going to remain an individual contribution ? No, it is accepted as an IDR WG document - see Tony's reply. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Dec 21 15:50:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpAuz-0006Wi-AO; Wed, 21 Dec 2005 15:50:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpAuT-0006MG-V4; Wed, 21 Dec 2005 15:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19473; Wed, 21 Dec 2005 15:49:01 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpAx8-0006gK-Q7; Wed, 21 Dec 2005 15:52:51 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EpAuQ-0005ZY-VQ; Wed, 21 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Dec 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-dynamic-cap-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --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 : Dynamic Capability for BGP-4 Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-dynamic-cap-08.txt Pages : 8 Date : 2005-12-21 This document defines a new BGP capability termed "Dynamic Capability", which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-08.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-ietf-idr-dynamic-cap-08.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-dynamic-cap-08.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: <2005-12-21150915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-dynamic-cap-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-dynamic-cap-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-21150915.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Tue Dec 27 18:50:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErOa3-00032J-7O; Tue, 27 Dec 2005 18:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErOZv-0002zZ-2F; Tue, 27 Dec 2005 18:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07046; Tue, 27 Dec 2005 18:48:52 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErOdq-0001nl-N1; Tue, 27 Dec 2005 18:54:07 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ErOZt-0003RD-SK; Tue, 27 Dec 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Dec 2005 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-avoid-transition-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --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 : Avoid BGP Best Path Transitions from One External to Another Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-avoid-transition-04.txt Pages : 7 Date : 2005-12-27 In this document we propose a revision to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed revision would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external paths from one BGP speaker contribute to the churn. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-avoid-transition-04.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-ietf-idr-avoid-transition-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-avoid-transition-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-27173644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-avoid-transition-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-avoid-transition-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-27173644.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Wed Dec 28 09:44:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErcXs-0007BP-7T; Wed, 28 Dec 2005 09:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErcXq-0007Ab-7N for idr@megatron.ietf.org; Wed, 28 Dec 2005 09:44:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13739 for ; Wed, 28 Dec 2005 09:43:40 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ercbt-0001Ul-6U for idr@ietf.org; Wed, 28 Dec 2005 09:49:02 -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 jBSEid1Z015833; Wed, 28 Dec 2005 06:44:39 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jBSEid508428; Wed, 28 Dec 2005 06:44:39 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200512281444.jBSEid508428@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44319.1135781078.1@juniper.net> Date: Wed, 28 Dec 2005 06:44:39 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: skh@nexthop.com Subject: [Idr] draft-ietf-idr-avoid-transition-04.txt to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-avoid-transition-04.txt to a Proposed Standard. The implementation report is draft-chen-bgp-avoid-ebgp-transition-survey-00.txt. The Last Call ends Jan 16, 2006. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Dec 29 15:50:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es4j3-00067e-31; Thu, 29 Dec 2005 15:50:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es4ip-00061e-F4; Thu, 29 Dec 2005 15:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12383; Thu, 29 Dec 2005 15:48:51 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es4n8-0002aK-DS; Thu, 29 Dec 2005 15:54:30 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Es4in-0002om-U3; Thu, 29 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Dec 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --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 : The AS_HOPCOUNT Path Attribute Author(s) : T. Li, et al. Filename : draft-ietf-idr-as-hopcount-00.txt Pages : 16 Date : 2005-12-29 This document describes the AS hopcount path attribute for BGP. This is an optional, transitive path attribute that is designed to help limit the distribution of routing information in the Internet. By default, prefixes advertised into the BGP mesh are distributed freely, and if not blocked by policy will propagate globally. This is harmful to the scalability of the routing subsystem since information that only has a local effect on routing will cause state creation throughout the default-free zone. This attribute can be attached to a particular path to limit its scope to a subset of the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as-hopcount-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-ietf-idr-as-hopcount-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-ietf-idr-as-hopcount-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-29150403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as-hopcount-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as-hopcount-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-29150403.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Thu Dec 29 20:16:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es8qL-0007IZ-RE; Thu, 29 Dec 2005 20:14:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es8qJ-0007Cl-Ma for idr@megatron.ietf.org; Thu, 29 Dec 2005 20:14:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10963 for ; Thu, 29 Dec 2005 20:12:51 -0500 (EST) Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es8ue-0003qU-Qi for idr@ietf.org; Thu, 29 Dec 2005 20:18:34 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id C28F7E044A; Thu, 29 Dec 2005 20:13:57 -0500 (EST) Date: Thu, 29 Dec 2005 20:13:57 -0500 From: John Leslie To: idr@ietf.org Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Message-ID: <20051230011357.GA86351@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Internet-Drafts@ietf.org wrote: > > Title : The AS_HOPCOUNT Path Attribute > Author(s) : T. Li, et al. > Filename : draft-ietf-idr-as-hopcount-00.txt > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-as-hopcount-00.txt > > This document describes the AS hopcount path attribute for BGP. This > is an optional, transitive path attribute that is designed to help > limit the distribution of routing information in the Internet. I thoroughly agree it should be optional transitive. However, IMHO, we have an obligation to carefully consider the effects of passing such an attribute through BGP speakers which don't recognize it. Thus, I would much prefer that BGP speakers which recognize it MUST NOT modify it -- their action should be limited to discarding the NLRI based upon it. This implies that it should contain a number which is the maximum "path length" to which the NLRI is intended to propagate (with clear definition of how to count this "path length". (I am agnostic on whether this should equal AS_Path_Length, a count of different ASs in the AS_Path, or something else entirely.) Several other issues jump out at me: - if there is to be any interaction with the NO_EXPORT community attribute, we should carefully consider what is appropriate if the NO_EXPORT is added after the AS_HOPCOUNT by a BGP speaker which does not understand AS_HOPCOUNT. - I'm slightly nervous about specifying the use of a 4-byte AS number for BGP speakers which recognize AS_HOPCOUNT but not 4-byte AS numbers. (At worst, though, this is a documentation issue.) - The interaction with ATOMIC_AGGREGATE introduces a potential for some issues. I quite understand the suggestion (it's not a MUST or SHOULD) that the BGP speaker which introduces the AS_HOPCOUNT on a more-specific NLRI put ATOMIC-AGGREGATE on the less-specific (without the AS_HOPCOUNT). This does seem far safer than hoping some other BGP speaker will add it, but there's a nagging doubt... I need to think about it more. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Dec 29 23:30:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsBuZ-0006ir-7m; Thu, 29 Dec 2005 23:30:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsBuX-0006im-KU for idr@megatron.ietf.org; Thu, 29 Dec 2005 23:30:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28835 for ; Thu, 29 Dec 2005 23:29:26 -0500 (EST) Received: from paintbird.ucs.indiana.edu ([129.79.5.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsByu-0001ko-F2 for idr@ietf.org; Thu, 29 Dec 2005 23:35:09 -0500 Received: from [192.168.254.2] (iub-vpn-175-2.noc.indiana.edu [156.56.175.2]) (authenticated bits=0) by paintbird.ucs.indiana.edu (8.12.11/8.12.11) with ESMTP id jBU4UFmv021412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Dec 2005 23:30:17 -0500 Message-ID: <43B4B7D4.4090201@grnoc.iu.edu> Date: Thu, 29 Dec 2005 23:30:12 -0500 From: Andrew Lee User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt References: <20051230011357.GA86351@verdi> In-Reply-To: <20051230011357.GA86351@verdi> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (paintbird.ucs.indiana.edu [129.79.5.54]); Thu, 29 Dec 2005 23:30:17 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > However, IMHO, we have an obligation to carefully consider the effects > of passing such an attribute through BGP speakers which don't recognize > it. Can someone clarify something real quick: you are saying if a speaker receives an attribute that it does not recognize, it will dutifully pass it along? > Thus, I would much prefer that BGP speakers which recognize it > MUST NOT modify it -- their action should be limited to discarding the > NLRI based upon it. > If the answer to my question is 'yes', then the above seems the more correct way to go, as an NLRI could pass through an unknown number of ASes where the hopcount attribute is not correctly decremented, and when it arrives at a BGP speaker that recognizes the attribute, the information is wrong. If the hopcount is not modified in transit, but simply compared with the AS path length, this problem is avoided, along with the problem of what to do with AS prepends or other AS path modifications that may not be coming to mind. However this would negatively impact the operation of other sections such as Proxy Control, where an intervening provider could no longer simply specify the number of additional ASes to traverse, but must take into account the current path length and hope that it doesn't change (though I think this is an acceptable trade off). _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 30 00:53:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsDD1-0006eH-4u; Fri, 30 Dec 2005 00:53:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsDD0-0006eC-26 for idr@megatron.ietf.org; Fri, 30 Dec 2005 00:53:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06646 for ; Fri, 30 Dec 2005 00:52:34 -0500 (EST) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsDHO-0004Tl-DJ for idr@ietf.org; Fri, 30 Dec 2005 00:58:18 -0500 Received: from [10.0.0.14] (bdsl.66.15.11.172.gte.net[66.15.11.172]) by comcast.net (sccrmhc11) with SMTP id <20051230055325011004n442e>; Fri, 30 Dec 2005 05:53:28 +0000 In-Reply-To: <43B4B7D4.4090201@grnoc.iu.edu> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Thu, 29 Dec 2005 21:52:07 -0800 To: Andrew Lee X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Dec 29, 2005, at 8:30 PM, Andrew Lee wrote: > >> However, IMHO, we have an obligation to carefully consider the >> effects >> of passing such an attribute through BGP speakers which don't >> recognize >> it. > > Can someone clarify something real quick: you are saying if a > speaker receives an attribute that it does not recognize, it will > dutifully pass it along? That is correct. BGP stipulates that a speaker that receives a transitive optional attribute that it does not recognize should simply propagate the attribute untouched. >> Thus, I would much prefer that BGP speakers which recognize it >> MUST NOT modify it -- their action should be limited to discarding >> the >> NLRI based upon it. > > If the answer to my question is 'yes', then the above seems the > more correct way to go, as an NLRI could pass through an unknown > number of ASes where the hopcount attribute is not correctly > decremented, and when it arrives at a BGP speaker that recognizes > the attribute, the information is wrong. If the hopcount is not > modified in transit, but simply compared with the AS path length, > this problem is avoided, along with the problem of what to do with > AS prepends or other AS path modifications that may not be coming > to mind. However this would negatively impact the operation of > other sections such as Proxy Control, where an intervening provider > could no longer simply specify the number of additional ASes to > traverse, but must take into account the current path length and > hope that it doesn't change (though I think this is an acceptable > trade off). If you re-read the draft, I think that you'll find that the behavior that you want is achieved by including NO_EXPORT along with AS_HOPCOUNT. This will cause ASes that don't recognize AS_HOPCOUNT to drop the path. Note that there is *no* guarantee (nor even a specification) of what value the AS_HOPCOUNT will have when it reaches a given point in the network. While the specification of how it operates is already clearly defined (IMHO ;-) the vagaries of non-recognizing implementations combined with the policy flexibility of adding the attribute by ASes other than the originator basically implies that the result will only be deterministic through extremely detailed analysis taking into account each and every BGP speaker that is traversed, it's implementation and version. I'll also note that forbidding an AS from modifying path attributes would only give us a false sense of security. An AS that really wanted to perform this function would simply end up deploying a non-compliant implementation. At this point, the lack of a BGP police force and a BGP jail would leave us staring at each other, looking silly. Thus, we do not issue mandates that prohibit behavior unless we can demonstrate that it negates interoperability. This is a philosophical constant not only throughout BGP but throughout most of the IETF's work as well. Regards, Tony Protocol Police, Badge #47 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 30 02:17:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsEWQ-00010j-EL; Fri, 30 Dec 2005 02:17:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsEWO-0000zs-57 for idr@megatron.ietf.org; Fri, 30 Dec 2005 02:17:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13041 for ; Fri, 30 Dec 2005 02:16:40 -0500 (EST) Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsEaa-0006bE-2H for idr@ietf.org; Fri, 30 Dec 2005 02:22:13 -0500 Received: from [10.0.0.14] (bdsl.66.15.11.172.gte.net[66.15.11.172]) by comcast.net (rwcrmhc14) with SMTP id <20051230071724014007sl6oe>; Fri, 30 Dec 2005 07:17:24 +0000 In-Reply-To: <20051230011357.GA86351@verdi> References: <20051230011357.GA86351@verdi> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F987392-EE78-4414-9B9E-CDE0DDDDE53E@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Thu, 29 Dec 2005 23:17:24 -0800 To: John Leslie X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org John, > - if there is to be any interaction with the NO_EXPORT community > attribute, we should carefully consider what is appropriate if the > NO_EXPORT is added after the AS_HOPCOUNT by a BGP speaker which > does not understand AS_HOPCOUNT. This is already specified in the draft. If a speaker receives AS_HOPCOUNT with NO_EXPORT, it cannot determine whether NO_EXPORT was added by the originator or some other AS in the path. > - I'm slightly nervous about specifying the use of a 4-byte AS number > for BGP speakers which recognize AS_HOPCOUNT but not 4-byte AS > numbers. > (At worst, though, this is a documentation issue.) Presumably any implementation that parsed AS_HOPCOUNT but did not yet support 4-byte AS numbers would simply pass the AS number through to the management interface as a 4-byte number. Regards, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 30 10:01:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsLkq-0002u2-Vx; Fri, 30 Dec 2005 10:01:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsLko-0002tI-Hv for idr@megatron.ietf.org; Fri, 30 Dec 2005 10:01:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28498 for ; Fri, 30 Dec 2005 10:00:01 -0500 (EST) Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsLpG-0004uI-P4 for idr@ietf.org; Fri, 30 Dec 2005 10:05:52 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id BA93EE0429; Fri, 30 Dec 2005 10:01:03 -0500 (EST) Date: Fri, 30 Dec 2005 10:01:03 -0500 From: John Leslie To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Message-ID: <20051230150103.GC86351@verdi> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Andrew Lee , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Tony Li wrote: > On Dec 29, 2005, at 8:30 PM, Andrew Lee wrote: >> [John Leslie wrote:] >> >>> However, IMHO, we have an obligation to carefully consider the >>> effects of passing such an attribute through BGP speakers which >>> don't recognize it. >> >> Can someone clarify something real quick: you are saying if a >> speaker receives an attribute that it does not recognize, it will >> dutifully pass it along? > > That is correct. BGP stipulates that a speaker that receives a > transitive optional attribute that it does not recognize should > simply propagate the attribute untouched. > >>> Thus, I would much prefer that BGP speakers which recognize it >>> MUST NOT modify it -- their action should be limited to discarding >>> the NLRI based upon it. >> >> If the answer to my question is 'yes', then the above seems the >> more correct way to go, as an NLRI could pass through an unknown >> number of ASes where the hopcount attribute is not correctly >> decremented, and when it arrives at a BGP speaker that recognizes >> the attribute, the information is wrong. If the hopcount is not >> modified in transit, but simply compared with the AS path length, >> this problem is avoided, along with the problem of what to do with >> AS prepends or other AS path modifications that may not be coming >> to mind. However this would negatively impact the operation of >> other sections such as Proxy Control, where an intervening provider >> could no longer simply specify the number of additional ASes to >> traverse, but must take into account the current path length and >> hope that it doesn't change (though I think this is an acceptable >> trade off). > > If you re-read the draft, I think that you'll find that the behavior > that you want is achieved by including NO_EXPORT along with AS_HOPCOUNT. > This will cause ASes that don't recognize AS_HOPCOUNT to drop the path. I don't presume to know what Andrew "wants"; but I think that's the wrong question. Instead, we should worry whether the results are sufficiently predictable. IMHO, it is neither predictable nor stable whether any particular BGP speaker will recognize the AS_HOPCOUNT attribute. > Note that there is *no* guarantee (nor even a specification) of what > value the AS_HOPCOUNT will have when it reaches a given point in the > network. > ... the vagaries of non-recognizing implementations combined with > the policy flexibility of adding the attribute by ASes other than > the originator basically implies that the result will only be > deterministic through extremely detailed analysis taking into account > each and every BGP speaker that is traversed, its implementation and > version. My point exactly: we shouldn't be starting down that road. We want something which can have a (somewhat) predictable effect beyond the inserting AS. Pretty much by definition this means we won't know, from day to day, what versions of software will be running on their routers. > I'll also note that forbidding an AS from modifying path attributes > would only give us a false sense of security. An AS that really > wanted to perform this function would simply end up deploying a > non-compliant implementation. "MUST NOT" doesn't mean we have to call the cops: it simply means that any implementation which does what we say it "MUST NOT" can't argue that it's compliant. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 30 10:09:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsLsK-0004uZ-4u; Fri, 30 Dec 2005 10:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsLsH-0004tG-It for idr@megatron.ietf.org; Fri, 30 Dec 2005 10:08:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29365 for ; Fri, 30 Dec 2005 10:07:44 -0500 (EST) Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsLwj-0005Br-P8 for idr@ietf.org; Fri, 30 Dec 2005 10:13:34 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id C3B07E0432; Fri, 30 Dec 2005 10:08:55 -0500 (EST) Date: Fri, 30 Dec 2005 10:08:55 -0500 From: John Leslie To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Message-ID: <20051230150855.GD86351@verdi> References: <20051230011357.GA86351@verdi> <6F987392-EE78-4414-9B9E-CDE0DDDDE53E@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F987392-EE78-4414-9B9E-CDE0DDDDE53E@tony.li> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Tony Li wrote: > > John [Leslie wrote], > >> - if there is to be any interaction with the NO_EXPORT community >> attribute, we should carefully consider what is appropriate if the >> NO_EXPORT is added after the AS_HOPCOUNT by a BGP speaker which >> does not understand AS_HOPCOUNT. > > This is already specified in the draft. If a speaker receives > AS_HOPCOUNT with NO_EXPORT, it cannot determine whether NO_EXPORT > was added by the originator or some other AS in the path. What the draft specifies seems dubious: that NO_EXPORT must be ignored in the presence of an AS_HOPCOUNT -- whether or not the NO_EXPORT was added by the AS which inserted the AS_HOPCOUNT. Thus inserting an AS_HOPCOUNT may override the NO_EXPORT function for peer ASs. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 30 10:27:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsMA0-0005mu-42; Fri, 30 Dec 2005 10:27:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsM9y-0005mX-EQ for idr@megatron.ietf.org; Fri, 30 Dec 2005 10:27:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01508 for ; Fri, 30 Dec 2005 10:26:01 -0500 (EST) Received: from paintbird.ucs.indiana.edu ([129.79.5.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsMEP-0005qK-LA for idr@ietf.org; Fri, 30 Dec 2005 10:31:52 -0500 Received: from [192.168.254.2] (iub-vpn-175-2.noc.indiana.edu [156.56.175.2]) (authenticated bits=0) by paintbird.ucs.indiana.edu (8.12.11/8.12.11) with ESMTP id jBUFR1gO027529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Dec 2005 10:27:02 -0500 Message-ID: <43B551C3.8050105@grnoc.iu.edu> Date: Fri, 30 Dec 2005 10:26:59 -0500 From: Andrew Lee User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> In-Reply-To: <20051230150103.GC86351@verdi> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (paintbird.ucs.indiana.edu [129.79.5.54]); Fri, 30 Dec 2005 10:27:02 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > I don't presume to know what Andrew "wants"; but I think that's the > wrong question. Instead, we should worry whether the results are > sufficiently predictable. IMHO, it is neither predictable nor stable > whether any particular BGP speaker will recognize the AS_HOPCOUNT > attribute. Then I shall use more verbage instead of relying on my telepatic interperative dancing to express my idea. I am less concerned with any particular BGP speaker recognizing or not recognizing the attribute, than I am will the effect that has on what the hopcount attribute is trying to accomplish. Example (using the diagram in the draft): Site A advertises Y to its upstreams with hopcount=2, but C, D and E do not support the draft. When Y reaches H and F, hopcount will still be 2, as the intervening systems did not decrement it. H and F will decrement hopcount, and advertise it to its peers and customers, who would then decrement it and advertise it, where it would stop. The total hopcount would actually be 5. If we modify the behavior in 5.b such that instead of decrementing the hopcount, the speaker simply compares the path length to the hopcount and makes a decision on whether to accept or advertise, then the following would happen: Site A advertises Y to its upstreams with hopcount=3 (to account for its own AS), but C, D and E do not support the draft. When Y reaches H and F, they will compare (path-len=3) >= (hopcount=3) and not accept the route. Coincidently this is the behavior Site A was hoping for, and I will leave it as an exercise for the reader to imagine a scenario where it doesn't work out quite so tidily, but still has a more favorable effect. As C, D and E finally get stable code from their vendors that they are willing to deploy that happens to support the draft, the behavior of the propogation of Y will not change dramatically. On a side note, the draft reads: Assuming that there are no policy boundaries involved, BGP will propagate both of these prefixes A and X throughout the entire AS- level topology. Should this be prefixes Y and X? _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 30 13:58:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPSa-0003M2-92; Fri, 30 Dec 2005 13:58:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPSY-0003Lq-8V for idr@megatron.ietf.org; Fri, 30 Dec 2005 13:58:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26502 for ; Fri, 30 Dec 2005 13:57:25 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsPX3-0005PU-8e for idr@ietf.org; Fri, 30 Dec 2005 14:03:17 -0500 Received: from [10.0.0.14] (bdsl.66.15.11.172.gte.net[66.15.11.172]) by comcast.net (sccrmhc11) with SMTP id <20051230185804011004n93ne>; Fri, 30 Dec 2005 18:58:20 +0000 In-Reply-To: <20051230150103.GC86351@verdi> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2018ECFE-F850-46B5-9D74-B254E2B0EE3F@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Fri, 30 Dec 2005 10:58:06 -0800 To: John Leslie X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > IMHO, it is neither predictable nor stable > whether any particular BGP speaker will recognize the AS_HOPCOUNT > attribute. Well, the facts of the matter are simple: between a software change, it will be 100% predictable as to whether AS_HOPCOUNT is supported as long as you know the software version number. Of course, for those outside of the AS, that is unlikely to be disclosed and is thus wholly unknown. Note that this is the condition that all incremental deployments go through. >> Note that there is *no* guarantee (nor even a specification) of what >> value the AS_HOPCOUNT will have when it reaches a given point in the >> network. >> ... the vagaries of non-recognizing implementations combined with >> the policy flexibility of adding the attribute by ASes other than >> the originator basically implies that the result will only be >> deterministic through extremely detailed analysis taking into account >> each and every BGP speaker that is traversed, its implementation and >> version. > > My point exactly: we shouldn't be starting down that road. We want > something which can have a (somewhat) predictable effect beyond the > inserting AS. Pretty much by definition this means we won't know, > from day to day, what versions of software will be running on their > routers. Sorry, but you can never get that level of determinism via incremental deployment. >> I'll also note that forbidding an AS from modifying path attributes >> would only give us a false sense of security. An AS that really >> wanted to perform this function would simply end up deploying a >> non-compliant implementation. > > "MUST NOT" doesn't mean we have to call the cops: it simply means > that any implementation which does what we say it "MUST NOT" can't > argue that it's compliant. And so? If there is a commercial motivation to be non-compliant, then there WILL be non-compliant implementations. And please let me assure you that there will be implementations that want to modify AS_HOPCOUNT in flight. There are a number of various policy reasons for doing so. The most obvious is a form of routing scoping, whereby a third party would attach AS_HOPCOUNT to a prefix that it did not originate. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 30 19:47:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsUuL-00052E-Lh; Fri, 30 Dec 2005 19:47:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsUuJ-000528-3J for idr@megatron.ietf.org; Fri, 30 Dec 2005 19:47:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06827 for ; Fri, 30 Dec 2005 19:46:26 -0500 (EST) Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsUym-00019S-Iz for idr@ietf.org; Fri, 30 Dec 2005 19:52:17 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (rwcrmhc11) with SMTP id <2005123100470601300bgb3ce>; Sat, 31 Dec 2005 00:47:10 +0000 In-Reply-To: <20051230150855.GD86351@verdi> References: <20051230011357.GA86351@verdi> <6F987392-EE78-4414-9B9E-CDE0DDDDE53E@tony.li> <20051230150855.GD86351@verdi> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B9DBF6B-7323-4BB0-9ABB-092AE840F5E7@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Fri, 30 Dec 2005 16:47:07 -0800 To: John Leslie X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > What the draft specifies seems dubious: that NO_EXPORT must be > ignored in the presence of an AS_HOPCOUNT -- whether or not the > NO_EXPORT was added by the AS which inserted the AS_HOPCOUNT. > Thus inserting an AS_HOPCOUNT may override the NO_EXPORT function > for peer ASs. Those observations about the draft are correct. However, 'dubious' seems like a value judgement or an emotional report, not a well supported technical evaluation. Having one attribute modify the semantics of another is not uncommon. Yes, it can add to complexity and it is certainly less than ideal, but we are evolving a protocol, not starting with a clean slate. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Dec 30 20:05:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsVBl-0000QU-97; Fri, 30 Dec 2005 20:05:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsVBj-0000QM-IW for idr@megatron.ietf.org; Fri, 30 Dec 2005 20:05:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08507 for ; Fri, 30 Dec 2005 20:04:27 -0500 (EST) Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsVGG-0001kZ-QJ for idr@ietf.org; Fri, 30 Dec 2005 20:10:22 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (rwcrmhc11) with SMTP id <2005123101052801300bg5lie>; Sat, 31 Dec 2005 01:05:28 +0000 In-Reply-To: <43B551C3.8050105@grnoc.iu.edu> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Fri, 30 Dec 2005 16:40:45 -0800 To: Andrew Lee X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > Site A advertises Y to its upstreams with hopcount=2, but C, D and > E do not support the draft. When Y reaches H and F, hopcount will > still be 2, as the intervening systems did not decrement it. H and > F will decrement hopcount, and advertise it to its peers and > customers, who would then decrement it and advertise it, where it > would stop. The total hopcount would actually be 5. > > If we modify the behavior in 5.b such that instead of decrementing > the hopcount, the speaker simply compares the path length to the > hopcount and makes a decision on whether to accept or advertise, > then the following would happen: > > Site A advertises Y to its upstreams with hopcount=3 (to account > for its own AS), but C, D and E do not support the draft. When Y > reaches H and F, they will compare (path-len=3) >= (hopcount=3) and > not accept the route. Coincidently this is the behavior Site A was > hoping for, and I will leave it as an exercise for the reader to > imagine a scenario where it doesn't work out quite so tidily, but > still has a more favorable effect. As C, D and E finally get > stable code from their vendors that they are willing to deploy that > happens to support the draft, the behavior of the propogation of Y > will not change dramatically. Seems like a fine alternate semantics to me. What do other folks think? I think that the evaluation gets a little bit more complicated, due to private AS numbers and confederations, but this seems like something that can be addressed. > On a side note, the draft reads: > > Assuming that there are no policy boundaries involved, BGP will > propagate both of these prefixes A and X throughout the entire AS- > level topology. > > Should this be prefixes Y and X? Correct, thanks. My typo. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Dec 31 02:52:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsbXk-0002dx-9w; Sat, 31 Dec 2005 02:52:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsbXi-0002dn-C3 for idr@megatron.ietf.org; Sat, 31 Dec 2005 02:52:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12599 for ; Sat, 31 Dec 2005 02:51:33 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1+k7gZTIy7un/4tONxnrSJIuqakJ67GUp4=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsbcI-0005KA-A8 for idr@ietf.org; Sat, 31 Dec 2005 02:57:32 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1/B/zBxnDItUeCequCMUM2mRg9gAOcBtVE@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id jBV7qDZl020201; Sat, 31 Dec 2005 07:52:20 GMT Date: Sat, 31 Dec 2005 07:52:13 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1219/Wed Dec 28 22:57:59 2005 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Andrew Lee , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Fri, 30 Dec 2005, Tony Li wrote: > Seems like a fine alternate semantics to me. What do other folks > think? I think that the evaluation gets a little bit more > complicated, due to private AS numbers and confederations, but this > seems like something that can be addressed. It does seem a bit complicated. How about instead we just specify that if AS_HOPCOUNT is received with partial set, that the receiving speaker shall then treat the attribute as if it had a hopcount value of 0? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Although it's never fun getting one year older, it sure beats the alternative! _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Dec 31 12:12:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EskGz-0001YA-R8; Sat, 31 Dec 2005 12:12:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EskGx-0001Y5-HH for idr@megatron.ietf.org; Sat, 31 Dec 2005 12:12:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28762 for ; Sat, 31 Dec 2005 12:10:47 -0500 (EST) Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EskLX-00045o-KD for idr@ietf.org; Sat, 31 Dec 2005 12:16:50 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (rwcrmhc13) with SMTP id <200512311711270150046tiie>; Sat, 31 Dec 2005 17:11:33 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Sat, 31 Dec 2005 09:11:27 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > How about instead we just specify that if AS_HOPCOUNT is received > with partial set, that the receiving speaker shall then treat the > attribute as if it had a hopcount value of 0? That would seem to eliminate any choice in having AS_HOPCOUNT interpreted conservatively or liberally (i.e., with NO_EXPORT or not). Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Dec 31 13:03:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esl4K-0004cp-4u; Sat, 31 Dec 2005 13:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esl4I-0004bf-L3 for idr@megatron.ietf.org; Sat, 31 Dec 2005 13:03:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02583 for ; Sat, 31 Dec 2005 13:01:50 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19pLuwpmZXZu8eCyAz47DkwOG6vkPDf69A=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Esl8z-0005N2-4t for idr@ietf.org; Sat, 31 Dec 2005 13:07:54 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+IFxgGppBDP/Qar24IY4xLjWEg2iuetTE@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id jBVI2j7o024696; Sat, 31 Dec 2005 18:02:50 GMT Date: Sat, 31 Dec 2005 18:02:45 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1219/Wed Dec 28 22:57:59 2005 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Andrew Lee , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Sat, 31 Dec 2005, Tony Li wrote: > That would seem to eliminate any choice in having AS_HOPCOUNT interpreted > conservatively or liberally (i.e., with NO_EXPORT or not). Six of one, half dozen of the other I guess. Given the point of the attribute is to provide better ways to limit scope, it might be more beneficial for transition to err on side of limiting scope, see below. The problem is that /not/ treating partial as == infinite hops would cause one to disregard no-export incorrectly. E.g. imagine receiving an announcement with both AS_HOPCOUNT (partial) and no-export. The right thing to do here is to honour no-export (because the receiving speaker can't know how many hops were 'missed' in the count, other than with the AS_PATH counting hacks mentioned by Andrew). Such a situation could arise where 'action' communities are used, e.g.: X-Y-Z Z announces route with AS_HOPCOUNT > 1 and with community including Y:. Ys speakers are not AS_HOPCOUNT capable. Y sets no-export when passing on the announcement to X, because Z requested Y to do so. Z, as the draft stands today, will ignore the no-export because of the presence of AS_HOPCOUNT (complete or not), decrement the AS_HOPCOUNT, which will then be >= 1 and hence announce it to other peers, when it shouldn't. You could argue that Z shouldn't do the above, they should know which of the two mechanisms (action communities versus AS_HOPCOUNT) should be used for Y and pick one. But that's not always possible, particularly during transitions. Transition would be easier if the draft erred on side of restricting scope. E.g. think case where Y takes time to transition all its speakers over to AS_HOPCOUNT capable software. If receiving speakers treat partial as == 0 and ignore, then Z /can/ make use of both the legacy 'action community' offered by Y and of AS_HOPCOUNT. E.g: X-Y:1 \ Y:3-Z / A-Y:2 Imagine all but Y:1 (Y:{1,2,3} are 3 speakers of AS Y) are AS_HOPCOUNT capable. Then /both/ the action communities and AS_HOPCOUNT can work through a transition period, where Y is upgrading its routers, one by one. X will receive partial AS_HOPCOUNT from Y:1 and hence ignore AS_HOPCOUNT and honour no-export instead, as desired. A will receive complete and decremented AS_HOPCOUNT from Y:2 and hence honour that, ignoring the no-export, as desired. I.e. if the point of AS_HOPCOUNT is to reduce scope of routes, then it seems more beneficial to err on the side of reducing scope. ;) (Just about everyone announcing AS_HOPCOUNT routes will also be announcing a less-specific global scope route anyway, right? And the anycasters definitely would prefer reduced, not greater scope. They only have no-export and maybe ASN:action communities available to them today in their toolbox today anyway, as per above.) > Tony regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Lots of folks confuse bad management with destiny. -- Frank Hubbard _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Dec 31 22:43:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esu7y-0000Wk-K8; Sat, 31 Dec 2005 22:43:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esu7w-0000Wb-Gs for idr@megatron.ietf.org; Sat, 31 Dec 2005 22:43:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13082 for ; Sat, 31 Dec 2005 22:42:11 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsuCi-0002N0-Ux for idr@ietf.org; Sat, 31 Dec 2005 22:48:22 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (sccrmhc13) with SMTP id <2006010103425901300o1arfe>; Sun, 1 Jan 2006 03:43:05 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Sat, 31 Dec 2005 11:20:31 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.6 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > Given the point of the attribute is to provide better ways to limit > scope, it might be more beneficial for transition to err on side of > limiting scope, see below. I'm not yet convinced of the above. Consider that most longer prefixes are now being distributed globally. Folks playing with the new attribute are likely to want to experiment with it by slowly contracting scope. An abrupt change in distribution is likely to result in some unanticipated results, which would delay, not encourage deployment. Thus, it seems like many providers might want a more liberal interpretation of the semantics. Providing the option of a liberal or strict scoping would seem to give the provider an increased level of control and thus ease deployment. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA12696 for ; Sat, 31 Dec 2005 22:49:12 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esu7y-0000Wk-9n; Sat, 31 Dec 2005 22:43:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esu7w-0000Wb-Gs for idr@megatron.ietf.org; Sat, 31 Dec 2005 22:43:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13082 for ; Sat, 31 Dec 2005 22:42:11 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsuCi-0002N0-Ux for idr@ietf.org; Sat, 31 Dec 2005 22:48:22 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (sccrmhc13) with SMTP id <2006010103425901300o1arfe>; Sun, 1 Jan 2006 03:43:05 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Sat, 31 Dec 2005 11:20:31 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.6 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > Given the point of the attribute is to provide better ways to limit > scope, it might be more beneficial for transition to err on side of > limiting scope, see below. I'm not yet convinced of the above. Consider that most longer prefixes are now being distributed globally. Folks playing with the new attribute are likely to want to experiment with it by slowly contracting scope. An abrupt change in distribution is likely to result in some unanticipated results, which would delay, not encourage deployment. Thus, it seems like many providers might want a more liberal interpretation of the semantics. Providing the option of a liberal or strict scoping would seem to give the provider an increased level of control and thus ease deployment. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA09341 for ; Sat, 31 Dec 2005 13:06:53 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esl4K-0004cp-00; Sat, 31 Dec 2005 13:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esl4I-0004bf-L3 for idr@megatron.ietf.org; Sat, 31 Dec 2005 13:03:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02583 for ; Sat, 31 Dec 2005 13:01:50 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19pLuwpmZXZu8eCyAz47DkwOG6vkPDf69A=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Esl8z-0005N2-4t for idr@ietf.org; Sat, 31 Dec 2005 13:07:54 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+IFxgGppBDP/Qar24IY4xLjWEg2iuetTE@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id jBVI2j7o024696; Sat, 31 Dec 2005 18:02:50 GMT Date: Sat, 31 Dec 2005 18:02:45 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1219/Wed Dec 28 22:57:59 2005 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Andrew Lee , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Sat, 31 Dec 2005, Tony Li wrote: > That would seem to eliminate any choice in having AS_HOPCOUNT interpreted > conservatively or liberally (i.e., with NO_EXPORT or not). Six of one, half dozen of the other I guess. Given the point of the attribute is to provide better ways to limit scope, it might be more beneficial for transition to err on side of limiting scope, see below. The problem is that /not/ treating partial as == infinite hops would cause one to disregard no-export incorrectly. E.g. imagine receiving an announcement with both AS_HOPCOUNT (partial) and no-export. The right thing to do here is to honour no-export (because the receiving speaker can't know how many hops were 'missed' in the count, other than with the AS_PATH counting hacks mentioned by Andrew). Such a situation could arise where 'action' communities are used, e.g.: X-Y-Z Z announces route with AS_HOPCOUNT > 1 and with community including Y:. Ys speakers are not AS_HOPCOUNT capable. Y sets no-export when passing on the announcement to X, because Z requested Y to do so. Z, as the draft stands today, will ignore the no-export because of the presence of AS_HOPCOUNT (complete or not), decrement the AS_HOPCOUNT, which will then be >= 1 and hence announce it to other peers, when it shouldn't. You could argue that Z shouldn't do the above, they should know which of the two mechanisms (action communities versus AS_HOPCOUNT) should be used for Y and pick one. But that's not always possible, particularly during transitions. Transition would be easier if the draft erred on side of restricting scope. E.g. think case where Y takes time to transition all its speakers over to AS_HOPCOUNT capable software. If receiving speakers treat partial as == 0 and ignore, then Z /can/ make use of both the legacy 'action community' offered by Y and of AS_HOPCOUNT. E.g: X-Y:1 \ Y:3-Z / A-Y:2 Imagine all but Y:1 (Y:{1,2,3} are 3 speakers of AS Y) are AS_HOPCOUNT capable. Then /both/ the action communities and AS_HOPCOUNT can work through a transition period, where Y is upgrading its routers, one by one. X will receive partial AS_HOPCOUNT from Y:1 and hence ignore AS_HOPCOUNT and honour no-export instead, as desired. A will receive complete and decremented AS_HOPCOUNT from Y:2 and hence honour that, ignoring the no-export, as desired. I.e. if the point of AS_HOPCOUNT is to reduce scope of routes, then it seems more beneficial to err on the side of reducing scope. ;) (Just about everyone announcing AS_HOPCOUNT routes will also be announcing a less-specific global scope route anyway, right? And the anycasters definitely would prefer reduced, not greater scope. They only have no-export and maybe ASN:action communities available to them today in their toolbox today anyway, as per above.) > Tony regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Lots of folks confuse bad management with destiny. -- Frank Hubbard _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA09079 for ; Sat, 31 Dec 2005 12:12:36 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EskGz-0001YA-Lf; Sat, 31 Dec 2005 12:12:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EskGx-0001Y5-HH for idr@megatron.ietf.org; Sat, 31 Dec 2005 12:12:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28762 for ; Sat, 31 Dec 2005 12:10:47 -0500 (EST) Received: from rwcrmhc13.comcast.net ([204.127.198.39] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EskLX-00045o-KD for idr@ietf.org; Sat, 31 Dec 2005 12:16:50 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (rwcrmhc13) with SMTP id <200512311711270150046tiie>; Sat, 31 Dec 2005 17:11:33 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Sat, 31 Dec 2005 09:11:27 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > How about instead we just specify that if AS_HOPCOUNT is received > with partial set, that the receiving speaker shall then treat the > attribute as if it had a hopcount value of 0? That would seem to eliminate any choice in having AS_HOPCOUNT interpreted conservatively or liberally (i.e., with NO_EXPORT or not). Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA05905 for ; Sat, 31 Dec 2005 02:54:37 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsbXk-0002dx-2s; Sat, 31 Dec 2005 02:52:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsbXi-0002dn-C3 for idr@megatron.ietf.org; Sat, 31 Dec 2005 02:52:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12599 for ; Sat, 31 Dec 2005 02:51:33 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1+k7gZTIy7un/4tONxnrSJIuqakJ67GUp4=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsbcI-0005KA-A8 for idr@ietf.org; Sat, 31 Dec 2005 02:57:32 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1/B/zBxnDItUeCequCMUM2mRg9gAOcBtVE@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id jBV7qDZl020201; Sat, 31 Dec 2005 07:52:20 GMT Date: Sat, 31 Dec 2005 07:52:13 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1219/Wed Dec 28 22:57:59 2005 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Andrew Lee , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Fri, 30 Dec 2005, Tony Li wrote: > Seems like a fine alternate semantics to me. What do other folks > think? I think that the evaluation gets a little bit more > complicated, due to private AS numbers and confederations, but this > seems like something that can be addressed. It does seem a bit complicated. How about instead we just specify that if AS_HOPCOUNT is received with partial set, that the receiving speaker shall then treat the attribute as if it had a hopcount value of 0? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Although it's never fun getting one year older, it sure beats the alternative! _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA02884 for ; Fri, 30 Dec 2005 20:09:03 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsVBl-0000QU-58; Fri, 30 Dec 2005 20:05:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsVBj-0000QM-IW for idr@megatron.ietf.org; Fri, 30 Dec 2005 20:05:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08507 for ; Fri, 30 Dec 2005 20:04:27 -0500 (EST) Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsVGG-0001kZ-QJ for idr@ietf.org; Fri, 30 Dec 2005 20:10:22 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (rwcrmhc11) with SMTP id <2005123101052801300bg5lie>; Sat, 31 Dec 2005 01:05:28 +0000 In-Reply-To: <43B551C3.8050105@grnoc.iu.edu> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Fri, 30 Dec 2005 16:40:45 -0800 To: Andrew Lee X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > Site A advertises Y to its upstreams with hopcount=2, but C, D and > E do not support the draft. When Y reaches H and F, hopcount will > still be 2, as the intervening systems did not decrement it. H and > F will decrement hopcount, and advertise it to its peers and > customers, who would then decrement it and advertise it, where it > would stop. The total hopcount would actually be 5. > > If we modify the behavior in 5.b such that instead of decrementing > the hopcount, the speaker simply compares the path length to the > hopcount and makes a decision on whether to accept or advertise, > then the following would happen: > > Site A advertises Y to its upstreams with hopcount=3 (to account > for its own AS), but C, D and E do not support the draft. When Y > reaches H and F, they will compare (path-len=3) >= (hopcount=3) and > not accept the route. Coincidently this is the behavior Site A was > hoping for, and I will leave it as an exercise for the reader to > imagine a scenario where it doesn't work out quite so tidily, but > still has a more favorable effect. As C, D and E finally get > stable code from their vendors that they are willing to deploy that > happens to support the draft, the behavior of the propogation of Y > will not change dramatically. Seems like a fine alternate semantics to me. What do other folks think? I think that the evaluation gets a little bit more complicated, due to private AS numbers and confederations, but this seems like something that can be addressed. > On a side note, the draft reads: > > Assuming that there are no policy boundaries involved, BGP will > propagate both of these prefixes A and X throughout the entire AS- > level topology. > > Should this be prefixes Y and X? Correct, thanks. My typo. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA02759 for ; Fri, 30 Dec 2005 19:50:58 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsUuL-00052E-Hm; Fri, 30 Dec 2005 19:47:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsUuJ-000528-3J for idr@megatron.ietf.org; Fri, 30 Dec 2005 19:47:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06827 for ; Fri, 30 Dec 2005 19:46:26 -0500 (EST) Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsUym-00019S-Iz for idr@ietf.org; Fri, 30 Dec 2005 19:52:17 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (rwcrmhc11) with SMTP id <2005123100470601300bgb3ce>; Sat, 31 Dec 2005 00:47:10 +0000 In-Reply-To: <20051230150855.GD86351@verdi> References: <20051230011357.GA86351@verdi> <6F987392-EE78-4414-9B9E-CDE0DDDDE53E@tony.li> <20051230150855.GD86351@verdi> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B9DBF6B-7323-4BB0-9ABB-092AE840F5E7@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Fri, 30 Dec 2005 16:47:07 -0800 To: John Leslie X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > What the draft specifies seems dubious: that NO_EXPORT must be > ignored in the presence of an AS_HOPCOUNT -- whether or not the > NO_EXPORT was added by the AS which inserted the AS_HOPCOUNT. > Thus inserting an AS_HOPCOUNT may override the NO_EXPORT function > for peer ASs. Those observations about the draft are correct. However, 'dubious' seems like a value judgement or an emotional report, not a well supported technical evaluation. Having one attribute modify the semantics of another is not uncommon. Yes, it can add to complexity and it is certainly less than ideal, but we are evolving a protocol, not starting with a clean slate. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00470 for ; Fri, 30 Dec 2005 13:59:53 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPSa-0003M2-4Z; Fri, 30 Dec 2005 13:58:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsPSY-0003Lq-8V for idr@megatron.ietf.org; Fri, 30 Dec 2005 13:58:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26502 for ; Fri, 30 Dec 2005 13:57:25 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsPX3-0005PU-8e for idr@ietf.org; Fri, 30 Dec 2005 14:03:17 -0500 Received: from [10.0.0.14] (bdsl.66.15.11.172.gte.net[66.15.11.172]) by comcast.net (sccrmhc11) with SMTP id <20051230185804011004n93ne>; Fri, 30 Dec 2005 18:58:20 +0000 In-Reply-To: <20051230150103.GC86351@verdi> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2018ECFE-F850-46B5-9D74-B254E2B0EE3F@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Fri, 30 Dec 2005 10:58:06 -0800 To: John Leslie X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > IMHO, it is neither predictable nor stable > whether any particular BGP speaker will recognize the AS_HOPCOUNT > attribute. Well, the facts of the matter are simple: between a software change, it will be 100% predictable as to whether AS_HOPCOUNT is supported as long as you know the software version number. Of course, for those outside of the AS, that is unlikely to be disclosed and is thus wholly unknown. Note that this is the condition that all incremental deployments go through. >> Note that there is *no* guarantee (nor even a specification) of what >> value the AS_HOPCOUNT will have when it reaches a given point in the >> network. >> ... the vagaries of non-recognizing implementations combined with >> the policy flexibility of adding the attribute by ASes other than >> the originator basically implies that the result will only be >> deterministic through extremely detailed analysis taking into account >> each and every BGP speaker that is traversed, its implementation and >> version. > > My point exactly: we shouldn't be starting down that road. We want > something which can have a (somewhat) predictable effect beyond the > inserting AS. Pretty much by definition this means we won't know, > from day to day, what versions of software will be running on their > routers. Sorry, but you can never get that level of determinism via incremental deployment. >> I'll also note that forbidding an AS from modifying path attributes >> would only give us a false sense of security. An AS that really >> wanted to perform this function would simply end up deploying a >> non-compliant implementation. > > "MUST NOT" doesn't mean we have to call the cops: it simply means > that any implementation which does what we say it "MUST NOT" can't > argue that it's compliant. And so? If there is a commercial motivation to be non-compliant, then there WILL be non-compliant implementations. And please let me assure you that there will be implementations that want to modify AS_HOPCOUNT in flight. There are a number of various policy reasons for doing so. The most obvious is a form of routing scoping, whereby a third party would attach AS_HOPCOUNT to a prefix that it did not originate. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00086 for ; Fri, 30 Dec 2005 13:26:03 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsLkq-0002u2-Rx; Fri, 30 Dec 2005 10:01:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsLko-0002tI-Hv for idr@megatron.ietf.org; Fri, 30 Dec 2005 10:01:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28498 for ; Fri, 30 Dec 2005 10:00:01 -0500 (EST) Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsLpG-0004uI-P4 for idr@ietf.org; Fri, 30 Dec 2005 10:05:52 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id BA93EE0429; Fri, 30 Dec 2005 10:01:03 -0500 (EST) Date: Fri, 30 Dec 2005 10:01:03 -0500 From: John Leslie To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Message-ID: <20051230150103.GC86351@verdi> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Andrew Lee , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Tony Li wrote: > On Dec 29, 2005, at 8:30 PM, Andrew Lee wrote: >> [John Leslie wrote:] >> >>> However, IMHO, we have an obligation to carefully consider the >>> effects of passing such an attribute through BGP speakers which >>> don't recognize it. >> >> Can someone clarify something real quick: you are saying if a >> speaker receives an attribute that it does not recognize, it will >> dutifully pass it along? > > That is correct. BGP stipulates that a speaker that receives a > transitive optional attribute that it does not recognize should > simply propagate the attribute untouched. > >>> Thus, I would much prefer that BGP speakers which recognize it >>> MUST NOT modify it -- their action should be limited to discarding >>> the NLRI based upon it. >> >> If the answer to my question is 'yes', then the above seems the >> more correct way to go, as an NLRI could pass through an unknown >> number of ASes where the hopcount attribute is not correctly >> decremented, and when it arrives at a BGP speaker that recognizes >> the attribute, the information is wrong. If the hopcount is not >> modified in transit, but simply compared with the AS path length, >> this problem is avoided, along with the problem of what to do with >> AS prepends or other AS path modifications that may not be coming >> to mind. However this would negatively impact the operation of >> other sections such as Proxy Control, where an intervening provider >> could no longer simply specify the number of additional ASes to >> traverse, but must take into account the current path length and >> hope that it doesn't change (though I think this is an acceptable >> trade off). > > If you re-read the draft, I think that you'll find that the behavior > that you want is achieved by including NO_EXPORT along with AS_HOPCOUNT. > This will cause ASes that don't recognize AS_HOPCOUNT to drop the path. I don't presume to know what Andrew "wants"; but I think that's the wrong question. Instead, we should worry whether the results are sufficiently predictable. IMHO, it is neither predictable nor stable whether any particular BGP speaker will recognize the AS_HOPCOUNT attribute. > Note that there is *no* guarantee (nor even a specification) of what > value the AS_HOPCOUNT will have when it reaches a given point in the > network. > ... the vagaries of non-recognizing implementations combined with > the policy flexibility of adding the attribute by ASes other than > the originator basically implies that the result will only be > deterministic through extremely detailed analysis taking into account > each and every BGP speaker that is traversed, its implementation and > version. My point exactly: we shouldn't be starting down that road. We want something which can have a (somewhat) predictable effect beyond the inserting AS. Pretty much by definition this means we won't know, from day to day, what versions of software will be running on their routers. > I'll also note that forbidding an AS from modifying path attributes > would only give us a false sense of security. An AS that really > wanted to perform this function would simply end up deploying a > non-compliant implementation. "MUST NOT" doesn't mean we have to call the cops: it simply means that any implementation which does what we say it "MUST NOT" can't argue that it's compliant. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00084 for ; Fri, 30 Dec 2005 13:26:03 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsLsK-0004uZ-09; Fri, 30 Dec 2005 10:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsLsH-0004tG-It for idr@megatron.ietf.org; Fri, 30 Dec 2005 10:08:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29365 for ; Fri, 30 Dec 2005 10:07:44 -0500 (EST) Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsLwj-0005Br-P8 for idr@ietf.org; Fri, 30 Dec 2005 10:13:34 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id C3B07E0432; Fri, 30 Dec 2005 10:08:55 -0500 (EST) Date: Fri, 30 Dec 2005 10:08:55 -0500 From: John Leslie To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Message-ID: <20051230150855.GD86351@verdi> References: <20051230011357.GA86351@verdi> <6F987392-EE78-4414-9B9E-CDE0DDDDE53E@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F987392-EE78-4414-9B9E-CDE0DDDDE53E@tony.li> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Tony Li wrote: > > John [Leslie wrote], > >> - if there is to be any interaction with the NO_EXPORT community >> attribute, we should carefully consider what is appropriate if the >> NO_EXPORT is added after the AS_HOPCOUNT by a BGP speaker which >> does not understand AS_HOPCOUNT. > > This is already specified in the draft. If a speaker receives > AS_HOPCOUNT with NO_EXPORT, it cannot determine whether NO_EXPORT > was added by the originator or some other AS in the path. What the draft specifies seems dubious: that NO_EXPORT must be ignored in the presence of an AS_HOPCOUNT -- whether or not the NO_EXPORT was added by the AS which inserted the AS_HOPCOUNT. Thus inserting an AS_HOPCOUNT may override the NO_EXPORT function for peer ASs. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00078 for ; Fri, 30 Dec 2005 13:26:01 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsMA0-0005mu-1H; Fri, 30 Dec 2005 10:27:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsM9y-0005mX-EQ for idr@megatron.ietf.org; Fri, 30 Dec 2005 10:27:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01508 for ; Fri, 30 Dec 2005 10:26:01 -0500 (EST) Received: from paintbird.ucs.indiana.edu ([129.79.5.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsMEP-0005qK-LA for idr@ietf.org; Fri, 30 Dec 2005 10:31:52 -0500 Received: from [192.168.254.2] (iub-vpn-175-2.noc.indiana.edu [156.56.175.2]) (authenticated bits=0) by paintbird.ucs.indiana.edu (8.12.11/8.12.11) with ESMTP id jBUFR1gO027529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Dec 2005 10:27:02 -0500 Message-ID: <43B551C3.8050105@grnoc.iu.edu> Date: Fri, 30 Dec 2005 10:26:59 -0500 From: Andrew Lee User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> In-Reply-To: <20051230150103.GC86351@verdi> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (paintbird.ucs.indiana.edu [129.79.5.54]); Fri, 30 Dec 2005 10:27:02 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > I don't presume to know what Andrew "wants"; but I think that's the > wrong question. Instead, we should worry whether the results are > sufficiently predictable. IMHO, it is neither predictable nor stable > whether any particular BGP speaker will recognize the AS_HOPCOUNT > attribute. Then I shall use more verbage instead of relying on my telepatic interperative dancing to express my idea. I am less concerned with any particular BGP speaker recognizing or not recognizing the attribute, than I am will the effect that has on what the hopcount attribute is trying to accomplish. Example (using the diagram in the draft): Site A advertises Y to its upstreams with hopcount=2, but C, D and E do not support the draft. When Y reaches H and F, hopcount will still be 2, as the intervening systems did not decrement it. H and F will decrement hopcount, and advertise it to its peers and customers, who would then decrement it and advertise it, where it would stop. The total hopcount would actually be 5. If we modify the behavior in 5.b such that instead of decrementing the hopcount, the speaker simply compares the path length to the hopcount and makes a decision on whether to accept or advertise, then the following would happen: Site A advertises Y to its upstreams with hopcount=3 (to account for its own AS), but C, D and E do not support the draft. When Y reaches H and F, they will compare (path-len=3) >= (hopcount=3) and not accept the route. Coincidently this is the behavior Site A was hoping for, and I will leave it as an exercise for the reader to imagine a scenario where it doesn't work out quite so tidily, but still has a more favorable effect. As C, D and E finally get stable code from their vendors that they are willing to deploy that happens to support the draft, the behavior of the propogation of Y will not change dramatically. On a side note, the draft reads: Assuming that there are no policy boundaries involved, BGP will propagate both of these prefixes A and X throughout the entire AS- level topology. Should this be prefixes Y and X? _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA24906 for ; Fri, 30 Dec 2005 02:20:08 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsEWQ-00010j-AM; Fri, 30 Dec 2005 02:17:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsEWO-0000zs-57 for idr@megatron.ietf.org; Fri, 30 Dec 2005 02:17:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13041 for ; Fri, 30 Dec 2005 02:16:40 -0500 (EST) Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsEaa-0006bE-2H for idr@ietf.org; Fri, 30 Dec 2005 02:22:13 -0500 Received: from [10.0.0.14] (bdsl.66.15.11.172.gte.net[66.15.11.172]) by comcast.net (rwcrmhc14) with SMTP id <20051230071724014007sl6oe>; Fri, 30 Dec 2005 07:17:24 +0000 In-Reply-To: <20051230011357.GA86351@verdi> References: <20051230011357.GA86351@verdi> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F987392-EE78-4414-9B9E-CDE0DDDDE53E@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Thu, 29 Dec 2005 23:17:24 -0800 To: John Leslie X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org John, > - if there is to be any interaction with the NO_EXPORT community > attribute, we should carefully consider what is appropriate if the > NO_EXPORT is added after the AS_HOPCOUNT by a BGP speaker which > does not understand AS_HOPCOUNT. This is already specified in the draft. If a speaker receives AS_HOPCOUNT with NO_EXPORT, it cannot determine whether NO_EXPORT was added by the originator or some other AS in the path. > - I'm slightly nervous about specifying the use of a 4-byte AS number > for BGP speakers which recognize AS_HOPCOUNT but not 4-byte AS > numbers. > (At worst, though, this is a documentation issue.) Presumably any implementation that parsed AS_HOPCOUNT but did not yet support 4-byte AS numbers would simply pass the AS number through to the management interface as a 4-byte number. Regards, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA24245 for ; Fri, 30 Dec 2005 00:56:49 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsDD1-0006eH-1M; Fri, 30 Dec 2005 00:53:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsDD0-0006eC-26 for idr@megatron.ietf.org; Fri, 30 Dec 2005 00:53:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06646 for ; Fri, 30 Dec 2005 00:52:34 -0500 (EST) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsDHO-0004Tl-DJ for idr@ietf.org; Fri, 30 Dec 2005 00:58:18 -0500 Received: from [10.0.0.14] (bdsl.66.15.11.172.gte.net[66.15.11.172]) by comcast.net (sccrmhc11) with SMTP id <20051230055325011004n442e>; Fri, 30 Dec 2005 05:53:28 +0000 In-Reply-To: <43B4B7D4.4090201@grnoc.iu.edu> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Thu, 29 Dec 2005 21:52:07 -0800 To: Andrew Lee X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Dec 29, 2005, at 8:30 PM, Andrew Lee wrote: > >> However, IMHO, we have an obligation to carefully consider the >> effects >> of passing such an attribute through BGP speakers which don't >> recognize >> it. > > Can someone clarify something real quick: you are saying if a > speaker receives an attribute that it does not recognize, it will > dutifully pass it along? That is correct. BGP stipulates that a speaker that receives a transitive optional attribute that it does not recognize should simply propagate the attribute untouched. >> Thus, I would much prefer that BGP speakers which recognize it >> MUST NOT modify it -- their action should be limited to discarding >> the >> NLRI based upon it. > > If the answer to my question is 'yes', then the above seems the > more correct way to go, as an NLRI could pass through an unknown > number of ASes where the hopcount attribute is not correctly > decremented, and when it arrives at a BGP speaker that recognizes > the attribute, the information is wrong. If the hopcount is not > modified in transit, but simply compared with the AS path length, > this problem is avoided, along with the problem of what to do with > AS prepends or other AS path modifications that may not be coming > to mind. However this would negatively impact the operation of > other sections such as Proxy Control, where an intervening provider > could no longer simply specify the number of additional ASes to > traverse, but must take into account the current path length and > hope that it doesn't change (though I think this is an acceptable > trade off). If you re-read the draft, I think that you'll find that the behavior that you want is achieved by including NO_EXPORT along with AS_HOPCOUNT. This will cause ASes that don't recognize AS_HOPCOUNT to drop the path. Note that there is *no* guarantee (nor even a specification) of what value the AS_HOPCOUNT will have when it reaches a given point in the network. While the specification of how it operates is already clearly defined (IMHO ;-) the vagaries of non-recognizing implementations combined with the policy flexibility of adding the attribute by ASes other than the originator basically implies that the result will only be deterministic through extremely detailed analysis taking into account each and every BGP speaker that is traversed, it's implementation and version. I'll also note that forbidding an AS from modifying path attributes would only give us a false sense of security. An AS that really wanted to perform this function would simply end up deploying a non-compliant implementation. At this point, the lack of a BGP police force and a BGP jail would leave us staring at each other, looking silly. Thus, we do not issue mandates that prohibit behavior unless we can demonstrate that it negates interoperability. This is a philosophical constant not only throughout BGP but throughout most of the IETF's work as well. Regards, Tony Protocol Police, Badge #47 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA23454 for ; Thu, 29 Dec 2005 23:33:50 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsBuZ-0006ir-2Q; Thu, 29 Dec 2005 23:30:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsBuX-0006im-KU for idr@megatron.ietf.org; Thu, 29 Dec 2005 23:30:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28835 for ; Thu, 29 Dec 2005 23:29:26 -0500 (EST) Received: from paintbird.ucs.indiana.edu ([129.79.5.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsByu-0001ko-F2 for idr@ietf.org; Thu, 29 Dec 2005 23:35:09 -0500 Received: from [192.168.254.2] (iub-vpn-175-2.noc.indiana.edu [156.56.175.2]) (authenticated bits=0) by paintbird.ucs.indiana.edu (8.12.11/8.12.11) with ESMTP id jBU4UFmv021412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Dec 2005 23:30:17 -0500 Message-ID: <43B4B7D4.4090201@grnoc.iu.edu> Date: Thu, 29 Dec 2005 23:30:12 -0500 From: Andrew Lee User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt References: <20051230011357.GA86351@verdi> In-Reply-To: <20051230011357.GA86351@verdi> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (paintbird.ucs.indiana.edu [129.79.5.54]); Thu, 29 Dec 2005 23:30:17 -0500 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > However, IMHO, we have an obligation to carefully consider the effects > of passing such an attribute through BGP speakers which don't recognize > it. Can someone clarify something real quick: you are saying if a speaker receives an attribute that it does not recognize, it will dutifully pass it along? > Thus, I would much prefer that BGP speakers which recognize it > MUST NOT modify it -- their action should be limited to discarding the > NLRI based upon it. > If the answer to my question is 'yes', then the above seems the more correct way to go, as an NLRI could pass through an unknown number of ASes where the hopcount attribute is not correctly decremented, and when it arrives at a BGP speaker that recognizes the attribute, the information is wrong. If the hopcount is not modified in transit, but simply compared with the AS path length, this problem is avoided, along with the problem of what to do with AS prepends or other AS path modifications that may not be coming to mind. However this would negatively impact the operation of other sections such as Proxy Control, where an intervening provider could no longer simply specify the number of additional ASes to traverse, but must take into account the current path length and hope that it doesn't change (though I think this is an acceptable trade off). _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA21888 for ; Thu, 29 Dec 2005 20:14:29 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es8qL-0007IZ-LC; Thu, 29 Dec 2005 20:14:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es8qJ-0007Cl-Ma for idr@megatron.ietf.org; Thu, 29 Dec 2005 20:14:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10963 for ; Thu, 29 Dec 2005 20:12:51 -0500 (EST) Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es8ue-0003qU-Qi for idr@ietf.org; Thu, 29 Dec 2005 20:18:34 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id C28F7E044A; Thu, 29 Dec 2005 20:13:57 -0500 (EST) Date: Thu, 29 Dec 2005 20:13:57 -0500 From: John Leslie To: idr@ietf.org Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Message-ID: <20051230011357.GA86351@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Internet-Drafts@ietf.org wrote: > > Title : The AS_HOPCOUNT Path Attribute > Author(s) : T. Li, et al. > Filename : draft-ietf-idr-as-hopcount-00.txt > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-as-hopcount-00.txt > > This document describes the AS hopcount path attribute for BGP. This > is an optional, transitive path attribute that is designed to help > limit the distribution of routing information in the Internet. I thoroughly agree it should be optional transitive. However, IMHO, we have an obligation to carefully consider the effects of passing such an attribute through BGP speakers which don't recognize it. Thus, I would much prefer that BGP speakers which recognize it MUST NOT modify it -- their action should be limited to discarding the NLRI based upon it. This implies that it should contain a number which is the maximum "path length" to which the NLRI is intended to propagate (with clear definition of how to count this "path length". (I am agnostic on whether this should equal AS_Path_Length, a count of different ASs in the AS_Path, or something else entirely.) Several other issues jump out at me: - if there is to be any interaction with the NO_EXPORT community attribute, we should carefully consider what is appropriate if the NO_EXPORT is added after the AS_HOPCOUNT by a BGP speaker which does not understand AS_HOPCOUNT. - I'm slightly nervous about specifying the use of a 4-byte AS number for BGP speakers which recognize AS_HOPCOUNT but not 4-byte AS numbers. (At worst, though, this is a documentation issue.) - The interaction with ATOMIC_AGGREGATE introduces a potential for some issues. I quite understand the suggestion (it's not a MUST or SHOULD) that the BGP speaker which introduces the AS_HOPCOUNT on a more-specific NLRI put ATOMIC-AGGREGATE on the less-specific (without the AS_HOPCOUNT). This does seem far safer than hoping some other BGP speaker will add it, but there's a nagging doubt... I need to think about it more. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA20197 for ; Thu, 29 Dec 2005 16:02:57 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es4j2-00067e-Vu; Thu, 29 Dec 2005 15:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es4ip-00061e-F4; Thu, 29 Dec 2005 15:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12383; Thu, 29 Dec 2005 15:48:51 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es4n8-0002aK-DS; Thu, 29 Dec 2005 15:54:30 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Es4in-0002om-U3; Thu, 29 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Dec 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --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 : The AS_HOPCOUNT Path Attribute Author(s) : T. Li, et al. Filename : draft-ietf-idr-as-hopcount-00.txt Pages : 16 Date : 2005-12-29 This document describes the AS hopcount path attribute for BGP. This is an optional, transitive path attribute that is designed to help limit the distribution of routing information in the Internet. By default, prefixes advertised into the BGP mesh are distributed freely, and if not blocked by policy will propagate globally. This is harmful to the scalability of the routing subsystem since information that only has a local effect on routing will cause state creation throughout the default-free zone. This attribute can be attached to a particular path to limit its scope to a subset of the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as-hopcount-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-ietf-idr-as-hopcount-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-ietf-idr-as-hopcount-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-29150403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as-hopcount-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as-hopcount-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-29150403.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA05689 for ; Wed, 28 Dec 2005 09:45:09 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErcXs-0007BP-38; Wed, 28 Dec 2005 09:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErcXq-0007Ab-7N for idr@megatron.ietf.org; Wed, 28 Dec 2005 09:44:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13739 for ; Wed, 28 Dec 2005 09:43:40 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ercbt-0001Ul-6U for idr@ietf.org; Wed, 28 Dec 2005 09:49:02 -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 jBSEid1Z015833; Wed, 28 Dec 2005 06:44:39 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jBSEid508428; Wed, 28 Dec 2005 06:44:39 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200512281444.jBSEid508428@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <44319.1135781078.1@juniper.net> Date: Wed, 28 Dec 2005 06:44:39 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: skh@nexthop.com Subject: [Idr] draft-ietf-idr-avoid-transition-04.txt to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, This is to start the IDR WG Last Call on advancing draft-ietf-idr-avoid-transition-04.txt to a Proposed Standard. The implementation report is draft-chen-bgp-avoid-ebgp-transition-survey-00.txt. The Last Call ends Jan 16, 2006. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA14964 for ; Tue, 27 Dec 2005 19:05:50 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErOa3-00032J-2w; Tue, 27 Dec 2005 18:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErOZv-0002zZ-2F; Tue, 27 Dec 2005 18:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07046; Tue, 27 Dec 2005 18:48:52 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErOdq-0001nl-N1; Tue, 27 Dec 2005 18:54:07 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ErOZt-0003RD-SK; Tue, 27 Dec 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Dec 2005 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-avoid-transition-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --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 : Avoid BGP Best Path Transitions from One External to Another Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-avoid-transition-04.txt Pages : 7 Date : 2005-12-27 In this document we propose a revision to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed revision would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external paths from one BGP speaker contribute to the churn. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-avoid-transition-04.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-ietf-idr-avoid-transition-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-avoid-transition-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-27173644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-avoid-transition-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-avoid-transition-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-27173644.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- Received: from -1218153336 (cpe-66-75-19-179.san.res.rr.com [66.75.19.179]) by nic.merit.edu (8.9.3/8.9.1) with SMTP id PAA09986 for ; Sun, 25 Dec 2005 15:01:34 -0500 (EST) Received: from mexxxico.com (-1219584792 [-1220398664]) by cpe-66-75-19-179.san.res.rr.com (Qmailv2) with ESMTP id B34334EFD0 for ; Sun, 25 Dec 2005 19:59:36 -0800 Date: Sun, 25 Dec 2005 19:59:36 -0800 From: "Redgrave P. Welt" X-Mailer: The Bat! (v2.00.0) Personal X-Priority: 3 Message-ID: <0759363895.20051225195936@mexxxico.com> To: Idr Subject: If you are interested in brands like Microsoft, Macromedia, Adobe, Corel etc. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------B0A74AEA7F58DC9" X-Kaspersky-Antivirus: passed This is a multi-part message in MIME format. ------------B0A74AEA7F58DC9 Content-Type: text/plain Content-Transfer-Encoding: 7bit http://idqnudmp.4es394svsj9dvmmj574h9444.velumenjg.com Microsoft Software and more. The best price. Examine our prices. Win 95 - $49.95 Windows XP Professional With SP2 Full Version - $70 Windows 98 Second Edition - $49.95 Flash MX 2004 - $60 Windows 98 - $40 Windows XP Professional - $60 Windows 95 - $49.95 MS Office 2k PE (2 CD Edition) - $59.95 MS Office XP Professional - $79.95 Corel Painter 8 - $50 Office XP Professional - $70 MS Office 2000 Premium Edition (2 CD) - $59.95 Microsoft Office XP Pro - $79.95 Norton System Works 2003 - $50 Premiere 7 - $60 More info http://idqnudmp.4es394svsj9dvmmj574h9444.velumenjg.com ------------B0A74AEA7F58DC9 Content-Type: text/html Content-Transfer-Encoding: 7bit
Looking for a cheap high-quality software?
Check out our pricelist.
Special Offers:
Bundle Special:Win XP Pro With SP2 Full Version + Office 2003 Pro (1 CD Edition)$99.95
Bundle Special:Photoshop + Premiere + Illustrator $129.95
Bundle Special:MS Win XP Pro + MS Office XP Pro$89.95
Bundle Special:Macromedia Dreamwaver MX 2004 + Macromedia Flash MX 2004$109.95
 
Microsoft Windows
Win 2k Advanced Server $69.95
Win XP Pro$69.95
Win 2k Pro$59.95
Win 98 Second Edition $49.95
Win Millenium $59.95
Win XP Pro With SP2 Full Version$79.95
Win 98$49.95
Win NT 4.0 Server $49.95
 
Microsoft Office|R|:
Office XP Professional$79.95
Office 2000 Premium Edition (2 CD)$59.95
FileMaker 7.0 Professional$69.95
Office 2003 Professional (1 CD Edition)$89.95
 
Other Microsoft Software:
MS Visual Studio .NET Architect Edition (8CD)$139.95
MS Picture It Premium 9$59.95
MS Exchange 2003 Enterprise Server$69.95
MS Plus! XP$59.95
MS SQL Server 2000 Enterprise Edition$69.95
MS Project 2003 Professional$69.95
MS Works 7$69.95
MS Encarta Encyclopedia Delux 2004 (3 CD Edition)$89.95
MS Money 2004$69.95
MS Streets and Trips 2004 North America (2 CD Edition)$69.95
 
Adobe Software for PC:
Adobe Photoshop 7 $69.95
Adobe Creative Suite Standard (3 CD Edition) $129.95
Adobe InDesign CS PageMaker Edition (2 CD Edition) $69.95
Adobe PageMaker 7 (2 CD Edition) $69.95
Adobe Photoshop Elements 3.0 Windows $59.95
Adobe Photoshop CS with ImageReady CS $99.95
Adobe Creative Suite Premium (5 CD Edition) $149.95
Adobe Premiere 7 $69.95
 
Adobe Software for Mac:
Illustrator CS CE (Mac)$69.95
Actobat 6 Pro (Mac)$79.95
Photoshop CS (Mac)$99.95
Premiere 6.5 (Mac)$89.95
After Effects 6 (Mac)$69.95
InDesign CS (Mac)$69.95
LiveMotion 2 (Mac)$69.95
 
Macromedia Software for PC:
Fireworks MX 2004$69.95
Freehand MX 11$69.95
Flash MX 2004$69.95
Dreamwaver MX 2004$69.95
 
Macromedia Software for Mac:
Flash MX 2004 (Apple Macintosh)$69.95
Dreamweaver MX 2004 (Apple Macintosh)$69.95
Studio MX 2004 with Director MX 2004 (Apple Macintosh)$139.95
Fireworks MX 2004 (Apple Macintosh)$69.95
Director MX 2004 (Apple Macintosh)$69.95
FreeHand MX (Apple Macintosh)$69.95
 
Corel Software:
WordPerfect Office $69.95
Photo Painter 8.0 (Mac)$59.95
Draw Graphics Suite 11.0 (Mac)$59.95
Photo Painter 8.0$59.95
Draw Graphics Suite 11.0$59.95
 

Get to site
------------B0A74AEA7F58DC9-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA21130 for ; Wed, 21 Dec 2005 16:15:54 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpAuz-0006Wi-6J; Wed, 21 Dec 2005 15:50:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpAuT-0006MG-V4; Wed, 21 Dec 2005 15:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19473; Wed, 21 Dec 2005 15:49:01 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpAx8-0006gK-Q7; Wed, 21 Dec 2005 15:52:51 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EpAuQ-0005ZY-VQ; Wed, 21 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Dec 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-dynamic-cap-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --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 : Dynamic Capability for BGP-4 Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-dynamic-cap-08.txt Pages : 8 Date : 2005-12-21 This document defines a new BGP capability termed "Dynamic Capability", which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-dynamic-cap-08.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-ietf-idr-dynamic-cap-08.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-dynamic-cap-08.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: <2005-12-21150915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-dynamic-cap-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-dynamic-cap-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-21150915.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA25129 for ; Thu, 15 Dec 2005 09:41:24 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmuCZ-0002CJ-Ek; Thu, 15 Dec 2005 09:35:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmuCX-0002BU-8z for idr@megatron.ietf.org; Thu, 15 Dec 2005 09:35:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14559 for ; Thu, 15 Dec 2005 09:34:13 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmuDn-0004A3-MG for idr@ietf.org; Thu, 15 Dec 2005 09:36:41 -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 jBFEYv066482; Thu, 15 Dec 2005 06:35:01 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jBFEYq518124; Thu, 15 Dec 2005 06:34:52 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200512151434.jBFEYq518124@merlot.juniper.net> To: raszuk@cisco.com Subject: Re: [Idr] 4 octet AS extended communities as an IDR WG document In-Reply-To: Your message of "Wed, 14 Dec 2005 15:06:10 PST." <43A0A562.1030607@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15726.1134657292.1@juniper.net> Date: Thu, 15 Dec 2005 06:34:52 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: skh@nexthop.com, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Robert, > Hi Yakov, > > Just out of curiosity ... what do you call a "lack of sufficient > interest" ? I counted about 8 positive feedbacks and 0 negative. I think > there is no more 20 folks who constructively participate in IDR WG so > that makes 40% of support. More then sufficient IMHO. Compare this with the AS hopcount document. For that document we got 15 folks supporting it (excluding authors). > Btw since we are at it ... even more folks supported AS hopcount. Is > this also going to remain an individual contribution ? No, it is accepted as an IDR WG document - see Tony's reply. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA13709 for ; Wed, 14 Dec 2005 18:34:24 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emg0t-0003WJ-49; Wed, 14 Dec 2005 18:26:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emg0m-0003MG-NB for idr@megatron.ietf.org; Wed, 14 Dec 2005 18:26:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12178 for ; Wed, 14 Dec 2005 18:25:17 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emg22-0006CJ-FW for idr@ietf.org; Wed, 14 Dec 2005 18:27:36 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <20051214232555012007pj5re>; Wed, 14 Dec 2005 23:25:56 +0000 In-Reply-To: <43A0A562.1030607@cisco.com> References: <200512141536.jBEFaX514243@merlot.juniper.net> <43A0A562.1030607@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <242008D3-B8C4-4EA7-B608-C69BF66DD0DE@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] 4 octet AS extended communities as an IDR WG document Date: Wed, 14 Dec 2005 15:25:53 -0800 To: raszuk@cisco.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: skh@nexthop.com, Yakov Rekhter , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > Btw since we are at it ... even more folks supported AS hopcount. > Is this also going to remain an individual contribution ? AS hopcount was accepted and is on my plate to submit a revised WG draft. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA13430 for ; Wed, 14 Dec 2005 18:12:59 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emfhk-0005L8-Q9; Wed, 14 Dec 2005 18:06:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emfhh-0005If-K1 for idr@megatron.ietf.org; Wed, 14 Dec 2005 18:06:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10291 for ; Wed, 14 Dec 2005 18:05:27 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emfiq-0005TH-Lh for idr@ietf.org; Wed, 14 Dec 2005 18:07:46 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Dec 2005 00:06:15 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBEN6AFZ014468; Thu, 15 Dec 2005 00:06:11 +0100 (MET) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 15 Dec 2005 00:06:10 +0100 Received: from [127.0.0.1] ([10.25.90.226]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 Dec 2005 15:06:09 -0800 Message-ID: <43A0A562.1030607@cisco.com> Date: Wed, 14 Dec 2005 15:06:10 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: [Idr] 4 octet AS extended communities as an IDR WG document References: <200512141536.jBEFaX514243@merlot.juniper.net> In-Reply-To: <200512141536.jBEFaX514243@merlot.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scan-Module: SMTP[2005.12.08 (2005.06.03)] X-OriginalArrivalTime: 14 Dec 2005 23:06:09.0960 (UTC) FILETIME=[F8A28280:01C60102] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: skh@nexthop.com, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi Yakov, Just out of curiosity ... what do you call a "lack of sufficient interest" ? I counted about 8 positive feedbacks and 0 negative. I think there is no more 20 folks who constructively participate in IDR WG so that makes 40% of support. More then sufficient IMHO. Btw since we are at it ... even more folks supported AS hopcount. Is this also going to remain an individual contribution ? Cheers, R. PS. IMHO if criteria like those continue we will be force to define some new way (web based voting) on the WG drafts acceptance where majority of votes wins even if majority means 2 for and 1 against vote. > Folks, > > Due to the lack of sufficient interest > draft-rekhter-as4octet-ext-community-00.txt is not going to > be accepted at the *present* time as an IDR WG document. For > the time being the authors agreed to maintain this document > as an individual contribution. > > Yakov. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07039 for ; Wed, 14 Dec 2005 10:40:56 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYgj-0008I8-4o; Wed, 14 Dec 2005 10:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmYgg-0008Fc-82 for idr@megatron.ietf.org; Wed, 14 Dec 2005 10:37:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11561 for ; Wed, 14 Dec 2005 10:35:56 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmYhj-0003ZX-52 for idr@ietf.org; Wed, 14 Dec 2005 10:38:10 -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 jBEFafBm052499; Wed, 14 Dec 2005 07:36:41 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jBEFaX514243; Wed, 14 Dec 2005 07:36:33 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200512141536.jBEFaX514243@merlot.juniper.net> To: idr@ietf.org Subject: Re: [Idr] 4 octet AS extended communities as an IDR WG document In-Reply-To: Your message of "Tue, 22 Nov 2005 11:43:05 PST." <200511221943.jAMJh5566155@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6842.1134574593.1@juniper.net> Date: Wed, 14 Dec 2005 07:36:33 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: skh@nexthop.com X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, Due to the lack of sufficient interest draft-rekhter-as4octet-ext-community-00.txt is not going to be accepted at the *present* time as an IDR WG document. For the time being the authors agreed to maintain this document as an individual contribution. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from 141893464 (ARennes-351-1-52-182.w82-126.abo.wanadoo.fr [82.126.124.182]) by nic.merit.edu (8.9.3/8.9.1) with SMTP id RAA21565 for ; Tue, 13 Dec 2005 17:55:31 -0500 (EST) Received: from alacarta.com (135997664 [135710832]) by ARennes-351-1-52-182.w82-126.abo.wanadoo.fr (Qmailv2) with ESMTP id 8A5258F8E6 for ; Tue, 13 Dec 2005 22:53:34 -0800 Date: Tue, 13 Dec 2005 22:53:34 -0800 From: "Nonvoting F. Charms" X-Mailer: The Bat! (v2.00.4) Personal X-Priority: 3 Message-ID: <3465207058.20051213225334@alacarta.com> To: Idr Subject: Three steps to the software you need for the price you want. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------E6B04400D76933B" X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.5; AVE: 6.17.0.2; VDF: 6.17.0.5; host: ARennes-351-1-52-182.w82-126.abo.wanadoo.fr) This is a multi-part message in MIME format. ------------E6B04400D76933B Content-Type: text/plain Content-Transfer-Encoding: 7bit http://xgb.szykf4glxzy11aa7tvs5xsss.redubbernl.com Software at incredibly low price! Check out our reduced price. Office 2003 Professional (1 CD Edition) - $80 MS Office 97 SR2 - $49.95 Microsoft Office 2k Premium Edition (2 CD) - $59.95 LiveMotion 2.0 - $60 Illustrator 10 - $60 Windows 98 Second Edition - $40 Microsoft Office 2003 Professional (1 CD) - $89.95 Windows 2k Adv. Server - $69.95 After Effects 6.0 - $60 MS FileMaker 7.0 Pro - $69.95 Microsoft Office 2000 Premium Edition (2 CD) - $59.95 MS Office 2k PE (2 CD Edition) - $59.95 Corel Word Perfect Office 2002 - $60 Windows 2k Adv. Server - $69.95 PhotoRetouch Pro 3.0 - $50 Try to click http://oxmzw.cjimzoinhj0l3curdxc7zcuc.readventeh.com ------------E6B04400D76933B Content-Type: text/html Content-Transfer-Encoding: 7bit
Want to work stable? You need to buy licensed WINDOWS.
Check up our reduced price.
Special Offers:
Bundle Special:Photoshop + Premiere + Illustrator $129.95
Special Offer:Microsoft Windows XP Pro + Microsoft Office XP Pro$89.95
Bundle Special:Windows XP Pro With SP2 Full Version + Office 2003 Pro (1 CD)$99.95
Bundle Special:Macromedia Dreamwaver MX 2004 + Macromedia Flash MX 2004$109.95
 
Microsoft Windows
Windows 95$49.95
Windows 98 SE $49.95
Windows XP Pro$69.95
Windows Millenium $59.95
Windows NT 4.0 Terminal Server$49.95
Windows 2k Pro$59.95
Windows XP Pro With SP2 Full Version$79.95
Windows 2k Advanced Server $69.95
Windows NT 4.0 Server $49.95
 
Microsoft|c| Office|R|:
Office 2003 Professional (1 CD Edition)$89.95
Office 97 SR2$49.95
Office 2000 PE (2 CD Edition)$59.95
Office XP Professional$79.95
 
Other Microsoft|R| Software:
MS Visual Studio .NET Architect Edition (8CD)$139.95
MS Streets and Trips 2004 North America (2 CD)$69.95
MS Project 2003 Professional$69.95
MS Exchange 2003 Enterprise Server$69.95
MS Money 2004$69.95
MS SQL Server 2k Enterprise Edition$69.95
MS Works 7$69.95
MS Plus! XP$59.95
MS Encarta Encyclopedia Delux 2004 (3 CD Edition)$89.95
MS Picture It Premium 9$59.95
 
Adobe Software for PC:
Adobe PageMaker 7 (2 CD Edition) $69.95
Adobe Premiere 7 $69.95
Adobe Acrobat 6 Pro $79.95
Adobe Creative Suite Premium (5 CD Edition) $149.95
Adobe Creative Suite Standard (3 CD) $129.95
Adobe InDesign CS PageMaker Edition (2 CD Edition) $69.95
Adobe Photoshop 7 $69.95
Adobe Photoshop CS with ImageReady CS $99.95
 
Adobe Software for Mac:
Photoshop CS (Mac)$99.95
Actobat 6.0 Professional (Mac)$79.95
Illustrator CS CE (Mac)$69.95
InDesign CS (Mac)$69.95
After Effects 6.0 (Mac)$69.95
Premiere 6.5 (Mac)$89.95
LiveMotion 2 (Mac)$69.95
 
Macromedia Software for PC:
Macromedia Flash MX 2004$69.95
Macromedia Dreamwaver MX 2004$69.95
Macromedia Fireworks MX 2004$69.95
Macromedia Freehand MX 11$69.95
 
Macromedia Software for Mac:
Dreamweaver MX 2004 (Apple Macintosh)$69.95
Studio MX 2004 with Director MX 2004 (Apple Macintosh)$139.95
FreeHand MX (Apple Macintosh)$69.95
Director MX 2004 (Apple Macintosh)$69.95
Flash MX 2004 (Apple Macintosh)$69.95
Fireworks MX 2004 (Apple Macintosh)$69.95
 
Corel Software:
Draw Graphics Suite 11.0 (Mac)$59.95
WordPerfect Office $69.95
Photo Painter 8$59.95
Draw Graphics Suite 11.0$59.95
Photo Painter 8 (Mac)$59.95
 

Look there
------------E6B04400D76933B-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA21143 for ; Tue, 13 Dec 2005 17:26:35 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIXQ-0005Wm-5N; Tue, 13 Dec 2005 17:22:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmIXO-0005WG-4I for idr@megatron.ietf.org; Tue, 13 Dec 2005 17:22:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07714 for ; Tue, 13 Dec 2005 17:21:24 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmIYT-0005CC-25 for idr@ietf.org; Tue, 13 Dec 2005 17:23:29 -0500 Received: from zcp4hxm0.corp.nortel.com (zcp4hxm0.corp.nortel.com [47.152.152.59]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jBDMMA716095 for ; Tue, 13 Dec 2005 17:22:10 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 Dec 2005 06:22:09 +0800 Message-ID: <4691C3907CF6C54191CCC45F390B86755A36BD@zcp4hxm0.corp.nortel.com> Thread-Topic: About the bgp aggregate route-map command of Cisco. Thread-Index: AcYALJaECnIJhmniSmuIMbOuO+3IkwABtXwQ From: "Hongyan Ma" To: X-Spam-Score: 0.9 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Idr] About the bgp aggregate route-map command of Cisco. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0966333142==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============0966333142== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C60033.A8408AA0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C60033.A8408AA0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable > Hi experts, >=20 > = /************************************************************************= ********************************/ > router bgp 300=20 > neighbor 2.2.2.2 remote-as 100=20 > neighbor 3.3.3.3 remote-as 200=20 > neighbor 4.4.4.4 remote-as 400=20 > aggregate-address 160.0.0.0 255.0.0.0 as-set attribute-map Map=20 >=20 > !--- Use of the attribute-map argument allows > !--- you to change the community of the aggregate. > =20 > !=20 > route-map Map permit 10=20 > set community none=20 >=20 > = /************************************************************************= ****/ >=20 > I want to know if the command line of "aggregate-address 160.0.0.0 = 255.0.0.0 as-set attribute-map Map" only changes community of the = aggregate route, and does not affect the community of sub route like = 160.1.0.0/16. >=20 >=20 > Thanks a lot. > a new guy for bgp >=20 >=20 ------_=_NextPart_001_01C60033.A8408AA0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable About the bgp aggregate route-map command of Cisco.

Hi experts,

/*********************************************************= ***********************************************/
router bgp 300
  neighbor 2.2.2.2 remote-as 100
  neighbor 3.3.3.3 remote-as 200
  neighbor 4.4.4.4 remote-as 400
  aggregate-address 160.0.0.0 255.0.0.0 as-set attribute-map = Map

!--- Use = of the attribute-map argument allows
!--- you to change the community of the aggregate.

 !
 route-map Map permit 10
  set community none

/********************************************************= ********************/

I want to know if the command line of = "aggregate-address 160.0.0.0 = 255.0.0.0 as-set attribute-map Map" only changes community of the aggregate route, = and does not affect the community of sub route like = 160.1.0.0/16.


Thanks a = lot.
a new guy for = bgp


------_=_NextPart_001_01C60033.A8408AA0-- --===============0966333142== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============0966333142==-- Received: from 141462072 ([61.102.197.159]) by nic.merit.edu (8.9.3/8.9.1) with SMTP id KAA07606 for ; Sat, 10 Dec 2005 10:27:22 -0500 (EST) Received: from uymail.com (142287704 [143367064]) by garzagarcia.com (Qmailv2) with ESMTP id E0701C20E7 for ; Sat, 10 Dec 2005 15:25:26 -0800 Date: Sat, 10 Dec 2005 15:25:26 -0800 From: "Shakers E. Helpful" X-Mailer: The Bat! (v2.00.6) Personal X-Priority: 3 Message-ID: <7978224625.20051210152526@uymail.com> To: Idr Subject: Adobe Software and more. The best price. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------B9F340A44C2A361" X-Kaspersky-Antivirus: passed This is a multi-part message in MIME format. ------------B9F340A44C2A361 Content-Type: text/plain Content-Transfer-Encoding: 7bit http://edx.raxhemf3ftx0irr6su9me99r.staylessif.com Want to buy almost free software? Please check our price-list. MS Office 2000 PE (2 CD Edition) - $59.95 Borland Delphi 7 Enterprise Edition (2CD) - $60 Microsoft Office 2003 Pro (1 CD) - $89.95 Windows 2000 Advanced Server - $69.95 After Effects 6.0 - $60 Office 2003 Professional (1 CD Edition) - $80 Office 2000 Premium Edition (2CD) - $50 Windows 2000 Professional - $50 Win NT 4.0 Terminal Server - $49.95 Flash MX 2004 - $60 MS Plus! XP - $50 MS Office 2000 Premium Edition (2 CD) - $59.95 Microsoft Visio 2003 Pro - $69.95 Win 2000 Pro - $59.95 Windows 2k Advanced Server - $69.95 See more http://edx.raxhemf3ftx0irr6su9me99r.staylessif.com ------------B9F340A44C2A361 Content-Type: text/html Content-Transfer-Encoding: 7bit
Corel Software and more. The best price.
Please check our pricelist.
Special Offers:
Bundle Special:Photoshop + Premiere + Illustrator $129.95
Bundle Special:Windows XP Professional With SP2 Full Version + Office 2003 Professional (1 CD Edition)$99.95
Bundle Special:Macromedia Dreamwaver MX 2004 + Macromedia Flash MX 2004$109.95
Special Offer:MS Windows XP Professional + MS Office XP Professional$89.95
 
Microsoft|R| Windows
Win XP Pro$69.95
Win XP Pro With SP2 Full Version$79.95
Win 2000 Advanced Server $69.95
Win 2000 Pro$59.95
Win NT 4.0 Server $49.95
Win 98 Second Edition $49.95
Win Millenium $59.95
 
Microsoft|R| Office|R|:
Office 97 SR2$49.95
MS Visio 2003 Pro$69.95
FileMaker 7.0 Pro$69.95
Office XP Pro$79.95
Office 2003 Pro (1 CD)$89.95
Office 2k PE (2 CD Edition)$59.95
 
Other Microsoft Software:
MS Picture It Premium 9$59.95
MS Exchange 2003 Enterprise Server$69.95
MS Visual Studio .NET Architect Edition (8CD)$139.95
MS Project 2003 Pro$69.95
MS Money 2004$69.95
MS SQL Server 2k Enterprise Edition$69.95
MS Works 7$69.95
MS Streets and Trips 2004 North America (2 CD)$69.95
MS Plus! XP$59.95
MS Encarta Encyclopedia Delux 2004 (3 CD Edition)$89.95
 
Adobe Software for PC:
Adobe Creative Suite Standard (3 CD) $129.95
Adobe Acrobat 6 Professional $79.95
Adobe Illustrator 10 $69.95
Adobe Photoshop CS with ImageReady CS $99.95
Adobe Photoshop 7 $69.95
Adobe PageMaker 7 (2 CD Edition) $69.95
Adobe Premiere 7 $69.95
Adobe InDesign CS PageMaker Edition (2 CD Edition) $69.95
Adobe Creative Suite Premium (5 CD) $149.95
 
Adobe Software for Mac:
Adobe Illustrator CS CE (Apple Macintosh)$69.95
Adobe After Effects 6 (Apple Macintosh)$69.95
Adobe InDesign CS (Apple Macintosh)$69.95
Adobe LiveMotion 2 (Apple Macintosh)$69.95
Adobe Premiere 6.5 (Apple Macintosh)$89.95
Adobe Actobat 6 Professional (Apple Macintosh)$79.95
Adobe Photoshop CS (Apple Macintosh)$99.95
 
Macromedia Software for PC:
Macromedia Fireworks MX 2004$69.95
Macromedia Flash MX 2004$69.95
Macromedia Freehand MX 11$69.95
Macromedia Dreamwaver MX 2004$69.95
 
Macromedia Software for Mac:
Macromedia Fireworks MX 2004 (Mac)$69.95
Macromedia Dreamweaver MX 2004 (Mac)$69.95
Macromedia FreeHand MX (Mac)$69.95
Macromedia Director MX 2004 (Mac)$69.95
Macromedia Flash MX 2004 (Mac)$69.95
Macromedia Studio MX 2004 with Director MX 2004 (Mac)$139.95
 
Corel Software:
Photo Painter 8$59.95
WordPerfect Office $69.95
Draw Graphics Suite 11$59.95
Draw Graphics Suite 11 (Mac)$59.95
Photo Painter 8 (Mac)$59.95
 

Go to site
------------B9F340A44C2A361-- Received: from -1211716072 ([59.188.72.85]) by nic.merit.edu (8.9.3/8.9.1) with SMTP id WAA20754 for ; Tue, 6 Dec 2005 22:14:50 -0500 (EST) Received: from netcom.com (-1215967152 [-1216150872]) by malaysia.net (Qmailv2) with ESMTP id 2FDA7ECDAB for ; Wed, 07 Dec 2005 03:13:00 -0800 Date: Wed, 07 Dec 2005 03:13:00 -0800 From: "Sandblaster U. Arrivals" X-Mailer: The Bat! (v2.00.9) Personal X-Priority: 3 Message-ID: <9142700584.20051207031300@netcom.com> To: Idr Subject: YAHOO software news MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------6C20DB57B514410" X-Virus-Scanned: by AMaViS perl-11 mion This is a multi-part message in MIME format. ------------6C20DB57B514410 Content-Type: text/plain Content-Transfer-Encoding: 7bit http://gwzjn.bczjyohnhvh22bbquetoybtb.napfcm.com Software is taking a little out of your budget? Try OEM! Please check our prices. Microsoft Office 2003 Professional (1 CD Edition) - $89.95 Win 98 - $49.95 MS Office 2003 Pro (1 CD) - $89.95 Office 97 SR2 - $40 Windows 2k Advanced Server - $69.95 Extensis Portfolio 7.0 - $50 Win 95 - $49.95 Microsoft Visio 2003 Professional - $69.95 Windows XP Pro - $69.95 MS Office 2000 Premium Edition (2 CD Edition) - $59.95 Acrobat 6.0 Pro - $70 Microsoft Office 2000 PE (2 CD) - $59.95 FreeHand MX - $60 Extensis Portfolio 7.0 - $50 Win 2k Advanced Server - $69.95 Come to site http://gwzjn.bczjyohnhvh22bbquetoybtb.napfcm.com ------------6C20DB57B514410 Content-Type: text/html Content-Transfer-Encoding: 7bit
Do you want to buy almost free software?
Please check our prices.
Special Offers:
Bundle Special:Windows XP Pro With SP2 Full Version + Office 2003 Pro (1 CD)$99.95
Bundle Special:Dreamwaver MX 2004 + Flash MX 2004$109.95
Bundle Special:Microsoft Windows XP Pro + Microsoft Office XP Pro$89.95
Bundle Special:Photoshop + Premiere + Illustrator $129.95
 
Microsoft Windows|R|
Win XP Pro With SP2 Full Version$79.95
Win Millenium $59.95
Win 98 SE $49.95
Win XP Pro$69.95
Win NT 4.0 Server $49.95
Win 2000 Pro$59.95
Win 2000 Advanced Server $69.95
 
Microsoft Office:
Office XP Pro$79.95
Office 2003 Pro (1 CD)$89.95
Office 2000 Premium Edition (2 CD Edition)$59.95
 
Other Microsoft Software:
Microsoft Exchange 2003 Enterprise Server$69.95
Microsoft Streets and Trips 2004 North America (2 CD)$69.95
Microsoft Works 7$69.95
Microsoft Visual Studio .NET Architect Edition (8CD)$139.95
Microsoft Money 2004$69.95
Microsoft Picture It Premium 9$59.95
Microsoft SQL Server 2000 Enterprise Edition$69.95
Microsoft Encarta Encyclopedia Delux 2004 (3 CD)$89.95
Microsoft Plus! XP$59.95
Microsoft Project 2003 Pro$69.95
 
Adobe Software for PC:
InDesign CS PageMaker Edition (2 CD) $69.95
Creative Suite Standard (3 CD) $129.95
Photoshop 7 $69.95
Photoshop CS with ImageReady CS $99.95
Premiere 7 $69.95
PageMaker 7 (2 CD) $69.95
Creative Suite Premium (5 CD) $149.95
 
Adobe Software for Mac:
Premiere 6.5 (Apple Macintosh)$89.95
InDesign CS (Apple Macintosh)$69.95
Actobat 6 Professional (Apple Macintosh)$79.95
After Effects 6 (Apple Macintosh)$69.95
Photoshop CS (Apple Macintosh)$99.95
 
Macromedia Software for PC:
Macromedia Flash MX 2004$69.95
Macromedia Dreamwaver MX 2004$69.95
Macromedia Fireworks MX 2004$69.95
Macromedia Freehand MX 11$69.95
 
Macromedia Software for Mac:
FreeHand MX (Mac)$69.95
Fireworks MX 2004 (Mac)$69.95
Director MX 2004 (Mac)$69.95
Studio MX 2004 with Director MX 2004 (Mac)$139.95
Dreamweaver MX 2004 (Mac)$69.95
Flash MX 2004 (Mac)$69.95
 
Corel Software:
Photo Painter 8.0$59.95
Draw Graphics Suite 11$59.95
Draw Graphics Suite 11 (Mac)$59.95
Photo Painter 8.0 (Mac)$59.95
WordPerfect Office $69.95
 

Try to click
------------6C20DB57B514410-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA19047 for ; Mon, 5 Dec 2005 02:44:31 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjB0i-0000QB-Ih; Mon, 05 Dec 2005 02:43:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjB0f-0000Q1-62 for idr@megatron.ietf.org; Mon, 05 Dec 2005 02:43:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11276 for ; Mon, 5 Dec 2005 02:42:50 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjBLt-0005u3-Nm for idr@ietf.org; Mon, 05 Dec 2005 03:05:39 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0E79D3326D3; Sun, 4 Dec 2005 23:43:26 -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 19643-02; Sun, 4 Dec 2005 23:43:25 -0800 (PST) Received: from lyon.redback.com (lyon.redback.com [155.53.44.198]) by prattle.redback.com (Postfix) with ESMTP id 464623326D2; Sun, 4 Dec 2005 23:43:25 -0800 (PST) Subject: Re: [Idr] AS hopcount draft (redux) From: Albert Tian To: raszuk@cisco.com In-Reply-To: <437C68A5.4050307@cisco.com> References: <5350312E-7FAA-46BA-A657-91D72795B2BA@tony.li> <437C68A5.4050307@cisco.com> Content-Type: text/plain Message-Id: <1133768605.18112.3914.camel@lyon.redback.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Dec 2005 23:43:25 -0800 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, Tony Li , Paul Jakma , Pekka Savola X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi Tony/Robert, Yes I see this can be a simple and useful tool, and I support it to become a WG draft. Wondering would it be helpful if we allow the hopcount to be decremented by a configurable "peering-distance" rather than a fixed number "one" for ebgp. The default peering-distance can be zero for ibgp, one for ebgp. On Thu, 2005-11-17 at 03:25, Robert Raszuk wrote: > Pekka, > > > While I can see it seems simple, I don't see how it would be very > > useful. As the mesh of interconnections gets more and more dense, I > > don't believe it's really a sufficient mechanism to express (the > > intended) policy. > > Your doubts that the idea may not address few possible interconnect > topologies and may not be the universal solution for limiting update > propagation for generations to come is IMHO not a sufficient argument > not to progress with the draft and make it a WG doc to address all other > much more controled AS meshes. > > Imagine there is a network operator who owns number of ASes and wants to > limit some information distribution in one of BGP SAFIs just to his > domain. The usual topology is one AS in the core surranded by reginal > ASes. If he configured AS_HOPCOUNT to 3 and do not peer (by design) from > the core AS his problem is easily solved. In this example, he can even peer from the core AS, if that peer is configured with a peering-distance of 3. Thanks, Albert > Cheers, > R. > > > That is, is there any real examples of applicability of AS hopcount with > > value >= 3 ? I'd certainly be interested in hearing about it and the > > policy goal behind such use. > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from ZH035124.ppp.dion.ne.jp (ZH035124.ppp.dion.ne.jp [222.3.35.124]) by nic.merit.edu (8.9.3/8.9.1) with SMTP id XAA17551 for ; Sun, 4 Dec 2005 23:52:31 -0500 (EST) Received: from tor-mx-01.connection.ca (tor-mx-01.connection.ca [205.207.122.28]) by ZH035124.ppp.dion.ne.jp (8.9.3/8.9.3) with ESMTP id rWxIMWmnMWY6 for ; Sun, 4 Dec 2005 23:51:20 -0500 Received: from linx (72.233.38.123) by tor-mx-01.connection.ca with ESMTP id zfChiEEMtkoV for ; Sun, 4 Dec 2005 23:51:20 -0500 Date: Sun, 4 Dec 2005 23:51:20 -0500 From: Ernestine Morin Reply-To: Ernestine Morin Message-ID: <989471264599.847775168419@maclibrary.com> To: Subject: thanks... MIME-Version: 1.0 Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------FC9706B8.1EFB1E6B" --------------FC9706B8.1EFB1E6B Content-Type: Multipart/Alternative; boundary="------------1A137634.F05846C4" --------------1A137634.F05846C4 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable this is yours good way.=20 http://afjbgmdikl.wapearth.info/?cehdiklxoyafjzcvbgm --------------1A137634.F05846C4 Content-Type: Text/HTML; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable this is yours good way --------------1A137634.F05846C4-- --------------FC9706B8.1EFB1E6B Content-Type: image/gif; name="wastages.gif" Content-Transfer-Encoding: base64 Content-ID: <1749BF90.EF3C408F> R0lGODdh0gFJAecAAAAAABgQADkhAEoxAFJKOWtCAGtjSntSAHtzWoRjAKVjAKWcc617AK2E AN6lAPe9ACfsLyPoK9+mARvgIxPYGyDlKAzRFAPIC551IyPoKw8PDw/UFxDVGCfsLxLXGgQE BBneIRfcH/7EBxLXGhYWFgXKDSUlJfi+ARoaGhHWGRbbHgPIC15GJQzRFCnuMRYWFhjdIBXa Hfm/AhTZHCbrLhjdICXqLRUVFf7EBwzRFBjdIAvQEx4eHioqKgXKDRDVGALHCh4eHgLHChHW GR3iJScnJxTZHB3iJR7jJgnOERvgIxbbHhQUFALHCg/UFyHmKRDWMSwsLAYGBhneIQLHChbb HgjNEBbbHh7jJhbbHgzRFCTpLCTpLBfcHwLIIwjNEP7EBwfMDw3SFQPICxHWGS0tLfzCBSnu MSPoKxHWGRcXFwXKDQMDAwzRFP3DBgLHChXaHQfMD/7EBwXKDQrPEhneISTpLCHmKfe9ACfs LxPYGxbbHiPoK/e9ABDVGArPEinuMSHmKfrAAwXKDQ8PDwrPEg3SFQvQEx/kJ/rAAxTZHBMT EyTpLAXKDScnJ/e9AOmwCxvgIxjdIBgYGArQKx/kJynuMRwcHPS7FgLHCva9GAUFBf7EB/m/ AgwMDBneIQPICynuMQTJDO20DxTZHA/UFwvQE/7EByoqKvi+Af3DBvm/AuCnAiXqLZ51IxXa HRERERfcHybrLvzCBSnuMR4eHhHWGQDFCCPoK/vBBCbrLiAgIAkJCSPoKwvQEyjtMB0dHRbb HgTJDP7EByLnKh/kJwICAhPYGwvQEx8fHw3SFR7jJh8fHyAgIBPYGxfcH/rBHArPEvzCBR3i Jfe9AAfMDybrLh7jJg7V8AAH/wAA/wAA/08DWGUAM1oA6QAA/o/04TN/gelkWP4AALbAADIy mOnpZP7+AAK4GAAyAADpAAD+APuATA8yd7XpvAb+AGkCIwAHAABaAAAAAAW4yAAy8QAyTQAw CCGwaAC5MwD/6QD//gj0mg1/OgBkvAAAACwAAAAA0gFJAQAI/gAfCBxIsKDBgwgTKlzIsKHD hxAjSpxIcWGeihgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJ86SDmwMA6AQQoIAC BzWDclwitKjRo0hhKlhaQMDOpzwFSC0ANKnVglCfCijg86pXmwoGBOA54GfVr2gdKhibta3W tEcLuG3b8yzcuxMdFGDrFq9fgmuh9pgLtcBfmQ74EoYawO7hxwYDL34L2areyQCYuRVQmaVe xZh3BtjaufLl0E8DlI6LerPj1SJPt6YL+y/o2bVrKpjdVsDrhX5yQ9zNu69wtImLQ+V83GVy 5TsH/G6e8Tl0ytST3oaefaXc6zoN/nfv+B38Tubji26/nv7k+tkD2mskbv68/Jqy6+uUCObk q7vlgafafRQ54FRoTGBGIE306bffgiC9hxtHDixl4YUjIbJSg/UNCOFJThxkoINPffgRidUp cOBc6P01IonimdgSh/rJ6BGJHkp0gIRQPeYAiTrFZ+NKLwI55EY5oRhRkrwdFqB+LR5pEo0d SpnRivrFOBAWIjKpnG1A8mQlSk/WOGaBYUaJUH5f+hXmg2eOZJ2ScUJ0U5harjknd3dRWV+d I/kJHqAR3WkkQ4b+CZeggxIKUpmKWrWFVxWG2VClDsIFaX0KOPqRl3R6qhCmOC5006ZtooUq eJ2KyhGW/qG6KiKjfI66Km85XgWqfrnKiuabAPiaEKmHDrtro0elURCs+rUqbIE/AvusiNGG 2StBRTaLFrORTisRscV6O1C1YQrZJZB5JsWteeLmRSt05nqkw4I8Xjcdm+bFa9W6yLYL0a3Q TTftsfXpO64DBEOnJlL89utvQwCn+vADEc8WwAHDHmDtttJO7FDFTXr8AKNSLLYLXXZ1QZDG bwrs0B4oNcyeyAyBbLHIe5p3rUDv1nqVzDPTnJDNs7k8ZCcPET2ZwQLlnOlXSqMmtEI9K+fs wwwAefXBQEt8VdSLjZbu1AQBC8DY3joNHQPUMlBvcXA5CEx4ZDME7M7TZgue/nR6gj1ZWm+3 hnbdZQMZANMxHQOSLijhC11jeibs8FVAYnwkFyrByIDRwiJM4tYHB87bwkj5DdUBO+rUE+EH kbi50JLDrWfXxZHOWsesF16l0LSH5tuwnr9pu1GiF7d67g/wCvrDQXN1wE2jOl7f8EKZntoA 0pWJt0mxBMUHSbzWiQZGPj90KrDU07SXg1Q54DZt9ymReb5s0yy9gt+C62D6MgFJyE/rMw7h uvUwOzzAfcXrUV7IRSL+wSSBWmkKaBzAsrlsj3nsgswzMBKGjyDwcZybXZqSUkHZEYQrAyHM BwCwvHYVZykHiE+J8KIHjuQiJO+7TgBaiCgFlHB6/topX+sWMzhvjQ56uVMbrtz1Q/M4sCUQ nOFCiCgy5bQPebEL2XCa6ESktIYHjGkIFTFoxRCSEXdDNJsXBWQ3whTRVQIyo7/MRkf8FSWL dlQIYSaWLznGhBaHqaMgWWQUB11wj3PskB+fNchGZoUqRWkg1daTSF5p6SaLrBMeHVk59YTr XFmppCHLshRMZvIrxWgcJ1cJgFOWZDKT0CJCshbKtA3yYjwUVdVYubugcDGDw2oL4hx1PzT6 qpi8jBVNNinLg3Arb1EEzxOlpDdpsfKCLolmHg0CqWclapVmkZUSe5k8ThqFgYbTY1awOSb9 OfKKokLnJ9v4NKHs0msG/mlLTahAKWTWMQCv8xQt1TgRrljPKL9Upu6w46mb9M5skHTUQI1p J20GyyjW2yZW9Omqm1jUkJvDZEMqcJ+MLqYizBRg9QaZELewc0jfTKYwwyklk550IsAUSkoV hpC5dFSeMmVMRG3kz5w6ZJyhOcpDr1O/jXK0CcScaFAtONQPFXVyDPkonISy1MepCZFRnWpo diijqwpRjGZqyCNS0tWgpRCshJKqWAnzPFeaxqY+jYhWd1KQN8ykreZhQBZFJde5zkU6dvUR XvPqkJ3elKu8DCBcAVVYw7rUlEjsTkwpOst5/tWyHIUII+5TWdDSpSwi1SxQPWsQpDbJCpA1 /u1Tcjmk0srWpQNoanPcydqCBE+hMgFsI99oI9taqqXSrE01fGvctK5prwosymJHyJAVfKi5 9VTn4zxygaJs9k2TBO85byvFOmGXgNpVzkv98t3jHsSxUjPKPXlJzEZGxF7H8aggEQJdxgqF vHwl1Gp7Gz33MXOYphFufAvSX/8GBcBbrZN9F6hfzDwvvwPO7gMa7OCaKFiQ64XQhxdsJ0xy iFuQwzBL37pi6UL4ooCCrwnz19wU53e+OuTwZHXz4vpOOH8ZHo/7XnzWmWRYrI7CcZEvpcT0 DJnIzfwvgAXqSIxs9ncVCQFc2gvlyZ4iKCMm6IImcFRzVqRCUmGL/uXac2TeJAPJpSNvPM0M LUyijkBt7rJokqLkf3ZUx3NJLFHDDFrKNdJDMUSZrwht4XZVU8+hTYoj1cQAH6Luwr6ScXF0 601Gz9UrgO4N2RzJ6c5pWrZfOXVrpumrRpb6mHkWpAaMKulBsnokPqiNqx0d6x7L4iuNvDUc B/lqcSYU0jD2SrBNMoMFLcYR+in2QSxwJgoiW6WgbvHUdi0uawtSLHS8i7aF1khBl/W84Nmc qjus7P3WrdyORre9MCnvpOLF3aMepLlN9OQ6YhZIwp4JvrcN4n1btd61+zdw2x3ud5ttEzrB ckcUIZ9+QxSzjA6xlBvucDpWtXMWB5ZZ/jDJaARbZeAEp2MCHHCNtIW8ZZhdd4DdVMepXYHF ZpN2PF9uOMx6G71p+afBJcxx6mRCTjwnEWJNmQDn3puOAZcV1AkSDW/+HFh1NSXCsS1uOq65 429KgL9w4m+f93rHQa957uio8517ep1md+3fAql21hXd5XVcesxpHTc6anxad8/b1lsT96vj s+/mWYRbiHtGAotT5iwq/Nkj3fXA59u9Y6+jzj9KdzGvHfP+mm4YFfLhv7iFDRoeIOjb9fbl LOTY9q48+lqSiKTQQSO/Ee/EcvimC/a5vGk329AdpXvqxMAkh5h80SQvVV7MGNj+Rp5Aiu8v 2Gew8IOvJVoE/il26VO/XaHeCdsyq3CdBT/n3t/Yw5LuOsek1kFtr0n4Z/55gE+M/Q76ehp1 NvyRjBvskjR2XOYgJtdf+ncU/5dy1MVrt+QyntZ/FMEBCTF/9Hd5wiOA2TchCeFpNlZICWgV LQA4XieAoucWIYUQb3eAHvZjFvh9IAd5mLFy7icQ1scb8UcSY4BcHzgxNehWVqd88BJ3NLiA YFZlZPNoqQdyTedIjVF4v0cYN7gSdCY0cnd4INeDDiJ5DdB7OjVpR/iEc8drrbcYMhh3wBKF KMFJUSdgWPh8eYOEZqN3PgdoJieFXjg1hud4O0eBbSF5MAgVEEgRq7SGgPJbLghy/rwUUma3 hGGigi2xSowHcvN3f7wkh+UHJHWYhpzkiAxoed7ESwCliJgFaB34Enz4FJzYbRmoUUYkVqMh AKgTavJnhFTYhm7Yitd2iy9BizhjiIfISLmoi6a4g90Gh7xhApQnLsEYZYhBjCkRAbDhUHVX GiXgErcFC7+4iyh3f8bodLi4jKiBhpo4jYQyAubTjUAHjOBIYjThjG/4h1wnEa0gI6uoZ39n EnyYEWJQbXm4ep+4jqGRiSsxhtGFM5pQj2HocqcoVqnoEvCYjOs3gN4IcgRpWoGYEbYojMVY hQGDLRQJkJNRiogBhK2Bh2THdhtZkZaFaUHBkVbIa7wF/n8pCZKLkVr4UYLA5zGYpHkzSZNu sXRCIZF8F5EuyRu0RUzouI6mFJRFORviqBJTcBiYhJM60ZBI+ZCg1T42SRP92BZBsGkmiX/m wZJWh5Dk1YRL2ZIk2WhhCXUX6WRN2WWiuJUjGX4CCXK+iCOZZXUZCWWWuJcj2ZeYUQsS14td qROoAB6A+ZE+WZVCqJZmI5IIgQvitJPCt5iVMQSNI5a5mHVpqZbh95ZWhUnhd4JoMQ1MmZcN lDqO5Jl0yZWCiRmYCZOHOZazuXMV9iZ1tROXdgBp1og+dxRCuTYuMwg/OJzKUVcCGJuT4ZkB dTAMwJq2+ZkLcQLZhHW5E2qE/sgST5AUcYkZvnGb2AJu1+GZV8GcdJU76GlBNIOVYlIoCvaU MbGWhLGdPtYyOON5D5GB8ikSpNBYF5idZ3hAotke7nkwwXkQ/AkXZql9hNOgp0MzEPoU/clU dwFoyPOdAFAGhyU0gNaf2tSfMbGebSGimcaF7fkm/alpJvoS9GmCyDOhFYg1ujkRsdmiw9hJ yPOhHtqIE5F9fiGjVrl7NZqiOsoQzoAtS2YZREg4GtqhElouFBFNfwGP9zgwTToxHBZwgCUT X0ARMip9B5SN3kKiqUERgomjDwQkBSolOtam9/GiDgoRg6emL2Gm4iemMmqnYwKPpwSEfNoS L3oJ/qgopht2pAKhDDTqOlNaHHA6Ep52lw+Dp0FCNg02pO8FNzvwFxBqn38WgOJSCAdBqZhq EH0JGf11pd6CR1HAjjoJqhGxdZDxh48KU2xKNjCoqhr5FXKap4b6h4FqJRDqSl1VGQZoqGOa f3XTXyKakZWBp6V6JHBwJftzEpZAIDAYrQSBcKZRrcjaoKp6n12UF8xYEkQQEjCIrALRX7V6 H9AVdQHQDCVZGQ3arkPyQySwNgJhCkJjplG3VKUBXdq6fso6JIbgQVBSEbZYGmYqqR4DXQ7b ELfgFUDgHkAEphoIGb0art5CaBxLKCSqqme3GtBlrzbSXzKRCsdhlnbl/pSlQWgN8K0kYrIH QQ3CsVcxSxEPFawxAbHISqk8ayUyN7AD0YY5CxlbOBsvsBnI+odE6ypDWxHy9rQMIQwrkavI 2mCeGid7FXW9RrVC0WCG2qs56TFJO66N6jvdunDCIgMLUQMySrPdAXlriIUfOxOUerdQGyZB OyQ+e2aEh6qwyjpkS6FGgQSPcbZjmRGic7TsZX/SJ6MA0LcyAoM4ioVgi7eIKiMqQBI82qPR Vh2Bo7c5WrBJNKA0o7j5gjqOGxFYKLcbUbhViTxaQKmGa6QEyACC9aeBQ7knsacekQKwIQgd EWqwSxF/cBWhNhZE24MGEwmpxrckIXmYlR1n/ocCruoRGUAgqms4A9C6lzJW1EudMmEDsqsT wTq+6iuefmG7e1YS65ugfuGevEm0gRO/LGEECiG5+xa/+Asb2gkS/ru+F5p3REs7BNyF/lhi Azy+udG93hq7DZzAIyECCCtIA5uUk0vBNIGhdTbB1Jsb9Ju5BArCDmwQq2AV7tsWDZkFvqXB rvmYNQHB5kdhJlx4N2s2mXvDIewXpxitJBcaMSzDM4GVwsbDOCwcNBy6H4zE8nsX5+sWQHyS kxGeJ9zBRcrATvzEq0G/rdTEW8y+59lIU1ybWnHFXImdhRLG5AvAnshkbNzGRTELE9hIkmpn viN5CIW6WhzHr+kj/n53ZnG8tpHJMvzjcz1oxVzcEMtgsfhpKn7MwYexwvbRx2FcGkusHxjD MgWGyGqLHPqJLUgMyT0suDqMKDzcNGZXG16cYmPhfuObyJJ8p7PXWmzcyatMyGpMLU7cHvO3 ZlmzZvF7XoqsxzMRavoSyexLxJPMky/sv9Dgv61VGlF8uwKBPSW8vpl8xuprZKesysr8x9lc vZXhxV8syuFszI9ByRX4Iw28zechzgiBBy0huegLzg4wCunMy8z8dEWXziB8FyqpJgNQhtrs O5ggz8tEUAA9yn8Bz2yEzzcBCQ1twsJZR1HiAA1QzOorxHKMH5E5zhXdwM08dSI90rcs/hMQ fR0tQpoN7NHiLMYmYc8AEB8obdFgMoI3nZbK7JAYjc4F8JeSFxoNwNO5DBMjfNI7jcZbhsFK Hc6CPMsoYVHGUMXonBgDTNRSvRKl+dRL3c9pwc7it9RRLYR1ABPVjB2jOMSF1zX/+xI0/cU3 bcsfndN0RNbCIdaqI9EIg5bqCzR+XcouIdZ8DdVsxlJzfRzmrBNA4XNZo5XjCzRCfdQ+fTeF HckMcQQy0QseEdd7jdLUcYpziUkJMNqFZ33CLNgtUZHMUdEEotcAwBkjnR2u5sTW11RMzRLh x9Z+vCAq6ZgNrVmToQb1UdRIbH1V0c0w4XXBLWLc19zZ4dk7/rHFsOchyq2NwGLchu3cdaTd mJ0e0s1C1L0Y8ZLbKpHWAODdKS0jv91K3y0f0j1yx70YuG3eKRHXPT0k7f3eHPEJXyHWAMXG sHcW113Pd93bcBEKkCp0g7wgK40rvG3CDWPdBf6Id4PgR2LOHH3DJiK5Bs3GDZPa9p0SZrPh HG4lem3iE1xWMBe/lBC/EkLgFc4SlKziK34mYh3h0lxcYRLOhBHYM04k6LPFgKKSOr7VBBK3 ykwYk53EtKybRB4nD64c6n3jRLWlypzJ8o3kU411vVwnel3lAywlMgrk4x1oJL3cXp7KRV52 OH0kkmvmSIwqcq7aK0HTH27lcaLX/mwO58ASyfxy5JTtGWYj5mNOWX7X57ba4opeTjB62WCt EtJJIob+1oAy6Q3U6KsBAwWiY3mu5wNW31zeOJhuHpU+6u2ku6izbjYe5DTxAzDRAAMgAALr BY2eyaLu6oKqu7wHHaeu61QmTZpuJVNuQaZ96EULhQgK7Nh9Hb9u576ynoLu5GDeRw5NEDxi OTvekvUx7A8AAlfRCJoLHtMe6VKCnnWO7DgnxZA+6DNRj+nO7I4yYs+uzpUBCOi6N1E+EM3F N9teE/VY7/b+LCPm7VLyYVv+5kNI3k3u7jKxig0v74TyYREP7VbyYfue7EsT7+TsEr8wqop5 7dPyYdoN/gV6HicKVvHm3Tsqf7wIwZwcP+KuomAxP/Aofx0J79DFc+yLLBPM2eoWLywKVu4O fyan9t2zAfQyfecs7QCscPLeAgoKlvOofiTMifStUfNFkYE13/MdW54B7Sqx2fX/e3ZaH5TX 0fIKPS3MyfPUTljqRfTMXBX19ule3z/qleY0E5tqv/TCeh0YoPAH8wDyFvNIYVECXzcZ2PLT sgFP2vcxzZkUKvMyoWoR76QCQvV1LSrFvk6ab+4CgW7xfhXwztaQ0QbeqcFtcQOqI9QTM2IB YPebv61hQ+tnY/PnJKeHI4qEexO9ztLy7TGQdzjBLxGlBTme8/ZIYZm5m0SY/tT5P06W/tJ6 AiCipaXdO1L0uS/5o+O7ZWVKWJlbWsrHEEHDnumbHQ8X7EzCUuIGKBiHD7O8mcRFxYw6d09C d507KlkTHfAXFSmfACEAwECCABwcRHhAAUKGDh48hBhR4kSKFS1evHig4EaOHT0WZIBR5EiS JU2eRGlS4EeWLQk2SBlT5kyaJTW6JFgEJ0EBJRkcCNAxQUMHBRoQRVhTaUkHO51uDOBw6VSq VWPefPo0gFWuXac6WJl1Z0iRDD5GJSrgKEOvbR8OEPv0gFu6dWk6CBp3rF2+fSMC1dtygFSL eD8ubPggAFnCfqkmyBv4I1nHlS0/cABXMsvGlz1//mWgeXPBpBZFc0R7MCKAkJ0/z3QQOvJo AAJcv8Zd9SCDsLQHHridW/jJ2AeAYz79lEHwh2BZHpfYVPXwpQ6MH4DZQG9U6t2tWheQ98BP vQO8n6/ZYLbLxSKTc7zNYKvXKtStZ7WNXn9Xw04DzN0vQOIOeA+qAZYbqb+OAKSIMgGrA4yl AA58sMKlfgrKk7Og0+8MC0/66TrjEEwps9na+9AuCRhgscUWU4RRqeJEvM7BGG/EMccbKdCx Rx9/BDJIIYckskgjj0QySSWXZLJJJ3UM5kkpp6SySiuvxDJLLbfkUsk5ugQzTDHHJLNMM89E M00112QTIxrahDNOOecc/o6MJ3GgM0899+SzTz//1BECQEvyZVBDD0U00TDvqIoTRR+FNFKI KpG0UksvxTRNVWLqI1NPPwU1VFFHJbVUU09FNVVVV2W1VUlFcTXWkoSQtVZbb8U1V1135bVX X38FNtjvpGLMoekeCMlFG6ODiC3MCDtWWPsECC+z1gx6YDxkzXuop4d+imgAatGab4C58Go2 gPAAFICsdoGi1ttsw6P2oPkeoHaAwRyT5jxtpUM2pAPkBSBbjYxrNt78BABwPHC3be5eNGOT KESH9kUOrHgpY3A5jaldLl8OP3NggQWYc8+hn0JDtj3u9JVK3ocxmw8sxS7eiuW3yKKwXnxX /q5I3hG7/ZZBHUtGAIHSfDLvugf2ZViqgh+aGiKMba42WxYZpBBjJ50FkUG8WhxMW2THMxoi obeOCNzY5P0MgYEMkAkoBNEtG13rHpaZQbOfXtm6simTF913fx6RRLXVRhdf4yj0UW7UUI4I b3yfPlvnqqsmGqKt2u3JYbH/W1ZJyaGiHKKZ/x6v8ahmjmht2B9u/DXJEZgJw7mi6unAuQ6U z6G+IWJ9PHNb5K5zqi8f7F2HO/N25XZ/Di1tHBeIFz6SeH/auqeN425zieDuqffEjdb5ydM5 WmCk1SkDl9yW4yVM4cXkox9/ASC3fSDcr4JIwZymr5BtLSTDK5rV/uzVExPFTiqZuZzGgEYR b7WLRebxVu2C5AAEEGAgEssIwgi0nPshTHwOjFgEJ8Q21VnvSQdZgAcBAMKKzIxFLTybtmC3 uIeIrm1zSV//APC/lNAIWaw54tlS+B+HMUxbDPsJt6j1kP+07X7ciR5rCHSdxjBQXrx7nAuB JEOSmOVaSqTZA06YMBYt7Fus4c3QdmilvLhPbPkBi7ECwJ05Xq6HLEygwXJzO9gojjLGglZs WLSbRWLmRc15YGcU+UDVMbKRzXpWsyyJpJX4BJPH2o3qJjLJ5lRSkXdLXZMIkqB4nctcXkMY ZhTGMVPOkmKyTCVdCCktihiGhqVqykDI/rTLXS0gaQgwgMLsRxAiRsoByVRmNMdFEAIM03+7 euZ6WEKAXFooCRUKplbKRExc9WaG0qQWNzFiBkN9DJ3TLAjdqFMK6pCTOOKCnMKkwjrvIecv IOvW/qADwcpRC0C82Z+x9Kmwhumzez0UaHPEBZ1A4CaY+fnOQQHaw3uZS42CzByDbBMedY1H XT4b2PSm1B+bAOiWjpwIt7IVsB4ObaY9xJfCiBcdi9EUpgYzG9xKYk+TIAwvwpuIzvbmrYHx 7FztYaB8IOogBvZMZa9L2xwLx7DOIWxfBBpOMKsJkRxcqIp+/At38DIXAfIRbTzkTSAl+pZu DmmV25uPDa0H/gB2CdKoPePhR2PXNguyDCgqm8tfQ8K5oV4zJoXDIEXmA5y4PoAFECRoJjM4 H9vIVDED9dtbfzgReQ2GswZ8mteEc1GusHAxHHJaiD4KvpDCNXrAaw2KqnTXsowQjb9VG1QF WTikKo+xcPOabYzTE3ARV7AnIWpJ4FawkxpNW+aJa3OLI8vpqUtdiMUXtIAyGBu266Rk0epc n0ig9oBHtxYdiFCn4ja03cukiJttiFYm0m9Fz4kHJZBqm7SAD5KEvNjtmPVswz3jOMAVNQ3J ScMTwPENlngrOx5wGqatX4okuiQp3Od6CTxkmW+LmW0uzS4WxuaQhUAoFi0OK7wt/tpuFlkp XG1cMNrbTD7XePvN71o1bFu5ImufYozRM9+pzMi0TyR4Gdd2i0w0AoUOOHkdGFoJNmO6Xrh1 TGzcT0KXkg+PBKzWQqtE9NXf2kXleLKNXlTulbwS/q41ttlhem+2s8L2rkXy9Uw4s+KTp0Ls j8EDlwCTVcUSove2LToI8PiXG0nAJisBcLJIzDaiucgBuJ2bMMJUGld5bdnC3+KWzXRYxVEz t0RLK6JNS/fT2LwUQTX61oXh90CbWqfBP23Wslojtq392tcjsyhSlA22J6M3lt86yLkEZuRv DfvZtzy2Dm36Iw4e09vfTtrJTHK15hn0Y35rDnNbI66EQ97U3UJNaX5CtC8S/YvdUOOlpKyR b35jygWPGka/cxQHgRfc4Ilaw8HH5AGqIEPhD4d4xN1iC0ARQ+IXx3jGNW6hgAAAOw== --------------FC9706B8.1EFB1E6B-- Received: from -1223782488 ([210.127.210.228]) by nic.merit.edu (8.9.3/8.9.1) with SMTP id DAA24864 for ; Sat, 3 Dec 2005 03:01:25 -0500 (EST) Received: from indiya.com (-1224193192 [-1226407560]) by miho-nakayama.com (Qmailv2) with ESMTP id E37DC38D4B for ; Sat, 03 Dec 2005 07:59:42 -0800 Date: Sat, 03 Dec 2005 07:59:42 -0800 From: "Numeracy K. Beiderbecke" X-Mailer: The Bat! (v2.00.8) Personal X-Priority: 3 Message-ID: <9312234549.20051203075942@indiya.com> To: Idr Subject: Microsoft Software and more. The best price. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------6C061D94D33ACA5" X-AntiVirus: skaner antywirusowy poczty Wirtualnej Polski S. A. This is a multi-part message in MIME format. ------------6C061D94D33ACA5 Content-Type: text/plain Content-Transfer-Encoding: 7bit http://yiwzj.2e8a8f8v8i7tbkkz3n2fp222.resalelk.com Borland Software and more. The best price. Check our price-list. Win XP Professional - $69.95 MS Office 2003 Pro (1 CD Edition) - $89.95 MS Office XP Pro - $79.95 Windows 2000 Advanced Server - $69.95 MS Streets and Trips 2004 - $60 Windows 2000 Professional - $59.95 Windows 2000 Advanced Server - $69.95 Windows 2000 Professional - $50 Microsoft Office 2000 PE (2 CD Edition) - $59.95 Windows Millenium - $59.95 MS FileMaker 7.0 Pro - $69.95 Microsoft FileMaker 7.0 Professional - $69.95 MS Office 2003 Professional (1 CD) - $89.95 Microsoft Office XP Pro - $79.95 Borland Delphi 7 Enterprise Edition (2CD) - $60 Look there http://yiwzj.2e8a8f8v8i7tbkkz3n2fp222.resalelk.com ------------6C061D94D33ACA5 Content-Type: text/html Content-Transfer-Encoding: 7bit
Three steps to the software you need for the price you want.
Check our reduced price.
Special Offers:
Bundle Special:Dreamwaver MX 2004 + Flash MX 2004$109.95
Bundle Special:Photoshop + Premiere + Illustrator $129.95
Special Offer:MS Windows XP Professional + MS Office XP Professional$89.95
Bundle Special:Windows XP Professional With SP2 Full Version + Office 2003 Professional (1 CD)$99.95
 
Microsoft|R| Windows|R|
Win 98 SE $49.95
Win 2k Adv. Server $69.95
Win NT 4.0 Server $49.95
Win XP Pro With SP2 Full Version$79.95
Win XP Pro$69.95
Win 98$49.95
Win 95$49.95
Win Millenium $59.95
Win 2k Pro$59.95
 
Microsoft Office|R|:
Office XP Pro$79.95
FileMaker 7.0 Pro$69.95
Office 2003 Pro (1 CD Edition)$89.95
Office 2k Premium Edition (2 CD)$59.95
 
Other Microsoft|c| Software:
MS Money 2004$69.95
MS Plus! XP$59.95
MS Encarta Encyclopedia Delux 2004 (3 CD Edition)$89.95
MS Project 2003 Pro$69.95
MS Exchange 2003 Enterprise Server$69.95
MS Visual Studio .NET Architect Edition (8CD)$139.95
MS Works 7$69.95
MS Picture It Premium 9$59.95
MS SQL Server 2k Enterprise Edition$69.95
MS Streets and Trips 2004 North America (2 CD)$69.95
 
Adobe Software for PC:
Adobe PageMaker 7 (2 CD Edition) $69.95
Adobe Creative Suite Standard (3 CD Edition) $129.95
Adobe InDesign CS PageMaker Edition (2 CD Edition) $69.95
Adobe Premiere 7 $69.95
Adobe Creative Suite Premium (5 CD) $149.95
Adobe Acrobat 6 Pro $79.95
Adobe Photoshop CS with ImageReady CS $99.95
Adobe Photoshop 7 $69.95
 
Adobe Software for Mac:
Photoshop CS (Mac)$99.95
Actobat 6.0 Professional (Mac)$79.95
Illustrator CS CE (Mac)$69.95
InDesign CS (Mac)$69.95
After Effects 6.0 (Mac)$69.95
Premiere 6.5 (Mac)$89.95
LiveMotion 2 (Mac)$69.95
 
Macromedia Software for PC:
Macromedia Dreamwaver MX 2004$69.95
Macromedia Fireworks MX 2004$69.95
Macromedia Flash MX 2004$69.95
Macromedia Freehand MX 11$69.95
 
Macromedia Software for Mac:
Director MX 2004 (Apple Macintosh)$69.95
Fireworks MX 2004 (Apple Macintosh)$69.95
Dreamweaver MX 2004 (Apple Macintosh)$69.95
Studio MX 2004 with Director MX 2004 (Apple Macintosh)$139.95
FreeHand MX (Apple Macintosh)$69.95
Flash MX 2004 (Apple Macintosh)$69.95
 
Corel Software:
Corel Draw Graphics Suite 11.0$59.95
Corel Draw Graphics Suite 11.0 (Mac)$59.95
Corel Photo Painter 8.0$59.95
Corel WordPerfect Office $69.95
Corel Photo Painter 8.0 (Mac)$59.95
 

Get to site
------------6C061D94D33ACA5-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA20239 for ; Thu, 1 Dec 2005 09:06:50 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehp5B-0007DM-Mu; Thu, 01 Dec 2005 09:06:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehp5A-0007BL-Qr for idr@megatron.ietf.org; Thu, 01 Dec 2005 09:06:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24244 for ; Thu, 1 Dec 2005 09:05:56 -0500 (EST) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhpPd-0006lj-9X for idr@ietf.org; Thu, 01 Dec 2005 09:27:55 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id 9C86A163BCD; Thu, 1 Dec 2005 14:06:15 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 488JLaogm0263Mo2; Thu, 01 Dec 2005 14:06:13 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 483JLaogL0279Mo2; Thu, 01 Dec 2005 14:06:11 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Thu, 01 Dec 2005 14:06:11 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com gw3.EXCHPROD.USA.NET X-USANET-MsgId: XID973JLaogL8871Xo2 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by gw3.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Dec 2005 07:06:00 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Idr] AS hopcount draft Date: Thu, 1 Dec 2005 07:05:23 -0700 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F02024DC38C@VS4.EXCHPROD.USA.NET> Thread-Topic: [Idr] AS hopcount draft Thread-Index: AcX2f/xnYl9Wwo0SQf+RFQ8VWJBd7QAAENlw From: "Susan Hares" To: , "Tony Li" X-OriginalArrivalTime: 01 Dec 2005 14:06:00.0554 (UTC) FILETIME=[5BC0DCA0:01C5F680] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id JAA20239 Thanks for the note. sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Eric W Gray Sent: Thursday, December 01, 2005 9:02 AM To: Tony Li Cc: idr@ietf.org Subject: Re: [Idr] AS hopcount draft Yes, this should be a WG draft. Tony Li wrote: > > Hi all, > > On the AS hopcount draft, we're in the middle of polling interest on > having this > draft as a WG item. This expires on Monday. If you have an opinion, > please voice > it now to the list. > > Here's my summary of where we are, with both people and their > affiliations. If > any of these need correction, please unicast to me. > > Authors: > Myself (SP) > Rex Fernando (Vendor emeritus) > Joe Abley (SP) > > For: > Curtis Villamizar (Vendor?) > Paul Jakma (SP?) > Elmar Bins (SP?) > Robert Raszuk (Vendor) > Enke Chen (Vendor) > Kanchei Loa (SP/End user) > Geoff Huston (SP) > Danny McPherson (Vendor) > > Against: > Pekka Savola (Vendor) > > > Tony > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA20189 for ; Thu, 1 Dec 2005 09:02:14 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehp0b-0000Ly-Hc; Thu, 01 Dec 2005 09:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehp0a-0000L6-9b for idr@megatron.ietf.org; Thu, 01 Dec 2005 09:02:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23603 for ; Thu, 1 Dec 2005 09:01:12 -0500 (EST) Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhpL0-0006YS-KY for idr@ietf.org; Thu, 01 Dec 2005 09:23:11 -0500 Received: from ewgray2k@netscape.net by imo-d02.mx.aol.com (mail_out_v38_r6.3.) id i.19.1362dbd9 (22681); Thu, 1 Dec 2005 09:01:36 -0500 (EST) Received: from [192.168.3.101] (c-24-128-207-21.hsd1.nh.comcast.net [24.128.207.21]) by air-in04.mx.aol.com (v107.13) with ESMTP id MAILININ42-5899438f02401b7; Thu, 01 Dec 2005 09:01:36 -0500 Message-ID: <438F023A.8010602@netscape.net> Date: Thu, 01 Dec 2005 09:01:30 -0500 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 Subject: Re: [Idr] AS hopcount draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 24.128.207.21 X-Mailer: Unknown (No Version) X-Spam-Flag: NO X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ewgray@GraIyMage.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Yes, this should be a WG draft. Tony Li wrote: > > Hi all, > > On the AS hopcount draft, we're in the middle of polling interest on > having this > draft as a WG item. This expires on Monday. If you have an opinion, > please voice > it now to the list. > > Here's my summary of where we are, with both people and their > affiliations. If > any of these need correction, please unicast to me. > > Authors: > Myself (SP) > Rex Fernando (Vendor emeritus) > Joe Abley (SP) > > For: > Curtis Villamizar (Vendor?) > Paul Jakma (SP?) > Elmar Bins (SP?) > Robert Raszuk (Vendor) > Enke Chen (Vendor) > Kanchei Loa (SP/End user) > Geoff Huston (SP) > Danny McPherson (Vendor) > > Against: > Pekka Savola (Vendor) > > > Tony > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA13043 for ; Thu, 1 Dec 2005 01:39:00 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehi3p-00030M-Re; Thu, 01 Dec 2005 01:36:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehi3o-00030F-CV for idr@megatron.ietf.org; Thu, 01 Dec 2005 01:36:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26677 for ; Thu, 1 Dec 2005 01:36:05 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhiOB-0000p9-Qt for idr@ietf.org; Thu, 01 Dec 2005 01:57:59 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2005120106363301200arhoue>; Thu, 1 Dec 2005 06:36:39 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] AS hopcount draft Date: Wed, 30 Nov 2005 22:36:31 -0800 To: Pekka Savola X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > On Wed, 30 Nov 2005, Tony Li wrote: >> Against: >> Pekka Savola (Vendor) > > For the record, I represent a service provider :) Corrected, thanks. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA12160 for ; Thu, 1 Dec 2005 00:45:01 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhhEg-0005lv-2S; Thu, 01 Dec 2005 00:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhhEd-0005lq-7Y for idr@megatron.ietf.org; Thu, 01 Dec 2005 00:44:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21944 for ; Thu, 1 Dec 2005 00:43:12 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhhZ2-0007es-G5 for idr@ietf.org; Thu, 01 Dec 2005 01:05:05 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jB15hVQ29688; Thu, 1 Dec 2005 07:43:32 +0200 Date: Thu, 1 Dec 2005 07:43:31 +0200 (EET) From: Pekka Savola To: Tony Li Subject: Re: [Idr] AS hopcount draft In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Wed, 30 Nov 2005, Tony Li wrote: > Against: > Pekka Savola (Vendor) For the record, I represent a service provider :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr