From idr-bounces@ietf.org Sun Aug 05 13:47:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHkBn-0008Gh-Ti; Sun, 05 Aug 2007 13:46:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHkBn-0008Gc-1G for idr@ietf.org; Sun, 05 Aug 2007 13:46:51 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHkBm-00070S-EY for idr@ietf.org; Sun, 05 Aug 2007 13:46:50 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 05 Aug 2007 10:46:46 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l75HkfO23112; Sun, 5 Aug 2007 10:46:45 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200708051746.l75HkfO23112@merlot.juniper.net> To: idr@ietf.org Subject: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18185.1186336001.1@juniper.net> Date: Sun, 05 Aug 2007 10:46:41 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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: , Errors-To: idr-bounces@ietf.org Folks, Please keep in mind that silence counts as a lack of interest, not as a sign of support. Yakov. ------- Forwarded Message Date: Fri, 27 Jul 2007 08:01:14 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document Folks, IDR WG chairs received a request to accept draft-marques-idr-flow-spec-04.txt as an IDR WG document (see attached). Comments are greatly appreciated. The deadline for comments is August 10, 2007. Yakov. - ------- Forwarded Message Date: Thu, 26 Jul 2007 12:33:27 -0600 From: Danny McPherson To: Hares Susan , Yakov Rekhter cc: Pedro Roque Marques , raszuk@juniper.net Subject: Fwd: I-D ACTION:draft-marques-idr-flow-spec-04.txt Susan/Yakov, As discussed in the meeting today, could you please ask the WG about this becoming a WG item? - - -danny Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: July 8, 2007 4:15:02 PM MDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-marques-idr-flow-spec-04.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Dissemination of flow specification rules > Author(s) : P. Marques, et al. > Filename : draft-marques-idr-flow-spec-04.txt > Pages : 25 > Date : 2007-7-8 > > This document defines a new BGP NLRI encoding format that can be used > to distribute traffic flow specifications. This allows the routing > system to propagate information regarding more-specific > components of > the traffic aggregate defined by an IP destination prefix. > > Additionally it defines two applications of that encoding format. > One that can be used to automate inter-domain coordination of > traffic > filtering, such as what is required in order to mitigate > (distributed) denial of service attacks. And a second > application to > traffic filtering in the context of a BGP/MPLS VPN service. > > The information is carried via the Border Gateway Protocol (BGP), > thereby reusing protocol algorithms, operational experience and > administrative processes such as inter-provider peering agreements. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-marques-idr-flow-spec-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-marques-idr-flow-spec-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-marques-idr-flow-spec-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. > Content-Type: text/plain > Content-ID: <2007-7-8172242.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce - ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 06 21:53:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIEFZ-0005LE-Gz; Mon, 06 Aug 2007 21:52:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIEFY-0005L2-4Y for idr@ietf.org; Mon, 06 Aug 2007 21:52:44 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIEFW-0000Nq-U1 for idr@ietf.org; Mon, 06 Aug 2007 21:52:44 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 06 Aug 2007 18:52:42 -0700 Received: from [172.23.10.157] ([172.23.10.157]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l771qfO31034; Mon, 6 Aug 2007 18:52:41 -0700 (PDT) (envelope-from raszuk@juniper.net) Message-ID: <46B7D069.3060105@juniper.net> Date: Tue, 07 Aug 2007 03:52:41 +0200 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document References: <200707271501.l6RF1EO05626@merlot.juniper.net> In-Reply-To: <200707271501.l6RF1EO05626@merlot.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@juniper.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Yakov, I support this to be an IDR WG document. Thx, R. > Folks, > > IDR WG chairs received a request to accept > draft-marques-idr-flow-spec-04.txt > as an IDR WG document (see attached). > > Comments are greatly appreciated. The deadline for comments is > August 10, 2007. > > Yakov. > ------- Forwarded Message > > Date: Thu, 26 Jul 2007 12:33:27 -0600 > From: Danny McPherson > To: Hares Susan , Yakov Rekhter > cc: Pedro Roque Marques , raszuk@juniper.net > Subject: Fwd: I-D ACTION:draft-marques-idr-flow-spec-04.txt > > Susan/Yakov, > As discussed in the meeting today, could you please ask > the WG about this becoming a WG item? > > - -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 06 22:48:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIF7l-0001wf-MG; Mon, 06 Aug 2007 22:48:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIF7k-0001uj-Ch for idr@ietf.org; Mon, 06 Aug 2007 22:48:44 -0400 Received: from dog.tcb.net ([64.78.150.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIF7k-0004X6-5R for idr@ietf.org; Mon, 06 Aug 2007 22:48:44 -0400 Received: by dog.tcb.net (Postfix, from userid 0) id 7564C268096; Mon, 6 Aug 2007 20:48:43 -0600 (MDT) Received: from [192.168.1.7] (VDSL-151-118-145-60.DNVR.QWEST.NET [151.118.145.60]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for idr@ietf.org; Mon, 06 Aug 2007 20:48:43 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=151.118.145.60; client-port=52769; syn-fingerprint=65535:56:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <46B7D069.3060105@juniper.net> References: <200707271501.l6RF1EO05626@merlot.juniper.net> <46B7D069.3060105@juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <690A4BFE-D351-453A-86AF-CD3E38FFC7CE@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document Date: Mon, 6 Aug 2007 20:48:06 -0600 To: idr List Routing X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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: , Errors-To: idr-bounces@ietf.org On Aug 6, 2007, at 7:52 PM, Robert Raszuk wrote: > Yakov, > > I support this to be an IDR WG document. ++me, obviously.. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 07 09:32:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIP9b-0006Wr-7g; Tue, 07 Aug 2007 09:31:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIP9Y-0006Vw-TJ for idr@ietf.org; Tue, 07 Aug 2007 09:31:16 -0400 Received: from alles.doetraar.nl ([194.109.30.250]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIP9Y-00067W-Hc for idr@ietf.org; Tue, 07 Aug 2007 09:31:16 -0400 Received: from localhost (localhost [127.0.0.1]) by alles.doetraar.nl (Postfix) with ESMTP id 4EECA4F51948; Tue, 7 Aug 2007 15:31:15 +0200 (CEST) X-Virus-Scanned: by amavisd-new at doetraar.nl Received: from alles.doetraar.nl ([127.0.0.1]) by localhost (alles.doetraar.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeZCwL+oC7QF; Tue, 7 Aug 2007 15:31:14 +0200 (CEST) Received: from [62.216.3.69] (zij.doetraar.nl [62.216.3.69]) by alles.doetraar.nl (Postfix) with ESMTP id E06AA4F5193C; Tue, 7 Aug 2007 15:31:13 +0200 (CEST) To: idr@ietf.org In-Reply-To: <2BFCDDCB-DD7A-4DDA-8EE2-93B25A986BE7@tcb.net> References: <200707271501.l6RF1EO05626@merlot.juniper.net> <2BFCDDCB-DD7A-4DDA-8EE2-93B25A986BE7@tcb.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed X-Scientology: Cult Message-Id: Content-Transfer-Encoding: 7bit From: Scott A.McIntyre Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document X-Hd-Dvd: 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 Date: Tue, 7 Aug 2007 15:31:12 +0200 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: yakov@juniper.net 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: , Errors-To: idr-bounces@ietf.org Hey all, > From: Yakov Rekhter > Date: July 27, 2007 9:01:14 AM MDT > To: idr@ietf.org > Subject: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG > document > > Folks, > > IDR WG chairs received a request to accept draft-marques-idr-flow- > spec-04.txt > as an IDR WG document (see attached). > > Comments are greatly appreciated. The deadline for comments is > August 10, 2007. Great to see this moving forward, consider this note a positive comment in support of accepting it. Can't wait to see flow-spec more widely deployed... Regards, Scott A. McIntyre Security Officer KPN-CERT > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 07 09:46:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPN4-0006Mj-3j; Tue, 07 Aug 2007 09:45:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPN2-0006Mb-Lh for idr@ietf.org; Tue, 07 Aug 2007 09:45:12 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIPN1-0001yb-CQ for idr@ietf.org; Tue, 07 Aug 2007 09:45:12 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l77DjAdG004870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Aug 2007 06:45:10 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l77DjAPu012669; Tue, 7 Aug 2007 06:45:10 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (xch-swbh-04.sw.nos.boeing.com [192.79.11.25]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l77Dj9Zb012642; Tue, 7 Aug 2007 06:45:10 -0700 (PDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 06:45:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] draft-marques-idr-flow-spec-04.txt as an IDR WG document Date: Tue, 7 Aug 2007 06:45:09 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2E711@XCH-SW-42.sw.nos.boeing.com> In-Reply-To: <46B7D069.3060105@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document Thread-Index: AcfYlbn732Hs2BygSkS8ntweEEJqzAAY2qrg References: <200707271501.l6RF1EO05626@merlot.juniper.net> <46B7D069.3060105@juniper.net> From: "Drake, John E" To: , "Yakov Rekhter" X-OriginalArrivalTime: 07 Aug 2007 13:45:09.0536 (UTC) FILETIME=[2BB92A00:01C7D8F9] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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: , Errors-To: idr-bounces@ietf.org As do I=20 > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@juniper.net]=20 > Sent: Monday, August 06, 2007 6:53 PM > To: Yakov Rekhter > Cc: idr@ietf.org > Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an=20 > IDR WG document >=20 > Yakov, >=20 > I support this to be an IDR WG document. >=20 > Thx, > R. >=20 >=20 > > Folks, > >=20 > > IDR WG chairs received a request to accept=20 > > draft-marques-idr-flow-spec-04.txt > > as an IDR WG document (see attached). > >=20 > > Comments are greatly appreciated. The deadline for comments=20 > is August=20 > > 10, 2007. > >=20 > > Yakov. > > ------- Forwarded Message > >=20 > > Date: Thu, 26 Jul 2007 12:33:27 -0600 > > From: Danny McPherson > > To: Hares Susan , Yakov Rekhter=20 > > > cc: Pedro Roque Marques , raszuk@juniper.net > > Subject: Fwd: I-D ACTION:draft-marques-idr-flow-spec-04.txt > >=20 > > Susan/Yakov, > > As discussed in the meeting today, could you please ask the=20 > WG about=20 > > this becoming a WG item? > >=20 > > - -danny >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr >=20 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 07 10:03:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPdv-0001Ef-Qi; Tue, 07 Aug 2007 10:02:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIPdu-0001Ea-Mp for idr@ietf.org; Tue, 07 Aug 2007 10:02:38 -0400 Received: from dog.tcb.net ([64.78.150.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIPdt-0007Jf-SZ for idr@ietf.org; Tue, 07 Aug 2007 10:02:38 -0400 Received: by dog.tcb.net (Postfix, from userid 0) id 67DF5268096; Tue, 7 Aug 2007 08:02:37 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; Tue, 07 Aug 2007 08:02:37 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=47966; data-bytes=0 Message-ID: <46B87B7C.9080308@castlepoint.net> Date: Tue, 07 Aug 2007 08:02:36 -0600 From: Shane Amante User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document References: <200707271501.l6RF1EO05626@merlot.juniper.net> In-Reply-To: <200707271501.l6RF1EO05626@merlot.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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: , Errors-To: idr-bounces@ietf.org Yakov Rekhter wrote: > Folks, > > IDR WG chairs received a request to accept draft-marques-idr-flow-spec-04.txt > as an IDR WG document (see attached). Support. -shane > Comments are greatly appreciated. The deadline for comments is > August 10, 2007. > > Yakov. > ------- Forwarded Message > > Date: Thu, 26 Jul 2007 12:33:27 -0600 > From: Danny McPherson > To: Hares Susan , Yakov Rekhter > cc: Pedro Roque Marques , raszuk@juniper.net > Subject: Fwd: I-D ACTION:draft-marques-idr-flow-spec-04.txt > > Susan/Yakov, > As discussed in the meeting today, could you please ask > the WG about this becoming a WG item? > > - -danny > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: July 8, 2007 4:15:02 PM MDT >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-marques-idr-flow-spec-04.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Dissemination of flow specification rules >> Author(s) : P. Marques, et al. >> Filename : draft-marques-idr-flow-spec-04.txt >> Pages : 25 >> Date : 2007-7-8 >> >> This document defines a new BGP NLRI encoding format that can be used >> to distribute traffic flow specifications. This allows the routing >> system to propagate information regarding more-specific >> components of >> the traffic aggregate defined by an IP destination prefix. >> >> Additionally it defines two applications of that encoding format. >> One that can be used to automate inter-domain coordination of >> traffic >> filtering, such as what is required in order to mitigate >> (distributed) denial of service attacks. And a second >> application to >> traffic filtering in the context of a BGP/MPLS VPN service. >> >> The information is carried via the Border Gateway Protocol (BGP), >> thereby reusing protocol algorithms, operational experience and >> administrative processes such as inter-provider peering agreements. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-marques-idr-flow-spec-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-marques-idr-flow-spec-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-marques-idr-flow-spec-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. >> Content-Type: text/plain >> Content-ID: <2007-7-8172242.I-D@ietf.org> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > > ------- End of Forwarded Message > > _______________________________________________ > 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 Aug 07 13:47:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIT7K-0003S8-Tu; Tue, 07 Aug 2007 13:45:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIT7H-0003RT-5n for idr@ietf.org; Tue, 07 Aug 2007 13:45:11 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIT7G-0001rR-Qt for idr@ietf.org; Tue, 07 Aug 2007 13:45:11 -0400 Received: from yxu1a17.hopcount.ca ([199.212.90.17]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IIT9g-000Mev-OT; Tue, 07 Aug 2007 17:47:41 +0000 In-Reply-To: <200707271501.l6RF1EO05626@merlot.juniper.net> References: <200707271501.l6RF1EO05626@merlot.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document Date: Tue, 7 Aug 2007 13:44:45 -0400 To: Yakov Rekhter X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: idr-bounces@ietf.org On 27-Jul-2007, at 11:01, Yakov Rekhter wrote: > IDR WG chairs received a request to accept draft-marques-idr-flow- > spec-04.txt > as an IDR WG document (see attached). > > Comments are greatly appreciated. The deadline for comments is > August 10, 2007. I support this draft being adopted as a working group document. Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 07 20:39:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIZXH-0007uH-QF; Tue, 07 Aug 2007 20:36:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIZXG-0007tn-Rv; Tue, 07 Aug 2007 20:36:26 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIZXG-0005Uc-Ck; Tue, 07 Aug 2007 20:36:26 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id BDACFDF448; Tue, 7 Aug 2007 17:36:04 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070808003604.BDACFDF448@bosco.isi.edu> Date: Tue, 7 Aug 2007 17:36:04 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] RFC 5065 on Autonomous System Confederations for BGP 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: , Errors-To: idr-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5065 Title: Autonomous System Confederations for BGP Author: P. Traina, D. McPherson, J. Scudder Status: Standards Track Date: August 2007 Mailbox: bgp-confederations@st04.pst.org, danny@arbor.net, jgs@juniper.net Pages: 14 Characters: 28732 Obsoletes: RFC3065 See-Also: I-D Tag: draft-ietf-idr-rfc3065bis-06.txt URL: http://www.rfc-editor.org/rfc/rfc5065.txt The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals. This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. This document obsoletes RFC 3065. [STANDARDSD TRACK] This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Draft Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 09 06:23:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ580-0001fg-1G; Thu, 09 Aug 2007 06:20:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ57v-0001fN-Uq for idr@ietf.org; Thu, 09 Aug 2007 06:20:25 -0400 Received: from boromix.nask.net.pl ([195.187.245.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ57u-0006aa-91 for idr@ietf.org; Thu, 09 Aug 2007 06:20:23 -0400 Received: from boromir.nask.net.pl (boromir [195.187.245.66]) by boromix.nask.net.pl with ESMTP id l79AKHJv019294; Thu, 9 Aug 2007 12:20:17 +0200 Received: from [127.0.0.1] (lossoth.nask.waw.pl [195.187.243.221]) by boromir.nask.net.pl with ESMTP id l79AKG9n006845; Thu, 9 Aug 2007 12:20:17 +0200 (CEST) Message-ID: <46BAEA6A.3050106@nask.pl> Date: Thu, 09 Aug 2007 12:20:26 +0200 From: Michal Mroczek User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document References: <200707271501.l6RF1EO05626@merlot.juniper.net> In-Reply-To: <200707271501.l6RF1EO05626@merlot.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (boromix.nask.net.pl: 195.187.245.66 is authenticated by a trusted mechanism) VirusProtection: checked - Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: idr-bounces@ietf.org Yakov Rekhter pisze: > Folks, > > IDR WG chairs received a request to accept draft-marques-idr-flow-spec-04.txt > as an IDR WG document (see attached). > > Comments are greatly appreciated. The deadline for comments is > August 10, 2007. > Support. -- MPM _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Aug 09 10:53:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ9MH-0006zK-OH; Thu, 09 Aug 2007 10:51:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ9MG-0006yZ-2c for idr@ietf.org; Thu, 09 Aug 2007 10:51:28 -0400 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ9ME-0003Wc-Op for idr@ietf.org; Thu, 09 Aug 2007 10:51:28 -0400 Received: by mailhost.jlc.net (Postfix, from userid 104) id A08C223F0CA; Thu, 9 Aug 2007 10:51:26 -0400 (EDT) Date: Thu, 9 Aug 2007 10:51:26 -0400 From: John Leslie To: Yakov Rekhter Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document Message-ID: <20070809145126.GC67748@verdi> References: <200707271501.l6RF1EO05626@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707271501.l6RF1EO05626@merlot.juniper.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: idr-bounces@ietf.org Yakov Rekhter wrote: > > IDR WG chairs received a request to accept draft-marques-idr-flow-spec-04.txt > as an IDR WG document (see attached). > > Comments are greatly appreciated. The deadline for comments is > August 10, 2007. I support adding this as a WG item. It would be highly useful to have an automated way to report, "I am dropping packets like this: please log them instead of sending them to me." == John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 10 14:20:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZ4Q-00029o-Nb; Fri, 10 Aug 2007 14:18:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZ4P-00029j-T3 for idr@ietf.org; Fri, 10 Aug 2007 14:18:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJZ4O-000430-F5 for idr@ietf.org; Fri, 10 Aug 2007 14:18:45 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 10 Aug 2007 11:18:44 -0700 X-IronPort-AV: i="4.19,245,1183359600"; d="scan'208"; a="170446996:sNHT53055900" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7AIIhAH023808; Fri, 10 Aug 2007 11:18:43 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7AIIZFE029314; Fri, 10 Aug 2007 18:18:43 GMT Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 11:18:42 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 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] draft-marques-idr-flow-spec-04.txt as an IDR WG document Date: Fri, 10 Aug 2007 11:18:41 -0700 Message-ID: In-Reply-To: <200707271501.l6RF1EO05626@merlot.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document Thread-Index: AcfQXyk+DvW2tG1uTnieC94phgK3KQLFt8AQ References: <200707271501.l6RF1EO05626@merlot.juniper.net> From: "Martin Djernaes \(djernaes\)" To: "Yakov Rekhter" , X-OriginalArrivalTime: 10 Aug 2007 18:18:42.0554 (UTC) FILETIME=[E1E235A0:01C7DB7A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5310; t=1186769924; x=1187633924; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=djernaes@cisco.com; z=From:=20=22Martin=20Djernaes=20\(djernaes\)=22=20 |Subject:=20RE=3A=20[Idr]=20draft-marques-idr-flow-spec-04.txt=20as=20an= 20IDR=20WG=20document |Sender:=20; bh=0s4A073GKe6n/twjIuzV7B5rrBVWNz6wA3b/WkdfT+s=; b=zAbKYdHw8XIymejX3UDykSu1QbCUjgUUxEQhY+39aDZDjUg2dQz0JtCuT+V2cjfsiZPWHLmj fZ39UDqwlCbcSxx9bihL6nRkxj/b7FPh0p8MtqpYCbe2m74AbeWgyrxq; Authentication-Results: sj-dkim-2; header.From=djernaes@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: 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: , Errors-To: idr-bounces@ietf.org Hi, I think that the problem space presented in the FlowSpec draft is a very interesting, and very important, problem, but I do not think that the FlowSpec draft does enough to resolve the problem and leaves enough issues behind that it at best could be seen a stop gap measure for a more comprehensive solution. Instead of having FlowSpec becoming a working group document I would suggest that the problem is taken up separately, possibly in the security area, to ensure that a solution resolve the majority of the needs in such networks. Therefore I can not support this as a WG document. Martin > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net]=20 > Sent: Friday, July 27, 2007 8:01 AM > To: idr@ietf.org > Subject: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR=20 > WG document >=20 > Folks, >=20 > IDR WG chairs received a request to accept=20 > draft-marques-idr-flow-spec-04.txt=20 > as an IDR WG document (see attached). >=20 > Comments are greatly appreciated. The deadline for comments is > August 10, 2007. >=20 > Yakov. > ------- Forwarded Message >=20 > Date: Thu, 26 Jul 2007 12:33:27 -0600 > From: Danny McPherson > To: Hares Susan , Yakov Rekhter=20 > > cc: Pedro Roque Marques , raszuk@juniper.net > Subject: Fwd: I-D ACTION:draft-marques-idr-flow-spec-04.txt=20 >=20 > Susan/Yakov, > As discussed in the meeting today, could you please ask > the WG about this becoming a WG item? >=20 > - -danny >=20 > Begin forwarded message: >=20 > > From: Internet-Drafts@ietf.org > > Date: July 8, 2007 4:15:02 PM MDT > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-marques-idr-flow-spec-04.txt > > Reply-To: internet-drafts@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Dissemination of flow specification rules > > Author(s) : P. Marques, et al. > > Filename : draft-marques-idr-flow-spec-04.txt > > Pages : 25 > > Date : 2007-7-8 > > =09 > > This document defines a new BGP NLRI encoding format that=20 > can be used > > to distribute traffic flow specifications. This allows=20 > the routing > > system to propagate information regarding more-specific =20 > > components of > > the traffic aggregate defined by an IP destination prefix. > > > > Additionally it defines two applications of that encoding format. > > One that can be used to automate inter-domain coordination of =20 > > traffic > > filtering, such as what is required in order to mitigate > > (distributed) denial of service attacks. And a second =20 > > application to > > traffic filtering in the context of a BGP/MPLS VPN service. > > > > The information is carried via the Border Gateway Protocol (BGP), > > thereby reusing protocol algorithms, operational experience and > > administrative processes such as inter-provider peering=20 > agreements. > > > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-marques-idr-flow-spec-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=20 > the body of > > the message. > > You can also visit=20 > 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-marques-idr-flow-spec-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-marques-idr-flow-spec-04.txt". > > =09 > > 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=20 > 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. > > Content-Type: text/plain > > Content-ID: <2007-7-8172242.I-D@ietf.org> > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce >=20 > ------- End of Forwarded Message >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr >=20 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 10 15:18:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZyr-0006M2-92; Fri, 10 Aug 2007 15:17:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZyq-0006Lj-OC for idr@ietf.org; Fri, 10 Aug 2007 15:17:04 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJZyp-0003bh-TO for idr@ietf.org; Fri, 10 Aug 2007 15:17:04 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2007 12:17:04 -0700 X-IronPort-AV: i="4.19,245,1183359600"; d="scan'208"; a="512449435:sNHT55711194" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7AJH3Vt002642; Fri, 10 Aug 2007 12:17:03 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7AJH3Vp022591; Fri, 10 Aug 2007 19:17:03 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA05525; Fri, 10 Aug 2007 12:16:01 -0700 (PDT) Date: Fri, 10 Aug 2007 12:16:01 -0700 From: Chandrashekhar Appanna To: Yakov Rekhter Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document Message-ID: <20070810191601.GD19275@cisco.com> References: <200707271501.l6RF1EO05626@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707271501.l6RF1EO05626@merlot.juniper.net> User-Agent: Mutt/1.4i DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5811; t=1186773423; x=1187637423; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20 |Subject:=20Re=3A=20[Idr]=20draft-marques-idr-flow-spec-04.txt=20as=20an= 20IDR=20WG=20document |Sender:=20; bh=nyfY2pBkqNUzRGLJkAWpWS9s4LZL2DnoipnqYxYco1Y=; b=BVDg0ZNY2T7+avVWL93ChuaeXLCyxcdfNbVDPPftCbOXlKBgkoFyct8AS4PudOs0iqQRXN3g k1P8WfzJiJHeNvSzvZM3f3IrXifFPCaXS2yHxpgNJrSvGGPvnoYAgOGb1NEo11z6WhqIfSUu6Z iAyDGzG6w5OPNfrPi2ed6f38I=; Authentication-Results: sj-dkim-1; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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: , Errors-To: idr-bounces@ietf.org Hi, The document says : "Additionally it defines two applications of that encoding format. One that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial of service attacks. And a second application to traffic filtering in the context of a BGP/MPLS VPN service." I believe that for the most part the solution for threat detection, propogation and then mitigation requires a framework of which BGP may be a part. However, we should consider whether BGP is the transport for the propagation once we have figured out the framework and the requirements. Would IDR be the group for that? I do not think so. I think that there are quite a few interesting discussion points raised by the draft and they all are related to the application that is using BGP as a transport. Is BGP going to be extensible as a framwork? Is BGP going to be the transport of choice? Does the distribution network for information propagation for these applications mirror a BGP routing information distribution network? In summary, at this point I do not feel that this should become an IDR WG document. We should perhaps find a suitable home for these discussions and then if we still choose to use BGP we can bring the BGP changes to IDR. 0.02, Chandra. On Fri, Jul 27, 2007 at 08:01:14AM -0700, Yakov Rekhter wrote: > Folks, > > IDR WG chairs received a request to accept draft-marques-idr-flow-spec-04.txt > as an IDR WG document (see attached). > > Comments are greatly appreciated. The deadline for comments is > August 10, 2007. > > Yakov. > ------- Forwarded Message > > Date: Thu, 26 Jul 2007 12:33:27 -0600 > From: Danny McPherson > To: Hares Susan , Yakov Rekhter > cc: Pedro Roque Marques , raszuk@juniper.net > Subject: Fwd: I-D ACTION:draft-marques-idr-flow-spec-04.txt > > Susan/Yakov, > As discussed in the meeting today, could you please ask > the WG about this becoming a WG item? > > - -danny > > Begin forwarded message: > > > From: Internet-Drafts@ietf.org > > Date: July 8, 2007 4:15:02 PM MDT > > To: i-d-announce@ietf.org > > Subject: I-D ACTION:draft-marques-idr-flow-spec-04.txt > > Reply-To: internet-drafts@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Dissemination of flow specification rules > > Author(s) : P. Marques, et al. > > Filename : draft-marques-idr-flow-spec-04.txt > > Pages : 25 > > Date : 2007-7-8 > > > > This document defines a new BGP NLRI encoding format that can be used > > to distribute traffic flow specifications. This allows the routing > > system to propagate information regarding more-specific > > components of > > the traffic aggregate defined by an IP destination prefix. > > > > Additionally it defines two applications of that encoding format. > > One that can be used to automate inter-domain coordination of > > traffic > > filtering, such as what is required in order to mitigate > > (distributed) denial of service attacks. And a second > > application to > > traffic filtering in the context of a BGP/MPLS VPN service. > > > > The information is carried via the Border Gateway Protocol (BGP), > > thereby reusing protocol algorithms, operational experience and > > administrative processes such as inter-provider peering agreements. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-marques-idr-flow-spec-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-marques-idr-flow-spec-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-marques-idr-flow-spec-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. > > Content-Type: text/plain > > Content-ID: <2007-7-8172242.I-D@ietf.org> > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > ------- End of Forwarded Message > > _______________________________________________ > 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 Fri Aug 10 15:47:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJaQM-0007sx-4I; Fri, 10 Aug 2007 15:45:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJaQK-0007sn-Jw for idr@ietf.org; Fri, 10 Aug 2007 15:45:28 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJaQJ-0005pi-5q for idr@ietf.org; Fri, 10 Aug 2007 15:45:28 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 Aug 2007 12:45:26 -0700 X-IronPort-AV: i="4.19,245,1183359600"; d="scan'208"; a="198077242:sNHT63664020" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7AJjQEv010025; Fri, 10 Aug 2007 12:45:26 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7AJjQiF014291; Fri, 10 Aug 2007 19:45:26 GMT Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 12:45:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] draft-marques-idr-flow-spec-04.txt as an IDR WG document Date: Fri, 10 Aug 2007 12:45:16 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document Thread-Index: AcfQXyk+DvW2tG1uTnieC94phgK3KQLFt8AQAAPgaHA= References: <200707271501.l6RF1EO05626@merlot.juniper.net> From: "Barry Greene \(bgreene\)" To: "Martin Djernaes \(djernaes\)" , "Yakov Rekhter" , X-OriginalArrivalTime: 10 Aug 2007 19:45:26.0480 (UTC) FILETIME=[FFAA4D00:01C7DB86] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7232; t=1186775126; x=1187639126; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bgreene@cisco.com; z=From:=20=22Barry=20Greene=20\(bgreene\)=22=20 |Subject:=20RE=3A=20[Idr]=20draft-marques-idr-flow-spec-04.txt=20as=20an= 20IDR=20WG=20document |Sender:=20; bh=lUEdxVjKW7eKxHKlriU5ukhpFiUMDvcffVRL3am1kO4=; b=jHPuMTzAXro7Hb+ZUppuMjz5P1XaDAe9lYBJ1N5KjDoN8YbsNLO9XGkn2QpPZVyqQlYvNnjQ zLuy1nUFmtS3uLZBFuQicXm7TdNEuJh9RoZTkPhPqz6+EdKfZLDMqXgv; Authentication-Results: sj-dkim-4; header.From=bgreene@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: 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: , Errors-To: idr-bounces@ietf.org =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The operators objectives is to get this draft to Information RFC status. Be that through IDR or through the normal processes.=20 Realities is that Flowspec does work - with an operational understanding that it is not the perfect solution. Operators are not looking for a perfect solution, they are looking for thing that will solve a issue that is causing them pain.=20 Keep in mind that today, the #1 SP Security tool used to hammer the bad guys is BGP + Forwarding to Null 0 (Remote Triggered Black Hole). This is an industry wide practice. So the comfort level of using BGP to trigger security policy is the defacto standard today. IMHO - doing flowspec work in IDR - making sure that all BGP bases are covered (i.e. we need to add 4-byte ASN) is logical. The objective is not standards. The objective is completeness of a partial tool that operators would like to deploy and require of their vendors. Barry =20 > -----Original Message----- > From: Martin Djernaes (djernaes)=20 > Sent: Friday, August 10, 2007 11:19 AM > To: Yakov Rekhter; idr@ietf.org > Subject: RE: [Idr] draft-marques-idr-flow-spec-04.txt as an=20 > IDR WG document >=20 > Hi, >=20 > I think that the problem space presented in the FlowSpec=20 > draft is a very interesting, and very important, problem, but=20 > I do not think that the FlowSpec draft does enough to resolve=20 > the problem and leaves enough issues behind that it at best=20 > could be seen a stop gap measure for a more comprehensive=20 > solution. Instead of having FlowSpec becoming a working group=20 > document I would suggest that the problem is taken up=20 > separately, possibly in the security area, to ensure that a=20 > solution resolve the majority of the needs in such networks.=20 > Therefore I can not support this as a WG document. >=20 > Martin >=20 >=20 > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Friday, July 27, 2007 8:01 AM > > To: idr@ietf.org > > Subject: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG=20 > > document > >=20 > > Folks, > >=20 > > IDR WG chairs received a request to accept=20 > > draft-marques-idr-flow-spec-04.txt > > as an IDR WG document (see attached). > >=20 > > Comments are greatly appreciated. The deadline for comments=20 > is August=20 > > 10, 2007. > >=20 > > Yakov. > > ------- Forwarded Message > >=20 > > Date: Thu, 26 Jul 2007 12:33:27 -0600 > > From: Danny McPherson > > To: Hares Susan , Yakov Rekhter=20 > > > > cc: Pedro Roque Marques , > > raszuk@juniper.net Subject: Fwd: I-D > > ACTION:draft-marques-idr-flow-spec-04.txt > >=20 > > Susan/Yakov, > > As discussed in the meeting today, could you please ask the=20 > WG about=20 > > this becoming a WG item? > >=20 > > - -danny > >=20 > > Begin forwarded message: > >=20 > > > From: Internet-Drafts@ietf.org > > > Date: July 8, 2007 4:15:02 PM MDT > > > To: i-d-announce@ietf.org > > > Subject: I-D ACTION:draft-marques-idr-flow-spec-04.txt > > > Reply-To: internet-drafts@ietf.org > > > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > > directories. > > > > > > > > > Title : Dissemination of flow specification rules > > > Author(s) : P. Marques, et al. > > > Filename : draft-marques-idr-flow-spec-04.txt > > > Pages : 25 > > > Date : 2007-7-8 > > > =09 > > > This document defines a new BGP NLRI encoding format that > > can be used > > > to distribute traffic flow specifications. This allows > > the routing > > > system to propagate information regarding more-specific=20 > > > components of > > > the traffic aggregate defined by an IP destination prefix. > > > > > > Additionally it defines two applications of that=20 > encoding format. > > > One that can be used to automate inter-domain coordination > > > of traffic > > > filtering, such as what is required in order to mitigate > > > (distributed) denial of service attacks. And a second=20 > > > application to > > > traffic filtering in the context of a BGP/MPLS VPN service. > > > > > > The information is carried via the Border Gateway=20 > Protocol (BGP), > > > thereby reusing protocol algorithms, operational experience > > > and=20 > > > administrative processes such as inter-provider peering > > agreements. > > > > > > A URL for this Internet-Draft is: > > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-marques-idr-flow-spec-04.t > xt=20 > > > > > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > > 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.=20 > Login with the=20 > > > username "anonymous" and a password of your e-mail address. > > > After logging in, type "cd internet-drafts" and then "get=20 > > > draft-marques-idr-flow-spec-04.txt". > > > > > > A list of Internet-Drafts directories can be found in=20 > > > http://www.ietf.org/shadow.html or=20 > > > 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-marques-idr-flow-spec-04.txt". > > > =09 > > > 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. > > > Content-Type: text/plain > > > Content-ID: <2007-7-8172242.I-D@ietf.org> > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/i-d-announce > >=20 > > ------- End of Forwarded Message > >=20 > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www1.ietf.org/mailman/listinfo/idr > >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRrzATL/UEA/xivvmEQI+zQCffdINHv+6Hw78PJnLWPj5ltrX4JcAn2eA 8SWJhM9mcKd+75NRPYNyXPtA =3DvOAV -----END PGP SIGNATURE----- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 10 15:53:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJaWk-00034j-AT; Fri, 10 Aug 2007 15:52:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJaWj-0002zH-7s for idr@ietf.org; Fri, 10 Aug 2007 15:52:05 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJaWh-0005y1-8a for idr@ietf.org; Fri, 10 Aug 2007 15:52:04 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 5A2D553E0EA; Fri, 10 Aug 2007 15:52:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id MSGV+0yfpfUl; Fri, 10 Aug 2007 15:51:53 -0400 (EDT) Received: from [172.16.13.200] (dsl093-003-111.det1.dsl.speakeasy.net [66.93.3.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 2539253E072; Fri, 10 Aug 2007 15:51:53 -0400 (EDT) In-Reply-To: <200707271501.l6RF1EO05626@merlot.juniper.net> References: <200707271501.l6RF1EO05626@merlot.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FDD1131-18FF-4950-9663-68241D33817B@bgp.nu> Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document Date: Fri, 10 Aug 2007 15:51:47 -0400 To: Yakov Rekhter X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: idr , John Scudder 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: , Errors-To: idr-bounces@ietf.org I support this. Regarding some of the other points raised, I'll just note that "the perfect is the enemy of the good". --John On Jul 27, 2007, at 11:01 AM, Yakov Rekhter wrote: > Folks, > > IDR WG chairs received a request to accept draft-marques-idr-flow- > spec-04.txt > as an IDR WG document (see attached). > > Comments are greatly appreciated. The deadline for comments is > August 10, 2007. > > Yakov. > ------- Forwarded Message > > Date: Thu, 26 Jul 2007 12:33:27 -0600 > From: Danny McPherson > To: Hares Susan , Yakov Rekhter > > cc: Pedro Roque Marques , raszuk@juniper.net > Subject: Fwd: I-D ACTION:draft-marques-idr-flow-spec-04.txt > > Susan/Yakov, > As discussed in the meeting today, could you please ask > the WG about this becoming a WG item? > > - -danny > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: July 8, 2007 4:15:02 PM MDT >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-marques-idr-flow-spec-04.txt >> Reply-To: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Dissemination of flow specification rules >> Author(s) : P. Marques, et al. >> Filename : draft-marques-idr-flow-spec-04.txt >> Pages : 25 >> Date : 2007-7-8 >> >> This document defines a new BGP NLRI encoding format that can be used >> to distribute traffic flow specifications. This allows the >> routing >> system to propagate information regarding more-specific >> components of >> the traffic aggregate defined by an IP destination prefix. >> >> Additionally it defines two applications of that encoding format. >> One that can be used to automate inter-domain coordination of >> traffic >> filtering, such as what is required in order to mitigate >> (distributed) denial of service attacks. And a second >> application to >> traffic filtering in the context of a BGP/MPLS VPN service. >> >> The information is carried via the Border Gateway Protocol (BGP), >> thereby reusing protocol algorithms, operational experience and >> administrative processes such as inter-provider peering >> agreements. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-marques-idr-flow- >> spec-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-marques-idr-flow-spec-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-marques-idr-flow-spec-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. >> Content-Type: text/plain >> Content-ID: <2007-7-8172242.I-D@ietf.org> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > > ------- End of Forwarded Message > > _______________________________________________ > 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 Fri Aug 10 15:56:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJaZR-0006Ww-P6; Fri, 10 Aug 2007 15:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJaZR-0006Wo-2C for idr@ietf.org; Fri, 10 Aug 2007 15:54:53 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJaZP-00061b-No for idr@ietf.org; Fri, 10 Aug 2007 15:54:52 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 10 Aug 2007 12:54:51 -0700 Received: from [172.23.10.157] ([172.23.10.157]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l7AJsnO02102; Fri, 10 Aug 2007 12:54:49 -0700 (PDT) (envelope-from raszuk@juniper.net) Message-ID: <46BCC284.7070302@juniper.net> Date: Fri, 10 Aug 2007 12:54:44 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Martin Djernaes (djernaes)" Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document References: <200707271501.l6RF1EO05626@merlot.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Yakov Rekhter , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@juniper.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Martin, Can you list those issues which are left by the draft behind ? Thx, R. > Hi, > > I think that the problem space presented in the FlowSpec draft is a very > interesting, and very important, problem, but I do not think that the > FlowSpec draft does enough to resolve the problem and leaves enough > issues behind that it at best could be seen a stop gap measure for a > more comprehensive solution. Instead of having FlowSpec becoming a > working group document I would suggest that the problem is taken up > separately, possibly in the security area, to ensure that a solution > resolve the majority of the needs in such networks. Therefore I can not > support this as a WG document. > > Martin > > > > -----Original Message----- > > From: Yakov Rekhter [mailto:yakov@juniper.net] > > Sent: Friday, July 27, 2007 8:01 AM > > To: idr@ietf.org > > Subject: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR > > WG document > > > > Folks, > > > > IDR WG chairs received a request to accept > > draft-marques-idr-flow-spec-04.txt > > as an IDR WG document (see attached). _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 10 16:05:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJahf-0006zJ-3u; Fri, 10 Aug 2007 16:03:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJahd-0006zD-EJ for idr@ietf.org; Fri, 10 Aug 2007 16:03:21 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJahc-0006Dd-7U for idr@ietf.org; Fri, 10 Aug 2007 16:03:21 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 10 Aug 2007 13:03:20 -0700 Received: from [172.23.10.157] ([172.23.10.157]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l7AK3HO04321; Fri, 10 Aug 2007 13:03:18 -0700 (PDT) (envelope-from raszuk@juniper.net) Message-ID: <46BCC483.2080003@juniper.net> Date: Fri, 10 Aug 2007 13:03:15 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Chandrashekhar Appanna Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document References: <200707271501.l6RF1EO05626@merlot.juniper.net> <20070810191601.GD19275@cisco.com> In-Reply-To: <20070810191601.GD19275@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Yakov Rekhter , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@juniper.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Chandra, I am afraid you have missed the main point about flowspec since you are asking such questions below. We use BGP not just as a transport for it. It is highly integrated with the actual advertisement of customer routes which today travel via BGP. The main objective is to be able to automatically verify if filter for a given prefix comes from the router which advertised such prefix to us in the first place. Then we compare if such filter application would not negatively impact other peers with more specific blocks. I see no practical way to achieve the above goals if the transport of filter for a given destination is not part of the same protocol which distributed the actual route in the first place. So clearly please provide actual facts how such integration and verification is negative and if you consider it positive how could that be achieved by decoupling transport protocols for both. Cheers, R. > Hi, > > The document says : > > > "Additionally it defines two applications of that encoding format. > One that can be used to automate inter-domain coordination of traffic > filtering, such as what is required in order to mitigate > (distributed) denial of service attacks. And a second application to > traffic filtering in the context of a BGP/MPLS VPN service." > > I believe that for the most part the solution for threat detection, > propogation and then mitigation requires a framework of which BGP may > be a part. However, we should consider whether BGP is the transport > for the propagation once we have figured out the framework and the > requirements. Would IDR be the group for that? I do not think so. > > I think that there are quite a few interesting discussion points > raised by the draft and they all are related to the application > that is using BGP as a transport. Is BGP going to be extensible as > a framwork? Is BGP going to be the transport of choice? Does the > distribution network for information propagation for these applications > mirror a BGP routing information distribution network? > > In summary, at this point I do not feel that this should become an > IDR WG document. We should perhaps find a suitable home for these > discussions and then if we still choose to use BGP we can bring the > BGP changes to IDR. > > 0.02, > Chandra. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 10 16:27:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJb2i-0001I2-TS; Fri, 10 Aug 2007 16:25:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJb2h-0001Hx-T0 for idr@ietf.org; Fri, 10 Aug 2007 16:25:07 -0400 Received: from [66.251.193.121] (helo=fl.us.curmudgeon.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJb2g-0006ee-JK for idr@ietf.org; Fri, 10 Aug 2007 16:25:07 -0400 Received: from xen011013.gplhost.com (xen011013.gplhost.com [66.251.193.121]) by fl.us.curmudgeon.net (Postfix) with ESMTP id 616D714C39D; Fri, 10 Aug 2007 20:24:59 +0000 (UCT) Date: Fri, 10 Aug 2007 20:24:59 +0000 (UCT) From: Brad Volz X-X-Sender: bradv@fl.us.curmudgeon.net To: "Barry Greene \\(bgreene\\)" Subject: RE: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document In-Reply-To: Message-ID: References: <200707271501.l6RF1EO05626@merlot.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Yakov Rekhter , "Martin Djernaes \\\(djernaes\\\)" , 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: , Errors-To: idr-bounces@ietf.org As an operator, I agree with Barry Greene's summary below. The only point that I would add is that at least for this operator, support for the flow-spec draft is already a part of our RFPs to vendors; both in terms of network hardware and IP transit. The difference that flow-spec support makes when dealing with a flood from multiple points of network ingress toward a critical service ( ie, one that cannot simply be blackholed ) is amazing. Brad On Fri, 10 Aug 2007, Barry Greene \(bgreene\) wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The operators objectives is to get this draft to Information RFC > status. Be that through IDR or through the normal processes. > > Realities is that Flowspec does work - with an operational > understanding that it is not the perfect solution. Operators are not > looking for a perfect solution, they are looking for thing that will > solve a issue that is causing them pain. > > Keep in mind that today, the #1 SP Security tool used to hammer the > bad guys is BGP + Forwarding to Null 0 (Remote Triggered Black Hole). > This is an industry wide practice. So the comfort level of using BGP > to trigger security policy is the defacto standard today. > > IMHO - doing flowspec work in IDR - making sure that all BGP bases > are covered (i.e. we need to add 4-byte ASN) is logical. The > objective is not standards. The objective is completeness of a > partial tool that operators would like to deploy and require of their > vendors. > > > Barry > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Aug 11 14:23:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJvaL-0004Sr-26; Sat, 11 Aug 2007 14:21:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJvaJ-0004Sl-QO for idr@ietf.org; Sat, 11 Aug 2007 14:21:11 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJvaI-0004zF-UT for idr@ietf.org; Sat, 11 Aug 2007 14:21:11 -0400 Received: from [192.168.0.2] ([82.152.216.166]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l7BIKoos009101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2007 19:21:05 +0100 Date: Sat, 11 Aug 2007 19:20:00 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Yakov Rekhter Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document In-Reply-To: <200708051746.l75HkfO23112@merlot.juniper.net> Message-ID: References: <200708051746.l75HkfO23112@merlot.juniper.net> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (hibernia.jakma.org [212.17.55.49]); Sat, 11 Aug 2007 19:21:07 +0100 (IST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Errors-To: idr-bounces@ietf.org On Sun, 5 Aug 2007, Yakov Rekhter wrote: > Folks, > > Please keep in mind that silence counts as a lack of interest, not > as a sign of support. I'd support this being adopted as an informational document. I think it's well-understood that BGP is /the/ tool for distributing packet filtering information... That said, if it were to be considered as a standard, some serious thought needs to be given to whether it is appropriate to stuff flow-filters into UPDATE: - The rationale that NLRIs are opaque to a point, and that BGP filtering mechanisms are quite agnostic to NLRI composition seems questionable. - There's no conceptual sense to installing flow-specs into a RIB - no selection is made between flows, the NLRIs are not hierarchical; simply put a lot of the language in 4271 no longer applies to flow-specs. (E.g. flow-specs to describe, potentially, IPv6,etc.. flows would use AFI=1???) It might be more natural to use a different message type. Nothing would prevent re-use of attributes and mechanisms specified already for UPDATE. This would allow the authors to design a nice clean, extensible message; optimum re-use, minimum baggage. I think such an approach would be simpler in every conceivable way.. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: You have mail. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Aug 11 14:43:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJvuQ-0005nF-U8; Sat, 11 Aug 2007 14:41:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJvuP-0005n4-2P for idr@ietf.org; Sat, 11 Aug 2007 14:41:57 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJvuO-0003gs-L6 for idr@ietf.org; Sat, 11 Aug 2007 14:41:57 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by smtpa.juniper.net with ESMTP; 11 Aug 2007 11:41:56 -0700 X-IronPort-AV: i="4.19,249,1183359600"; d="scan'208"; a="54864013:sNHT37697888" Received: from [172.24.104.85] ([172.24.104.85]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Aug 2007 11:41:55 -0700 Message-ID: <46BE02F3.4060308@juniper.net> Date: Sat, 11 Aug 2007 11:41:55 -0700 From: "Pedro R. Marques" User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Paul Jakma Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document References: <200708051746.l75HkfO23112@merlot.juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Aug 2007 18:41:55.0880 (UTC) FILETIME=[4AC8A280:01C7DC47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: idr-bounces@ietf.org Paul Jakma wrote: > On Sun, 5 Aug 2007, Yakov Rekhter wrote: > > > - There's no conceptual sense to installing flow-specs into a RIB - > no selection is made between flows, Section 5 of the document states otherwise: Flow specifications received from a BGP peer and which are accepted in the respective Adj-RIB-In are used as input to the route selection process. Although the forwarding attributes of two routes for the same Flow Specification prefix may be the same, BGP is still required to perform its path selection algorithm in order to select the correct set of attributes to advertise. Do you believe that the text is not clear enough in this respect ? Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Aug 11 15:38:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJwkw-0008NW-Px; Sat, 11 Aug 2007 15:36:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJwkv-0008NQ-Jq for idr@ietf.org; Sat, 11 Aug 2007 15:36:13 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJwkv-0004nK-2C for idr@ietf.org; Sat, 11 Aug 2007 15:36:13 -0400 Received: from [192.168.0.2] ([82.152.216.166]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l7BJa41V010135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2007 20:36:10 +0100 Date: Sat, 11 Aug 2007 20:35:03 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: "Pedro R. Marques" Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document In-Reply-To: <46BE02F3.4060308@juniper.net> Message-ID: References: <200708051746.l75HkfO23112@merlot.juniper.net> <46BE02F3.4060308@juniper.net> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (hibernia.jakma.org [212.17.55.49]); Sat, 11 Aug 2007 20:36:11 +0100 (IST) X-Spam-Score: -1.4 (-) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: idr-bounces@ietf.org On Sat, 11 Aug 2007, Pedro R. Marques wrote: > Section 5 of the document states otherwise: > > Flow specifications received from a BGP peer and which are accepted > in the respective Adj-RIB-In are used as input to the route selection > process. Although the forwarding attributes of two routes for the > same Flow Specification prefix may be the same, BGP is still required > to perform its path selection algorithm in order to select the > correct set of attributes to advertise. > > Do you believe that the text is not clear enough in this respect ? It's clear, but that section is proving exactly my point. ;) That section makes it clear we're dealing with routing meta-data, not distinct routing information: It quite clearly describes that we're talking about data that derives meaning from routes... To move to a less abstract nit with the details of this draft: All the NLRI tuple types are optional, but validation seems to require a destination address. So shouldn't destination be a required tuple for the NLRI? How is a flow-spec without destination validated? It seems it can't be, in which it's pointless to allow such NLRIs (until some future draft specifies how..). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: telnet: Unable to connect to remote host: Connection refused _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Aug 11 16:02:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJx8Z-0002jk-Nh; Sat, 11 Aug 2007 16:00:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJx8Y-0002je-1t for idr@ietf.org; Sat, 11 Aug 2007 16:00:38 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJx8X-00075C-Nx for idr@ietf.org; Sat, 11 Aug 2007 16:00:37 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by smtpb.juniper.net with ESMTP; 11 Aug 2007 13:00:37 -0700 Received: from [172.24.104.85] ([172.24.104.85]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Aug 2007 13:00:36 -0700 Message-ID: <46BE1563.1040603@juniper.net> Date: Sat, 11 Aug 2007 13:00:35 -0700 From: "Pedro R. Marques" User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Paul Jakma Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document References: <200708051746.l75HkfO23112@merlot.juniper.net> <46BE02F3.4060308@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Aug 2007 20:00:36.0505 (UTC) FILETIME=[487ED890:01C7DC52] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Errors-To: idr-bounces@ietf.org Paul Jakma wrote: I apologize but i'm unable to follow the distinction between meta-data and routing and thus refrain from commenting. > > To move to a less abstract nit with the details of this draft: All the > NLRI tuple types are optional, but validation seems to require a > destination address. So shouldn't destination be a required tuple for > the NLRI? How is a flow-spec without destination validated? The automatic validation procedure rejects a route unless a destination address is present and matches unicast routing. Imho the document is clear about this. > It seems it > can't be, in which it's pointless to allow such NLRIs (until some future > draft specifies how..). Existing implementations allow the administrator to assert that flow routes matching particular criteria are to be accepted. This is the most common deployment mode and requires no explicit standardization. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Aug 11 19:33:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK0QZ-0005bb-L0; Sat, 11 Aug 2007 19:31:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK0QY-0005Wy-Pt for idr@ietf.org; Sat, 11 Aug 2007 19:31:26 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IK0QY-0003up-6D for idr@ietf.org; Sat, 11 Aug 2007 19:31:26 -0400 Received: from [192.168.0.4] ([82.152.216.166]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l7BNV2Km012374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2007 00:31:23 +0100 Date: Sun, 12 Aug 2007 00:30:12 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: "Pedro R. Marques" Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document In-Reply-To: <46BE1563.1040603@juniper.net> Message-ID: References: <200708051746.l75HkfO23112@merlot.juniper.net> <46BE02F3.4060308@juniper.net> <46BE1563.1040603@juniper.net> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (hibernia.jakma.org [212.17.55.49]); Sun, 12 Aug 2007 00:31:24 +0100 (IST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: idr-bounces@ietf.org On Sat, 11 Aug 2007, Pedro R. Marques wrote: > I apologize but i'm unable to follow the distinction between meta-data and > routing and thus refrain from commenting. I'll restate the point in another email, in a fashion more directly related to the draft. > The automatic validation procedure rejects a route unless a > destination address is present and matches unicast routing. Imho > the document is clear about this. Agreed. > Existing implementations allow the administrator to assert that > flow routes matching particular criteria are to be accepted. This > is the most common deployment mode and requires no explicit > standardization. Right, but that is at odds with the text of the draft. It's a nit with the text as it stands.. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Most public domain software is free, at least at first glance. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Aug 11 19:41:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK0Yt-0002SJ-Vv; Sat, 11 Aug 2007 19:40:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK0Yr-0002M8-SQ for idr@ietf.org; Sat, 11 Aug 2007 19:40:01 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IK0Yr-0004BN-8X for idr@ietf.org; Sat, 11 Aug 2007 19:40:01 -0400 Received: from [192.168.0.4] ([82.152.216.166]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l7BNdtLA012461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2007 00:39:59 +0100 Date: Sun, 12 Aug 2007 00:39:05 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: "Pedro R. Marques" Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document In-Reply-To: Message-ID: References: <200708051746.l75HkfO23112@merlot.juniper.net> <46BE02F3.4060308@juniper.net> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (hibernia.jakma.org [212.17.55.49]); Sun, 12 Aug 2007 00:40:00 +0100 (IST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: idr-bounces@ietf.org On Sat, 11 Aug 2007, Paul Jakma wrote: > To move to a less abstract nit with the details of this draft: Another one: - what happens when the route (real route) which caused a flow-spec to validate correctly is removed? It really seems to me these flow-specs are inherently tied to the RIB for some /normal/ afi/safi, in the current text... I.e. given the validation process mandated[1], the flow-specs are /derived/ from routes[2]. Indeed, if (rather than inventing some artificial SAFI) you index the flow-specs using the existing RIB, upon whose entries these flow-specs depend, then we can note: - The 'protocol' discriminator in the flow-spec NRLI is redundant.. - The 'destination' discriminator in the flow-spec is redundant.. Anyway, that's something to consider once the scope of this validation procedure is clarified. 1. And that validation procedure is a 'must' in the text: "A flow specification NLRI must be validated ... if and only if:" 2. The flows describe something that must be consequent to the route (without the route, the flow-spec is not valid, by this draft), hence the flow is meta-data of the route, to clarify a previous point. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: QOTD: I've heard about civil Engineers, but I've never met one. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Aug 11 19:57:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK0oM-0007Kc-3a; Sat, 11 Aug 2007 19:56:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK0oK-0007KV-Iq for idr@ietf.org; Sat, 11 Aug 2007 19:56:00 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IK0oK-0004mN-6J for idr@ietf.org; Sat, 11 Aug 2007 19:56:00 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by smtpa.juniper.net with ESMTP; 11 Aug 2007 16:56:00 -0700 X-IronPort-AV: i="4.19,249,1183359600"; d="scan'208"; a="55009021:sNHT37220756" Received: from [172.24.104.85] ([172.24.104.85]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Aug 2007 16:55:59 -0700 Message-ID: <46BE4C8D.3000806@juniper.net> Date: Sat, 11 Aug 2007 16:55:57 -0700 From: "Pedro R. Marques" User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Paul Jakma Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document References: <200708051746.l75HkfO23112@merlot.juniper.net> <46BE02F3.4060308@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Aug 2007 23:55:59.0168 (UTC) FILETIME=[2A423400:01C7DC73] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Errors-To: idr-bounces@ietf.org Paul Jakma wrote: > On Sat, 11 Aug 2007, Paul Jakma wrote: > >> To move to a less abstract nit with the details of this draft: > > Another one: > > - what happens when the route (real route) which caused a flow-spec > to validate correctly is removed? The document states that the flow route is valid iff and only if certain conditions are met. If those conditions no longer hold true the validation state has to transition to false. > > It really seems to me these flow-specs are inherently tied to the RIB > for some /normal/ afi/safi, in the current text... That is correct. > > I.e. given the validation process mandated[1], the flow-specs are > /derived/ from routes[2]. You cannot derive flow routes from unicast routes. > Indeed, if (rather than inventing some > artificial SAFI) you index the flow-specs using the existing RIB, upon > whose entries these flow-specs depend, then we can note: > > - The 'protocol' discriminator in the flow-spec NRLI is redundant.. Protocol matches against the "protocol" field in the IP packet. Can you please tell us how is that redundant ? > - The 'destination' discriminator in the flow-spec is redundant.. Please explain how that is the case. For it to be redundant one assumes that you can derive it from information already present in the system. I'd like to see an example of how that is the case. > > Anyway, that's something to consider once the scope of this validation > procedure is clarified. > > 1. And that validation procedure is a 'must' in the text: > > "A flow specification NLRI must be validated ... if and only if:" > > 2. The flows describe something that must be consequent to the route > (without the route, the flow-spec is not valid, by this draft), > hence the flow is meta-data of the route, to clarify a previous > point. > I fail to see how flow routes describe information about unicast routes. Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Aug 11 20:41:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK1Tx-0000LU-W5; Sat, 11 Aug 2007 20:39:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK1Tw-0000Ig-7o for idr@ietf.org; Sat, 11 Aug 2007 20:39:00 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IK1Tv-0003eb-Ht for idr@ietf.org; Sat, 11 Aug 2007 20:39:00 -0400 Received: from [192.168.0.4] ([82.152.216.166]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l7C0cpFI012879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2007 01:38:57 +0100 Date: Sun, 12 Aug 2007 01:38:01 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: "Pedro R. Marques" Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document In-Reply-To: <46BE4C8D.3000806@juniper.net> Message-ID: References: <200708051746.l75HkfO23112@merlot.juniper.net> <46BE02F3.4060308@juniper.net> <46BE4C8D.3000806@juniper.net> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (hibernia.jakma.org [212.17.55.49]); Sun, 12 Aug 2007 01:38:58 +0100 (IST) X-Spam-Score: -1.4 (-) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: , Errors-To: idr-bounces@ietf.org On Sat, 11 Aug 2007, Pedro R. Marques wrote: > The document states that the flow route is valid iff and only if > certain conditions are met. If those conditions no longer hold true > the validation state has to transition to false. Right. So don't you need to state that you are adding to section 9 of 4271 then? Also, I refer back to my question about why the destination discriminator can be optional, if it is required for validation.. These two are nits in the draft that you can easily clarify regarding the current state of deployed flow-spec, I think, no? Below is a conceptual discussion, nothing to do with what is deployed: >> I.e. given the validation process mandated[1], the flow-specs are /derived/ >> from routes[2]. > > You cannot derive flow routes from unicast routes. I'll try again: "The proposition that some flow-spec is valid or not is derived from routes (of related AFI,SAFI)." Given that (and it's given in the draft!), it seems conceptually odd to take *all* flow-specs, pertaining to flows of potentially various different AFIs,SAFIs and stuff them all together into a new RIB. > Protocol matches against the "protocol" field in the IP packet. Can you > please tell us how is that redundant ? If I've had to use the IPv4 RIB to validate the flow-spec, then the flow-spec must apply to packets only of that protocol. >> - The 'destination' discriminator in the flow-spec is redundant.. > > Please explain how that is the case. For it to be redundant one > assumes that you can derive it from information already present in > the system. I'd like to see an example of how that is the case. I'm obviously mistaken there - sorry ;). >> (without the route, the flow-spec is not valid, by this draft), > I fail to see how flow routes describe information about unicast routes. Right. They relate to them though - the draft specifies that. It doesn't make conceptual sense to try think of the aggregate flow-information as composing a distinct, seperate and indepent RIB. It doesn't make sense to even think of them as belonging to a RIB (they don't describe routes - we seem agreed on that). It just be simpler to not use UPDATE, rather than creating a franken-AFI/SAFI. To just have a flow-spec message type that can just fan-out to its own validator (re-using UPDATE attributes is still trivial). I dont see the point of trying to overload UPDATE with stuff that looks *nothing* like routes.. (a point we seem agreed on). Anyway... Notwithstanding abstract questions, there do seem to more immediate questions, see top of mail. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: QOTD: "I used to go to UCLA, but then my Dad got a job." _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Aug 12 01:13:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK5jB-00013H-DH; Sun, 12 Aug 2007 01:11:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK5j9-00013C-QI for idr@ietf.org; Sun, 12 Aug 2007 01:10:59 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IK5j9-0005hS-CF for idr@ietf.org; Sun, 12 Aug 2007 01:10:59 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 11 Aug 2007 22:10:59 -0700 X-IronPort-AV: i="4.19,250,1183359600"; d="scan'208"; a="55107449:sNHT40838724" Received: from [172.26.250.99] ([172.26.250.99]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l7C5AuO14667; Sat, 11 Aug 2007 22:10:56 -0700 (PDT) (envelope-from raszuk@juniper.net) Message-ID: <46BE9660.7070300@juniper.net> Date: Sat, 11 Aug 2007 22:10:56 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Paul Jakma Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document References: <200708051746.l75HkfO23112@merlot.juniper.net><46BE02F3.4060308@juniper.net><46BE4C8D.3000806@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: skh@nexthop.com, Yakov Rekhter , Pedro Marques , idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@juniper.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Paul, > > The document states that the flow route is valid iff and only if > > certain conditions are met. If those conditions no longer hold true > > the validation state has to transition to false. > > Right. So don't you need to state that you are adding to section 9 of > 4271 then? I don't think we need to. Notice that 9.1.2 talks about BGP route selection and we are not adding/changing those. What we are describing is an add-on for the purpose of particular application ... flow-spec. In other words I can easily see a case where flow-spec route will be valid and propagated by BGP (for example by RR) yet in the same time not valid by flow-spec rules - the case where one uses different RRs for IPv4 unicast and for flow-spec reflection. > Also, I refer back to my question about why the destination > discriminator can be optional, if it is required for validation.. > > These two are nits in the draft that you can easily clarify regarding > the current state of deployed flow-spec, I think, no? Correct. The destination is optional for two reasons ... for BGP 4271/9.1.2 section it is not required and for flow-spec it is optional when operator disables the auto-validation feature. In fact one deployment scenario is to block/rate-limit/monitor network wide some specific ports/applications. Mandating to have destination prefix of any length would make the above application much harder. > I'll try again: > > "The proposition that some flow-spec is valid or not is derived from > routes (of related AFI,SAFI)." > > Given that (and it's given in the draft!), it seems conceptually odd > to take *all* flow-specs, pertaining to flows of potentially various > different AFIs,SAFIs and stuff them all together into a new RIB. But that is clearly not the case .. even in the draft. You have separate RIB per each flow-spec SAFI (example 133/134). > > Protocol matches against the "protocol" field in the IP packet. Can you > > please tell us how is that redundant ? > > If I've had to use the IPv4 RIB to validate the flow-spec, then the > flow-spec must apply to packets only of that protocol. That is exactly the case. Cheers, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Aug 12 05:44:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK9xY-0006Ag-9Z; Sun, 12 Aug 2007 05:42:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IK9xW-0006Ab-Ne for idr@ietf.org; Sun, 12 Aug 2007 05:42:06 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IK9xV-0000z7-S5 for idr@ietf.org; Sun, 12 Aug 2007 05:42:06 -0400 Received: from [192.168.0.4] ([82.152.216.166]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l7C9fwbk007525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2007 10:42:02 +0100 Date: Sun, 12 Aug 2007 10:40:58 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Robert Raszuk Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document In-Reply-To: <46BE9660.7070300@juniper.net> Message-ID: References: <200708051746.l75HkfO23112@merlot.juniper.net><46BE02F3.4060308@juniper.net><46BE4C8D.3000806@juniper.net> <46BE9660.7070300@juniper.net> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (hibernia.jakma.org [212.17.55.49]); Sun, 12 Aug 2007 10:42:04 +0100 (IST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: skh@nexthop.com, Yakov Rekhter , Pedro Marques , 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: , Errors-To: idr-bounces@ietf.org On Sat, 11 Aug 2007, Robert Raszuk wrote: > I don't think we need to. Notice that 9.1.2 talks about BGP route > selection and we are not adding/changing those. Uhm, the document lays out a rationale for how flow-specs are no different to other routes distributed through BGP, to a point: " BGP itself treats the NLRI as an opaque key to an entry in its databases. Entries that are placed in the Loc-RIB are then associated with a given set of semantics which is application dependent. This is consistent with existing BGP applications." The existing text in 4271:9 barely applies to this SAFI though. Essentially, it'd be nice, for potential implementors, if the draft could make it clear which bits of 4271 do and which don't apply to this SAFI (given the document in one place tries to explain that much of 4271 *is* applicable ;) ). > What we are describing is an add-on for the purpose of particular application > ... flow-spec. Right, we're in violent agreement they're not routes. > In other words I can easily see a case where flow-spec route will > be valid and propagated by BGP (for example by RR) yet in the same > time not valid by flow-spec rules - the case where one uses > different RRs for IPv4 unicast and for flow-spec reflection. Ok. > Correct. The destination is optional for two reasons ... for BGP > 4271/9.1.2 section it is not required and for flow-spec it is > optional when operator disables the auto-validation feature. Right. But an implementation which allows the auto-validation feature to be disabled would no longer conform with this draft, as validation is a 'must'. Either the draft needs to say validation is optional, or else the destination discriminator needs to become mandatory. > In fact one deployment scenario is to block/rate-limit/monitor > network wide some specific ports/applications. Mandating to have > destination prefix of any length would make the above application > much harder. Neat and understood (all along). I'm trying to point out the draft is missing some text.. ;) > But that is clearly not the case .. even in the draft. You have > separate RIB per each flow-spec SAFI (example 133/134). Well, yes. Each artificial SAFI in the draft has its own SAFI and RIB. That's not what I wrote though: >> to take *all* flow-specs, pertaining to flows of potentially various >> different AFIs,SAFIs and stuff them all together into a new RIB. E.g. 1/133 (unicast flow-specs), could contain flow-specs for protocols IP and IPv6 - and they both go into one 'FlowIB', sorry RIB ;). I.e. it's pretty clear you end up with one RIB, which may contain information relating to packets of /multiple/ AFIs. Further, this RIB requires reference to one or more other RIBs to be validated, which jars with this text in section 2: "se RIBs should be treated independently from each other in order to assure non-interference between distinct applications." ;) A lot of the philosophical BGP stuff in section 2 should just be removed IMHO. >> If I've had to use the IPv4 RIB to validate the flow-spec, then the >> flow-spec must apply to packets only of that protocol. > > That is exactly the case. So the protocol discriminator is misnamed; it's not a discriminator for matching packets, it's the key to which unicast RIB is to be used for validation. That presumes of course that validation via RIB is required, which the draft and deployed reality apparently are in disagreement about ;). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: In Devon, Connecticut, it is unlawful to walk backwards after sunset. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Aug 12 05:50:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKA49-00047n-Tx; Sun, 12 Aug 2007 05:48:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKA47-00047d-6c for idr@ietf.org; Sun, 12 Aug 2007 05:48:55 -0400 Received: from hibernia.jakma.org ([212.17.55.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKA46-0001OM-JH for idr@ietf.org; Sun, 12 Aug 2007 05:48:55 -0400 Received: from [192.168.0.4] ([82.152.216.166]) (authenticated bits=0) by hibernia.jakma.org (8.14.1/8.14.1) with ESMTP id l7C9mmNW007743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Aug 2007 10:48:52 +0100 Date: Sun, 12 Aug 2007 10:47:58 +0100 (IST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Robert Raszuk Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document In-Reply-To: Message-ID: References: <200708051746.l75HkfO23112@merlot.juniper.net><46BE02F3.4060308@juniper.net><46BE4C8D.3000806@juniper.net> <46BE9660.7070300@juniper.net> Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (hibernia.jakma.org [212.17.55.49]); Sun, 12 Aug 2007 10:48:53 +0100 (IST) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: skh@nexthop.com, Yakov Rekhter , Pedro Marques , 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: , Errors-To: idr-bounces@ietf.org On Sun, 12 Aug 2007, Paul Jakma wrote: > Essentially, it'd be nice, for potential implementors, if the draft > could make it clear which bits of 4271 do and which don't apply to > this SAFI (given the document in one place tries to explain that > much of 4271 *is* applicable ;) ). Oh, this is why it'd just be nicer to have it a seperate message type. No need to worry about what extant bits of BGP (and code) do and don't implicitely apply to flow-specs. (While still allowing explicit re-use of existing BGP features obviously..). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Feature was not beta tested _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 13 13:29:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdgz-0006Dk-Hx; Mon, 13 Aug 2007 13:27:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdgy-0006CW-Th for idr@ietf.org; Mon, 13 Aug 2007 13:27:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKdgx-0005vx-HY for idr@ietf.org; Mon, 13 Aug 2007 13:27:00 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 13 Aug 2007 10:26:59 -0700 X-IronPort-AV: i="4.19,255,1183359600"; d="scan'208"; a="199256090:sNHT52391241" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7DHQxxe006098; Mon, 13 Aug 2007 10:26:59 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7DHQsiF018186; Mon, 13 Aug 2007 17:26:54 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA20873; Mon, 13 Aug 2007 10:25:43 -0700 (PDT) Date: Mon, 13 Aug 2007 10:25:43 -0700 From: Chandrashekhar Appanna To: Paul Jakma Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document Message-ID: <20070813172543.GU19275@cisco.com> References: <200708051746.l75HkfO23112@merlot.juniper.net> <46BE02F3.4060308@juniper.net> <46BE4C8D.3000806@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4001; t=1187026019; x=1187890019; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20 |Subject:=20Re=3A=20[Idr]=20draft-marques-idr-flow-spec-04.txt=20as=20an= 20IDR=20WG=20document |Sender:=20; bh=iK906GPDUeqnbeZCKiyOT9BZTD8ofm9O4BIDH4UxPbQ=; b=FRn1opLUbyWejgEL15Ojk6EM/0p12pK2rOQ7BdAYitQUODuHdLsa0lvjBbau5Jy/PBPua7GX btA/GgoyRy1hoXvOwD/jxk1Uh9UkNv1J8ka1pS56fgqlHTPRqpEr4oe9; Authentication-Results: sj-dkim-4; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: skh@nexthop.com, Yakov Rekhter , "Pedro R. Marques" , 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: , Errors-To: idr-bounces@ietf.org On Sun, Aug 12, 2007 at 01:38:01AM +0100, Paul Jakma wrote: > On Sat, 11 Aug 2007, Pedro R. Marques wrote: > > >The document states that the flow route is valid iff and only if > >certain conditions are met. If those conditions no longer hold true > >the validation state has to transition to false. > > Right. So don't you need to state that you are adding to section 9 of > 4271 then? > > Also, I refer back to my question about why the destination > discriminator can be optional, if it is required for validation.. > > These two are nits in the draft that you can easily clarify regarding > the current state of deployed flow-spec, I think, no? > > Below is a conceptual discussion, nothing to do with what is > deployed: > > >>I.e. given the validation process mandated[1], the flow-specs are > >>/derived/ from routes[2]. > > > >You cannot derive flow routes from unicast routes. > > I'll try again: > > "The proposition that some flow-spec is valid or not is derived from > routes (of related AFI,SAFI)." > > Given that (and it's given in the draft!), it seems conceptually odd > to take *all* flow-specs, pertaining to flows of potentially various > different AFIs,SAFIs and stuff them all together into a new RIB. > > >Protocol matches against the "protocol" field in the IP packet. Can you > >please tell us how is that redundant ? > > If I've had to use the IPv4 RIB to validate the flow-spec, then the > flow-spec must apply to packets only of that protocol. > > >>- The 'destination' discriminator in the flow-spec is redundant.. > > > >Please explain how that is the case. For it to be redundant one > >assumes that you can derive it from information already present in > >the system. I'd like to see an example of how that is the case. > > I'm obviously mistaken there - sorry ;). > > >> (without the route, the flow-spec is not valid, by this draft), > > >I fail to see how flow routes describe information about unicast routes. > > Right. They relate to them though - the draft specifies that. > > It doesn't make conceptual sense to try think of the aggregate > flow-information as composing a distinct, seperate and indepent RIB. > It doesn't make sense to even think of them as belonging to a RIB > (they don't describe routes - we seem agreed on that). > > It just be simpler to not use UPDATE, rather than creating a > franken-AFI/SAFI. To just have a flow-spec message type that can just > fan-out to its own validator (re-using UPDATE attributes is still > trivial). > > I dont see the point of trying to overload UPDATE with stuff that > looks *nothing* like routes.. (a point we seem agreed on). > While I am personally not against using BGP for a variety of applications.. I think the point you raise is very important. It seems to me that over time we have used the basic message structure of BGP and fitted applications to them even when all we might have wanted is the distribution semantics of BGP. In this case we have constructed an NLRI that is a long list of components and atleast _to me_ is a cery creative interpretation of an UPDATE message. What about the attributes? There is a statement that all standard BGP policy mechanisms should apply as usual, in the draft but based on the limited amount of time I have spent on this draft, I cannot see that many of the attributes would even apply here. Till date that has not been asked for when new AFI/SAFIs are brought in.. Rgds, Chandra. > Anyway... > > Notwithstanding abstract questions, there do seem to more immediate > questions, see top of mail. > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > QOTD: > "I used to go to UCLA, but then my Dad got a job." > > _______________________________________________ > 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 Aug 13 16:23:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKgPn-00072H-Nq; Mon, 13 Aug 2007 16:21:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKgPm-00071t-IF for idr@ietf.org; Mon, 13 Aug 2007 16:21:26 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKgPm-0005NW-6B for idr@ietf.org; Mon, 13 Aug 2007 16:21:26 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpa.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 13 Aug 2007 13:21:26 -0700 X-IronPort-AV: i="4.19,256,1183359600"; d="scan'208"; a="56471429:sNHT35337060" Received: from [172.26.250.99] ([172.26.250.99]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l7DKL0O94907; Mon, 13 Aug 2007 13:21:01 -0700 (PDT) (envelope-from raszuk@juniper.net) Message-ID: <46C0BD2C.3020604@juniper.net> Date: Mon, 13 Aug 2007 13:21:00 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Chandrashekhar Appanna Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document References: <200708051746.l75HkfO23112@merlot.juniper.net><46BE02F3.4060308@juniper.net><46BE4C8D.3000806@juniper.net> <20070813172543.GU19275@cisco.com> In-Reply-To: <20070813172543.GU19275@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: skh@nexthop.com, idr@ietf.org, Yakov Rekhter , Pedro Marques , Paul Jakma , David Ward X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@juniper.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Chandra, > While I am personally not against using BGP for a variety of > applications.. > I think the point you raise is very important. It seems to me that over > time we have used the basic message structure of BGP and fitted > applications > to them even when all we might have wanted is the distribution semantics > of BGP. In this case we have constructed an NLRI that is a long list of > components and atleast _to me_ is a cery creative interpretation of an > UPDATE message. What about the attributes? There is a statement that all > standard BGP policy mechanisms should apply as usual, in the draft but > based on the limited amount of time I have spent on this draft, I cannot > see that many of the attributes would even apply here. Till date that has > not been asked for when new AFI/SAFIs are brought in.. You are asking the same question again to which I have already replied on the 10th of Aug. Was there anything in my reply not clear which would require further explanation ? I think I explained well the reasons for flow-spec rules to be placed in the MP_REACH NLRIs. If on the other hand you would like to discuss if new drafts fit the sematics of BGP UPDATE msg could you start a new thread and bring some arguments which would justify draft-pmohapat-idr-info-safi-02.txt to fit semantics of BGP UPDATE msg ? I did spend sufficient amount of time on this draft and see no relation of it's proposed NLRI format to routing information. Thx, R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 13 16:30:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKgWX-0000KN-GS; Mon, 13 Aug 2007 16:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKgWX-0000KI-3Q for idr@ietf.org; Mon, 13 Aug 2007 16:28:25 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKgWV-0004Yh-RT for idr@ietf.org; Mon, 13 Aug 2007 16:28:25 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 13 Aug 2007 13:28:24 -0700 X-IronPort-AV: i="4.19,256,1183359600"; d="scan'208"; a="391960510:sNHT49671464" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7DKSNKR022179; Mon, 13 Aug 2007 13:28:23 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7DKSNVp001678; Mon, 13 Aug 2007 20:28:23 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA19882; Mon, 13 Aug 2007 13:27:12 -0700 (PDT) Date: Mon, 13 Aug 2007 13:27:12 -0700 From: Chandrashekhar Appanna To: Robert Raszuk Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document Message-ID: <20070813202712.GA19275@cisco.com> References: <20070813172543.GU19275@cisco.com> <46C0BD2C.3020604@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46C0BD2C.3020604@juniper.net> User-Agent: Mutt/1.4i DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2149; t=1187036903; x=1187900903; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20 |Subject:=20Re=3A=20[Idr]=20draft-marques-idr-flow-spec-04.txt=20as=20an= 20IDR=20WG=20document |Sender:=20; bh=d46UEZ7WAFt/3V6Es0Ayn8wHGyhyLQXvyi+P0e6kxJs=; b=P4tZuV67Ssxq6/QKHhZcmUWEF47CvGOiEAlvUzwBOuWSAko8qKrOdYEwc5W6Q0tMAFpwekb4 aHmvYIozV9ojcMCYmT1zu7alMfHaaFDKgRoNPKhVqChDOGazXKwDQ+Kb; Authentication-Results: sj-dkim-4; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: skh@nexthop.com, idr@ietf.org, Yakov Rekhter , Pedro Marques , Paul Jakma , David Ward , Chandrashekhar Appanna 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: , Errors-To: idr-bounces@ietf.org On Mon, Aug 13, 2007 at 01:21:00PM -0700, Robert Raszuk wrote: > Chandra, > > > While I am personally not against using BGP for a variety of > >applications.. > > I think the point you raise is very important. It seems to me that over > > time we have used the basic message structure of BGP and fitted > >applications > > to them even when all we might have wanted is the distribution semantics > > of BGP. In this case we have constructed an NLRI that is a long list of > > components and atleast _to me_ is a cery creative interpretation of an > > UPDATE message. What about the attributes? There is a statement that all > > standard BGP policy mechanisms should apply as usual, in the draft but > > based on the limited amount of time I have spent on this draft, I cannot > > see that many of the attributes would even apply here. Till date that has > > not been asked for when new AFI/SAFIs are brought in.. > > You are asking the same question again to which I have already replied > on the 10th of Aug. Was there anything in my reply not clear which would > require further explanation ? > > I think I explained well the reasons for flow-spec rules to be placed in > the MP_REACH NLRIs. > > If on the other hand you would like to discuss if new drafts fit the > sematics of BGP UPDATE msg could you start a new thread and bring some > arguments which would justify draft-pmohapat-idr-info-safi-02.txt to fit > semantics of BGP UPDATE msg ? I did spend sufficient amount of time on I was not specifically pointing to the flowspec idea as the only one where we are crossing a boundary (I do not even know if there is one)... my comments was that generally that in IDR I have not seen that as a community we ask that question when new AFi/SAFI requests are brought in. I agree with you that such a question might apply to other AFI/SAFI also. Paul's point did resonate with my thinking and my response was in the context of his point. Rgds, Chandra. > this draft and see no relation of it's proposed NLRI format to routing > information. > > Thx, > R. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Aug 13 16:36:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKgcW-0005nv-Vb; Mon, 13 Aug 2007 16:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKgcU-0005np-Fw for idr@ietf.org; Mon, 13 Aug 2007 16:34:34 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKgcT-0004pL-AE for idr@ietf.org; Mon, 13 Aug 2007 16:34:34 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 13 Aug 2007 13:34:31 -0700 Received: from [172.26.250.99] ([172.26.250.99]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l7DKYOO97969; Mon, 13 Aug 2007 13:34:24 -0700 (PDT) (envelope-from raszuk@juniper.net) Message-ID: <46C0C04F.6060401@juniper.net> Date: Mon, 13 Aug 2007 13:34:23 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Chandrashekhar Appanna Subject: Re: [Idr] draft-marques-idr-flow-spec-04.txt as an IDR WG document References: <20070813172543.GU19275@cisco.com> <46C0BD2C.3020604@juniper.net> <20070813202712.GA19275@cisco.com> In-Reply-To: <20070813202712.GA19275@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: skh@nexthop.com, idr@ietf.org, Yakov Rekhter , Pedro Marques , Paul Jakma , David Ward X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@juniper.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Chandra, And that is exactly why I only suggested you should start a new thread on that topic and let this one be focused on discussion related to flow-spec only. Cheers, R. > > You are asking the same question again to which I have already replied > > on the 10th of Aug. Was there anything in my reply not clear which would > > require further explanation ? > > > > I think I explained well the reasons for flow-spec rules to be placed in > > the MP_REACH NLRIs. > > > > If on the other hand you would like to discuss if new drafts fit the > > sematics of BGP UPDATE msg could you start a new thread and bring some > > arguments which would justify draft-pmohapat-idr-info-safi-02.txt to fit > > semantics of BGP UPDATE msg ? I did spend sufficient amount of time on > > I was not specifically pointing to the flowspec idea as the only one > where we are > crossing a boundary (I do not even know if there is one)... my > comments was > that generally that in IDR I have > not seen that as a community we ask that question when new AFi/SAFI > requests > are brought in. I agree with you that such a question might apply to other > AFI/SAFI also. Paul's point did resonate with my thinking and my response > was in the context of his point. > > Rgds, > Chandra. > > > this draft and see no relation of it's proposed NLRI format to routing > > information. > > > > Thx, > > R. > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 14 11:16:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKy5e-0003Up-Ot; Tue, 14 Aug 2007 11:13:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKy5c-0003Uh-Ew for idr@ietf.org; Tue, 14 Aug 2007 11:13:48 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKy5b-0004Ax-8w for idr@ietf.org; Tue, 14 Aug 2007 11:13:48 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 14 Aug 2007 08:13:46 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l7EFDbO52432; Tue, 14 Aug 2007 08:13:41 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200708141513.l7EFDbO52432@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <43287.1187104417.1@juniper.net> Date: Tue, 14 Aug 2007 08:13:37 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: skh@nexthop.com Subject: [Idr] RE: draft-marques-idr-flow-spec-04.txt as an IDR WG document 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: , Errors-To: idr-bounces@ietf.org Folks, We have a fairly strong (but not unanimous) consensus to accept draft-marques-idr-flow-spec-04.txt as an IDR WG document. With this in mind, the IDR chairs ask the authors of the draft to resubmit it as an IDR WG document. Sue & Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 14 14:37:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1EG-0000p0-Rx; Tue, 14 Aug 2007 14:34:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1EF-0000ou-NN for idr@ietf.org; Tue, 14 Aug 2007 14:34:55 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL1EE-0002bl-DE for idr@ietf.org; Tue, 14 Aug 2007 14:34:55 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 14 Aug 2007 11:34:53 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l7EIYmO07546; Tue, 14 Aug 2007 11:34:49 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200708141834.l7EIYmO07546@merlot.juniper.net> To: idr@ietf.org Subject: [Idr] draft-pmohapat-idr-info-safi-02.txt as an IDR WG document MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70315.1187116488.1@juniper.net> Date: Tue, 14 Aug 2007 11:34:48 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: , Errors-To: idr-bounces@ietf.org Folks, Since there were no objections to accepting draft-pmohapat-idr-info-safi-02.txt as an IDR WG document, and since this document is a normative reference in one of the Softwires WG documents, the IDR WG accepts this document as an IDR WG document. The IDR WG chairs ask the authors of the draft to resubmit it as an IDR WG document with the name draft-ietf-idr-encaps-safi. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Aug 14 14:43:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1Kh-0004qn-7L; Tue, 14 Aug 2007 14:41:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL1Kg-0004qi-Cf for idr@ietf.org; Tue, 14 Aug 2007 14:41:34 -0400 Received: from somehost-5.equinix.net ([207.20.85.157] helo=glaciar.corp.equinix.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL1KZ-0002kr-W2 for idr@ietf.org; Tue, 14 Aug 2007 14:41:34 -0400 Received: from glaciar.corp.equinix.com (localhost [127.0.0.1]) by glaciar.corp.equinix.com (8.12.11/8.12.11) with ESMTP id l7EIf73l023738; Tue, 14 Aug 2007 11:41:07 -0700 (PDT) Received: (from mschmidt@localhost) by glaciar.corp.equinix.com (8.12.11/8.12.11) id l7EIf2F6000707; Tue, 14 Aug 2007 11:41:02 -0700 (PDT) Date: Tue, 14 Aug 2007 11:41:02 -0700 From: Marcelo Schmidt To: Tony Li Subject: Re: [Idr] Re: draft-ietf-idr-as-pathlimit-03.txt Message-ID: <20070814184102.GA4953@equinix.com> References: <68357C8C-66C0-4520-8316-CACA1C431CCE@cisco.com> Mime-Version: 1.0 In-Reply-To: <68357C8C-66C0-4520-8316-CACA1C431CCE@cisco.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Inter-Domain Routing List , Paul Jakma 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="===============0019750319==" Errors-To: idr-bounces@ietf.org --===============0019750319== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 30, 2007 at 07:11:59AM -0700, Tony Li wrote: > > E.g. When sending an AS_PATHLIMIT with a private-ASN to an EBGP > > neighbour outside of the parent AS, a speaker should update the > > ASN in the attribute with preferrably its own ASN, if that is a > > public ASN, or else the ASN of the EBGP peer the attribute is > > being sent to, if that is a public ASN. > > > > That still allows for the discretion around determining 'parent AS' > > which the original wording carefully put there, but gives a gentle > > hint as to expected behaviour.. >=20 > Works for me. Other folks? I think the e.g works but I just have a little problem understand the wording around the end of the e.g. "being sent to, if that is a public ASN." If I would tried to follow the example in this kinda psuedo C (laughable enough) it looks like this :) /* AS_PATHLIMIT with a private-ASN to an EBGP \ _neighbor_ outside of the parent AS: */ =09 if (that is a public ASN) { a speaker should update the ASN in \ the attribute with preferrably its own ASN } else {=20 the ASN of the EBGP peer the attribute is \ being sent to } if that is a public ASN? --=20 -m =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Key fingerprint =3D 8E48 6CD0 6D2B 538E 264B D1D0 21E2 E7EE A40F 2A0B gpg --keyserver wwwkeys.pgp.net --recv-keys 0xA40F2A0B =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iD8DBQFGwfc+IeLn7qQPKgsRAtKJAJ95o3C7wizm2tTQJejqIt8pdrc89gCfQfdW ZzqqO/YmnSY4hqmevy20Ahg= =mbdX -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- --===============0019750319== 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 --===============0019750319==-- From idr-bounces@ietf.org Tue Aug 14 17:19:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL3lr-0006A7-8h; Tue, 14 Aug 2007 17:17:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL3lp-0006A0-D1 for idr@ietf.org; Tue, 14 Aug 2007 17:17:45 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL3lp-0001n8-1J for idr@ietf.org; Tue, 14 Aug 2007 17:17:45 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Aug 2007 14:17:44 -0700 X-IronPort-AV: i="4.19,261,1183359600"; d="scan'208"; a="513513365:sNHT48767176" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7ELHiiH008980; Tue, 14 Aug 2007 14:17:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7ELHYFE010047; Tue, 14 Aug 2007 21:17:44 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 14:17:38 -0700 Received: from [171.71.55.44] ([171.71.55.44]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 14:17:38 -0700 In-Reply-To: <20070814184102.GA4953@equinix.com> References: <68357C8C-66C0-4520-8316-CACA1C431CCE@cisco.com> <20070814184102.GA4953@equinix.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9F29544C-27B4-4738-8BD4-A82D66A51056@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Re: draft-ietf-idr-as-pathlimit-03.txt Date: Tue, 14 Aug 2007 14:17:35 -0700 To: Marcelo Schmidt X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Aug 2007 21:17:38.0016 (UTC) FILETIME=[8A5EB600:01C7DEB8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1414; t=1187126264; x=1187990264; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20Re=3A=20draft-ietf-idr-as-pathlimit-03.txt |Sender:=20; bh=eXAv09OZvnwfQMTgvywu42ZimwstL2AWUzL5PnJFv8M=; b=qhJP6f5IhYEPlvjZevEltr9DmoTzxM2004KzoO87bKuMgiMu8TSJLywzil4IdzVqsauaOBRK lddkzhQ3I4GKEyGcyaBSMh5UMC+jBC52Qse7FrnZM9vthbn8HowP692x; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Inter-Domain Routing List , Paul Jakma 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: , Errors-To: idr-bounces@ietf.org On Aug 14, 2007, at 11:41 AM, Marcelo Schmidt wrote: > On Mon, Jul 30, 2007 at 07:11:59AM -0700, Tony Li wrote: >>> E.g. When sending an AS_PATHLIMIT with a private-ASN to an EBGP >>> neighbour outside of the parent AS, a speaker should update the >>> ASN in the attribute with preferrably its own ASN, if that is a >>> public ASN, or else the ASN of the EBGP peer the attribute is >>> being sent to, if that is a public ASN. >>> >>> That still allows for the discretion around determining 'parent AS' >>> which the original wording carefully put there, but gives a gentle >>> hint as to expected behaviour.. >> >> Works for me. Other folks? > > I think the e.g works but I just have a little problem understand the > wording around the end of the e.g. "being sent to, if that is a > public ASN." > If I would tried to follow the example in this kinda psuedo C > (laughable > enough) it looks like this :) > > /* AS_PATHLIMIT with a private-ASN to an EBGP \ > _neighbor_ outside of the parent AS: */ > > if (that is a public ASN) { > a speaker should update the ASN in \ > the attribute with preferrably its own ASN > } else { > the ASN of the EBGP peer the attribute is \ > being sent to > } > if that is a public ASN? > Hi Marcelo, I think you have the intent correct. I might have coded it slightly differently. ;-) Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Aug 15 16:17:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPHI-0000I5-Qx; Wed, 15 Aug 2007 16:15:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPHA-0008OU-Ox; Wed, 15 Aug 2007 16:15:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILPHA-00072I-Ad; Wed, 15 Aug 2007 16:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3AA282AC64; Wed, 15 Aug 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ILPGf-0000mT-W7; Wed, 15 Aug 2007 16:15:01 -0400 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, 15 Aug 2007 16:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-flow-spec-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: , 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 : Dissemination of flow specification rules Author(s) : P. Marques Filename : draft-ietf-idr-flow-spec-00.txt Pages : 25 Date : 2007-8-15 This document defines a new BGP NLRI encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more-specific components of the traffic aggregate defined by an IP destination prefix. Additionally it defines two applications of that encoding format. One that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial of service attacks. And a second application to traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the Border Gateway Protocol (BGP), thereby reusing protocol algorithms, operational experience and administrative processes such as inter-provider peering agreements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-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-flow-spec-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-flow-spec-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: <2007-8-15151959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-flow-spec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-flow-spec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-15151959.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 Mon Aug 20 06:53:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN4qf-000695-Pm; Mon, 20 Aug 2007 06:51:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN4qf-000690-3S for idr@ietf.org; Mon, 20 Aug 2007 06:51:05 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN4qe-0003Y5-PP for idr@ietf.org; Mon, 20 Aug 2007 06:51:05 -0400 Received: from unknown (HELO emailsmtp55.jnpr.net) ([172.24.18.132]) by smtpb.juniper.net with ESMTP; 20 Aug 2007 03:51:04 -0700 Received: from emailbng1.jnpr.net ([10.209.194.15]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 03:51:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Aug 2007 16:23:20 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Obscure 4-byte AS implementation question thread-index: AcbxFv5VFgmrUgIPSnKYm6VzMQpLUAZdGNjQAAAwZlA2HIfs0A== From: "Kaliraj Vairavakkalai" To: , X-OriginalArrivalTime: 20 Aug 2007 10:51:03.0617 (UTC) FILETIME=[00D72B10:01C7E318] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: idr@ietf.org, Bruno Rijsman , lorenzo@ripe.net Subject: [Idr] RE: Obscure 4-byte AS implementation question 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: , Errors-To: idr-bounces@ietf.org Quaizar, Enke :=20 > Note that a valid AS_CONFED_SEQUENCE or AS_CONFED_SET path segment=20 > SHALL be prepended if it is either the leading path segment or=20 > adjacent to a path segment that is prepended. It was a bit confusing to us what this statement from RFC-4893 exactly meant. So please clarify. Does it mean that -=20 "While making a consolidated-AS-path out of a four-byte(new) and two-byte(old) AS-path-attributes received in a BGP-update, an ASCONF_SEQ or ASCONF_SET appearing in the old-AS-path before the first non-confed-segment should be prepended to the consolidated-AS-path. Any AS_CONF_SEQ or AS_CONF_SET appearing in mid of non-confed-segment entries in the old-AS-path should be ignored and not included in the consolidated-AS-path." But I think confed-segments, in the first-place, cannot occur in between non-confed-segments in an ASpath. So I could be missing something?=20 Could you please clarify what the above statement implies?=20 Kaliraj=20 =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Aug 31 11:17:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR8Dq-0006iQ-FJ; Fri, 31 Aug 2007 11:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR8Dd-0006Qk-Ua; Fri, 31 Aug 2007 11:15:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IR8Dc-0000Me-CX; Fri, 31 Aug 2007 11:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 4C518328B9; Fri, 31 Aug 2007 15:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IR8D8-0001yM-72; Fri, 31 Aug 2007 11:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 31 Aug 2007 11:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-encaps-safi-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: , 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 : BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute Author(s) : E. Rosen, P. Mohapatra Filename : draft-ietf-idr-encaps-safi-00.txt Pages : 13 Date : 2007-8-31 In certain situations, transporting a packet from one BGP speaker to another, the BGP next hop, requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header. The encapsulation information need not be signaled for all encapsulation types. In the cases where the signaling is required (such as L2TPv3, GRE with key), This draft specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the "Encapsulation SAFI" and IPv4 or IPv6 AFI. In the cases where no encapsulation information needs to be signaled (such as GRE without key), this draft specifies a BGP extended community that can be attached to UPDATE messages that carry payload prefixes to indicate the encapsulation protocol type to be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-encaps-safi-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-encaps-safi-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-encaps-safi-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: <2007-8-31105257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-encaps-safi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-encaps-safi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-31105257.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--