From pmohapat@cisco.com Mon Aug 3 13:52:42 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7AC3A6E9D for ; Mon, 3 Aug 2009 13:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XHD0rHj+wUb for ; Mon, 3 Aug 2009 13:52:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 28E273A694E for ; Mon, 3 Aug 2009 13:52:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIPrdkqrR7PD/2dsb2JhbAC7SogpjncFhBg X-IronPort-AV: E=Sophos;i="4.43,316,1246838400"; d="scan'208";a="222810824" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 03 Aug 2009 20:52:38 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n73Kqbjm018441; Mon, 3 Aug 2009 13:52:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n73Kqb20013999; Mon, 3 Aug 2009 20:52:37 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 13:52:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Aug 2009 13:52:34 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EA9E@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] RFC 4360 clarification (BGP Extended Communities Attribute) Thread-Index: AcoRa4ytfM/otezqTW+uSyAe3ViWhQDEI0zQ References: From: "Pradosh Mohapatra (pmohapat)" To: , X-OriginalArrivalTime: 03 Aug 2009 20:52:37.0397 (UTC) FILETIME=[555A6C50:01CA147C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1429; t=1249332757; x=1250196757; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pmohapat@cisco.com; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20 |Subject:=20RE=3A=20[Idr]=20RFC=204360=20clarification=20(B GP=20Extended=20Communities=20Attribute) |Sender:=20; bh=BVIiHULaGtpSMtFFr7a+tCjM5OTY8pzpHSueTIJOpEw=; b=pvwMEHMVudIkF9NMtmwlBFW5RrwVQU3lKTHklYTp75Apb2lAdi76rJ2gkR UEb4I5PfzGdRXUcMwurdeueMtBbIgfit5L7bSiIs5660CW8163unScHcPfZ2 FE4gop6ZqE; Authentication-Results: sj-dkim-3; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Idr] RFC 4360 clarification (BGP Extended Communities Attribute) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 20:52:42 -0000 Hi Bruno, | We have a clarification question regarding RFC 4360. Section "6. | Operations" states that "If a route has a non-transitivity extended | community, then before advertising the route across the Autonomous | System boundary the community SHOULD be removed from the route." |=20 | Is it compliant with the specification to: | -a- set / add, on the outbound policy of an eBGP session, a non | transitive extended community? | -b- expect that the eBGP peer will not remove it to enforce the | non-transitivity? |=20 | It seems to us that this is compliant: | -a- seems to be inlined with the operation of well know communities | defined in RFC 1997 where the advertisement restrictions applies when | BGP receive a route with this community, not when it advertise it. | -b- RFC 4360 does not ask the eBGP to enforce the non-transitivity (and | besides, non-transivity is a SHOULD, not a MUST) |=20 | - Could you please correct or confirm this? | - If your BGP implementation removes a non-transitive community | received | over an eBGP session, could you please tell us? (either privately or on | the mailing list). The implementations I know of will strip out the non-transitive extcomms even if they get attached through the outbound policy before advertising them to EBGP peers. And yes, it would also remove all non-transitive extcomms received over an EBGP session. - Pradosh From dhrao@cisco.com Mon Aug 3 14:01:58 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E943A6E07 for ; Mon, 3 Aug 2009 14:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbeb-aa96Pff for ; Mon, 3 Aug 2009 14:01:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D6FC73A6DF2 for ; Mon, 3 Aug 2009 14:01:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACftdkqrR7PE/2dsb2JhbAC7XIgpjnoFhBg X-IronPort-AV: E=Sophos;i="4.43,316,1246838400"; d="scan'208";a="359564186" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Aug 2009 21:01:58 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n73L1wb2014015; Mon, 3 Aug 2009 14:01:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n73L1wfe023590; Mon, 3 Aug 2009 21:01:58 GMT Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 14:01:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Aug 2009 14:01:57 -0700 Message-ID: <2FEA927D4859134F939C41B656EBB21C090EDD44@xmb-sjc-21e.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EA9E@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] RFC 4360 clarification (BGP Extended CommunitiesAttribute) Thread-Index: AcoRa4ytfM/otezqTW+uSyAe3ViWhQDEI0zQAAA2N7A= References: <04CAD96D4C5A3D48B1919248A8FE0D5409E0EA9E@xmb-sjc-215.amer.cisco.com> From: "Dhananjaya Rao (dhrao)" To: "Pradosh Mohapatra (pmohapat)" , , X-OriginalArrivalTime: 03 Aug 2009 21:01:58.0004 (UTC) FILETIME=[A3804340:01CA147D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2232; t=1249333318; x=1250197318; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dhrao@cisco.com; z=From:=20=22Dhananjaya=20Rao=20(dhrao)=22=20 |Subject:=20RE=3A=20[Idr]=20RFC=204360=20clarification=20(B GP=20Extended=20CommunitiesAttribute) |Sender:=20; bh=hfxzKtQsgE/X5OXuJRwphWYuKyh4U4B4NXnbRZgU/Tg=; b=gsQ+CBue5xfqOijy4lBvE2C/f2ceHJ6+s2Q51VnVem84Hg5TUaWmhJWltM o7OHTrYS/kboxOCdKbsg2K8DsxAJ4TFiO6Aon2JVm4yTj2r2R+jdmhwMDacS JxxsiONgne; Authentication-Results: sj-dkim-4; header.From=dhrao@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Idr] RFC 4360 clarification (BGP Extended CommunitiesAttribute) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 21:01:58 -0000 =20 >-----Original Message----- >From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 >Behalf Of Pradosh Mohapatra (pmohapat) >Sent: Monday, August 03, 2009 1:53 PM >To: bruno.decraene@orange-ftgroup.com; idr@ietf.org >Subject: Re: [Idr] RFC 4360 clarification (BGP Extended=20 >CommunitiesAttribute) > >Hi Bruno, > > >| We have a clarification question regarding RFC 4360. Section "6. >| Operations" states that "If a route has a non-transitivity extended >| community, then before advertising the route across the Autonomous >| System boundary the community SHOULD be removed from the route." >|=20 >| Is it compliant with the specification to: >| -a- set / add, on the outbound policy of an eBGP session, a non >| transitive extended community? >| -b- expect that the eBGP peer will not remove it to enforce the >| non-transitivity? >|=20 >| It seems to us that this is compliant: >| -a- seems to be inlined with the operation of well know communities >| defined in RFC 1997 where the advertisement restrictions applies when >| BGP receive a route with this community, not when it advertise it. >| -b- RFC 4360 does not ask the eBGP to enforce the non-transitivity >(and >| besides, non-transivity is a SHOULD, not a MUST) >|=20 >| - Could you please correct or confirm this? >| - If your BGP implementation removes a non-transitive community >| received >| over an eBGP session, could you please tell us? (either privately or >on >| the mailing list). > > >The implementations I know of will strip out the=20 >non-transitive extcomms >even if they get attached through the outbound policy before=20 >advertising >them to EBGP peers. And yes, it would also remove all non-transitive >extcomms received over an EBGP session. > Although this does seem to be different from the behavior for other non-transitive attributes, for example MED. Any good reason for it to be different ? Seems like this behavior would in fact prevent a non-transitive extended community from being used between 2 ASes. Thanks, -Dhananjaya >- Pradosh >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr > From root@core3.amsl.com Mon Aug 3 15:15:01 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C44FC3A68D2; Mon, 3 Aug 2009 15:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090803221501.C44FC3A68D2@core3.amsl.com> Date: Mon, 3 Aug 2009 15:15:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-add-paths-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 22:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Advertisement of Multiple Paths in BGP Author(s) : D. Walton, et al. Filename : draft-ietf-idr-add-paths-02.txt Pages : 8 Date : 2009-08-03 In this document we propose a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-add-paths-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-add-paths-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-03150509.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Aug 3 16:00:01 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D117B3A6D0C; Mon, 3 Aug 2009 16:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090803230001.D117B3A6D0C@core3.amsl.com> Date: Mon, 3 Aug 2009 16:00:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-bgp-identifier-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 23:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : AS-wide Unique BGP Identifier for BGP-4 Author(s) : E. Chen, J. Yuan Filename : draft-ietf-idr-bgp-identifier-10.txt Pages : 5 Date : 2009-08-03 To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-identifier-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-bgp-identifier-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-03155520.I-D@ietf.org> --NextPart-- From Aleksi.Suhonen@tut.fi Tue Aug 11 02:40:28 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3A83A7041 for ; Tue, 11 Aug 2009 02:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.536 X-Spam-Level: X-Spam-Status: No, score=-1.536 tagged_above=-999 required=5 tests=[AWL=-0.796, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwwLTT5vlJ3p for ; Tue, 11 Aug 2009 02:40:23 -0700 (PDT) Received: from mail-gw1.cc.tut.fi (mail-gw1.cc.tut.fi [130.230.160.15]) by core3.amsl.com (Postfix) with ESMTP id 787F93A706C for ; Tue, 11 Aug 2009 02:39:24 -0700 (PDT) X-AuditID: 82e6a00f-b7b40ae000007078-23-4a813c4f14b8 Received: from mail.cc.tut.fi (mail.cc.tut.fi [130.230.1.120]) by mail-gw1.cc.tut.fi (Symantec Brightmail Gateway) with SMTP id 76.3E.28792.F4C318A4; Tue, 11 Aug 2009 12:39:27 +0300 (EEST) Received: from [130.230.52.50] (rotta.atm.tut.fi [130.230.52.50]) by mail.cc.tut.fi (Postfix) with ESMTP id 24A64A40A8 for ; Tue, 11 Aug 2009 12:39:27 +0300 (EEST) Message-ID: <4A813C4E.8070802@tut.fi> Date: Tue, 11 Aug 2009 12:39:26 +0300 From: Aleksi Suhonen Organization: Tampere University of Technology / Institute of Communications Engineering User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [Idr] BGP Peer Groups X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 09:40:28 -0000 Hi, I was writing an Internet-Draft on another BGP issue and I needed a normative reference for BGP Peer Groups, but couldn't find one. So I wrote one myself, because it felt like a good idea at this time: http://www.axu.tm/2009/draft-axu-bgp-peer-groups.html I'm looking for: * Support for the draft or reasons why it's a silly draft. * Information on any Intellectual Property Rights issues regarding it. * Co-Authors. * White papers I could add as informative references. * Insights from BGP implementors on things I've overlooked. After a bit of input, I'll actually submit the draft at tools.ietf.org, if it still feels like a good idea. -- Aleksi Suhonen From david.freedman@uk.clara.net Tue Aug 11 07:19:50 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C9B3A6FE4 for ; Tue, 11 Aug 2009 07:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIMRfHTgHVAp for ; Tue, 11 Aug 2009 07:19:49 -0700 (PDT) Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [IPv6:2001:a88:0:ffff::6]) by core3.amsl.com (Postfix) with ESMTP id 36EB13A7146 for ; Tue, 11 Aug 2009 07:19:33 -0700 (PDT) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.69) (envelope-from ) id 1MasCL-0006ed-QF; Tue, 11 Aug 2009 15:19:33 +0100 Message-ID: <4A817DF5.3080901@uk.clara.net> Date: Tue, 11 Aug 2009 15:19:33 +0100 From: David Freedman Organization: Claranet LImited User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 Newsgroups: gmane.ietf.idr To: Aleksi Suhonen References: <4A813C4E.8070802@tut.fi> In-Reply-To: <4A813C4E.8070802@tut.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] BGP Peer Groups X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 14:19:50 -0000 If you look at the IOS implementation, peer-groups have been decoupled from "update groups" which are used to group peers to which common updates are sent. As an end user of the implementation you can configure the members of the peer-group but the update-group membership remains internal to the implementation. Since there are many different type of groups one can have (same updates to members, same transport, same timers etc..) would be interested as to which you refer in these notes, if you really do mean "all" then you want to revert the behaviour described above which puts control back to the end user again. David. Aleksi Suhonen wrote: > Hi, > > I was writing an Internet-Draft on another BGP issue and I needed a > normative reference for BGP Peer Groups, but couldn't find one. So I > wrote one myself, because it felt like a good idea at this time: > http://www.axu.tm/2009/draft-axu-bgp-peer-groups.html > > I'm looking for: > > * Support for the draft or reasons why it's a silly draft. > * Information on any Intellectual Property Rights issues regarding it. > * Co-Authors. > * White papers I could add as informative references. > * Insights from BGP implementors on things I've overlooked. > > After a bit of input, I'll actually submit the draft at tools.ietf.org, > if it still feels like a good idea. > From Aleksi.Suhonen@tut.fi Tue Aug 11 21:28:27 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0CD3A6947 for ; Tue, 11 Aug 2009 21:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O55qeeJdO570 for ; Tue, 11 Aug 2009 21:28:26 -0700 (PDT) Received: from mail-gw2.cc.tut.fi (mail-gw2.cc.tut.fi [130.230.160.16]) by core3.amsl.com (Postfix) with ESMTP id E55063A657C for ; Tue, 11 Aug 2009 21:28:25 -0700 (PDT) X-AuditID: 82e6a010-b7b0dae00000634f-0b-4a8240016e11 Received: from mail.cc.tut.fi (mail.cc.tut.fi [130.230.1.120]) by mail-gw2.cc.tut.fi (Symantec Brightmail Gateway) with SMTP id C5.0C.25423.100428A4; Wed, 12 Aug 2009 07:07:29 +0300 (EEST) Received: from [130.230.52.50] (rotta.atm.tut.fi [130.230.52.50]) by mail.cc.tut.fi (Postfix) with ESMTP id 4914BA40F8; Wed, 12 Aug 2009 07:07:29 +0300 (EEST) Message-ID: <4A824001.7000301@tut.fi> Date: Wed, 12 Aug 2009 07:07:29 +0300 From: Aleksi Suhonen Organization: Tampere University of Technology / Department of Communications Engineering User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: idr@ietf.org References: <4A813C4E.8070802@tut.fi> <4A817DF5.3080901@uk.clara.net> In-Reply-To: <4A817DF5.3080901@uk.clara.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: David Freedman Subject: Re: [Idr] BGP Peer Groups X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 04:28:27 -0000 Hello again, I'm generally pleased with the response I've already received to the rough draft on BGP peer groups. Here's a short summary: * Someone from Cisco was interested in extending the draft to cover some important challenges in the implementation of peer groups. * Someone from SixXS.net suggested that maybe it should be a draft on "BGP Dos and Don'ts". * Someone from Sweden pointed out update groups, as did David Freedman below. * Someone from a Central-European ISP said that it's an implementation issue and shouldn't be an Internet-Draft at all. David Freedman wrote: > If you look at the IOS implementation, peer-groups have been decoupled > from "update groups" which are used to group peers to which common > updates are sent. > As an end user of the implementation you can configure the members of > the peer-group but the update-group membership remains internal to the > implementation. Right. > Since there are many different type of groups one can have (same updates > to members, same transport, same timers etc..) would be interested as to > which you refer in these notes, if you really do mean "all" then you > want to revert the behaviour described above which puts control back to > the end user again. I wrote the thing quite quickly. I was rather naive and thought only of my needs for the other draft, which needs configuration level peer groups rather than the more generic update groups. I think at least update groups definitely fall within the scope of the draft. Otherwise it's all still open. One question I forgot to ask yesterday was: Should this be experimental, informational, bcp or proposed standard? From the responses I've received so far, I gather that it should be bcp. A new question for today: can this be adopted as a working group document, ever? -- Aleksi Suhonen From christopher.morrow@gmail.com Wed Aug 12 07:24:25 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B093A6AE0 for ; Wed, 12 Aug 2009 07:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5xUZr0Avwzv for ; Wed, 12 Aug 2009 07:24:25 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 577D53A6886 for ; Wed, 12 Aug 2009 07:24:21 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so15254qwi.31 for ; Wed, 12 Aug 2009 07:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=ERuSYAxzUczv7pYrOKLkvFN+y1ziLwMH8FSXNGFS8+E=; b=SbMSDphA3W9q3e4DKdavpBjNGhLQMbpvZMATJ0hwsYRQUy6XRA3ksrhcwLwlRxGjJS JisTyS5xow28+Cv4euwOXWFjvf07wG+CEaZdWRaUCpDbBCwDzjkoIT8HiobrquJPESsI imhP0MRzDasl9ljsbOdX4uc3YDUdMD4Cmscfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=JuMMlVoGr1g6NlwLjcL3IVTAgoITGl5UJjFM2ioRuPhAluQYQ8NPg/2pzaAj/Qf1/g 3BDtD1F7286Dk0hZEhjh3Y9Ve4FZEG/QeYPI48wnLm57atHLNUbriXdT+UJwJ6ZehQMi YRSGl6VVfIkFm8ESWp6JKXbC9ITLwWdWSDyyU= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.45.194 with SMTP id g2mr118254qaf.309.1250086989533; Wed, 12 Aug 2009 07:23:09 -0700 (PDT) In-Reply-To: <4A824001.7000301@tut.fi> References: <4A813C4E.8070802@tut.fi> <4A817DF5.3080901@uk.clara.net> <4A824001.7000301@tut.fi> Date: Wed, 12 Aug 2009 10:23:09 -0400 X-Google-Sender-Auth: dd36f6fbb1ca382c Message-ID: <75cb24520908120723j19933b33n704f6f31ee44455b@mail.gmail.com> From: Christopher Morrow To: Aleksi Suhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] BGP Peer Groups X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 14:24:26 -0000 On Wed, Aug 12, 2009 at 12:07 AM, Aleksi Suhonen wrote: > Hello again, > > I'm generally pleased with the response I've already received to the rough > draft on BGP peer groups. Here's a short summary: > > * Someone from Cisco was interested in extending the draft to cover some > important challenges in the implementation of peer groups. > * Someone from SixXS.net suggested that maybe it should be a draft on "BGP > Dos and Don'ts". > * Someone from Sweden pointed out update groups, as did David Freedman > below. > * Someone from a Central-European ISP said that it's an implementation issue > and shouldn't be an Internet-Draft at all. I would side with this commentor, that peer-groups alone are just an implementation optimization (and now a useful operations configuration widget). > David Freedman wrote: >> >> If you look at the IOS implementation, peer-groups have been decoupled >> from "update groups" which are used to group peers to which common >> updates are sent. > >> As an end user of the implementation you can configure the members of >> the peer-group but the update-group membership remains internal to the >> implementation. > > Right. > >> Since there are many different type of groups one can have (same updates >> to members, same transport, same timers etc..) would be interested as to >> which you refer in these notes, if you really do mean "all" then you >> want to revert the behaviour described above which puts control back to >> the end user again. > > I wrote the thing quite quickly. I was rather naive and thought only of my > needs for the other draft, which needs configuration level peer groups > rather than the more generic update groups. > > I think at least update groups definitely fall within the scope of the > draft. Otherwise it's all still open. > > One question I forgot to ask yesterday was: > > Should this be experimental, informational, bcp or proposed standard? > From the responses I've received so far, I gather that it should be bcp. > > A new question for today: can this be adopted as a working group document, > ever? My above comment aside, the GROW chairs (and one of our AD's) was interested in some more operations focused bgp 'best practices for configuration' document... Something that at least covered: 1) prefix filtering 2) neighbor safe-guards 3) policy configurations The peer-group business fits into the best practices doc mold... If you wanted to expand some I think we would like to chat about it on the grow mailing list. -chris From Andrew.Lange@alcatel-lucent.com Wed Aug 12 11:22:12 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D275928C0D9 for ; Wed, 12 Aug 2009 11:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTyZvfzLjw80 for ; Wed, 12 Aug 2009 11:22:11 -0700 (PDT) Received: from audl953.usa.alcatel.com (audl953.usa.alcatel.com [143.209.238.162]) by core3.amsl.com (Postfix) with ESMTP id 246C03A6838 for ; Wed, 12 Aug 2009 11:22:09 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id n7CIL7Cb017025; Wed, 12 Aug 2009 13:21:10 -0500 Received: from uscaln-fspeiser.aind.ind.alcatel.com ([172.22.216.4]) by usdalsbhs01.ad3.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 13:21:08 -0500 Message-Id: From: Andrew Lange To: "Christopher Morrow" In-Reply-To: <75cb24520908120723j19933b33n704f6f31ee44455b@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1--936356781 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 Aug 2009 11:21:06 -0700 References: <4A813C4E.8070802@tut.fi> <4A817DF5.3080901@uk.clara.net><4A824001.7000301@tut.fi> <75cb24520908120723j19933b33n704f6f31ee44455b@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Aug 2009 18:21:08.0432 (UTC) FILETIME=[A9A02D00:01CA1B79] X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34 X-Mailman-Approved-At: Wed, 12 Aug 2009 16:06:42 -0700 Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] BGP Peer Groups X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 18:22:12 -0000 --Apple-Mail-1--936356781 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I agree with Chris on this. Peer groups are an implementation optimization. There isn't anything in terms of interoperability that needs to be standardized. However, as part of a BGP configuration best practices in GROW it may be a good addition. Andrew On Aug 12, 2009, at 7:23 AM, Christopher Morrow wrote: > On Wed, Aug 12, 2009 at 12:07 AM, Aleksi > Suhonen wrote: > > Hello again, > > > > I'm generally pleased with the response I've already received to > the rough > > draft on BGP peer groups. Here's a short summary: > > > > * Someone from Cisco was interested in extending the draft to > cover some > > important challenges in the implementation of peer groups. > > * Someone from SixXS.net suggested that maybe it should be a draft > on "BGP > > Dos and Don'ts". > > * Someone from Sweden pointed out update groups, as did David > Freedman > > below. > > * Someone from a Central-European ISP said that it's an > implementation issue > > and shouldn't be an Internet-Draft at all. > > I would side with this commentor, that peer-groups alone are just an > implementation optimization (and now a useful operations configuration > widget). > > > David Freedman wrote: > >> > >> If you look at the IOS implementation, peer-groups have been > decoupled > >> from "update groups" which are used to group peers to which common > >> updates are sent. > > > >> As an end user of the implementation you can configure the > members of > >> the peer-group but the update-group membership remains internal > to the > >> implementation. > > > > Right. > > > >> Since there are many different type of groups one can have (same > updates > >> to members, same transport, same timers etc..) would be > interested as to > >> which you refer in these notes, if you really do mean "all" then > you > >> want to revert the behaviour described above which puts control > back to > >> the end user again. > > > > I wrote the thing quite quickly. I was rather naive and thought > only of my > > needs for the other draft, which needs configuration level peer > groups > > rather than the more generic update groups. > > > > I think at least update groups definitely fall within the scope of > the > > draft. Otherwise it's all still open. > > > > One question I forgot to ask yesterday was: > > > > Should this be experimental, informational, bcp or proposed > standard? > > From the responses I've received so far, I gather that it should > be bcp. > > > > A new question for today: can this be adopted as a working group > document, > > ever? > > My above comment aside, the GROW chairs (and one of our AD's) was > interested in some more operations focused bgp 'best practices for > configuration' document... Something that at least covered: > > 1) prefix filtering > 2) neighbor safe-guards > 3) policy configurations > > The peer-group business fits into the best practices doc mold... If > you wanted to expand some I think we would like to chat about it on > the grow mailing list. > > -chris > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --Apple-Mail-1--936356781 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I agree with Chris on this. =   Peer groups are an implementation optimization.  There isn't = anything in terms of interoperability that needs to be = standardized. 

However, as part of a BGP = configuration best practices in GROW it may be a good = addition.

Andrew

On Aug 12, 2009, at 7:23 AM, Christopher Morrow wrote:

=

On Wed, Aug = 12, 2009 at 12:07 AM, Aleksi Suhonen<Aleksi.Suhonen@tut.fi> = wrote:
> Hello again,
>
> I'm generally pleased = with the response I've already received to the rough
> draft on = BGP peer groups. Here's a short summary:
>
> * Someone = from Cisco was interested in extending the draft to cover some
> = important challenges in the implementation of peer groups.
> * = Someone from SixXS.net suggested that maybe it should be a draft on = "BGP
> Dos and Don'ts".
> * Someone from Sweden pointed = out update groups, as did David Freedman
> below.
> * = Someone from a Central-European ISP said that it's an implementation = issue
> and shouldn't be an Internet-Draft at all.

I = would side with this commentor, that peer-groups alone are just an
= implementation optimization (and now a useful operations = configuration
widget).

> David Freedman wrote:
= >>
>> If you look at the IOS implementation, peer-groups = have been decoupled
>> from "update groups" which are used to = group peers to which common
>> updates are sent.
>
= >> As an end user of the implementation you can configure the = members of
>> the peer-group but the update-group membership = remains internal to the
>> implementation.
>
> = Right.
>
>> Since there are many different type of = groups one can have (same updates
>> to members, same = transport, same timers etc..) would be interested as to
>> = which you refer in these notes, if you really do mean "all" then you
= >> want to revert the behaviour described above which puts control = back to
>> the end user again.
>
> I wrote the = thing quite quickly. I was rather naive and thought only of my
> = needs for the other draft, which needs configuration level peer = groups
> rather than the more generic update groups.
>
= > I think at least update groups definitely fall within the scope of = the
> draft. Otherwise it's all still open.
>
> One = question I forgot to ask yesterday was:
>
> Should this be = experimental, informational, bcp or proposed standard?
> =46rom = the responses I've received so far, I gather that it should be bcp.
= >
> A new question for today: can this be adopted as a working = group document,
> ever?

My above comment aside, the GROW = chairs (and one of our AD's) was
interested in some more operations = focused bgp 'best practices for
configuration' document... Something = that at least covered:

1) prefix filtering
2) neighbor = safe-guards
3) policy configurations

The peer-group = business fits into the best practices doc mold... If
you wanted to = expand some I think we would like to chat about it on
the grow = mailing list.

-chris
= _______________________________________________
Idr mailing list
= Idr@ietf.org
https://www.ietf.org/ma= ilman/listinfo/idr

=

= --Apple-Mail-1--936356781-- From swmike@swm.pp.se Wed Aug 12 20:53:31 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC3B3A68D1 for ; Wed, 12 Aug 2009 20:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHeQSWQ6Rka5 for ; Wed, 12 Aug 2009 20:53:31 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 2C43A3A67B0 for ; Wed, 12 Aug 2009 20:53:30 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4330B9F; Thu, 13 Aug 2009 05:53:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 419A99C; Thu, 13 Aug 2009 05:53:32 +0200 (CEST) Date: Thu, 13 Aug 2009 05:53:32 +0200 (CEST) From: Mikael Abrahamsson To: Christopher Morrow In-Reply-To: <75cb24520908120723j19933b33n704f6f31ee44455b@mail.gmail.com> Message-ID: References: <4A813C4E.8070802@tut.fi> <4A817DF5.3080901@uk.clara.net> <4A824001.7000301@tut.fi> <75cb24520908120723j19933b33n704f6f31ee44455b@mail.gmail.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] BGP Peer Groups X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 03:53:32 -0000 On Wed, 12 Aug 2009, Christopher Morrow wrote: > I would side with this commentor, that peer-groups alone are just an > implementation optimization (and now a useful operations configuration > widget). If the intention is to give router OS manufacturers a hint as what to do (and also greenfield rollouts) then advising them to not implementing peer-groups but instead peer-templates is definitely very good advice. -- Mikael Abrahamsson email: swmike@swm.pp.se From christopher.morrow@gmail.com Wed Aug 12 21:13:37 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23C13A69E9 for ; Wed, 12 Aug 2009 21:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qeog09ylm7yB for ; Wed, 12 Aug 2009 21:13:37 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id D5D833A67AE for ; Wed, 12 Aug 2009 21:13:36 -0700 (PDT) Received: by qyk41 with SMTP id 41so464240qyk.29 for ; Wed, 12 Aug 2009 21:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=iCVhN9iIXQLzUhOSL7XOwmcKBiUeK17l51FTs/2goPQ=; b=B3zfNEbU41LuZlZTgNBf4ne66ZWUFY8qN4/S/SGeVnYvVCCwTkw4LTNHNy88Be2VVl HMk2XpXHRSA++tIP99YeQlBCjPy9CBMti0sRvNbE6V7uwCgTdQGYgt5YZUJcCOxd8kQh P9o6b0mKqkbAlGXzu8KI0XhVJm/OyaxHQyiMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=StHHxePgRgVQhIjmzx/G8szXGca1KVXVDH+nrbxHuXBiVUTV3hxzVKMCBf36e8QlTK VmEx2/j5QQVklewOBLQyheYfhCdb5zMtFiZxtlUnm7bQQPEtzBRdH3FfRt6si4k52cxZ +DPygVxTfomJ9/b74/DMfHvra+VQMjgYw8buM= MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.224.52.138 with SMTP id i10mr856317qag.38.1250136692468; Wed, 12 Aug 2009 21:11:32 -0700 (PDT) In-Reply-To: References: <4A813C4E.8070802@tut.fi> <4A817DF5.3080901@uk.clara.net> <4A824001.7000301@tut.fi> <75cb24520908120723j19933b33n704f6f31ee44455b@mail.gmail.com> Date: Thu, 13 Aug 2009 00:11:32 -0400 X-Google-Sender-Auth: 342a616455e7c96f Message-ID: <75cb24520908122111h12c14789h51ff16209d8937e5@mail.gmail.com> From: Christopher Morrow To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] BGP Peer Groups X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 04:13:37 -0000 On Wed, Aug 12, 2009 at 11:53 PM, Mikael Abrahamsson wrote: > On Wed, 12 Aug 2009, Christopher Morrow wrote: > >> I would side with this commentor, that peer-groups alone are just an >> implementation optimization (and now a useful operations configuration >> widget). > > If the intention is to give router OS manufacturers a hint as what to do > (and also greenfield rollouts) then advising them to not implementing > peer-groups but instead peer-templates is definitely very good advice. for IDR or for somewhere else? (and explain the difference if possible between template/group, please.) From Ilya.Varlashkin@de.easynet.net Thu Aug 13 02:22:20 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0EA63A690B for ; Thu, 13 Aug 2009 02:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjOBNuOql6wg for ; Thu, 13 Aug 2009 02:22:20 -0700 (PDT) Received: from softy.de.easynet.net (softy.de.easynet.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id 387083A6902 for ; Thu, 13 Aug 2009 02:22:19 -0700 (PDT) Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.local.de.easynet.net) by softy.de.easynet.net with esmtp (Exim 4.63) (envelope-from ) id 1MbV9G-0007br-Hk; Thu, 13 Aug 2009 09:54:58 +0200 Received: from ex01kgham.adoffice.local.de.easynet.net ([10.43.3.3]) by paul.adoffice.local.de.easynet.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 09:54:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Aug 2009 09:54:57 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] BGP Peer Groups Thread-Index: AcobyaSwUQMMH95tQ2Gtszcgv935CAAHTiwQ References: <4A813C4E.8070802@tut.fi> <4A817DF5.3080901@uk.clara.net><4A824001.7000301@tut.fi><75cb24520908120723j19933b33n704f6f31ee44455b@mail.gmail.com> From: "Ilya Varlashkin" To: "Mikael Abrahamsson" , "Christopher Morrow" X-OriginalArrivalTime: 13 Aug 2009 07:54:58.0531 (UTC) FILETIME=[5AA1FB30:01CA1BEB] Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] BGP Peer Groups X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 09:22:21 -0000 > -----Urspr=FCngliche Nachricht----- > If the intention is to give router OS manufacturers a hint as=20 > what to do (and also greenfield rollouts) then advising them=20 > to not implementing peer-groups but instead peer-templates is=20 > definitely very good advice. >=20 Despite all the flexibilities of the templates I find them more = cluttering config rather than helping to make it more efficient. = Peer-groups for me are good enough and I wouldn't like them to disappear = as result of a draft proposing templates as BCP. In any case as previous = posters mentioned, either of these is implementation details because it = doesn't require cooperation of remote speaker. And therefore draft on = peer-groups should be in some other WG but not in IDR. /iLya From skh@ndzh.com Thu Aug 13 06:20:47 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EBA13A6962 for ; Thu, 13 Aug 2009 06:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.569 X-Spam-Level: * X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djOJautktdsr for ; Thu, 13 Aug 2009 06:20:45 -0700 (PDT) Received: from hickoryhill-consulting.com (63-208-161-197.digitalrealm.net [63.208.161.197]) by core3.amsl.com (Postfix) with ESMTP id 42F5D3A68B8 for ; Thu, 13 Aug 2009 06:20:45 -0700 (PDT) Received: from fargo (unverified [64.112.195.202]) by hickoryhill-consulting.com (SurgeMail 3.9h) with ESMTP id 560839-1945496 for multiple; Thu, 13 Aug 2009 08:00:35 -0400 Message-ID: From: "Susan Hares" To: Date: Thu, 13 Aug 2009 08:00:35 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01CA1BEC.23A2BCE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Authenticated-User: skh@ndzh.com Cc: shares@ndzh.com, "John G. Scudder" Subject: [Idr] Working Group notes for IETF 75 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 13:20:47 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00D7_01CA1BEC.23A2BCE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please send comments on working group notes to the list. Thanks to Keyur and Robert for taking the notes! Sue Hares=20 John Scudder=20 ----------------------------------------------------------------- Inter-domain Routing (IDR) WG =20 THURSDAY, July 30, 2009 1300-1500 Afternoon Session I Small Stage = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =20 CHAIR(s): Susan Hares John Scudder =20 SCRIBES: Keyur Patel, Robert Raszuk =20 AGENDA =20 o Administrivia 20 minutes Chairs =20 - Note Well - Scribe - Blue Sheets - Thank you Yakov! - Document Status =20 o draft-raszuk-ti-bgp-00.txt 15 minutes Robert Raszuk =20 o draft-ietf-idr-bgp-multisession-04 15 minutes John Scudder =20 o draft-vvds-add-paths-analysis-00.txt 15 minutes Pierre Francois =20 o draft-chen-bgp-ext-opt-param 15 minutes John Scudder =20 o draft-scudder-idr-rt-constrain-lite 15 minutes John Scudder =20 =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 IDR notes =20 1) Robert Raszuk: Multiple Transport Instance BGP: =20 - Create a possibility for SP to divide BGP applications over two different instances =20 * Running Separately (Examples): Internet from applications (l3vpns versus ipv4). =20 * Auto-discovery is another example which can be run independently. =20 * Proposal: =20 - Current Suggested 2 instances. If need arises for more we need further discussion. =20 - Complimentary compared to John's Proposal. =20 - Suggestion to ask for a well known 2nd port. Code for running =20 Both the instances should be the same. Easy for migration. No changes = to BGP protocol other than listening on a separate port. =20 - Max CPU, Max Memory, Different tunable sizing of BGP IO queue, Manual locking to preferred CPU/core, per instance choice of IP Precedence, tunable TCP parameters -- considerations for separating application into a different instance =20 =20 Questions/Comments: =20 Q: (Ilya): Basically the draft proposes a new port? Usage as =20 multiplexing a separate identifier? Wouldn't multisession running over = separate processes would give enough separation? =20 A: It does provide a session separation with no definition on how the implementation will handle the instance separation itself. If there is a WG interest we will define a set of profiles to clearly indicate = what levels of separation given platform/code can handle. To define it =20 here seems justified from the point of view of multivendor = environments. =20 Q:(Chris Morrow): BGP should be multiple process in unix world? Being able to demultiplex using different port? There is no difference in how BGP works with the current proposal? Doesn't seem to have any difference other than a new port. =20 DoS attacks are not fully safe. Though moves control traffic on a separate port. =20 A Yes. Point of this was different applications over different threads. Yes its suggesting to run over a separate port. =20 Q: (Peter Lothberg_: The DOS will result flooding forwarding plane =20 And control plane. Doesn't matter where the packet came from. =20 Q: Shouldn't standardize software implementation. Not a protocol =20 issue. =20 Q: (Unknown person): If need flexibility why have a static port and why = two =20 And not N? A: Two can address most of the issues. We are allowing n but not statically. =20 Q: (Unknown person): have requirements where peers would have shorter Convergence time? Are these the applications you have in mind? Why = static and not dynamic? =20 A: Applications as VPNs versus IPv4. =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 (Agenda interruption -- Ross Callon presented a plaque to Yakov for =20 19 years of service as IDR chair. Applause, etc.) =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 2) Multisession: John Scudder =20 Update: Dynamic Port support. Using redirect. =20 =20 Q: Notification should be used for redirect. =20 A: Doesn't currently do this, though did consider it. I will think about it more for next revision. =20 Q Robert Raszuk: What is your view of doing your proposal using pre-configured port ranges. =20 A: Seems reasonable. =20 Q: (unknown) How about to have the ranges pre-allocated ? =20 A: (John) Perhaps it would be too much waste, TCP well-known port space = is limited. =20 Q: (Peter Lothberg) ... it should be TCP thing not related to BGP. =20 A: Not clear how to do this without protocol involvement. Open to suggestions. =20 Q: (Keyur Patel) .. Notification breaks GR =20 A: Thanks. Will give attention to this in the next revision. =20 Q: (Ilya) TCP can address it itself ... no need to have new ports =20 A: Let's take it off line. =20 Q: (Luca Martini): Good idea to have full dynamic range. LDP has a = feature for =20 10 years. Label space. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 3) Pierre Francois: Analysis of paths selection modes for ADD-PATHS. =20 Measuring load in terms of # of paths. =20 Backup path optimality: YES. =20 Note on terminology -- "RIB charge" is a "false friend" translation from French. "RIB load" would be better. =20 RIB charge: N best is the only one that guarantees bound on RIB =20 change. Others don't guarantee any upper bound on paths you = store. =20 MED Oscillations: All but N-best =20 Control plane complexity: Implementation dependent? =20 TOOL: We have a tool. Send us your network topology and we can do the analysis. Need data from PEs, not just a few core routers. =20 Questions:=20 =20 Ilya: Draft is valuable. Slides are more recent. Please update the draft. =20 Scudder: Interested in Draft.=20 =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 4) John Scudder: Extended Optional Parameters =20 Suggests to extend optional parameters beyond 255 types by reserving 255, changing encoding when more than 255 bytes needed. =20 I propose this as a Working-Group draft. =20 Questions/Comments:=20 =20 Q: (Ilya) Backward compatible. If length is more than 255 the session =20 won't come. Not necessary that would be the case with implementations. = Once the new software is installed is it possible for new implementation =20 to break the old speakers. =20 A: Once you have certain number capabilities, you will have to start triaging once the count goes beyond 255. Draft forbids from sending new encoding unless you have byte count > 255. =20 Q (Alexi): Previous draft suggested to break the capability count by running multiple instances. =20 A: Scudder: Would like to fix under all circumstances. =20 Q: (Sumita) Like to see a better solution for backward compatible =20 routers. =20 Q: Scudder: Old implementations can't deal with this issue. Upgraded implementations won't have this issue. Open to suggestions how to do this even better. =20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D =20 5) John Scudder: RT-Constrain Lite =20 Current 4684 is complex from implementation standpoint. Lite draft suggests a subset simpler to implement, useful for PEs. =20 =20 Question and Answer/Comments:=20 =20 =20 Q: (Robert Raszuk) Violates with RFC 4684 as the default filtering is =20 DENY which is changed to PERMIT. DEFAULT DENY versus DEFAULT PERMIT. =20 A:(Scudder) Technically yes. More interested in practical interoperability. =20 Q: (Robert Raszuk) PE simplification can be done without RT Constrain - = lite. =20 A (Scudder): Sure. =20 ------=_NextPart_000_00D7_01CA1BEC.23A2BCE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please send = comments on=20 working group notes to the list.

 

Thanks to = Keyur and=20 Robert for taking the notes!

 

Sue Hares =

John Scudder =

---------------------------------------------------------------= --

 Inter-domain Routing (IDR) WG

 

 THURSDAY,=20 July 30, 2009

 1300-1500 Afternoon Session = I

 Small Stage

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 CHAIR(s):   Susan Hares = <shares@ghs.com>

          =20  John Scudder = <jgs@juniper.net>

 

 SCRIBES: Keyur Patel, Robert=20 Raszuk

 

 AGENDA

 

 o Administrivia           &n= bsp;           &nb= sp;           &nbs= p;    =20 20 minutes

  =20 Chairs

 

  - Note Well

  - Scribe

  - Blue Sheets

  - Thank you Yakov!

  - Document Status

 

 o = draft-raszuk-ti-bgp-00.txt           &n= bsp;           &nb= sp;    =20 15 minutes

 Robert Raszuk

 

 o = draft-ietf-idr-bgp-multisession-04           &n= bsp;        =20 15 minutes

 John Scudder

 

 o=20 draft-vvds-add-paths-analysis-00.txt           &n= bsp;      =20 15 minutes

 Pierre Francois

 

 o = draft-chen-bgp-ext-opt-param           &n= bsp;           &nb= sp;  =20 15 minutes

 John Scudder

 

 o=20 draft-scudder-idr-rt-constrain-lite           &n= bsp;       =20 15 minutes

 John Scudder

 

 

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 IDR notes

 

 1) Robert Raszuk: Multiple = Transport=20 Instance BGP:

 

 - Create a possibility for SP = to divide=20 BGP applications over two

  =20 different instances

 

   * Running Separately = (Examples): Internet=20 from applications (l3vpns

     versus = ipv4).

 

  =20 * Auto-discovery is another example which can be run=20 independently.

 

   * Proposal:

 

 - Current Suggested 2 = instances. If need=20 arises for more we need

  =20 further discussion.

 

 - Complimentary compared to = John's=20 Proposal.

 

 - Suggestion to ask for a well = known 2nd=20 port.  Code for = running 

  =20 Both the instances should be the same. Easy for migration. No = changes=20 to

  =20 BGP protocol other than listening on a separate port.

 

 - Max CPU, Max Memory, = Different tunable=20 sizing of BGP IO queue, Manual

  =20 locking to preferred CPU/core, per instance choice of IP=20 Precedence,

  =20 tunable TCP parameters -- considerations for separating=20 application

  =20 into a different instance

 

 

 Questions/Comments:

 

 Q: (Ilya): Basically the draft = proposes a=20 new port? Usage as  =

 multiplexing a separate = identifier?=20 Wouldn't multisession running over separate

 processes would give enough=20 separation?

 

 A: It does provide a session = separation=20 with no definition on how the

 implementation will handle the = instance=20 separation itself. If there

 is a WG interest we will define = a set of=20 profiles to clearly indicate what

 levels of separation given = platform/code=20 can handle. To define it =20

 here seems justified from the = point of=20 view of multivendor environments.

 

 Q:(Chris Morrow): BGP should be = multiple=20 process in unix world? Being

 able to demultiplex using = different=20 port?  There is no = difference=20 in

 how BGP works with the current = proposal?=20 Doesn't seem to have any

 difference other than a new=20 port.

 

 DoS attacks are not fully safe. = Though=20 moves control traffic on a

 separate port.

 

 A Yes. Point of this was = different=20 applications over different

 threads. Yes its suggesting to = run over a=20 separate port.

 

 Q: (Peter Lothberg_: The DOS = will result=20 flooding forwarding plane =20

 And control plane. Doesn't = matter where=20 the packet came from.

 

 Q: Shouldn=92t standardize = software=20 implementation. Not a protocol =20

 issue.

 

 Q: (Unknown person): If need = flexibility=20 why have a static port and why two =20

 And not N?

 

 A: Two can address most of the = issues. We=20 are allowing n but not

  =20 statically.

 

 Q: (Unknown person): have = requirements=20 where peers would have shorter

 Convergence time? Are these the = applications you have in mind? Why static and

 not dynamic?

 

 A: Applications as VPNs versus=20 IPv4.

 

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

 

 (Agenda interruption -- Ross = Callon=20 presented a plaque to Yakov for =20

 19 years of service as IDR = chair.  Applause, etc.)

 

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

2)=20 Multisession: John Scudder

 

 Update: Dynamic Port support. = Using=20 redirect.

 

 

 Q: Notification should be used = for=20 redirect.

 

 A: Doesn't currently do this, = though did=20 consider it.  I will=20 think

 about it more for next=20 revision.

 

 Q Robert Raszuk: What is your = view of=20 doing your proposal using

 pre-configured port = ranges.

 

 A: Seems reasonable.

 

 Q: (unknown) How about to have = the ranges=20 pre-allocated ?

 

 A: (John) Perhaps it would be = too much=20 waste, TCP well-known port space is

 limited.

 

 Q: (Peter Lothberg) ... it = should be TCP=20 thing not related to BGP.

 

 A: Not clear how to do this = without=20 protocol involvement.  = Open=20 to

    suggestions.

 

 Q: (Keyur Patel) .. = Notification breaks=20 GR

 

 A: Thanks.  Will give attention to this in = the next=20 revision.

 

 Q: (Ilya) TCP can address it = itself ...=20 no need to have new ports

 

 A: Let's take it off = line.

 

 Q: (Luca Martini): Good idea to = have full=20 dynamic range. LDP has a feature for   

    10 years. Label=20 space.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 

 

3)  = Pierre=20 Francois: Analysis of paths selection modes for ADD-PATHS.

 

 Measuring load in terms of # of = paths.

 

 Backup path optimality:  YES.

 

 Note on terminology -- "RIB = charge" is a=20 "false friend" translation

 from French.  "RIB load" would be = better.

 

 RIB charge: N best is the only = one that=20 guarantees bound on RIB  =

            =20 change. Others don=92t guarantee any upper bound on paths you=20 store.

 

 MED Oscillations: All but=20 N-best

 

 Control plane complexity: = Implementation=20 dependent?

 

 TOOL: We have a tool. Send us = your=20 network topology and we can do the

      =20 analysis.  Need = data from=20 PEs, not just a few core routers.

 

 Questions:

 

 Ilya: Draft is valuable. Slides = are more=20 recent. Please update the

 draft.

 

 Scudder: Interested in Draft. =

 

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

4)=20  John Scudder: Extended = Optional=20 Parameters

 

 Suggests to extend optional = parameters=20 beyond 255 types by reserving

 255, changing encoding when = more than 255=20 bytes needed.

 

 I propose this as a = Working-Group=20 draft.

 

 Questions/Comments:

 

 Q: (Ilya) Backward compatible. = If length=20 is more than 255 the session =20

 won't come. Not necessary that = would be=20 the case with implementations. Once

 the new software is installed = is it=20 possible for new implementation =20

 to break the old = speakers.

 

 A: Once you have certain number = capabilities, you will have to start

 triaging once the count goes = beyond=20 255.  Draft forbids from=20 sending

 new encoding unless you have = byte count=20 > 255.

 

 Q (Alexi): Previous draft = suggested to=20 break the capability count by

 running multiple = instances.

 

 A: Scudder: Would like to fix = under all=20 circumstances.

 

 Q: (Sumita) Like to see a = better solution=20 for backward compatible  =

 routers.

 

 Q: Scudder: Old implementations = can=92t=20 deal with this issue. =20 Upgraded

 implementations won't have this = issue.  Open to = suggestions how to=20 do

 this even better.

 

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 5) John Scudder: RT-Constrain=20 Lite

 

 Current 4684 is complex from=20 implementation standpoint.  = Lite=20 draft

 suggests a subset simpler to = implement,=20 useful for PEs.

 

 

 Question and Answer/Comments: =

 

 

 Q: (Robert Raszuk) Violates = with RFC 4684=20 as the default filtering is =20

 DENY which is changed to = PERMIT. DEFAULT=20 DENY versus DEFAULT PERMIT.

 

 A:(Scudder) Technically = yes.  More interested in = practical

 interoperability.

 

 Q: (Robert Raszuk) PE = simplification can=20 be done without RT Constrain -

 lite.

 

 A (Scudder):  Sure.

 

------=_NextPart_000_00D7_01CA1BEC.23A2BCE0-- From swmike@swm.pp.se Thu Aug 13 19:41:49 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262A33A6955 for ; Thu, 13 Aug 2009 19:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLxX68VHo1f3 for ; Thu, 13 Aug 2009 19:41:47 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id E3C3D3A69BE for ; Thu, 13 Aug 2009 19:41:46 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 86842A1; Fri, 14 Aug 2009 04:41:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 85481A0; Fri, 14 Aug 2009 04:41:48 +0200 (CEST) Date: Fri, 14 Aug 2009 04:41:48 +0200 (CEST) From: Mikael Abrahamsson To: Christopher Morrow In-Reply-To: <75cb24520908122111h12c14789h51ff16209d8937e5@mail.gmail.com> Message-ID: References: <4A813C4E.8070802@tut.fi> <4A817DF5.3080901@uk.clara.net> <4A824001.7000301@tut.fi> <75cb24520908120723j19933b33n704f6f31ee44455b@mail.gmail.com> <75cb24520908122111h12c14789h51ff16209d8937e5@mail.gmail.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: idr@ietf.org, David Freedman Subject: Re: [Idr] BGP Peer Groups X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 02:41:49 -0000 On Thu, 13 Aug 2009, Christopher Morrow wrote: > for IDR or for somewhere else? (and explain the difference if possible > between template/group, please.) Peer template is a more flexible way of doing the same thing peer-groups are used for, but things can be inherited in a much more flexible way. http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/s_bgpct.html -- Mikael Abrahamsson email: swmike@swm.pp.se From enkechen@cisco.com Fri Aug 14 09:51:47 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE7D28C1B0 for ; Fri, 14 Aug 2009 09:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV1cv3Vsl693 for ; Fri, 14 Aug 2009 09:51:47 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0009A3A6D68 for ; Fri, 14 Aug 2009 09:51:46 -0700 (PDT) X-Files: draft-chen-bgp-ext-opt-param-01.txt, Attached Message Part : 253 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN0yhUqrR7PE/2dsb2JhbAC6GIgtkQwFhBk X-IronPort-AV: E=Sophos;i="4.43,381,1246838400"; d="txt'208?scan'208,208";a="228082346" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 14 Aug 2009 16:51:51 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7EGpp0E023069; Fri, 14 Aug 2009 09:51:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7EGppLx021860; Fri, 14 Aug 2009 16:51:51 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 09:51:51 -0700 Received: from [171.71.139.253] ([171.71.139.253]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 09:51:51 -0700 Message-ID: <4A859626.10202@cisco.com> Date: Fri, 14 Aug 2009 09:51:50 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Sue Hares , "John G. Scudder" Content-Type: multipart/mixed; boundary="------------020903090103090409060102" X-OriginalArrivalTime: 14 Aug 2009 16:51:51.0169 (UTC) FILETIME=[85463710:01CA1CFF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2532; t=1250268711; x=1251132711; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20draft-chen-bgp-ext-opt-param-01.txt |Sender:=20; bh=s1m9M+Gks/Z3dvqI+DWflcTkq+a+pxFlGUCl6o4pFO4=; b=m8y0unAfifY4nC2HRe76XlbOfKwLcgJ+b/oJzsWuAspUr0LZmFEjJsqFjM pgCLUh7Mxo4eAKPy8Y6n3T0PGbLqmJPpec2lZue6OpfAX5qVJfBEuhjeHVHl gxvYrskhvL; Authentication-Results: sj-dkim-4; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Inter-Domain Routing List Subject: [Idr] draft-chen-bgp-ext-opt-param-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 16:51:48 -0000 This is a multi-part message in MIME format. --------------020903090103090409060102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Sue and John: I would like to request that draft-chen-bgp-ext-opt-param-01.txt be adopted as an IDR WG document. The draft was presented at the last IETF. Thanks. -- Enke -------- Original Message -------- Subject: I-D Action:draft-chen-bgp-ext-opt-param-01.txt Date: Thu, 25 Jun 2009 09:15:04 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Optional Parameters Length for BGP OPEN Message Author(s) : E. Chen, J. Scudder Filename : draft-chen-bgp-ext-opt-param-01.txt Pages : 5 Date : 2009-06-25 The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP Capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concern about this limitation. In this document we extend the BGP OPEN length field in a backward- compatible manner. The Parameter Length field of individual Optional Parameters is similarly extended. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-ext-opt-param-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------020903090103090409060102 Content-Type: Message/External-body; name="draft-chen-bgp-ext-opt-param-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-chen-bgp-ext-opt-param-01.txt" Content-Type: text/plain Content-ID: <2009-06-25090323.I-D@ietf.org> --------------020903090103090409060102 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ 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 --------------020903090103090409060102-- From rfc-editor@rfc-editor.org Fri Aug 21 16:55:43 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1683A683B; Fri, 21 Aug 2009 16:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.761 X-Spam-Level: X-Spam-Status: No, score=-16.761 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 872Pxg7YAtEr; Fri, 21 Aug 2009 16:55:42 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 44A463A6879; Fri, 21 Aug 2009 16:55:42 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 512E930D789; Fri, 21 Aug 2009 16:55:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090821235533.512E930D789@bosco.isi.edu> Date: Fri, 21 Aug 2009 16:55:33 -0700 (PDT) Cc: idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] RFC 5575 on Dissemination of Flow Specification Rules X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 23:55:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5575 Title: Dissemination of Flow Specification Rules Author: P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, D. McPherson Status: Standards Track Date: August 2009 Mailbox: roque@cisco.com, nsheth@juniper.net, raszuk@cisco.com, bgreene@juniper.net, jmauch@us.ntt.net, danny@arbor.net Pages: 22 Characters: 46473 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idr-flow-spec-09.txt URL: http://www.rfc-editor.org/rfc/rfc5575.txt This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. [STANDARDS TRACK] This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From skh@ndzh.com Sat Aug 22 07:22:15 2009 Return-Path: X-Original-To: idr@core3.amsl.com Delivered-To: idr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562C03A69EE for ; Sat, 22 Aug 2009 07:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.352 X-Spam-Level: ** X-Spam-Status: No, score=2.352 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTE2muvstJOd for ; Sat, 22 Aug 2009 07:22:14 -0700 (PDT) Received: from hickoryhill-consulting.com (63-208-161-197.digitalrealm.net [63.208.161.197]) by core3.amsl.com (Postfix) with ESMTP id 97DE13A68A0 for ; Sat, 22 Aug 2009 07:22:14 -0700 (PDT) Received: from fargo (unverified [64.112.195.202]) by hickoryhill-consulting.com (SurgeMail 3.9h) with ESMTP id 586470-1945496 for multiple; Sat, 22 Aug 2009 10:22:21 -0400 Message-ID: From: "Susan Hares" To: Date: Sat, 22 Aug 2009 10:22:21 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0326_01CA2312.6F1FA9D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Authenticated-User: skh@ndzh.com Cc: shares@ndzh.com Subject: [Idr] draft-asati-idr-bgp-bestpath-selection-criteria-01.txt as working group draft X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 14:22:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0326_01CA2312.6F1FA9D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have rough consensus on creating = draft-asati-idr-bgp-bestpath-selection-criteria-01.txtas a Working Group = draft.Will the authors please submit to the IETF for publishing as: = draft-ietf-idr-bgp-bestpath-selection-criteria-01.txtSue HaresIDR WG = co-chair ------=_NextPart_000_0326_01CA2312.6F1FA9D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
We have rough =
consensus on creating 
draft-asati-idr-bgp-bestpath-selection-criteria-01.txt
as a Working Group draft.
Will the authors please submit to the IETF for publishing as: =

draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt
Sue Hares
IDR WG =
co-chair
 
------=_NextPart_000_0326_01CA2312.6F1FA9D0-- From root@core3.amsl.com Fri Aug 28 12:00:02 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1D26F3A70A2; Fri, 28 Aug 2009 12:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090828190002.1D26F3A70A2@core3.amsl.com> Date: Fri, 28 Aug 2009 12:00:02 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-bgp-bestpath-selection-criteria-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 19:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Bestpath Selection Criteria Author(s) : R. Asati Filename : draft-ietf-idr-bgp-bestpath-selection-criteria-00.txt Pages : 8 Date : 2009-08-28 BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection-criteria-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-bgp-bestpath-selection-criteria-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-28115337.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Aug 28 12:30:01 2009 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A491C3A68A3; Fri, 28 Aug 2009 12:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090828193001.A491C3A68A3@core3.amsl.com> Date: Fri, 28 Aug 2009 12:30:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 19:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Bestpath Selection Criteria Author(s) : R. Asati Filename : draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt Pages : 9 Date : 2009-08-28 BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-bgp-bestpath-selection-criteria-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-28122523.I-D@ietf.org> --NextPart--