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)
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! |
|
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! |
|
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. |
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! |
|
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. |
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)
|
|
|
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! |
|
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: