From russw@riw.us Fri Nov 1 18:39:18 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8828311E80E7 for ; Fri, 1 Nov 2013 18:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZwTvgAd8eNi for ; Fri, 1 Nov 2013 18:39:12 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2D311E810C for ; Fri, 1 Nov 2013 18:39:12 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:55228 helo=RussPC) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VcQBB-0006st-5h; Sat, 02 Nov 2013 01:39:10 +0000 From: "Russ White" To: "'Jeffrey Haas'" , References: <20131024204333.GS17538@pfrc> In-Reply-To: <20131024204333.GS17538@pfrc> Date: Fri, 1 Nov 2013 21:39:12 -0400 Message-ID: <059d01ced76c$55bea3c0$013beb40$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGkBg+4Kp4SLP5wbxoUgNIMCH96/ZpmzGUw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Idr] Advancing add-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 01:39:18 -0000 > Service Providers seem to be happy with add-paths in its current form. Has > anyone seen demand for the eBGP support covered by fast-conn-restore? No, not that I'm aware of... I think we should move the drafts forward without this piece. It can always be added later if some use case comes up. :-) Russ From nick@inex.ie Sat Nov 2 03:27:08 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1EC11E8186 for ; Sat, 2 Nov 2013 03:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtJSi7T1DdAj for ; Sat, 2 Nov 2013 03:27:07 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5F93E11E815C for ; Sat, 2 Nov 2013 03:27:02 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rA2AQwK6062017 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 2 Nov 2013 10:26:58 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <5274D371.9010002@inex.ie> Date: Sat, 02 Nov 2013 10:26:57 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Russ White , "'Jeffrey Haas'" , idr@ietf.org References: <20131024204333.GS17538@pfrc> <059d01ced76c$55bea3c0$013beb40$@riw.us> In-Reply-To: <059d01ced76c$55bea3c0$013beb40$@riw.us> X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] Advancing add-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 10:27:09 -0000 On 02/11/2013 01:39, Russ White wrote: > No, not that I'm aware of... I think we should move the drafts forward > without this piece. It can always be added later if some use case comes up. the ixp community is interested in add-path/ebgp, as it solves a bunch of rather nasty scaling issues on route servers. Nick From russw@riw.us Sat Nov 2 05:21:28 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D4621E8096 for ; Sat, 2 Nov 2013 05:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bza7cyMMQMY1 for ; Sat, 2 Nov 2013 05:21:23 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 054D021E80BE for ; Sat, 2 Nov 2013 05:21:22 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:59168 helo=RussPC) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VcaCU-0003vF-KW; Sat, 02 Nov 2013 12:21:10 +0000 From: "Russ White" To: "'Nick Hilliard'" , "'Jeffrey Haas'" , References: <20131024204333.GS17538@pfrc> <059d01ced76c$55bea3c0$013beb40$@riw.us> <5274D371.9010002@inex.ie> In-Reply-To: <5274D371.9010002@inex.ie> Date: Sat, 2 Nov 2013 08:21:12 -0400 Message-ID: <012a01ced7c6$066d83e0$13488ba0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGkBg+4Kp4SLP5wbxoUgNIMCH96/QKKLU2pAdUFBXKaRIYNwA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Idr] Advancing add-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 12:21:29 -0000 > > No, not that I'm aware of... I think we should move the drafts forward > > without this piece. It can always be added later if some use case comes up. > > the ixp community is interested in add-path/ebgp, as it solves a bunch of > rather nasty scaling issues on route servers. How about we move add-paths for iBGP forward, and then we work on a separate draft for eBGP add paths? :-) Russ From nick@inex.ie Sat Nov 2 08:37:26 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBB621F9344 for ; Sat, 2 Nov 2013 08:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EH+w4tBns-iX for ; Sat, 2 Nov 2013 08:37:23 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 88F4211E813B for ; Sat, 2 Nov 2013 08:37:19 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id rA2FbDkN063872 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 2 Nov 2013 15:37:15 GMT (envelope-from nick@inex.ie) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org Message-ID: <52751C29.9060109@inex.ie> Date: Sat, 02 Nov 2013 15:37:13 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Russ White , "'Jeffrey Haas'" , idr@ietf.org References: <20131024204333.GS17538@pfrc> <059d01ced76c$55bea3c0$013beb40$@riw.us> <5274D371.9010002@inex.ie> <012a01ced7c6$066d83e0$13488ba0$@riw.us> In-Reply-To: <012a01ced7c6$066d83e0$13488ba0$@riw.us> X-Enigmail-Version: 1.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] Advancing add-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 15:37:27 -0000 On 02/11/2013 12:21, Russ White wrote: > How about we move add-paths for iBGP forward, and then we work on a separate > draft for eBGP add paths? ha! But probably this is a better option than confusing the two things. Nick From thomas.mangin@exa-networks.co.uk Sat Nov 2 08:44:22 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A3C11E81DE; Sat, 2 Nov 2013 08:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTe2P4k4k9H1; Sat, 2 Nov 2013 08:44:17 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8744711E816F; Sat, 2 Nov 2013 08:44:17 -0700 (PDT) Received: from smtp-3.mail.exa.net.uk (smtp-3.mail.exa.net.uk [82.219.5.3]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id E0931A00C8; Sat, 2 Nov 2013 15:44:15 +0000 (GMT) Received: from [82.219.212.37] (ptr-37.212.219.82.rev.exa.net.uk [82.219.212.37]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPSA id 951276C0047; Sat, 2 Nov 2013 15:44:15 +0000 (GMT) References: <20131024204333.GS17538@pfrc> <059d01ced76c$55bea3c0$013beb40$@riw.us> <5274D371.9010002@inex.ie> Mime-Version: 1.0 (1.0) In-Reply-To: <5274D371.9010002@inex.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <06384C32-688B-42BC-B514-E74C96C1E6A7@exa-networks.co.uk> X-Mailer: iPad Mail (11B511) From: Thomas Mangin Date: Sat, 2 Nov 2013 15:44:18 +0000 To: "idr-bounces@ietf.org" X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "idr@ietf.org" Subject: Re: [Idr] Advancing add-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 15:44:22 -0000 +1 Sent from my iPad > On 2 Nov 2013, at 10:26, Nick Hilliard wrote: >=20 >> On 02/11/2013 01:39, Russ White wrote: >> No, not that I'm aware of... I think we should move the drafts forward >> without this piece. It can always be added later if some use case comes u= p. >=20 > the ixp community is interested in add-path/ebgp, as it solves a bunch of > rather nasty scaling issues on route servers. >=20 > Nick >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 From jayb@braeburn.org Mon Nov 4 08:02:20 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A3111E82A2 for ; Mon, 4 Nov 2013 08:02:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EbsDdnnvQNq for ; Mon, 4 Nov 2013 08:02:13 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3C47511E827E for ; Mon, 4 Nov 2013 08:02:13 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 405c7725.0.2426232.00-361.6771386.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 04 Nov 2013 16:02:13 +0000 (UTC) X-MXL-Hash: 5277c5056b39ce73-46bf7170e8f1c8d9e9da914264f788117a83805f Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rA4G2Cb7013889 for ; Mon, 4 Nov 2013 11:02:12 -0500 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rA4G24Si013789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Nov 2013 11:02:08 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Mon, 4 Nov 2013 16:01:49 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id rA4G1n4X025746 for ; Mon, 4 Nov 2013 11:01:49 -0500 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id rA4G1k15025689 for ; Mon, 4 Nov 2013 11:01:47 -0500 Received: by oz.mt.att.com (Postfix, from userid 1000) id 3B51A6803E0; Mon, 4 Nov 2013 11:01:46 -0500 (EST) X-Mailer: emacs 23.3.1 (via feedmail 8 I) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21111.50401.542862.187680@oz.mt.att.com> Date: Mon, 4 Nov 2013 11:01:37 -0500 From: Jay Borkenhagen To: idr@ietf.org X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 X-RSA-Inspected: yes X-RSA-Classifications: public Subject: [Idr] comments on draft-ietf-idr-add-paths-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jay Borkenhagen List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 16:02:20 -0000 Some comments on draft-ietf-idr-add-paths-09: The second paragraph of Section 5 now reads: A BGP speaker that is willing to receive multiple paths from its peer, or would like to send multiple paths to its peer, SHOULD advertise the ADD-PATH Capability to the peer using BGP Capabilities advertisement [RFC5492]. BGP speakers *hate* being anthropomorphized, so I would recommend removing terms such as "is willing" and "would like to". Also, this use of "SHOULD" should be changed: "SHOULD" implies that add-path might still happen in this session even if the ADD-PATH capabilities advertisements do not occur -- that ain't gonna happen. Let me propose: For a BGP speaker to be able to send multiple paths to its peer, that BGP speaker MUST advertise the ADD-PATH 'send' capability to the peer AND that peer MUST advertise the ADD-PATH 'receive' capability to the BGP speaker, using BGP Capabilities advertisement [RFC5492]. OR possibly you should delete this second paragraph entirely -- I think the current third paragraph specifies this requirement well enough. The draft needs to specify how certain conditions should be dealt with. Suppose router A and router B agree that A will send to B using add-path. - What should B do if an update received from A is a withdrawal containing a Path Identifier not seen previously, while B had previously received from A an announcement for the same prefix with a different Path Identifier? One implementation might be strict in interpreting the withdrawal as gratuitous and leave the received annoucement in place, while another might conclude that the odd withdrawal is a sign that router A has lost track of which Path Identifiers it has used for which announced prefixes, and take some other action. This standard should specify which interpretation should be used. - What should B do if an update received from A does not include any Path Identifier? (I presume this situation would be a NOTIFY-worthy protocol error condition.) From internet-drafts@ietf.org Mon Nov 4 08:55:06 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B185221E81AE; Mon, 4 Nov 2013 08:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1yeZLX8Op23; Mon, 4 Nov 2013 08:55:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6AF11E8212; Mon, 4 Nov 2013 08:54:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131104165452.10097.40248.idtracker@ietfa.amsl.com> Date: Mon, 04 Nov 2013 08:54:52 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-sla-exchange-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 16:55:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Inter-domain SLA Exchange Author(s) : Shitanshu Shah Keyur Patel Sandeep Bajaj Luis Tomotaki Mohamed Boucadair Filename : draft-ietf-idr-sla-exchange-02.txt Pages : 24 Date : 2013-11-04 Abstract: Network administrators typically enforce Quality of Service (QoS) policies according to Service Level Agreement (SLA) with their providers. The enforcement of such policies often relies upon vendor-specific configuration language. Both learning of SLA, either thru SLA documents or via some other out-of-band method, and translating them to vendor specific configuration language is a complex, many times manual, process and prone to errors. This document proposes an in-band method of SLA signaling which can help to simplify some of the complexities. This document defines an optional transitive attribute to signal SLA details in-band, across administrative boundaries (considered as Autonomous Systems (AS)), thus simplifying and facilitating some of the complex provisioning tasks. Though the use case with the proposed BGP attribute is explicitly defined in this document, purpose of this attribute is not limited to this use case only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-sla-exchange-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sla-exchange-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shyam.ioml@gmail.com Mon Nov 4 17:37:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EE511E8344 for ; Mon, 4 Nov 2013 17:37:36 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC8Lwmn+c3vG for ; Mon, 4 Nov 2013 17:37:35 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8E53021E818C for ; Mon, 4 Nov 2013 17:37:32 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id va2so130559obc.6 for ; Mon, 04 Nov 2013 17:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CV/yRktk155WGZFt4B40tFu1m9ZAqyQmPmRSdmL1fW0=; b=D2h4lpjanQlWYurAj5GdF1gYK5wRhyRdRDj4A0fVuQFtuMabxUH8AojbLSU5rWI53b bkzREQaZrdbLpDsagTikxaJU6Tm0m6jsDr3CirtcUYTpgLXkNL3LGeQDcunGoUurg+Ho B1tfwbtzIoY8zZXReufU1+z1sfwlpegLqeu+1eaDaiLNs/+RzMW62Tq94kii7sa1FVUX DqUgY2yp0H2J4z1JV/I1NRjgPbbUZSzHHxxm4kxJlF7Ua/bC+B5cP2v0MGJG7TJkNfkK UzI7IfFs5Y75CUaafyHAM1SlHNUpwk7aXV/5LxBme5qaLYreiSWKJMbkt5jnVxAVDUpj cKrA== MIME-Version: 1.0 X-Received: by 10.60.174.75 with SMTP id bq11mr16546444oec.17.1383615451943; Mon, 04 Nov 2013 17:37:31 -0800 (PST) Received: by 10.76.175.226 with HTTP; Mon, 4 Nov 2013 17:37:31 -0800 (PST) In-Reply-To: <21111.50401.542862.187680@oz.mt.att.com> References: <21111.50401.542862.187680@oz.mt.att.com> Date: Mon, 4 Nov 2013 17:37:31 -0800 Message-ID: From: Shyam Sethuram To: Jay Borkenhagen Content-Type: multipart/alternative; boundary=089e01228a4884d96304ea64139d Cc: "idr@ietf. org" Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 01:37:36 -0000 --089e01228a4884d96304ea64139d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 4, 2013 at 8:01 AM, Jay Borkenhagen wrote: > Some comments on draft-ietf-idr-add-paths-09: > > The second paragraph of Section 5 now reads: > > A BGP speaker that is willing to receive multiple paths from its > peer, or would like to send multiple paths to its peer, SHOULD > advertise the ADD-PATH Capability to the peer using BGP > Capabilities advertisement [RFC5492]. > > BGP speakers *hate* being anthropomorphized, so I would recommend > removing terms such as "is willing" and "would like to". Also, this > use of "SHOULD" should be changed: "SHOULD" implies that add-path > might still happen in this session even if the ADD-PATH capabilities > advertisements do not occur -- that ain't gonna happen. Let me > propose: > > For a BGP speaker to be able to send multiple paths to its peer, > that BGP speaker MUST advertise the ADD-PATH 'send' capability to > the peer AND that peer MUST advertise the ADD-PATH 'receive' > capability to the BGP speaker, using BGP Capabilities advertisement > [RFC5492]. > > OR possibly you should delete this second paragraph entirely -- I > think the current third paragraph specifies this requirement well > enough. > > > The draft needs to specify how certain conditions should be dealt > with. Suppose router A and router B agree that A will send to B > using add-path. > > - What should B do if an update received from A is a withdrawal > containing a Path Identifier not seen previously, while B had > previously received from A an announcement for the same prefix with a > different Path Identifier? That would be a NOP. > One implementation might be strict in > interpreting the withdrawal as gratuitous and leave the received > annoucement in place, while another might conclude that the odd > withdrawal is a sign that router A has lost track of which Path > Identifiers it has used for which announced prefixes, and take some > other action. This standard should specify which interpretation > should be used. > The former is the right behavior. IMHO it's sufficiently clear in the standard. > > - What should B do if an update received from A does not include any > Path Identifier? (I presume this situation would be a NOTIFY-worthy > protocol error condition.) > There's no reliable way to know this... you'd probably run into a parsing error and end up sending a Notification anyway. Cheers! -Shyam > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --089e01228a4884d96304ea64139d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Mon, Nov 4, 2013 at 8:01 AM, Jay Borkenhagen <jayb@braeburn.org>= wrote:
Some comments on draft-ietf-idr-add-paths-09= :

The second paragraph of Section 5 now reads:

=A0 =A0A BGP speaker that is willing to receive multiple paths from its
=A0 =A0peer, or would like to send multiple paths to its peer, SHOULD
=A0 =A0advertise the ADD-PATH Capability to the peer using BGP
=A0 =A0Capabilities advertisement [RFC5492].

BGP speakers *hate* being anthropomorphized, so I would recommend
removing terms such as "is willing" and "would like to"= . =A0Also, this
use of "SHOULD" should be changed: "SHOULD" implies tha= t add-path
might still happen in this session even if the ADD-PATH capabilities
advertisements do not occur -- that ain't gonna happen. =A0Let me
propose:

=A0 =A0For a BGP speaker to be able to send multiple paths to its peer,
=A0 =A0that BGP speaker MUST advertise the ADD-PATH 'send' capabili= ty to
=A0 =A0the peer AND that peer MUST advertise the ADD-PATH 'receive'=
=A0 =A0capability to the BGP speaker, using BGP Capabilities advertisement<= br> =A0 =A0[RFC5492].

OR possibly you should delete this second paragraph entirely -- I
think the current third paragraph specifies this requirement well
enough.


The draft needs to specify how certain conditions should be dealt
with. Suppose router A and router B agree that A will send to B
using add-path.

=A0- What should B do if an update received from A is a withdrawal
containing a Path Identifier not seen previously, while B had
previously received from A an announcement for the same prefix with a
different Path Identifier?

That would be a= NOP.

=A0
= One implementation might be strict in
interpreting the withdrawal as gratuitous and leave the received
annoucement in place, while another might conclude that the odd
withdrawal is a sign that router A has lost track of which Path
Identifiers it has used for which announced prefixes, and take some
other action. =A0This standard should specify which interpretation
should be used.

The former is the right= behavior. IMHO it's sufficiently clear in the standard.

=
=A0

=A0- What should B do if an update received from A does not include any
Path Identifier? =A0(I presume this situation would be a NOTIFY-worthy
protocol error condition.)

There's = no reliable way to know this... you'd probably run into a
par= sing error and end up sending a Notification anyway.

Cheers!
-Shyam



_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--089e01228a4884d96304ea64139d-- From jakob.heitz@ericsson.com Mon Nov 4 18:18:55 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88C721E82EE for ; Mon, 4 Nov 2013 18:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSqB2TUSNtcB for ; Mon, 4 Nov 2013 18:18:50 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 167A621E82C6 for ; Mon, 4 Nov 2013 18:18:49 -0800 (PST) X-AuditID: c618062d-b7fd88e00000439f-86-52785588f220 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3A.97.17311.88558725; Tue, 5 Nov 2013 03:18:48 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Mon, 4 Nov 2013 21:18:48 -0500 From: Jakob Heitz To: Jay Borkenhagen , "idr@ietf.org" Thread-Topic: [Idr] comments on draft-ietf-idr-add-paths-09 Thread-Index: AQHO2XdeOrK/B1KFCUKtlJ+iRCHhZZoV4nsg Date: Tue, 5 Nov 2013 02:18:47 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB5DF4@eusaamb109.ericsson.se> References: <21111.50401.542862.187680@oz.mt.att.com> In-Reply-To: <21111.50401.542862.187680@oz.mt.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPiG5HaEWQwaFWa4tXt58xWSw7vpfd gcnj0bRHTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mpo3H6VpeCneMXd9mvMDYxrhbsYOTkkBEwk Xjc1MkPYYhIX7q1n62Lk4hASOMIocfvnfxaQhJDAMkaJjz0+IDabgI7Et+tdYA0iAm4Suy5t ZAKxhQWsJJouv2GCiFtLvH/UyAhhG0nM3vIPLM4ioCLxresDmM0r4CuxY8sdJoj5phIrXq9j A7E5Bcwk7t04ChZnBDro+6k1YDazgLjErSfzmSAOFZBYsuc81NGiEi8f/2OFsJUlljzZzwJR ryOxYPcnNghbW2LZwtfMEHsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWMHKXFqWW56UYG mxiB0XBMgk13B+Oel5aHGKU5WJTEeb+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwNgp utS9o/O5zelPW1bJTi6XnLzYRNJvUUiI2672paV3vzHN/sahfc9uy/0gjd2mYVOaWT24/jcs 22774We1wf2OXV/Vs7YYBnK12Wk89z9n2VLCx1t/VHAl++RTJxyWdc056s8yO4L3wwrf+3Kp FfPiWc5yhn7nuhJVcGMFq4XA7RcBZ36dnK7EUpyRaKjFXFScCAAcAlA3VAIAAA== Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 02:18:55 -0000 Withdraw for non-existent path: BGP is permitted to do that without add-path. My vote would be to do the same with add-path: ignore it. You said never-existed path. I can not tell the difference between a once-e= xisted-and-now-gone path and a never-existed path. Send add-path capability, but send updates without path-id: I can not see a reason for doing this, so consider it an error. My vote would be to treat it as withdraw, in accordance with the error-hand= ling draft. That is: withdraw all paths with that prefix from this speaker. And log an = error, of course. Thanks, Jakob. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jay B= orkenhagen Sent: Monday, November 04, 2013 8:02 AM To: idr@ietf.org Subject: [Idr] comments on draft-ietf-idr-add-paths-09 Some comments on draft-ietf-idr-add-paths-09: The second paragraph of Section 5 now reads: A BGP speaker that is willing to receive multiple paths from its peer, or would like to send multiple paths to its peer, SHOULD advertise the ADD-PATH Capability to the peer using BGP Capabilities advertisement [RFC5492]. BGP speakers *hate* being anthropomorphized, so I would recommend removing = terms such as "is willing" and "would like to". Also, this use of "SHOULD"= should be changed: "SHOULD" implies that add-path might still happen in th= is session even if the ADD-PATH capabilities advertisements do not occur --= that ain't gonna happen. Let me propose: For a BGP speaker to be able to send multiple paths to its peer, that BGP speaker MUST advertise the ADD-PATH 'send' capability to the peer AND that peer MUST advertise the ADD-PATH 'receive' capability to the BGP speaker, using BGP Capabilities advertisement [RFC5492]. OR possibly you should delete this second paragraph entirely -- I think the= current third paragraph specifies this requirement well enough. The draft needs to specify how certain conditions should be dealt with. Sup= pose router A and router B agree that A will send to B using add-path. =20 - What should B do if an update received from A is a withdrawal containing= a Path Identifier not seen previously, while B had previously received fro= m A an announcement for the same prefix with a different Path Identifier? = One implementation might be strict in interpreting the withdrawal as gratui= tous and leave the received annoucement in place, while another might concl= ude that the odd withdrawal is a sign that router A has lost track of which= Path Identifiers it has used for which announced prefixes, and take some o= ther action. This standard should specify which interpretation should be u= sed. - What should B do if an update received from A does not include any Path = Identifier? (I presume this situation would be a NOTIFY-worthy protocol er= ror condition.) _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From sairay@cisco.com Mon Nov 4 18:25:44 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EAB21E82EE for ; Mon, 4 Nov 2013 18:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpw75QLVlg9x for ; Mon, 4 Nov 2013 18:25:39 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD5921E8172 for ; Mon, 4 Nov 2013 18:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3870; q=dns/txt; s=iport; t=1383618339; x=1384827939; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wOx/GvCa7fxYOpJVNdGbSlTdPqY9j5nRW1sWle9T7w8=; b=brkMjarz1FIKrgIPRrqotWV5bhpoJE53WP2S+r5bQLXa347Z8ssWwcN6 A48yu87fRCKgGkvj5KHB8eS1GDdG8p6PP30qtIkRB4G0vPi5VH/kRQSOv 5POdsKxDEW3HT6fuE+dvlcB45kIj98Bbtfa7WV1s4taBGUhERdE1Dxn4S 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFANdVeFKtJXG+/2dsb2JhbABZgwc4U787gSgWdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQBEgiHeQ2+LgSPGjgGgxqBDgOqE4Mmgio X-IronPort-AV: E=Sophos;i="4.93,637,1378857600"; d="scan'208";a="280630826" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2013 02:25:38 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA52PcOU004057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 02:25:38 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.14]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 20:25:37 -0600 From: "Saikat Ray (sairay)" To: Jakob Heitz , Jay Borkenhagen , "idr@ietf.org" Thread-Topic: [Idr] comments on draft-ietf-idr-add-paths-09 Thread-Index: AQHO2XdJCtyw5FMEpUGgU5aX0sisP5oWTF2A//+cG+A= Date: Tue, 5 Nov 2013 02:25:37 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A11ABEF13@xmb-rcd-x13.cisco.com> References: <21111.50401.542862.187680@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB5DF4@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB5DF4@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.165.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 02:25:44 -0000 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jakob= Heitz Sent: Monday, November 04, 2013 6:19 PM To: Jay Borkenhagen; idr@ietf.org Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 Withdraw for non-existent path: BGP is permitted to do that without add-path. My vote would be to do the same with add-path: ignore it. You said never-existed path. I can not tell the difference between a once-e= xisted-and-now-gone path and a never-existed path. Send add-path capability, but send updates without path-id: [SR] What does it mean to say "without path ID"? If the BGP speaker is expe= cting an "add-path NLRI" (because the capabilities are exchanged at least o= ne way), then it will always parse the first 4 octets as the ID. If the sen= der didn't actually add the Path ID field in the NLRI, it will (most likely= ) run into a parsing error (a length error somewhere), in which case it has= to reset the neighbor session. I can not see a reason for doing this, so consider it an error. My vote would be to treat it as withdraw, in accordance with the error-hand= ling draft. That is: withdraw all paths with that prefix from this speaker. And log an = error, of course. Thanks, Jakob. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jay B= orkenhagen Sent: Monday, November 04, 2013 8:02 AM To: idr@ietf.org Subject: [Idr] comments on draft-ietf-idr-add-paths-09 Some comments on draft-ietf-idr-add-paths-09: The second paragraph of Section 5 now reads: A BGP speaker that is willing to receive multiple paths from its peer, or would like to send multiple paths to its peer, SHOULD advertise the ADD-PATH Capability to the peer using BGP Capabilities advertisement [RFC5492]. BGP speakers *hate* being anthropomorphized, so I would recommend removing = terms such as "is willing" and "would like to". Also, this use of "SHOULD"= should be changed: "SHOULD" implies that add-path might still happen in th= is session even if the ADD-PATH capabilities advertisements do not occur --= that ain't gonna happen. Let me propose: For a BGP speaker to be able to send multiple paths to its peer, that BGP speaker MUST advertise the ADD-PATH 'send' capability to the peer AND that peer MUST advertise the ADD-PATH 'receive' capability to the BGP speaker, using BGP Capabilities advertisement [RFC5492]. OR possibly you should delete this second paragraph entirely -- I think the= current third paragraph specifies this requirement well enough. The draft needs to specify how certain conditions should be dealt with. Sup= pose router A and router B agree that A will send to B using add-path. =20 - What should B do if an update received from A is a withdrawal containing= a Path Identifier not seen previously, while B had previously received fro= m A an announcement for the same prefix with a different Path Identifier? = One implementation might be strict in interpreting the withdrawal as gratui= tous and leave the received annoucement in place, while another might concl= ude that the odd withdrawal is a sign that router A has lost track of which= Path Identifiers it has used for which announced prefixes, and take some o= ther action. This standard should specify which interpretation should be u= sed. - What should B do if an update received from A does not include any Path = Identifier? (I presume this situation would be a NOTIFY-worthy protocol er= ror condition.) _______________________________________________ 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 jakob.heitz@ericsson.com Mon Nov 4 18:31:50 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4EB11E8267 for ; Mon, 4 Nov 2013 18:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c71xpo02prGD for ; Mon, 4 Nov 2013 18:31:45 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 785DA11E8353 for ; Mon, 4 Nov 2013 18:31:44 -0800 (PST) X-AuditID: c6180641-b7f3f8e000000a05-2e-5278588f5c3e Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id EC.97.02565.F8858725; Tue, 5 Nov 2013 03:31:43 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Mon, 4 Nov 2013 21:31:42 -0500 From: Jakob Heitz To: "Saikat Ray (sairay)" Thread-Topic: [Idr] comments on draft-ietf-idr-add-paths-09 Thread-Index: AQHO2XdeOrK/B1KFCUKtlJ+iRCHhZZoV4nsggABbCID//63gww== Date: Tue, 5 Nov 2013 02:31:41 +0000 Message-ID: <548411C6-315A-43F1-B5AC-C48E9EE57C54@ericsson.com> References: <21111.50401.542862.187680@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB5DF4@eusaamb109.ericsson.se>, <8ED5B0B0F5B4854A912480C1521F973A11ABEF13@xmb-rcd-x13.cisco.com> In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A11ABEF13@xmb-rcd-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXSPt25/REWQwf11Ghavbj9jslh2fC+7 xZ5Dy9kcmD0eTXvE5DHl90ZWjyVLfjIFMEdx2aSk5mSWpRbp2yVwZXSeci84pVCx7VUXSwPj eqkuRk4OCQETifn7O1ghbDGJC/fWs4HYQgJHGCXOPS3tYuQCspcxSuw8fZMRJMEmoCPx7XoX M4gtAmT3XN8B1sAs4Cbx7vgCdhBbWMBK4sSKB6wQNdYS7x81MkLYThLTfm8C62URUJHY2v8T LM4rYC9x+VInO8TiXYwSPWdqQGxOAV+JD5MXg81hBDru+6k1TBC7xCVuPZnPBHG0gMSSPeeZ IWxRiZeP/7FC1OhILNj9Ceo2bYllC18zQ+wSlDg58wnLBEbRWUhGzULSMgtJyywkLQsYWVYx cpQWp5blphsZbmIExscxCTbHHYwLPlkeYpTmYFES5/3y1jlISCA9sSQ1OzW1ILUovqg0J7X4 ECMTB6dUA2N44Oy1p+OW3JvgznruWVPHjYCq7V9+JLPb3dK/6LHEbvk6DdlDjHzv9O9xb1yU +JpDJOb+d3ZVK/afz5I9/V8vslYT7w871SFz6XKJsL6roexC1ycemWldzNVNz0T0grTy7Coi Vlv9jBA/UfX4v2bQOc5eWVstAaHa3isN5ra5m89VWfZNVmIpzkg01GIuKk4EANFJRBFdAgAA Cc: "idr@ietf.org" , Jay Borkenhagen Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 02:31:50 -0000 Good point. Didn't think enough. -- Jakob Heitz.=20 > On Nov 4, 2013, at 6:25 PM, "Saikat Ray (sairay)" wrot= e: >=20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jak= ob Heitz > Sent: Monday, November 04, 2013 6:19 PM > To: Jay Borkenhagen; idr@ietf.org > Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 >=20 > Withdraw for non-existent path: > BGP is permitted to do that without add-path. > My vote would be to do the same with add-path: ignore it. > You said never-existed path. I can not tell the difference between a once= -existed-and-now-gone path and a never-existed path. >=20 > Send add-path capability, but send updates without path-id: >=20 > [SR] What does it mean to say "without path ID"? If the BGP speaker is ex= pecting an "add-path NLRI" (because the capabilities are exchanged at least= one way), then it will always parse the first 4 octets as the ID. If the s= ender didn't actually add the Path ID field in the NLRI, it will (most like= ly) run into a parsing error (a length error somewhere), in which case it h= as to reset the neighbor session. >=20 >=20 > I can not see a reason for doing this, so consider it an error. > My vote would be to treat it as withdraw, in accordance with the error-ha= ndling draft. > That is: withdraw all paths with that prefix from this speaker. And log a= n error, of course. >=20 > Thanks, > Jakob. >=20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jay= Borkenhagen > Sent: Monday, November 04, 2013 8:02 AM > To: idr@ietf.org > Subject: [Idr] comments on draft-ietf-idr-add-paths-09 >=20 > Some comments on draft-ietf-idr-add-paths-09: >=20 > The second paragraph of Section 5 now reads: >=20 > A BGP speaker that is willing to receive multiple paths from its > peer, or would like to send multiple paths to its peer, SHOULD > advertise the ADD-PATH Capability to the peer using BGP > Capabilities advertisement [RFC5492]. >=20 > BGP speakers *hate* being anthropomorphized, so I would recommend removin= g terms such as "is willing" and "would like to". Also, this use of "SHOUL= D" should be changed: "SHOULD" implies that add-path might still happen in = this session even if the ADD-PATH capabilities advertisements do not occur = -- that ain't gonna happen. Let me > propose: >=20 > For a BGP speaker to be able to send multiple paths to its peer, > that BGP speaker MUST advertise the ADD-PATH 'send' capability to > the peer AND that peer MUST advertise the ADD-PATH 'receive' > capability to the BGP speaker, using BGP Capabilities advertisement > [RFC5492]. >=20 > OR possibly you should delete this second paragraph entirely -- I think t= he current third paragraph specifies this requirement well enough. >=20 >=20 > The draft needs to specify how certain conditions should be dealt with. S= uppose router A and router B agree that A will send to B using add-path. =20 >=20 > - What should B do if an update received from A is a withdrawal containin= g a Path Identifier not seen previously, while B had previously received fr= om A an announcement for the same prefix with a different Path Identifier? = One implementation might be strict in interpreting the withdrawal as gratu= itous and leave the received annoucement in place, while another might conc= lude that the odd withdrawal is a sign that router A has lost track of whic= h Path Identifiers it has used for which announced prefixes, and take some = other action. This standard should specify which interpretation should be = used. >=20 > - What should B do if an update received from A does not include any Path= Identifier? (I presume this situation would be a NOTIFY-worthy protocol e= rror condition.) >=20 > _______________________________________________ > 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 wwwrun@rfc-editor.org Mon Nov 4 22:49:51 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D3321E809E for ; Mon, 4 Nov 2013 22:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p77alHJh4qSw for ; Mon, 4 Nov 2013 22:49:50 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BEA9921F9AE7 for ; Mon, 4 Nov 2013 22:49:50 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id BB22075E011; Mon, 4 Nov 2013 22:40:27 -0800 (PST) To: jhaas@nexthop.com, skh@nexthop.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20131105064027.BB22075E011@rfc-editor.org> Date: Mon, 4 Nov 2013 22:40:27 -0800 (PST) Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC4273 (3782) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 06:49:51 -0000 The following errata report has been submitted for RFC4273, "Definitions of Managed Objects for BGP-4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4273&eid=3782 -------------------------------------- Type: Editorial Reported by: Ramakrishna DTV Section: 5 Original Text ------------- There are several management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Corrected Text -------------- There are several management objects defined in this MIB that have a MAX-ACCESS clause of read-write. Notes ----- No object in this MIB has MAX-ACCESS clause of "read-create". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4273 (draft-ietf-idr-bgp4-mib-15) -------------------------------------- Title : Definitions of Managed Objects for BGP-4 Publication Date : January 2006 Author(s) : J. Haas, Ed., S. Hares, Ed. Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From jrmitche@puck.nether.net Tue Nov 5 09:13:15 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562A011E8178 for ; Tue, 5 Nov 2013 09:13: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0oO8uFfUf-g for ; Tue, 5 Nov 2013 09:13:13 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA8D21E80F8 for ; Tue, 5 Nov 2013 09:13:13 -0800 (PST) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id rA5HDCvI012878; Tue, 5 Nov 2013 12:13:12 -0500 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id rA5HDB0f012877; Tue, 5 Nov 2013 12:13:11 -0500 Date: Tue, 5 Nov 2013 12:13:11 -0500 From: Jon Mitchell To: Nick Hilliard Message-ID: <20131105171311.GB10567@puck.nether.net> References: <20131024204333.GS17538@pfrc> <059d01ced76c$55bea3c0$013beb40$@riw.us> <5274D371.9010002@inex.ie> <012a01ced7c6$066d83e0$13488ba0$@riw.us> <52751C29.9060109@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52751C29.9060109@inex.ie> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.1 (puck.nether.net [127.0.0.1]); Tue, 05 Nov 2013 12:13:12 -0500 (EST) Cc: idr@ietf.org Subject: Re: [Idr] Advancing add-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:13:15 -0000 On 02/11/13 15:37 +0000, Nick Hilliard wrote: > On 02/11/2013 12:21, Russ White wrote: > > How about we move add-paths for iBGP forward, and then we work on a separate > > draft for eBGP add paths? > > ha! > > But probably this is a better option than confusing the two things. I support this approach but don't think the current drafts need to exclude/prohibit EBGP applications. Rather, the whole paragraph could be deleted as it was probably more appropriate for it to have been in the deployment considerations section anyway which already references getting guidance on usage of add-paths in seperate documents (presumably the guidelines doc or fast-conn), which can progress at their own pace. Jon From jhaas@slice.pfrc.org Tue Nov 5 14:02:04 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50721E812E for ; Tue, 5 Nov 2013 14:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.207 X-Spam-Level: X-Spam-Status: No, score=-102.207 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jspn2i6bVyYT for ; Tue, 5 Nov 2013 14:02:00 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFC721E80F1 for ; Tue, 5 Nov 2013 14:01:56 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id D1D4BC305; Tue, 5 Nov 2013 17:01:55 -0500 (EST) Date: Tue, 5 Nov 2013 17:01:55 -0500 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20131105220155.GA19411@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Idr] draft-haas-idr-flowspec-redirect-rt-bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:02:04 -0000 Working Group, The following draft pertains to the brief presentation on this topic during Friday's session at IDR in Vancouver. The goal of this draft is to clarify deployed behavior of the flowspec redirect extended community. My desire post presentation is for WG adoption and possibly simultaneous WGLC. This is just errata that we wish to codify in RFC sooner than later. -- Jeff ----- Forwarded message from internet-drafts@ietf.org ----- Date: Tue, 05 Nov 2013 13:57:53 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-haas-idr-flowspec-redirect-rt-bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Clarification of the Flowspec Redirect Extended Community Author(s) : Jeffrey Haas Filename : draft-haas-idr-flowspec-redirect-rt-bis-00.txt Pages : 5 Date : 2013-11-05 Abstract: This document clarifies the formatting of the the BGP Flowspec Redirect Extended Community, originally documented in RFC 5575. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haas-idr-flowspec-redirect-rt-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-haas-idr-flowspec-redirect-rt-bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 ----- End forwarded message ----- From jayb@braeburn.org Tue Nov 5 19:52:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A71D21E80DC for ; Tue, 5 Nov 2013 19:52:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xhpVf30QJEo for ; Tue, 5 Nov 2013 19:52:30 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id A06E921F9DC9 for ; Tue, 5 Nov 2013 19:51:35 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 6ccb9725.0.857817.00-188.2409800.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 06 Nov 2013 03:51:35 +0000 (UTC) X-MXL-Hash: 5279bcc713f4f803-adc9dba342cc55cfb8b56090bb641df004c33823 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rA63pYCB029906 for ; Tue, 5 Nov 2013 22:51:34 -0500 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rA63pUdx029881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 5 Nov 2013 22:51:32 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Wed, 6 Nov 2013 03:51:18 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id rA63pIjq021958 for ; Tue, 5 Nov 2013 22:51:18 -0500 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id rA63pBW4021833 for ; Tue, 5 Nov 2013 22:51:12 -0500 Received: by oz.mt.att.com (Postfix, from userid 1000) id 2F886681FC8; Tue, 5 Nov 2013 22:51:11 -0500 (EST) X-Mailer: emacs 23.3.1 (via feedmail 8 I); VM 8.2.0b under 23.3.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21113.48296.396769.745319@oz.mt.att.com> Date: Tue, 5 Nov 2013 22:51:04 -0500 From: Jay Borkenhagen To: "idr@ietf.org" In-Reply-To: <548411C6-315A-43F1-B5AC-C48E9EE57C54@ericsson.com> References: <21111.50401.542862.187680@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB5DF4@eusaamb109.ericsson.se> <8ED5B0B0F5B4854A912480C1521F973A11ABEF13@xmb-rcd-x13.cisco.com> <548411C6-315A-43F1-B5AC-C48E9EE57C54@ericsson.com> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 X-RSA-Inspected: yes X-RSA-Classifications: public Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jay Borkenhagen List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 03:52:36 -0000 Top-posting here because we already have a formatting mish-mash. I agree that if add-path capability is negotiated but a sender omits the PathID, this will result in length error. That is why I initially wrote "I presume this situation would be a NOTIFY-worthy protocol error condition." But I still believe more care needs to be taken for the other case, namely: A and B negotiate that A will announce to B with add-path. A announces prefix-1, using PathID-1 in so doing. Later A withdraws prefix-1, using PathID-2. Suppose this situation occurs because of an off-by-one or other logic error in managing PathIDs in A's implementation, and now A will never again update prefix-1 using PathID-1. That PathID-1/prefix-1 will never be removed from B's RIB-IN until someone (a person) notices that the prefix-1 route learned from A is no longer forwarding correctly. Prior to add-path, the situation is different: a gratuitous withdrawal won't hurt (other than possibly causing needless work) and it will be effective in removing any state that might earlier have been created. Jakob Heitz writes: > Good point. Didn't think enough. > > -- > Jakob Heitz. > > > On Nov 4, 2013, at 6:25 PM, "Saikat Ray (sairay)" wrote: > > > > -----Original Message----- > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz > > Sent: Monday, November 04, 2013 6:19 PM > > To: Jay Borkenhagen; idr@ietf.org > > Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 > > > > Withdraw for non-existent path: > > BGP is permitted to do that without add-path. > > My vote would be to do the same with add-path: ignore it. > > You said never-existed path. I can not tell the difference between a once-existed-and-now-gone path and a never-existed path. > > > > Send add-path capability, but send updates without path-id: > > > > [SR] What does it mean to say "without path ID"? If the BGP speaker is expecting an "add-path NLRI" (because the capabilities are exchanged at least one way), then it will always parse the first 4 octets as the ID. If the sender didn't actually add the Path ID field in the NLRI, it will (most likely) run into a parsing error (a length error somewhere), in which case it has to reset the neighbor session. > > > > > > I can not see a reason for doing this, so consider it an error. > > My vote would be to treat it as withdraw, in accordance with the error-handling draft. > > That is: withdraw all paths with that prefix from this speaker. And log an error, of course. > > > > Thanks, > > Jakob. > > > > -----Original Message----- > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jay Borkenhagen > > Sent: Monday, November 04, 2013 8:02 AM > > To: idr@ietf.org > > Subject: [Idr] comments on draft-ietf-idr-add-paths-09 > > > > Some comments on draft-ietf-idr-add-paths-09: > > > > The second paragraph of Section 5 now reads: > > > > A BGP speaker that is willing to receive multiple paths from its > > peer, or would like to send multiple paths to its peer, SHOULD > > advertise the ADD-PATH Capability to the peer using BGP > > Capabilities advertisement [RFC5492]. > > > > BGP speakers *hate* being anthropomorphized, so I would recommend removing terms such as "is willing" and "would like to". Also, this use of "SHOULD" should be changed: "SHOULD" implies that add-path might still happen in this session even if the ADD-PATH capabilities advertisements do not occur -- that ain't gonna happen. Let me > > propose: > > > > For a BGP speaker to be able to send multiple paths to its peer, > > that BGP speaker MUST advertise the ADD-PATH 'send' capability to > > the peer AND that peer MUST advertise the ADD-PATH 'receive' > > capability to the BGP speaker, using BGP Capabilities advertisement > > [RFC5492]. > > > > OR possibly you should delete this second paragraph entirely -- I think the current third paragraph specifies this requirement well enough. > > > > > > The draft needs to specify how certain conditions should be dealt with. Suppose router A and router B agree that A will send to B using add-path. > > > > - What should B do if an update received from A is a withdrawal containing a Path Identifier not seen previously, while B had previously received from A an announcement for the same prefix with a different Path Identifier? One implementation might be strict in interpreting the withdrawal as gratuitous and leave the received annoucement in place, while another might conclude that the odd withdrawal is a sign that router A has lost track of which Path Identifiers it has used for which announced prefixes, and take some other action. This standard should specify which interpretation should be used. > > > > - What should B do if an update received from A does not include any Path Identifier? (I presume this situation would be a NOTIFY-worthy protocol error condition.) > > > > _______________________________________________ > > 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 jakob.heitz@ericsson.com Tue Nov 5 21:32:27 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C9311E8131 for ; Tue, 5 Nov 2013 21:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVb8ovyNczlM for ; Tue, 5 Nov 2013 21:32:16 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 96BFE11E80F8 for ; Tue, 5 Nov 2013 21:32:13 -0800 (PST) X-AuditID: c6180641-b7f3f8e000000a05-57-5279d45cb617 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id AD.A8.02565.C54D9725; Wed, 6 Nov 2013 06:32:12 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Wed, 6 Nov 2013 00:32:11 -0500 From: Jakob Heitz To: Jay Borkenhagen , "idr@ietf.org" Thread-Topic: [Idr] comments on draft-ietf-idr-add-paths-09 Thread-Index: AQHO2XdeOrK/B1KFCUKtlJ+iRCHhZZoV4nsggABbCID//63gw4AB/FQA///HyqY= Date: Wed, 6 Nov 2013 05:32:10 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB768B@eusaamb109.ericsson.se> References: <21111.50401.542862.187680@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB5DF4@eusaamb109.ericsson.se> <8ED5B0B0F5B4854A912480C1521F973A11ABEF13@xmb-rcd-x13.cisco.com> <548411C6-315A-43F1-B5AC-C48E9EE57C54@ericsson.com>, <21113.48296.396769.745319@oz.mt.att.com> In-Reply-To: <21113.48296.396769.745319@oz.mt.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyuXRPuG7Mlcogg6uzlS1e3X7GZLHs+F52 ByaPR9MeMXksWfKTKYApissmJTUnsyy1SN8ugStj/dsnbAXrjSr+/l7P0sB4U6OLkZNDQsBE Yvfqf0wQtpjEhXvr2boYuTiEBI4wSqxZf4MZwlnGKLF8/mJ2kCo2AR2Jb9e7mEFsEQE3iV2X NoJ1CwtYSTRdfsMEEbeWeP+okRHC9pO4/uwtK4jNIqAi8XV6M5jNK+Ar8WpPAxPEgjlMEieO bQZLcAqYSbz42AW2jBHopO+n1oANZRYQl7j1ZD7UqQISS/acZ4awRSVePv7HCmErS3yf84gF ol5HYsHuT2wQtrbEsoWvmSEWC0qcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctON DDcxAiPimASb4w7GBZ8sDzFKc7AoifN+eescJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR d/PO5CaFB0fa3Doz7kXOvzHzgeObc93r1/+Witl3Ov7Kr7+10+Udu4Ldcv5Ovm3HvIu18ZLm /8fTj2VET2CR2KH6wOfQb8/OO8smJk+2DZu4LfzGlIk3nO2C2Syl9jLOMEu/1vFzbuEL0dlf XdVfpyy8L3upNCXd/bNjisDmhqN8Mvfab1koK7EUZyQaajEXFScCAGPxFtdWAgAA Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 05:32:27 -0000 How can you tell the difference between a gratuitous withdrawal and this er= ror?=0A= =0A= --=0A= =0A= Jakob Heitz.=0A= =0A= ________________________________________=0A= From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Jay Borkenha= gen [jayb@braeburn.org]=0A= Sent: Tuesday, 05 November 2013 7:51 PM=0A= To: idr@ietf.org=0A= Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09=0A= =0A= Top-posting here because we already have a formatting mish-mash.=0A= =0A= I agree that if add-path capability is negotiated but a sender omits=0A= the PathID, this will result in length error. That is why I=0A= initially wrote "I presume this situation would be a NOTIFY-worthy=0A= protocol error condition."=0A= =0A= =0A= But I still believe more care needs to be taken for the other case,=0A= namely:=0A= =0A= A and B negotiate that A will announce to B with add-path.=0A= =0A= A announces prefix-1, using PathID-1 in so doing.=0A= =0A= Later A withdraws prefix-1, using PathID-2.=0A= =0A= =0A= Suppose this situation occurs because of an off-by-one or other logic=0A= error in managing PathIDs in A's implementation, and now A will never=0A= again update prefix-1 using PathID-1. That PathID-1/prefix-1 will=0A= never be removed from B's RIB-IN until someone (a person) notices that=0A= the prefix-1 route learned from A is no longer forwarding correctly.=0A= =0A= Prior to add-path, the situation is different: a gratuitous withdrawal=0A= won't hurt (other than possibly causing needless work) and it will be=0A= effective in removing any state that might earlier have been created.=0A= =0A= =0A= =0A= =0A= =0A= Jakob Heitz writes:=0A= > Good point. Didn't think enough.=0A= >=0A= > --=0A= > Jakob Heitz.=0A= >=0A= > > On Nov 4, 2013, at 6:25 PM, "Saikat Ray (sairay)" w= rote:=0A= > >=0A= > > -----Original Message-----=0A= > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Jakob Heitz=0A= > > Sent: Monday, November 04, 2013 6:19 PM=0A= > > To: Jay Borkenhagen; idr@ietf.org=0A= > > Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09=0A= > >=0A= > > Withdraw for non-existent path:=0A= > > BGP is permitted to do that without add-path.=0A= > > My vote would be to do the same with add-path: ignore it.=0A= > > You said never-existed path. I can not tell the difference between a o= nce-existed-and-now-gone path and a never-existed path.=0A= > >=0A= > > Send add-path capability, but send updates without path-id:=0A= > >=0A= > > [SR] What does it mean to say "without path ID"? If the BGP speaker is= expecting an "add-path NLRI" (because the capabilities are exchanged at le= ast one way), then it will always parse the first 4 octets as the ID. If th= e sender didn't actually add the Path ID field in the NLRI, it will (most l= ikely) run into a parsing error (a length error somewhere), in which case i= t has to reset the neighbor session.=0A= > >=0A= > >=0A= > > I can not see a reason for doing this, so consider it an error.=0A= > > My vote would be to treat it as withdraw, in accordance with the error= -handling draft.=0A= > > That is: withdraw all paths with that prefix from this speaker. And lo= g an error, of course.=0A= > >=0A= > > Thanks,=0A= > > Jakob.=0A= > >=0A= > > -----Original Message-----=0A= > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Jay Borkenhagen=0A= > > Sent: Monday, November 04, 2013 8:02 AM=0A= > > To: idr@ietf.org=0A= > > Subject: [Idr] comments on draft-ietf-idr-add-paths-09=0A= > >=0A= > > Some comments on draft-ietf-idr-add-paths-09:=0A= > >=0A= > > The second paragraph of Section 5 now reads:=0A= > >=0A= > > A BGP speaker that is willing to receive multiple paths from its=0A= > > peer, or would like to send multiple paths to its peer, SHOULD=0A= > > advertise the ADD-PATH Capability to the peer using BGP=0A= > > Capabilities advertisement [RFC5492].=0A= > >=0A= > > BGP speakers *hate* being anthropomorphized, so I would recommend remo= ving terms such as "is willing" and "would like to". Also, this use of "SH= OULD" should be changed: "SHOULD" implies that add-path might still happen = in this session even if the ADD-PATH capabilities advertisements do not occ= ur -- that ain't gonna happen. Let me=0A= > > propose:=0A= > >=0A= > > For a BGP speaker to be able to send multiple paths to its peer,=0A= > > that BGP speaker MUST advertise the ADD-PATH 'send' capability to=0A= > > the peer AND that peer MUST advertise the ADD-PATH 'receive'=0A= > > capability to the BGP speaker, using BGP Capabilities advertisement= =0A= > > [RFC5492].=0A= > >=0A= > > OR possibly you should delete this second paragraph entirely -- I thin= k the current third paragraph specifies this requirement well enough.=0A= > >=0A= > >=0A= > > The draft needs to specify how certain conditions should be dealt with= . Suppose router A and router B agree that A will send to B using add-path.= =0A= > >=0A= > > - What should B do if an update received from A is a withdrawal contai= ning a Path Identifier not seen previously, while B had previously received= from A an announcement for the same prefix with a different Path Identifie= r? One implementation might be strict in interpreting the withdrawal as gr= atuitous and leave the received annoucement in place, while another might c= onclude that the odd withdrawal is a sign that router A has lost track of w= hich Path Identifiers it has used for which announced prefixes, and take so= me other action. This standard should specify which interpretation should = be used.=0A= > >=0A= > > - What should B do if an update received from A does not include any P= ath Identifier? (I presume this situation would be a NOTIFY-worthy protoco= l error condition.)=0A= > >=0A= > > _______________________________________________=0A= > > Idr mailing list=0A= > > Idr@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/idr=0A= > > _______________________________________________=0A= > > Idr mailing list=0A= > > Idr@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/idr=0A= _______________________________________________=0A= Idr mailing list=0A= Idr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/idr=0A= From jayb@braeburn.org Wed Nov 6 05:29:11 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3EA11E8168 for ; Wed, 6 Nov 2013 05:29:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Stf3bjuisFh for ; Wed, 6 Nov 2013 05:29:05 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 37B0521F9ECA for ; Wed, 6 Nov 2013 05:29:05 -0800 (PST) Received: from unknown [144.160.229.23] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 1244a725.6606c940.3572112.00-537.9991866.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 06 Nov 2013 13:29:05 +0000 (UTC) X-MXL-Hash: 527a44212db67442-5b08d2f8d7f6a4570feba480c6355da4da625d29 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id e144a725.0.3572098.00-279.9991827.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 06 Nov 2013 13:29:04 +0000 (UTC) X-MXL-Hash: 527a44207f5cb576-d96fd74cb6dfc3fa40cba3f0142f19367b5684bf Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rA6DT2Aj022157; Wed, 6 Nov 2013 08:29:02 -0500 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rA6DSwUW022143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Nov 2013 08:28:59 -0500 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 6 Nov 2013 13:28:41 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id rA6DSfD8013548; Wed, 6 Nov 2013 08:28:41 -0500 Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id rA6DSaWM013381; Wed, 6 Nov 2013 08:28:36 -0500 Received: by oz.mt.att.com (Postfix, from userid 1000) id 8009C681ECF; Wed, 6 Nov 2013 08:28:35 -0500 (EST) X-Mailer: emacs 23.3.1 (via feedmail 8 I); VM 8.2.0b under 23.3.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21114.17410.159355.826952@oz.mt.att.com> Date: Wed, 6 Nov 2013 08:28:34 -0500 From: Jay Borkenhagen To: Jakob Heitz In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB768B@eusaamb109.ericsson.se> References: <21111.50401.542862.187680@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB5DF4@eusaamb109.ericsson.se> <8ED5B0B0F5B4854A912480C1521F973A11ABEF13@xmb-rcd-x13.cisco.com> <548411C6-315A-43F1-B5AC-C48E9EE57C54@ericsson.com> <21113.48296.396769.745319@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB768B@eusaamb109.ericsson.se> X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0 X-RSA-Inspected: yes X-RSA-Classifications: public Cc: "idr@ietf.org" Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Jay Borkenhagen List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 13:29:11 -0000 Precisely! So while in regular BGP a gratuitous withdrawal might be no big deal, with add-path it could be one of the few things a receiver could look for as a sign that the sender has lost its mind. Summing up: to create add-path's value, the draft introduces the Path Identifier which carries no semantics. But in doing so some new ambiguities are created. Perhaps the requirements of add-path receivers should be tightened w.r.t. regular BGP receivers to eliminate/control the ambiguities. For the specific case in point: if there is no demonstrably good reason to send an explicit withdrawal using a Path Identifier that had not been used to announce the same prefix, then perhaps it should not be allowed. That's what I wanted to say. I would very much like to hear the [respected] authors' reactions. Jakob Heitz writes: > How can you tell the difference between a gratuitous withdrawal and this error? > > -- > > Jakob Heitz. > > ________________________________________ > From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Jay Borkenhagen [jayb@braeburn.org] > Sent: Tuesday, 05 November 2013 7:51 PM > To: idr@ietf.org > Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 > > Top-posting here because we already have a formatting mish-mash. > > I agree that if add-path capability is negotiated but a sender omits > the PathID, this will result in length error. That is why I > initially wrote "I presume this situation would be a NOTIFY-worthy > protocol error condition." > > > But I still believe more care needs to be taken for the other case, > namely: > > A and B negotiate that A will announce to B with add-path. > > A announces prefix-1, using PathID-1 in so doing. > > Later A withdraws prefix-1, using PathID-2. > > > Suppose this situation occurs because of an off-by-one or other logic > error in managing PathIDs in A's implementation, and now A will never > again update prefix-1 using PathID-1. That PathID-1/prefix-1 will > never be removed from B's RIB-IN until someone (a person) notices that > the prefix-1 route learned from A is no longer forwarding correctly. > > Prior to add-path, the situation is different: a gratuitous withdrawal > won't hurt (other than possibly causing needless work) and it will be > effective in removing any state that might earlier have been created. > > > > > > Jakob Heitz writes: > > Good point. Didn't think enough. > > > > -- > > Jakob Heitz. > > > > > On Nov 4, 2013, at 6:25 PM, "Saikat Ray (sairay)" wrote: > > > > > > -----Original Message----- > > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz > > > Sent: Monday, November 04, 2013 6:19 PM > > > To: Jay Borkenhagen; idr@ietf.org > > > Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 > > > > > > Withdraw for non-existent path: > > > BGP is permitted to do that without add-path. > > > My vote would be to do the same with add-path: ignore it. > > > You said never-existed path. I can not tell the difference between a once-existed-and-now-gone path and a never-existed path. > > > > > > Send add-path capability, but send updates without path-id: > > > > > > [SR] What does it mean to say "without path ID"? If the BGP speaker is expecting an "add-path NLRI" (because the capabilities are exchanged at least one way), then it will always parse the first 4 octets as the ID. If the sender didn't actually add the Path ID field in the NLRI, it will (most likely) run into a parsing error (a length error somewhere), in which case it has to reset the neighbor session. > > > > > > > > > I can not see a reason for doing this, so consider it an error. > > > My vote would be to treat it as withdraw, in accordance with the error-handling draft. > > > That is: withdraw all paths with that prefix from this speaker. And log an error, of course. > > > > > > Thanks, > > > Jakob. > > > > > > -----Original Message----- > > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jay Borkenhagen > > > Sent: Monday, November 04, 2013 8:02 AM > > > To: idr@ietf.org > > > Subject: [Idr] comments on draft-ietf-idr-add-paths-09 > > > > > > Some comments on draft-ietf-idr-add-paths-09: > > > > > > The second paragraph of Section 5 now reads: > > > > > > A BGP speaker that is willing to receive multiple paths from its > > > peer, or would like to send multiple paths to its peer, SHOULD > > > advertise the ADD-PATH Capability to the peer using BGP > > > Capabilities advertisement [RFC5492]. > > > > > > BGP speakers *hate* being anthropomorphized, so I would recommend removing terms such as "is willing" and "would like to". Also, this use of "SHOULD" should be changed: "SHOULD" implies that add-path might still happen in this session even if the ADD-PATH capabilities advertisements do not occur -- that ain't gonna happen. Let me > > > propose: > > > > > > For a BGP speaker to be able to send multiple paths to its peer, > > > that BGP speaker MUST advertise the ADD-PATH 'send' capability to > > > the peer AND that peer MUST advertise the ADD-PATH 'receive' > > > capability to the BGP speaker, using BGP Capabilities advertisement > > > [RFC5492]. > > > > > > OR possibly you should delete this second paragraph entirely -- I think the current third paragraph specifies this requirement well enough. > > > > > > > > > The draft needs to specify how certain conditions should be dealt with. Suppose router A and router B agree that A will send to B using add-path. > > > > > > - What should B do if an update received from A is a withdrawal containing a Path Identifier not seen previously, while B had previously received from A an announcement for the same prefix with a different Path Identifier? One implementation might be strict in interpreting the withdrawal as gratuitous and leave the received annoucement in place, while another might conclude that the odd withdrawal is a sign that router A has lost track of which Path Identifiers it has used for which announced prefixes, and take some other action. This standard should specify which interpretation should be used. > > > > > > - What should B do if an update received from A does not include any Path Identifier? (I presume this situation would be a NOTIFY-worthy protocol error condition.) > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From sairay@cisco.com Wed Nov 6 09:02:26 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDC411E821F for ; Wed, 6 Nov 2013 09:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy5b8UIjwV1C for ; Wed, 6 Nov 2013 09:02:20 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5F90521F9CDA for ; Wed, 6 Nov 2013 09:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7890; q=dns/txt; s=iport; t=1383757314; x=1384966914; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lwLdK4CVo/8y3K7PLYVDQupSe2NYNcGWDvCKnsNojQc=; b=dqxCEc1T/Nd6cpuNVKQ0QLr9RSZ17fgUz1AYa7kUj1aK6ACANJwko4Wf 9nOxrBOmeYJDYTXCuEVfhGdCJlK3fNOHgXxa6qsBtFurkaQlP5Hof9NCb jE3VxW7HLl7XwkqaLpom56P3gdVblpqpXhlXfc2CmElkNTCkyMF1otOyy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAGR1elKtJXG8/2dsb2JhbABagwc4U782gSQWdIIlAQEBBAEBATctBwsMBAIBCBEEAQEBChQJBycLFAkIAgQBDQUIh3kNvx4EjygxBwaDGoEQA4xXkm2KUoMmgWgHOw X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208";a="281495763" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 06 Nov 2013 17:01:49 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA6H1mDG024818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 17:01:48 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.14]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 11:01:48 -0600 From: "Saikat Ray (sairay)" To: Jay Borkenhagen , Jakob Heitz Thread-Topic: [Idr] comments on draft-ietf-idr-add-paths-09 Thread-Index: AQHO2qNqCtyw5FMEpUGgU5aX0sisP5oYEmIAgACFGwD//9ZCcA== Date: Wed, 6 Nov 2013 17:01:48 +0000 Message-ID: <8ED5B0B0F5B4854A912480C1521F973A11AC016C@xmb-rcd-x13.cisco.com> References: <21111.50401.542862.187680@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB5DF4@eusaamb109.ericsson.se> <8ED5B0B0F5B4854A912480C1521F973A11ABEF13@xmb-rcd-x13.cisco.com> <548411C6-315A-43F1-B5AC-C48E9EE57C54@ericsson.com> <21113.48296.396769.745319@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB768B@eusaamb109.ericsson.se> <21114.17410.159355.826952@oz.mt.att.com> In-Reply-To: <21114.17410.159355.826952@oz.mt.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.148.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:02:26 -0000 The path-id is part of the NLRI key. If the id is changed, it is a differen= t key. So first sending a prefix with id 10, and then sending a withdraw wi= th the same prefix with id 20 is no different from the case where sender fi= rst sends 1.1.1.1/32 and then sends a withdraw for 0.1.1.1/32. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jay B= orkenhagen Sent: Wednesday, November 06, 2013 5:29 AM To: Jakob Heitz Cc: idr@ietf.org Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 Precisely! So while in regular BGP a gratuitous withdrawal might be no big deal, with = add-path it could be one of the few things a receiver could look for as a s= ign that the sender has lost its mind. Summing up: to create add-path's value, the draft introduces the Path Ident= ifier which carries no semantics. But in doing so some new ambiguities are= created. Perhaps the requirements of add-path receivers should be tighten= ed w.r.t. regular BGP receivers to eliminate/control the ambiguities. For = the specific case in point: if there is no demonstrably good reason to send= an explicit withdrawal using a Path Identifier that had not been used to a= nnounce the same prefix, then perhaps it should not be allowed. That's what I wanted to say. I would very much like to hear the [respected= ] authors' reactions. Jakob Heitz writes: > How can you tell the difference between a gratuitous withdrawal and this= error? > > -- > > Jakob Heitz. > > ________________________________________ > From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Jay Borke= nhagen [jayb@braeburn.org] > Sent: Tuesday, 05 November 2013 7:51 PM > To= : idr@ietf.org > Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-0= 9 > > Top-posting here because we already have a formatting mish-mash. > > I agree that if add-path capability is negotiated but a sender omits > = the PathID, this will result in length error. That is why I > initially w= rote "I presume this situation would be a NOTIFY-worthy > protocol error c= ondition." > > > But I still believe more care needs to be taken for the other case, > n= amely: > > A and B negotiate that A will announce to B with add-path. > > A announces prefix-1, using PathID-1 in so doing. > > Later A withdraws prefix-1, using PathID-2. > > > Suppose this situation occurs because of an off-by-one or other logic >= error in managing PathIDs in A's implementation, and now A will never > a= gain update prefix-1 using PathID-1. That PathID-1/prefix-1 will > never = be removed from B's RIB-IN until someone (a person) notices that > the pre= fix-1 route learned from A is no longer forwarding correctly. > > Prior to add-path, the situation is different: a gratuitous withdrawal = > won't hurt (other than possibly causing needless work) and it will be > = effective in removing any state that might earlier have been created. > > > > > > Jakob Heitz writes: > > Good point. Didn't think enough. > > > > -- > > Jakob Heitz. > > > > > On Nov 4, 2013, at 6:25 PM, "Saikat Ray (sairay)" wrote: > > > > > > -----Original Message----- > > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf = Of Jakob Heitz > > > Sent: Monday, November 04, 2013 6:19 PM > > > To: = Jay Borkenhagen; idr@ietf.org > > > Subject: Re: [Idr] comments on draft-= ietf-idr-add-paths-09 > > > > > > Withdraw for non-existent path: > > > BGP is permitted to do that without add-path. > > > My vote would be to do the same with add-path: ignore it. > > > You said never-existed path. I can not tell the difference between = a once-existed-and-now-gone path and a never-existed path. > > > > > > Send add-path capability, but send updates without path-id: > > > > > > [SR] What does it mean to say "without path ID"? If the BGP speaker= is expecting an "add-path NLRI" (because the capabilities are exchanged at= least one way), then it will always parse the first 4 octets as the ID. If= the sender didn't actually add the Path ID field in the NLRI, it will (mos= t likely) run into a parsing error (a length error somewhere), in which cas= e it has to reset the neighbor session. > > > > > > > > > I can not see a reason for doing this, so consider it an error. > > > My vote would be to treat it as withdraw, in accordance with the er= ror-handling draft. > > > That is: withdraw all paths with that prefix from this speaker. And= log an error, of course. > > > > > > Thanks, > > > Jakob. > > > > > > -----Original Message----- > > > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf = Of Jay Borkenhagen > > > Sent: Monday, November 04, 2013 8:02 AM > > > = To: idr@ietf.org > > > Subject: [Idr] comments on draft-ietf-idr-add-path= s-09 > > > > > > Some comments on draft-ietf-idr-add-paths-09: > > > > > > The second paragraph of Section 5 now reads: > > > > > > A BGP speaker that is willing to receive multiple paths from its > > > peer, or would like to send multiple paths to its peer, SHOULD > > > advertise the ADD-PATH Capability to the peer using BGP > > > Capabilities advertisement [RFC5492]. > > > > > > BGP speakers *hate* being anthropomorphized, so I would recommend r= emoving terms such as "is willing" and "would like to". Also, this use of = "SHOULD" should be changed: "SHOULD" implies that add-path might still happ= en in this session even if the ADD-PATH capabilities advertisements do not = occur -- that ain't gonna happen. Let me > > > propose: > > > > > > For a BGP speaker to be able to send multiple paths to its peer, > > > that BGP speaker MUST advertise the ADD-PATH 'send' capability to > > > the peer AND that peer MUST advertise the ADD-PATH 'receive' > > > capability to the BGP speaker, using BGP Capabilities advertiseme= nt > > > [RFC5492]. > > > > > > OR possibly you should delete this second paragraph entirely -- I t= hink the current third paragraph specifies this requirement well enough. > > > > > > > > > The draft needs to specify how certain conditions should be dealt w= ith. Suppose router A and router B agree that A will send to B using add-pa= th. > > > > > > - What should B do if an update received from A is a withdrawal con= taining a Path Identifier not seen previously, while B had previously recei= ved from A an announcement for the same prefix with a different Path Identi= fier? One implementation might be strict in interpreting the withdrawal as= gratuitous and leave the received annoucement in place, while another migh= t conclude that the odd withdrawal is a sign that router A has lost track o= f which Path Identifiers it has used for which announced prefixes, and take= some other action. This standard should specify which interpretation shou= ld be used. > > > > > > - What should B do if an update received from A does not include an= y Path Identifier? (I presume this situation would be a NOTIFY-worthy prot= ocol error condition.) > > > > > > ____________________________________= ___________ > > > 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 > _______________________________________________ > 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 jakob.heitz@ericsson.com Wed Nov 6 09:17:30 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C5A21E8115 for ; Wed, 6 Nov 2013 09:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TX2jNxh9bk-e for ; Wed, 6 Nov 2013 09:17:25 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 72DFE11E8112 for ; Wed, 6 Nov 2013 09:17:25 -0800 (PST) X-AuditID: c6180641-b7f158e0000006b6-40-527a799d1d0b Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 2F.20.01718.E997A725; Wed, 6 Nov 2013 18:17:18 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Wed, 6 Nov 2013 12:17:17 -0500 From: Jakob Heitz To: "Saikat Ray (sairay)" Thread-Topic: [Idr] comments on draft-ietf-idr-add-paths-09 Thread-Index: AQHO2XdeOrK/B1KFCUKtlJ+iRCHhZZoV4nsggABbCID//63gw4AB/FQA///HyqaAANmQAIAAO5QA//+wgZY= Date: Wed, 6 Nov 2013 17:17:16 +0000 Message-ID: References: <21111.50401.542862.187680@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB5DF4@eusaamb109.ericsson.se> <8ED5B0B0F5B4854A912480C1521F973A11ABEF13@xmb-rcd-x13.cisco.com> <548411C6-315A-43F1-B5AC-C48E9EE57C54@ericsson.com> <21113.48296.396769.745319@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB768B@eusaamb109.ericsson.se> <21114.17410.159355.826952@oz.mt.att.com>, <8ED5B0B0F5B4854A912480C1521F973A11AC016C@xmb-rcd-x13.cisco.com> In-Reply-To: <8ED5B0B0F5B4854A912480C1521F973A11AC016C@xmb-rcd-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXRPuO68yqogg5OH1Sxe3X7GZLHs+F52 iz2HlrM5MHs8mvaIyWPK742sHkuW/GQKYI7isklJzcksSy3St0vgynjaIVXQ6lix+shp9gbG 8yZdjBwcEgImEosvR3UxcgKZYhIX7q1n62Lk4hASOMIosXL7HhYIZxmjxPUpsxhBqtgEdCS+ Xe9iBrFFgOye6zvYQGxmATeJd8cXsIPYwgJWEidWPGCFqLGWeP+okRHCTpJ4vHgpmM0ioCJx 4+p8MJtXwF5i7v13YL1CAueZJfoXx4DYnAK+Er3nOplAbEag676fWsMEsUtc4taT+UwQVwtI LNlznhnCFpV4+fgfK0SNjsSC3Z+gbtOWWLbwNTPELkGJkzOfsExgFJ2FZNQsJC2zkLTMQtKy gJFlFSNHaXFqWW66keEmRmB8HJNgc9zBuOCT5SFGaQ4WJXHeL2+dg4QE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwiufXRHoIh8WxxyRdqJk8OfRn6qq2LU353x1iREO0f8UezD8s4v3pbq4i 68XPhfNWT6xlXvS5XsxqS0Fq/qLVUpU8P2pjv9j+9G+bw2daIrh6ZdSnXbah16Xf/FQ4F2r2 fqFhx5T1uy+U719pHb1o+Zk56Sb7l0x1vOC33UqbyeV0S13zpAduSizFGYmGWsxFxYkAbPbr Hl0CAAA= Cc: "idr@ietf.org" , Jay Borkenhagen Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:17:30 -0000 Yes, the ambiguity exists with or without add-path. To provide a demonstrably good reason not to treat the ambiguity as an erro= r, a BGP receiver frequently discards received paths due to policy. Non imp= orted route target is an example. To detect the bad withdrawal, the receive= r would have to keep all received paths. It's not worth it. -- Jakob Heitz. On Nov 6, 2013, at 9:01 AM, "Saikat Ray (sairay)" wrote: > The path-id is part of the NLRI key. If the id is changed, it is a differ= ent key. So first sending a prefix with id 10, and then sending a withdraw = with the same prefix with id 20 is no different from the case where sender = first sends 1.1.1.1/32 and then sends a withdraw for 0.1.1.1/32. >=20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jay= Borkenhagen > Sent: Wednesday, November 06, 2013 5:29 AM > To: Jakob Heitz > Cc: idr@ietf.org > Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 >=20 > Precisely! >=20 > So while in regular BGP a gratuitous withdrawal might be no big deal, wit= h add-path it could be one of the few things a receiver could look for as a= sign that the sender has lost its mind. >=20 > Summing up: to create add-path's value, the draft introduces the Path Ide= ntifier which carries no semantics. But in doing so some new ambiguities a= re created. Perhaps the requirements of add-path receivers should be tight= ened w.r.t. regular BGP receivers to eliminate/control the ambiguities. Fo= r the specific case in point: if there is no demonstrably good reason to se= nd an explicit withdrawal using a Path Identifier that had not been used to= announce the same prefix, then perhaps it should not be allowed. >=20 > That's what I wanted to say. I would very much like to hear the [respect= ed] authors' reactions. >=20 >=20 >=20 > Jakob Heitz writes: >> How can you tell the difference between a gratuitous withdrawal and this= error? >>=20 >> -- >>=20 >> Jakob Heitz. >>=20 >> ________________________________________ >> From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Jay Borke= nhagen [jayb@braeburn.org] > Sent: Tuesday, 05 November 2013 7:51 PM > To= : idr@ietf.org > Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-0= 9 > > Top-posting here because we already have a formatting mish-mash. >>=20 >> I agree that if add-path capability is negotiated but a sender omits > = the PathID, this will result in length error. That is why I > initially w= rote "I presume this situation would be a NOTIFY-worthy > protocol error c= ondition." >>=20 >>=20 >> But I still believe more care needs to be taken for the other case, > n= amely: >>=20 >> A and B negotiate that A will announce to B with add-path. >>=20 >> A announces prefix-1, using PathID-1 in so doing. >>=20 >> Later A withdraws prefix-1, using PathID-2. >>=20 >>=20 >> Suppose this situation occurs because of an off-by-one or other logic >= error in managing PathIDs in A's implementation, and now A will never > a= gain update prefix-1 using PathID-1. That PathID-1/prefix-1 will > never = be removed from B's RIB-IN until someone (a person) notices that > the pre= fix-1 route learned from A is no longer forwarding correctly. >>=20 >> Prior to add-path, the situation is different: a gratuitous withdrawal = > won't hurt (other than possibly causing needless work) and it will be > = effective in removing any state that might earlier have been created. >>=20 >>=20 >>=20 >>=20 >>=20 >> Jakob Heitz writes: >>> Good point. Didn't think enough. >>>=20 >>> -- >>> Jakob Heitz. >>>=20 >>>> On Nov 4, 2013, at 6:25 PM, "Saikat Ray (sairay)" w= rote: >>>>=20 >>>> -----Original Message----- >>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Jakob Heitz > > > Sent: Monday, November 04, 2013 6:19 PM > > > To: Jay= Borkenhagen; idr@ietf.org > > > Subject: Re: [Idr] comments on draft-iet= f-idr-add-paths-09 > > > > > > Withdraw for non-existent path: >>>> BGP is permitted to do that without add-path. >>>> My vote would be to do the same with add-path: ignore it. >>>> You said never-existed path. I can not tell the difference between a o= nce-existed-and-now-gone path and a never-existed path. >>>>=20 >>>> Send add-path capability, but send updates without path-id: >>>>=20 >>>> [SR] What does it mean to say "without path ID"? If the BGP speaker is= expecting an "add-path NLRI" (because the capabilities are exchanged at le= ast one way), then it will always parse the first 4 octets as the ID. If th= e sender didn't actually add the Path ID field in the NLRI, it will (most l= ikely) run into a parsing error (a length error somewhere), in which case i= t has to reset the neighbor session. >>>>=20 >>>>=20 >>>> I can not see a reason for doing this, so consider it an error. >>>> My vote would be to treat it as withdraw, in accordance with the error= -handling draft. >>>> That is: withdraw all paths with that prefix from this speaker. And lo= g an error, of course. >>>>=20 >>>> Thanks, >>>> Jakob. >>>>=20 >>>> -----Original Message----- >>>> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Jay Borkenhagen > > > Sent: Monday, November 04, 2013 8:02 AM > > > To:= idr@ietf.org > > > Subject: [Idr] comments on draft-ietf-idr-add-paths-0= 9 > > > > > > Some comments on draft-ietf-idr-add-paths-09: >>>>=20 >>>> The second paragraph of Section 5 now reads: >>>>=20 >>>> A BGP speaker that is willing to receive multiple paths from its >>>> peer, or would like to send multiple paths to its peer, SHOULD >>>> advertise the ADD-PATH Capability to the peer using BGP >>>> Capabilities advertisement [RFC5492]. >>>>=20 >>>> BGP speakers *hate* being anthropomorphized, so I would recommend remo= ving terms such as "is willing" and "would like to". Also, this use of "SH= OULD" should be changed: "SHOULD" implies that add-path might still happen = in this session even if the ADD-PATH capabilities advertisements do not occ= ur -- that ain't gonna happen. Let me > > > propose: >>>>=20 >>>> For a BGP speaker to be able to send multiple paths to its peer, >>>> that BGP speaker MUST advertise the ADD-PATH 'send' capability to >>>> the peer AND that peer MUST advertise the ADD-PATH 'receive' >>>> capability to the BGP speaker, using BGP Capabilities advertisement >>>> [RFC5492]. >>>>=20 >>>> OR possibly you should delete this second paragraph entirely -- I thin= k the current third paragraph specifies this requirement well enough. >>>>=20 >>>>=20 >>>> The draft needs to specify how certain conditions should be dealt with= . Suppose router A and router B agree that A will send to B using add-path. >>>>=20 >>>> - What should B do if an update received from A is a withdrawal contai= ning a Path Identifier not seen previously, while B had previously received= from A an announcement for the same prefix with a different Path Identifie= r? One implementation might be strict in interpreting the withdrawal as gr= atuitous and leave the received annoucement in place, while another might c= onclude that the odd withdrawal is a sign that router A has lost track of w= hich Path Identifiers it has used for which announced prefixes, and take so= me other action. This standard should specify which interpretation should = be used. >>>>=20 >>>> - What should B do if an update received from A does not include any P= ath Identifier? (I presume this situation would be a NOTIFY-worthy protoco= l error condition.) > > > > > > _______________________________________= ________ >>>> 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 >> _______________________________________________ >> 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 jschiel@flowtools.net Wed Nov 6 12:52:02 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BE021F9FB5 for ; Wed, 6 Nov 2013 12:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfX5vu-xWQse for ; Wed, 6 Nov 2013 12:51:57 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3C41921F9ED4 for ; Wed, 6 Nov 2013 12:51:56 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so91727iet.18 for ; Wed, 06 Nov 2013 12:51:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UoFjtreI6feKyVO44G78h6AHHnOeOtt5s5hqYkmnIC8=; b=isAB8Q9QJKXcfVoYiyv9c5o2GSlakc16KrduVItE4cDmWGtuc/5JuKA/Bw7/5b6msy Wg7O2JUhjfcF08irUrZJq0Ke5cuPyOaeTpxzKgEl3biLh5Pd5UZRVEz8nh565STLmcX3 yVLno72wWiqA+a9l+znK6YXhHR+nrq1wWmDV7vTLu1rCO9gGddcyQzKunmxIIyyAPH6Q juIdWEsokLsQZcBVlUemfjfqSS1IaR90ohxCvXRgLyPckb73mYWY9m/FGZXxzezWhYjq YfqZ+v+BwguWxsQN5szMGHtws8wvrRy9pqWIvgv4zEpXMM3Y3eBxtQhz2kxPQcekE2uG U8ig== X-Gm-Message-State: ALoCoQkhhgq2YOjoTPCe6CesPTM5Avr83bKiZ6ZIxg3JeQ6mNHy65UtaDq0EHmtGk78ADR2ogQtG X-Received: by 10.50.128.137 with SMTP id no9mr3985011igb.36.1383771116356; Wed, 06 Nov 2013 12:51:56 -0800 (PST) Received: from handyj.ip.qwest.net (handyj.ip.qwest.net. [205.169.63.144]) by mx.google.com with ESMTPSA id m1sm15956396igj.10.2013.11.06.12.51.54 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 Nov 2013 12:51:55 -0800 (PST) Message-ID: <527AABDF.3020900@flowtools.net> Date: Wed, 06 Nov 2013 13:51:43 -0700 From: John User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Jeffrey Haas , idr@ietf.org References: <20131105220155.GA19411@pfrc> In-Reply-To: <20131105220155.GA19411@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-haas-idr-flowspec-redirect-rt-bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 20:52:02 -0000 On 11/05/2013 03:01 PM, Jeffrey Haas wrote: > Working Group, > > The following draft pertains to the brief presentation on this topic during > Friday's session at IDR in Vancouver. The goal of this draft is to clarify > deployed behavior of the flowspec redirect extended community. Jeff, Would you know if this presentation is available to share? --John > > My desire post presentation is for WG adoption and possibly simultaneous > WGLC. This is just errata that we wish to codify in RFC sooner than later. > > -- Jeff > > ----- Forwarded message from internet-drafts@ietf.org ----- > > Date: Tue, 05 Nov 2013 13:57:53 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D Action: draft-haas-idr-flowspec-redirect-rt-bis-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Clarification of the Flowspec Redirect Extended Community > Author(s) : Jeffrey Haas > Filename : draft-haas-idr-flowspec-redirect-rt-bis-00.txt > Pages : 5 > Date : 2013-11-05 > > Abstract: > This document clarifies the formatting of the the BGP Flowspec > Redirect Extended Community, originally documented in RFC 5575. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haas-idr-flowspec-redirect-rt-bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haas-idr-flowspec-redirect-rt-bis-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 > > ----- End forwarded message ----- > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From wwwrun@rfc-editor.org Tue Nov 5 20:18:19 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D377311E817D for ; Tue, 5 Nov 2013 20:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YRqQGDsVDtq for ; Tue, 5 Nov 2013 20:18:19 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 663BA11E811D for ; Tue, 5 Nov 2013 20:18:19 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id BF9F579E001; Tue, 5 Nov 2013 20:08:53 -0800 (PST) To: danny@tcb.net, vijay@umbc.edu, dwalton@cisco.com, aretana@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20131106040853.BF9F579E001@rfc-editor.org> Date: Tue, 5 Nov 2013 20:08:53 -0800 (PST) X-Mailman-Approved-At: Wed, 06 Nov 2013 16:01:34 -0800 Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC3345 (3787) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 04:18:19 -0000 The following errata report has been submitted for RFC3345, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3345&eid=3787 -------------------------------------- Type: Editorial Reported by: Ramakrishna DTV Section: 2.1 Original Text ------------- 1) Ra has the following installed in its BGP table, with the path learned via AS2 marked best: Corrected Text -------------- 1) Ra has the following installed in its BGP table, with the path learned via AS10 marked best: Notes ----- The above text is related to a discussion of topology depicted in Figure 1. This figure does not have AS2 at all. The text should refer to AS10 instead. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3345 (draft-ietf-idr-route-oscillation-01) -------------------------------------- Title : Border Gateway Protocol (BGP) Persistent Route Oscillation Condition Publication Date : August 2002 Author(s) : D. McPherson, V. Gill, D. Walton, A. Retana Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From danny@tcb.net Wed Nov 6 14:17:19 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F91021E809E for ; Wed, 6 Nov 2013 14:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU7wohA6IRwD for ; Wed, 6 Nov 2013 14:17:14 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8C211E80E2 for ; Wed, 6 Nov 2013 14:17:14 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 76DDE300050 for ; Wed, 6 Nov 2013 22:17:08 +0000 (UTC) Received: from dul1dmcphers-m1.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 2D489300049; Wed, 6 Nov 2013 15:17:03 -0700 (MST) Content-Type: multipart/signed; boundary="Apple-Mail=_4CA19AF9-0C0D-465D-AB63-7049F23BF7B6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Danny McPherson In-Reply-To: <20131106040853.BF9F579E001@rfc-editor.org> Date: Wed, 6 Nov 2013 17:17:01 -0500 Message-Id: References: <20131106040853.BF9F579E001@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1816) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Nov 6 15:17:08 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 527abfe442074796613167 X-DSPAM-Factors: 27, 2013+at, 0.40000, Thanks+#+On, 0.40000, AS2+#+all, 0.40000, change+#+#+#+edit, 0.40000, report+if, 0.40000, To*RFC+#+#+#+rfc-editor.org, 0.40000, above+text, 0.40000, Errata+#+#+#+rfc, 0.40000, report+#+#+#+draft, 0.40000, Gill+#+#+#+Retana, 0.40000, can+log, 0.40000, Oscillation+#+#+#+August, 0.40000, IETF+#+Party, 0.40000, as+#+If, 0.40000, Oscillation+#+Publication, 0.40000, Subject*Re+#+#+Reported, 0.40000, Original+Text, 0.40000, to+#+the, 0.40000, above+#+is, 0.40000, should+#+#+or, 0.40000, 2002+#+s, 0.40000, All+#+#+#+it, 0.40000, with+#+#+#+via, 0.40000, with+#+#+#+via, 0.40000, danny+#+Nov, 0.40000, Stream+#+#+#+IESG, 0.40000, Url*rfc, 0.40000 X-Mailman-Approved-At: Wed, 06 Nov 2013 16:01:37 -0800 Cc: idr@ietf.org, vijay@umbc.edu, dwalton@cisco.com, shares@ndzh.com Subject: Re: [Idr] [Editorial Errata Reported] RFC3345 (3787) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 22:17:19 -0000 --Apple-Mail=_4CA19AF9-0C0D-465D-AB63-7049F23BF7B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I confirm (=93verify=94) that the error reported below is appropriate. = There is indeed no AS2 in the figure and it should have indicated AS10, = as illustrated in the subsequent table. Thanks,=20 -danny On Nov 5, 2013, at 11:08 PM, RFC Errata System = wrote: > The following errata report has been submitted for RFC3345, > "Border Gateway Protocol (BGP) Persistent Route Oscillation = Condition". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3345&eid=3D3787 >=20 > -------------------------------------- > Type: Editorial > Reported by: Ramakrishna DTV >=20 > Section: 2.1 >=20 > Original Text > ------------- > 1) Ra has the following installed in its BGP table, with the path > learned via AS2 marked best: >=20 > Corrected Text > -------------- > 1) Ra has the following installed in its BGP table, with the path > learned via AS10 marked best: >=20 > Notes > ----- > The above text is related to a discussion of topology depicted in = Figure 1. This figure does not have AS2 at all. The text should refer to = AS10 instead. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC3345 (draft-ietf-idr-route-oscillation-01) > -------------------------------------- > Title : Border Gateway Protocol (BGP) Persistent Route = Oscillation Condition > Publication Date : August 2002 > Author(s) : D. McPherson, V. Gill, D. Walton, A. Retana > Category : INFORMATIONAL > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 --Apple-Mail=_4CA19AF9-0C0D-465D-AB63-7049F23BF7B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJ6v90ACgkQVbIg27AGOxqjlwCeOizq7uDd0xxEJUuDTI+zMX1V 9VMAn213hd+Lcg2eT1YJ64Fb51GeTJ/5 =wCRW -----END PGP SIGNATURE----- --Apple-Mail=_4CA19AF9-0C0D-465D-AB63-7049F23BF7B6-- From jhaas@slice.pfrc.org Wed Nov 6 16:31:05 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4822321E818E for ; Wed, 6 Nov 2013 16:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.21 X-Spam-Level: X-Spam-Status: No, score=-102.21 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHWAr-eQSFwK for ; Wed, 6 Nov 2013 16:31:00 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E015221E817C for ; Wed, 6 Nov 2013 16:30:54 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 81B53C2A8; Wed, 6 Nov 2013 19:30:54 -0500 (EST) Date: Wed, 6 Nov 2013 19:30:54 -0500 From: Jeffrey Haas To: RFC Errata System Message-ID: <20131107003054.GB7283@pfrc> References: <20131105064027.BB22075E011@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131105064027.BB22075E011@rfc-editor.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: skh@nexthop.com, idr@ietf.org, jhaas@nexthop.com, shares@ndzh.com Subject: Re: [Idr] [Editorial Errata Reported] RFC4273 (3782) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 00:31:05 -0000 On Mon, Nov 04, 2013 at 10:40:27PM -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC4273, > "Definitions of Managed Objects for BGP-4". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4273&eid=3782 > > -------------------------------------- > Type: Editorial > Reported by: Ramakrishna DTV > > Section: 5 > > Original Text > ------------- > There are several management objects defined in this MIB that have a > MAX-ACCESS clause of read-write and/or read-create. > > Corrected Text > -------------- > There are several management objects defined in this MIB that have a > MAX-ACCESS clause of read-write. > > Notes > ----- > No object in this MIB has MAX-ACCESS clause of "read-create". The cited text is standard SNMP MIB boilerplate. The alternative as specified by "and/or" is a standard English shorthand for "both may be present or one may be present". Thus while the reporter is correct, I do not believe anything would be altered today. My recommendation is that the reporter work with the MIB doctors to adjust standard Internet boilerplate. -- Jeff From jhaas@slice.pfrc.org Wed Nov 6 16:36:35 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F9521E8191 for ; Wed, 6 Nov 2013 16:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaHtDRoWCS3L for ; Wed, 6 Nov 2013 16:36:23 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 262DA11E8179 for ; Wed, 6 Nov 2013 16:36:20 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id C0D40C2A8; Wed, 6 Nov 2013 19:36:19 -0500 (EST) Date: Wed, 6 Nov 2013 19:36:19 -0500 From: Jeffrey Haas To: Jakob Heitz Message-ID: <20131107003619.GC7283@pfrc> References: <21111.50401.542862.187680@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB5DF4@eusaamb109.ericsson.se> <8ED5B0B0F5B4854A912480C1521F973A11ABEF13@xmb-rcd-x13.cisco.com> <548411C6-315A-43F1-B5AC-C48E9EE57C54@ericsson.com> <21113.48296.396769.745319@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB768B@eusaamb109.ericsson.se> <21114.17410.159355.826952@oz.mt.att.com> <8ED5B0B0F5B4854A912480C1521F973A11AC016C@xmb-rcd-x13.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "idr@ietf.org" , Jay Borkenhagen Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 00:36:35 -0000 On Wed, Nov 06, 2013 at 05:17:16PM +0000, Jakob Heitz wrote: > Yes, the ambiguity exists with or without add-path. There really is no ambiguity. In deployment, there is no way to distinguish this case from having discarded the associated *valid* reachability according to local policy. -- Jeff From jakob.heitz@ericsson.com Wed Nov 6 16:39:55 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F6F21E8198 for ; Wed, 6 Nov 2013 16:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iit6u0NXm7JF for ; Wed, 6 Nov 2013 16:39:45 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0E121E8197 for ; Wed, 6 Nov 2013 16:39:41 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-9f-527ae1496a49 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EE.27.23183.941EA725; Thu, 7 Nov 2013 01:39:37 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Wed, 6 Nov 2013 19:39:37 -0500 From: Jakob Heitz To: Jeffrey Haas Thread-Topic: [Idr] comments on draft-ietf-idr-add-paths-09 Thread-Index: AQHO2XdeOrK/B1KFCUKtlJ+iRCHhZZoV4nsggABbCID//63gw4AB/FQA///HyqaAANmQAIAAO5QA//+wgZYAGc+egP//rLah Date: Thu, 7 Nov 2013 00:39:37 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB8729@eusaamb109.ericsson.se> References: <21111.50401.542862.187680@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB5DF4@eusaamb109.ericsson.se> <8ED5B0B0F5B4854A912480C1521F973A11ABEF13@xmb-rcd-x13.cisco.com> <548411C6-315A-43F1-B5AC-C48E9EE57C54@ericsson.com> <21113.48296.396769.745319@oz.mt.att.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E02EB768B@eusaamb109.ericsson.se> <21114.17410.159355.826952@oz.mt.att.com> <8ED5B0B0F5B4854A912480C1521F973A11AC016C@xmb-rcd-x13.cisco.com> , <20131107003619.GC7283@pfrc> In-Reply-To: <20131107003619.GC7283@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyuXRPuK7nw6oggxXXbSxe3X7GZLHs+F52 i/0H37Ja7Dm0nM2BxePRtEdMHlN+b2T1WLLkJ5PH5d6trAEsUVw2Kak5mWWpRfp2CVwZq58s Yi9YzFbR2P2AsYFxPmsXIweHhICJxKr7KV2MnECmmMSFe+vZQGwhgSOMEvPe1nQxcgHZyxgl 3i/cCpZgE9CR+Ha9ixnEFhFQlJj/vxMszixQJPHiYTcTiC0sYCXRdPkNE0SNtcT7R42MEHae xJ5ja8DqWQRUJK5MXcECYvMK+Eq0PnnBBLFsCYvEl6OXwBKcApoST78dA2tgBLru+6k1TBDL xCVuPZnPBHG1gMSSPeeZIWxRiZeP/7FC2MoS3+c8YoGo15FYsPsT1KHaEssWvmaGWCwocXLm E5YJjGKzkIydhaRlFpKWWUhaFjCyrGLkKC1OLctNNzLYxAiMpmMSbLo7GPe8tDzEKM3BoiTO ++Wtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxtbqGSlts+Z/atr1cTvLTs4tG3MnXmAU MLBdc6b6ZffLJ2zs5/5ekjmW+q7NpavEKoiP/ZHcTq1ahU/iyVuUpiTdW3yjuaXaMLjE51vC jTu6naHf3h3beV5dhV2gatPithQNA4/5dQkf7seWvFNauk414n5peY8wP3/sUb3ZPufbpqjc Ddl0WomlOCPRUIu5qDgRAFF0KId0AgAA Cc: "idr@ietf.org" , Jay Borkenhagen Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 00:39:55 -0000 By "ambiguity" I meant that there is no way to distinguish the cases.=0A= So, even though the words don't agree, we agree on meaning.=0A= --=0A= =0A= Jakob Heitz.=0A= =0A= ________________________________________=0A= From: Jeffrey Haas [jhaas@pfrc.org]=0A= Sent: Wednesday, 06 November 2013 4:36 PM=0A= To: Jakob Heitz=0A= Cc: Saikat Ray (sairay); idr@ietf.org; Jay Borkenhagen=0A= Subject: Re: [Idr] comments on draft-ietf-idr-add-paths-09=0A= =0A= On Wed, Nov 06, 2013 at 05:17:16PM +0000, Jakob Heitz wrote:=0A= > Yes, the ambiguity exists with or without add-path.=0A= =0A= There really is no ambiguity. In deployment, there is no way to distinguis= h=0A= this case from having discarded the associated *valid* reachability=0A= according to local policy.=0A= =0A= -- Jeff=0A= From jgs@juniper.net Wed Nov 6 19:42:34 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E437F11E80F5 for ; Wed, 6 Nov 2013 19:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUW6gVYcJjCq for ; Wed, 6 Nov 2013 19:42:23 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id D748121E80EB for ; Wed, 6 Nov 2013 19:42:22 -0800 (PST) Received: from mail173-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE018.bigfish.com (10.243.66.81) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 03:42:20 +0000 Received: from mail173-co1 (localhost [127.0.0.1]) by mail173-co1-R.bigfish.com (Postfix) with ESMTP id 0B65C500287 for ; Thu, 7 Nov 2013 03:42:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zzda00h4015Idc73h14ffIzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2052h20b3h2216h1155h) Received-SPF: pass (mail173-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(53754006)(164054003)(81542001)(77096001)(69226001)(53806001)(63696002)(80976001)(56816003)(83322001)(83072001)(47736001)(49866001)(47976001)(50986001)(54356001)(87936001)(80022001)(66066001)(65816001)(54316002)(74706001)(2656002)(56776001)(81686001)(81342001)(81816001)(33656001)(76482001)(79102001)(87266001)(76786001)(59766001)(77982001)(74366001)(74876001)(74502001)(47446002)(46102001)(31966008)(558084003)(74662001)(36756003)(85306002)(76176001)(83716003)(76796001)(4396001)(51856001)(82746002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB526; H:DM2PR05MB527.namprd05.prod.outlook.com; CLIP:31.133.167.246; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail173-co1 (localhost.localdomain [127.0.0.1]) by mail173-co1 (MessageSwitch) id 1383795737937126_11907; Thu, 7 Nov 2013 03:42:17 +0000 (UTC) Received: from CO1EHSMHS029.bigfish.com (unknown [10.243.78.232]) by mail173-co1.bigfish.com (Postfix) with ESMTP id E18B21C0071 for ; Thu, 7 Nov 2013 03:42:17 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS029.bigfish.com (10.243.66.39) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 03:42:17 +0000 Received: from DM2PR05MB526.namprd05.prod.outlook.com (10.141.99.148) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 7 Nov 2013 03:42:17 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by DM2PR05MB526.namprd05.prod.outlook.com (10.141.99.148) with Microsoft SMTP Server (TLS) id 15.0.810.5; Thu, 7 Nov 2013 03:42:15 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com ([169.254.6.241]) by DM2PR05MB527.namprd05.prod.outlook.com ([169.254.6.241]) with mapi id 15.00.0815.000; Thu, 7 Nov 2013 03:42:15 +0000 From: John Scudder To: "idr@ietf. org" Thread-Topic: Note taker, jabber scribe for Friday IDR meeting Thread-Index: AQHO22tZ9nB4wcJMjU6vUAJX8kH1QA== Date: Thu, 7 Nov 2013 03:42:14 +0000 Message-ID: <2D8FB3A4-2AF3-44A9-8D62-097B5028BC9E@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.167.246] x-forefront-prvs: 00235A1EEF Content-Type: text/plain; charset="us-ascii" Content-ID: <90E5DC574F936844A753605A1BF1DB9C@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Idr] Note taker, jabber scribe for Friday IDR meeting X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 03:42:34 -0000 Hi All, Sue won't be able to be at Friday's meeting. This makes it all the more imp= ortant for me to have volunteers to take notes and act as Jabber scribe.=20 If you're willing to help, please let me know.=20 Thanks, --John= From jschiel@flowtools.net Thu Nov 7 07:31:18 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9B921E811E for ; Thu, 7 Nov 2013 07:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuS3RlRnT+jm for ; Thu, 7 Nov 2013 07:31:13 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 471DC21E80DD for ; Thu, 7 Nov 2013 07:31:13 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id tp5so1081289ieb.17 for ; Thu, 07 Nov 2013 07:31:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LQAsgkgb/XyAgKXT485K2aZefmvssdTPY3WKv7oTlEU=; b=BW/9SY3jQCv9rTm501UvljUeURtXZ2HGdSiQBp4GOF9u3urS01kXOKCP3pWNnH3+/M 8OIKzlCfuCQ8CmerJpMxfST+rjUUWu9wsv8DTddDNTOcTAxGJHJyjGNSdIekFg37PQ+M hUxHLjrCi6fmRCa4nNBuH5EIEepORGdHy0EtbAlXe18navR0BLz6DStWE1UHawFwsnni T4okNA0M4jTpDOSWiNmsvCbZzcpczbaGaLcThWUjDKZnkm23UJwwwaV1hEeZ+uT9v2U5 9Zojm3qP5oIw3JKap4w0Q7/3DB782foQSMfBQVKBOHO+H8WgvYQir2AMHa9PdfN6/Cin ALGg== X-Gm-Message-State: ALoCoQlDf0rmRLiPHnzp7sfdjVmCcow98YMdxXsNH3oTeX2ayUoZxI0quZPseRWETmnXaJlABkR5 X-Received: by 10.50.23.16 with SMTP id i16mr2391772igf.50.1383838271374; Thu, 07 Nov 2013 07:31:11 -0800 (PST) Received: from handyj.ip.qwest.net (handyj.ip.qwest.net. [205.169.63.144]) by mx.google.com with ESMTPSA id ka1sm4669513igb.7.2013.11.07.07.31.09 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Nov 2013 07:31:10 -0800 (PST) Message-ID: <527BB23D.7060205@flowtools.net> Date: Thu, 07 Nov 2013 08:31:09 -0700 From: John User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Jeffrey Haas , idr@ietf.org References: <20131105220155.GA19411@pfrc> In-Reply-To: <20131105220155.GA19411@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-haas-idr-flowspec-redirect-rt-bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:31:18 -0000 On 11/05/2013 03:01 PM, Jeffrey Haas wrote: > Working Group, > > The following draft pertains to the brief presentation on this topic during > Friday's session at IDR in Vancouver. The goal of this draft is to clarify > deployed behavior of the flowspec redirect extended community. > > My desire post presentation is for WG adoption and possibly simultaneous > WGLC. This is just errata that we wish to codify in RFC sooner than later. Ack, sorry, misunderstood the timing of the meeting. Disregard. --John > > -- Jeff > > ----- Forwarded message from internet-drafts@ietf.org ----- > > Date: Tue, 05 Nov 2013 13:57:53 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D Action: draft-haas-idr-flowspec-redirect-rt-bis-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Clarification of the Flowspec Redirect Extended Community > Author(s) : Jeffrey Haas > Filename : draft-haas-idr-flowspec-redirect-rt-bis-00.txt > Pages : 5 > Date : 2013-11-05 > > Abstract: > This document clarifies the formatting of the the BGP Flowspec > Redirect Extended Community, originally documented in RFC 5575. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haas-idr-flowspec-redirect-rt-bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haas-idr-flowspec-redirect-rt-bis-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 > > ----- End forwarded message ----- > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Thu Nov 7 16:15:09 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6B221E8156 for ; Thu, 7 Nov 2013 16:15:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrPpMow2kCkQ for ; Thu, 7 Nov 2013 16:15:04 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id EB46921E81EB for ; Thu, 7 Nov 2013 16:14:53 -0800 (PST) Received: from mail74-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Fri, 8 Nov 2013 00:14:53 +0000 Received: from mail74-tx2 (localhost [127.0.0.1]) by mail74-tx2-R.bigfish.com (Postfix) with ESMTP id DE3241C0321 for ; Fri, 8 Nov 2013 00:14:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 5 X-BigFish: VPS5(zzda00hdc73hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h2052h20b3h2216h17ej1155h) Received-SPF: pass (mail74-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(74502001)(74366001)(50986001)(77096001)(77982001)(76176001)(47736001)(46102001)(81342001)(74706001)(36756003)(63696002)(47446002)(31966008)(74662001)(47976001)(558084003)(76786001)(56816003)(87936001)(56776001)(76796001)(59766001)(49866001)(4396001)(79102001)(54316002)(81542001)(51856001)(54356001)(65816001)(80022001)(76482001)(53806001)(82746002)(87266001)(81816001)(33656001)(81686001)(83072001)(80976001)(83322001)(85306002)(74876001)(69226001)(2656002)(83716003)(42262001)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB528; H:DM2PR05MB527.namprd05.prod.outlook.com; CLIP:2001:67c:370:176:75ff:ba66:dc49:e7f2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail74-tx2 (localhost.localdomain [127.0.0.1]) by mail74-tx2 (MessageSwitch) id 1383869691323091_7791; Fri, 8 Nov 2013 00:14:51 +0000 (UTC) Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.238]) by mail74-tx2.bigfish.com (Postfix) with ESMTP id 4313D10012E for ; Fri, 8 Nov 2013 00:14:51 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 8 Nov 2013 00:14:51 +0000 Received: from DM2PR05MB528.namprd05.prod.outlook.com (10.141.99.156) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 8 Nov 2013 00:14:50 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by DM2PR05MB528.namprd05.prod.outlook.com (10.141.99.156) with Microsoft SMTP Server (TLS) id 15.0.815.6; Fri, 8 Nov 2013 00:14:47 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com ([169.254.6.241]) by DM2PR05MB527.namprd05.prod.outlook.com ([169.254.6.241]) with mapi id 15.00.0815.000; Fri, 8 Nov 2013 00:14:47 +0000 From: John Scudder To: "idr@ietf. org" Thread-Topic: Small agenda change for IDR Thread-Index: AQHO3BeIESAHCIsEQUSQ5yCdq9zOdA== Date: Fri, 8 Nov 2013 00:14:46 +0000 Message-ID: <747E82B1-2689-424B-9E1D-14E9036FE48B@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:176:75ff:ba66:dc49:e7f2] x-forefront-prvs: 00246AB517 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Idr] Small agenda change for IDR X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:15:10 -0000 Keyur will be the first presenter and not the sixth as shown on the posted = agenda.=20 --John= From wwwrun@rfc-editor.org Fri Nov 8 04:19:20 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018FE11E8177 for ; Fri, 8 Nov 2013 04:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVRkDrDcKfhU for ; Fri, 8 Nov 2013 04:19:19 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7C89E11E8128 for ; Fri, 8 Nov 2013 04:19:19 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 39BEE726002; Fri, 8 Nov 2013 04:09:45 -0800 (PST) To: bgp-confederations@st04.pst.org, danny@arbor.net, jgs@juniper.net, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20131108120945.39BEE726002@rfc-editor.org> Date: Fri, 8 Nov 2013 04:09:45 -0800 (PST) X-Mailman-Approved-At: Fri, 08 Nov 2013 07:30:04 -0800 Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC5065 (3791) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 12:19:20 -0000 The following errata report has been submitted for RFC5065, "Autonomous System Confederations for BGP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5065&eid=3791 -------------------------------------- Type: Editorial Reported by: Ramakrishna DTV Section: 7 Original Text ------------- Additionally, confederations (as well as route reflectors), by excluding different reachability information from consideration at different locations in a confederation, have been shown [RFC3345] to cause permanent oscillation between candidate routes when using the tie-breaking rules required by BGP [BGP-4]. Corrected Text -------------- Additionally, confederations (as well as route reflectors), by excluding different reachability information from consideration at different locations in a confederation, have been shown [RFC3345] to cause persistent oscillation between candidate routes when using the tie-breaking rules required by BGP [BGP-4]. Notes ----- s/permanent/persistent RFC 3345 nowhere refers to this oscillation as "permanent". It consistently refers to it as "persistent" only. "Permanent" is a much stronger word than "persistent", and I believe is not applicable here. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5065 (draft-ietf-idr-rfc3065bis-06) -------------------------------------- Title : Autonomous System Confederations for BGP Publication Date : August 2007 Author(s) : P. Traina, D. McPherson, J. Scudder Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From jgs@juniper.net Fri Nov 8 08:10:45 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A4011E8189 for ; Fri, 8 Nov 2013 08:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=-1.913, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O4JCqNKwge4 for ; Fri, 8 Nov 2013 08:10:39 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 9D01511E8184 for ; Fri, 8 Nov 2013 08:10:37 -0800 (PST) Received: from mail109-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.22; Fri, 8 Nov 2013 16:10:36 +0000 Received: from mail109-ch1 (localhost [127.0.0.1]) by mail109-ch1-R.bigfish.com (Postfix) with ESMTP id D1354380233; Fri, 8 Nov 2013 16:10:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zz98dI9371Ic85fh1432Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h17326ah172cdfh8275bh8275dh19a27bh1de097h186068hz2fh2a8h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1b2bh1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h20f0h2218h2216h1155h) Received-SPF: pass (mail109-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(24454002)(377454003)(189002)(199002)(77982001)(74502001)(47446002)(80022001)(47976001)(50226001)(63696002)(49866001)(59766001)(4396001)(56776001)(50986001)(47736001)(74706001)(46102001)(81816001)(81686001)(79102001)(66066001)(82746002)(15975445006)(69226001)(51856001)(31966008)(74662001)(57306001)(80976001)(19580405001)(54316002)(19580395003)(65816001)(84326002)(85306002)(74876001)(53806001)(42186004)(69556001)(62966002)(76482001)(15188155005)(74366001)(512954002)(15202345003)(83072001)(83322001)(16799955002)(77096001)(56816003)(77156001)(76786001)(76796001)(87286001)(81542001)(83716003)(87266001)(81342001)(36756003)(33656001)(87976001)(71186001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:sa-nc-finance-136.static.jnpr.net; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail109-ch1 (localhost.localdomain [127.0.0.1]) by mail109-ch1 (MessageSwitch) id 1383927035476541_7337; Fri, 8 Nov 2013 16:10:35 +0000 (UTC) Received: from CH1EHSMHS021.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail109-ch1.bigfish.com (Postfix) with ESMTP id 6DEA630013B; Fri, 8 Nov 2013 16:10:35 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 8 Nov 2013 16:10:35 +0000 Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 8 Nov 2013 16:10:35 +0000 Received: from sa-nc-finance-136.static.jnpr.net (66.129.224.36) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.815.6; Fri, 8 Nov 2013 16:10:33 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_922A6961-D4B1-413D-9BA2-35BF4C904654" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: "John G. Scudder" In-Reply-To: <20131108120945.39BEE726002@rfc-editor.org> Date: Fri, 8 Nov 2013 08:10:22 -0800 Message-ID: <6153EFC2-9366-4B2B-ADC7-37BED5B7B485@juniper.net> References: <20131108120945.39BEE726002@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1816) X-Originating-IP: [66.129.224.36] X-ClientProxiedBy: DM2PR03CA001.namprd03.prod.outlook.com (10.141.52.149) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) X-Forefront-PRVS: 00246AB517 X-FOPE-CRA-Verdict: 157.56.240.101$infosys.com%0%1%DuplicateDomain-c684c95e-93ad-459f-9d80-96fa46cd75af.juniper.net%False%False%0$ X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INFOSYS.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "idr@ietf. org" , bgp-confederations@st04.pst.org, danny@arbor.net, Hares Susan Subject: Re: [Idr] [Editorial Errata Reported] RFC5065 (3791) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 16:10:45 -0000 --Apple-Mail=_922A6961-D4B1-413D-9BA2-35BF4C904654 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" I agree with the erratum. --John On Nov 8, 2013, at 4:09 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC5065, > "Autonomous System Confederations for BGP". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5065&eid=3D3791 >=20 > -------------------------------------- > Type: Editorial > Reported by: Ramakrishna DTV >=20 > Section: 7 >=20 > Original Text > ------------- > Additionally, confederations (as well as route reflectors), by > excluding different reachability information from consideration at > different locations in a confederation, have been shown [RFC3345] to > cause permanent oscillation between candidate routes when using the > tie-breaking rules required by BGP [BGP-4]. >=20 > Corrected Text > -------------- > Additionally, confederations (as well as route reflectors), by > excluding different reachability information from consideration at > different locations in a confederation, have been shown [RFC3345] to > cause persistent oscillation between candidate routes when using the > tie-breaking rules required by BGP [BGP-4]. >=20 > Notes > ----- > s/permanent/persistent >=20 > RFC 3345 nowhere refers to this oscillation as "permanent". It = consistently refers to it as "persistent" only. >=20 > "Permanent" is a much stronger word than "persistent", and I believe = is not applicable here. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5065 (draft-ietf-idr-rfc3065bis-06) > -------------------------------------- > Title : Autonomous System Confederations for BGP > Publication Date : August 2007 > Author(s) : P. Traina, D. McPherson, J. Scudder > Category : DRAFT STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 >=20 --Apple-Mail=_922A6961-D4B1-413D-9BA2-35BF4C904654 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" I = agree with the erratum.

--John

On Nov 8, 2013, at 4:09 AM, RFC Errata System <rfc-editor@rfc-editor.org>= ; wrote:

The following errata report has been submitted for = RFC5065,
"Autonomous System Confederations for = BGP".

--------------------------------------
You may review = the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D5065&eid=3D3791=

--------------------------------------
Type: = Editorial
Reported by: Ramakrishna DTV = <ramakrishnadtv@infosys.com>

Section: 7

Original = Text
-------------
  Additionally, confederations (as = well as route reflectors), by
  excluding different = reachability information from consideration at
  different = locations in a confederation, have been shown [RFC3345] to
=   cause permanent oscillation between candidate routes when = using the
  tie-breaking rules required by BGP = [BGP-4].

Corrected Text
--------------
=   Additionally, confederations (as well as route reflectors), = by
  excluding different reachability information from = consideration at
  different locations in a confederation, = have been shown [RFC3345] to
  cause persistent = oscillation between candidate routes when using the
=   tie-breaking rules required by BGP = [BGP-4].

Notes
-----
s/permanent/persistent

RFC 3345 = nowhere refers to this oscillation as "permanent". It consistently = refers to it as "persistent" only.

"Permanent" is a much stronger = word than "persistent", and I believe is not applicable = here.

Instructions:
-------------
This errata is currently = posted as "Reported". If necessary, please
use "Reply All" to discuss = whether it should be verified or
rejected. When a decision is = reached, the verifying party (IESG)
can log in to change the status = and edit the report, if necessary. =

--------------------------------------
RFC5065 = (draft-ietf-idr-rfc3065bis-06)
--------------------------------------Title =             &n= bsp; : Autonomous System Confederations for BGP
Publication Date =    : August 2007
Author(s) =           : P. Traina, = D. McPherson, J. Scudder
Category =            : = DRAFT STANDARD
Source =             &n= bsp;: Inter-Domain Routing
Area =             &n= bsp;  : Routing
Stream =             &n= bsp;: IETF
Verifying Party     : = IESG



= --Apple-Mail=_922A6961-D4B1-413D-9BA2-35BF4C904654-- From steve@wreck.net Fri Nov 8 09:40:40 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAE221F9EAD for ; Fri, 8 Nov 2013 09:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDpELrCMBih2 for ; Fri, 8 Nov 2013 09:40:27 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA7111E80E9 for ; Fri, 8 Nov 2013 09:39:31 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id tp5so3785192ieb.31 for ; Fri, 08 Nov 2013 09:38:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wreck.net; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=Llo88906V2g5wGf7jCyn1wPUc3ozFXd8p8bENjF11Ak=; b=Oo67OBqbfdkppU8DkDD2FAK0hKBlLFt/WJu8/a0gVt+HBmjsHBX0QiBhVZUwDMQ1r+ DPvFkpC8KBFOzfZKUFAamdAO+jZIkk3cuxLr6rqOB46QtAsgKc6k3K4h1WOHOEYNmbKq Aqr11SP2NlQMCsfvwy2Eij8kZ42rhltdU2IRg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Llo88906V2g5wGf7jCyn1wPUc3ozFXd8p8bENjF11Ak=; b=d3H2GQUX0fEJ1oRADgTlevGfEXVBO2tP77ApWnGpvdh8EJwo6K7JzOT8U4jzkEttZB lFv3QEfY8Sb2qWR7jIgAY9NYqZzcbf6agFH7vKOT8ULzj8PFpX9hZZZRrsS1jb52VGh3 /YYl7sySvCyKy+fB+8/Ipq4wC7emZGiH5PCk+h0egePtr0A8tHB043/oV5mKfdhLAWuL rCq5w2RcRvlpFb9nGigZSNeIb0dE0SqMsOaYtbSQLoAw9327k2g1xunQO3U6/dXXC57V EalLMjkaGMZSt5SG2z2hUtTMEa6pXyVNPj50+XP5DriZnWL4XT7iF9T53nqPoNAbmsPW srcw== X-Gm-Message-State: ALoCoQmPy9OSnZrFfRLhmYRQuQas6iTpJmaJZuDFvgVTQr53vgpbnKkNhl/pdDJ3DMqyzaZwssEt X-Received: by 10.42.24.138 with SMTP id w10mr1076273icb.22.1383932326485; Fri, 08 Nov 2013 09:38:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.225.180 with HTTP; Fri, 8 Nov 2013 09:38:26 -0800 (PST) From: Steve Padgett Date: Fri, 8 Nov 2013 09:38:26 -0800 Message-ID: To: "idr@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1 Subject: [Idr] Comments on draft-patel-raszuk-bgp-vector-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 17:40:42 -0000 A few questions ... (a) What should be the behavior be if there's a loop in the path, where the same router is configured to receive the same packet in the same vrf multiple times in the same vector? Note that a loop may not be obvious by looking at the vector attribute, as the IPs listed could be different interfaces on the same router. If the node that detects the loop falls back to next_hop, wouldn't that possibly create a loop? If it jumps to it's last entry in the chain then that may prevent loops but it'd skip other entries in the chain (which may be a firewall :) ... possibly a security concern if this happens). (b) What happens if one (or more) nodes in the network are part of the path but do not understand the vector attribute? Don't they fall back to the next_hop, potentially creating a loop? (c) Calculating IGP distance to the next_hop is part of the BGP path selection. Which next-hop is used here selecting the BGP route? The vector-calculated next-hop or the bgp next_hop attribute? (d) Is there a security attack possible if an untrusted peer sends you an advertisement with a vector route? If I (as the "untrusted peer") can control what path my packets take in your network, that seems undesirable, as I could route my traffic through whatever nodes/service devices I want. (Assume that I advertise the route to you with your ASN in the vector attribute, thus it'll pass the AS number validation check). (e) Assuming that ECMP is useful :) and that the plan as I understand it here for ECMP support is to use 'anycast next hops' -- how does it deal with a topology like: (A needs to send to D, and A can ECMP to B,E,F; B forwards to C then D; E & F forward to D directly) A-B-C-D A-E-D A-F-D Thanks, Steve From xuxiaohu@huawei.com Fri Nov 8 10:17:08 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90E821E8150 for ; Fri, 8 Nov 2013 10:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.928 X-Spam-Level: X-Spam-Status: No, score=-3.928 tagged_above=-999 required=5 tests=[AWL=2.671, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcU96WQAcV4T for ; Fri, 8 Nov 2013 10:16:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 420B221E81D6 for ; Fri, 8 Nov 2013 10:16:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXR58689; Fri, 08 Nov 2013 18:16:58 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 18:16:11 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 18:16:50 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sat, 9 Nov 2013 02:16:45 +0800 From: Xuxiaohu To: "idr@ietf.org" Thread-Topic: Clarify my commennts on draft-patel-raszuk-bgp-vector-routing-01 Thread-Index: Ac7cqYRwA5QD+pONQQS/0+CF49Ormg== Date: Fri, 8 Nov 2013 18:16:43 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A3F@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Idr] Clarify my commennts on draft-patel-raszuk-bgp-vector-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 18:17:08 -0000 Hi co-authors of this draft, It said "Vector Node attribute consist of one or more TLVs which carry orde= red lists of IP Transit Hops that needs to be traversed before the packet i= s forwarded to its destination" in the presentation slides. My question to the speaker was whether the above IP Transit Hops must be BG= P routers. The answer is No. If so, when a packet is forwarded to one of t= he above Transit Hop which is non-BGP router according to the vector routin= g proposed by this draft, how could that Transit Hop know what the next IP = Transit Hop is given that this draft doesn't require any change to the forw= arding plane? BR, Xiaohu= From rjs@rob.sh Fri Nov 8 11:21:45 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E3611E816D for ; Fri, 8 Nov 2013 11:21:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKjqH3GQlVzR for ; Fri, 8 Nov 2013 11:21:44 -0800 (PST) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id E058121E8173 for ; Fri, 8 Nov 2013 11:21:41 -0800 (PST) Received: from [31.133.176.146] (helo=dhcp-b092.meeting.ietf.org) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VerbG-000540-SX; Fri, 08 Nov 2013 19:20:11 +0000 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: Date: Fri, 8 Nov 2013 11:21:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <835552BB-E043-4ACF-BF4A-F68A6400ACC3@rob.sh> References: To: John Scudder X-Mailer: Apple Mail (2.1510) Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-ga-idr-as-migration X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 19:21:45 -0000 On 8 Oct 2013, at 14:17, John Scudder wrote: > Folks, >=20 > The authors have requested IDR adopt draft-ga-idr-as-migration as a = working group document.=20 >=20 > http://datatracker.ietf.org/doc/draft-ga-idr-as-migration/ >=20 > Please send any comments to the list by October 23. Hi John, Demonstrating how far I am behind on my mail -- I'd like to support this = draft for adoption into IDR. As per Jeff's comment, I think that it = would be useful to ensure that as we progress this draft, we consult = with GROW , but IDR seems to be the right place to adopt it. Cheers, r.= From rraszuk@gmail.com Fri Nov 8 20:15:38 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739BA21E80DF for ; Fri, 8 Nov 2013 20:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMRD+t8ei+C7 for ; Fri, 8 Nov 2013 20:15:38 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F373321E80DB for ; Fri, 8 Nov 2013 20:15:37 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id tp5so4715143ieb.31 for ; Fri, 08 Nov 2013 20:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=iaK5u4posWzZte6AwDPyZVzOrkRPnylQiijBDfoIbHE=; b=ciKONY/VUM+pzdvnaLlzUWhSx15cOxy62Zm4h8fxm3kFvlJvExYNO+mWy7zGd+qRWD R9GvOr4/iVqwl1dYGXBO5itDAJjTf0bQRF3ncnrmjPH45cMJ9ezzorxrzAhnRkOXKSdy rc3Q710zl4204wEakB/Z9rzsnchmvKxG9v8Gl0ilbG8GY7senWD5EdQ7yy4A8Qpt38yD CzHyCO/+RJidpoeA3X5tvxrismSPfCvAVpAIgIoxW/fWJO16Gy6BMZQE38/3atz80Tci ILnIYWkaSZFQZgSI78ZqJvrniFpn372efjxT/yAc0I8EF664ZI2uPwNV3q28yBOokyek n/kg== MIME-Version: 1.0 X-Received: by 10.43.73.197 with SMTP id yt5mr11645723icb.0.1383970537410; Fri, 08 Nov 2013 20:15:37 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 8 Nov 2013 20:15:37 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A3F@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A3F@NKGEML512-MBS.china.huawei.com> Date: Sat, 9 Nov 2013 05:15:37 +0100 X-Google-Sender-Auth: dYZJB89j0rfuALufyLEEcB46y88 Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf.org" Subject: Re: [Idr] Clarify my commennts on draft-patel-raszuk-bgp-vector-routing-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 04:15:38 -0000 Hi, The term Transit Hop is being overloaded here. Let's divide it to term BGP Vector Node and P router. BGP Vector Node is a BGP speaker ... P router is not. P router just switches IP packet or MPLS packet to its destination embedded in the encapsulation header. Best regards, R. On Fri, Nov 8, 2013 at 7:16 PM, Xuxiaohu wrote: > Hi co-authors of this draft, > > It said "Vector Node attribute consist of one or more TLVs which carry or= dered lists of IP Transit Hops that needs to be traversed before the packet= is forwarded to its destination" in the presentation slides. > > My question to the speaker was whether the above IP Transit Hops must be = BGP routers. The answer is No. If so, when a packet is forwarded to one of= the above Transit Hop which is non-BGP router according to the vector rout= ing proposed by this draft, how could that Transit Hop know what the next I= P Transit Hop is given that this draft doesn't require any change to the fo= rwarding plane? > > BR, > Xiaohu > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From xuxiaohu@huawei.com Fri Nov 8 22:03:43 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527BF11E814B for ; Fri, 8 Nov 2013 22:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.81 X-Spam-Level: X-Spam-Status: No, score=0.81 tagged_above=-999 required=5 tests=[AWL=-1.639, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79QbK9TnPbDU for ; Fri, 8 Nov 2013 22:03:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1E511E80F5 for ; Fri, 8 Nov 2013 22:03:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXR87031; Sat, 09 Nov 2013 06:03:35 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 9 Nov 2013 06:02:48 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 9 Nov 2013 06:03:34 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sat, 9 Nov 2013 14:03:27 +0800 From: Xuxiaohu To: Robert Raszuk Thread-Topic: [Idr] Clarify my commennts on draft-patel-raszuk-bgp-vector-routing-01 Thread-Index: AQHO3QJfRDAhHm/60U2QdkZlNmdfvpocVCJy Date: Sat, 9 Nov 2013 06:03:26 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BC2@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A3F@NKGEML512-MBS.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.157.237] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "idr@ietf.org" Subject: [Idr] =?gb2312?b?tPC4tDogIENsYXJpZnkgbXkgY29tbWVubnRzIG9uCWRyYWZ0?= =?gb2312?b?LXBhdGVsLXJhc3p1ay1iZ3AtdmVjdG9yLXJvdXRpbmctMDE=?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 06:03:43 -0000 SGksDQoNClRoZSB0ZXJtICJUcmFuc2l0IEhvcCIgaXMgbm90IG92ZXJsb2FkZWQgSEVSRSBzaW5j ZSB0aGVyZSBpcyBhIGNsZWFyIGNvbnRleHQgdGhhdCB0aGVzZSBUcmFuc2l0IEhvcHMgYXJlIGNv bnRhaW5lZCBpbiB0aGUgVExWcyBvZiBCR1AgVmVjdG9yIE5vZGUgYXR0cmlidXRlLiBCVFcsIHRo ZXJlIGlzIG9ubHkgb25lIHBsYWNlIG9mIHlvdXIgZHJhZnQgd2hlcmUgIklQIHRyYW5zaXQgaG9w cyIgaXMgdXNlZC4NCg0KIi4uLi4gdGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IEJHUA0KICAg YXR0cmlidXRlIGtub3duIGFzIGEgQkdQIFZlY3RvciBOb2RlIGF0dHJpYnV0ZS4gIFRoZSBCR1Ag VmVjdG9yIE5vZGUNCiAgIGF0dHJpYnV0ZSBjb25zaXN0IG9mIGFuIG9yZGVyZWQgbGlzdCBvZiBJ UCB0cmFuc2l0IGhvcHMgdGhhdCBuZWVkcyB0bw0KICAgYmUgdHJhdmVyc2VkIGJlZm9yZSB0aGUg cGFja2V0IGlzIGZvcndhcmRlZCB0byBpdHMgQkdQIE5FWFQgSE9QLiAgVGhlDQogICBpbmZvcm1h dGlvbiBjYXJyaWVkIGluIHRoZSBvcmRlcmVkIGxpc3Qgb2YgVmVjdG9yIE5vZGUgaXMgdXNlZA0K ICAgdG93YXJkcyBhdWdtZW50aW5nIHRoZSBORVhUIEhPUCBpbmZvcm1hdGlvbiBmb3IgdGhlIEJH UCBwcmVmaXhlcyBhcw0KICAgY2FycmllZCBpbiB0aGUgTVBfUkVBQ0ggYXR0cmlidXRlLiINCg0K QWNjb3JkaW5nIHRvIHRoZSBhYm92ZSBkZXNjcmlwdGlvbiwgaXQgc2VlbXMgdGhlcmUgaXMgbm8g ZGlmZmVyZWNlIGluIHNlbWFudGljcyBiZXR3ZWVuICJhbiBvcmRlcmVkIGxpc3Qgb2YgSVAgdHJh bnNpdCBob3BzIiBhbmQgImFuIG9yZGVyZWQgbGlzdCBvZiBWZWN0b3IgTm9kZXMiLiANCg0KVG8g c3VwcG9ydCB0cmFmZmljLWVuZ2lubmVyaW5nIGZvciBhIGdpdmVuIFZQTiB0cmFmZmljIGZsb3cg ZGVzdGluZWQgdG8gYSBnaXZlbiBDRSBob3N0IG9yIGN1c3RvbWVyIHNpdGUsIHNpbmNlIHRoZXNl IFZlY3RvciBOb2RlcyBNVVNUIGJlIEJHUCByb3V0ZXJzLCB0aGUgVEUgbWVjaGFuaXNtIHByb3Bv c2VkIGJ5IHRoaXMgZHJhZnQgc2VlbXMgaW5mbGV4aWJsZSBhbmQgdW5zY2FsYWJsZSBjb21wYXJl ZCB0byB0aGUgc291cmNlIHJvdXRpbmctYmFzZWQgVEUgbWVjaGFuaXNtLiBGdXJ0aGVybW9yZSwg d2l0aCB0aGUgVEUgbWVjaGFuaXNtIGRlZmluZWQgaW4gdGhpcyBkcmFmdCwgYWxsIHRyYWZmaWMg ZGVzdGluZWQgZm9yIGEgZ2l2ZW4gcHJlZml4IHdoaWNoIGlzIGFzc29jaWF0ZWQgd2l0aCBhIEJH UCBWZWN0b3IgTm9kZSBhdHRyaWJ1dGUgd291bGQgYmUgaW5mbHVlbmNlZCBubyBtYXR0ZXIgdGhl IHNvdXJjZSBvZiB0aGUgdHJhZmZpYy4gVGhpcyBpcyB1bnByYWN0aWNhbCBpbiBtYW55IGNhc2Vz LiBGb3IgaW5zdGFuY2UsIGFuIG9wZXJhdG9yIG1heSBqdXN0IHdhbnQgdG8gcGVyZm9ybSB0cmFm ZmljLWVuZ2lubmVyaW5nIG9uIHRoZSB0cmFmZmljIGZyb20gc2l0ZSBYIHRvIHNpdGUgWiwgYnV0 IG5vdCBvbiB0aGUgdHJhZmZpYyBmcm9tIHNpdGUgWSB0byBzaXRlIFouDQoNCkJlc3QgcmVnYXJk cywNClhpYW9odQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3 orz+yMs6IGlkci1ib3VuY2VzQGlldGYub3JnIFtpZHItYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBS b2JlcnQgUmFzenVrIFtyb2JlcnRAcmFzenVrLm5ldF0NCreiy83KsbzkOiAyMDEzxOoxMdTCOcjV IDEyOjE1DQrK1bz+yMs6IFh1eGlhb2h1DQqzrcvNOiBpZHJAaWV0Zi5vcmcNCtb3zOI6IFJlOiBb SWRyXSBDbGFyaWZ5IG15IGNvbW1lbm50cyBvbiAgIGRyYWZ0LXBhdGVsLXJhc3p1ay1iZ3AtdmVj dG9yLXJvdXRpbmctMDENCg0KSGksDQoNClRoZSB0ZXJtIFRyYW5zaXQgSG9wIGlzIGJlaW5nIG92 ZXJsb2FkZWQgaGVyZS4gTGV0J3MgZGl2aWRlIGl0IHRvIHRlcm0NCkJHUCBWZWN0b3IgTm9kZSBh bmQgUCByb3V0ZXIuDQoNCkJHUCBWZWN0b3IgTm9kZSBpcyBhIEJHUCBzcGVha2VyIC4uLiBQIHJv dXRlciBpcyBub3QuIFAgcm91dGVyIGp1c3QNCnN3aXRjaGVzIElQIHBhY2tldCBvciBNUExTIHBh Y2tldCB0byBpdHMgZGVzdGluYXRpb24gZW1iZWRkZWQgaW4gdGhlDQplbmNhcHN1bGF0aW9uIGhl YWRlci4NCg0KQmVzdCByZWdhcmRzLA0KUi4NCg0KT24gRnJpLCBOb3YgOCwgMjAxMyBhdCA3OjE2 IFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IEhpIGNvLWF1dGhv cnMgb2YgdGhpcyBkcmFmdCwNCj4NCj4gSXQgc2FpZCAiVmVjdG9yIE5vZGUgYXR0cmlidXRlIGNv bnNpc3Qgb2Ygb25lIG9yIG1vcmUgVExWcyB3aGljaCBjYXJyeSBvcmRlcmVkIGxpc3RzIG9mIElQ IFRyYW5zaXQgSG9wcyB0aGF0IG5lZWRzIHRvIGJlIHRyYXZlcnNlZCBiZWZvcmUgdGhlIHBhY2tl dCBpcyBmb3J3YXJkZWQgdG8gaXRzIGRlc3RpbmF0aW9uIiBpbiB0aGUgcHJlc2VudGF0aW9uIHNs aWRlcy4NCj4NCj4gTXkgcXVlc3Rpb24gdG8gdGhlIHNwZWFrZXIgd2FzIHdoZXRoZXIgdGhlIGFi b3ZlIElQIFRyYW5zaXQgSG9wcyBtdXN0IGJlIEJHUCByb3V0ZXJzLiBUaGUgYW5zd2VyIGlzIE5v LiBJZiBzbywgd2hlbiBhIHBhY2tldCBpcyBmb3J3YXJkZWQgIHRvIG9uZSBvZiB0aGUgYWJvdmUg VHJhbnNpdCBIb3Agd2hpY2ggaXMgbm9uLUJHUCByb3V0ZXIgYWNjb3JkaW5nIHRvIHRoZSB2ZWN0 b3Igcm91dGluZyBwcm9wb3NlZCBieSB0aGlzIGRyYWZ0LCBob3cgY291bGQgdGhhdCBUcmFuc2l0 IEhvcCBrbm93IHdoYXQgdGhlIG5leHQgSVAgVHJhbnNpdCBIb3AgaXMgZ2l2ZW4gdGhhdCB0aGlz IGRyYWZ0IGRvZXNuJ3QgcmVxdWlyZSBhbnkgY2hhbmdlIHRvIHRoZSBmb3J3YXJkaW5nIHBsYW5l Pw0KPg0KPiBCUiwNCj4gWGlhb2h1DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IElkciBtYWlsaW5nIGxpc3QNCj4gSWRyQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWRyIG1haWxpbmcgbGlzdA0KSWRyQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg== From rraszuk@gmail.com Fri Nov 8 22:33:23 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44EC21E80BC for ; Fri, 8 Nov 2013 22:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.95 X-Spam-Level: * X-Spam-Status: No, score=1.95 tagged_above=-999 required=5 tests=[AWL=-3.367, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfTzYNNoB6gP for ; Fri, 8 Nov 2013 22:33:23 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id F19B321E80CE for ; Fri, 8 Nov 2013 22:33:22 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id e14so4634741iej.25 for ; Fri, 08 Nov 2013 22:33:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=hbpPls2NVteqejDb00mZaacjfzQ/kZr0wD8w2YjImC0=; b=ZTZxZ1Olvt5FEZd/XjcwGgFQdjGEQUJenzZofdvaYhG+IEbNddtOekMYxDCYlHDI/K tWBWAi5Sns+TifPCt2K7RkpwcWU+X3sdCgDVQXXnPnqFqD/dkfXoM/3qOQTKu1wDS2QC 1AAqxnepFj2gZsCBzl9AM5evhLC8l53FbENXpVEcyFwrpDEV9kr1YGh7rxwE1/+Vrmo2 1igf/yBoATwXnfcDZOtymAFESN1shYI6nSbABLGfyPkDcJ031RwGlNGaEpCJojNwK/W6 CFpJtPbkr64qwh98xMiR/NeLgKHzwuuxA1bTrtsAgsz/BM+Ri0wdvg2tIt0ATWGO9Ptn 0puw== MIME-Version: 1.0 X-Received: by 10.50.11.67 with SMTP id o3mr5375814igb.55.1383978802360; Fri, 08 Nov 2013 22:33:22 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 8 Nov 2013 22:33:22 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BC2@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A3F@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BC2@NKGEML512-MBS.china.huawei.com> Date: Sat, 9 Nov 2013 07:33:22 +0100 X-Google-Sender-Auth: IFjktyCkmrlKgmCdFXqg9eAd3bA Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf.org" Subject: Re: [Idr] =?gb2312?b?tPC4tDogQ2xhcmlmeSBteSBjb21tZW5udHMgb24gZHJhZnQt?= =?gb2312?b?cGF0ZWwtcmFzenVrLWJncC12ZWN0b3Itcm91dGluZy0wMQ==?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 06:33:24 -0000 Hi Xiaohu, We will fix the terminology in next rev removing the notion of "transit node" entirely. > To support traffic-enginnering for a given VPN traffic flow destined to a > given CE host or customer site, since these Vector Nodes MUST be > BGP routers, the TE mechanism proposed by this draft seems inflexible > and unscalable compared to the source routing-based TE mechanism. As clearly mentioned today already this mechanism works for BGP routes in the global table or within context of VPN in any particular VRF. Naturally the solution focuses on steering the traffic going outside of your AS being global IPv4 and IPv6. This is not intended to steer traffic between your IGP next hops - for that you are much better to use Segment Routing technology. That is why those two are complimentary not exclusive solutions. Said this if I build data center model based on the EBGP interconnects across my fabric core as documented in the draft http://goo.gl/3ZMYl6 BGP vector routing can be of very good use to steer your virtualized tenant traffic. > Furthermore, with the TE mechanism defined in this draft, all traffic > destined for a given prefix which is associated with a BGP Vector > Node attribute would be influenced no matter the source of the traffic. > This is unpractical in many cases. For instance, an operator may just > want to perform traffic-enginnering on the traffic from site X to site Z, > but not on the traffic from site Y to site Z. That is not true either. As mentioned today you can apply this attribute to flow-spec SAFI and use it with any much more finer granularity of the flow as compared with per dst based routing. Best regards, R. > On Sat, Nov 9, 2013 at 7:03 AM, Xuxiaohu wrote: > Hi, > > The term "Transit Hop" is not overloaded HERE since there is a clear cont= ext that these Transit Hops are contained in the TLVs of BGP Vector Node at= tribute. BTW, there is only one place of your draft where "IP transit hops"= is used. > > ".... this document defines a new BGP > attribute known as a BGP Vector Node attribute. The BGP Vector Node > attribute consist of an ordered list of IP transit hops that needs to > be traversed before the packet is forwarded to its BGP NEXT HOP. The > information carried in the ordered list of Vector Node is used > towards augmenting the NEXT HOP information for the BGP prefixes as > carried in the MP_REACH attribute." > > According to the above description, it seems there is no differece in sem= antics between "an ordered list of IP transit hops" and "an ordered list of= Vector Nodes". > > To support traffic-enginnering for a given VPN traffic flow destined to a= given CE host or customer site, since these Vector Nodes MUST be BGP route= rs, the TE mechanism proposed by this draft seems inflexible and unscalable= compared to the source routing-based TE mechanism. Furthermore, with the T= E mechanism defined in this draft, all traffic destined for a given prefix = which is associated with a BGP Vector Node attribute would be influenced no= matter the source of the traffic. This is unpractical in many cases. For i= nstance, an operator may just want to perform traffic-enginnering on the tr= affic from site X to site Z, but not on the traffic from site Y to site Z. > > Best regards, > Xiaohu > > ________________________________________ > =B7=A2=BC=FE=C8=CB: idr-bounces@ietf.org [idr-bounces@ietf.org] =B4=FA=B1= =ED Robert Raszuk [robert@raszuk.net] > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C29=C8=D5 12:15 > =CA=D5=BC=FE=C8=CB: Xuxiaohu > =B3=AD=CB=CD: idr@ietf.org > =D6=F7=CC=E2: Re: [Idr] Clarify my commennts on draft-patel-raszuk-bgp-= vector-routing-01 > > Hi, > > The term Transit Hop is being overloaded here. Let's divide it to term > BGP Vector Node and P router. > > BGP Vector Node is a BGP speaker ... P router is not. P router just > switches IP packet or MPLS packet to its destination embedded in the > encapsulation header. > > Best regards, > R. > > On Fri, Nov 8, 2013 at 7:16 PM, Xuxiaohu wrote: >> Hi co-authors of this draft, >> >> It said "Vector Node attribute consist of one or more TLVs which carry o= rdered lists of IP Transit Hops that needs to be traversed before the packe= t is forwarded to its destination" in the presentation slides. >> >> My question to the speaker was whether the above IP Transit Hops must be= BGP routers. The answer is No. If so, when a packet is forwarded to one o= f the above Transit Hop which is non-BGP router according to the vector rou= ting proposed by this draft, how could that Transit Hop know what the next = IP Transit Hop is given that this draft doesn't require any change to the f= orwarding plane? >> >> BR, >> Xiaohu >> _______________________________________________ >> 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 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From xuxiaohu@huawei.com Fri Nov 8 23:33:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C171B21E80F3 for ; Fri, 8 Nov 2013 23:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.907 X-Spam-Level: X-Spam-Status: No, score=0.907 tagged_above=-999 required=5 tests=[AWL=-1.542, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbyUZbuDLbww for ; Fri, 8 Nov 2013 23:33:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9CF21E8056 for ; Fri, 8 Nov 2013 23:33:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAB73628; Sat, 09 Nov 2013 07:33:30 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 9 Nov 2013 07:33:24 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 9 Nov 2013 07:33:28 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Sat, 9 Nov 2013 15:33:22 +0800 From: Xuxiaohu To: Robert Raszuk Thread-Topic: =?gb2312?B?W0lkcl0JtPC4tDogQ2xhcmlmeSBteSBjb21tZW5udHMgb24gZHJhZnQtcGF0?= =?gb2312?Q?el-raszuk-bgp-vector-routing-01?= Thread-Index: AQHO3RWcLq2NfcTcdE+tZz7JsIC1S5ocdGGS Date: Sat, 9 Nov 2013 07:33:21 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227C24@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A3F@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BC2@NKGEML512-MBS.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.157.237] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "idr@ietf.org" Subject: [Idr] =?gb2312?b?tPC4tDogCbTwuLQ6IENsYXJpZnkgbXkgY29tbWVubnRzIG9u?= =?gb2312?b?IGRyYWZ0LXBhdGVsLXJhc3p1ay1iZ3AtdmVjdG9yLXJvdXRpbmctMDE=?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 07:33:36 -0000 SGkgUm9iZXJ0LA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3 orz+yMs6IGlkci1ib3VuY2VzQGlldGYub3JnIFtpZHItYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBS b2JlcnQgUmFzenVrIFtyb2JlcnRAcmFzenVrLm5ldF0NCreiy83KsbzkOiAyMDEzxOoxMdTCOcjV IDE0OjMzDQrK1bz+yMs6IFh1eGlhb2h1DQqzrcvNOiBpZHJAaWV0Zi5vcmcNCtb3zOI6IFJlOiBb SWRyXSAgILTwuLQ6IENsYXJpZnkgbXkgY29tbWVubnRzIG9uIGRyYWZ0LXBhdGVsLXJhc3p1ay1i Z3AtdmVjdG9yLXJvdXRpbmctMDENCg0KSGkgWGlhb2h1LA0KDQpXZSB3aWxsIGZpeCB0aGUgdGVy bWlub2xvZ3kgaW4gbmV4dCByZXYgcmVtb3ZpbmcgdGhlIG5vdGlvbiBvZg0KInRyYW5zaXQgbm9k ZSIgZW50aXJlbHkuDQoNCj4gVG8gc3VwcG9ydCB0cmFmZmljLWVuZ2lubmVyaW5nIGZvciBhIGdp dmVuIFZQTiB0cmFmZmljIGZsb3cgZGVzdGluZWQgdG8gYQ0KPiBnaXZlbiBDRSBob3N0IG9yIGN1 c3RvbWVyIHNpdGUsIHNpbmNlIHRoZXNlIFZlY3RvciBOb2RlcyBNVVNUIGJlDQo+IEJHUCByb3V0 ZXJzLCB0aGUgVEUgbWVjaGFuaXNtIHByb3Bvc2VkIGJ5IHRoaXMgZHJhZnQgc2VlbXMgaW5mbGV4 aWJsZQ0KPiBhbmQgdW5zY2FsYWJsZSBjb21wYXJlZCB0byB0aGUgc291cmNlIHJvdXRpbmctYmFz ZWQgVEUgbWVjaGFuaXNtLg0KDQpBcyBjbGVhcmx5IG1lbnRpb25lZCB0b2RheSBhbHJlYWR5IHRo aXMgbWVjaGFuaXNtIHdvcmtzIGZvciBCR1Agcm91dGVzDQppbiB0aGUgZ2xvYmFsIHRhYmxlIG9y IHdpdGhpbiBjb250ZXh0IG9mIFZQTiBpbiBhbnkgcGFydGljdWxhciBWUkYuDQpOYXR1cmFsbHkg dGhlIHNvbHV0aW9uIGZvY3VzZXMgb24gc3RlZXJpbmcgdGhlIHRyYWZmaWMgZ29pbmcgb3V0c2lk ZQ0Kb2YgeW91ciBBUyBiZWluZyBnbG9iYWwgSVB2NCBhbmQgSVB2Ni4NCg0KW1hpYW9odV0gRXZl biBmb3IgZ2xvYmFsIElQIHRyYWZmaWMsIHRoZXJlIGlzIG5vIG5lZWQgZm9yIEVSIGhvcHMgdG8g bWFpbnRhaW4gYSBsb3Qgb2Ygcm91dGVzIGZvciB0aGUgZGVzdGluYXRpb25zIG9mIHRob3NlIGds b2JhbCB0cmFmZmljIGluIHRoZSBzb3VyY2Utcm91dGluZy1iYXNlZCBURSBtZWNoYW5pc20uIEVS IGhvcHMganVzdCBuZWVkcyB0byBrbm93IGhvdyB0byByZWFjaCB0aGUgbmV4dCBFUiBob3AuDQoN ClRoaXMgaXMgbm90IGludGVuZGVkIHRvIHN0ZWVyIHRyYWZmaWMgYmV0d2VlbiB5b3VyIElHUCBu ZXh0IGhvcHMgLSBmb3INCnRoYXQgeW91IGFyZSBtdWNoIGJldHRlciB0byB1c2UgU2VnbWVudCBS b3V0aW5nIHRlY2hub2xvZ3kuIFRoYXQgaXMNCndoeSB0aG9zZSB0d28gYXJlIGNvbXBsaW1lbnRh cnkgbm90IGV4Y2x1c2l2ZSBzb2x1dGlvbnMuDQoNClNhaWQgdGhpcyBpZiBJIGJ1aWxkIGRhdGEg Y2VudGVyIG1vZGVsIGJhc2VkIG9uIHRoZSBFQkdQIGludGVyY29ubmVjdHMNCmFjcm9zcyBteSBm YWJyaWMgY29yZSBhcyBkb2N1bWVudGVkIGluIHRoZSBkcmFmdCBodHRwOi8vZ29vLmdsLzNaTVls Ng0KQkdQIHZlY3RvciByb3V0aW5nIGNhbiBiZSBvZiB2ZXJ5IGdvb2QgdXNlIHRvIHN0ZWVyIHlv dXIgdmlydHVhbGl6ZWQNCnRlbmFudCB0cmFmZmljLg0KDQo+IEZ1cnRoZXJtb3JlLCB3aXRoIHRo ZSBURSBtZWNoYW5pc20gZGVmaW5lZCBpbiB0aGlzIGRyYWZ0LCBhbGwgdHJhZmZpYw0KPiBkZXN0 aW5lZCBmb3IgYSBnaXZlbiBwcmVmaXggd2hpY2ggaXMgYXNzb2NpYXRlZCB3aXRoIGEgQkdQIFZl Y3Rvcg0KPiBOb2RlIGF0dHJpYnV0ZSB3b3VsZCBiZSBpbmZsdWVuY2VkIG5vIG1hdHRlciB0aGUg c291cmNlIG9mIHRoZSB0cmFmZmljLg0KPiBUaGlzIGlzIHVucHJhY3RpY2FsIGluIG1hbnkgY2Fz ZXMuIEZvciBpbnN0YW5jZSwgYW4gb3BlcmF0b3IgbWF5IGp1c3QNCj4gd2FudCB0byBwZXJmb3Jt IHRyYWZmaWMtZW5naW5uZXJpbmcgb24gdGhlIHRyYWZmaWMgZnJvbSBzaXRlIFggdG8gc2l0ZSBa LA0KPiBidXQgbm90IG9uIHRoZSB0cmFmZmljIGZyb20gc2l0ZSBZIHRvIHNpdGUgWi4NCg0KVGhh dCBpcyBub3QgdHJ1ZSBlaXRoZXIuIEFzIG1lbnRpb25lZCB0b2RheSB5b3UgY2FuIGFwcGx5IHRo aXMNCmF0dHJpYnV0ZSB0byBmbG93LXNwZWMgU0FGSSBhbmQgdXNlIGl0IHdpdGggYW55IG11Y2gg bW9yZSBmaW5lcg0KZ3JhbnVsYXJpdHkgb2YgdGhlIGZsb3cgYXMgY29tcGFyZWQgd2l0aCBwZXIg ZHN0IGJhc2VkIHJvdXRpbmcuDQoNCltYaWFvaHVdIFNvcnJ5IHRoYXQgSSBoYXZlIG5vdCB5ZXQg Zm91bmQgYW55IG1lbnRpb24gb2YgZmxvdy1zcGVjIFNBRkkgaW4geW91ciBjdXJyZW50IGRyYWZ0 OykgIEl0IHNlZW1zIHRoYXQgeW91IGludGVuZCB0byBnbyBhIHN0ZXAgZnVydGhlciBiZXlvbmQg dGhlIFJlZGlyZWN0IHRvIElQIEV4dGVuZGVkIENvbW11bml0eSBieSByZWRpcmVjdGluZyB0byBh IGxvb3NlIGV4cGxpY2l0IHBhdGguIEl0IHdvdWxkIGJlIGJldHRlciB0byBtZW50aW9uIHRoaXMg aW4gdGhlIGRyYWZ0Lg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KDQpCZXN0IHJlZ2FyZHMs DQpSLg0KDQoNCg0KDQoNCg0KDQoNCj4gT24gU2F0LCBOb3YgOSwgMjAxMyBhdCA3OjAzIEFNLCBY dXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+IEhpLA0KPg0KPiBUaGUgdGVy bSAiVHJhbnNpdCBIb3AiIGlzIG5vdCBvdmVybG9hZGVkIEhFUkUgc2luY2UgdGhlcmUgaXMgYSBj bGVhciBjb250ZXh0IHRoYXQgdGhlc2UgVHJhbnNpdCBIb3BzIGFyZSBjb250YWluZWQgaW4gdGhl IFRMVnMgb2YgQkdQIFZlY3RvciBOb2RlIGF0dHJpYnV0ZS4gQlRXLCB0aGVyZSBpcyBvbmx5IG9u ZSBwbGFjZSBvZiB5b3VyIGRyYWZ0IHdoZXJlICJJUCB0cmFuc2l0IGhvcHMiIGlzIHVzZWQuDQo+ DQo+ICIuLi4uIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBCR1ANCj4gICAgYXR0cmlidXRl IGtub3duIGFzIGEgQkdQIFZlY3RvciBOb2RlIGF0dHJpYnV0ZS4gIFRoZSBCR1AgVmVjdG9yIE5v ZGUNCj4gICAgYXR0cmlidXRlIGNvbnNpc3Qgb2YgYW4gb3JkZXJlZCBsaXN0IG9mIElQIHRyYW5z aXQgaG9wcyB0aGF0IG5lZWRzIHRvDQo+ICAgIGJlIHRyYXZlcnNlZCBiZWZvcmUgdGhlIHBhY2tl dCBpcyBmb3J3YXJkZWQgdG8gaXRzIEJHUCBORVhUIEhPUC4gIFRoZQ0KPiAgICBpbmZvcm1hdGlv biBjYXJyaWVkIGluIHRoZSBvcmRlcmVkIGxpc3Qgb2YgVmVjdG9yIE5vZGUgaXMgdXNlZA0KPiAg ICB0b3dhcmRzIGF1Z21lbnRpbmcgdGhlIE5FWFQgSE9QIGluZm9ybWF0aW9uIGZvciB0aGUgQkdQ IHByZWZpeGVzIGFzDQo+ICAgIGNhcnJpZWQgaW4gdGhlIE1QX1JFQUNIIGF0dHJpYnV0ZS4iDQo+ DQo+IEFjY29yZGluZyB0byB0aGUgYWJvdmUgZGVzY3JpcHRpb24sIGl0IHNlZW1zIHRoZXJlIGlz IG5vIGRpZmZlcmVjZSBpbiBzZW1hbnRpY3MgYmV0d2VlbiAiYW4gb3JkZXJlZCBsaXN0IG9mIElQ IHRyYW5zaXQgaG9wcyIgYW5kICJhbiBvcmRlcmVkIGxpc3Qgb2YgVmVjdG9yIE5vZGVzIi4NCj4N Cj4gVG8gc3VwcG9ydCB0cmFmZmljLWVuZ2lubmVyaW5nIGZvciBhIGdpdmVuIFZQTiB0cmFmZmlj IGZsb3cgZGVzdGluZWQgdG8gYSBnaXZlbiBDRSBob3N0IG9yIGN1c3RvbWVyIHNpdGUsIHNpbmNl IHRoZXNlIFZlY3RvciBOb2RlcyBNVVNUIGJlIEJHUCByb3V0ZXJzLCB0aGUgVEUgbWVjaGFuaXNt IHByb3Bvc2VkIGJ5IHRoaXMgZHJhZnQgc2VlbXMgaW5mbGV4aWJsZSBhbmQgdW5zY2FsYWJsZSBj b21wYXJlZCB0byB0aGUgc291cmNlIHJvdXRpbmctYmFzZWQgVEUgbWVjaGFuaXNtLiBGdXJ0aGVy bW9yZSwgd2l0aCB0aGUgVEUgbWVjaGFuaXNtIGRlZmluZWQgaW4gdGhpcyBkcmFmdCwgYWxsIHRy YWZmaWMgZGVzdGluZWQgZm9yIGEgZ2l2ZW4gcHJlZml4IHdoaWNoIGlzIGFzc29jaWF0ZWQgd2l0 aCBhIEJHUCBWZWN0b3IgTm9kZSBhdHRyaWJ1dGUgd291bGQgYmUgaW5mbHVlbmNlZCBubyBtYXR0 ZXIgdGhlIHNvdXJjZSBvZiB0aGUgdHJhZmZpYy4gVGhpcyBpcyB1bnByYWN0aWNhbCBpbiBtYW55 IGNhc2VzLiBGb3IgaW5zdGFuY2UsIGFuIG9wZXJhdG9yIG1heSBqdXN0IHdhbnQgdG8gcGVyZm9y bSB0cmFmZmljLWVuZ2lubmVyaW5nIG9uIHRoZSB0cmFmZmljIGZyb20gc2l0ZSBYIHRvIHNpdGUg WiwgYnV0IG5vdCBvbiB0aGUgdHJhZmZpYyBmcm9tIHNpdGUgWSB0byBzaXRlIFouDQo+DQo+IEJl c3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gt6K8/sjLOiBpZHItYm91bmNlc0BpZXRmLm9yZyBbaWRyLWJvdW5jZXNA aWV0Zi5vcmddILT6se0gUm9iZXJ0IFJhc3p1ayBbcm9iZXJ0QHJhc3p1ay5uZXRdDQo+ILeiy83K sbzkOiAyMDEzxOoxMdTCOcjVIDEyOjE1DQo+IMrVvP7IyzogWHV4aWFvaHUNCj4gs63LzTogaWRy QGlldGYub3JnDQo+INb3zOI6IFJlOiBbSWRyXSBDbGFyaWZ5IG15IGNvbW1lbm50cyBvbiAgIGRy YWZ0LXBhdGVsLXJhc3p1ay1iZ3AtdmVjdG9yLXJvdXRpbmctMDENCj4NCj4gSGksDQo+DQo+IFRo ZSB0ZXJtIFRyYW5zaXQgSG9wIGlzIGJlaW5nIG92ZXJsb2FkZWQgaGVyZS4gTGV0J3MgZGl2aWRl IGl0IHRvIHRlcm0NCj4gQkdQIFZlY3RvciBOb2RlIGFuZCBQIHJvdXRlci4NCj4NCj4gQkdQIFZl Y3RvciBOb2RlIGlzIGEgQkdQIHNwZWFrZXIgLi4uIFAgcm91dGVyIGlzIG5vdC4gUCByb3V0ZXIg anVzdA0KPiBzd2l0Y2hlcyBJUCBwYWNrZXQgb3IgTVBMUyBwYWNrZXQgdG8gaXRzIGRlc3RpbmF0 aW9uIGVtYmVkZGVkIGluIHRoZQ0KPiBlbmNhcHN1bGF0aW9uIGhlYWRlci4NCj4NCj4gQmVzdCBy ZWdhcmRzLA0KPiBSLg0KPg0KPiBPbiBGcmksIE5vdiA4LCAyMDEzIGF0IDc6MTYgUE0sIFh1eGlh b2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4+IEhpIGNvLWF1dGhvcnMgb2YgdGhp cyBkcmFmdCwNCj4+DQo+PiBJdCBzYWlkICJWZWN0b3IgTm9kZSBhdHRyaWJ1dGUgY29uc2lzdCBv ZiBvbmUgb3IgbW9yZSBUTFZzIHdoaWNoIGNhcnJ5IG9yZGVyZWQgbGlzdHMgb2YgSVAgVHJhbnNp dCBIb3BzIHRoYXQgbmVlZHMgdG8gYmUgdHJhdmVyc2VkIGJlZm9yZSB0aGUgcGFja2V0IGlzIGZv cndhcmRlZCB0byBpdHMgZGVzdGluYXRpb24iIGluIHRoZSBwcmVzZW50YXRpb24gc2xpZGVzLg0K Pj4NCj4+IE15IHF1ZXN0aW9uIHRvIHRoZSBzcGVha2VyIHdhcyB3aGV0aGVyIHRoZSBhYm92ZSBJ UCBUcmFuc2l0IEhvcHMgbXVzdCBiZSBCR1Agcm91dGVycy4gVGhlIGFuc3dlciBpcyBOby4gSWYg c28sIHdoZW4gYSBwYWNrZXQgaXMgZm9yd2FyZGVkICB0byBvbmUgb2YgdGhlIGFib3ZlIFRyYW5z aXQgSG9wIHdoaWNoIGlzIG5vbi1CR1Agcm91dGVyIGFjY29yZGluZyB0byB0aGUgdmVjdG9yIHJv dXRpbmcgcHJvcG9zZWQgYnkgdGhpcyBkcmFmdCwgaG93IGNvdWxkIHRoYXQgVHJhbnNpdCBIb3Ag a25vdyB3aGF0IHRoZSBuZXh0IElQIFRyYW5zaXQgSG9wIGlzIGdpdmVuIHRoYXQgdGhpcyBkcmFm dCBkb2Vzbid0IHJlcXVpcmUgYW55IGNoYW5nZSB0byB0aGUgZm9yd2FyZGluZyBwbGFuZT8NCj4+ DQo+PiBCUiwNCj4+IFhpYW9odQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IElkciBtYWlsaW5nIGxpc3QNCj4+IElkckBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHINCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSWRyIG1haWxpbmcgbGlzdA0K PiBJZHJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZHINCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g SWRyIG1haWxpbmcgbGlzdA0KPiBJZHJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pZHINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRy From rraszuk@gmail.com Fri Nov 8 23:51:21 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D2F11E8151 for ; Fri, 8 Nov 2013 23:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[AWL=-1.966, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzLaUZIKbRGI for ; Fri, 8 Nov 2013 23:51:21 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 01D7411E8131 for ; Fri, 8 Nov 2013 23:51:20 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id at1so4881186iec.15 for ; Fri, 08 Nov 2013 23:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BoUkvvUQtgqr9SPlUVqu/EpngPGhbcQSsK+6xNf6Y7U=; b=aLWCSNMGf+DehBpeimVsB49Ekmm7VJaG1aHEt2E2TeGccP83vgt8mN+2EPt/po4kTo a5TsMugjw7saZ8CkWYXByJ7bTGrGnXHLPTfKTDD0PhmwC7/b8pFOW74L53SLS1bssRQd 0mA2Ejk9VpdD092TxERGxdgTVUCVdE5TdBF23NPgM7mPczSp3kzNz9EnItsNWC2sQtt8 +LqwH8XtMAi2dYId9duJnAF99RPurdYS8naDUNVMnvYIlPhLhEZGeWryj27FN+Gb0w0F huwufGO8c2B7NJ4oWoc25BbqcKYpqvFyj9vcC7WI5nf3VR7xM92sn1XH3FMyatU1HLBK kTbw== MIME-Version: 1.0 X-Received: by 10.50.16.45 with SMTP id c13mr5539479igd.55.1383983480351; Fri, 08 Nov 2013 23:51:20 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Fri, 8 Nov 2013 23:51:20 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227C24@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A3F@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BC2@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227C24@NKGEML512-MBS.china.huawei.com> Date: Sat, 9 Nov 2013 08:51:20 +0100 X-Google-Sender-Auth: unc9S6vaH3K5bBKICiJk_UpsHig Message-ID: From: Robert Raszuk To: Xuxiaohu Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf.org" Subject: Re: [Idr] =?gb2312?b?tPC4tDogILTwuLQ6IENsYXJpZnkgbXkgY29tbWVubnRzIG9u?= =?gb2312?b?IGRyYWZ0LXBhdGVsLXJhc3p1ay1iZ3AtdmVjdG9yLXJvdXRpbmct?= =?gb2312?b?MDE=?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 07:51:21 -0000 > [Xiaohu] Even for global IP traffic, there is no need for ER hops to maintain a > lot of routes for the destinations of those global traffic in the source-routing-based > TE mechanism. ER hops just needs to know how to reach the next ER hop. That's a trade-off if you are encoding the path in each data packet, signalling your path by for example RSVP-TE or you building the topology in the control plane. IMHO there is room for all three of the above in current networks and it would be operators to choose which architecture they use and which fits best their needs. > [Xiaohu] Sorry that I have not yet found any mention of flow-spec SAFI in > your current draft;) Please seriously consider taking a second look. The text is pretty clear there in version -01: In the presence of requirement for more selective then to entire IP destination packet handling (example separate port 80 http traffic from delay sensitve packets) the BGP Vector Node attribute can be attached to BGP update containing Dissemination of Flow Specification Rules RFC 5575 [RFC5575] where traffic action is defined as new E bit (Encapsulate). 40 41 42 43 44 45 46 47 +---+---+---+---+---+---+---+---+ | reserved | E | S | T | +---+---+---+---+---+---+---+---+ E-bit - defines new action which results in encapsulation of matching packets to the next vector node as specified in the BGP Vector Node Attribute. Regards, R. From xuxiaohu@huawei.com Sat Nov 9 01:07:26 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD4221E8108 for ; Sat, 9 Nov 2013 01:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=1.273, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwF+ZS2BttGR for ; Sat, 9 Nov 2013 01:07:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AEEF021E80F0 for ; Sat, 9 Nov 2013 01:07:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAB77633; Sat, 09 Nov 2013 09:06:59 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 9 Nov 2013 09:06:53 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 9 Nov 2013 09:06:57 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sat, 9 Nov 2013 17:06:49 +0800 From: Xuxiaohu To: Robert Raszuk Thread-Topic: =?big5?B?W0lkcl0JtarOYDogILWqzmA6IENsYXJpZnkgbXkgY29tbWVubnRzIG9uIGRyYWZ0?= =?big5?Q?-patel-raszuk-bgp-vector-routing-01?= Thread-Index: AQHO3SCBU3HNX3Ja5kmqFbK8v2opo5oclWmW Date: Sat, 9 Nov 2013 09:06:48 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227C55@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227A3F@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227BC2@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227C24@NKGEML512-MBS.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.222] Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "idr@ietf.org" Subject: [Idr] =?big5?b?tarOYDogCbWqzmA6ICC1qs5gOiBDbGFyaWZ5IG15IGNvbW1l?= =?big5?b?bm50cyBvbiBkcmFmdC1wYXRlbC1yYXN6dWstYmdwLXZlY3Rvci1yb3V0aW5nLTAx?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 09:07:26 -0000 SGkgUm9iZXJ0LA0KDQpUaGFua3MgZm9yIHBvaW50aW5nIGl0IG91dC4gSSBoYXZlIG9ubHkgcmVh ZCB0aGUgLTAwIGRyYWZ0IHdoaWNoIHdhcyBsaXN0ZWQgb24gdGhlIGFnZW5kYS4NCg0KQlRXLCB0 aGUgb3JkZXJlZCBsaXN0IG9mIFZlY3RvciBOb2RlcyBsb29rcyBsaWtlIGEgaGlnaHdheSB3aGls ZSB0aGUgbm9ybWFsIEJHUCBwYXRoIGxvb2tzIGxpa2UgYSByb2FkLCBvbmNlIGEgY2FyIChpLmUu LCBhIHBhY2tldCkgZW50ZXJzIHRoZSBoaWdod2F5cyBzb21laG93LCBpdCBzaG91bGQgbm90IGV4 aXQgdGhlIGhpZ2h3YXkgdW50aWwgaXQgaGFzIHJlYWNoZWQgdGhlIGZpbmFsIGRlc3RpbmF0aW9u Lk90aGVyd2lzZSwgaXQgbWF5IGNhdXNlIGxvb3AuIEhlbmNlLCBpdCBzZWVtcyB0aGF0IHRob3Nl IEJHUCBWZWN0b3IgTm9kZXMgbGlzdGVkIGluIHRoZSBCR1AgVmVjdG9yIE5vZGUgYXR0cmlidXRl IG11c3QgYmUgbmV3IEJHUCByb3V0ZXJzIHdoaWNoIGNhbiByZWNvZ25pemUgdGhpcyBCR1AgVmVj dG9yIE5vZGUgYXR0cmlidXRlLCBpbiBhZGRpdGlvbiwgdGhlIGxhc3QgVmVjdG9yIE5vZGUgb24g dGhlIGxpc3QgbXVzdCBiZSB0aGUgZWdyZXNzIG9mIHRoZSBwcmVmaXguIEl0IHdvdWxkIGJlIGJl dHRlciB0byBhZGQgdGhlIGFib3ZlIGNvbnNpZGVyYXRpb25zIHRvIHRoZSBkcmFmdC4NCg0KWGlh b2h1DQoNCj4gW1hpYW9odV0gU29ycnkgdGhhdCBJIGhhdmUgbm90IHlldCBmb3VuZCBhbnkgbWVu dGlvbiBvZiBmbG93LXNwZWMgU0FGSSBpbg0KPiB5b3VyIGN1cnJlbnQgZHJhZnQ7KQ0KDQpQbGVh c2Ugc2VyaW91c2x5IGNvbnNpZGVyIHRha2luZyBhIHNlY29uZCBsb29rLiBUaGUgdGV4dCBpcyBw cmV0dHkNCmNsZWFyIHRoZXJlIGluIHZlcnNpb24gLTAxOg0KDQogICBJbiB0aGUgcHJlc2VuY2Ug b2YgcmVxdWlyZW1lbnQgZm9yIG1vcmUgc2VsZWN0aXZlIHRoZW4gdG8gZW50aXJlIElQDQogICBk ZXN0aW5hdGlvbiBwYWNrZXQgaGFuZGxpbmcgKGV4YW1wbGUgc2VwYXJhdGUgcG9ydCA4MCBodHRw IHRyYWZmaWMNCiAgIGZyb20gZGVsYXkgc2Vuc2l0dmUgcGFja2V0cykgdGhlIEJHUCBWZWN0b3Ig Tm9kZSBhdHRyaWJ1dGUgY2FuIGJlDQogICBhdHRhY2hlZCB0byBCR1AgdXBkYXRlIGNvbnRhaW5p bmcgRGlzc2VtaW5hdGlvbiBvZiBGbG93IFNwZWNpZmljYXRpb24NCiAgIFJ1bGVzIFJGQyA1NTc1 IFtSRkM1NTc1XSB3aGVyZSB0cmFmZmljIGFjdGlvbiBpcyBkZWZpbmVkIGFzIG5ldyBFIGJpdA0K ICAgKEVuY2Fwc3VsYXRlKS4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIDQwICA0MSAg NDIgIDQzICA0NCAgNDUgIDQ2ICA0Nw0KICAgICAgICAgICAgICAgICAgICAgICAgKy0tLSstLS0r LS0tKy0tLSstLS0rLS0tKy0tLSstLS0rDQogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg cmVzZXJ2ZWQgICAgIHwgRSB8IFMgfCBUIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICstLS0r LS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKw0KDQoNCiAgIEUtYml0IC0gZGVmaW5lcyBuZXcg YWN0aW9uIHdoaWNoIHJlc3VsdHMgaW4gZW5jYXBzdWxhdGlvbiBvZiBtYXRjaGluZw0KICAgcGFj a2V0cyB0byB0aGUgbmV4dCB2ZWN0b3Igbm9kZSBhcyBzcGVjaWZpZWQgaW4gdGhlIEJHUCBWZWN0 b3IgTm9kZQ0KICAgQXR0cmlidXRlLg0KDQpSZWdhcmRzLA0KUi4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0DQpJZHJAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRy From wwwrun@rfc-editor.org Mon Nov 11 00:09:48 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F38521E8127 for ; Mon, 11 Nov 2013 00:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kiry4eS5qsTc for ; Mon, 11 Nov 2013 00:09:47 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE8721E811E for ; Mon, 11 Nov 2013 00:09:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 69761726001; Mon, 11 Nov 2013 00:00:02 -0800 (PST) To: stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20131111080002.69761726001@rfc-editor.org> Date: Mon, 11 Nov 2013 00:00:02 -0800 (PST) Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC1774 (3794) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 08:09:48 -0000 The following errata report has been submitted for RFC1774, "BGP-4 Protocol Analysis". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=1774&eid=3794 -------------------------------------- Type: Editorial Reported by: Ramakrishna DTV Section: 2 Original Text ------------- To allow graceful coexistence with EGP and OSPF, BGP provides support for carrying both EGP and OSPF derived exterior routes BGP also allows to carry statically defined exterior routes or routes derived by other IGP information. Corrected Text -------------- To allow graceful coexistence with EGP and OSPF, BGP provides support for carrying both EGP and OSPF derived exterior routes. BGP also allows to carry statically defined exterior routes or routes derived by other IGP information. Notes ----- This is a run-on sentence, missing ".". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC1774 (no draft string recorded) -------------------------------------- Title : BGP-4 Protocol Analysis Publication Date : March 1995 Author(s) : P. Traina, Ed. Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From RAMAKRISHNADTV@infosys.com Mon Nov 11 02:55:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F99611E8159 for ; Mon, 11 Nov 2013 02:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhd9jfZuo55O for ; Mon, 11 Nov 2013 02:55:30 -0800 (PST) Received: from KECGATE08.infosys.com (kecgate08.infosysconsulting.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id CFD8F21E80EC for ; Mon, 11 Nov 2013 02:55:23 -0800 (PST) X-TM-IMSS-Message-ID: <57832310000b1443@infosys.com> Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 57832310000b1443 ; Mon, 11 Nov 2013 16:25:08 +0530 Received: from BLRKECHUB09.ad.infosys.com (10.66.236.119) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 11 Nov 2013 16:23:04 +0530 Received: from BLRKECMBX23.ad.infosys.com ([fe80::d9f9:2028:fd8:1e35]) by Blrkechub09.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Mon, 11 Nov 2013 16:23:04 +0530 From: RAMAKRISHNADTV To: Jeffrey Haas , RFC Errata System Thread-Topic: [Idr] [Editorial Errata Reported] RFC4273 (3782) Thread-Index: AQHO2fMsB9xxiWCiu0iBHu8Saio2PpoYkSIAgAdSjBQ= Date: Mon, 11 Nov 2013 10:53:04 +0000 Message-ID: References: <20131105064027.BB22075E011@rfc-editor.org>, <20131107003054.GB7283@pfrc> In-Reply-To: <20131107003054.GB7283@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "skh@nexthop.com" , "idr@ietf.org" , "jhaas@nexthop.com" , "shares@ndzh.com" Subject: Re: [Idr] [Editorial Errata Reported] RFC4273 (3782) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 10:55:36 -0000 Thank you for the clarification.=0A=0AWhile I agree that the current text= is technically correct, it is less precise.=0AThat's why I wanted to upd= ate it. I was not aware of the standard SNMP MIB boiler=0Aplate.=0A=0AWhi= le I agree that the best place to get it corrected is SNMP MIB boiler pla= te=0Aitself, it appears that SNMP MIB boiler plate already allows its te= xt to be=0Atuned for individual RFCs in this regard.=0A=0AThe following M= IB RFCs seem to have tuned the boiler plate text exactly in the=0Asame wa= y I was suggesting for RFC 4273:=0A=0ARFC 6825=0A "There are several o= bjects defined in this MIB module that have a MAX-=0A ACCESS clause o= f read-write."=0A=0ARFC 4044=0A "There are a number of management obje= cts defined in this MIB that=0A have a MAX-ACCESS clause of read-writ= e:"=0A=0ARFC 4022=0A "There are a number of management objects defined= in this MIB module=0A with a MAX-ACCESS clause of read-write."=0A=0A= RFC 3418=0A "There are a number of management objects defined in this = MIB that=0A have a MAX-ACCESS clause of read-write."=0A=0AThanks and = regards,=0ARamakrishna DTV.=0A=0A>=0A> Section: 5=0A>=0A> Original Text= =0A> -------------=0A> There are several management objects defined in th= is MIB that have a=0A> MAX-ACCESS clause of read-write and/or read-create= .=0A>=0A> Corrected Text=0A> --------------=0A> There are several managem= ent objects defined in this MIB that have a=0A> MAX-ACCESS clause of read= -write.=0A>=0A> Notes=0A> -----=0A> No object in this MIB has MAX-ACCESS = clause of "read-create".=0A=0AThe cited text is standard SNMP MIB boilerp= late. The alternative as=0Aspecified by "and/or" is a standard English s= horthand for "both may be=0Apresent or one may be present". Thus while t= he reporter is correct, I do=0Anot believe anything would be altered toda= y.=0A=0AMy recommendation is that the reporter work with the MIB doctors = to adjust=0Astandard Internet boilerplate.=0A=0A-- Jeff **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease notify the sender by e-mail and delete the original message. Further, you= are not to copy, disclose, or distribute this e-mail or its contents to any other= person and any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken every reasonable precaution to minimize this risk, but is not liable for = any damage you may sustain as a result of any virus in this e-mail. You should carry= out your own virus checks before opening the e-mail or attachment. Infosys reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From bduvivie@cisco.com Mon Nov 11 06:51:24 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED73D21F9E44 for ; Mon, 11 Nov 2013 06:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfOybuwgnPG2 for ; Mon, 11 Nov 2013 06:51:09 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C48A721E8064 for ; Mon, 11 Nov 2013 06:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=619; q=dns/txt; s=iport; t=1384181469; x=1385391069; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/f2zW9EOzp6moAy+1jyCre7adG/L6YATBJOeQTCK9vo=; b=K4RSohtL4EjS556WgwYGbzADnrRJtt+ulXHBXy1+htOLlvqN5ozfTQ+3 GpOlRw2gm9bMsSdUBUShUaPVWDTy7R7E7rST5tsNw+BWC4x1jzz+ndP4x gDw9D2OvG1uoLoR8jgFNrxZd1UQW4QaE5aoSPjv7J5b4JsAYafnV8DCoy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAHPtgFKtJV2Y/2dsb2JhbABZgwc4U78XgToWdIIlAQEBBAEBATc0FwQCAQgRBAEBAQoUCQcnCxQJCAIEARIIh3kNvgEEjzY4BoMagRADqhmDJoIq X-IronPort-AV: E=Sophos;i="4.93,678,1378857600"; d="scan'208";a="280283052" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 11 Nov 2013 14:51:07 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rABEp7IT013853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 14:51:07 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.19]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 08:51:07 -0600 From: "Bertrand Duvivier (bduvivie)" To: Nick Hilliard , Russ White , "'Jeffrey Haas'" , "idr@ietf.org" Thread-Topic: [Idr] Advancing add-path Thread-Index: AQGkBg+4Kp4SLP5wbxoUgNIMCH96/ZpmzGUwgADnaoCAAB/sAIAANsSAgA3EMGA= Date: Mon, 11 Nov 2013 14:51:06 +0000 Message-ID: <5F1FD493E541C642ABBC18EDC327C82F1F36E414@xmb-aln-x11.cisco.com> References: <20131024204333.GS17538@pfrc> <059d01ced76c$55bea3c0$013beb40$@riw.us> <5274D371.9010002@inex.ie> <012a01ced7c6$066d83e0$13488ba0$@riw.us> <52751C29.9060109@inex.ie> In-Reply-To: <52751C29.9060109@inex.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.113.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] Advancing add-path X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 14:51:24 -0000 +1 Bertrand=20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Nick = Hilliard Sent: samedi 2 novembre 2013 16:37 To: Russ White; 'Jeffrey Haas'; idr@ietf.org Subject: Re: [Idr] Advancing add-path On 02/11/2013 12:21, Russ White wrote: > How about we move add-paths for iBGP forward, and then we work on a=20 > separate draft for eBGP add paths? ha! But probably this is a better option than confusing the two things. Nick _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From bruno.decraene@orange.com Tue Nov 12 02:21:34 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755A921E8107 for ; Tue, 12 Nov 2013 02:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKPV7qyzIePg for ; Tue, 12 Nov 2013 02:21:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 17F5521E80EB for ; Tue, 12 Nov 2013 02:21:23 -0800 (PST) Received: from opfeda41.si.francetelecom.fr (unknown [10.98.245.92]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 812E02ACC49 for ; Tue, 12 Nov 2013 11:21:20 +0100 (CET) Received: from opfeda41.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id A20DE82383_2820172B for ; Tue, 12 Nov 2013 10:22:42 +0000 (GMT) Received: from omfeda05.si.francetelecom.fr (omfeda05.si.francetelecom.fr [xx.xx.xx.198]) by opfeda41.si.francetelecom.fr (Sophos Email Appliance) with ESMTP id 33A4D7F4F1_2820172F for ; Tue, 12 Nov 2013 10:22:42 +0000 (GMT) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id CBEF51800C2 for ; Tue, 12 Nov 2013 11:21:19 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 11:21:19 +0100 From: To: "idr@ietf.org" Thread-Topic: draft-ietf-idr-error-handling Thread-Index: Ac7fkOzvPpO7593jRnWfrdrII2Rz/w== Date: Tue, 12 Nov 2013 10:21:18 +0000 Message-ID: <9855_1384251679_5282011F_9855_2108_1_53C29892C857584299CBF5D05346208A070A3AE4@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.12.74814 Subject: [Idr] draft-ietf-idr-error-handling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 10:21:34 -0000 Hi, draft-ietf-idr-error-handling =A72 says: " If the "Optional bit" or the "Transitive bit" in the Attribute Flags for an attribute conflicts with the Attribute Type Code, then the error SHOULD be logged, and the conflicting bit in the Attribute Flags MUST be reset to the correct value." IMO, if the "Transitive bit" is found to be 1 (transitive) in the received = UPDATE message while should be 0 (non-transitive) as per the spec then the = attribute MUST be discarded. Indeed if there is such a conflict, it means that previous BGP speakers did= not recognize the attribute and have propagated it because of the Transiti= ve bit (incorrectly set to Transitive).=20 This was not the intended behavior as the Transitive bit should have been c= leared/non-transitive and hence previous BGP speaker not understanding this= attribute should have removed it. This would also match the analysis performed by Eric for the specific case = of the AIGP attribute. (http://tools.ietf.org/agenda/88/slides/slides-88-id= r-2.pdf slides 3 & 4) Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From chris.hall@highwayman.com Wed Nov 13 06:12:03 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979CE21E80E9 for ; Wed, 13 Nov 2013 06:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTKwNMg3tG+U for ; Wed, 13 Nov 2013 06:11:57 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tch.inty.net [91.221.169.50]) by ietfa.amsl.com (Postfix) with ESMTP id 253E021E8082 for ; Wed, 13 Nov 2013 06:11:56 -0800 (PST) Received: from mdfmta009.tch.inty.net (unknown [127.0.0.1]) by mdfmta009.tch.inty.net (Postfix) with ESMTP id 51BB11280A0 for ; Wed, 13 Nov 2013 14:11:55 +0000 (GMT) Received: from mdfmta009.tch.inty.net (unknown [127.0.0.1]) by mdfmta009.tch.inty.net (Postfix) with ESMTP id 2916B12809A for ; Wed, 13 Nov 2013 14:11:55 +0000 (GMT) Received: from hestia.halldom.com (unknown [80.177.246.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tch.inty.net (Postfix) with ESMTP for ; Wed, 13 Nov 2013 14:11:54 +0000 (GMT) Received: from hyperion.halldom.com ([80.177.246.170] helo=HYPERION) by hestia.halldom.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1VgbAg-0005Q9-2s for idr@ietf.org; Wed, 13 Nov 2013 14:11:54 +0000 From: "Chris Hall" To: References: <9855_1384251679_5282011F_9855_2108_1_53C29892C857584299CBF5D05346208A070A3AE4@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <9855_1384251679_5282011F_9855_2108_1_53C29892C857584299CBF5D05346208A070A3AE4@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Wed, 13 Nov 2013 14:11:48 -0000 Organization: Highwayman Message-ID: <003801cee07a$4e1739e0$ea45ada0$@highwayman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGoLE2SZq9j+RbNgStpn3+dYzPSIppvAM/A Content-Language: en-gb X-MDF-HostID: 22 Subject: Re: [Idr] draft-ietf-idr-error-handling X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:12:03 -0000 Bruno Decraene wrote (on Tue 12-Nov-2013 at 10:21 +0000): ... > draft-ietf-idr-error-handling =A72 says: > " If the "Optional bit" or the "Transitive bit" in the Attribute > Flags for an attribute conflicts with the Attribute Type Code, > then the error SHOULD be logged, and the conflicting bit in the > Attribute Flags MUST be reset to the correct value." >=20 > IMO, if the "Transitive bit" is found to be 1 (transitive) in the > received UPDATE message while should be 0 (non-transitive) as per > the spec then the attribute MUST be discarded. >=20 > Indeed if there is such a conflict, it means that previous BGP > speakers did not recognize the attribute and have propagated it > because of the Transitive bit (incorrectly set to Transitive). > This was not the intended behavior as the Transitive bit should > have been cleared/non-transitive and hence previous BGP speaker not > understanding this attribute should have removed it. It could also mean: * the Attribute Type Code is corrupt... ...the fact that the Flags and the Type "conflict" doesn't tell you which is correct -- all it means is that something is wrong. * an earlier Attribute Length is corrupt... ...so the Flags and the Type are both nonsense (but happily the small number of valid Flags values is indicating that something is wrong). IMO: trying to "patch-up" a set of attributes and continue is a primrose path of good intentions most likely to lead to disappointment. Not to mention being a lot of special purpose code to implement some ill-defined heuristic(s), which will probably never be tested outside the lab and which may (or may not) work as expected or as intended in production. Chris From wwwrun@rfc-editor.org Thu Nov 14 01:11:51 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA5221E80CA for ; Thu, 14 Nov 2013 01:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8EVa3H3+wU3 for ; Thu, 14 Nov 2013 01:11:50 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9FADD21E808F for ; Thu, 14 Nov 2013 01:11:50 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DE71475E015; Thu, 14 Nov 2013 01:01:51 -0800 (PST) To: dmm@1-4-5.net, keyupate@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20131114090151.DE71475E015@rfc-editor.org> Date: Thu, 14 Nov 2013 01:01:51 -0800 (PST) Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC4274 (3803) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 09:11:51 -0000 The following errata report has been submitted for RFC4274, "BGP-4 Protocol Analysis". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4274&eid=3803 -------------------------------------- Type: Editorial Reported by: Ramakrishna DTV Section: 2.1 Original Text ------------- BGP enhances the AS_PATH attribute to include sets of autonomous systems as well as lists via the AS_SET attribute. Corrected Text -------------- BGP enhances the AS_PATH attribute to include sets of autonomous systems as well as lists via the AS_SET path segment type. Notes ----- AS_SET is not an attribute. It is a path segment type. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4274 (draft-ietf-idr-bgp-analysis-07) -------------------------------------- Title : BGP-4 Protocol Analysis Publication Date : January 2006 Author(s) : D. Meyer, K. Patel Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From internet-drafts@ietf.org Mon Nov 18 09:25:21 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E9311E8190; Mon, 18 Nov 2013 09:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+RlkxDmJckH; Mon, 18 Nov 2013 09:25:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5716F11E8135; Mon, 18 Nov 2013 09:25:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131118172516.18228.20889.idtracker@ietfa.amsl.com> Date: Mon, 18 Nov 2013 09:25:16 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-custom-decision-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 17:25:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : BGP Custom Decision Process Author(s) : Alvaro Retana Russ White Filename : draft-ietf-idr-custom-decision-04.txt Pages : 8 Date : 2013-11-18 Abstract: The BGP specification defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. This document defines a new Extended Community, called the Cost Community, which may be used in tie breaking during the best path selection process. The end result is a local custom decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-custom-decision There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-custom-decision-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-custom-decision-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Nov 18 22:27:22 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E3F1A1F62; Mon, 18 Nov 2013 22:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqRRC0LbmQQs; Mon, 18 Nov 2013 22:27:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C815C1A1F05; Mon, 18 Nov 2013 22:27:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131119062720.12919.58642.idtracker@ietfa.amsl.com> Date: Mon, 18 Nov 2013 22:27:20 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-04.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 06:27:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : North-Bound Distribution of Link-State and TE Informatio= n using BGP Author(s) : Hannes Gredler Jan Medved Stefano Previdi Adrian Farrel Saikat Ray Filename : draft-ietf-idr-ls-distribution-04.txt Pages : 41 Date : 2013-11-18 Abstract: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-ls-distribution-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Nov 21 07:18:37 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA091ADFE0; Thu, 21 Nov 2013 07:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Gzk6GBbiO10; Thu, 21 Nov 2013 07:18:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0E81ADFD2; Thu, 21 Nov 2013 07:18:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131121151835.12144.4982.idtracker@ietfa.amsl.com> Date: Thu, 21 Nov 2013 07:18:35 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-aigp-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 15:18:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : The Accumulated IGP Metric Attribute for BGP Author(s) : Pradosh Mohapatra Rex Fernando Eric C. Rosen James Uttaro Filename : draft-ietf-idr-aigp-11.txt Pages : 14 Date : 2013-11-21 Abstract: Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-aigp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-aigp-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-aigp-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From erosen@cisco.com Thu Nov 21 07:44:21 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D90C1AE1D6 for ; Thu, 21 Nov 2013 07:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.026 X-Spam-Level: X-Spam-Status: No, score=-15.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ujLiE6odtMn for ; Thu, 21 Nov 2013 07:44:20 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 333A71AE1D4 for ; Thu, 21 Nov 2013 07:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1062; q=dns/txt; s=iport; t=1385048653; x=1386258253; h=from:to:subject:reply-to:date:message-id; bh=KfolWfGZ41JwzD24AfSdObcUmqvNb8wKpORNqr3ABJk=; b=b6V5zbADzAqJejtUjCCj/eICKT3HRos5VWgxgSi3CTShiF4zlt1AaDv9 eJVwsQkN0R8d3ydmHxfagVt8IJCST5tBSOQ5NJailIdxZGhdLwq0KpHfu vVztoS31PJMgEAsvXXSlVKGpByNgUetJa6lAfDD37eH2yKbLkveRrw+5H 4=; X-IronPort-AV: E=Sophos;i="4.93,745,1378857600"; d="scan'208";a="98362001" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 21 Nov 2013 15:44:12 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rALFi6wg005165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Nov 2013 15:44:10 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id rALFi6tp006308; Thu, 21 Nov 2013 10:44:06 -0500 From: Eric Rosen To: idr@ietf.org Date: Thu, 21 Nov 2013 10:44:06 -0500 Message-ID: <6307.1385048646@erosen-linux> Subject: [Idr] draft-ietf-idr-aigp-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 15:44:21 -0000 I have revised this draft per the WG Last Call comments: - Error handling for a malformed AIGP attribute is "discard attribute". - An AIGP attribute with the transitive bit set is regarded to be malformed, and is to be discarded. - Stated explicitly that the AIGP value used in bestpath computations is the value of the first AIGP TLV in the attribute. - The requirement to default "AIGP_SESSION" to "enabled" on IBGP sessions has been demoted from "MUST" to "SHOULD". This reflect the fact that there is some controversy about it, but no real consensus to default it to "disabled". - Stated that the AIGP value is capped at its maximum (unsigned) value, i.e., it should not wrap around due to addition. Also stated that if an AIGP attribute is received and its value is already the maximum, the attribute should be treated as malformed. (It's not really useful if you can't add to it.) I would like to thank those of you who commented during the last call, and would welcome comments on the changes. From thomas.mangin@exa-networks.co.uk Thu Nov 21 07:48:54 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C381ADFFD; Thu, 21 Nov 2013 07:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTVFuk1X53u8; Thu, 21 Nov 2013 07:48:52 -0800 (PST) Received: from out-9.mail.exa.net.uk (out-7.mail.exa.net.uk [82.219.4.135]) by ietfa.amsl.com (Postfix) with ESMTP id E97F21ADFF6; Thu, 21 Nov 2013 07:48:51 -0800 (PST) Received: from smtp-3.mail.exa.net.uk (smtp-1.mail.exa.net.uk [82.219.5.1]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id 5D3DBA01CA; Thu, 21 Nov 2013 15:48:44 +0000 (GMT) Received: from [10.0.1.3] (office.exa-networks.co.uk [82.219.212.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-3.mail.exa.net.uk (ExaSMTPD) with ESMTPS id 2F0D422115D; Thu, 21 Nov 2013 15:48:44 +0000 (GMT) Content-Type: multipart/signed; boundary="Apple-Mail=_CC2A6BAE-2D48-471C-AC97-2938F900834C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Thomas Mangin In-Reply-To: <6307.1385048646@erosen-linux> Date: Thu, 21 Nov 2013 15:48:43 +0000 Message-Id: <71DB2D92-4631-484E-BFBF-5E938D1D746C@exa-networks.co.uk> References: <6307.1385048646@erosen-linux> To: idr-bounces@ietf.org, erosen@cisco.com X-Mailer: Apple Mail (2.1822) X-Virus-Scanned: clamav-milter 0.97.8 at out-2-2.mail.exa.net.uk X-Virus-Status: Clean Cc: "idr@ietf.org wg" Subject: Re: [Idr] draft-ietf-idr-aigp-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 15:48:54 -0000 --Apple-Mail=_CC2A6BAE-2D48-471C-AC97-2938F900834C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Eric, Following your changes, I have no more feedback (at least atm - never = say never :p) on this draft. Good luck with its progression. Thomas On 21 Nov 2013, at 15:44, Eric Rosen wrote: > I have revised this draft per the WG Last Call comments: >=20 > - Error handling for a malformed AIGP attribute is "discard = attribute". >=20 > - An AIGP attribute with the transitive bit set is regarded to be = malformed, > and is to be discarded. >=20 > - Stated explicitly that the AIGP value used in bestpath computations = is the > value of the first AIGP TLV in the attribute. >=20 > - The requirement to default "AIGP_SESSION" to "enabled" on IBGP = sessions > has been demoted from "MUST" to "SHOULD". This reflect the fact that > there is some controversy about it, but no real consensus to default = it to > "disabled". >=20 > - Stated that the AIGP value is capped at its maximum (unsigned) = value, > i.e., it should not wrap around due to addition. >=20 > Also stated that if an AIGP attribute is received and its value is = already > the maximum, the attribute should be treated as malformed. (It's not > really useful if you can't add to it.) >=20 > I would like to thank those of you who commented during the last call, = and > would welcome comments on the changes. >=20 >=20 >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 --Apple-Mail=_CC2A6BAE-2D48-471C-AC97-2938F900834C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKOK1sACgkQA/52wvuLgaGN7QCcDX/4lV76J2JV9K8D40DxgENS W/cAoPEZy3mLO7VZNlNJ6Pe1GDt2Taxi =P2Kv -----END PGP SIGNATURE----- --Apple-Mail=_CC2A6BAE-2D48-471C-AC97-2938F900834C-- From wwwrun@rfc-editor.org Fri Nov 22 01:34:40 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CFF1AC862; Fri, 22 Nov 2013 01:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIzxU19BSKqS; Fri, 22 Nov 2013 01:34:39 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 09B661AC421; Fri, 22 Nov 2013 01:34:39 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5B05A75E019; Fri, 22 Nov 2013 01:24:07 -0800 (PST) To: ramakrishnadtv@infosys.com, yakov@juniper.net, tony.li@tony.li, skh@nexthop.com From: RFC Errata System Message-Id: <20131122092407.5B05A75E019@rfc-editor.org> Date: Fri, 22 Nov 2013 01:24:07 -0800 (PST) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Held for Document Update] RFC4271 (3809) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 09:34:40 -0000 The following errata report has been held for document update for RFC4271, "A Border Gateway Protocol 4 (BGP-4)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3809 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Ramakrishna DTV Date Reported: 2013-11-21 Held by: Stewart Bryant (IESG) Section: 6 Original Text ------------- Before the invalid routes are deleted from the system, it advertises, to its peers, either withdraws for the routes marked as invalid, or the new best routes before the invalid routes are deleted from the system. Corrected Text -------------- Before the invalid routes are deleted from the system, it advertises, to its peers, either withdraws for the routes marked as invalid, or the new best routes. Notes ----- The phrase "Before the invalid routes are deleted from the system" is unnecessarily repeated in the same sentence. -------------------------------------- RFC4271 (draft-ietf-idr-bgp4-26) -------------------------------------- Title : A Border Gateway Protocol 4 (BGP-4) Publication Date : January 2006 Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Nov 22 01:38:30 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8DD1ACCDA; Fri, 22 Nov 2013 01:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cESB1LU9HCA; Fri, 22 Nov 2013 01:38:29 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 85AE71ACAD7; Fri, 22 Nov 2013 01:38:29 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 07D0A75E019; Fri, 22 Nov 2013 01:27:58 -0800 (PST) To: ramakrishnadtv@infosys.com From: RFC Errata System Message-Id: <20131122092758.07D0A75E019@rfc-editor.org> Date: Fri, 22 Nov 2013 01:27:58 -0800 (PST) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Held for Document Update] RFC1774 (3794) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 09:38:30 -0000 The following errata report has been held for document update for RFC1774, "BGP-4 Protocol Analysis". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=1774&eid=3794 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Ramakrishna DTV Date Reported: 2013-11-10 Held by: Stewart Bryant (IESG) Section: 2 Original Text ------------- To allow graceful coexistence with EGP and OSPF, BGP provides support for carrying both EGP and OSPF derived exterior routes BGP also allows to carry statically defined exterior routes or routes derived by other IGP information. Corrected Text -------------- To allow graceful coexistence with EGP and OSPF, BGP provides support for carrying both EGP and OSPF derived exterior routes. BGP also allows to carry statically defined exterior routes or routes derived by other IGP information. Notes ----- This is a run-on sentence, missing ".". -------------------------------------- RFC1774 (no draft string recorded) -------------------------------------- Title : BGP-4 Protocol Analysis Publication Date : March 1995 Author(s) : P. Traina, Ed. Category : INFORMATIONAL Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Nov 22 01:41:18 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41071ACCF9; Fri, 22 Nov 2013 01:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivySSuh6d3BW; Fri, 22 Nov 2013 01:41:17 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8ED1ACAD7; Fri, 22 Nov 2013 01:41:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8D34775E019; Fri, 22 Nov 2013 01:30:45 -0800 (PST) To: ramakrishnadtv@infosys.com, jhaas@nexthop.com, skh@nexthop.com From: RFC Errata System Message-Id: <20131122093045.8D34775E019@rfc-editor.org> Date: Fri, 22 Nov 2013 01:30:45 -0800 (PST) Cc: idr@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Idr] [Errata Held for Document Update] RFC4273 (3782) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 09:41:18 -0000 The following errata report has been held for document update for RFC4273, "Definitions of Managed Objects for BGP-4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4273&eid=3782 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Ramakrishna DTV Date Reported: 2013-11-04 Held by: Stewart Bryant (IESG) Section: 5 Original Text ------------- There are several management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Corrected Text -------------- There are several management objects defined in this MIB that have a MAX-ACCESS clause of read-write. Notes ----- No object in this MIB has MAX-ACCESS clause of "read-create". -------------------------------------- RFC4273 (draft-ietf-idr-bgp4-mib-15) -------------------------------------- Title : Definitions of Managed Objects for BGP-4 Publication Date : January 2006 Author(s) : J. Haas, Ed., S. Hares, Ed. Category : PROPOSED STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From internet-drafts@ietf.org Fri Nov 22 07:46:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E541AE193; Fri, 22 Nov 2013 07:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77oeTWBLZiNk; Fri, 22 Nov 2013 07:46:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE141ADFA3; Fri, 22 Nov 2013 07:46:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131122154631.16557.72636.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 07:46:31 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-aigp-12.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 15:46:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : The Accumulated IGP Metric Attribute for BGP Author(s) : Pradosh Mohapatra Rex Fernando Eric C. Rosen James Uttaro Filename : draft-ietf-idr-aigp-12.txt Pages : 14 Date : 2013-11-22 Abstract: Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-aigp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-aigp-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-aigp-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wwwrun@rfc-editor.org Thu Nov 21 21:56:55 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C361AE2C4 for ; Thu, 21 Nov 2013 21:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5xzXy1maLTg for ; Thu, 21 Nov 2013 21:56:54 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 56F3A1AE2A1 for ; Thu, 21 Nov 2013 21:56:54 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5309C75E018; Thu, 21 Nov 2013 21:46:23 -0800 (PST) To: yakov@juniper.net, tony.li@tony.li, skh@nexthop.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20131122054623.5309C75E018@rfc-editor.org> Date: Thu, 21 Nov 2013 21:46:23 -0800 (PST) X-Mailman-Approved-At: Fri, 22 Nov 2013 08:56:12 -0800 Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] [Editorial Errata Reported] RFC4271 (3809) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 05:56:56 -0000 The following errata report has been submitted for RFC4271, "A Border Gateway Protocol 4 (BGP-4)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3809 -------------------------------------- Type: Editorial Reported by: Ramakrishna DTV Section: 6 Original Text ------------- Before the invalid routes are deleted from the system, it advertises, to its peers, either withdraws for the routes marked as invalid, or the new best routes before the invalid routes are deleted from the system. Corrected Text -------------- Before the invalid routes are deleted from the system, it advertises, to its peers, either withdraws for the routes marked as invalid, or the new best routes. Notes ----- The phrase "Before the invalid routes are deleted from the system" is unnecessarily repeated in the same sentence. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4271 (draft-ietf-idr-bgp4-26) -------------------------------------- Title : A Border Gateway Protocol 4 (BGP-4) Publication Date : January 2006 Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG