From njamin@americanhotel.com Mon Jan 5 05:14:13 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE843A689E for ; Mon, 5 Jan 2009 05:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.729 X-Spam-Level: X-Spam-Status: No, score=-33.729 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnTdFoa1enN2 for ; Mon, 5 Jan 2009 05:14:13 -0800 (PST) Received: from adjk214.neoplus.adsl.tpnet.pl (adjk214.neoplus.adsl.tpnet.pl [79.184.218.214]) by core3.amsl.com (Postfix) with SMTP id 1711D3A68B6 for ; Mon, 5 Jan 2009 05:14:11 -0800 (PST) To: Subject: Re: Order status 94379 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090105131412.1711D3A68B6@core3.amsl.com> Date: Mon, 5 Jan 2009 05:14:11 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 39503
From idr-bounces@ietf.org Tue Jan 6 08:54:40 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50E523A6923; Tue, 6 Jan 2009 08:54:40 -0800 (PST) X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id AEC073A689D; Tue, 6 Jan 2009 08:54:38 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090106165438.AEC073A689D@core3.amsl.com> Date: Tue, 6 Jan 2009 08:54:38 -0800 (PST) Cc: idr@ietf.org Subject: [Idr] Last Call: draft-ietf-idr-flow-spec (Dissemination of flow specification rules) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Dissemination of flow specification rules ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-01-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16385&rfc_flag=0 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 6 11:00:04 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC4228C15B; Tue, 6 Jan 2009 11:00:04 -0800 (PST) X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C5A233A6893; Tue, 6 Jan 2009 11:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090106190001.C5A233A6893@core3.amsl.com> Date: Tue, 6 Jan 2009 11:00:01 -0800 (PST) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-rfc3392bis-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Capabilities Advertisement with BGP-4 Author(s) : J. Scudder, R. Chandra Filename : draft-ietf-idr-rfc3392bis-04.txt Pages : 6 Date : 2009-01-06 This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3392bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-idr-rfc3392bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-06104732.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/idr --NextPart-- From kjlin@amath.nchu.edu.tw Tue Jan 6 19:07:06 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 700253A6988 for ; Tue, 6 Jan 2009 19:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -37.351 X-Spam-Level: X-Spam-Status: No, score=-37.351 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hd4NyLGrgyw for ; Tue, 6 Jan 2009 19:07:00 -0800 (PST) Received: from 89-138-98-122.bb.netvision.net.il (89-138-98-122.bb.netvision.net.il [89.138.98.122]) by core3.amsl.com (Postfix) with SMTP id 2A24F3A6894 for ; Tue, 6 Jan 2009 19:06:56 -0800 (PST) To: Subject: Your order 09877 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090107030658.2A24F3A6894@core3.amsl.com> Date: Tue, 6 Jan 2009 19:06:56 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 48413
From idr-bounces@ietf.org Wed Jan 7 10:28:21 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8CB3A69A6; Wed, 7 Jan 2009 10:28:21 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221243A69A6 for ; Wed, 7 Jan 2009 10:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF6ROYt1EHFw for ; Wed, 7 Jan 2009 10:28:19 -0800 (PST) Received: from chip3og51.obsmtp.com (chip3og51.obsmtp.com [64.18.14.167]) by core3.amsl.com (Postfix) with ESMTP id D97DC3A687C for ; Wed, 7 Jan 2009 10:28:18 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob51.postini.com ([64.18.6.12]) with SMTP ID DSNKSWT0MK/CcBMpEGvvmioqZgQuO6iRgzZN@postini.com; Wed, 07 Jan 2009 10:28:06 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Wed, 7 Jan 2009 10:25:24 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 10:25:24 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 10:25:23 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jan 2009 10:25:23 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n07IPMM70266; Wed, 7 Jan 2009 10:25:22 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200901071825.n07IPMM70266@magenta.juniper.net> To: dward@cisco.com MIME-Version: 1.0 Content-ID: <19895.1231352722.1@juniper.net> Date: Wed, 7 Jan 2009 10:25:22 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 07 Jan 2009 18:25:23.0577 (UTC) FILETIME=[4E107690:01C970F5] Cc: rcallon@juniper.net, idr@ietf.org Subject: [Idr] registry for BGP optional parameters X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Dave, IDR WG would like to ask IANA to create and maintain a registry for OPEN message optional parameters called "BGP OPEN Optional Parameter Type". Optional parameters are identified by the Parameter Type, which is a one-octet unsigned integer. Values are to be allocated according to the "IETF Consensus" policy as defined in [RFC5226]. The registry should be populated with the two Parameter Type codes that are currently defined: o Parameter Type 1: Authentication (deprecated). o Parameter Type 2: Capabilities ([RFC3392]) Yakov. ------- Forwarded Message Date: Wed, 24 Dec 2008 13:14:54 -0800 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] registry for BGP optional parameters Folks, This is to start the IDR WG Last Call on the following proposal by John Scudder: The base BGP specification [RFC4271] specifies in Section 4.2 a mechanism to include optional parameters with the OPEN message. Optional parameters are identified by the Parameter Type, which is a one-octet unsigned binary integer. Two Parameter Type codes are currently defined: o Parameter Type 1: Authentication (deprecated). o Parameter Type 2: Capabilities ([RFC3392]) This proposal is to request that IANA create and maintain a registry for OPEN message optional parameters called "BGP OPEN Optional Parameter Type". Values are to be allocated according to the "IETF Consensus" policy as defined in [RFC5226]. The Last Call ends Jan 7, 2009. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 7 13:00:04 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30103A6A77; Wed, 7 Jan 2009 13:00:03 -0800 (PST) X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ACC5728B797; Wed, 7 Jan 2009 13:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090107210001.ACC5728B797@core3.amsl.com> Date: Wed, 7 Jan 2009 13:00:01 -0800 (PST) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-rfc3392bis-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Capabilities Advertisement with BGP-4 Author(s) : J. Scudder, R. Chandra Filename : draft-ietf-idr-rfc3392bis-05.txt Pages : 7 Date : 2009-01-07 This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3392bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-idr-rfc3392bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-07125452.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Wed Jan 7 13:08:32 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7D103A6A60; Wed, 7 Jan 2009 13:08:32 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D993A6A60 for ; Wed, 7 Jan 2009 13:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mePLy95++fz for ; Wed, 7 Jan 2009 13:08:31 -0800 (PST) Received: from chip3og61.obsmtp.com (chip3og61.obsmtp.com [64.18.14.187]) by core3.amsl.com (Postfix) with ESMTP id 082243A67EE for ; Wed, 7 Jan 2009 13:08:30 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob61.postini.com ([64.18.6.12]) with SMTP ID DSNKSWUZwcOD84y1bbSl/QqAo0EaCdwgCJDX@postini.com; Wed, 07 Jan 2009 13:08:18 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Wed, 7 Jan 2009 13:03:53 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 13:03:53 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 13:03:53 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 13:03:53 -0800 Received: from [172.16.13.200] ([172.16.13.200]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n07L3qM52226 for ; Wed, 7 Jan 2009 13:03:52 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: <0AD4AAEF-0F74-4F86-93C0-D00941D8D4E6@juniper.net> From: "John G. Scudder" To: Inter-Domain Routing List In-Reply-To: <20090107210001.ACC5728B797@core3.amsl.com> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 7 Jan 2009 16:03:51 -0500 References: <20090107210001.ACC5728B797@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 07 Jan 2009 21:03:53.0114 (UTC) FILETIME=[7230A7A0:01C9710B] Subject: Re: [Idr] I-D Action:draft-ietf-idr-rfc3392bis-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org FYI versions -04 and -05 address feedback received during IESG review. Summary of changes between -03 and -05: - Added "obsoletes" header. - Added some additional descriptive text to the Introduction. - Changed SHOULD to MUST in the case of sending an Unsupported Capability NOTIFICATION. - Changed SHOULD to MUST in the case of ignoring a capability which the speaker doesn't recognize. - Noted that a speaker MUST be prepared to accept multiple instances of a capability. (This was already implicit.) - Updated acks and change log. The s/SHOULD/MUST/ changes are nominally normative changes, but ought to be non-controversial. --John On Jan 7, 2009, at 4:00 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Inter-Domain Routing Working Group > of the IETF. > > > Title : Capabilities Advertisement with BGP-4 > Author(s) : J. Scudder, R. Chandra > Filename : draft-ietf-idr-rfc3392bis-05.txt > Pages : 7 > Date : 2009-01-07 > > This document defines an Optional Parameter, called Capabilities, > that is expected to facilitate the introduction of new capabilities > in the Border Gateway Protocol (BGP) by providing graceful capability > advertisement without requiring that BGP peering be terminated. This > document obsoletes RFC 3392. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3392bis-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From m-imakurusu@acrossboard.co.jp Wed Jan 7 19:24:24 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 868343A6993 for ; Wed, 7 Jan 2009 19:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.214 X-Spam-Level: X-Spam-Status: No, score=-11.214 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nn5ouBwlNGpI for ; Wed, 7 Jan 2009 19:24:23 -0800 (PST) Received: from h104.60.91.75.dynamic.ip.windstream.net (h104.60.91.75.dynamic.ip.windstream.net [75.91.60.104]) by core3.amsl.com (Postfix) with SMTP id E20EF3A6984 for ; Wed, 7 Jan 2009 19:24:22 -0800 (PST) To: Subject: Re: Order status 39542 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090108032422.E20EF3A6984@core3.amsl.com> Date: Wed, 7 Jan 2009 19:24:22 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 01749
From keithhouin@aglending.com Thu Jan 8 03:47:23 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7914E3A6A97 for ; Thu, 8 Jan 2009 03:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.327 X-Spam-Level: X-Spam-Status: No, score=-15.327 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I92oWyUuSbBb for ; Thu, 8 Jan 2009 03:47:22 -0800 (PST) Received: from access-accounts.com (unknown [122.160.68.94]) by core3.amsl.com (Postfix) with SMTP id F14113A6A5E for ; Thu, 8 Jan 2009 03:47:20 -0800 (PST) To: Subject: Re: Order status 59324 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090108114720.F14113A6A5E@core3.amsl.com> Date: Thu, 8 Jan 2009 03:47:20 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 24145
From idr-archive@odin.ie Thu Jan 8 07:34:42 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF973A6AD4 for ; Thu, 8 Jan 2009 07:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -61.737 X-Spam-Level: X-Spam-Status: No, score=-61.737 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_H_CANADIAN=0.5, GB_H_PHARMACY=1, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiNR4HSYYoq4 for ; Thu, 8 Jan 2009 07:34:42 -0800 (PST) Received: from mta.email.webmd.com (unknown [195.78.244.51]) by core3.amsl.com (Postfix) with SMTP id 53EBD3A68E0 for ; Thu, 8 Jan 2009 07:34:39 -0800 (PST) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20090108083410.4206.qmail@mta.email.webmd.com> From: "Doctor Louisa" To: idr-archive@ietf.org Subject: RE: (Canadian Pharmacy Message) We need your presence MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 8 Jan 2009 07:34:39 -0800 (PST)
From lucktiger@alum.rpi.edu Fri Jan 9 05:40:47 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE3553A6A5D for ; Fri, 9 Jan 2009 05:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.486 X-Spam-Level: X-Spam-Status: No, score=-21.486 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4tBKH-FNCxV for ; Fri, 9 Jan 2009 05:40:46 -0800 (PST) Received: from adsl190-28-131-235.epm.net.co (adsl190-28-131-235.epm.net.co [190.28.131.235]) by core3.amsl.com (Postfix) with SMTP id C36013A686E for ; Fri, 9 Jan 2009 05:40:45 -0800 (PST) To: Subject: Your order 85748 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090109134045.C36013A686E@core3.amsl.com> Date: Fri, 9 Jan 2009 05:40:45 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 62829
From jopsdd@alien.bt.co.uk Sat Jan 10 09:52:50 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F8B3A68C8 for ; Sat, 10 Jan 2009 09:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.327 X-Spam-Level: X-Spam-Status: No, score=-15.327 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTOW30u2XJ5W for ; Sat, 10 Jan 2009 09:52:49 -0800 (PST) Received: from alliancelink.com (unknown [121.246.170.43]) by core3.amsl.com (Postfix) with SMTP id 37D633A69CA for ; Sat, 10 Jan 2009 09:52:47 -0800 (PST) To: Subject: Your order 34754 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090110175248.37D633A69CA@core3.amsl.com> Date: Sat, 10 Jan 2009 09:52:47 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 64288
From laufer5@aig.com Sat Jan 10 16:37:24 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DBE13A6A6F for ; Sat, 10 Jan 2009 16:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.638 X-Spam-Level: X-Spam-Status: No, score=-14.638 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HOST_EQ_BROADBND=1.118, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIlNNttJiJXP for ; Sat, 10 Jan 2009 16:37:23 -0800 (PST) Received: from 85-189-234-11.tmbsystems.managedbroadband.co.uk (85-189-234-11.tmbsystems.managedbroadband.co.uk [85.189.234.11]) by core3.amsl.com (Postfix) with SMTP id 936333A6A6A for ; Sat, 10 Jan 2009 16:37:18 -0800 (PST) To: Subject: Re: Order status 42717 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090111003720.936333A6A6A@core3.amsl.com> Date: Sat, 10 Jan 2009 16:37:18 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 66910
From kumoto@ahm.honda.com Sun Jan 11 04:05:43 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03D03A69A9 for ; Sun, 11 Jan 2009 04:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.001 X-Spam-Level: X-Spam-Status: No, score=-3.001 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVJjQ6H9qYVL for ; Sun, 11 Jan 2009 04:05:43 -0800 (PST) Received: from ejt63.neoplus.adsl.tpnet.pl (ejt63.neoplus.adsl.tpnet.pl [83.21.161.63]) by core3.amsl.com (Postfix) with SMTP id 11A363A699A for ; Sun, 11 Jan 2009 04:05:41 -0800 (PST) To: Subject: RE: Message 87544 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090111120542.11A363A699A@core3.amsl.com> Date: Sun, 11 Jan 2009 04:05:41 -0800 (PST)

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 02782
From idr-bounces@ietf.org Wed Jan 14 06:54:52 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9F328C174; Wed, 14 Jan 2009 06:54:52 -0800 (PST) X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7ED523A69F5; Wed, 14 Jan 2009 06:54:50 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090114145450.7ED523A69F5@core3.amsl.com> Date: Wed, 14 Jan 2009 06:54:50 -0800 (PST) Cc: idr mailing list , idr chair , Internet Architecture Board , RFC Editor Subject: [Idr] Protocol Action: 'Capabilities Advertisement with BGP-4' to Draft Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org The IESG has approved the following document: - 'Capabilities Advertisement with BGP-4 ' as a Draft Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are David Ward and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3392bis-05.txt Technical Summary This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. Working Group Summary There were no objections to this document within the IDR WG during the IDR WG Last Call. Document Quality There are multiple, interoperable implementations of this technology. Personnel Dave Ward RFC-Editor Note Please add this to the IANA Considerations section: IANA is requested to create and maintain a registry for OPEN message optional parameters called "BGP OPEN Optional Parameter Types". Optional parameters are identified by the Parameter Type, which is a one-octet unsigned integer. Values (0 reserved, 1-255) are to be allocated according to the "IETF Review" policy as defined in [RFC5226]. The registry should be populated with the two Parameter Type codes that are currently defined: o Parameter Type 1: Authentication (deprecated). o Parameter Type 2: Capabilities ([RFC3392bis]) IANA Note See RFC-Editor note for instructions on the new registry. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From ksuwildcans@abspc.com Wed Jan 14 11:36:38 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B030C3A6A33 for ; Wed, 14 Jan 2009 11:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.35 X-Spam-Level: X-Spam-Status: No, score=-15.35 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+Hc9w1qlSTw for ; Wed, 14 Jan 2009 11:36:38 -0800 (PST) Received: from amd.com (unknown [41.196.141.47]) by core3.amsl.com (Postfix) with SMTP id D1B803A6A13 for ; Wed, 14 Jan 2009 11:36:32 -0800 (PST) To: Subject: Survey results From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114193634.D1B803A6A13@core3.amsl.com> Date: Wed, 14 Jan 2009 11:36:32 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 39776
From majordomo@abfas.com Thu Jan 15 07:20:35 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B4628C264 for ; Thu, 15 Jan 2009 07:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.416 X-Spam-Level: X-Spam-Status: No, score=-15.416 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_AT=0.424, HELO_EQ_CPE=0.5, HOST_EQ_AT=0.745, HOST_EQ_CPE=0.979, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41a+oFvcRSdy for ; Thu, 15 Jan 2009 07:20:29 -0800 (PST) Received: from cpe90-146-27-69.liwest.at (cpe90-146-27-69.liwest.at [90.146.27.69]) by core3.amsl.com (Postfix) with SMTP id A559328C25C for ; Thu, 15 Jan 2009 07:20:27 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090115152028.A559328C25C@core3.amsl.com> Date: Thu, 15 Jan 2009 07:20:27 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 75614
From idr-bounces@ietf.org Wed Jan 21 01:58:03 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19E83A6A4A; Wed, 21 Jan 2009 01:58:03 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9C83A68EC for ; Wed, 21 Jan 2009 01:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdisAK2rY51q for ; Wed, 21 Jan 2009 01:58:00 -0800 (PST) Received: from mx01.eng.pipex.net (mx01.eng.pipex.net [212.241.168.204]) by core3.amsl.com (Postfix) with ESMTP id A752B3A68CC for ; Wed, 21 Jan 2009 01:58:00 -0800 (PST) Received: from bronze.eng.gxn.net (bronze.eng.gxn.net [212.241.168.68]) by mx01.eng.pipex.net (8.13.8/8.11.2) with ESMTP id n0L9vgXN012632 for ; Wed, 21 Jan 2009 09:57:42 GMT X-Envelope-From: rjs@eng.gxn.net Received: (from rjs@localhost) by bronze.eng.gxn.net (8.13.1/8.13.1) id n0L9vfuC010597 for idr@ietf.org; Wed, 21 Jan 2009 09:57:41 GMT X-Authentication-Warning: bronze.eng.gxn.net: rjs set sender to rjs@eng.gxn.net using -f Date: Wed, 21 Jan 2009 09:57:41 +0000 From: Rob Shakir To: idr@ietf.org Message-ID: <20090121095741.GA5577@bronze.eng.gxn.net> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mx01.eng.pipex.net [212.241.168.204]); Wed, 21 Jan 2009 09:57:42 +0000 (GMT) Subject: [Idr] Operational Recommendations on Handling Invalid AS4_PATH Attributes X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org As discussed on the IETF IDR list last month, there are concerns relating to the treatment of AS_CONFED_SET/SEQUENCE in AS4_PATH as described in RFC4893 [0]. Since the last post to that thread the situation has been made more urgent with the release of Cisco IOS 12.0(32)S12, which responds to malformed AS4_PATH attributes by sending a NOTIFICATION to the neighbour, and tearing down the BGP adjacency. This behaviour seems to be required by RFC4721 section 6.3, as there is no alternative error handling defined in RFC4893. As posted last Friday [1], and discussed on the IDR list, this strict implementation introduces a new attack vector by which a BGP session can be torn down due to a an attribute populated by a distant BGP neighbour. These malformed attributes have already been seen in the wild as a result of a error in Juniper's implementation of RFC4893. Following discussions with a number of operators, we have attempted to generate some recommendations relating to the behaviour that would be operationally most useful when treating the invalid data in the AS4_PATH optional transitive attribute. There are two cases to consider when an invalid AS4_PATH is received: (1) A path to the prefix is not already known from that neighbour. (2) A path to the prefix has already been learnt from that neighbour; In case (1) we recommend that the BGP speaker should discard the UPDATE and log the fact. The log entry should include the received AS_PATH and AS4_PATH to aid in debugging. In case (2) we recommend that the BGP speaker should treat the UPDATE as a withdrawal of existing path to the prefix. As per case (1) a log entry should be raised to indicate that this has occurred. It is quite possible that in both cases this behaviour may result in the BGP speaker no longer having a valid path to the destination. We foresee that this lack of a prefix in a BGP speaker's routing table may cause some operational load initially, however, we feel that this is acceptable, considering the alternate behaviours. Should a prefix be injected into the global table with an invalid AS4_PATH, and should the newly advertised (invalid) path be selected by all upstreams available to a given ASN then this ASN will lose reachability to the prefix. Whilst this can be abused we do not see this as more serious than the existing possibility of malicious injection and blackholing of a prefix by a 3rd party. As long as the rejection of paths due to invalid AS4_PATHs is clearly reported to the administrator the source of the problem can be clearly identified. We consider that attempting to extract a valid AS4 or AS_PATH from the invalid UPDATE is a mistake since this allows the propagation of invalid BGP data. In addition, incorrect implementation of this comparatively complex mechanism by a vendor may result in loops. By explicitly not installing prefixes with invalid AS_PATH or AS4_PATH into the routing table, the possibility of loops caused by these invalid paths is avoided. The defined behaviour in RFC4893 and RFC4271 has significantly harmful effects and it seems only by virtue of the fact that the implementations of many vendors do not strictly comply with the RFCs that this problem has not had the same impact for every vendor. At the current time, however, one cannot deploy a 4-byte capable Cisco IOS device, or an OpenBGP (current stable release) router into the global table, without risking teardown of a every session via which a global table is learnt. Further discussion of this issue would be much appreciated, as a common and consistent approach to rectifying the problem will benefit network operators far more than individual vendor implementing their own solution. Should a consensus be reached an update to the RFC is required in order to ensure that future implementations do not exhibit this harmful behaviour. Kind regards, Andy Davidson (NetSumo), andy.davidson@netsumo.com Jonathan Oddy (HostWay), jonathan.oddy@hostway.co.uk Rob Shakir (GX Networks), rjs@eng.gxn.net [0]: http://www.ietf.org/mail-archive/web/idr/current/msg03368.html [1]: http://www.merit.edu/mail.archives/nanog/msg14345.html Many thanks to David Freedman (Claranet) for assistance in developing the recommendations in this document. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From krissland@aegiscomputer.com Wed Jan 21 03:47:41 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA9428C116 for ; Wed, 21 Jan 2009 03:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.204 X-Spam-Level: X-Spam-Status: No, score=-17.204 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_PH_SUBJ_META=0, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT15F50GypEQ for ; Wed, 21 Jan 2009 03:47:40 -0800 (PST) Received: from 62.42.126.90.dyn.user.ono.com (62.42.126.90.dyn.user.ono.com [62.42.126.90]) by core3.amsl.com (Postfix) with SMTP id 46BD928C113 for ; Wed, 21 Jan 2009 03:47:33 -0800 (PST) To: Subject: Your payment has been sent From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121114734.46BD928C113@core3.amsl.com> Date: Wed, 21 Jan 2009 03:47:33 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.segmentanimal.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://segmentanimal.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 5, B426. 356 Clements Road. London. SE81 7DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From ncamadrid@4dcsi.com Wed Jan 21 07:14:13 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6AF128C0F2 for ; Wed, 21 Jan 2009 07:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.732 X-Spam-Level: X-Spam-Status: No, score=-22.732 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBDLTpHckBCa for ; Wed, 21 Jan 2009 07:14:10 -0800 (PST) Received: from airlux.pt (unknown [189.51.59.56]) by core3.amsl.com (Postfix) with SMTP id 0AB2A28C0EC for ; Wed, 21 Jan 2009 07:13:58 -0800 (PST) To: Subject: Welcome to eBay! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121151400.0AB2A28C0EC@core3.amsl.com> Date: Wed, 21 Jan 2009 07:13:58 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.harmonydrive.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://harmonydrive.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 5, B884. 097 Clements Road. London. SE45 2DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From idr-bounces@ietf.org Wed Jan 21 08:16:39 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1761828C1EC; Wed, 21 Jan 2009 08:16:39 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCD53A68F3 for ; Wed, 21 Jan 2009 08:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GLzGisfkek3 for ; Wed, 21 Jan 2009 08:16:36 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 9DCE628C1EF for ; Wed, 21 Jan 2009 08:16:00 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9FA1533C30; Wed, 21 Jan 2009 11:15:44 -0500 (EST) Date: Wed, 21 Jan 2009 11:15:44 -0500 From: John Leslie To: Rob Shakir Message-ID: <20090121161544.GK24908@verdi> References: <20090121095741.GA5577@bronze.eng.gxn.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090121095741.GA5577@bronze.eng.gxn.net> User-Agent: Mutt/1.4.1i Cc: idr@ietf.org Subject: Re: [Idr] Operational Recommendations on Handling Invalid AS4_PATH Attributes X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Rob Shakir wrote: > > ... This behaviour seems to be required by RFC4721 section 6.3, as there > is no alternative error handling defined in RFC4893. >... > Following discussions with a number of operators, we have attempted to > generate some recommendations relating to the behaviour that would be > operationally most useful when treating the invalid data in the > AS4_PATH optional transitive attribute. I have no desire to criticize, but I think it may be helpful to step back for a moment. The _useful_ information in AS4_PATH is the 4-byte ASNs where OLD speakers must place AS_TRANS. We might consider whether that information is useful in cases where RFC4893's algorithm produces invalid data. (I frankly doubt we have found all possible cases yet.) I can imagine a treatment where we abandon the 4893 algorithm and simply substitute 4-byte ASNs for AS_TRANS in the AS_PATH received from an OLD speaker. This would preserve loop-detection for 4-byte ASNs while matching other characteristics of the NLRI received from our OLD peer. Obviously this would be better than tearing down the session with our OLD peer; the question is, would it be better than discarding the new NLRI? -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jan 23 00:00:05 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02FAB28C13B; Fri, 23 Jan 2009 00:00:05 -0800 (PST) X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D467C3A68F5; Fri, 23 Jan 2009 00:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090123080001.D467C3A68F5@core3.amsl.com> Date: Fri, 23 Jan 2009 00:00:01 -0800 (PST) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-flow-spec-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Dissemination of flow specification rules Author(s) : P. Roque Marques, et al. Filename : draft-ietf-idr-flow-spec-04.txt Pages : 21 Date : 2009-01-18 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-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-idr-flow-spec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-22234947.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/idr --NextPart-- From oms@123multimedia.com Sat Jan 24 11:37:23 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9413A6942 for ; Sat, 24 Jan 2009 11:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -37.225 X-Spam-Level: X-Spam-Status: No, score=-37.225 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODVY+s54Fnlf for ; Sat, 24 Jan 2009 11:37:22 -0800 (PST) Received: from aldebarana.tk (unknown [92.45.219.206]) by core3.amsl.com (Postfix) with SMTP id 462F43A67FA for ; Sat, 24 Jan 2009 11:37:20 -0800 (PST) To: Subject: Mail could not be delivered From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124193721.462F43A67FA@core3.amsl.com> Date: Sat, 24 Jan 2009 11:37:20 -0800 (PST)

Having trouble viewing this email? Click here to view as a webpage.

Best prices! Go to Our Site!

This email was sent to:

This email was sent by: Canadian Internet Services, Inc.
8154 Amphitheatre Parkway, Mountain View, CA, 19190, USA.


We respect your right to privacy - view our policy

Manage Subscriptions | Update Profile | One-Click Unsubscribe
From maysbill.mays@alliedpickfords-bg.com Sat Jan 24 11:38:47 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C21E3A69E4 for ; Sat, 24 Jan 2009 11:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.179 X-Spam-Level: X-Spam-Status: No, score=-32.179 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCDEZY3aECqo for ; Sat, 24 Jan 2009 11:38:46 -0800 (PST) Received: from akzonobel.com (unknown [189.110.246.40]) by core3.amsl.com (Postfix) with SMTP id 7529D3A6AF4 for ; Sat, 24 Jan 2009 11:38:43 -0800 (PST) To: Subject: Receipt for Your Payment From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124193844.7529D3A6AF4@core3.amsl.com> Date: Sat, 24 Jan 2009 11:38:43 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.funintuition.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://funintuition.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 5, B543. 886 Clements Road. London. SE54 9DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From idr-bounces@ietf.org Sat Jan 24 13:19:31 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061193A6AEC; Sat, 24 Jan 2009 13:19:31 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47D03A6908 for ; Sat, 24 Jan 2009 13:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj2QIVeeqpfx for ; Sat, 24 Jan 2009 13:19:28 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CD0FE3A685C for ; Sat, 24 Jan 2009 13:19:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,318,1231113600"; d="eml'208?txt'208,208?scan'208,208,208";a="130847379" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 24 Jan 2009 21:19:12 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0OLJBmU018887; Sat, 24 Jan 2009 13:19:11 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0OLJBYb022874; Sat, 24 Jan 2009 21:19:11 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jan 2009 13:19:09 -0800 Received: from [10.21.115.14] ([10.21.115.14]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jan 2009 13:19:09 -0800 Message-ID: <497B85CC.4010302@cisco.com> Date: Sat, 24 Jan 2009 13:19:08 -0800 From: Enke Chen User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: idr Content-Type: multipart/mixed; boundary="------------010305050005090106020806" X-OriginalArrivalTime: 24 Jan 2009 21:19:09.0271 (UTC) FILETIME=[6548DE70:01C97E69] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6211; t=1232831951; x=1233695951; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20[Fwd=3A=20I-D=20Action=3Adraft-chen-rfc4893bis- 00.txt] |Sender:=20; bh=KzO+G4ElUZ1ySGnycW6Noxdu0qeyZGLtkQBAIrVvkwQ=; b=Ex3PuhJiHmp18chWgWjaRqEcOoWxuiLV6MmQbjESm78biLbl+NjSibN3cK fVYA+/o8WeVslZEKjadFdypANwi3zxTZ52IGcFXZyRXXKpbxIBGdQv2TZN6O Z7QV9YsLZr; Authentication-Results: sj-dkim-3; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: quaizar.vohra@gmail.com Subject: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --------------010305050005090106020806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, folks: The changes from RFC 4893 are summarized in the Appendix of the draft: This document clarifies the handling of the confederation path segments in the AS4_PATH attribute, and also specifies the error handling for the new attributes. The following are the specific additions: ----------------------- 3. Protocol Extensions A NEW BGP speaker SHOULD NOT send these path segment types in the AS4_PATH attribute of an UPDATE message. A NEW BGP speaker that receives these path segment types in the AS4_PATH attribute of an UPDATE message MUST discard these path segments, adjust the relevant attribute fields accordingly, and continue processing the UPDATE message. 6. Error Handling When a NEW BGP speaker encounters an error (other than the invalid confederation path segment types described previously) in parsing the AS4_PATH attribute or the AS4_AGGREGATOR attribute of an UPDATE message, the speaker MUST discard the attribute in error, and continue processing the UPDATE message. The error SHOULD be logged locally for analysis. 9. Security Considerations It is a misconfiguration to assign a non-mappable 4-octet AS number as the "Member AS Number" in a BGP confederation before all the BGP speakers within the confederation have transitioned to support 4- octet AS numbers. Such a misconfiguration would weaken the AS path loop detection within a confederation. ----------------------------- Your comments are welcome and appreciated. Thanks. -- Enke --------------010305050005090106020806 Content-Type: message/rfc822; name="I-D Action:draft-chen-rfc4893bis-00.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D Action:draft-chen-rfc4893bis-00.txt.eml" Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xmb-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jan 2009 13:02:09 -0800 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jan 2009 13:02:08 -0800 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 24 Jan 2009 21:02:08 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0OL28wf005549; Sat, 24 Jan 2009 13:02:08 -0800 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0OL26ZI017228; Sat, 24 Jan 2009 21:02:08 GMT X-from-outside-Cisco: 64.170.98.32 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYBAB8Qe0lAqmIgk2dsb2JhbACSVCl/AQEBAQkJCgkRBbRrhUw X-IronPort-AV: E=Sophos;i="4.37,318,1231113600"; d="txt'208?scan'208,208";a="83821388" Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-f.cisco.com with ESMTP; 24 Jan 2009 21:02:07 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A94C28C130; Sat, 24 Jan 2009 13:00:04 -0800 (PST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7F5E93A67D9; Sat, 24 Jan 2009 13:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-chen-rfc4893bis-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090124210001.7F5E93A67D9@core3.amsl.com> Date: Sat, 24 Jan 2009 13:00:01 -0800 (PST) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org Authentication-Results: sj-dkim-1; header.From=Internet-Drafts@ietf.org; dkim=neutral Return-Path: i-d-announce-bounces@ietf.org X-OriginalArrivalTime: 24 Jan 2009 21:02:08.0759 (UTC) FILETIME=[05031870:01C97E67] --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP Support for Four-octet AS Number Space Author(s) : Q. Vohra, E. Chen Filename : draft-chen-rfc4893bis-00.txt Pages : 10 Date : 2009-01-24 Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-rfc4893bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-chen-rfc4893bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-24125551.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------010305050005090106020806 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://www.ietf.org/mailman/listinfo/idr --------------010305050005090106020806-- From loke@aeat.es Sat Jan 24 22:27:24 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DDFD3A68A4 for ; Sat, 24 Jan 2009 22:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.186 X-Spam-Level: X-Spam-Status: No, score=-20.186 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SUBJ_YOUR_DEBT=2.622, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dnAJFKlh9Am for ; Sat, 24 Jan 2009 22:27:23 -0800 (PST) Received: from host7-50-static.28-87-b.business.telecomitalia.it (host7-50-static.28-87-b.business.telecomitalia.it [87.28.50.7]) by core3.amsl.com (Postfix) with SMTP id 81D703A677D for ; Sat, 24 Jan 2009 22:27:21 -0800 (PST) To: Subject: Administrator: 7 days to save your credit From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090125062722.81D703A677D@core3.amsl.com> Date: Sat, 24 Jan 2009 22:27:21 -0800 (PST)

Having trouble viewing this email? Click here to view as a webpage.

Best prices! Go to Our Site!

This email was sent to:

This email was sent by: Canadian Internet Services, Inc.
7505 Amphitheatre Parkway, Mountain View, CA, 74070, USA.


We respect your right to privacy - view our policy

Manage Subscriptions | Update Profile | One-Click Unsubscribe
From idr-bounces@ietf.org Mon Jan 26 10:49:16 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE9A28C13B; Mon, 26 Jan 2009 10:49:16 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F3028C13B for ; Mon, 26 Jan 2009 10:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8IJdlRJ4cAn for ; Mon, 26 Jan 2009 10:49:14 -0800 (PST) Received: from mx01.eng.pipex.net (mx01.eng.pipex.net [212.241.168.204]) by core3.amsl.com (Postfix) with ESMTP id E536728C105 for ; Mon, 26 Jan 2009 10:49:13 -0800 (PST) Received: from bronze.eng.gxn.net (bronze.eng.gxn.net [212.241.168.68]) by mx01.eng.pipex.net (8.13.8/8.11.2) with ESMTP id n0QImpg6007448; Mon, 26 Jan 2009 18:48:51 GMT X-Envelope-From: rjs@eng.gxn.net Received: (from rjs@localhost) by bronze.eng.gxn.net (8.13.1/8.13.1) id n0QImoYd015557; Mon, 26 Jan 2009 18:48:50 GMT X-Authentication-Warning: bronze.eng.gxn.net: rjs set sender to rjs@eng.gxn.net using -f Date: Mon, 26 Jan 2009 18:48:50 +0000 From: Rob Shakir To: Enke Chen Message-ID: <20090126184849.GA23929@bronze.eng.gxn.net> References: <497B85CC.4010302@cisco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <497B85CC.4010302@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mx01.eng.pipex.net [212.241.168.204]); Mon, 26 Jan 2009 18:48:52 +0000 (GMT) Cc: idr , quaizar.vohra@gmail.com Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Sat, Jan 24, 2009 at 01:19:08PM -0800, Enke Chen wrote: > 3. Protocol Extensions > > A NEW BGP speaker SHOULD NOT send these path segment > types in the AS4_PATH attribute of an UPDATE message. A NEW BGP > speaker that receives these path segment types in the AS4_PATH > attribute of an UPDATE message MUST discard these path segments, > adjust the relevant attribute fields accordingly, and continue > processing the UPDATE message. Enke, Thanks for following up on this matter. I appreciate that stripping the confederation data from AS4_PATH does deal with the problem of a neighbour resetting sessions due to an invalid optional transitive attribute, I am not entirely convinced that it is the best way to handle invalid data in AS4_PATH. I understand from the current RFC that if we have a broken set of paths where the AS4_PATH contains a conferation sequence, but this information has been stripped from the AS_PATH and replaced with the confederation identifier, then we will retain loop-prevention (due to the fact that the confed ID will be one of the AS numbers that is prepended to the AS_PATH during AS4_PATH-AS_PATH reconciliation). Hence, by not discarding the update, and merely stripping the invalid data then we do keep the required underlying functionality. However, this does introduce some complexity into the implementation of this standard, we must ensure to strip the correct elements from the AS4_PATH. Whilst this should not be a matter of great importance - some implementors do not produce standards-compliant behaviour (see the cause of the session resets that we observed when connecting to the global table). I am interested to hear whether you envisage problems being caused by incorrect data being stripped from the AS4_PATH and hence result in routing information (which was present) being lost? One possibility of this would be in AS_SET and AS_SEQUENCE being stripped from the AS4_PATH (a feasible bug in an implementation of this new behaviour). The other concern that I have is that if some BGP neighbour does not implement the standard correctly, to what extent can the routing information produced by and propagated through this neighbour be trusted? One of the advantages of the approach that we suggested on the IDR list, in my eyes, was the fact that when routing information is 'corrupted' by the insertion of invalid data into an attribute, the receiver chooses to not use this routing data. Operationally, I feel that this behaviour is advantageous, since those paths that contain incorrect information have a penalty placed against them. > 6. Error Handling > > When a NEW BGP speaker encounters an error (other than the invalid > confederation path segment types described previously) in parsing the > AS4_PATH attribute or the AS4_AGGREGATOR attribute of an UPDATE > message, the speaker MUST discard the attribute in error, and > continue processing the UPDATE message. The error SHOULD be logged > locally for analysis. I appreciate this addition. Given this error, and the possibility for further problems, there is definitely a requirement for a well defined method of dealing with errors during the transition to 4-byte AS numbers, where these optional transitive elements have the possibility to propagate far from the source without any validation. I would be very interested in your comments as to why it is felt that stripping the invalid elements from the AS4_PATH attribute is a better solution than the alternative we proposed to the IDR list last week. Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jan 26 11:15:03 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7623A68B8; Mon, 26 Jan 2009 11:15:03 -0800 (PST) X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 432DB3A68B8; Mon, 26 Jan 2009 11:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090126191501.432DB3A68B8@core3.amsl.com> Date: Mon, 26 Jan 2009 11:15:01 -0800 (PST) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-as4octet-extcomm-generic-subtype-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Generic Subtype for BGP Four-octet AS specific extended community Author(s) : D. Rao, et al. Filename : draft-ietf-idr-as4octet-extcomm-generic-subtype-00.txt Pages : 6 Date : 2009-01-26 Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4octet-extcomm-generic-subtype-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-idr-as4octet-extcomm-generic-subtype-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-26110051.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Mon Jan 26 15:15:40 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC0C3A6AAA; Mon, 26 Jan 2009 15:15:40 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C962928C163 for ; Mon, 26 Jan 2009 15:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ace1rcjuHCfX for ; Mon, 26 Jan 2009 15:15:38 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5253F3A6953 for ; Mon, 26 Jan 2009 15:15:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,327,1231113600"; d="scan'208";a="125856183" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2009 23:15:21 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0QNFL5A021450; Mon, 26 Jan 2009 15:15:21 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0QNFKpf000889; Mon, 26 Jan 2009 23:15:21 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 15:15:20 -0800 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 15:15:20 -0800 Message-ID: <497E4408.8060303@cisco.com> Date: Mon, 26 Jan 2009 15:15:20 -0800 From: Enke Chen User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Rob Shakir References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> In-Reply-To: <20090126184849.GA23929@bronze.eng.gxn.net> X-OriginalArrivalTime: 26 Jan 2009 23:15:20.0551 (UTC) FILETIME=[F5514770:01C9800B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5747; t=1233011721; x=1233875721; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20[Idr]=20[Fwd=3A=20I-D=20Action=3Adraft- chen-rfc4893bis-00.txt] |Sender:=20; bh=zRrvT1uMNtshoYcX14k8if9eSYQP7WCnWWAkLEEQSJU=; b=tkg4UFzGma9T5vnQJp+CzvEGH1p6pNpsvj3B/MUAo1R/e/TbjGTXcQiDRi vaZyHZ0LogdVDFOHyXqGr/+gU5YpfZbPGC8CQf3DLyFeQZxYBnuRH9bXCA04 vEB2Xon6LqSi/glDG8LQL6O0Et4pim83/n08ZHlh8PHhbgTp7fmbU=; Authentication-Results: sj-dkim-1; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: idr , quaizar.vohra@gmail.com Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi, Rob: Please see my comments inlined. Rob Shakir wrote: > On Sat, Jan 24, 2009 at 01:19:08PM -0800, Enke Chen wrote: > >> 3. Protocol Extensions >> >> A NEW BGP speaker SHOULD NOT send these path segment >> types in the AS4_PATH attribute of an UPDATE message. A NEW BGP >> speaker that receives these path segment types in the AS4_PATH >> attribute of an UPDATE message MUST discard these path segments, >> adjust the relevant attribute fields accordingly, and continue >> processing the UPDATE message. >> > > Enke, > > Thanks for following up on this matter. > > I appreciate that stripping the confederation data from AS4_PATH does deal with > the problem of a neighbour resetting sessions due to an invalid optional > transitive attribute, I am not entirely convinced that it is the best way to > handle invalid data in AS4_PATH. > > I understand from the current RFC that if we have a broken set of paths where > the AS4_PATH contains a conferation sequence, but this information has been > stripped from the AS_PATH and replaced with the confederation identifier, then > we will retain loop-prevention (due to the fact that the confed ID will be one > of the AS numbers that is prepended to the AS_PATH during AS4_PATH-AS_PATH > reconciliation). Hence, by not discarding the update, and merely stripping the > invalid data then we do keep the required underlying functionality. > > However, this does introduce some complexity into the implementation of this > standard, we must ensure to strip the correct elements from the AS4_PATH. Whilst > this should not be a matter of great importance - some implementors do not > produce standards-compliant behaviour (see the cause of the session resets that > we observed when connecting to the global table). I am interested to hear > whether you envisage problems being caused by incorrect data being stripped from > the AS4_PATH and hence result in routing information (which was present) being > lost? One possibility of this would be in AS_SET and AS_SEQUENCE being stripped > from the AS4_PATH (a feasible bug in an implementation of this new behaviour). > Stripping the confed path segments is pretty straightforward. IMO an implementation that can deal with the merge of AS_PATH and AS4_PATH should have no difficult in implementing the stripping. > The other concern that I have is that if some BGP neighbour does not implement > the standard correctly, to what extent can the routing information produced by > and propagated through this neighbour be trusted? One of the advantages of the > approach that we suggested on the IDR list, in my eyes, was the fact that when > routing information is 'corrupted' by the insertion of invalid data into an > attribute, the receiver chooses to not use this routing data. Operationally, I > feel that this behaviour is advantageous, since those paths that contain > incorrect information have a penalty placed against them. > This seems to be a perfect case to follow the time-tested principle "Be liberal in what you accept". It is a recoverable, non-fatal error. There is no need to use any disruptive procedures. > >> 6. Error Handling >> >> When a NEW BGP speaker encounters an error (other than the invalid >> confederation path segment types described previously) in parsing the >> AS4_PATH attribute or the AS4_AGGREGATOR attribute of an UPDATE >> message, the speaker MUST discard the attribute in error, and >> continue processing the UPDATE message. The error SHOULD be logged >> locally for analysis. >> > > I appreciate this addition. Given this error, and the possibility for further > problems, there is definitely a requirement for a well defined method of dealing > with errors during the transition to 4-byte AS numbers, where these optional > transitive elements have the possibility to propagate far from the source > without any validation. > > Thanks. That is exactly the objective of the new section. > I would be very interested in your comments as to why it is felt that stripping > the invalid elements from the AS4_PATH attribute is a better solution than the > alternative we proposed to the IDR list last week. > Here is an excerpt of your proposal posted to the IDR mailing list last week: ----------------------------------- There are two cases to consider when an invalid AS4_PATH is received: (1) A path to the prefix is not already known from that neighbour. (2) A path to the prefix has already been learnt from that neighbour; In case (1) we recommend that the BGP speaker should discard the UPDATE and log the fact. The log entry should include the received AS_PATH and AS4_PATH to aid in debugging. In case (2) we recommend that the BGP speaker should treat the UPDATE as a withdrawal of existing path to the prefix. As per case (1) a log entry should be raised to indicate that this has occurred. ------------------------------------ The proposal for (1) is incorrect from the protocol aspect. As BGP update is incremental, we can not just hold on to the old info and discard the new info. The proposal for (2) is ok from the *pure* protocol aspect, but it would cause unnecessary disruption (i.e., loss of connectivity) for this recoverable, non-fatal error. Thanks. -- Enke > Kind regards, > Rob > > -- > Rob Shakir > Network Development Engineer GX Networks/Vialtus Solutions > ddi: +44208 587 6077 mob: +44797 155 4098 > pgp: 0xc07e6deb nic-hdl: RJS-RIPE > > This email is subject to: http//www.vialtus.com/disclaimer.html > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From legal@aea.uk.com Mon Jan 26 16:19:00 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8D23A6968 for ; Mon, 26 Jan 2009 16:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.912 X-Spam-Level: X-Spam-Status: No, score=-13.912 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9r4kWTqEJCv for ; Mon, 26 Jan 2009 16:18:58 -0800 (PST) Received: from cpe-76-173-127-53.socal.res.rr.com (cpe-76-173-127-53.socal.res.rr.com [76.173.127.53]) by core3.amsl.com (Postfix) with SMTP id 234213A6849 for ; Mon, 26 Jan 2009 16:18:56 -0800 (PST) To: Subject: Fwd: Finest products From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090127001857.234213A6849@core3.amsl.com> Date: Mon, 26 Jan 2009 16:18:56 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello idr-archive

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 SASI Limited. SASi Communications S.a.r.l., 22/24 Green St, Amsterdam L5496.

SASi, SASiIn, SASiOut, SASicasts, SASi Certified, SASiMe!, SASi Pro, SASiFind, SASi Prime, SASi To Go, associated logos and the ‘S’-symbol are trademarks of SASi Limited.
From idr-bounces@ietf.org Mon Jan 26 16:50:21 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BCE23A6B10; Mon, 26 Jan 2009 16:50:21 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42E643A6B10 for ; Mon, 26 Jan 2009 16:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywl+kBpyqT4A for ; Mon, 26 Jan 2009 16:50:19 -0800 (PST) Received: from mx01.eng.pipex.net (mx01.eng.pipex.net [212.241.168.204]) by core3.amsl.com (Postfix) with ESMTP id 1BA3D3A6866 for ; Mon, 26 Jan 2009 16:50:18 -0800 (PST) Received: from bronze.eng.gxn.net (bronze.eng.gxn.net [212.241.168.68]) by mx01.eng.pipex.net (8.13.8/8.11.2) with ESMTP id n0R0nub2016537; Tue, 27 Jan 2009 00:49:56 GMT X-Envelope-From: rjs@eng.gxn.net Received: (from rjs@localhost) by bronze.eng.gxn.net (8.13.1/8.13.1) id n0R0ntU6026108; Tue, 27 Jan 2009 00:49:55 GMT X-Authentication-Warning: bronze.eng.gxn.net: rjs set sender to rjs@eng.gxn.net using -f Date: Tue, 27 Jan 2009 00:49:55 +0000 From: Rob Shakir To: Enke Chen Message-ID: <20090127004955.GA8673@bronze.eng.gxn.net> References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> <497E4408.8060303@cisco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <497E4408.8060303@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mx01.eng.pipex.net [212.241.168.204]); Tue, 27 Jan 2009 00:49:56 +0000 (GMT) Cc: idr , quaizar.vohra@gmail.com Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi Enke, Thanks for your reply. On Mon, Jan 26, 2009 at 03:15:20PM -0800, Enke Chen wrote: > Stripping the confed path segments is pretty straightforward. IMO an > implementation that can deal with the merge of AS_PATH and AS4_PATH > should have no difficult in implementing the stripping. I concur that stripping the confed path segments should be straight-forward, but I feel that considering the bugs that could be feasibly introduced through the implementation of a new standard is valuable. After all, one could say that 4893 was very clear in terms of forbidding AS_CONFED_SET/SEQUENCE from AS4_PATH, yet as we have seen here, not all implementations obeyed this. > Here is an excerpt of your proposal posted to the IDR mailing list last > week: > > ----------------------------------- > > There are two cases to consider when an invalid AS4_PATH is received: > (1) A path to the prefix is not already known from that neighbour. > (2) A path to the prefix has already been learnt from that neighbour; > In case (1) we recommend that the BGP speaker should discard the UPDATE > and log > the fact. The log entry should include the received AS_PATH and > AS4_PATH to aid in debugging. > > In case (2) we recommend that the BGP speaker should treat the UPDATE as a > withdrawal of existing path to the prefix. As per case (1) a log entry should be > raised to indicate that this has occurred. > > ------------------------------------ > > The proposal for (1) is incorrect from the protocol aspect. As BGP > update is incremental, we can not just hold on to the old info and > discard the new info. > > The proposal for (2) is ok from the *pure* protocol aspect, but it would > cause unnecessary disruption (i.e., loss of connectivity) for this > recoverable, non-fatal error. In the case of (1), there is no old information to hold onto. (1) handles the case whereby a neighbour hands us a new prefix. At the time we receive this prefix, we have no path in any RIB that would provide us reachability to the prefix via that neighbour. Hence, when we parse the UPDATE message and find that there is an invalid AS4_PATH in it, we choose to not treat this path as valid, and not add it to any RIB. This ties back to my previous comment that we should perhaps penalise those paths to prefixes which contain invalid routing information. Combining your comments on (2), and earlier comments - one can be liberal in terms of accepting any prefix to a neighbour, however, if we have a 4-byte ASN in the path that is manipulating routing data that is important to it (i.e. AS4_PATH) incorrectly, should we not treat this as we treat invalid data in the AS_PATH? I believe our suggested approach (treating the UPDATE as WITHDRAWL) is closer to how rfc4893 currently deals with the invalid data, but takes into account the optional transitive nature of AS4_PATH. Is the intended behaviour to be permissive in handling invalid AS4_PATH data where we are not so with AS_PATH? It is worth considering that the loss of connectivity is only to a prefix that has no valid method of propagating itself via RFC-compliant BGP speakers. Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jan 26 17:08:24 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09743A6A00; Mon, 26 Jan 2009 17:08:23 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA93E3A6A00 for ; Mon, 26 Jan 2009 17:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Abokc2idd-YK for ; Mon, 26 Jan 2009 17:08:21 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 43A433A6403 for ; Mon, 26 Jan 2009 17:08:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,328,1231113600"; d="scan'208";a="133778748" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2009 01:08:03 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0R183LC031983; Mon, 26 Jan 2009 17:08:03 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0R183VU003381; Tue, 27 Jan 2009 01:08:03 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 17:08:01 -0800 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 17:08:01 -0800 Message-ID: <497E5E71.3020307@cisco.com> Date: Mon, 26 Jan 2009 17:08:01 -0800 From: Enke Chen User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Rob Shakir References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> <497E4408.8060303@cisco.com> <20090127004955.GA8673@bronze.eng.gxn.net> In-Reply-To: <20090127004955.GA8673@bronze.eng.gxn.net> X-OriginalArrivalTime: 27 Jan 2009 01:08:01.0705 (UTC) FILETIME=[B3478190:01C9801B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4227; t=1233018483; x=1233882483; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20[Idr]=20[Fwd=3A=20I-D=20Action=3Adraft- chen-rfc4893bis-00.txt] |Sender:=20; bh=Bewrl5K1M1bUckKjws3Ne0e6J2OFIywkMD8/wvS90I8=; b=aFU5tnMbK0hEzKweflDCdWbG9ScN/YOG7Tn7HFqYuDSh2vJngcPNGqFo+i IzhB3apo0T0jZXJ6a4pYW2M+i2sPoyHqJwxBquDtOP/doKw8xSwUqyZ3lJMt FInn347om7; Authentication-Results: sj-dkim-2; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: idr , quaizar.vohra@gmail.com Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi, Rob: Rob Shakir wrote: > Hi Enke, > > Thanks for your reply. > > On Mon, Jan 26, 2009 at 03:15:20PM -0800, Enke Chen wrote: > >> Stripping the confed path segments is pretty straightforward. IMO an >> implementation that can deal with the merge of AS_PATH and AS4_PATH >> should have no difficult in implementing the stripping. >> > > I concur that stripping the confed path segments should be straight-forward, but > I feel that considering the bugs that could be feasibly introduced through the > implementation of a new standard is valuable. After all, one could say that 4893 > was very clear in terms of forbidding AS_CONFED_SET/SEQUENCE from AS4_PATH, yet > as we have seen here, not all implementations obeyed this. > > >> Here is an excerpt of your proposal posted to the IDR mailing list last >> week: >> >> ----------------------------------- >> >> There are two cases to consider when an invalid AS4_PATH is received: >> (1) A path to the prefix is not already known from that neighbour. >> (2) A path to the prefix has already been learnt from that neighbour; >> In case (1) we recommend that the BGP speaker should discard the UPDATE >> and log >> the fact. The log entry should include the received AS_PATH and >> AS4_PATH to aid in debugging. >> >> In case (2) we recommend that the BGP speaker should treat the UPDATE as a >> withdrawal of existing path to the prefix. As per case (1) a log entry should be >> raised to indicate that this has occurred. >> >> ------------------------------------ >> >> The proposal for (1) is incorrect from the protocol aspect. As BGP >> update is incremental, we can not just hold on to the old info and >> discard the new info. >> >> The proposal for (2) is ok from the *pure* protocol aspect, but it would >> cause unnecessary disruption (i.e., loss of connectivity) for this >> recoverable, non-fatal error. >> > > In the case of (1), there is no old information to hold onto. > (1) handles the > case whereby a neighbour hands us a new prefix. At the time we receive this > prefix, we have no path in any RIB that would provide us reachability to the > prefix via that neighbour. Hence, when we parse the UPDATE message and find that > there is an invalid AS4_PATH in it, we choose to not treat this path as valid, > and not add it to any RIB. This ties back to my previous comment that we should > perhaps penalise those paths to prefixes which contain invalid routing > information. > Apologies that I did not read your message carefully (missed "not"). Then (1) and (2) is really the same - treat the update as a withdraw. > Combining your comments on (2), and earlier comments - one can be liberal in > terms of accepting any prefix to a neighbour, however, if we have a 4-byte ASN > in the path that is manipulating routing data that is important to it (i.e. > AS4_PATH) incorrectly, should we not treat this as we treat invalid data in the > AS_PATH? I believe our suggested approach (treating the UPDATE as WITHDRAWL) is > closer to how rfc4893 currently deals with the invalid data, but takes into > account the optional transitive nature of AS4_PATH. Is the intended behaviour > to be permissive in handling invalid AS4_PATH data where we are not so with > AS_PATH? It is worth considering that the loss of connectivity is only to a > prefix that has no valid method of propagating itself via RFC-compliant BGP > speakers. > The particular error involves "over supply of information" which can be repaired by removing the unnecessary information. At the risk of repeating myself, this is a recoverable, non-fatal error. The time-tested principle of "be liberal in what you accept" is precisely for dealing with this kind of non-fatal errors in protocol design. Thanks. -- Enke > Kind regards, > Rob > > -- > Rob Shakir > Network Development Engineer GX Networks/Vialtus Solutions > ddi: +44208 587 6077 mob: +44797 155 4098 > pgp: 0xc07e6deb nic-hdl: RJS-RIPE > > This email is subject to: http//www.vialtus.com/disclaimer.html > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jan 26 17:23:29 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42A13A68F5; Mon, 26 Jan 2009 17:23:29 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C4C3A68F5 for ; Mon, 26 Jan 2009 17:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYuujVr0bV9Y for ; Mon, 26 Jan 2009 17:23:27 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 89B343A6898 for ; Mon, 26 Jan 2009 17:23:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,328,1231113600"; d="scan'208";a="237102314" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Jan 2009 01:23:10 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0R1NAa0018321; Mon, 26 Jan 2009 17:23:10 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0R1NAwc013278; Tue, 27 Jan 2009 01:23:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 17:23:10 -0800 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 17:23:09 -0800 Message-ID: <497E61FD.5010001@cisco.com> Date: Mon, 26 Jan 2009 17:23:09 -0800 From: Enke Chen User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Rob Shakir References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> <497E4408.8060303@cisco.com> <20090127004955.GA8673@bronze.eng.gxn.net> <497E5E71.3020307@cisco.com> In-Reply-To: <497E5E71.3020307@cisco.com> X-OriginalArrivalTime: 27 Jan 2009 01:23:09.0501 (UTC) FILETIME=[D05E2ED0:01C9801D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5031; t=1233019390; x=1233883390; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20[Idr]=20[Fwd=3A=20I-D=20Action=3Adraft- chen-rfc4893bis-00.txt] |Sender:=20; bh=ribWjZpNRiIc3SXjRtF9cxMVuER2FOb8F8ybxrufJ4s=; b=QTlq79iJnp9AVGUhx3zNAXBnKeKnUhS+6LK3wnWCTUBxWPEuZXX+E/37Ca /5gJqK2ekg94k1mVHLPq4Q1uXm1LKFoqZkiv8rQIkMVCm0Ic2lqK4fp0nPbh zb/jfAtdg4; Authentication-Results: sj-dkim-2; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: idr , quaizar.vohra@gmail.com Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Rob, Regarding your comment: ---------------------------------------- It is worth considering that the loss of connectivity is only to a prefix that has no valid method of propagating itself via RFC-compliant BGP speakers. ----------------------------------------- The loss of connectivity (with your proposal) could be for all the prefixes exchanged over a session, in which case your proposal would have virtually identical effect as tearing down a session, and that is something we try to prevent with the current work. Regards, -- Enke Enke Chen wrote: > Hi, Rob: > > Rob Shakir wrote: >> Hi Enke, >> >> Thanks for your reply. >> >> On Mon, Jan 26, 2009 at 03:15:20PM -0800, Enke Chen wrote: >> >>> Stripping the confed path segments is pretty straightforward. IMO >>> an implementation that can deal with the merge of AS_PATH and >>> AS4_PATH should have no difficult in implementing the stripping. >>> >> >> I concur that stripping the confed path segments should be >> straight-forward, but >> I feel that considering the bugs that could be feasibly introduced >> through the >> implementation of a new standard is valuable. After all, one could >> say that 4893 >> was very clear in terms of forbidding AS_CONFED_SET/SEQUENCE from >> AS4_PATH, yet >> as we have seen here, not all implementations obeyed this. >> >> >>> Here is an excerpt of your proposal posted to the IDR mailing list >>> last week: >>> >>> ----------------------------------- >>> >>> There are two cases to consider when an invalid AS4_PATH is received: >>> (1) A path to the prefix is not already known from that >>> neighbour. (2) A path to the prefix has already been learnt from >>> that neighbour; In case (1) we recommend that the BGP speaker >>> should discard the UPDATE and log >>> the fact. The log entry should include the received AS_PATH and >>> AS4_PATH to aid in debugging. >>> >>> In case (2) we recommend that the BGP speaker should treat the >>> UPDATE as a >>> withdrawal of existing path to the prefix. As per case (1) a log >>> entry should be >>> raised to indicate that this has occurred. >>> >>> ------------------------------------ >>> >>> The proposal for (1) is incorrect from the protocol aspect. As BGP >>> update is incremental, we can not just hold on to the old info and >>> discard the new info. >>> >>> The proposal for (2) is ok from the *pure* protocol aspect, but it >>> would cause unnecessary disruption (i.e., loss of connectivity) for >>> this recoverable, non-fatal error. >>> >> >> In the case of (1), there is no old information to hold onto. >> (1) handles the >> case whereby a neighbour hands us a new prefix. At the time we >> receive this >> prefix, we have no path in any RIB that would provide us reachability >> to the >> prefix via that neighbour. Hence, when we parse the UPDATE message >> and find that >> there is an invalid AS4_PATH in it, we choose to not treat this path >> as valid, >> and not add it to any RIB. This ties back to my previous comment that >> we should >> perhaps penalise those paths to prefixes which contain invalid routing >> information. >> > > Apologies that I did not read your message carefully (missed "not"). > > Then (1) and (2) is really the same - treat the update as a withdraw. > >> Combining your comments on (2), and earlier comments - one can be >> liberal in >> terms of accepting any prefix to a neighbour, however, if we have a >> 4-byte ASN >> in the path that is manipulating routing data that is important to it >> (i.e. >> AS4_PATH) incorrectly, should we not treat this as we treat invalid >> data in the >> AS_PATH? I believe our suggested approach (treating the UPDATE as >> WITHDRAWL) is >> closer to how rfc4893 currently deals with the invalid data, but >> takes into >> account the optional transitive nature of AS4_PATH. Is the intended >> behaviour >> to be permissive in handling invalid AS4_PATH data where we are not >> so with >> AS_PATH? It is worth considering that the loss of connectivity is >> only to a >> prefix that has no valid method of propagating itself via >> RFC-compliant BGP >> speakers. >> > > The particular error involves "over supply of information" which can > be repaired by removing the unnecessary information. At the risk of > repeating myself, this is a recoverable, non-fatal error. The > time-tested principle of "be liberal in what you accept" is precisely > for dealing with this kind of non-fatal errors in protocol design. > > Thanks. -- Enke > >> Kind regards, >> Rob >> >> -- >> Rob Shakir >> Network Development Engineer GX Networks/Vialtus Solutions >> ddi: +44208 587 6077 mob: +44797 155 4098 >> pgp: 0xc07e6deb nic-hdl: RJS-RIPE >> >> This email is subject to: http//www.vialtus.com/disclaimer.html >> > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From numan@accedoconsulting.com Tue Jan 27 03:49:25 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C9CD3A6861 for ; Tue, 27 Jan 2009 03:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.593 X-Spam-Level: X-Spam-Status: No, score=-22.593 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poiNcazEUZJg for ; Tue, 27 Jan 2009 03:49:22 -0800 (PST) Received: from pdkkarolykrt1.dravanet.hu (pdkkarolykrt1.dravanet.hu [212.40.80.202]) by core3.amsl.com (Postfix) with SMTP id 1DFBE3A67D0 for ; Tue, 27 Jan 2009 03:49:20 -0800 (PST) To: Subject: Payment Accepted! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090127114921.1DFBE3A67D0@core3.amsl.com> Date: Tue, 27 Jan 2009 03:49:20 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.clotheingenuity.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://clotheingenuity.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 6, B851. 444 Clements Road. London. SE75 6DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

From idr-bounces@ietf.org Tue Jan 27 08:57:38 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9BE23A6B77; Tue, 27 Jan 2009 08:57:38 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EB333A6B77 for ; Tue, 27 Jan 2009 08:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zinNZxHX3LGR for ; Tue, 27 Jan 2009 08:57:36 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [192.207.141.16]) by core3.amsl.com (Postfix) with ESMTP id 8BA403A68D2 for ; Tue, 27 Jan 2009 08:57:36 -0800 (PST) Received: from rjs by cappuccino.rob.sh with local (Exim 4.69) (envelope-from ) id 1LRrAd-0007PB-0P; Tue, 27 Jan 2009 16:52:15 +0000 Date: Tue, 27 Jan 2009 16:52:15 +0000 From: Rob Shakir To: Enke Chen Message-ID: <20090127165214.GA27486@cappuccino.rob.sh> References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> <497E4408.8060303@cisco.com> <20090127004955.GA8673@bronze.eng.gxn.net> <497E5E71.3020307@cisco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <497E5E71.3020307@cisco.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: idr , quaizar.vohra@gmail.com, Jonathan Oddy Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Mon, Jan 26, 2009 at 05:08:01PM -0800, Enke Chen wrote: > The particular error involves "over supply of information" which can be > repaired by removing the unnecessary information. At the risk of > repeating myself, this is a recoverable, non-fatal error. The > time-tested principle of "be liberal in what you accept" is precisely > for dealing with this kind of non-fatal errors in protocol design. We do not agree with your statement that this is "over supply of information" as an AS_CONFED_SET/SEQUENCE is garbage data outside of the network making use of confederations, and infact it could be considered harmful misinformation if the neighbouring network also makes use of confederations. We do, however, agree that your suggested method for handling the presence of an AS_CONFED_SET/SEQUENCE is suitable for dealing with this specific bug, and comparatively easy to implement. Fom an operational perspective, this is also probably the best way to deal with the specific case since there are a large number of JunOS devices deployed that may to continue to insert AS_CONFED_SET/SEQUENCE into AS4_PATH in the future. We therefore accept the new handling of this specific error condition as being a necessary evil. Section 6 of the new draft defines handling for a general error case with behaviour that we do not believe is safe. Considering that the AS4_PATH is mechanism for transporting unsupported AS_PATH information through a number of AS4-unaware devices we must bear in mind that there is a reconciliation process with AS_PATH. Given the role of AS_PATH in loop prevention we feel that general lax treatment of AS4_PATH may have harmful concequences in the future. We feel that the general behaviour on an error should be the withdrawal of the path, as discarding the attribute is equivalent in effect to discarding part of the AS_PATH and may cause loops. Take for example the case when an BGP speaker in a 32bit AS receiving an invalid AS4_PATH attribute. With the AS4_PATH unreadable and therefore discarded the BGP speaker cannot know if its AS number was in the path. The only loop free options are: (a) treat it as a withdrawal (b) treat any AS_TRANS in the AS_PATH as the local AS (c) drop the session. Option c is the behaviour that has led us to needing a change to the RFC, so is obviously unacceptable. Option a and b are equivalent since the AS4_PATH attribute would not be present if there wasn't an AS_TRANS in the AS_PATH. While your "be liberal in what you accept" approach is commendable, and often an excellent idea, a line does need to be drawn. We cannot and should not extend the standards with special cases every time someone makes an implementation error or we risk creating an RFC that's almost impossible to implement without making further silly mistakes. Kind regards, Jonathan Oddy (Hostway UK) Rob Shakir (GX Networks) _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 27 09:39:00 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3932828C0D6; Tue, 27 Jan 2009 09:39:00 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022DF28C105 for ; Tue, 27 Jan 2009 09:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyembdzXYx+n for ; Tue, 27 Jan 2009 09:38:58 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 3E77F28C0D6 for ; Tue, 27 Jan 2009 09:38:58 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6E5AA33C2C; Tue, 27 Jan 2009 12:38:40 -0500 (EST) Date: Tue, 27 Jan 2009 12:38:40 -0500 From: John Leslie To: Rob Shakir Message-ID: <20090127173840.GF52653@verdi> References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> <497E4408.8060303@cisco.com> <20090127004955.GA8673@bronze.eng.gxn.net> <497E5E71.3020307@cisco.com> <20090127165214.GA27486@cappuccino.rob.sh> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090127165214.GA27486@cappuccino.rob.sh> User-Agent: Mutt/1.4.1i Cc: idr Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Rob Shakir wrote: > > With the AS4_PATH unreadable and therefore discarded the BGP speaker > cannot know if its AS number was in the path. The only loop free > options are: > (a) treat it as a withdrawal > (b) treat any AS_TRANS in the AS_PATH as the local AS > (c) drop the session. > > Option c is the behaviour that has led us to needing a change to the > RFC, so is obviously unacceptable. Agreed. > Option a and b are equivalent since the AS4_PATH attribute would not be > present if there wasn't an AS_TRANS in the AS_PATH. Actually, no. Option (a) removes any possibility that you're propagating the error, at the possible expense of losing reachability to the CIDR block. Option (b) removes the possibility of a loop, keeping reachability in most cases; but does not protects BGP speakers you may pass this NLRI to. The possibility of losing reachability in option (a) is unfortunately significant, because any NEW speaker receiving this NLRI from your OLD neighbor will likewise discard it. Note particularly that the OLD speaker has done nothing wrong (unless you call failure to upgrade it to a NEW speaker) and that the NLRI you received is its honest "best" route. I prefer imlementing option (b) independently of what we do with an erroneous AS4_PATH, largely because I doubt we can catch all the cases where a bug may cause AS_TRANS to show up in a (possibly reconstructed) NLRI. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 27 11:00:00 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04273A698D; Tue, 27 Jan 2009 11:00:00 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A153A6992 for ; Tue, 27 Jan 2009 10:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKN1uz-sltY3 for ; Tue, 27 Jan 2009 10:59:57 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id B02383A67CF for ; Tue, 27 Jan 2009 10:59:57 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSX9Zl4g7iOWq2KPoy+UrwGTkgZRcwK60@postini.com; Tue, 27 Jan 2009 10:59:40 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Tue, 27 Jan 2009 10:58:27 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 10:58:27 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 10:58:26 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jan 2009 10:58:26 -0800 Received: from sa-nc-common-42.static.jnpr.net (sa-nc-common-42.static.jnpr.net [172.23.8.42]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0RIwIM05945; Tue, 27 Jan 2009 10:58:19 -0800 (PST) (envelope-from jgs@juniper.net) Message-ID: <0ABE8021-AE73-4081-A0A5-559E5A646247@juniper.net> From: "John G. Scudder" To: Rob Shakir In-Reply-To: <20090127165214.GA27486@cappuccino.rob.sh> MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 27 Jan 2009 14:58:13 -0400 References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> <497E4408.8060303@cisco.com> <20090127004955.GA8673@bronze.eng.gxn.net> <497E5E71.3020307@cisco.com> <20090127165214.GA27486@cappuccino.rob.sh> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 27 Jan 2009 18:58:26.0351 (UTC) FILETIME=[3C26C3F0:01C980B1] Cc: idr , quaizar.vohra@gmail.com, Jonathan Oddy Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Jan 27, 2009, at 12:52 PM, Rob Shakir wrote: > We feel that the general behaviour on an error should be the > withdrawal > of the path, as discarding the attribute is equivalent in effect to > discarding part of the AS_PATH and may cause loops. Take for example > the > case when an BGP speaker in a 32bit AS receiving an invalid AS4_PATH > attribute. With the AS4_PATH unreadable and therefore discarded the > BGP > speaker cannot know if its AS number was in the path. The only loop > free > options are: While intuitively obvious, this isn't correct. As long as there's no corresponding damage to the AS_PATH, the loop free property is preserved. Here's the argument: On Dec 17, 2008, at 11:52 AM, John G. Scudder wrote: > On Dec 17, 2008, at 3:13 AM, Paul Jakma wrote: >> On Tue, 16 Dec 2008, John G. Scudder wrote: >> >>> 1. All the ASes in the path are 4-byte capable, in which case the >>> issue does not exist. >>> 2. At least one AS in the path is not 4-byte capable. In that >>> case, if there is a loop it will eventually be caught by the >>> regular 2-byte AS_PATH. >>> >>> In neither case is what you describe needed, AFAICT. >> >> We're talking about the case where the AS4_PATH has been removed by >> a preceding NEW speaker though. >> >> Your 2 seems to suggest that in such paths, loop-detection should >> only be done by the OLD speakers (and NEW speakers preceding it may >> happily install the path). > > That's more or less correct, modulo the adverb :-). The point is > that as long as the loop gets broken, regardless of by whom (in this > case the OLD speaker preceding the NEW speaker which removed the > AS4_PATH), it will proceed to unwind. That is to say, it's only a > transient loop. > > Keep in mind this behavior SHOULD never be seen in the wild since > it's predicated on broken behavior along the path someplace to begin > with; with luck this is just a chalkboard exercise. I for one find > it heartening that the protocol appears to be robust even in the > face of certain types of mangling of the AS4_PATH. One may still debate whether it's preferable to "fix" the broken route by dropping the AS4_PATH or treat the broken route as a withdraw (which as you point out is effectively what your options a+b are), but if the latter is chosen it should be for some reason other than "may cause loops". --John _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 27 11:18:22 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C496B3A6ABC; Tue, 27 Jan 2009 11:18:22 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28EBF3A6ABC for ; Tue, 27 Jan 2009 11:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4t8pG+z0xOD for ; Tue, 27 Jan 2009 11:18:20 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 07C143A696B for ; Tue, 27 Jan 2009 11:18:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,333,1231113600"; d="scan'208";a="134171878" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2009 19:18:02 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0RJI2J2008745; Tue, 27 Jan 2009 11:18:02 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0RJI2Eo015694; Tue, 27 Jan 2009 19:18:02 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 11:18:02 -0800 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 11:18:01 -0800 Message-ID: <497F5DE9.7030800@cisco.com> Date: Tue, 27 Jan 2009 11:18:01 -0800 From: Enke Chen User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Rob Shakir References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> <497E4408.8060303@cisco.com> <20090127004955.GA8673@bronze.eng.gxn.net> <497E5E71.3020307@cisco.com> <20090127165214.GA27486@cappuccino.rob.sh> In-Reply-To: <20090127165214.GA27486@cappuccino.rob.sh> X-OriginalArrivalTime: 27 Jan 2009 19:18:01.0746 (UTC) FILETIME=[F8BDCF20:01C980B3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4886; t=1233083882; x=1233947882; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20[Idr]=20[Fwd=3A=20I-D=20Action=3Adraft- chen-rfc4893bis-00.txt] |Sender:=20; bh=fQq0B+RvqUfuk5Co8jNdjcDy+KTFE60GyZU2dmP7Cew=; b=F3r9IxfkC7vAq3GqK20L23XUEPJ3JFBokMaoQCGknuqjr/94ktd0OvOG0l 9mZN8vz2Pv/N3xisPXxZYfnkSooeFrhoNxzEHtgLvM8j1Ff5N7gZaOR1lgv1 uzyFs745IhaiVdlD4HXrPGjnRIgWIiK1uBwBCmicUDq9gSrbTp7CQ=; Authentication-Results: sj-dkim-1; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: idr , quaizar.vohra@gmail.com, Jonathan Oddy Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Rob, Rob Shakir wrote: > On Mon, Jan 26, 2009 at 05:08:01PM -0800, Enke Chen wrote: > >> The particular error involves "over supply of information" which can be >> repaired by removing the unnecessary information. At the risk of >> repeating myself, this is a recoverable, non-fatal error. The >> time-tested principle of "be liberal in what you accept" is precisely >> for dealing with this kind of non-fatal errors in protocol design. >> > > We do not agree with your statement that this is "over supply of > information" as an AS_CONFED_SET/SEQUENCE is garbage data outside of the > network making use of confederations, and infact it could be considered > harmful misinformation if the neighbouring network also makes use of > confederations. > > We do, however, agree that your suggested method for handling the > presence of an AS_CONFED_SET/SEQUENCE is suitable for dealing with this > specific bug, and comparatively easy to implement. Fom an operational > perspective, this is also probably the best way to deal with the > specific case since there are a large number of JunOS devices deployed > that may to continue to insert AS_CONFED_SET/SEQUENCE into AS4_PATH in > the future. > > We therefore accept the new handling of this specific error condition as > being a necessary evil. > Good. > Section 6 of the new draft defines handling for a general error case > with behaviour that we do not believe is safe. Considering that the > AS4_PATH is mechanism for transporting unsupported AS_PATH information > through a number of AS4-unaware devices we must bear in mind that there > is a reconciliation process with AS_PATH. Given the role of AS_PATH in > loop prevention we feel that general lax treatment of AS4_PATH may have > harmful concequences in the future. > > We feel that the general behaviour on an error should be the withdrawal > of the path, as discarding the attribute is equivalent in effect to > discarding part of the AS_PATH and may cause loops. Yes, indeed. A routing loop may (or may not) occur when the AS4_PATH should carry useful info but is either malformed or is absent. There is no perfect solution here. There are some tradeoffs, however, between accepting the route and rejecting the route: o rejecting the route would guarantee disruption (i.e., loss of connectivity). o accepting the route would maintain connectivity, but may (or may not) introduce a routing loop. > Take for example the > case when an BGP speaker in a 32bit AS receiving an invalid AS4_PATH > attribute. With the AS4_PATH unreadable and therefore discarded the BGP > speaker cannot know if its AS number was in the path. The only loop free > options are: > (a) treat it as a withdrawal > (b) treat any AS_TRANS in the AS_PATH as the local AS > (c) drop the session. > > Option c is the behaviour that has led us to needing a change to the > RFC, so is obviously unacceptable. > Why is Option C "obviously unacceptable"? I think the reason is that it would result in loss of connectivity for all the routes over the session, and can be used as a remote attack vehicle. In the case of a malform AS4_PATH attribute, rejecting the route would also result in the loss of connectivity, and thus can also be used as a remote attack vehicle. Considering the following factors: 1) the tradeoffs, 2) especially the concern for the remote attack, 3) AS4_PATH being optional, I believe that what is proposed in the draft (accepting the routes) is more preferred than rejecting the route. Admittedly, a malformed AS4_PATH attribute would fall into the category of inconsistency and would subject to the risks described in the document: --------------------------------------------------------------------------------------- 9. Security Considerations The inconsistency between the AS_PATH attribute and the AS4_PATH attribute can create loss of the AS path information, and potential routing loops in certain cases as discussed in the document. This could be exploited by an attacker. --------------------------------------------------------------------------------------- Regards, -- Enke > Option a and b are equivalent since the AS4_PATH attribute would not be > present if there wasn't an AS_TRANS in the AS_PATH. > > While your "be liberal in what you accept" approach is commendable, and > often an excellent idea, a line does need to be drawn. We cannot and > should not extend the standards with special cases every time someone > makes an implementation error or we risk creating an RFC that's almost > impossible to implement without making further silly mistakes. > > Kind regards, > Jonathan Oddy (Hostway UK) > Rob Shakir (GX Networks) > _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 27 11:40:18 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A683A6B17; Tue, 27 Jan 2009 11:40:18 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E101F3A6B17 for ; Tue, 27 Jan 2009 11:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6twR7p35rmfb for ; Tue, 27 Jan 2009 11:40:16 -0800 (PST) Received: from synchronicity.convergence.cx (unknown [IPv6:2001:a88:0:ffff:216:17ff:fea5:e34c]) by core3.amsl.com (Postfix) with ESMTP id 1C0913A696A for ; Tue, 27 Jan 2009 11:40:15 -0800 (PST) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.69) (envelope-from ) id 1LRtmr-0008MM-UZ; Tue, 27 Jan 2009 19:39:53 +0000 Message-ID: <497F6309.5080204@uk.clara.net> Date: Tue, 27 Jan 2009 19:39:53 +0000 From: David Freedman Organization: Claranet LImited User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 Newsgroups: gmane.ietf.idr To: Enke Chen References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> <497E4408.8060303@cisco.com> <20090127004955.GA8673@bronze.eng.gxn.net> <497E5E71.3020307@cisco.com> <20090127165214.GA27486@cappuccino.rob.sh> <497F5DE9.7030800@cisco.com> In-Reply-To: <497F5DE9.7030800@cisco.com> Cc: idr , quaizar.vohra@gmail.com, Jonathan Oddy Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > In the case of a malform AS4_PATH attribute, rejecting the route would > also result in the loss of connectivity, and thus can also be used as a > remote attack vehicle. Yes, but the attack would be constrained to all prefixes with the malformed AS4_PATH attribute and not all prefixes received over the session. > > Considering the following factors: > > 1) the tradeoffs, > 2) especially the concern for the remote attack, > 3) AS4_PATH being optional, > > I believe that what is proposed in the draft (accepting the routes) is > more preferred than rejecting the route. How about not making it mandatory to accept it? Dave. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 27 11:50:01 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0D628C1A8; Tue, 27 Jan 2009 11:50:01 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E50B28C1A8 for ; Tue, 27 Jan 2009 11:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsEamDQqnzsQ for ; Tue, 27 Jan 2009 11:50:00 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6EB3528C1A3 for ; Tue, 27 Jan 2009 11:50:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,334,1231113600"; d="scan'208";a="131323841" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 27 Jan 2009 19:49:43 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n0RJngol010322; Tue, 27 Jan 2009 11:49:42 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n0RJngcv001342; Tue, 27 Jan 2009 19:49:42 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, 27 Jan 2009 11:49:42 -0800 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 11:49:41 -0800 Message-ID: <497F6555.3070508@cisco.com> Date: Tue, 27 Jan 2009 11:49:41 -0800 From: Enke Chen User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: David Freedman References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> <497E4408.8060303@cisco.com> <20090127004955.GA8673@bronze.eng.gxn.net> <497E5E71.3020307@cisco.com> <20090127165214.GA27486@cappuccino.rob.sh> <497F5DE9.7030800@cisco.com> <497F6309.5080204@uk.clara.net> In-Reply-To: <497F6309.5080204@uk.clara.net> X-OriginalArrivalTime: 27 Jan 2009 19:49:41.0832 (UTC) FILETIME=[6547EC80:01C980B8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1000; t=1233085782; x=1233949782; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20[Fwd=3A=20I-D=20Action=3Adraft-chen-rfc 4893bis-00.txt] |Sender:=20; bh=hYCkU4YnharvRxStP0cL1MxTEF3yZepN61Lr8JKyb88=; b=tWnUPb5uZ5GMR1iG5zsWVOoLGx1UCD1NqJHitEnL3bo2fxPVDjS4NaDqy8 47AVJ9zPmZvuWea+bIgnJMXDK7UIUPeWtmMMEg4RRWf1SgKxczmsB09W1cnj TRAd/Ujt8Z; Authentication-Results: sj-dkim-4; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: idr , quaizar.vohra@gmail.com, Jonathan Oddy Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org David, David Freedman wrote: >> In the case of a malform AS4_PATH attribute, rejecting the route would >> also result in the loss of connectivity, and thus can also be used as a >> remote attack vehicle. >> > > Yes, but the attack would be constrained to all prefixes with the > malformed AS4_PATH attribute and not all prefixes received over the session. > All the prefixes could have the malformed AS4_PATH attribute (from a remote router). In that case, rejecting the routes has the same effect as tearing down the session. > >> Considering the following factors: >> >> 1) the tradeoffs, >> 2) especially the concern for the remote attack, >> 3) AS4_PATH being optional, >> >> I believe that what is proposed in the draft (accepting the routes) is >> more preferred than rejecting the route. >> > > How about not making it mandatory to accept it? > I am concerned about it. Please see the above comment. Regards, -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 27 12:20:30 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F33828C20A; Tue, 27 Jan 2009 12:20:30 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BE2C28C20A for ; Tue, 27 Jan 2009 12:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCdmHfQFKFTc for ; Tue, 27 Jan 2009 12:20:28 -0800 (PST) Received: from synchronicity.convergence.cx (unknown [IPv6:2001:a88:0:ffff:216:17ff:fea5:e34c]) by core3.amsl.com (Postfix) with ESMTP id 64D6928C1E5 for ; Tue, 27 Jan 2009 12:20:27 -0800 (PST) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.69) (envelope-from ) id 1LRuPo-0008NW-Gd; Tue, 27 Jan 2009 20:20:08 +0000 Message-ID: <497F6C77.4020804@uk.clara.net> Date: Tue, 27 Jan 2009 20:20:07 +0000 From: David Freedman Organization: Claranet LImited User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 Newsgroups: gmane.ietf.idr To: Enke Chen References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> <497E4408.8060303@cisco.com> <20090127004955.GA8673@bronze.eng.gxn.net> <497E5E71.3020307@cisco.com> <20090127165214.GA27486@cappuccino.rob.sh> <497F5DE9.7030800@cisco.com> <497F6309.5080204@uk.clara.net> <497F6555.3070508@cisco.com> In-Reply-To: <497F6555.3070508@cisco.com> Cc: idr , quaizar.vohra@gmail.com, Jonathan Oddy Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org > > All the prefixes could have the malformed AS4_PATH attribute (from a > remote router). In that case, rejecting the routes has the same effect > as tearing down the session. You are correct that, in the tradeoff scenario we sever connectivity to the prefix, but the implications of this "in the wild" are not as worrying since a malicious network attempting to cause a user's disconnection to his upstream through mass prefix advertisement is made significantly more difficult due to the nature of both the network and BGP's bestpath selection algorithm. >One may still debate whether it's preferable to "fix" the broken route >by dropping the AS4_PATH or treat the broken route as a withdraw (which >as you point out is effectively what your options a+b are), but if the >latter is chosen it should be for some reason other than "may cause >loops". I'd like to see the "withdraw if you have something to withdraw or simply don't accept" such that everybody converges to a consistent view and we don't end up with having a patchwork of attributes recorded for a prefix, some with and some without an AS4_PATH (depending on who is doing what). Dave. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 27 13:42:59 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD293A6B95; Tue, 27 Jan 2009 13:42:59 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B783A6B8B for ; Tue, 27 Jan 2009 13:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKiNkQWUV1eC for ; Tue, 27 Jan 2009 13:42:56 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [192.207.141.16]) by core3.amsl.com (Postfix) with ESMTP id A0D123A6B95 for ; Tue, 27 Jan 2009 13:42:56 -0800 (PST) Received: from rjs by cappuccino.rob.sh with local (Exim 4.69) (envelope-from ) id 1LRvcf-0007QS-Qg; Tue, 27 Jan 2009 21:37:29 +0000 Date: Tue, 27 Jan 2009 21:37:29 +0000 From: Rob Shakir To: Enke Chen Message-ID: <20090127213729.GA28532@cappuccino.rob.sh> References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> <497E4408.8060303@cisco.com> <20090127004955.GA8673@bronze.eng.gxn.net> <497E5E71.3020307@cisco.com> <20090127165214.GA27486@cappuccino.rob.sh> <497F5DE9.7030800@cisco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <497F5DE9.7030800@cisco.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: idr , quaizar.vohra@gmail.com, Jonathan Oddy Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Tue, Jan 27, 2009 at 11:18:01AM -0800, Enke Chen wrote: > Yes, indeed. A routing loop may (or may not) occur when the AS4_PATH > should carry useful info but is either malformed or is absent. > > There is no perfect solution here. There are some tradeoffs, however, > between accepting the route and rejecting the route: > > o rejecting the route would guarantee disruption (i.e., loss of > connectivity). > o accepting the route would maintain connectivity, but may (or may > not) introduce a routing loop. > >> Take for example the case when an BGP speaker in a 32bit AS receiving >> an invalid AS4_PATH attribute. With the AS4_PATH unreadable and >> therefore discarded the BGP speaker cannot know if its AS number was in >> the path. The only loop free options are: >> (a) treat it as a withdrawal >> (b) treat any AS_TRANS in the AS_PATH as the local AS >> (c) drop the session. >> >> Option c is the behaviour that has led us to needing a change to the >> RFC, so is obviously unacceptable. >> > > Why is Option C "obviously unacceptable"? > > I think the reason is that it would result in loss of connectivity for > all the routes over the session, and can be used as a remote attack > vehicle. Enke, Forgive me for replying only to this section of your mail -- however, I'd like to clarify this statement. The reason that I originally picked up this problem is because I had a requirement to deploy a software release that happened to include 4-byte ASN support. The target device is a router that terminates a BGP transit session from our upstream. With this code, since my transit provider is (as far as I am aware) AS4-unaware through a large proportion (or maybe all) of their network, my router is likely to be the first router in the path that supports 4-byte ASN, and hence parses the AS4_PATH. In this case, I am learning a full BGP table from this transit provider of which only one prefix may contain invalid AS4_PATH information. According to the existing RFC, my device sends a notification, and tears down the session. With this behaviour, I have lost connectivity to all prefixes learnt via this session, rather than a single prefix that has invalid data. I believe what makes (c) 'obviously unacceptable' is that I am penalising all paths via my transit provider due to invalid data in the update for one prefix. The suggestion we provide differs from this in the important regard that I do not penalise all prefixes that my transit provider announces to me, but only those with invalid routing data. In the case where the invalid data is added by a router that is not within the originating AS, then (if the originating ASN is multi-homed - and not all routes propagate through the broken AS), I should see this prefix via some other (valid) path. It is only in the case that a prefix has no valid path to be propagated by that I would lack a valid route to this destination, and hence lose connectivity. You are correct that this could be all prefixes on a session, however, one must consider /what/ prefixes these are, and not just what proportion are affected. The current specification means that regardless of how many prefixes on a session contain this invalid data, my network will lose the path to all prefixes via the session. I do accept the point that if an OLD speaker propagates this route to me, then they are unaware of this invalid data, and hence I am penalising a path to which my direct neighbour (and OLD speakers path) has propagated correctly (by transiting an optional-transitive). Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From majordomo@amkya.com Tue Jan 27 18:42:09 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9083E3A6A28 for ; Tue, 27 Jan 2009 18:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.014 X-Spam-Level: X-Spam-Status: No, score=-9.014 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc7f0R5nuDt0 for ; Tue, 27 Jan 2009 18:42:08 -0800 (PST) Received: from p7101-ipbfp204fukuokachu.fukuoka.ocn.ne.jp (p7101-ipbfp204fukuokachu.fukuoka.ocn.ne.jp [123.219.66.101]) by core3.amsl.com (Postfix) with SMTP id 92AC53A6B49 for ; Tue, 27 Jan 2009 18:42:06 -0800 (PST) To: Subject: Check out hot deals From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090128024207.92AC53A6B49@core3.amsl.com> Date: Tue, 27 Jan 2009 18:42:06 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.meatthere.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://meatthere.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 9, B127. 756 Clements Road. London. SE25 1DG

© 2006-2008 BBCMEDIA, Ltd. All Rights Reserved

From nelson.carballo@agipecuador.com Wed Jan 28 10:32:41 2009 Return-Path: X-Original-To: ietfarch-idr-archive@core3.amsl.com Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A8A3A6B0D for ; Wed, 28 Jan 2009 10:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.717 X-Spam-Level: X-Spam-Status: No, score=-23.717 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HOST_EQ_STATICB=1.372, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQPCfrhVLD53 for ; Wed, 28 Jan 2009 10:32:40 -0800 (PST) Received: from static-217-133-75-207.clienti.tiscali.it (static-217-133-75-207.clienti.tiscali.it [217.133.75.207]) by core3.amsl.com (Postfix) with SMTP id B19B03A69E7 for ; Wed, 28 Jan 2009 10:32:29 -0800 (PST) To: Subject: Re: Re[1]: I'm Happy From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090128183233.B19B03A69E7@core3.amsl.com> Date: Wed, 28 Jan 2009 10:32:29 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello idr-archive

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 SASI Limited. SASi Communications S.a.r.l., 22/24 Green St, Amsterdam L2591.

SASi, SASiIn, SASiOut, SASicasts, SASi Certified, SASiMe!, SASi Pro, SASiFind, SASi Prime, SASi To Go, associated logos and the ‘S’-symbol are trademarks of SASi Limited.
From idr-bounces@ietf.org Wed Jan 28 22:00:44 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7393A6985; Wed, 28 Jan 2009 22:00:43 -0800 (PST) X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34F43A6985 for ; Wed, 28 Jan 2009 22:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bebrDEvMW7w for ; Wed, 28 Jan 2009 22:00:41 -0800 (PST) Received: from hibernia.jakma.org (cl-9.dub-01.ie.sixxs.net [IPv6:2001:770:100:8::2]) by core3.amsl.com (Postfix) with ESMTP id BC0B63A6983 for ; Wed, 28 Jan 2009 22:00:40 -0800 (PST) Received: from melandri.gla.jakma.org (melandri.jakma.org [81.168.24.37]) (authenticated bits=0) by hibernia.jakma.org (8.14.3/8.14.2) with ESMTP id n0T5xrPV011919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 06:00:02 GMT Date: Thu, 29 Jan 2009 05:59:52 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: "John G. Scudder" In-Reply-To: <0ABE8021-AE73-4081-A0A5-559E5A646247@juniper.net> Message-ID: References: <497B85CC.4010302@cisco.com> <20090126184849.GA23929@bronze.eng.gxn.net> <497E4408.8060303@cisco.com> <20090127004955.GA8673@bronze.eng.gxn.net> <497E5E71.3020307@cisco.com> <20090127165214.GA27486@cappuccino.rob.sh> <0ABE8021-AE73-4081-A0A5-559E5A646247@juniper.net> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.1.1 (hibernia.jakma.org [212.17.55.49]); Thu, 29 Jan 2009 06:00:11 +0000 (GMT) Cc: idr , quaizar.vohra@gmail.com, Jonathan Oddy Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt] X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org On Tue, 27 Jan 2009, John G. Scudder wrote: > On Jan 27, 2009, at 12:52 PM, Rob Shakir wrote: >> We feel that the general behaviour on an error should be the withdrawal >> of the path, as discarding the attribute is equivalent in effect to >> discarding part of the AS_PATH and may cause loops. Take for example the >> case when an BGP speaker in a 32bit AS receiving an invalid AS4_PATH >> attribute. With the AS4_PATH unreadable and therefore discarded the BGP >> speaker cannot know if its AS number was in the path. The only loop free >> options are: > > While intuitively obvious, this isn't correct. As long as there's no > corresponding damage to the AS_PATH, the loop free property is preserved. > Here's the argument: That's an argument as to why it doesn't break down completely if everything else is working in spec, which is indeed a nice property. I'm still puzzled as how this is an argument to not restore AS-path checking back to its full-strength. - It's not robust if two OLD speakers in a cycle each remove the other's ASN, with the remaining speakers on the cycle all being NEW. - It's not robust in a cycle of all NEW speakers where one session, for some reason, is both OLD and causes the AS4_PATH to be ignored. I really don't see what benefits there are to leave loop-detection degraded in this way in a mixed world. But hey.. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Extremism in the defense of liberty is no vice... moderation in the pursuit of justice is no virtue. -- Barry Goldwater _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jan 29 14:45:05 2009 Return-Path: X-Original-To: idr-archive@megatron.ietf.org Delivered-To: ietfarch-idr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CDFC3A6B79; Thu, 29 Jan 2009 14:45:05 -0800 (PST) X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B515A3A6A63; Thu, 29 Jan 2009 14:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090129224501.B515A3A6A63@core3.amsl.com> Date: Thu, 29 Jan 2009 14:45:01 -0800 (PST) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-flow-spec-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Dissemination of flow specification rules Author(s) : P. Roque Marques, et al. Filename : draft-ietf-idr-flow-spec-05.txt Pages : 21 Date : 2009-01-29 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-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-idr-flow-spec-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-29144121.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/idr --NextPart--