From dongjie_dj@huawei.com Wed Apr 1 02:25:23 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 8EB1C3A6C4E for ; Wed, 1 Apr 2009 02:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=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 HOV25Vya+gan for ; Wed, 1 Apr 2009 02:25:18 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B81DF3A6A16 for ; Wed, 1 Apr 2009 02:25:17 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHF00MVE0S6QF@szxga04-in.huawei.com> for idr@ietf.org; Wed, 01 Apr 2009 17:24:06 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHF0035Y0S6SC@szxga04-in.huawei.com> for idr@ietf.org; Wed, 01 Apr 2009 17:24:06 +0800 (CST) Received: from d65110 ([10.111.12.97]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHF000NX0S5YN@szxml04-in.huawei.com> for idr@ietf.org; Wed, 01 Apr 2009 17:24:06 +0800 (CST) Date: Wed, 01 Apr 2009 17:24:05 +0800 From: Dong Jie In-reply-to: <200903311757.n2VHvVM89688@magenta.juniper.net> To: 'Yakov Rekhter' , rex@juniper.net, idr@ietf.org Message-id: <009901c9b2ab$9a911180$610c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmyKrMalJlU2++TQLOQfc+zHxq9vAARCQyg Subject: Re: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc 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, 01 Apr 2009 09:25:23 -0000 Hi, I have some questions about the draft. 1. In section 4, the example of "inconsistency in routing" uses the path selection rules of RFC1771, which has been obsoleted by RFC4271. RFC1771 specified the "internal update process" in section 9.2.1, in which BGP elected the best path from all of the external paths for IBGP peers. IMO, RFC1771 can provide best external path for IBGP peers, and this draft elects the best external path with a different procedure. Is my understanding correct? But RFC4271 doesn't have any corresponding specification about "internal update process". If we use the rules of RFC4271 in this example, R3 would advertise its overall best path (b) to R4, so R4 will receive (c) from R1 and (b) from R3, then R4 would pick (b) (using the IGP cost tie-breaking) and advertise it to AS X. In this scenario, there would be no inconsistency between routing and forwarding. With respect to solving the inconsistency problem, is this draft better than RFC4271? 2. In section 3, it says" In order for the reflector to be able to advertise the best external route into the cluster, it is necessary that client-to-client reflection be disabled, since its advertisement may otherwise contain the best route within the cluster domain. " Does it mean that clients need to be full-meshed when best-external is used? If not, inconsistency between routing and forwarding can happen in some scenarios. Best regards, Jie > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Yakov > Rekhter > Sent: Wednesday, April 01, 2009 1:58 AM > To: idr@ietf.org > Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc > > Folks, > > Please comment on the attached request. The deadline for comments > is April 14, 2009. > > If anyone is aware of the IPR related to the draft, please follow > the procedurs of rfc3979. > > Yakov. > ------- Forwarded Message > > Date: Tue, 31 Mar 2009 10:40:17 -0700 > From: Rex Fernando > To: "'idr@ietf.org'" > Subject: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc > > > The authors would like to request that > draft-marques-idr-best-external-01.txt b e adopted as an IDR WG > document. It was presented in IDR in the Minneapolis IETF. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > ------- End of Forwarded Message > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From david.freedman@uk.clara.net Wed Apr 1 06:27:07 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 343BC28C0D6 for ; Wed, 1 Apr 2009 06:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.457, 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 GikFNpAYxyb2 for ; Wed, 1 Apr 2009 06:27:06 -0700 (PDT) Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [IPv6:2001:a88:0:ffff::6]) by core3.amsl.com (Postfix) with ESMTP id 5E5AB28C0CF for ; Wed, 1 Apr 2009 06:27:06 -0700 (PDT) Received: from localhost ([127.0.0.1] ident=tdcdf1) by synchronicity.convergence.cx with esmtp (Exim 4.69) (envelope-from ) id 1Lp0U8-0001pn-8R for idr@ietf.org; Wed, 01 Apr 2009 14:28:04 +0100 Message-ID: <49D36BE3.3000203@uk.clara.net> Date: Wed, 01 Apr 2009 14:28:03 +0100 From: David Freedman Organization: Claranet LImited User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: idr References: <49C903E0.4070604@raszuk.net> In-Reply-To: <49C903E0.4070604@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Idr] draft-scholl-idr-advisory-00 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, 01 Apr 2009 13:27:07 -0000 So it seems to me , we have a number of differing views here. Scholl recommends we have an unstructured payload, scoped by some general "types" (I think this is in the -01 version, tom?), length will be variable. Nalawade originally recommends we have a structured payload but with the capability to send an undefined string (see draft-nalawade-bgp-inform-02, sec 6.1.1), this string can be of variable length as well Nalawade then recommends that the payload not include the freedom to send an unspecified message (closest I could find was CEASE "5 - Other Configuration Change" , see draft-nalawade-bgp-soft-notify-01 sec 2.3) Since a number of purists on here are not happy with the protocol being "cluttered" by unspecified messages, a "middle of the road" approach sounds like a structured payload with the ability to send an unspecified message (without having to hide the fact), this could then be an implementation decision. An easy way to do this would be to place the ADVISORY payloads into soft-notify "Event Message subcodes" (sec 2.3), they would fit quite nicely here. So I present the two alternatives as either - Choose ADVISORY and don't bother with structured payloads or - Choose SOFT-NOTIFY and ammend it to suit the purposes of ADVISORY Both of these cases would satisfy the operator community I believe (please, somebody correct me if I'm wrong) Do people concur? Dave. From root@core3.amsl.com Wed Apr 1 16:45: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 4BCD53A68CB; Wed, 1 Apr 2009 16:45:00 -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: <20090401234501.4BCD53A68CB@core3.amsl.com> Date: Wed, 1 Apr 2009 16:45:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-flow-spec-07.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: Wed, 01 Apr 2009 23:45: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 : Dissemination of flow specification rules Author(s) : P. Roque Marques, et al. Filename : draft-ietf-idr-flow-spec-07.txt Pages : 23 Date : 2009-04-01 This document defines a new BGP NLRI encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more-specific components of the traffic aggregate defined by an IP destination prefix. Additionally it defines two applications of that encoding format. One that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial of service attacks. And a second application to traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the Border Gateway Protocol (BGP), thereby reusing protocol algorithms, operational experience and administrative processes such as inter-provider peering agreements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-flow-spec-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-01164204.I-D@ietf.org> --NextPart-- From pekkas@netcore.fi Wed Apr 1 22:33:59 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 09DC928C1E4 for ; Wed, 1 Apr 2009 22:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 7qfNqjG-dWCl for ; Wed, 1 Apr 2009 22:33:58 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id B52FF28C161 for ; Wed, 1 Apr 2009 22:33:57 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id n325YsSv027071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Apr 2009 08:34:54 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id n325Ysb9027068 for ; Thu, 2 Apr 2009 08:34:54 +0300 Date: Thu, 2 Apr 2009 08:34:53 +0300 (EEST) From: Pekka Savola To: idr@ietf.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95 at otso.netcore.fi X-Virus-Status: Clean Subject: [Idr] MED in iBGP -> eBGP advertisement 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, 02 Apr 2009 05:33:59 -0000 Hello, There doesn't appear to be any specification whether MED should be propagated from iBGP to eBGP on routes originated within the AS, except that about MED transitivity between ASs [1] (RFC 4271 S 5.1.4). See more about this below. How should the implementation behave in this case? This area of spec seems to be undefined, and the way MED transitivity is specified, it has implementation consequences. Is this a problem? FWIW, at least on Juniper, locally originated iBGP route MEDs are not propagated to eBGP unless you touch the MED explicitly in eBGP policy (e.g. 'metric add 0'). [1] RFC4271 S 5.1.4 says: "The MULTI_EXIT_DISC attribute received from a neighboring AS MUST NOT be propagated to other neighboring ASes." This does not seem to be implementable exactly as narrowly as written. Consider a route 1.0.0.0/8 from AS1. Router A at AS2 with eBGP session to adds MED=100. The route is advertised to router B at AS2. Router B has no way of knowing whether MED attribute was added at AS2 or AS1, and the only alternative for routes originated outside its own AS is to not propagate the metric. For consistency, one could argue that locally origianted routes should also by default propagate the metric but that seems unspecified. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas@netcore.fi Wed Apr 1 23:05: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 964583A6907 for ; Wed, 1 Apr 2009 23:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 S6HaAIYFzs5I for ; Wed, 1 Apr 2009 23:05:36 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 794933A69BB for ; Wed, 1 Apr 2009 23:05:36 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id n3266XXM028009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2009 09:06:33 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id n3266Wfa028006; Thu, 2 Apr 2009 09:06:32 +0300 Date: Thu, 2 Apr 2009 09:06:32 +0300 (EEST) From: Pekka Savola To: Jakob Heitz In-Reply-To: <49D454FF.4010400@redback.com> Message-ID: References: <49D454FF.4010400@redback.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95 at otso.netcore.fi X-Virus-Status: Clean Cc: idr@ietf.org Subject: Re: [Idr] MED in iBGP -> eBGP advertisement 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, 02 Apr 2009 06:05:37 -0000 On Wed, 1 Apr 2009, Jakob Heitz wrote: > Now: The purpose of the MED is for the receiving AS to make > a routing decision based upon it. Therefore, to be useful, the MED > must be a DIFFERENT value at each point you export the route > to the other guy. For the pedants: not the same at every point > all the time. That's right, but one possible way to make it different is to set a different MED towards different iBGP peers and as a result the external MED would be different. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From prvs=33676fffe=jheitz@redback.com Wed Apr 1 23:05:36 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 DD2743A6B92 for ; Wed, 1 Apr 2009 23:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 1hO9Mr-gySks for ; Wed, 1 Apr 2009 23:05:36 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 2D60B3A6907 for ; Wed, 1 Apr 2009 23:05:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,311,1235980800"; d="scan'208";a="654985" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 01 Apr 2009 23:06:37 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 81C4D7F317E; Wed, 1 Apr 2009 23:06:37 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15560-04; Wed, 1 Apr 2009 23:06:37 -0700 (PDT) Received: from [127.0.0.1] (unknown [155.53.112.59]) by prattle.redback.com (Postfix) with ESMTP id 0EC1E7F317D; Wed, 1 Apr 2009 23:06:36 -0700 (PDT) Message-ID: <49D455EC.1000200@redback.com> Date: Wed, 01 Apr 2009 23:06:36 -0700 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Pekka Savola References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] MED in iBGP -> eBGP advertisement 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, 02 Apr 2009 06:07:39 -0000 You have two choices: A) MED is generated at the point where a route enters the AS, That is either where it is originated or where it is received by EBGP. B) MED is generated by each router that exports the route to a neighboring AS: The EBGP exit point. Now: The purpose of the MED is for the receiving AS to make a routing decision based upon it. Therefore, to be useful, the MED must be a DIFFERENT value at each point you export the route to the other guy. For the pedants: not the same at every point all the time. That's only going to happen with choice B. I vote for choice B. From this, it follows that if a router receives a MED on IBGP, that the MED was generated in the neighboring AS. -- Jakob Heitz. Pekka Savola wrote: > Hello, > > There doesn't appear to be any specification whether MED should be > propagated from iBGP to eBGP on routes originated within the AS, except > that about MED transitivity between ASs [1] (RFC 4271 S 5.1.4). See more > about this below. > > How should the implementation behave in this case? > > This area of spec seems to be undefined, and the way MED transitivity is > specified, it has implementation consequences. Is this a problem? > > FWIW, at least on Juniper, locally originated iBGP route MEDs are not > propagated to eBGP unless you touch the MED explicitly in eBGP policy > (e.g. 'metric add 0'). > > [1] RFC4271 S 5.1.4 says: > > "The > MULTI_EXIT_DISC attribute received from a neighboring AS MUST NOT be > propagated to other neighboring ASes." > > This does not seem to be implementable exactly as narrowly as written. > Consider a route 1.0.0.0/8 from AS1. Router A at AS2 with eBGP session > to adds MED=100. The route is advertised to router B at AS2. Router B > has no way of knowing whether MED attribute was added at AS2 or AS1, and > the only alternative for routes originated outside its own AS is to not > propagate the metric. For consistency, one could argue that locally > origianted routes should also by default propagate the metric but that > seems unspecified. > From prvs=33676fffe=jheitz@redback.com Wed Apr 1 23:35:34 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 737BE3A6C31 for ; Wed, 1 Apr 2009 23:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 dy7STdLvGEmm for ; Wed, 1 Apr 2009 23:35:33 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id D2CB13A6CBF for ; Wed, 1 Apr 2009 23:35:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,312,1235980800"; d="scan'208";a="655495" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 01 Apr 2009 23:36:35 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 29819832A84; Wed, 1 Apr 2009 23:36:35 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24832-04; Wed, 1 Apr 2009 23:36:35 -0700 (PDT) Received: from [127.0.0.1] (unknown [155.53.112.59]) by prattle.redback.com (Postfix) with ESMTP id 45F55832A83; Wed, 1 Apr 2009 23:36:33 -0700 (PDT) Message-ID: <49D45CF1.3000102@redback.com> Date: Wed, 01 Apr 2009 23:36:33 -0700 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Pekka Savola References: <49D454FF.4010400@redback.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] MED in iBGP -> eBGP advertisement 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, 02 Apr 2009 06:35:34 -0000 Pekka Savola wrote: > On Wed, 1 Apr 2009, Jakob Heitz wrote: >> Now: The purpose of the MED is for the receiving AS to make >> a routing decision based upon it. Therefore, to be useful, the MED >> must be a DIFFERENT value at each point you export the route >> to the other guy. For the pedants: not the same at every point >> all the time. > > That's right, but one possible way to make it different is to set a > different MED towards different iBGP peers and as a result the external > MED would be different. Then the MED you propagate around your own AS is your own. That means you erased the MED your upstream sent you and you can not make routing decisions based upon it. I guess this is ok if you ignore received MEDs. I can see nothing stopping you from doing it. Seems like a simple knob to add. You would have to make sure every router in your AS is doing it the same way though. -- Jakob Heitz. From danny@tcb.net Thu Apr 2 07:35: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 52D703A6CEF for ; Thu, 2 Apr 2009 07:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.607 X-Spam-Level: X-Spam-Status: No, score=-0.607 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, SARE_SUB_RAND_LETTRS4=0.799] 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 D1VsEXoboonj for ; Thu, 2 Apr 2009 07:35:26 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id A8CAF3A6B32 for ; Thu, 2 Apr 2009 07:35:26 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 58C9E2684EA; Thu, 2 Apr 2009 08:36:28 -0600 (MDT) Received: from jchouinard-sim-102.eng.ellacoya.com (97-122-114-19.hlrn.qwest.net [97.122.114.19]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 02 Apr 2009 08:36:28 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.114.19; client-port=56625; syn-fingerprint=65535:55:1:64:M1408,N,W3,N,N,T,S; data-bytes=0 Message-Id: <0148E047-7901-49A5-B5D0-1A52ADF4FE65@tcb.net> From: Danny McPherson To: Pekka Savola In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 08:36:26 -0600 References: X-Mailer: Apple Mail (2.930.3) Cc: idr@ietf.org Subject: Re: [Idr] MED in iBGP -> eBGP advertisement 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, 02 Apr 2009 14:35:27 -0000 On Apr 1, 2009, at 11:34 PM, Pekka Savola wrote: > > This does not seem to be implementable exactly as narrowly as > written. Consider a route 1.0.0.0/8 from AS1. Router A at AS2 with > eBGP session to adds MED=100. The route is advertised to router B > at AS2. Router B has no way of knowing whether MED attribute was > added at AS2 or AS1, and the only alternative for routes originated > outside its own AS is to not propagate the metric. For consistency, > one could argue that locally origianted routes should also by > default propagate the metric but that seems unspecified. In reality, externally announced prefixes for locally routes are often aggregated and announced from multiple locations in the network. This is the "aggregation breaks MEDs" argument and makes a case that an AS may not want to accept MEDs from an adjacent AS for routes that they originate, but only for routes from downstream ASes. This and other MEDS issues are discussed in more detail in RFC 4451. I would be opposed to deriving MEDs from IGP metrics as a default behavior. -danny From rjs@eng.gxn.net Thu Apr 2 08:09:21 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 6920B3A681D for ; Thu, 2 Apr 2009 08:09:21 -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, NO_RELAYS=-0.001, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bng4UKOtyRuh for ; Thu, 2 Apr 2009 08:09:20 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by core3.amsl.com (Postfix) with ESMTP id 0D3BE28C246 for ; Thu, 2 Apr 2009 08:08:29 -0700 (PDT) Received: from rjs by cappuccino.rob.sh with local (Exim 4.69) (envelope-from ) id 1LpOWY-0005pn-K0; Thu, 02 Apr 2009 16:08:10 +0100 Date: Thu, 2 Apr 2009 16:08:10 +0100 From: Rob Shakir To: David Freedman Message-ID: <20090402150810.GU20021@cappuccino.rob.sh> References: <49C903E0.4070604@raszuk.net> <49D36BE3.3000203@uk.clara.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49D36BE3.3000203@uk.clara.net> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: idr Subject: Re: [Idr] draft-scholl-idr-advisory-00 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, 02 Apr 2009 15:09:21 -0000 On Wed, Apr 01, 2009 at 02:28:03PM +0100, David Freedman wrote: > So I present the two alternatives as either > > - Choose ADVISORY and don't bother with structured payloads > > or > > - Choose SOFT-NOTIFY and ammend it to suit the purposes of ADVISORY > > Both of these cases would satisfy the operator community I believe > (please, somebody correct me if I'm wrong) Dave, Thanks for this summary. I think the major point here, from my point of view is that we need some way to be able to deliver a non-fatal message to our peer, to be able to react to some anomaly, or transmit some further information in-band. I agree that a soft-notify with some advisory-esque enhancements would deliver this, as would Tom's draft. As you say, either is an enhancement to the protocol. I can see both pros and cons of the additional structure that INFORM brings, but this can also be said for the flexibility that ADVISORY would bring. I don't have any strong preference between the two drafts. I think the worst case here is that we end up with neither INFORM nor ADVISORY, and end up with two drafts that would have enhanced the operation of the protocol being rejected. Although there are quite a few operators commenting on this thread -- it's a shame we're not more vocal :-) Kind regards, Rob -- Rob Shakir Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html From pmohapat@cisco.com Thu Apr 2 10:40:19 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 E9B1928C104 for ; Thu, 2 Apr 2009 10:40:19 -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 bldXN5GHE2my for ; Thu, 2 Apr 2009 10:40:19 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 14A1A3A6E17 for ; Thu, 2 Apr 2009 10:40:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,315,1235952000"; d="scan'208";a="70112835" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2009 17:41:20 +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 n32HfKNN007800; Thu, 2 Apr 2009 10:41:20 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n32HfKBw001575; Thu, 2 Apr 2009 17:41:20 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Apr 2009 10:41:10 -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: Thu, 2 Apr 2009 10:41:09 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540902A852@xmb-sjc-215.amer.cisco.com> In-Reply-To: <009901c9b2ab$9a911180$610c6f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc Thread-Index: AcmyKrMalJlU2++TQLOQfc+zHxq9vAARCQygAFJ9LYA= References: <200903311757.n2VHvVM89688@magenta.juniper.net> <009901c9b2ab$9a911180$610c6f0a@china.huawei.com> From: "Pradosh Mohapatra (pmohapat)" To: "Dong Jie" , "Yakov Rekhter" , , X-OriginalArrivalTime: 02 Apr 2009 17:41:10.0732 (UTC) FILETIME=[35F530C0:01C9B3BA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2164; t=1238694080; x=1239558080; c=relaxed/simple; s=sjdkim4002; 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]=20draft-marques-idr-best-external -01.txt=20as=20IDR=20WG=20doc |Sender:=20; bh=Fo/7N5iufQsgiJsonIpeucKVsrJcky9Eh93TODGLeWY=; b=sXTWDKR+MTpgditIEPzMTz/IghW3SjpO5X+F1rFbdA5EyFImCRw9KolOBE YzN48B9qqPCRiCs/PM+jEQ5jHqtUYu42gns3IWN1RObdX83amLsP5Ct3hJfG HtL4chTs6c; Authentication-Results: sj-dkim-4; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc 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, 02 Apr 2009 17:40:20 -0000 Hi Jie, | 1. In section 4, the example of "inconsistency in routing"=20 | uses the path selection rules of RFC1771, which has been=20 | obsoleted by RFC4271. RFC1771 specified the "internal update=20 | process" in section 9.2.1, in which BGP elected the best path=20 | from all of the external paths for IBGP peers. IMO, | RFC1771 can provide best external path for IBGP peers, and=20 | this draft elects the best external path with a different=20 | procedure. Is my understanding correct? That's correct. This draft defines a different procedure based on total ordering of the paths to select and advertise the best external path. | But RFC4271 doesn't have any corresponding specification=20 | about "internal update process". If we use the rules of=20 | RFC4271 in this example, R3 would advertise its overall best=20 | path (b) to R4, so R4 will receive (c) from R1 and (b) from=20 | R3, then R4 would pick (b) (using the IGP cost tie-breaking)=20 | and advertise it to AS X. In this scenario, there would be no=20 | inconsistency between routing and forwarding.=20 Right. With RFC4271 procedure, R3 would _advertise_ and _install_ the overall best path (b). | With respect to solving the inconsistency problem, is this=20 | draft better than RFC4271?=20 We wouldn't consider is as solving inconsistency problem. E.g. 4271 provides consistency between routing and forwarding in this example like you described above. This draft provides a=20 mechanism to select and advertise the best external path in=20 cases where an internal path is chosen as best (& still provide=20 consistency between routing and forwarding). | 2. In section 3, it says" In order for the reflector to be=20 | able to advertise the best external route into the cluster,=20 | it is necessary that client-to-client reflection be disabled,=20 | since its advertisement may otherwise contain the best route=20 | within the cluster domain. "=20 | Does it mean that clients need to be full-meshed when=20 | best-external is used? | If not, inconsistency between routing and forwarding can=20 | happen in some scenarios. Yes. - Pradosh From dongjie_dj@huawei.com Fri Apr 3 01:01: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 F07993A67D8 for ; Fri, 3 Apr 2009 01:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=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 SU74OAZCT6+J for ; Fri, 3 Apr 2009 01:01:31 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1DD273A65A6 for ; Fri, 3 Apr 2009 01:01:30 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHI0026UMBXMV@szxga03-in.huawei.com> for idr@ietf.org; Fri, 03 Apr 2009 16:02:21 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHI00HYDMBX3B@szxga03-in.huawei.com> for idr@ietf.org; Fri, 03 Apr 2009 16:02:21 +0800 (CST) Received: from d65110 ([10.111.12.97]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHI0055NMBWBH@szxml04-in.huawei.com> for idr@ietf.org; Fri, 03 Apr 2009 16:02:21 +0800 (CST) Date: Fri, 03 Apr 2009 16:02:20 +0800 From: Dong Jie In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540902A852@xmb-sjc-215.amer.cisco.com> To: "'Pradosh Mohapatra (pmohapat)'" , 'Yakov Rekhter' , rex@juniper.net, idr@ietf.org Message-id: <014501c9b432$83ce9c50$610c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmyKrMalJlU2++TQLOQfc+zHxq9vAARCQygAFJ9LYAAG89sUA== Subject: Re: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc 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, 03 Apr 2009 08:01:32 -0000 Hi Pradosh, Thanks for your reply, and I support the WG adoption of this draft. Best regards, Jie > -----Original Message----- > From: Pradosh Mohapatra (pmohapat) [mailto:pmohapat@cisco.com] > Sent: Friday, April 03, 2009 1:41 AM > To: Dong Jie; Yakov Rekhter; rex@juniper.net; idr@ietf.org > Subject: RE: [Idr] draft-marques-idr-best-external-01.txt as IDR WG doc > > Hi Jie, > > | 1. In section 4, the example of "inconsistency in routing" > | uses the path selection rules of RFC1771, which has been > | obsoleted by RFC4271. RFC1771 specified the "internal update > | process" in section 9.2.1, in which BGP elected the best path > | from all of the external paths for IBGP peers. IMO, > | RFC1771 can provide best external path for IBGP peers, and > | this draft elects the best external path with a different > | procedure. Is my understanding correct? > > That's correct. This draft defines a different procedure > based on total ordering of the paths to select and advertise > the best external path. > > | But RFC4271 doesn't have any corresponding specification > | about "internal update process". If we use the rules of > | RFC4271 in this example, R3 would advertise its overall best > | path (b) to R4, so R4 will receive (c) from R1 and (b) from > | R3, then R4 would pick (b) (using the IGP cost tie-breaking) > | and advertise it to AS X. In this scenario, there would be no > | inconsistency between routing and forwarding. > > Right. With RFC4271 procedure, R3 would _advertise_ and _install_ > the overall best path (b). > > | With respect to solving the inconsistency problem, is this > | draft better than RFC4271? > > We wouldn't consider is as solving inconsistency problem. E.g. > 4271 provides consistency between routing and forwarding in > this example like you described above. This draft provides a > mechanism to select and advertise the best external path in > cases where an internal path is chosen as best (& still provide > consistency between routing and forwarding). > > | 2. In section 3, it says" In order for the reflector to be > | able to advertise the best external route into the cluster, > | it is necessary that client-to-client reflection be disabled, > | since its advertisement may otherwise contain the best route > | within the cluster domain. " > | Does it mean that clients need to be full-meshed when > | best-external is used? > | If not, inconsistency between routing and forwarding can > | happen in some scenarios. > > Yes. > > - Pradosh From jgs@juniper.net Fri Apr 3 12:26:41 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 AFC7D3A6862 for ; Fri, 3 Apr 2009 12:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 3T77nimOdHMb for ; Fri, 3 Apr 2009 12:26:40 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id ADA783A67FF for ; Fri, 3 Apr 2009 12:26:40 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSdZjL2yCPmYmtbk6rjxGez+t9ek7IVSs@postini.com; Fri, 03 Apr 2009 12:27:43 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 3 Apr 2009 12:24:04 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 12:24:04 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 12:24:04 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Apr 2009 12:24:04 -0700 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n33JO3M57175 for ; Fri, 3 Apr 2009 12:24:03 -0700 (PDT) (envelope-from jgs@juniper.net) Message-ID: <232F2BF0-3EFE-4300-8818-EC5F92D4CE45@juniper.net> From: "John G. Scudder" To: idr List Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 15:24:03 -0400 References: <467AE53E.3060001@merit.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 03 Apr 2009 19:24:04.0098 (UTC) FILETIME=[BFFBD620:01C9B491] Subject: [Idr] Fwd: old IDR archives? 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, 03 Apr 2009 19:26:41 -0000 Folks, AFAIK the pre-2003 IDR archives are still MIA. Here's info about where to find a copy, courtesy of Larry Blunk. FYI, --John Begin forwarded message: > From: "Larry J. Blunk" > Date: June 21, 2007 4:53:18 PM GMT-04:00 > To: "John G. Scudder" > Cc: skh@nexthop.com, Yakov Rekhter > Subject: Re: old IDR archives? > > > We have IDR archives from December, 1995 - January, 2006. > I put up a tar file of the archives at > http://www.merit.edu/networkresearch/idr-list-archives.tar > > -Larry From robert@raszuk.net Sat Apr 4 09:02: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 B9BAE3A68C1 for ; Sat, 4 Apr 2009 09:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 f2UmQRRmSWso for ; Sat, 4 Apr 2009 09:02:11 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id AE3A43A6A3F for ; Sat, 4 Apr 2009 09:02:11 -0700 (PDT) Received: (qmail 21720 invoked by uid 399); 4 Apr 2009 16:03:14 -0000 Received: from unknown (HELO ?192.168.1.55?) (83.24.23.34) by mail37.opentransfer.com with SMTP; 4 Apr 2009 16:03:14 -0000 Message-ID: <49D784BE.3050805@raszuk.net> Date: Sat, 04 Apr 2009 09:03:10 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: idr References: <49C903E0.4070604@raszuk.net> <49D36BE3.3000203@uk.clara.net> <20090402150810.GU20021@cappuccino.rob.sh> In-Reply-To: <20090402150810.GU20021@cappuccino.rob.sh> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] SUMMARY Re: draft-scholl-idr-advisory-00 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 16:02:12 -0000 All, So to change this thread into something which may perhaps result in a solution I have tried below to summarize so far received requirements from providers as well as so far proposed alternatives. Please correct/add as appropriate. I have also tried in a neutral way to express the current state of conclusion ... ** 1. Is the additional channel of communication to be used as a reactive or a proactive tool ? A -> I think there is clear consensus between all of us that it may work well as a reactive tool for getting more information about events which have happened. Example: ISP A before controlled session drop or reset injects some free form text informing about it which in turn on the other side of EBGP session would be displayed at show command. B -> I think there is a lot of hesitation on how this tool may be used pro-actively. At least most of my own comments were from coming from this aspect of discussed functionality. The issue is that if those messages need to be promptly seen by NOC of given ISP they better get there by filtered syslog notifications. Is BGP the write tool to be used as a carrier for syslog messages ? ** 2. What is the appropriate size of the free form text msg ? Or to put the question the other way what would be sufficient minimum size of the message to still serve the purpose ? Or should the max length be at all hardcoded ? -> I don't think there was any consensus reached on this so far. ** 3. What example of messages should be targeted to be send: -> notifications about planned router/session outages -> reached threasholds of max-prefix -> route dampening notifications -> policy failing/uRPF hint that you are a DoS src -> ... ** 4. How do we plan to accomplish selective reception of such messages ? -> Do we need new BGP inbound policy paragraphs entries mixed with BGP routing policy entries ? ==== Proposed alternatives: Group of solutions to send more verbal but predefined messages: --------------------------------------------------------------- * Use INFORM spec instead with all potential warnings listed. http://tools.ietf.org/html/draft-nalawade-bgp-inform-02 * Use BGP SOFT-NOTIFY http://tools.ietf.org/html/draft-nalawade-bgp-soft-notify-01 Group of solutions to send free form text in band: -------------------------------------------------- * Use one of the INFORM messages as fee for text (functionally would be the the same as new BGP message) * Maybe the right way to approach this is to add soft notifications, define a slew of message types that make sense for all the normal conditions that can be thought of, and just add a message type for free-form text as well. Group of solutions to send free form text out of band: ------------------------------------------------------ * Provide ability to auto-negotiate by new bgp capability the current and valid email dst for NOC/ADMIN etc ... Those could be used to automatically generate warnings from the routers or from the humans which would end up simultaneously on peer's syslogs, NOC screens or admin cell phones etc ... * Use syslog to syslog communication channel between providers. * Use the same as defined in the draft new BGP ADVISORY msg, use BGP-light (tcp session and single message) to carry it between routers, auto feed it to peer's syslog, but make sure it is carried over independent BGP sessions including using different tcp port number as compared with routing information. Perhaps as such it could go beyond just one router ... Cheers, R. From roque@juniper.net Mon Apr 6 10:59:52 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 3D8AA3A6C52 for ; Mon, 6 Apr 2009 10:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=0.766, 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 qw72XjW5V8+H for ; Mon, 6 Apr 2009 10:59:45 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id 39AFA28C133 for ; Mon, 6 Apr 2009 10:59:45 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob59.postini.com ([64.18.6.12]) with SMTP ID DSNKSdpDUuvKWxMoOSWggI8ZTW4P6YwiedM7@postini.com; Mon, 06 Apr 2009 11:00:51 PDT Received: from tzou-t61.jnpr.net (172.24.104.109) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.1.340.0; Mon, 6 Apr 2009 10:58:13 -0700 Message-ID: <29E7D5C3-CC55-49A3-82DE-2D0EA340DA0D@juniper.net> From: Pedro Marques To: Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 10:58:13 -0700 X-Mailer: Apple Mail (2.930.3) Subject: [Idr] flow-spec rule ordering 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, 06 Apr 2009 17:59:52 -0000 The more recent draft (07) has a change in the rule ordering text. Given that the document has passed last call the chairs and IESG believe that there should be last call on this specific change. Before The previous text implied that on when applying filters, least specific destination IP addresses in destination and source prefix would have priority. The most recent document: - More specific IP destination/source prefixes have priority. e.g. If the following rules are present rule 1 destination prefix 10.0.1/24 rule 2 destination prefix 10.0.1.1/32 rule 3 destination prefix 10.0.1/24 source prefix 20.0/16 rule 4 destination prefix 10.0.1/24 source prefix 20.0.1/24 With the previous text the order of rules would be: [1, 2, 3, 4] With the 07 text the order is: [2, 4, 3, 1] Please look at the complete text in the document and raise any concerns that you may have. thanks, Pedro. From yakov@juniper.net Mon Apr 6 11:06:44 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 60B843A698B for ; Mon, 6 Apr 2009 11:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 d5EnwJtE+wlJ for ; Mon, 6 Apr 2009 11:06:39 -0700 (PDT) Received: from chip3mo2-old.postini.com (chip3mo2-old.postini.com [64.18.14.205]) by core3.amsl.com (Postfix) with ESMTP id DD2DF3A67FC for ; Mon, 6 Apr 2009 11:06:38 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob64.postini.com ([64.18.6.12]) with SMTP ID DSNKSdpE8IfMk1JqexGkbXovc3Eu5W7YRlWZ@postini.com; Mon, 06 Apr 2009 11:07:45 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 6 Apr 2009 11:05:15 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 11:05:15 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 11:05:15 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 11:05:15 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n36I5FM43711 for ; Mon, 6 Apr 2009 11:05:15 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200904061805.n36I5FM43711@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17386.1239041115.1@juniper.net> Date: Mon, 6 Apr 2009 11:05:15 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 06 Apr 2009 18:05:15.0265 (UTC) FILETIME=[3C9E6F10:01C9B6E2] Subject: [Idr] flow-spec rule ordering 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, 06 Apr 2009 18:06:44 -0000 Folks, This is to start the IDR WG Last Call on the changes made to the flowspec draft (07 version), as described below. Note that the scope of this Last Call is limited to just these changes, and *nothing else*. This Last Call ends April 20, 2009. Yakov. ------- Forwarded Message Date: Mon, 06 Apr 2009 10:58:13 -0700 From: Pedro Marques To: Subject: [Idr] flow-spec rule ordering The more recent draft (07) has a change in the rule ordering text. Given that the document has passed last call the chairs and IESG believe that there should be last call on this specific change. Before The previous text implied that on when applying filters, least specific destination IP addresses in destination and source prefix would have priority. The most recent document: - - More specific IP destination/source prefixes have priority. e.g. If the following rules are present rule 1 destination prefix 10.0.1/24 rule 2 destination prefix 10.0.1.1/32 rule 3 destination prefix 10.0.1/24 source prefix 20.0/16 rule 4 destination prefix 10.0.1/24 source prefix 20.0.1/24 With the previous text the order of rules would be: [1, 2, 3, 4] With the 07 text the order is: [2, 4, 3, 1] Please look at the complete text in the document and raise any concerns that you may have. thanks, Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message From tony.li@tony.li Mon Apr 6 20:11:34 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 9E30F3A6CCC for ; Mon, 6 Apr 2009 20:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, 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 9ptNwZketOLM for ; Mon, 6 Apr 2009 20:11:34 -0700 (PDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id D629F3A6A7F for ; Mon, 6 Apr 2009 20:11:33 -0700 (PDT) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id cM1j1b0050x6nqcAETCh16; Tue, 07 Apr 2009 03:12:41 +0000 Received: from [127.0.0.1] ([24.6.155.154]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id cTCf1b00D3L8a8Q8YTCghc; Tue, 07 Apr 2009 03:12:40 +0000 Message-ID: <49DAC491.6050101@tony.li> Date: Mon, 06 Apr 2009 20:12:17 -0700 From: Tony Li User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Yakov Rekhter References: <200904061805.n36I5FM43711@magenta.juniper.net> In-Reply-To: <200904061805.n36I5FM43711@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] flow-spec rule ordering 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, 07 Apr 2009 03:11:34 -0000 Yakov Rekhter wrote: > Folks, > > This is to start the IDR WG Last Call on the changes made > to the flowspec draft (07 version), as described below. > > Note that the scope of this Last Call is limited to just > these changes, and *nothing else*. > > This Last Call ends April 20, 2009. This change seems fine to me. The new rules seem unambiguous and are explained quite clearly. Tony From knoll@etit.tu-chemnitz.de Tue Apr 7 09:43: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 01F673A6A58 for ; Tue, 7 Apr 2009 09:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 Nja6z8a5T-mc for ; Tue, 7 Apr 2009 09:43:26 -0700 (PDT) Received: from jack.hrz.tu-chemnitz.de (jack.hrz.tu-chemnitz.de [134.109.132.46]) by core3.amsl.com (Postfix) with ESMTP id D6A273A63EB for ; Tue, 7 Apr 2009 09:43:25 -0700 (PDT) Received: from galba.hrz.tu-chemnitz.de ([134.109.133.156] helo=mailbox.hrz.tu-chemnitz.de) by jack.hrz.tu-chemnitz.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LrEPW-00031j-2x for idr@ietf.org; Tue, 07 Apr 2009 18:44:30 +0200 Received: from tor.hrz.tu-chemnitz.de ([134.109.133.13]) by mailbox.hrz.tu-chemnitz.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LrEPW-0004Ao-2i for idr@ietf.org; Tue, 07 Apr 2009 18:44:30 +0200 Received: from tor.hrz.tu-chemnitz.de (localhost.localdomain [127.0.0.1]) by tor.hrz.tu-chemnitz.de (8.13.8/8.12.10) with ESMTP id n37GiTRr024055 for ; Tue, 7 Apr 2009 18:44:29 +0200 Received: from localhost (tkn@localhost) by tor.hrz.tu-chemnitz.de (8.13.8/8.12.10/Submit) with ESMTP id n37GiTVV024052 for ; Tue, 7 Apr 2009 18:44:29 +0200 X-Authentication-Warning: tor.hrz.tu-chemnitz.de: tkn owned process doing -bs Date: Tue, 7 Apr 2009 18:44:29 +0200 (MEST) From: "Thomas M. Knoll" X-X-Sender: tkn@tor.hrz.tu-chemnitz.de To: idr@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scan-Signature: e732f858814c7a815fb214039343b7c0 Subject: Re: [Idr] partial bit for ext. communities? -> update 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, 07 Apr 2009 16:43:27 -0000 One suggested solution to overcome the missing partial marking for single extended communities within a bunch of ext. communities was to send each ext. community separate in extended community attributes in order to use the partial bit of the attribute for the marking. This procedure would either result in an UPDATE message containing just one of the bunch of ext. communities in each message, which in turn would lead to overriding the first with the second in the following UPDATE message. Hence, "one per UPDATE" is no solution. Secondly, the single ext. community per ext. com. attribute would lead to several instances of ext. com. attributes for the bunch of ext. communities within a single UPDATE message. This sounds sensible in the first run and avoids the override. However, such behaviour leads to a BGP session tear down due to the "Malformed Attribute List" notification. This is RFC conform behaviour since RFC 4271 states in 6.3: "If any attribute appears more than once in the UPDATE message, then the Error Subcode MUST be set to Malformed Attribute List." (I assume, that "any attribute appears more than once" relates to identical type numbers rather than fully binary identical attributes.) Hence, multiple ext. communities MUST be sent bundled within one extended community attribute. If I am not mistaken, this inevitably leads to the situation, where those transitive attributes are always relayed as beeing completely processed although the contained communities might or might not have been processed/understood. A selective partial marking outside of ext. communities is not available and adding a fixed partial bit inside the ext. communities is arguably unattractive. Please let me know, if I have missed or misunderstood a point here. Thomas. On Wed, 25 Mar 2009, Thomas M. Knoll wrote: > Folks, > > within my presentation yesterday, I mentioned my observation about "unknown" > extended communities, which are relayed in BGP nodes without being marked as > partially processed. > see slide 13 in > http://www3.ietf.org/proceedings/09mar/slides/idr-5.pdf > > I was sending 4 of my new ext. communities (of regular type), which got > bundled into an extended community attribute and transferred to an commercial > router. This in turn relayed the attribute with the partial bit being > cleared. > > This router behaviour is arguably OK, since it did understand the extended > community attribute of type 16 and obviously did not care about the contained > bunch of not yet known ext. communities (of regular type 0x04). > > By means of this email, I would like to hear your opinion, whether you are > contended with such behaviour OR whether a partial bit in each extended > community would make the processing status of individual ext. communities > clearer. > > As far as I am aware of, there are no other extended communities of regular > type around (besides my own ones - 0x04, 0x44, 0x40), which would give the > chance to have a flags field next to the ext. community type, which could > host the proposed ext. community specific partial bit. > > Thomas. > From samitac@ipinfusion.com Wed Apr 8 10:09: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 9892B28C17D for ; Wed, 8 Apr 2009 10:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Nm8J-Z-TPNhr for ; Wed, 8 Apr 2009 10:09:46 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id DA95F28C167 for ; Wed, 8 Apr 2009 10:09:46 -0700 (PDT) Received: (qmail 49931 invoked from network); 8 Apr 2009 17:10:54 -0000 Received: from unknown (HELO samitacD630) (samitac@65.223.109.250 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 8 Apr 2009 17:10:54 -0000 X-YMail-OSG: BRfmeAgVM1l6R2_YfIJCh8o9PsOd3FkITShcWDzYwzyjnisR6bar7_shNQuY1kbTzrKxM4p7p3PeLYeqF_iksh2X.py4OtjXVVs2tg_YlTvdYXRxTBUUv4i9XBvwHUnMAPBbzZ_Xvf3TkXZhjXOX8B5S2G0zf1jywLL.QeygL4VzWuAIP4fz1sQnGiD_fhODNbenzNT5cuZJRWnWzFhZPRzVL6JNlPa.CUiEotjKFaZwmkPjQIzY0SaiBHfz7swfl9aO4vjDFIwcksZYBBduHy1RUBsyg9JDbCVoFrxPuHpWSHHr X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Jeffrey Haas'" , References: <20090222043001.40A7C3A6829@core3.amsl.com> <20090223152829.GB9207@slice> In-Reply-To: <20090223152829.GB9207@slice> Date: Wed, 8 Apr 2009 10:10:51 -0700 Message-ID: <00d801c9b86c$f8901260$e9b03720$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmVyzlbsXHktaIsS5COLA1YvixzHQioSoHA Content-Language: en-us Subject: Re: [Idr] BGP TC MIB 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, 08 Apr 2009 17:09:47 -0000 Hi Jeff, > > On Sat, Feb 21, 2009 at 08:30:01PM -0800, Internet-Drafts@ietf.org wrote: > > Title : Definitions of Textual Conventions for the > Management of the Fourth Version of Border Gateway Protocol (BGP-4) > > This MIB defines the textual conventions meant to be generic to BGP related > MIBs. At this point, it has textual conventions specifically for RFC 4760 > style AFI and SAFI. The only enumerations in this currently are for > ipv4/ipv6:unicast,multicast and mpls. These are the afi/safi sets likely to > occur in the BGPv2 MIB. > > Given that these are meant to be general purpose textual conventions, I'd > like to request feedback from BGP protocol implementors that use other > AFI/SAFI entries: What else should be added here? > [SC>] Hope, it is not too late to comment on this now. Another entry I can think of is 'bgp-mpls-vpn' [ SAFI=128 ] used for both VPNv4 [ AFI=IPV4] and VPNv6 [ AFI=IPv6]. Thanks, -Samita From dongjie_dj@huawei.com Wed Apr 8 21:14:26 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 82A7E3A68B1 for ; Wed, 8 Apr 2009 21:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=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 gUCbuzBeAZra for ; Wed, 8 Apr 2009 21:14:25 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7AD4A3A68D0 for ; Wed, 8 Apr 2009 21:14:25 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHT00FI9FK16J@szxga04-in.huawei.com> for idr@ietf.org; Thu, 09 Apr 2009 12:09:37 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHT007PDFK17G@szxga04-in.huawei.com> for idr@ietf.org; Thu, 09 Apr 2009 12:09:37 +0800 (CST) Received: from d65110 ([10.111.12.97]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHT00GM8FK1IO@szxml06-in.huawei.com> for idr@ietf.org; Thu, 09 Apr 2009 12:09:37 +0800 (CST) Date: Thu, 09 Apr 2009 12:09:37 +0800 From: Dong Jie In-reply-to: <5C5A67FB-FA71-44D9-8772-EE46F543A571@juniper.net> To: "'John G. Scudder'" Message-id: <004201c9b8c8$ff727170$610c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcmcIH3Jet5xHH+JQzGz85shWwoI4Qcp07nQ Cc: 'idr List' Subject: [Idr] Questions on draft-scudder-idr-optional-transitive-01 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, 09 Apr 2009 04:14:26 -0000 This draft said that optional transitive attributes with Partial bit set "have been propagated without being checked by intermediate routers that do not recognize the attribute", so if error-handling rules of RFC4271 is used, the session that is reset is not associated with the router that is at fault. But the rules of setting Partial bit are complex and sometimes may not meet the condition the draft based on. Section 5 of RFC4271 specifies the rules of Partial bit in optional transitive attributes: -"If a path with an unrecognized transitive optional attribute is accepted and passed to other BGP peers, then the unrecognized transitive optional attribute of that path MUST be passed, along with the path, to other BGP peers with the Partial bit in the Attribute Flags octet set to 1. If a path with a recognized, transitive optional attribute is accepted and passed along to other BGP peers and the Partial bit in the Attribute Flags octet is set to 1 by some previous AS, it MUST NOT be set back to 0 by the current AS." -"New, transitive optional attributes MAY be attached to the path by the originator or by any other BGP speaker in the path. If they are not attached by the originator, the Partial bit in the Attribute Flags octet is set to 1." Based on these rules, receiving optional transitive attributes with partial bit set does not mean the peering BGP speaker cannot recognize the attributes and does not check them, because Partial bit can be set by some previous BGP speakers, and it MUST NOT be set back to 0. In some cases, Partial bit is set by some previous BGP speaker, but the fault is done by the peering BGP speaker, then the procedures of RFC4271 SHOULD be followed. In some other cases, Partial bit is set because the attribute is attached by some intermediate BGP speaker, and all of the BGP speakers along the path can recognize it. Then the procedures of RFC4271 SHOULD also be followed. IMO, Partial bit of optional transitive attribute is not fit for identifying whether the fault is done by the peering BGP speaker. It only indicates that the optional transitive attribute is *not recognized* or *not seen* by all the BGP speakers in the path. Best regards, Jie From jgs@juniper.net Thu Apr 9 08:13:54 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 F1D863A6C72 for ; Thu, 9 Apr 2009 08:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 lgkMvsQxfiZN for ; Thu, 9 Apr 2009 08:13:54 -0700 (PDT) Received: from chip3og62.obsmtp.com (chip3og62.obsmtp.com [64.18.14.201]) by core3.amsl.com (Postfix) with ESMTP id BBF9B3A6C73 for ; Thu, 9 Apr 2009 08:13:53 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob62.postini.com ([64.18.6.12]) with SMTP ID DSNKSd4Q7xm4eDkPR75vAgMw1gidS7CyxNi6@postini.com; Thu, 09 Apr 2009 08:15:02 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 9 Apr 2009 08:11:56 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Apr 2009 08:11:56 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Apr 2009 08:11:55 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 08:11:55 -0700 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n39FBpM26977; Thu, 9 Apr 2009 08:11:51 -0700 (PDT) (envelope-from jgs@juniper.net) Message-ID: From: "John G. Scudder" To: Dong Jie In-Reply-To: <004201c9b8c8$ff727170$610c6f0a@china.huawei.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 9 Apr 2009 11:11:50 -0400 References: <004201c9b8c8$ff727170$610c6f0a@china.huawei.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 09 Apr 2009 15:11:55.0040 (UTC) FILETIME=[84D74A00:01C9B925] Cc: 'idr List' Subject: Re: [Idr] Questions on draft-scudder-idr-optional-transitive-01 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, 09 Apr 2009 15:13:55 -0000 You're right in your analysis of exactly what the Partial bit communicates, and we'll revise the next version of the draft to correct the inaccurate characterization. It would have been more accurate to note that if the Partial bit is *not* set, then the fault *can* be imputed to the direct neighbor. A set Partial bit means that we don't know -- and when we don't know, we have to assume innocence on the part of the direct neighbor. The unfortunate fact is that there is no certain way with optional transitive attributes of determining whether the "at fault" speaker is the direct neighbor or not, thus I don't think there should be any other change to the draft -- Partial is admittedly an imperfect heuristic, but it's the best one we have available. The only other supportable alternative I can see is to apply the procedures of the draft to all optional transitives, whether Partial is set or not -- but that option seems even less desirable. Regards, --John On Apr 9, 2009, at 12:09 AM, Dong Jie wrote: > This draft said that optional transitive attributes with Partial bit > set > "have been propagated without being checked by intermediate routers > that do > not recognize the attribute", so if error-handling rules of RFC4271 > is used, > the session that is reset is not associated with the router that is at > fault. > > But the rules of setting Partial bit are complex and sometimes may > not meet > the condition the draft based on. > > Section 5 of RFC4271 specifies the rules of Partial bit in optional > transitive attributes: > > -"If a path with an unrecognized transitive optional attribute is > accepted > and passed to other BGP peers, then the unrecognized transitive > optional > attribute of that path MUST be passed, along with the path, to other > BGP > peers with the Partial bit in the Attribute Flags octet set to 1. > If a path > with a recognized, transitive optional attribute is accepted and > passed > along to other BGP peers and the Partial bit in the Attribute Flags > octet is > set to 1 by some previous AS, it MUST NOT be set back to 0 by the > current > AS." > > -"New, transitive optional attributes MAY be attached to the path by > the > originator or by any other BGP speaker in the path. If they are not > attached by the originator, the Partial bit in the Attribute Flags > octet is > set to 1." > > Based on these rules, receiving optional transitive attributes with > partial > bit set does not mean the peering BGP speaker cannot recognize the > attributes and does not check them, because Partial bit can be set > by some > previous BGP speakers, and it MUST NOT be set back to 0. In some > cases, > Partial bit is set by some previous BGP speaker, but the fault is > done by > the peering BGP speaker, then the procedures of RFC4271 SHOULD be > followed. > > In some other cases, Partial bit is set because the attribute is > attached by > some intermediate BGP speaker, and all of the BGP speakers along the > path > can recognize it. Then the procedures of RFC4271 SHOULD also be > followed. > > IMO, Partial bit of optional transitive attribute is not fit for > identifying > whether the fault is done by the peering BGP speaker. It only > indicates that > the optional transitive attribute is *not recognized* or *not seen* > by all > the BGP speakers in the path. > > Best regards, > Jie > From dongjie_dj@huawei.com Thu Apr 9 19:49:13 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 B457228C145 for ; Thu, 9 Apr 2009 19:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=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 U+qPMODSFIeh for ; Thu, 9 Apr 2009 19:49:12 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 50F823A69E5 for ; Thu, 9 Apr 2009 19:49:12 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHV008E16JJER@szxga02-in.huawei.com> for idr@ietf.org; Fri, 10 Apr 2009 10:50:07 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHV004GT6JJCN@szxga02-in.huawei.com> for idr@ietf.org; Fri, 10 Apr 2009 10:50:07 +0800 (CST) Received: from d65110 ([10.111.12.97]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHV0033L6JIR9@szxml06-in.huawei.com> for idr@ietf.org; Fri, 10 Apr 2009 10:50:07 +0800 (CST) Date: Fri, 10 Apr 2009 10:50:06 +0800 From: Dong Jie In-reply-to: To: "'John G. Scudder'" Message-id: <001301c9b987$0e9fffa0$610c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acm5Jqx0kPHo3IawQJCUssskbKJadAAVewJQ Cc: 'idr List' Subject: Re: [Idr] Questions on draft-scudder-idr-optional-transitive-01 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, 10 Apr 2009 02:49:13 -0000 > The unfortunate fact is that there is no certain way with optional > transitive attributes of determining whether the "at fault" speaker is > the direct neighbor or not That's right. And we should find a way to make it clear. Does anybody know the intention of designing Partial bit? I don't know if there are some other usages of Partial bit at present. When a BGP router receives an attribute with Partial bit set, does the router process the attribute specially? If not, maybe we can change the rules of setting Partial bit (and also the meaning of it). Each speaker SHOULD reset Partial bit before advertising the updates, and this bit is set to 1 if the speaker recognizes the attribute and has checked its correctness. Then Partial bit can be used to determine whether the "at fault" speaker is the direct neighbor or not. If Partial bit has some other usages and cannot be modified, we can define a new *Check bit* from the reserved bits of Attribute Flags Octet. The Check bit is set to 1 if the speaker recognizes the attribute and has checked its correctness. Each speaker SHOULD reset this bit before advertising the updates. Based on this Check bit, a speaker can determine whether the attribute has been checked by the direct neighbor, and knows whether it is at fault. Either of the two modifications can guarantee that accurate error handling procedures are used. Best regards, Jie > -----Original Message----- > From: John G. Scudder [mailto:jgs@juniper.net] > Sent: Thursday, April 09, 2009 11:12 PM > To: Dong Jie > Cc: 'idr List' > Subject: Re: Questions on draft-scudder-idr-optional-transitive-01 > > You're right in your analysis of exactly what the Partial bit > communicates, and we'll revise the next version of the draft to > correct the inaccurate characterization. It would have been more > accurate to note that if the Partial bit is *not* set, then the fault > *can* be imputed to the direct neighbor. A set Partial bit means that > we don't know -- and when we don't know, we have to assume innocence > on the part of the direct neighbor. > > The unfortunate fact is that there is no certain way with optional > transitive attributes of determining whether the "at fault" speaker is > the direct neighbor or not, thus I don't think there should be any > other change to the draft -- Partial is admittedly an imperfect > heuristic, but it's the best one we have available. The only other > supportable alternative I can see is to apply the procedures of the > draft to all optional transitives, whether Partial is set or not -- > but that option seems even less desirable. > > Regards, > > --John > > On Apr 9, 2009, at 12:09 AM, Dong Jie wrote: > > > This draft said that optional transitive attributes with Partial bit > > set > > "have been propagated without being checked by intermediate routers > > that do > > not recognize the attribute", so if error-handling rules of RFC4271 > > is used, > > the session that is reset is not associated with the router that is at > > fault. > > > > But the rules of setting Partial bit are complex and sometimes may > > not meet > > the condition the draft based on. > > > > Section 5 of RFC4271 specifies the rules of Partial bit in optional > > transitive attributes: > > > > -"If a path with an unrecognized transitive optional attribute is > > accepted > > and passed to other BGP peers, then the unrecognized transitive > > optional > > attribute of that path MUST be passed, along with the path, to other > > BGP > > peers with the Partial bit in the Attribute Flags octet set to 1. > > If a path > > with a recognized, transitive optional attribute is accepted and > > passed > > along to other BGP peers and the Partial bit in the Attribute Flags > > octet is > > set to 1 by some previous AS, it MUST NOT be set back to 0 by the > > current > > AS." > > > > -"New, transitive optional attributes MAY be attached to the path by > > the > > originator or by any other BGP speaker in the path. If they are not > > attached by the originator, the Partial bit in the Attribute Flags > > octet is > > set to 1." > > > > Based on these rules, receiving optional transitive attributes with > > partial > > bit set does not mean the peering BGP speaker cannot recognize the > > attributes and does not check them, because Partial bit can be set > > by some > > previous BGP speakers, and it MUST NOT be set back to 0. In some > > cases, > > Partial bit is set by some previous BGP speaker, but the fault is > > done by > > the peering BGP speaker, then the procedures of RFC4271 SHOULD be > > followed. > > > > In some other cases, Partial bit is set because the attribute is > > attached by > > some intermediate BGP speaker, and all of the BGP speakers along the > > path > > can recognize it. Then the procedures of RFC4271 SHOULD also be > > followed. > > > > IMO, Partial bit of optional transitive attribute is not fit for > > identifying > > whether the fault is done by the peering BGP speaker. It only > > indicates that > > the optional transitive attribute is *not recognized* or *not seen* > > by all > > the BGP speakers in the path. > > > > Best regards, > > Jie > > From yakov@juniper.net Mon Apr 13 08:20:34 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 C14BD3A67DD for ; Mon, 13 Apr 2009 08:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 CaK2PMNjQuMB for ; Mon, 13 Apr 2009 08:20:34 -0700 (PDT) Received: from chip3og51.obsmtp.com (chip3og51.obsmtp.com [64.18.14.167]) by core3.amsl.com (Postfix) with ESMTP id C06B23A6978 for ; Mon, 13 Apr 2009 08:20:33 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob51.postini.com ([64.18.6.12]) with SMTP ID DSNKSeNYiCxPRC8bR+VdjuIl8F61xMz4aHUK@postini.com; Mon, 13 Apr 2009 08:21:45 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Mon, 13 Apr 2009 08:17:47 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 08:17:47 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 08:17:47 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Apr 2009 08:17:46 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3DFHkM49924 for ; Mon, 13 Apr 2009 08:17:46 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200904131517.n3DFHkM49924@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <74366.1239635866.1@juniper.net> Date: Mon, 13 Apr 2009 08:17:46 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 13 Apr 2009 15:17:46.0949 (UTC) FILETIME=[003F5750:01C9BC4B] Subject: [Idr] draft-scudder-idr-optional-transitive-01.txt as IDR WG document 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, 13 Apr 2009 15:20:34 -0000 Folks, draft-scudder-idr-optional-transitive-01.txt is accepted as IDR WG document. Authors should re-submit it as draft-ietf-idr- Yakov. ------- Forwarded Message Date: Tue, 24 Mar 2009 06:55:19 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] draft-scudder-idr-optional-transitive-01.txt as IDR WG document Folks, At the IDR WG meeting yesterday we had a very strong consensus for accepting draft-scudder-idr-optional-transitive-01.txt as an IDR WG document. Given that, unless we have a fairly strong consensus against accepting this draft, the draft will be accepted as an IDR WG document. The deadline for comments is April 6, 2009. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message From mach@huawei.com Mon Apr 13 19:30: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 50B083A6C69 for ; Mon, 13 Apr 2009 19:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.832 X-Spam-Level: **** X-Spam-Status: No, score=4.832 tagged_above=-999 required=5 tests=[AWL=3.527, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6, RDNS_NONE=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 Gd3C7TlHv9hG for ; Mon, 13 Apr 2009 19:30:24 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CCF5F3A6A6D for ; Mon, 13 Apr 2009 19:30:23 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI200MTJKASZV@szxga03-in.huawei.com> for idr@ietf.org; Tue, 14 Apr 2009 10:30:28 +0800 (CST) Received: from m55527c ([10.111.12.135]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI200BQMKARGP@szxga03-in.huawei.com> for idr@ietf.org; Tue, 14 Apr 2009 10:30:28 +0800 (CST) Date: Tue, 14 Apr 2009 10:30:27 +0800 From: Mach Chen In-reply-to: To: "John G. Scudder" , Dong Jie Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <004201c9b8c8$ff727170$610c6f0a@china.huawei.com> Cc: 'idr List' Subject: Re: [Idr] Questions on draft-scudder-idr-optional-transitive-01 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, 14 Apr 2009 02:30:25 -0000 Hi John and others, Happy Easter! maybe a little bit late:) Pls see inline... -------------------------------------------------- From: "John G. Scudder" Sent: Thursday, April 09, 2009 11:11 PM To: "Dong Jie" Cc: "'idr List'" Subject: Re: [Idr] Questions on draft-scudder-idr-optional-transitive-01 > You're right in your analysis of exactly what the Partial bit > communicates, and we'll revise the next version of the draft to correct > the inaccurate characterization. It would have been more accurate to > note that if the Partial bit is *not* set, then the fault *can* be > imputed to the direct neighbor. A set Partial bit means that we don't > know -- and when we don't know, we have to assume innocence on the part > of the direct neighbor. But sometime(for whatever reason), if it happens to the direct neighbor at fault, then we will mistake to assume that the direct neighbour is innocence, and hence to result in route inconsistent or any other underlying aftereffects no matter what we drop or accept the update with malformed transitive optional attribute. > > The unfortunate fact is that there is no certain way with optional > transitive attributes of determining whether the "at fault" speaker is > the direct neighbor or not, Actually, without a dedicated flag for judging whether the direct neighbor is innocence is the key point. Using the Partial bit for judging is somtimes a better than none choice, but as I said above, it will bring side effects. So, since we want to resolve this malformed transitive optional attribute issue, why don't we think out a more downright method? IMO, Dong's suggestion in another email may be a good idea, that is if the Partial bit has not any essential usage (I have not seen any application of it, or someone please educate me), we may change the usage of Partial bit to indicate whether a BGP speaker recognizes the transitive optional attribute attached on a route, if we can't change the usage of the Partial bit, we could assign a new bit(may called Check bit)from the reserved bits of attribute for such purpose. >thus I don't think there should be any other change to the draft -- >Partial is admittedly an imperfect heuristic, but it's the best one we >have available. The only other supportable alternative I can see is to >apply the procedures of the draft to all optional transitives, whether >Partial is set or not -- but that option seems even less desirable. > > Regards, > > --John Best regards, Mach Chen > > On Apr 9, 2009, at 12:09 AM, Dong Jie wrote: > >> This draft said that optional transitive attributes with Partial bit set >> "have been propagated without being checked by intermediate routers that >> do >> not recognize the attribute", so if error-handling rules of RFC4271 is >> used, >> the session that is reset is not associated with the router that is at >> fault. >> >> But the rules of setting Partial bit are complex and sometimes may not >> meet >> the condition the draft based on. >> >> Section 5 of RFC4271 specifies the rules of Partial bit in optional >> transitive attributes: >> >> -"If a path with an unrecognized transitive optional attribute is >> accepted >> and passed to other BGP peers, then the unrecognized transitive optional >> attribute of that path MUST be passed, along with the path, to other BGP >> peers with the Partial bit in the Attribute Flags octet set to 1. If a >> path >> with a recognized, transitive optional attribute is accepted and passed >> along to other BGP peers and the Partial bit in the Attribute Flags >> octet is >> set to 1 by some previous AS, it MUST NOT be set back to 0 by the >> current >> AS." >> >> -"New, transitive optional attributes MAY be attached to the path by the >> originator or by any other BGP speaker in the path. If they are not >> attached by the originator, the Partial bit in the Attribute Flags octet >> is >> set to 1." >> >> Based on these rules, receiving optional transitive attributes with >> partial >> bit set does not mean the peering BGP speaker cannot recognize the >> attributes and does not check them, because Partial bit can be set by >> some >> previous BGP speakers, and it MUST NOT be set back to 0. In some cases, >> Partial bit is set by some previous BGP speaker, but the fault is done >> by >> the peering BGP speaker, then the procedures of RFC4271 SHOULD be >> followed. >> >> In some other cases, Partial bit is set because the attribute is >> attached by >> some intermediate BGP speaker, and all of the BGP speakers along the >> path >> can recognize it. Then the procedures of RFC4271 SHOULD also be >> followed. >> >> IMO, Partial bit of optional transitive attribute is not fit for >> identifying >> whether the fault is done by the peering BGP speaker. It only indicates >> that >> the optional transitive attribute is *not recognized* or *not seen* by >> all >> the BGP speakers in the path. >> >> Best regards, >> Jie >> > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From rex@juniper.net Tue Apr 14 10:47:00 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 BEEBA3A6E44 for ; Tue, 14 Apr 2009 10:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 uxOGMBKnXthU for ; Tue, 14 Apr 2009 10:46:59 -0700 (PDT) Received: from chip3og62.obsmtp.com (chip3og62.obsmtp.com [64.18.14.201]) by core3.amsl.com (Postfix) with ESMTP id B399B3A6872 for ; Tue, 14 Apr 2009 10:46:58 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob62.postini.com ([64.18.6.12]) with SMTP ID DSNKSeTMV84uFYNLTyZUEwwXrvC557zvYIFB@postini.com; Tue, 14 Apr 2009 10:48:10 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 14 Apr 2009 10:45:27 -0700 From: Rex Fernando To: 'PAPADIMITRIOU Dimitri' , Yakov Rekhter , "idr@ietf.org" Date: Tue, 14 Apr 2009 10:45:27 -0700 Thread-Topic: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WGdocument Thread-Index: AcmsiWe7S/jJkEhqTGSkB1MLz3BMbAAGjIagAJq4b7AALO+fUANZP5Qg Message-ID: In-Reply-To: <00275A5B436CA441900CB10936742A3801F86AFB@FRVELSMBS22.ad2.ad.alcatel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_DBDEC20E6E29304D8AE5EAA493609B3555C17B706BEMBX02HQjnprn_" MIME-Version: 1.0 Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WGdocument 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, 14 Apr 2009 17:47:00 -0000 --_003_DBDEC20E6E29304D8AE5EAA493609B3555C17B706BEMBX02HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dimitri, The revised version includes the following changes that you suggested we ma= ke: (a) Note the fact that the value carried in the link-bandwidth extended com= munity does not change with traffic levels (text added to section 2). (b) Clarify the scenarios under which link bandwidth can be safely deployed= (clarified in section 3) I've attached the revised draft and the diff. Thanks, - Rex | -----Original Message----- | From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel- | lucent.be] | Sent: Saturday, March 28, 2009 10:08 AM | To: Rex Fernando; Yakov Rekhter; idr@ietf.org | Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR | WGdocument | =20 | Hi Fernando: | =20 | > -----Original Message----- | > From: Rex Fernando [mailto:rex@juniper.net] | > Sent: Friday, March 27, 2009 8:57 PM | > To: PAPADIMITRIOU Dimitri; Yakov Rekhter; idr@ietf.org | > Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt | > as IDR WGdocument | > | > Hi Dimitri, | > | > | The Link Bandwidth Community used to be part of the BGP Extended | > | Communities Attribute document (now RFC4360) until it was | > removed in v09 | > | after review. At that it was stated that in order to perform | > | BW-proportional BGP load-balancing, BGP multipath load | > balancing should | > | be first documented. Isn't this condition still valid in | > the present | > | case and the corr.mechanisms to be documented beyond | > limited deployment | > | consideration part of Section 3? | > | > The draft lists the cases (although not in so many words) | > where link bandwidth can be safely deployed i.e. when the | > candidate paths are identical until the IGP distance step in | > path selection or you have a tunneled network. Either of | > these would ensure loop freedom. And that's all there is to it. | > | > We'll be happy to omit the word "multipath" from the draft | > since it lacks prior definition and expand on the deployment | > scenarios a bit if you feel strongly about it. | =20 | I think we have first to agree on the definition of "link bandwidth" | =20 | - either consider the link bandwidth as the "nominal link capacity" | which is thus a fixed and configured value (equivalent to link cost) | that does not result in variability in the multipath selection process | at the border router (PE1 in the slide material) beside local policy | decision. this would lead to a control-driven usage of this attribute. | =20 | - or consider the link bandwidth as the "available link bandwidth" aka | "residual capacity" which thus leaves possibility for varying the | multipath selection process over time depending on the actual value of | this attribute. this would lead to a traffic-driven usage of this | attribute. | =20 | I would be advisable that you clarify on this point to see how to | consider Section 3 statement: | =20 | "The usage of this community is restricted to the cases where BGP | multipath can be safely deployed." | =20 | Thanks, | -dimitri. | =20 | > - Rex | > | > --_003_DBDEC20E6E29304D8AE5EAA493609B3555C17B706BEMBX02HQjnprn_ Content-Type: text/plain; name="draft-rfernando-idr-link-bandwidth-00.txt" Content-Description: draft-rfernando-idr-link-bandwidth-00.txt Content-Disposition: attachment; filename="draft-rfernando-idr-link-bandwidth-00.txt"; size=8717; creation-date="Tue, 14 Apr 2009 10:32:02 GMT"; modification-date="Tue, 14 Apr 2009 10:33:24 GMT" Content-Transfer-Encoding: base64 TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUC4gTW9oYXBhdHJhDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMNCkludGVuZGVkIHN0YXR1czogU3RhbmRh cmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBGZXJuYW5kbw0KRXhwaXJl czogU2VwdGVtYmVyIDQsIDIwMDkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5pcGVy IE5ldHdvcmtzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE1hcmNoIDMsIDIwMDkNCg0KDQogICAgICAgICAgICAgICAgIEJHUCBMaW5r IEJhbmR3aWR0aCBFeHRlbmRlZCBDb21tdW5pdHkNCiAgICAgICAgICAgICAgIGRyYWZ0LXJmZXJu YW5kby1pZHItbGluay1iYW5kd2lkdGgtMDAudHh0DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0K ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZv cm1hbmNlIHdpdGggdGhlDQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LiAgVGhp cyBkb2N1bWVudCBtYXkgY29udGFpbiBtYXRlcmlhbA0KICAgZnJvbSBJRVRGIERvY3VtZW50cyBv ciBJRVRGIENvbnRyaWJ1dGlvbnMgcHVibGlzaGVkIG9yIG1hZGUgcHVibGljbHkNCiAgIGF2YWls YWJsZSBiZWZvcmUgTm92ZW1iZXIgMTAsIDIwMDguICBUaGUgcGVyc29uKHMpIGNvbnRyb2xsaW5n IHRoZQ0KICAgY29weXJpZ2h0IGluIHNvbWUgb2YgdGhpcyBtYXRlcmlhbCBtYXkgbm90IGhhdmUg Z3JhbnRlZCB0aGUgSUVURg0KICAgVHJ1c3QgdGhlIHJpZ2h0IHRvIGFsbG93IG1vZGlmaWNhdGlv bnMgb2Ygc3VjaCBtYXRlcmlhbCBvdXRzaWRlIHRoZQ0KICAgSUVURiBTdGFuZGFyZHMgUHJvY2Vz cy4gIFdpdGhvdXQgb2J0YWluaW5nIGFuIGFkZXF1YXRlIGxpY2Vuc2UgZnJvbQ0KICAgdGhlIHBl cnNvbihzKSBjb250cm9sbGluZyB0aGUgY29weXJpZ2h0IGluIHN1Y2ggbWF0ZXJpYWxzLCB0aGlz DQogICBkb2N1bWVudCBtYXkgbm90IGJlIG1vZGlmaWVkIG91dHNpZGUgdGhlIElFVEYgU3RhbmRh cmRzIFByb2Nlc3MsIGFuZA0KICAgZGVyaXZhdGl2ZSB3b3JrcyBvZiBpdCBtYXkgbm90IGJlIGNy ZWF0ZWQgb3V0c2lkZSB0aGUgSUVURiBTdGFuZGFyZHMNCiAgIFByb2Nlc3MsIGV4Y2VwdCB0byBm b3JtYXQgaXQgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIFJGQyBvciB0bw0KICAgdHJhbnNsYXRlIGl0 IGludG8gbGFuZ3VhZ2VzIG90aGVyIHRoYW4gRW5nbGlzaC4NCg0KICAgSW50ZXJuZXQtRHJhZnRz IGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRh c2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3Rl IHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1l bnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRy YWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBt YXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMg YXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh ZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8x aWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93 IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9z aGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBTZXB0 ZW1iZXIgNCwgMjAwOS4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKGMpIDIw MDkgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNCiAgIGRvY3Vt ZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQoNCg0KDQpNb2hhcGF0cmEgJiBG ZXJuYW5kbyAgICBFeHBpcmVzIFNlcHRlbWJlciA0LCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2Ug MV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgTGluayBCYW5kd2lkdGggICAgICAg ICAgICAgICAgICAgTWFyY2ggMjAwOQ0KDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0 byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zpc2lvbnMgUmVsYXRp bmcgdG8gSUVURiBEb2N1bWVudHMgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQogICBwdWJsaWNh dGlvbiBvZiB0aGlzIGRvY3VtZW50IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWlu Zm8pLg0KICAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5 IGRlc2NyaWJlIHlvdXIgcmlnaHRzDQogICBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdCB0 byB0aGlzIGRvY3VtZW50Lg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyBhbiBhcHBsaWNhdGlvbiBvZiBCR1AgZXh0ZW5kZWQgY29tbXVuaXRpZXMNCiAgIHRoYXQgYWxs b3dzIGEgcm91dGVyIHRvIHBlcmZvcm0gdW5lcXVhbCBjb3N0IGxvYWQgYmFsYW5jaW5nLg0KDQoN ClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMw0KICAgICAxLjEuICBSZXF1aXJl bWVudHMgTGFuZ3VhZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzDQog ICAyLiAgTGluayBCYW5kd2lkdGggRXh0ZW5kZWQgQ29tbXVuaXR5IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDMNCiAgIDMuICBEZXBsb3ltZW50IENvbnNpZGVyYXRpb25zIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMw0KICAgNC4gIEFja25vd2xlZGdtZW50cyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0DQogICA1LiAg SUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDQNCiAgIDYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNA0KICAgNy4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0DQogICBBdXRob3JzJyBB ZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDQNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KTW9oYXBhdHJhICYgRmVybmFuZG8gICAgRXhwaXJlcyBTZXB0ZW1iZXIgNCwgMjAwOSAgICAg ICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExpbmsg QmFuZHdpZHRoICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDkNCg0KDQoxLiAgSW50cm9kdWN0 aW9uDQoNCiAgIFdoZW4gYSBCR1Agc3BlYWtlciByZWNlaXZlcyBtdWx0aXBsZSBwYXRocyBmcm9t IGl0cyBpbnRlcm5hbCBwZWVycywNCiAgIGl0IGNvdWxkIHNlbGVjdCBtb3JlIHRoYW4gb25lIHBh dGggdG8gc2VuZCB0cmFmZmljIHRvLiAgSW4gZG9pbmcgc28sDQogICBpdCBtaWdodCBiZSB1c2Vm dWwgdG8gcHJvdmlkZSB0aGUgc3BlYWtlciB3aXRoIGluZm9ybWF0aW9uIHRoYXQgd291bGQNCiAg IGhlbHAgaXQgZGlzdHJpYnV0ZSB0aGUgdHJhZmZpYyB1bmVxdWFsbHkgYmFzZWQgb24gdGhlIGNv c3Qgb2YgdGhlDQogICBleHRlcm5hbCAoRE1aKSBsaW5rLiAgVGhpcyBkb2N1bWVudCBzdWdnZXN0 cyB0aGF0IHRoZSBleHRlcm5hbCBsaW5rDQogICBiYW5kd2lkdGggYmUgY2FycmllZCBpbiB0aGUg bmV0d29yayB1c2luZyBhIG5ldyBleHRlbmRlZCBjb21tdW5pdHkNCiAgIFtSRkM0MzYwXSAtIHRo ZSBsaW5rIGJhbmR3aWR0aCBleHRlbmRlZCBjb21tdW5pdHkuDQoNCjEuMS4gIFJlcXVpcmVtZW50 cyBMYW5ndWFnZQ0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJ UkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAi UkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQg YXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0u DQoNCg0KMi4gIExpbmsgQmFuZHdpZHRoIEV4dGVuZGVkIENvbW11bml0eQ0KDQogICBXaGVuIGEg QkdQIHNwZWFrZXIgcmVjZWl2ZXMgYSByb3V0ZSBmcm9tIGEgZGlyZWN0bHkgY29ubmVjdGVkDQog ICBleHRlcm5hbCBuZWlnaGJvciAodGhlIGV4dGVybmFsIG5laWdoYm9yIHRoYXQgaXMgb25lIElQ IGhvcCBhd2F5KSBhbmQNCiAgIGFkdmVydGlzZXMgdGhpcyByb3V0ZSAodmlhIElCR1ApIHRvIGlu dGVybmFsIG5laWdoYm9ycywgYXMgcGFydCBvZg0KICAgdGhpcyBhZHZlcnRpc2VtZW50IHRoZSBy b3V0ZXIgbWF5IGNhcnJ5IHRoZSBiYW5kd2lkdGggb2YgdGhlIGxpbmsNCiAgIHRoYXQgY29ubmVj dHMgdGhlIHJvdXRlciB3aXRoIHRoZSBleHRlcm5hbCBuZWlnaGJvci4gIFRoZSBiYW5kd2lkdGgN CiAgIG9mIHN1Y2ggYSBsaW5rIGlzIGNhcnJpZWQgaW4gdGhlIExpbmsgQmFuZHdpZHRoIENvbW11 bml0eS4gIFRoZQ0KICAgY29tbXVuaXR5IGlzIG9wdGlvbmFsIG5vbi10cmFuc2l0aXZlLiAgQSBi b3JkZXIgcm91dGVyIE1VU1Qgc3RyaXAgdGhlDQogICBsaW5rIGJhbmR3aWR0aCBjb21tdW5pdHkg ZnJvbSBhIHJvdXRlIHdoZW4gaXQgYWR2ZXJ0aXNlcyB0aGUgcm91dGUgdG8NCiAgIGFuIGV4dGVy bmFsIG5laWdoYm9yLiAgDQoNCiAgIEl0IGlzIG5vdGV3b3J0aHkgdGhhdCB0aGUgYmFuZHdpZHRo IGNhcnJpZWQgaW4gdGhlIExpbmsgQmFuZHdpZHRoDQogICBleHRlbmRlZCBjb21tdW5pdHkgaXMg dGhlIGNvbmZpZ3VyZWQgYmFuZHdpZHRoIG9mIHRoZSBFQkdQIGxpbmsuDQogICBJdCBkb2VzIG5v dCBkZXBlbmQgb24gdGhlIGFtb3VudCBvZiB0cmFmZmljIHRyYW5zaXRpbmcgdGhhdCBsaW5rLg0K DQogICBUaGUgdmFsdWUgb2YgdGhlIGhpZ2gtb3JkZXIgb2N0ZXQgb2YgdGhlIGV4dGVuZGVkIFR5 cGUgRmllbGQgaXMNCiAgIDB4NDAuICBUaGUgdmFsdWUgb2YgdGhlIGxvdy1vcmRlciBvY3RldCBv ZiB0aGUgZXh0ZW5kZWQgdHlwZSBmaWVsZA0KICAgZm9yIHRoaXMgY29tbXVuaXR5IGlzIDB4MDQu ICBUaGUgdmFsdWUgb2YgdGhlIEdsb2JhbCBBZG1pbmlzdHJhdG9yDQogICBzdWJmaWVsZCBpbiB0 aGUgVmFsdWUgRmllbGQgU0hPVUxEIHJlcHJlc2VudCB0aGUgQXV0b25vbW91cyBTeXN0ZW0NCiAg IG9mIHRoZSByb3V0ZXIgdGhhdCBhdHRhY2hlcyB0aGUgTGluayBCYW5kd2lkdGggQ29tbXVuaXR5 LiAgSWYgZm91cg0KICAgb2N0ZXQgQVMgbnVtYmVyaW5nIHNjaGVtZSBpcyB1c2VkIFtSRkM0ODkz XSwgQVNfVFJBTlMgc2hvdWxkIGJlDQogICB1c2VkIGluIHRoZSBHbG9iYWwgQWRtaW5pc3RyYXRv ciBzdWJmaWVsZC4gIFRoZSBiYW5kd2lkdGggb2YgdGhlDQogICBsaW5rIGlzIGV4cHJlc3NlZCBh cyA0IG9jdGV0cyBpbiBJRUVFIGZsb2F0aW5nIHBvaW50IGZvcm1hdCwgdW5pdHMNCiAgIGJlaW5n IGJ5dGVzIHBlciBzZWNvbmQuICBJdCBpcyBjYXJyaWVkIGluIHRoZSBMb2NhbCBBZG1pbmlzdHJh dG9yDQogICBzdWJmaWVsZCBvZiB0aGUgVmFsdWUgRmllbGQuDQoNCg0KMy4gIERlcGxveW1lbnQg Q29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyB0byB1c2UgdGhlIExp bmsgQmFuZHdpZHRoIGV4dGVuZGVkDQogICBjb21tdW5pdHkgZm9yIHRoZSBwdXJwb3NlIG9mIGxv YWQgYmFsYW5jaW5nIGluIHRoZSBmb2xsb3dpbmcgdHdvDQogICBzY2VuYXJpb3MuIFRoZSBmaXJz dCBzY2VuYXJpbyBpcyB3aGVuIHRoZSBjYW5kaWRhdGUgcGF0aHMgYXJlDQogICBpZGVudGljYWwg dW50aWwgYW5kIGluY2x1ZGluZyB0aGUgSUdQIGRpc3RhbmNlIHN0ZXAgaW4gdGhlIEJHUA0KICAg ZGVjaXNpb24gcHJvY2Vzcy4gIFRoZSBzZWNvbmQgc2NlbmFyaW8gaXMgd2hlbiB0aGUgdHJhZmZp YyBnb2VzDQogICB2aWEgYSB0dW5uZWxlZCBuZXR3b3JrLCBpbiB3aGljaCBjYXNlIHRoZSBjYW5k aWRhdGUgcGF0aHMgYXJlDQogICBpZGVudGljYWwgZm9yIGFsbCBzdGVwcyBiZWZvcmUgdGhlIElH UCBkaXN0YW5jZSBzdGVwIGluIHRoZSBCR1ANCiAgIGRlY2lzaW9uIHByb2Nlc3MuICBVc2Ugb2Yg dGhpcyBjb21tdW5pdHkgZm9yIG90aGVyIHNjZW5hcmlvcyBpcw0KICAgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgSWYgdGhlcmUgYXJlIG11bHRpcGxlIHBhdGhzIHRv IHJlYWNoIGEgZGVzdGluYXRpb24gYW5kIGlmIG9ubHkgc29tZQ0KICAgb2YgdGhlbSBoYXZlIGxp bmsgYmFuZHdpZHRoIGNvbW11bml0eSwgdGhlIHJlY2VpdmVyIHNob3VsZCBub3QNCiAgIHBlcmZv cm0gdW5lcXVhbCBjb3N0IGxvYWQNCg0KDQoNCk1vaGFwYXRyYSAmIEZlcm5hbmRvICAgIEV4cGly ZXMgU2VwdGVtYmVyIDQsIDIwMDkgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICBMaW5rIEJhbmR3aWR0aCAgICAgICAgICAgICAgICAgICBNYXJj aCAyMDA5DQoNCg0KICAgYmFsYW5jaW5nIGJhc2VkIG9uIGxpbmsgYmFuZHdpZHRocy4NCg0KDQo0 LiAgQWNrbm93bGVkZ21lbnRzDQoNCiAgIFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsg WWFrb3YgUmVraHRlciwgU3JpaGFyaSBTYW5nbGkgYW5kIERhbg0KICAgVGFwcGFuIGZvciBwcm9w b3NpbmcgdW5lcXVhbCBjb3N0IGxvYWQgYmFsYW5jaW5nIGFzIG9uZSBwb3NzaWJsZQ0KICAgYXBw bGljYXRpb24gb2YgdGhlIGV4dGVuZGVkIGNvbW11bml0eSBhdHRyaWJ1dGUuDQoNCg0KNS4gIElB TkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc3BlY2lmaWMg YXBwbGljYXRpb24gb2YgdGhlIHR3by1vY3RldCBBUw0KICAgc3BlY2lmaWMgZXh0ZW5kZWQgY29t bXVuaXR5LiAgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gYXNzaWduIGEgc3ViLSB0eXBlDQogICB2YWx1 ZSBvZiAweDA0IGZvciB0aGUgbGluayBiYW5kd2lkdGggZXh0ZW5kZWQgY29tbXVuaXR5Lg0KDQoN CiAgICAgIE5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVmFs dWUNCiAgICAgIC0tLS0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LS0tLS0NCiAgICAgIG5vbi10cmFuc2l0aXZlIExpbmsgQmFuZHdpZHRoIEV4dC4gQ29tbXVuaXR5 ICAweDQwMDQNCg0KDQoNCjYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGVyZSBh cmUgbm8gYWRkaXRpb25hbCBzZWN1cml0eSByaXNrcyBpbnRyb2R1Y2VkIGJ5IHRoaXMgZGVzaWdu Lg0KDQoNCjcuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0gIEJyYWRuZXIs IFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAg ICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQog ICBbUkZDNDM2MF0gIFNhbmdsaSwgUy4sIFRhcHBhbiwgRC4sIGFuZCBZLiBSZWtodGVyLCAiQkdQ IEV4dGVuZGVkDQogICAgICAgICAgICAgIENvbW11bml0aWVzIEF0dHJpYnV0ZSIsIFJGQyA0MzYw LCBGZWJydWFyeSAyMDA2Lg0KDQogICBbUkZDNDg5M10gIFZvaHJhLCBRLiBhbmQgRS4gQ2hlbiwg IkJHUCBTdXBwb3J0IGZvciBGb3VyLW9jdGV0IEFTDQogICAgICAgICAgICAgIE51bWJlciBTcGFj ZSIsIFJGQyA0ODkzLCBNYXkgMjAwNy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTW9oYXBh dHJhICYgRmVybmFuZG8gICAgRXhwaXJlcyBTZXB0ZW1iZXIgNCwgMjAwOSAgICAgICAgICAgICAg IFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExpbmsgQmFuZHdpZHRo ICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDkNCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0K ICAgUHJhZG9zaCBNb2hhcGF0cmENCiAgIENpc2NvIFN5c3RlbXMNCiAgIDE3MCBXLiBUYXNtYW4g RHJpdmUNCiAgIFNhbiBKb3NlLCBDQSAgOTUxMzQNCiAgIFVTQQ0KDQogICBQaG9uZToNCiAgIEVt YWlsOiBwbW9oYXBhdEBjaXNjby5jb20NCg0KDQogICBSZXggRmVybmFuZG8NCiAgIEp1bmlwZXIg TmV0d29ya3MNCiAgIDExOTQgTi4gTWF0aGlsZGEgQXZlDQogICBTdW5ueXZhbGUsIENBICA5NDA4 OQ0KICAgVVNBDQoNCiAgIFBob25lOg0KICAgRW1haWw6IHJleEBqdW5pcGVyLm5ldA0KDQo= --_003_DBDEC20E6E29304D8AE5EAA493609B3555C17B706BEMBX02HQjnprn_ Content-Type: text/plain; name="diffs.txt" Content-Description: diffs.txt Content-Disposition: attachment; filename="diffs.txt"; size=3706; creation-date="Tue, 14 Apr 2009 10:32:50 GMT"; modification-date="Tue, 14 Apr 2009 10:33:33 GMT" Content-Transfer-Encoding: base64 DQoqKiogZHJhZnQtcmZlcm5hbmRvLWlkci1saW5rLWJhbmR3aWR0aC0wMC50eHQub3JpZwkyMDA5 LTA0LTE0IDA4OjM1OjU0LjQ0MzU4NDAwMCAtMDcwMA0KLS0tIGRyYWZ0LXJmZXJuYW5kby1pZHIt bGluay1iYW5kd2lkdGgtMDAudHh0CTIwMDktMDQtMTQgMDg6MzU6MjguNjU5ODI4MDAwIC0wNzAw DQoqKioqKioqKioqKioqKioNCioqKiAxNDAsMTY2ICoqKioNCiAgICAgb2Ygc3VjaCBhIGxpbmsg aXMgY2FycmllZCBpbiB0aGUgTGluayBCYW5kd2lkdGggQ29tbXVuaXR5LiAgVGhlDQogICAgIGNv bW11bml0eSBpcyBvcHRpb25hbCBub24tdHJhbnNpdGl2ZS4gIEEgYm9yZGVyIHJvdXRlciBNVVNU IHN0cmlwIHRoZQ0KICAgICBsaW5rIGJhbmR3aWR0aCBjb21tdW5pdHkgZnJvbSBhIHJvdXRlIHdo ZW4gaXQgYWR2ZXJ0aXNlcyB0aGUgcm91dGUgdG8NCiEgICAgYW4gZXh0ZXJuYWwgbmVpZ2hib3Iu ICBUaGUgdmFsdWUgb2YgdGhlIGhpZ2gtb3JkZXIgb2N0ZXQgb2YgdGhlDQohICAgIGV4dGVuZGVk IFR5cGUgRmllbGQgaXMgMHg0MC4gIFRoZSB2YWx1ZSBvZiB0aGUgbG93LW9yZGVyIG9jdGV0IG9m IHRoZQ0KISAgICBleHRlbmRlZCB0eXBlIGZpZWxkIGZvciB0aGlzIGNvbW11bml0eSBpcyAweDA0 LiAgVGhlIHZhbHVlIG9mIHRoZQ0KISAgICBHbG9iYWwgQWRtaW5pc3RyYXRvciBzdWJmaWVsZCBp biB0aGUgVmFsdWUgRmllbGQgU0hPVUxEIHJlcHJlc2VudCB0aGUNCiEgICAgQXV0b25vbW91cyBT eXN0ZW0gb2YgdGhlIHJvdXRlciB0aGF0IGF0dGFjaGVzIHRoZSBMaW5rIEJhbmR3aWR0aA0KISAg ICBDb21tdW5pdHkuICBJZiBmb3VyIG9jdGV0IEFTIG51bWJlcmluZyBzY2hlbWUgaXMgdXNlZCBb UkZDNDg5M10sDQohICAgIEFTX1RSQU5TIHNob3VsZCBiZSB1c2VkIGluIHRoZSBHbG9iYWwgQWRt aW5pc3RyYXRvciBzdWJmaWVsZC4gIFRoZQ0KISAgICBiYW5kd2lkdGggb2YgdGhlIGxpbmsgaXMg ZXhwcmVzc2VkIGFzIDQgb2N0ZXRzIGluIElFRUUgZmxvYXRpbmcgcG9pbnQNCiEgICAgZm9ybWF0 LCB1bml0cyBiZWluZyBieXRlcyBwZXIgc2Vjb25kLiAgSXQgaXMgY2FycmllZCBpbiB0aGUgTG9j YWwNCiEgICAgQWRtaW5pc3RyYXRvciBzdWJmaWVsZCBvZiB0aGUgVmFsdWUgRmllbGQuDQogIA0K ICANCiAgMy4gIERlcGxveW1lbnQgQ29uc2lkZXJhdGlvbnMNCiAgDQohICAgIFRoZSB1c2FnZSBv ZiB0aGlzIGNvbW11bml0eSBpcyByZXN0cmljdGVkIHRvIHRoZSBjYXNlcyB3aGVyZSBCR1ANCiEg ICAgbXVsdGlwYXRoIGNhbiBiZSBzYWZlbHkgZGVwbG95ZWQuICBJbiBvdGhlciB3b3JkcywgdGhl IElHUCBkaXN0YW5jZQ0KISAgICBiZXR3ZWVuIHRoZSBsb2FkIGJhbGFuY2luZyByb3V0ZXIgYW5k IHRoZSBleGl0IHBvaW50cyBzaG91bGQgYmUgdGhlDQohICAgIHNhbWUuICBBbHRlcm5hdGl2ZWx5 LCB0aGUgcGF0aCBiZXR3ZWVuIHRoZSBsb2FkIHNoYXJpbmcgcm91dGVyIGFuZA0KISAgICB0aGUg ZXhpdCBwb2ludHMgY291bGQgYmUgbGFiZWwgc3dpdGNoZWQuICBJZiB0aGVyZSBhcmUgbXVsdGlw bGUgcGF0aHMNCiEgICAgdG8gcmVhY2ggYSBkZXN0aW5hdGlvbiBhbmQgaWYgb25seSBzb21lIG9m IHRoZW0gaGF2ZSBsaW5rIGJhbmR3aWR0aA0KISAgICBjb21tdW5pdHksIHRoZSByZWNlaXZlciBz aG91bGQgbm90IHBlcmZvcm0gdW5lcXVhbCBjb3N0IGxvYWQNCiAgDQogIA0KICANCi0tLSAxNDAs MTc4IC0tLS0NCiAgICAgb2Ygc3VjaCBhIGxpbmsgaXMgY2FycmllZCBpbiB0aGUgTGluayBCYW5k d2lkdGggQ29tbXVuaXR5LiAgVGhlDQogICAgIGNvbW11bml0eSBpcyBvcHRpb25hbCBub24tdHJh bnNpdGl2ZS4gIEEgYm9yZGVyIHJvdXRlciBNVVNUIHN0cmlwIHRoZQ0KICAgICBsaW5rIGJhbmR3 aWR0aCBjb21tdW5pdHkgZnJvbSBhIHJvdXRlIHdoZW4gaXQgYWR2ZXJ0aXNlcyB0aGUgcm91dGUg dG8NCiEgICAgYW4gZXh0ZXJuYWwgbmVpZ2hib3IuICANCiEgDQohICAgIEl0IGlzIG5vdGV3b3J0 aHkgdGhhdCB0aGUgYmFuZHdpZHRoIGNhcnJpZWQgaW4gdGhlIExpbmsgQmFuZHdpZHRoDQohICAg IGV4dGVuZGVkIGNvbW11bml0eSBpcyB0aGUgY29uZmlndXJlZCBiYW5kd2lkdGggb2YgdGhlIEVC R1AgbGluay4NCiEgICAgSXQgZG9lcyBub3QgZGVwZW5kIG9uIHRoZSBhbW91bnQgb2YgdHJhZmZp YyB0cmFuc2l0aW5nIHRoYXQgbGluay4NCiEgDQohICAgIFRoZSB2YWx1ZSBvZiB0aGUgaGlnaC1v cmRlciBvY3RldCBvZiB0aGUgZXh0ZW5kZWQgVHlwZSBGaWVsZCBpcw0KISAgICAweDQwLiAgVGhl IHZhbHVlIG9mIHRoZSBsb3ctb3JkZXIgb2N0ZXQgb2YgdGhlIGV4dGVuZGVkIHR5cGUgZmllbGQN CiEgICAgZm9yIHRoaXMgY29tbXVuaXR5IGlzIDB4MDQuICBUaGUgdmFsdWUgb2YgdGhlIEdsb2Jh bCBBZG1pbmlzdHJhdG9yDQohICAgIHN1YmZpZWxkIGluIHRoZSBWYWx1ZSBGaWVsZCBTSE9VTEQg cmVwcmVzZW50IHRoZSBBdXRvbm9tb3VzIFN5c3RlbQ0KISAgICBvZiB0aGUgcm91dGVyIHRoYXQg YXR0YWNoZXMgdGhlIExpbmsgQmFuZHdpZHRoIENvbW11bml0eS4gIElmIGZvdXINCiEgICAgb2N0 ZXQgQVMgbnVtYmVyaW5nIHNjaGVtZSBpcyB1c2VkIFtSRkM0ODkzXSwgQVNfVFJBTlMgc2hvdWxk IGJlDQohICAgIHVzZWQgaW4gdGhlIEdsb2JhbCBBZG1pbmlzdHJhdG9yIHN1YmZpZWxkLiAgVGhl IGJhbmR3aWR0aCBvZiB0aGUNCiEgICAgbGluayBpcyBleHByZXNzZWQgYXMgNCBvY3RldHMgaW4g SUVFRSBmbG9hdGluZyBwb2ludCBmb3JtYXQsIHVuaXRzDQohICAgIGJlaW5nIGJ5dGVzIHBlciBz ZWNvbmQuICBJdCBpcyBjYXJyaWVkIGluIHRoZSBMb2NhbCBBZG1pbmlzdHJhdG9yDQohICAgIHN1 YmZpZWxkIG9mIHRoZSBWYWx1ZSBGaWVsZC4NCiAgDQogIA0KICAzLiAgRGVwbG95bWVudCBDb25z aWRlcmF0aW9ucw0KICANCiEgICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyB0byB1c2UgdGhlIExp bmsgQmFuZHdpZHRoIGV4dGVuZGVkDQohICAgIGNvbW11bml0eSBmb3IgdGhlIHB1cnBvc2Ugb2Yg bG9hZCBiYWxhbmNpbmcgaW4gdGhlIGZvbGxvd2luZyB0d28NCiEgICAgc2NlbmFyaW9zLiBUaGUg Zmlyc3Qgc2NlbmFyaW8gaXMgd2hlbiB0aGUgY2FuZGlkYXRlIHBhdGhzIGFyZQ0KISAgICBpZGVu dGljYWwgdW50aWwgYW5kIGluY2x1ZGluZyB0aGUgSUdQIGRpc3RhbmNlIHN0ZXAgaW4gdGhlIEJH UA0KISAgICBkZWNpc2lvbiBwcm9jZXNzLiAgVGhlIHNlY29uZCBzY2VuYXJpbyBpcyB3aGVuIHRo ZSB0cmFmZmljIGdvZXMNCiEgICAgdmlhIGEgdHVubmVsZWQgbmV0d29yaywgaW4gd2hpY2ggY2Fz ZSB0aGUgY2FuZGlkYXRlIHBhdGhzIGFyZQ0KISAgICBpZGVudGljYWwgZm9yIGFsbCBzdGVwcyBi ZWZvcmUgdGhlIElHUCBkaXN0YW5jZSBzdGVwIGluIHRoZSBCR1ANCiEgICAgZGVjaXNpb24gcHJv Y2Vzcy4gIFVzZSBvZiB0aGlzIGNvbW11bml0eSBmb3Igb3RoZXIgc2NlbmFyaW9zIGlzDQohICAg IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQohIA0KISAgICBJZiB0aGVyZSBh cmUgbXVsdGlwbGUgcGF0aHMgdG8gcmVhY2ggYSBkZXN0aW5hdGlvbiBhbmQgaWYgb25seSBzb21l DQohICAgIG9mIHRoZW0gaGF2ZSBsaW5rIGJhbmR3aWR0aCBjb21tdW5pdHksIHRoZSByZWNlaXZl ciBzaG91bGQgbm90DQohICAgIHBlcmZvcm0gdW5lcXVhbCBjb3N0IGxvYWQNCiAgDQogIA0KICAN Cg== --_003_DBDEC20E6E29304D8AE5EAA493609B3555C17B706BEMBX02HQjnprn_-- From robert@raszuk.net Tue Apr 14 10:57:48 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 ACD4228C1CA for ; Tue, 14 Apr 2009 10:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6] 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 bE0Qd1GNunmk for ; Tue, 14 Apr 2009 10:57:47 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 74E0828C1CC for ; Tue, 14 Apr 2009 10:57:47 -0700 (PDT) Received: (qmail 11337 invoked by uid 399); 14 Apr 2009 17:58:58 -0000 Received: from unknown (HELO ?192.168.1.52?) (83.24.22.241) by mail37.opentransfer.com with SMTP; 14 Apr 2009 17:58:58 -0000 Message-ID: <49E4CEE0.8020607@raszuk.net> Date: Tue, 14 Apr 2009 10:58:56 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mach Chen References: <004201c9b8c8$ff727170$610c6f0a@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'idr List' Subject: Re: [Idr] Questions on draft-scudder-idr-optional-transitive-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:57:48 -0000 Hi Mach & Dong, I think your suggestion for better way to determine the router at fault is very valuable and would indeed be very helpful. But in my opinion what this draft focuses on is the least expensive and as safe as possible while in the same time actually doable way to address issue in existing networks deployed today. In those we can not rely on the fact that all of my peers and peers of my peers will migrate and deploy either new semantics for partial bit setting and treatment or introduce some other form of malformation signaling. So I would suggest to continue the draft as is and in the same time start the work on exploring possibilities on better way to signal the peer if I am at fault or some box few routers down. The real issue (and perhaps only one) is that the content of the opaque transitive attribute is unknown to the router not supporting it. Therefor unless it contains some form of well known per transitive attribute based checksum it may be difficult to set any flag based on it's content. Cheers, R. > Hi John and others, > > Happy Easter! maybe a little bit late:) > > Pls see inline... > > -------------------------------------------------- > From: "John G. Scudder" > Sent: Thursday, April 09, 2009 11:11 PM > To: "Dong Jie" > Cc: "'idr List'" > Subject: Re: [Idr] Questions on draft-scudder-idr-optional-transitive-01 > >> You're right in your analysis of exactly what the Partial bit >> communicates, and we'll revise the next version of the draft to >> correct the inaccurate characterization. It would have been more >> accurate to note that if the Partial bit is *not* set, then the fault >> *can* be imputed to the direct neighbor. A set Partial bit means >> that we don't know -- and when we don't know, we have to assume >> innocence on the part of the direct neighbor. > > But sometime(for whatever reason), if it happens to the direct neighbor > at fault, then we will mistake to assume that the direct neighbour is > innocence, and hence to result in route inconsistent or any other > underlying aftereffects no matter what we drop or accept the update with > malformed transitive optional attribute. > >> >> The unfortunate fact is that there is no certain way with optional >> transitive attributes of determining whether the "at fault" speaker is >> the direct neighbor or not, > > Actually, without a dedicated flag for judging whether the direct > neighbor is innocence is the key point. Using the Partial bit for > judging is somtimes a better than none choice, but as I said above, it > will bring side effects. > > So, since we want to resolve this malformed transitive optional > attribute issue, why don't we think out a more downright method? > > IMO, Dong's suggestion in another email may be a good idea, that is if > the Partial bit has not any essential usage (I have not seen any > application of it, or someone please educate me), we may change the > usage of Partial bit to indicate whether a BGP speaker recognizes the > transitive optional attribute attached on a route, if we can't change > the usage of the Partial bit, we could assign a new bit(may called Check > bit)from the reserved bits of attribute for such purpose. > >> thus I don't think there should be any other change to the draft -- >> Partial is admittedly an imperfect heuristic, but it's the best one >> we have available. The only other supportable alternative I can see >> is to apply the procedures of the draft to all optional transitives, >> whether Partial is set or not -- but that option seems even less >> desirable. >> >> Regards, >> >> --John > > > Best regards, > Mach Chen > > >> >> On Apr 9, 2009, at 12:09 AM, Dong Jie wrote: >> >>> This draft said that optional transitive attributes with Partial bit >>> set >>> "have been propagated without being checked by intermediate routers >>> that do >>> not recognize the attribute", so if error-handling rules of RFC4271 >>> is used, >>> the session that is reset is not associated with the router that is at >>> fault. >>> >>> But the rules of setting Partial bit are complex and sometimes may >>> not meet >>> the condition the draft based on. >>> >>> Section 5 of RFC4271 specifies the rules of Partial bit in optional >>> transitive attributes: >>> >>> -"If a path with an unrecognized transitive optional attribute is >>> accepted >>> and passed to other BGP peers, then the unrecognized transitive >>> optional >>> attribute of that path MUST be passed, along with the path, to other >>> BGP >>> peers with the Partial bit in the Attribute Flags octet set to 1. >>> If a path >>> with a recognized, transitive optional attribute is accepted and passed >>> along to other BGP peers and the Partial bit in the Attribute Flags >>> octet is >>> set to 1 by some previous AS, it MUST NOT be set back to 0 by the >>> current >>> AS." >>> >>> -"New, transitive optional attributes MAY be attached to the path by >>> the >>> originator or by any other BGP speaker in the path. If they are not >>> attached by the originator, the Partial bit in the Attribute Flags >>> octet is >>> set to 1." >>> >>> Based on these rules, receiving optional transitive attributes with >>> partial >>> bit set does not mean the peering BGP speaker cannot recognize the >>> attributes and does not check them, because Partial bit can be set >>> by some >>> previous BGP speakers, and it MUST NOT be set back to 0. In some cases, >>> Partial bit is set by some previous BGP speaker, but the fault is >>> done by >>> the peering BGP speaker, then the procedures of RFC4271 SHOULD be >>> followed. >>> >>> In some other cases, Partial bit is set because the attribute is >>> attached by >>> some intermediate BGP speaker, and all of the BGP speakers along the >>> path >>> can recognize it. Then the procedures of RFC4271 SHOULD also be >>> followed. >>> >>> IMO, Partial bit of optional transitive attribute is not fit for >>> identifying >>> whether the fault is done by the peering BGP speaker. It only >>> indicates that >>> the optional transitive attribute is *not recognized* or *not seen* >>> by all >>> the BGP speakers in the path. >>> >>> Best regards, >>> Jie >>> >> >> _______________________________________________ >> 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 jgs@juniper.net Tue Apr 14 12:58:26 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 8E42B3A659C for ; Tue, 14 Apr 2009 12:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.675 X-Spam-Level: X-Spam-Status: No, score=-5.675 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6, 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 ItQ0zZtQ2T-d for ; Tue, 14 Apr 2009 12:58:25 -0700 (PDT) Received: from chip3og58.obsmtp.com (chip3og58.obsmtp.com [64.18.14.181]) by core3.amsl.com (Postfix) with ESMTP id C7DE63A699A for ; Tue, 14 Apr 2009 12:58:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob58.postini.com ([64.18.6.12]) with SMTP ID DSNKSeTrI8x1r2e/oWQje2C13ddsq1O2xVID@postini.com; Tue, 14 Apr 2009 12:59:37 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 14 Apr 2009 12:55:10 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 12:55:10 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 12:55:09 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 12:55:09 -0700 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3EJt8M76819; Tue, 14 Apr 2009 12:55:08 -0700 (PDT) (envelope-from jgs@juniper.net) Message-ID: <613C4A5B-3A8B-47F5-BE0B-D918BCA4543E@juniper.net> From: "John G. Scudder" To: Robert Raszuk , Mach Chen , Dong Jie In-Reply-To: <49E4CEE0.8020607@raszuk.net> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 15:55:06 -0400 References: <004201c9b8c8$ff727170$610c6f0a@china.huawei.com> <49E4CEE0.8020607@raszuk.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 14 Apr 2009 19:55:09.0345 (UTC) FILETIME=[EA4D3110:01C9BD3A] Cc: idr List Subject: Re: [Idr] Questions on draft-scudder-idr-optional-transitive-01 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, 14 Apr 2009 19:58:26 -0000 Folks, I think Robert expresses it well when he points out that an important goal of the draft is to be deployable in current networks. It is important that it not rely on the collaboration of peers in order to be deployed, thus the current flags and their semantics are a given. IMO it would be a fine idea to start a separate conversation on the suggestion to change the semantics of Partial or standardize a new flag. Regards, --John P.S.: It could also be early to wish a Happy Easter if you're following the Orthodox calendar. :-) On Apr 14, 2009, at 1:58 PM, Robert Raszuk wrote: > Hi Mach & Dong, > > I think your suggestion for better way to determine the router at > fault is very valuable and would indeed be very helpful. > > But in my opinion what this draft focuses on is the least expensive > and as safe as possible while in the same time actually doable way > to address issue in existing networks deployed today. In those we > can not rely on the fact that all of my peers and peers of my peers > will migrate and deploy either new semantics for partial bit setting > and treatment or introduce some other form of malformation signaling. > > So I would suggest to continue the draft as is and in the same time > start the work on exploring possibilities on better way to signal > the peer if I am at fault or some box few routers down. The real > issue (and perhaps only one) is that the content of the opaque > transitive attribute is unknown to the router not supporting it. > Therefor unless it contains some form of well known per transitive > attribute based checksum it may be difficult to set any flag based > on it's content. > > Cheers, > R. > > >> Hi John and others, >> Happy Easter! maybe a little bit late:) >> Pls see inline... >> -------------------------------------------------- >> From: "John G. Scudder" >> Sent: Thursday, April 09, 2009 11:11 PM >> To: "Dong Jie" >> Cc: "'idr List'" >> Subject: Re: [Idr] Questions on draft-scudder-idr-optional- >> transitive-01 >>> You're right in your analysis of exactly what the Partial bit >>> communicates, and we'll revise the next version of the draft to >>> correct the inaccurate characterization. It would have been more >>> accurate to note that if the Partial bit is *not* set, then the >>> fault *can* be imputed to the direct neighbor. A set Partial bit >>> means that we don't know -- and when we don't know, we have to >>> assume innocence on the part of the direct neighbor. >> But sometime(for whatever reason), if it happens to the direct >> neighbor at fault, then we will mistake to assume that the direct >> neighbour is innocence, and hence to result in route inconsistent >> or any other underlying aftereffects no matter what we drop or >> accept the update with malformed transitive optional attribute. >>> >>> The unfortunate fact is that there is no certain way with optional >>> transitive attributes of determining whether the "at fault" >>> speaker is the direct neighbor or not, >> Actually, without a dedicated flag for judging whether the direct >> neighbor is innocence is the key point. Using the Partial bit for >> judging is somtimes a better than none choice, but as I said above, >> it will bring side effects. >> So, since we want to resolve this malformed transitive optional >> attribute issue, why don't we think out a more downright method? >> IMO, Dong's suggestion in another email may be a good idea, that is >> if the Partial bit has not any essential usage (I have not seen any >> application of it, or someone please educate me), we may change the >> usage of Partial bit to indicate whether a BGP speaker recognizes >> the transitive optional attribute attached on a route, if we can't >> change the usage of the Partial bit, we could assign a new bit(may >> called Check bit)from the reserved bits of attribute for such >> purpose. >>> thus I don't think there should be any other change to the draft >>> -- Partial is admittedly an imperfect heuristic, but it's the >>> best one we have available. The only other supportable >>> alternative I can see is to apply the procedures of the draft to >>> all optional transitives, whether Partial is set or not -- but >>> that option seems even less desirable. >>> >>> Regards, >>> >>> --John >> Best regards, >> Mach Chen >>> >>> On Apr 9, 2009, at 12:09 AM, Dong Jie wrote: >>> >>>> This draft said that optional transitive attributes with Partial >>>> bit set >>>> "have been propagated without being checked by intermediate >>>> routers that do >>>> not recognize the attribute", so if error-handling rules of >>>> RFC4271 is used, >>>> the session that is reset is not associated with the router that >>>> is at >>>> fault. >>>> >>>> But the rules of setting Partial bit are complex and sometimes >>>> may not meet >>>> the condition the draft based on. >>>> >>>> Section 5 of RFC4271 specifies the rules of Partial bit in optional >>>> transitive attributes: >>>> >>>> -"If a path with an unrecognized transitive optional attribute is >>>> accepted >>>> and passed to other BGP peers, then the unrecognized transitive >>>> optional >>>> attribute of that path MUST be passed, along with the path, to >>>> other BGP >>>> peers with the Partial bit in the Attribute Flags octet set to >>>> 1. If a path >>>> with a recognized, transitive optional attribute is accepted and >>>> passed >>>> along to other BGP peers and the Partial bit in the Attribute >>>> Flags octet is >>>> set to 1 by some previous AS, it MUST NOT be set back to 0 by the >>>> current >>>> AS." >>>> >>>> -"New, transitive optional attributes MAY be attached to the path >>>> by the >>>> originator or by any other BGP speaker in the path. If they are >>>> not >>>> attached by the originator, the Partial bit in the Attribute >>>> Flags octet is >>>> set to 1." >>>> >>>> Based on these rules, receiving optional transitive attributes >>>> with partial >>>> bit set does not mean the peering BGP speaker cannot recognize the >>>> attributes and does not check them, because Partial bit can be >>>> set by some >>>> previous BGP speakers, and it MUST NOT be set back to 0. In some >>>> cases, >>>> Partial bit is set by some previous BGP speaker, but the fault >>>> is done by >>>> the peering BGP speaker, then the procedures of RFC4271 SHOULD be >>>> followed. >>>> >>>> In some other cases, Partial bit is set because the attribute is >>>> attached by >>>> some intermediate BGP speaker, and all of the BGP speakers along >>>> the path >>>> can recognize it. Then the procedures of RFC4271 SHOULD also be >>>> followed. >>>> >>>> IMO, Partial bit of optional transitive attribute is not fit for >>>> identifying >>>> whether the fault is done by the peering BGP speaker. It only >>>> indicates that >>>> the optional transitive attribute is *not recognized* or *not >>>> seen* by all >>>> the BGP speakers in the path. >>>> >>>> Best regards, >>>> Jie >>>> >>> >>> _______________________________________________ >>> 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 Dimitri.Papadimitriou@alcatel-lucent.be Tue Apr 14 13:50:29 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 116043A69C4 for ; Tue, 14 Apr 2009 13:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Li39udgR86MP for ; Tue, 14 Apr 2009 13:50:28 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id EB8823A69FA for ; Tue, 14 Apr 2009 13:50:27 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3EKpb91007448; Tue, 14 Apr 2009 22:51:37 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 22:51:36 +0200 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: Tue, 14 Apr 2009 22:51:36 +0200 Message-ID: <00275A5B436CA441900CB10936742A38020B7831@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WGdocument Thread-Index: AcmsiWe7S/jJkEhqTGSkB1MLz3BMbAAGjIagAJq4b7AALO+fUANZP5QgAAUGATA= References: <00275A5B436CA441900CB10936742A3801F86AFB@FRVELSMBS22.ad2.ad.alcatel.com> From: "PAPADIMITRIOU Dimitri" To: "Rex Fernando" , "Yakov Rekhter" , X-OriginalArrivalTime: 14 Apr 2009 20:51:36.0895 (UTC) FILETIME=[CD704CF0:01C9BD42] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WGdocument 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, 14 Apr 2009 20:50:29 -0000 Hi Fernando, Changes address the initial concerns. PS: In your revision, can you please also detail candidate route propagation to an external neighbor so as to clarify processing at the receiving speaker: is the BGP ID value still the tie breaker ?=20 Thanks, -dimitri. > -----Original Message----- > From: Rex Fernando [mailto:rex@juniper.net]=20 > Sent: Tuesday, April 14, 2009 7:45 PM > To: PAPADIMITRIOU Dimitri; Yakov Rekhter; idr@ietf.org > Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt=20 > as IDR WGdocument >=20 >=20 > Hi Dimitri, >=20 > The revised version includes the following changes that you=20 > suggested we make: >=20 > (a) Note the fact that the value carried in the=20 > link-bandwidth extended community does not change with=20 > traffic levels (text added to section 2). >=20 > (b) Clarify the scenarios under which link bandwidth can be=20 > safely deployed (clarified in section 3) >=20 > I've attached the revised draft and the diff. >=20 > Thanks, > - Rex >=20 > | -----Original Message----- > | From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel- > | lucent.be] > | Sent: Saturday, March 28, 2009 10:08 AM > | To: Rex Fernando; Yakov Rekhter; idr@ietf.org > | Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR > | WGdocument > | =20 > | Hi Fernando: > | =20 > | > -----Original Message----- > | > From: Rex Fernando [mailto:rex@juniper.net] > | > Sent: Friday, March 27, 2009 8:57 PM > | > To: PAPADIMITRIOU Dimitri; Yakov Rekhter; idr@ietf.org > | > Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt > | > as IDR WGdocument > | > > | > Hi Dimitri, > | > > | > | The Link Bandwidth Community used to be part of the=20 > BGP Extended > | > | Communities Attribute document (now RFC4360) until it was > | > removed in v09 > | > | after review. At that it was stated that in order to perform > | > | BW-proportional BGP load-balancing, BGP multipath load > | > balancing should > | > | be first documented. Isn't this condition still valid in > | > the present > | > | case and the corr.mechanisms to be documented beyond > | > limited deployment > | > | consideration part of Section 3? > | > > | > The draft lists the cases (although not in so many words) > | > where link bandwidth can be safely deployed i.e. when the > | > candidate paths are identical until the IGP distance step in > | > path selection or you have a tunneled network. Either of > | > these would ensure loop freedom. And that's all there is to it. > | > > | > We'll be happy to omit the word "multipath" from the draft > | > since it lacks prior definition and expand on the deployment > | > scenarios a bit if you feel strongly about it. > | =20 > | I think we have first to agree on the definition of "link=20 > bandwidth" > | =20 > | - either consider the link bandwidth as the "nominal link capacity" > | which is thus a fixed and configured value (equivalent to=20 > link cost) > | that does not result in variability in the multipath=20 > selection process > | at the border router (PE1 in the slide material) beside=20 > local policy > | decision. this would lead to a control-driven usage of=20 > this attribute. > | =20 > | - or consider the link bandwidth as the "available link=20 > bandwidth" aka > | "residual capacity" which thus leaves possibility for varying the > | multipath selection process over time depending on the=20 > actual value of > | this attribute. this would lead to a traffic-driven usage of this > | attribute. > | =20 > | I would be advisable that you clarify on this point to see how to > | consider Section 3 statement: > | =20 > | "The usage of this community is restricted to the cases where BGP > | multipath can be safely deployed." > | =20 > | Thanks, > | -dimitri. > | =20 > | > - Rex > | > > | > >=20 From robert@raszuk.net Tue Apr 14 14:01:52 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 A9B5F28C20A for ; Tue, 14 Apr 2009 14:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 D9eT6Diwf62t for ; Tue, 14 Apr 2009 14:01:51 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 88BE228C212 for ; Tue, 14 Apr 2009 14:01:51 -0700 (PDT) Received: (qmail 3989 invoked by uid 399); 14 Apr 2009 21:03:02 -0000 Received: from unknown (HELO ?192.168.1.52?) (83.24.23.183) by mail37.opentransfer.com with SMTP; 14 Apr 2009 21:03:02 -0000 Message-ID: <49E4FA02.90209@raszuk.net> Date: Tue, 14 Apr 2009 14:02:58 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri References: <00275A5B436CA441900CB10936742A3801F86AFB@FRVELSMBS22.ad2.ad.alcatel.com> <00275A5B436CA441900CB10936742A38020B7831@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A38020B7831@FRVELSMBS22.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WGdocument X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 21:01:52 -0000 Hi Dimitri, > PS: In your revision, can you please also detail candidate route > propagation to an external neighbor so as to clarify processing at the > receiving speaker: is the BGP ID value still the tie breaker ? Can you elaborate how this draft in discussion here is at all related to the above ? Perhaps this is not spelled out clearly in the draft, but this draft does not modify or have any influence on the bgp best path selection. It only enters into the play where multipath candidates are already selected in the normal multipath check rules. If anything only multipath selection rules are relaxed implicitly by this draft in the specific cases of edge to egde tunneling/label switching. Cheers, R. > Hi Fernando, > > Changes address the initial concerns. > > PS: In your revision, can you please also detail candidate route > propagation to an external neighbor so as to clarify processing at the > receiving speaker: is the BGP ID value still the tie breaker ? > > Thanks, > -dimitri. > >> -----Original Message----- >> From: Rex Fernando [mailto:rex@juniper.net] >> Sent: Tuesday, April 14, 2009 7:45 PM >> To: PAPADIMITRIOU Dimitri; Yakov Rekhter; idr@ietf.org >> Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt >> as IDR WGdocument >> >> >> Hi Dimitri, >> >> The revised version includes the following changes that you >> suggested we make: >> >> (a) Note the fact that the value carried in the >> link-bandwidth extended community does not change with >> traffic levels (text added to section 2). >> >> (b) Clarify the scenarios under which link bandwidth can be >> safely deployed (clarified in section 3) >> >> I've attached the revised draft and the diff. >> >> Thanks, >> - Rex >> >> | -----Original Message----- >> | From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel- >> | lucent.be] >> | Sent: Saturday, March 28, 2009 10:08 AM >> | To: Rex Fernando; Yakov Rekhter; idr@ietf.org >> | Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR >> | WGdocument >> | >> | Hi Fernando: >> | >> | > -----Original Message----- >> | > From: Rex Fernando [mailto:rex@juniper.net] >> | > Sent: Friday, March 27, 2009 8:57 PM >> | > To: PAPADIMITRIOU Dimitri; Yakov Rekhter; idr@ietf.org >> | > Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt >> | > as IDR WGdocument >> | > >> | > Hi Dimitri, >> | > >> | > | The Link Bandwidth Community used to be part of the >> BGP Extended >> | > | Communities Attribute document (now RFC4360) until it was >> | > removed in v09 >> | > | after review. At that it was stated that in order to perform >> | > | BW-proportional BGP load-balancing, BGP multipath load >> | > balancing should >> | > | be first documented. Isn't this condition still valid in >> | > the present >> | > | case and the corr.mechanisms to be documented beyond >> | > limited deployment >> | > | consideration part of Section 3? >> | > >> | > The draft lists the cases (although not in so many words) >> | > where link bandwidth can be safely deployed i.e. when the >> | > candidate paths are identical until the IGP distance step in >> | > path selection or you have a tunneled network. Either of >> | > these would ensure loop freedom. And that's all there is to it. >> | > >> | > We'll be happy to omit the word "multipath" from the draft >> | > since it lacks prior definition and expand on the deployment >> | > scenarios a bit if you feel strongly about it. >> | >> | I think we have first to agree on the definition of "link >> bandwidth" >> | >> | - either consider the link bandwidth as the "nominal link capacity" >> | which is thus a fixed and configured value (equivalent to >> link cost) >> | that does not result in variability in the multipath >> selection process >> | at the border router (PE1 in the slide material) beside >> local policy >> | decision. this would lead to a control-driven usage of >> this attribute. >> | >> | - or consider the link bandwidth as the "available link >> bandwidth" aka >> | "residual capacity" which thus leaves possibility for varying the >> | multipath selection process over time depending on the >> actual value of >> | this attribute. this would lead to a traffic-driven usage of this >> | attribute. >> | >> | I would be advisable that you clarify on this point to see how to >> | consider Section 3 statement: >> | >> | "The usage of this community is restricted to the cases where BGP >> | multipath can be safely deployed." >> | >> | Thanks, >> | -dimitri. >> | >> | > - Rex >> | > >> | > >> > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From Dimitri.Papadimitriou@alcatel-lucent.be Tue Apr 14 15:32:10 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 CB0213A6A3A for ; Tue, 14 Apr 2009 15:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.092 X-Spam-Level: X-Spam-Status: No, score=-6.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 0dBTVmWKzo8k for ; Tue, 14 Apr 2009 15:32:09 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 790D53A686A for ; Tue, 14 Apr 2009 15:32:09 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3EMXJSx009563; Wed, 15 Apr 2009 00:33:19 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 00:33:19 +0200 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: Wed, 15 Apr 2009 00:33:18 +0200 Message-ID: <00275A5B436CA441900CB10936742A38020B7835@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <49E4FA02.90209@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WGdocument Thread-Index: Acm9RGihJXOStW0DTyaKnegGCU/9vQAAVwjA References: <00275A5B436CA441900CB10936742A3801F86AFB@FRVELSMBS22.ad2.ad.alcatel.com> <00275A5B436CA441900CB10936742A38020B7831@FRVELSMBS22.ad2.ad.alcatel.com> <49E4FA02.90209@raszuk.net> From: "PAPADIMITRIOU Dimitri" To: X-OriginalArrivalTime: 14 Apr 2009 22:33:19.0529 (UTC) FILETIME=[02E45990:01C9BD51] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WGdocument 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, 14 Apr 2009 22:32:10 -0000 =20 Hi Robert, > -----Original Message----- > From: Robert Raszuk [mailto:robert@raszuk.net]=20 > Sent: Tuesday, April 14, 2009 11:03 PM > To: PAPADIMITRIOU Dimitri > Cc: Rex Fernando; Yakov Rekhter; idr@ietf.org > Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt=20 > as IDR WGdocument >=20 > Hi Dimitri, >=20 > > PS: In your revision, can you please also detail candidate route > > propagation to an external neighbor so as to clarify=20 > processing at the > > receiving speaker: is the BGP ID value still the tie breaker ? >=20 > Can you elaborate how this draft in discussion here is at all=20 > related to the above ? >=20 The document suggests:=20 "When a BGP speaker receives multiple paths from its internal peers, it could select more than one path to send traffic to.=20 [...] The first scenario is when the candidate paths are identical until and including the IGP distance step in the BGP decision process."=20 On the other hand, per 9.1.2.2 (4271) a speaker "selects" only one of these routes for inclusion in the associated Loc-RIB (reaching point f the BGP ID tie breaker and subsequent applies). > Perhaps this is not spelled out clearly in the draft, but this draft=20 > does not modify or have any influence on the bgp best path selection. > > It only enters into the play where multipath candidates are already=20 > selected in the normal multipath check rules.=20 > If anything only multipath=20 > selection rules are relaxed implicitly by this draft in the specific=20 > cases of edge to egde tunneling/label switching. Wouldn't it be worth clarifying this "implicit relaxation" of the selection rule (as a protocol specifies messages/format but also procedures) ?=20 =20 Thanks for clarifying, -dimitri. > Cheers, > R. >=20 >=20 > > Hi Fernando, > >=20 > > Changes address the initial concerns. > >=20 > > PS: In your revision, can you please also detail candidate route > > propagation to an external neighbor so as to clarify=20 > processing at the > > receiving speaker: is the BGP ID value still the tie breaker ?=20 > >=20 > > Thanks, > > -dimitri. > >=20 > >> -----Original Message----- > >> From: Rex Fernando [mailto:rex@juniper.net]=20 > >> Sent: Tuesday, April 14, 2009 7:45 PM > >> To: PAPADIMITRIOU Dimitri; Yakov Rekhter; idr@ietf.org > >> Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt=20 > >> as IDR WGdocument > >> > >> > >> Hi Dimitri, > >> > >> The revised version includes the following changes that you=20 > >> suggested we make: > >> > >> (a) Note the fact that the value carried in the=20 > >> link-bandwidth extended community does not change with=20 > >> traffic levels (text added to section 2). > >> > >> (b) Clarify the scenarios under which link bandwidth can be=20 > >> safely deployed (clarified in section 3) > >> > >> I've attached the revised draft and the diff. > >> > >> Thanks, > >> - Rex > >> > >> | -----Original Message----- > >> | From: PAPADIMITRIOU Dimitri=20 > [mailto:Dimitri.Papadimitriou@alcatel- > >> | lucent.be] > >> | Sent: Saturday, March 28, 2009 10:08 AM > >> | To: Rex Fernando; Yakov Rekhter; idr@ietf.org > >> | Subject: RE: [Idr]=20 > draft-rfernando-idr-link-bandwidth-00.txt as IDR > >> | WGdocument > >> | =20 > >> | Hi Fernando: > >> | =20 > >> | > -----Original Message----- > >> | > From: Rex Fernando [mailto:rex@juniper.net] > >> | > Sent: Friday, March 27, 2009 8:57 PM > >> | > To: PAPADIMITRIOU Dimitri; Yakov Rekhter; idr@ietf.org > >> | > Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt > >> | > as IDR WGdocument > >> | > > >> | > Hi Dimitri, > >> | > > >> | > | The Link Bandwidth Community used to be part of the=20 > >> BGP Extended > >> | > | Communities Attribute document (now RFC4360) until it was > >> | > removed in v09 > >> | > | after review. At that it was stated that in order=20 > to perform > >> | > | BW-proportional BGP load-balancing, BGP multipath load > >> | > balancing should > >> | > | be first documented. Isn't this condition still valid in > >> | > the present > >> | > | case and the corr.mechanisms to be documented beyond > >> | > limited deployment > >> | > | consideration part of Section 3? > >> | > > >> | > The draft lists the cases (although not in so many words) > >> | > where link bandwidth can be safely deployed i.e. when the > >> | > candidate paths are identical until the IGP distance step in > >> | > path selection or you have a tunneled network. Either of > >> | > these would ensure loop freedom. And that's all there=20 > is to it. > >> | > > >> | > We'll be happy to omit the word "multipath" from the draft > >> | > since it lacks prior definition and expand on the deployment > >> | > scenarios a bit if you feel strongly about it. > >> | =20 > >> | I think we have first to agree on the definition of "link=20 > >> bandwidth" > >> | =20 > >> | - either consider the link bandwidth as the "nominal=20 > link capacity" > >> | which is thus a fixed and configured value (equivalent to=20 > >> link cost) > >> | that does not result in variability in the multipath=20 > >> selection process > >> | at the border router (PE1 in the slide material) beside=20 > >> local policy > >> | decision. this would lead to a control-driven usage of=20 > >> this attribute. > >> | =20 > >> | - or consider the link bandwidth as the "available link=20 > >> bandwidth" aka > >> | "residual capacity" which thus leaves possibility for=20 > varying the > >> | multipath selection process over time depending on the=20 > >> actual value of > >> | this attribute. this would lead to a traffic-driven=20 > usage of this > >> | attribute. > >> | =20 > >> | I would be advisable that you clarify on this point to=20 > see how to > >> | consider Section 3 statement: > >> | =20 > >> | "The usage of this community is restricted to the cases=20 > where BGP > >> | multipath can be safely deployed." > >> | =20 > >> | Thanks, > >> | -dimitri. > >> | =20 > >> | > - Rex > >> | > > >> | > > >> > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr > >=20 > >=20 >=20 >=20 From robert@raszuk.net Tue Apr 14 15:43:59 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 2974A3A688A for ; Tue, 14 Apr 2009 15:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 TO9lorVjG1Cw for ; Tue, 14 Apr 2009 15:43:58 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 4D58E3A6820 for ; Tue, 14 Apr 2009 15:43:58 -0700 (PDT) Received: (qmail 18672 invoked by uid 399); 14 Apr 2009 22:45:09 -0000 Received: from unknown (HELO ?192.168.1.52?) (83.24.23.183) by mail37.opentransfer.com with SMTP; 14 Apr 2009 22:45:09 -0000 Message-ID: <49E511F3.4010706@raszuk.net> Date: Tue, 14 Apr 2009 15:45:07 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri References: <00275A5B436CA441900CB10936742A3801F86AFB@FRVELSMBS22.ad2.ad.alcatel.com> <00275A5B436CA441900CB10936742A38020B7831@FRVELSMBS22.ad2.ad.alcatel.com> <49E4FA02.90209@raszuk.net> <00275A5B436CA441900CB10936742A38020B7835@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A38020B7835@FRVELSMBS22.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WGdocument X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 22:43:59 -0000 Hi Dimitir, > The document suggests: > > "When a BGP speaker receives multiple paths from its internal peers, it > could select more than one path to send traffic to. > > [...] > > The first scenario is when the candidate paths are identical until and > including the IGP distance step in the BGP decision process." > > On the other hand, per 9.1.2.2 (4271) a speaker "selects" only one of > these routes for inclusion in the associated Loc-RIB (reaching point f > the BGP ID tie breaker and subsequent applies). Well I see your point. 4271 does not talk about multipath. And neither this draft :) This draft just enhances the multipath. The multipath alone as local box implementation matter may have not been spec-ed out as such. This is the point you are perhaps questioning. If you are correct. The draft enhancing "multipath" should either define what it is or bring the reference to other document defining it. And such definition does not need to be a poem. It will just suffice to include one paragraph on what makes a path a multipath candidate and what are the exceptions if you have tunneled core deployed. > Wouldn't it be worth clarifying this "implicit relaxation" of the > selection rule (as a protocol specifies messages/format but also > procedures) ? Agreed. That would/should be part of general multipath definition. Cheers, R. From mach@huawei.com Tue Apr 14 21:58: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 ED13D3A68DA for ; Tue, 14 Apr 2009 21:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.656 X-Spam-Level: *** X-Spam-Status: No, score=3.656 tagged_above=-999 required=5 tests=[AWL=2.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6, RDNS_NONE=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 whPcPKoUPHHQ for ; Tue, 14 Apr 2009 21:58:30 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4E5F43A6891 for ; Tue, 14 Apr 2009 21:58:30 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI400B27LV4YM@szxga04-in.huawei.com> for idr@ietf.org; Wed, 15 Apr 2009 12:59:28 +0800 (CST) Received: from m55527c ([10.111.12.135]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI400EP3LV2HN@szxga04-in.huawei.com> for idr@ietf.org; Wed, 15 Apr 2009 12:59:28 +0800 (CST) Date: Wed, 15 Apr 2009 12:59:25 +0800 From: Mach Chen In-reply-to: <49E4CEE0.8020607@raszuk.net> To: robert@raszuk.net Message-id: <4CCE9382D2D44813926C747690B60CC8@m55527c> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <004201c9b8c8$ff727170$610c6f0a@china.huawei.com> <49E4CEE0.8020607@raszuk.net> Cc: 'idr List' Subject: Re: [Idr] Questions on draft-scudder-idr-optional-transitive-01 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, 15 Apr 2009 04:58:32 -0000 Hi Robert, > Hi Mach & Dong, > > I think your suggestion for better way to determine the router at fault is > very valuable and would indeed be very helpful. Thanks! > > But in my opinion what this draft focuses on is the least expensive and as > safe as possible while in the same time actually doable way to address > issue in existing networks deployed today. In those we can not rely on the > fact that all of my peers and peers of my peers will migrate and deploy > either new semantics for partial bit setting and treatment or introduce > some other form of malformation signaling. As to deployment aspect, I fully agree with you, require all BGP routers to support a new function is not realistic. But back to the new semantics of partial bit, if we could change it (assume no existing application uses it) to relect the status whether the direct neighbor saw and understood an attribute received from its peer(s), then based on the partial bit, a BGP router can use the rules defined in this optional-transitive draft to accurately judge whether a direct neighbor is at fault. This will not require that all routers MUST support it, the at worst situation (on one supports it) is same as current, but if a router support it, someone will benefit. > > So I would suggest to continue the draft as is and in the same time start > the work on exploring possibilities on better way to signal the peer if I > am at fault or some box few routers down. I do not object to continue the draft as is, I just want to discuss more about it before we implement it. If the WG think that it is worth to find a better way, maybe we could work on it and write a new draft. > The real issue (and perhaps only one) is that the content of the opaque > transitive attribute is unknown to the router not supporting it. Therefor > unless it contains some form of well known per transitive attribute based > checksum it may be difficult to set any flag based on it's content. IMO, it will not be so complex like that. A BGP speaker SHOULD guarantee that the information (info originated from itself, info received from its peer and it see and understand) will be sent to its peer(s) MUST be correct. So, if a router does not know an received attribute, just setting the flag to tell its peer(s) that I do not know it and I should not answer for it. Of cause, that will be different if someone wants to locate the right point where is at fault. Best regards, Mach Chen > > Cheers, > R. > > >> Hi John and others, >> >> Happy Easter! maybe a little bit late:) >> >> Pls see inline... >> >> -------------------------------------------------- >> From: "John G. Scudder" >> Sent: Thursday, April 09, 2009 11:11 PM >> To: "Dong Jie" >> Cc: "'idr List'" >> Subject: Re: [Idr] Questions on draft-scudder-idr-optional-transitive-01 >> >>> You're right in your analysis of exactly what the Partial bit >>> communicates, and we'll revise the next version of the draft to correct >>> the inaccurate characterization. It would have been more accurate to >>> note that if the Partial bit is *not* set, then the fault *can* be >>> imputed to the direct neighbor. A set Partial bit means that we don't >>> know -- and when we don't know, we have to assume innocence on the part >>> of the direct neighbor. >> >> But sometime(for whatever reason), if it happens to the direct neighbor >> at fault, then we will mistake to assume that the direct neighbour is >> innocence, and hence to result in route inconsistent or any other >> underlying aftereffects no matter what we drop or accept the update with >> malformed transitive optional attribute. >> >>> >>> The unfortunate fact is that there is no certain way with optional >>> transitive attributes of determining whether the "at fault" speaker is >>> the direct neighbor or not, >> >> Actually, without a dedicated flag for judging whether the direct >> neighbor is innocence is the key point. Using the Partial bit for judging >> is somtimes a better than none choice, but as I said above, it will bring >> side effects. >> >> So, since we want to resolve this malformed transitive optional attribute >> issue, why don't we think out a more downright method? >> >> IMO, Dong's suggestion in another email may be a good idea, that is if >> the Partial bit has not any essential usage (I have not seen any >> application of it, or someone please educate me), we may change the usage >> of Partial bit to indicate whether a BGP speaker recognizes the >> transitive optional attribute attached on a route, if we can't change the >> usage of the Partial bit, we could assign a new bit(may called Check >> bit)from the reserved bits of attribute for such purpose. >> >>> thus I don't think there should be any other change to the draft -- >>> Partial is admittedly an imperfect heuristic, but it's the best one we >>> have available. The only other supportable alternative I can see is to >>> apply the procedures of the draft to all optional transitives, whether >>> Partial is set or not -- but that option seems even less desirable. >>> >>> Regards, >>> >>> --John >> >> >> Best regards, >> Mach Chen >> >> >>> >>> On Apr 9, 2009, at 12:09 AM, Dong Jie wrote: >>> >>>> This draft said that optional transitive attributes with Partial bit >>>> set >>>> "have been propagated without being checked by intermediate routers >>>> that do >>>> not recognize the attribute", so if error-handling rules of RFC4271 is >>>> used, >>>> the session that is reset is not associated with the router that is at >>>> fault. >>>> >>>> But the rules of setting Partial bit are complex and sometimes may not >>>> meet >>>> the condition the draft based on. >>>> >>>> Section 5 of RFC4271 specifies the rules of Partial bit in optional >>>> transitive attributes: >>>> >>>> -"If a path with an unrecognized transitive optional attribute is >>>> accepted >>>> and passed to other BGP peers, then the unrecognized transitive >>>> optional >>>> attribute of that path MUST be passed, along with the path, to other >>>> BGP >>>> peers with the Partial bit in the Attribute Flags octet set to 1. If >>>> a path >>>> with a recognized, transitive optional attribute is accepted and >>>> passed >>>> along to other BGP peers and the Partial bit in the Attribute Flags >>>> octet is >>>> set to 1 by some previous AS, it MUST NOT be set back to 0 by the >>>> current >>>> AS." >>>> >>>> -"New, transitive optional attributes MAY be attached to the path by >>>> the >>>> originator or by any other BGP speaker in the path. If they are not >>>> attached by the originator, the Partial bit in the Attribute Flags >>>> octet is >>>> set to 1." >>>> >>>> Based on these rules, receiving optional transitive attributes with >>>> partial >>>> bit set does not mean the peering BGP speaker cannot recognize the >>>> attributes and does not check them, because Partial bit can be set by >>>> some >>>> previous BGP speakers, and it MUST NOT be set back to 0. In some >>>> cases, >>>> Partial bit is set by some previous BGP speaker, but the fault is done >>>> by >>>> the peering BGP speaker, then the procedures of RFC4271 SHOULD be >>>> followed. >>>> >>>> In some other cases, Partial bit is set because the attribute is >>>> attached by >>>> some intermediate BGP speaker, and all of the BGP speakers along the >>>> path >>>> can recognize it. Then the procedures of RFC4271 SHOULD also be >>>> followed. >>>> >>>> IMO, Partial bit of optional transitive attribute is not fit for >>>> identifying >>>> whether the fault is done by the peering BGP speaker. It only >>>> indicates that >>>> the optional transitive attribute is *not recognized* or *not seen* by >>>> all >>>> the BGP speakers in the path. >>>> >>>> Best regards, >>>> Jie >>>> >>> >>> _______________________________________________ >>> 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 mach@huawei.com Tue Apr 14 21:58:32 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 71F403A6891 for ; Tue, 14 Apr 2009 21:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.068 X-Spam-Level: *** X-Spam-Status: No, score=3.068 tagged_above=-999 required=5 tests=[AWL=1.763, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6, RDNS_NONE=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 ybq-stRRQnvK for ; Tue, 14 Apr 2009 21:58:31 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2C6FE3A6896 for ; Tue, 14 Apr 2009 21:58:31 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI400398LV6OH@szxga04-in.huawei.com> for idr@ietf.org; Wed, 15 Apr 2009 12:59:30 +0800 (CST) Received: from m55527c ([10.111.12.135]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI400B0ILV5RX@szxga04-in.huawei.com> for idr@ietf.org; Wed, 15 Apr 2009 12:59:30 +0800 (CST) Date: Wed, 15 Apr 2009 12:59:28 +0800 From: Mach Chen In-reply-to: <613C4A5B-3A8B-47F5-BE0B-D918BCA4543E@juniper.net> To: "John G. Scudder" , Robert Raszuk , Dong Jie Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <004201c9b8c8$ff727170$610c6f0a@china.huawei.com> <49E4CEE0.8020607@raszuk.net> <613C4A5B-3A8B-47F5-BE0B-D918BCA4543E@juniper.net> Cc: idr List Subject: Re: [Idr] Questions on draft-scudder-idr-optional-transitive-01 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, 15 Apr 2009 04:58:32 -0000 Hi John, > Folks, > > I think Robert expresses it well when he points out that an important > goal of the draft is to be deployable in current networks. It is > important that it not rely on the collaboration of peers in order to > be deployed, thus the current flags and their semantics are a given. I got it. > > IMO it would be a fine idea to start a separate conversation on the > suggestion to change the semantics of Partial or standardize a new flag. OK. Best regards, Mach > > Regards, > > --John > > P.S.: It could also be early to wish a Happy Easter if you're > following the Orthodox calendar. :-) > > On Apr 14, 2009, at 1:58 PM, Robert Raszuk wrote: > >> Hi Mach & Dong, >> >> I think your suggestion for better way to determine the router at >> fault is very valuable and would indeed be very helpful. >> >> But in my opinion what this draft focuses on is the least expensive >> and as safe as possible while in the same time actually doable way >> to address issue in existing networks deployed today. In those we >> can not rely on the fact that all of my peers and peers of my peers >> will migrate and deploy either new semantics for partial bit setting >> and treatment or introduce some other form of malformation signaling. >> >> So I would suggest to continue the draft as is and in the same time >> start the work on exploring possibilities on better way to signal >> the peer if I am at fault or some box few routers down. The real >> issue (and perhaps only one) is that the content of the opaque >> transitive attribute is unknown to the router not supporting it. >> Therefor unless it contains some form of well known per transitive >> attribute based checksum it may be difficult to set any flag based >> on it's content. >> >> Cheers, >> R. >> >> >>> Hi John and others, >>> Happy Easter! maybe a little bit late:) >>> Pls see inline... >>> -------------------------------------------------- >>> From: "John G. Scudder" >>> Sent: Thursday, April 09, 2009 11:11 PM >>> To: "Dong Jie" >>> Cc: "'idr List'" >>> Subject: Re: [Idr] Questions on draft-scudder-idr-optional- >>> transitive-01 >>>> You're right in your analysis of exactly what the Partial bit >>>> communicates, and we'll revise the next version of the draft to >>>> correct the inaccurate characterization. It would have been more >>>> accurate to note that if the Partial bit is *not* set, then the >>>> fault *can* be imputed to the direct neighbor. A set Partial bit >>>> means that we don't know -- and when we don't know, we have to >>>> assume innocence on the part of the direct neighbor. >>> But sometime(for whatever reason), if it happens to the direct >>> neighbor at fault, then we will mistake to assume that the direct >>> neighbour is innocence, and hence to result in route inconsistent >>> or any other underlying aftereffects no matter what we drop or >>> accept the update with malformed transitive optional attribute. >>>> >>>> The unfortunate fact is that there is no certain way with optional >>>> transitive attributes of determining whether the "at fault" >>>> speaker is the direct neighbor or not, >>> Actually, without a dedicated flag for judging whether the direct >>> neighbor is innocence is the key point. Using the Partial bit for >>> judging is somtimes a better than none choice, but as I said above, >>> it will bring side effects. >>> So, since we want to resolve this malformed transitive optional >>> attribute issue, why don't we think out a more downright method? >>> IMO, Dong's suggestion in another email may be a good idea, that is >>> if the Partial bit has not any essential usage (I have not seen any >>> application of it, or someone please educate me), we may change the >>> usage of Partial bit to indicate whether a BGP speaker recognizes >>> the transitive optional attribute attached on a route, if we can't >>> change the usage of the Partial bit, we could assign a new bit(may >>> called Check bit)from the reserved bits of attribute for such >>> purpose. >>>> thus I don't think there should be any other change to the draft >>>> -- Partial is admittedly an imperfect heuristic, but it's the >>>> best one we have available. The only other supportable >>>> alternative I can see is to apply the procedures of the draft to >>>> all optional transitives, whether Partial is set or not -- but >>>> that option seems even less desirable. >>>> >>>> Regards, >>>> >>>> --John >>> Best regards, >>> Mach Chen >>>> >>>> On Apr 9, 2009, at 12:09 AM, Dong Jie wrote: >>>> >>>>> This draft said that optional transitive attributes with Partial >>>>> bit set >>>>> "have been propagated without being checked by intermediate >>>>> routers that do >>>>> not recognize the attribute", so if error-handling rules of >>>>> RFC4271 is used, >>>>> the session that is reset is not associated with the router that >>>>> is at >>>>> fault. >>>>> >>>>> But the rules of setting Partial bit are complex and sometimes >>>>> may not meet >>>>> the condition the draft based on. >>>>> >>>>> Section 5 of RFC4271 specifies the rules of Partial bit in optional >>>>> transitive attributes: >>>>> >>>>> -"If a path with an unrecognized transitive optional attribute is >>>>> accepted >>>>> and passed to other BGP peers, then the unrecognized transitive >>>>> optional >>>>> attribute of that path MUST be passed, along with the path, to >>>>> other BGP >>>>> peers with the Partial bit in the Attribute Flags octet set to >>>>> 1. If a path >>>>> with a recognized, transitive optional attribute is accepted and >>>>> passed >>>>> along to other BGP peers and the Partial bit in the Attribute >>>>> Flags octet is >>>>> set to 1 by some previous AS, it MUST NOT be set back to 0 by the >>>>> current >>>>> AS." >>>>> >>>>> -"New, transitive optional attributes MAY be attached to the path >>>>> by the >>>>> originator or by any other BGP speaker in the path. If they are >>>>> not >>>>> attached by the originator, the Partial bit in the Attribute >>>>> Flags octet is >>>>> set to 1." >>>>> >>>>> Based on these rules, receiving optional transitive attributes >>>>> with partial >>>>> bit set does not mean the peering BGP speaker cannot recognize the >>>>> attributes and does not check them, because Partial bit can be >>>>> set by some >>>>> previous BGP speakers, and it MUST NOT be set back to 0. In some >>>>> cases, >>>>> Partial bit is set by some previous BGP speaker, but the fault >>>>> is done by >>>>> the peering BGP speaker, then the procedures of RFC4271 SHOULD be >>>>> followed. >>>>> >>>>> In some other cases, Partial bit is set because the attribute is >>>>> attached by >>>>> some intermediate BGP speaker, and all of the BGP speakers along >>>>> the path >>>>> can recognize it. Then the procedures of RFC4271 SHOULD also be >>>>> followed. >>>>> >>>>> IMO, Partial bit of optional transitive attribute is not fit for >>>>> identifying >>>>> whether the fault is done by the peering BGP speaker. It only >>>>> indicates that >>>>> the optional transitive attribute is *not recognized* or *not >>>>> seen* by all >>>>> the BGP speakers in the path. >>>>> >>>>> Best regards, >>>>> Jie >>>>> >>>> >>>> _______________________________________________ >>>> 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 paul@jakma.org Wed Apr 15 06:55: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 C82313A6E31 for ; Wed, 15 Apr 2009 06:55:28 -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 M3U7piQdTXeb for ; Wed, 15 Apr 2009 06:55:28 -0700 (PDT) Received: from hibernia.jakma.org (cl-9.dub-01.ie.sixxs.net [IPv6:2001:770:100:8::2]) by core3.amsl.com (Postfix) with ESMTP id 828433A6C0B for ; Wed, 15 Apr 2009 06:55:27 -0700 (PDT) Received: from melandri.gla.jakma.org (IDENT:U2FsdGVkX19d1ASu1bkCy/n0DuYbYwDV6gqWtu/yisY@melandri.jakma.org [81.168.24.37]) (authenticated bits=0) by hibernia.jakma.org (8.14.3/8.14.2) with ESMTP id n3FDuRIS008057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 14:56:36 +0100 Date: Wed, 15 Apr 2009 14:56:26 +0100 (BST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: "John G. Scudder" In-Reply-To: <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> Message-ID: References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.1.1 (hibernia.jakma.org [212.17.55.49]); Wed, 15 Apr 2009 14:56:36 +0100 (IST) Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive 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, 15 Apr 2009 13:55:28 -0000 Hi, I have a question nagging me, possibly just philosophical. The text (of 01) says: "In the case of an optional transitive attribute which has no effect on route selection or installation, the malformed attribute MAY instead be discarded and the UPDATE message continue to be processed. " my question is, to what extent (if any) can a speaker simply assume that any Partial-bit attribute automatically "has no effect on route selection". I.e. an optional attribute by definition contains either optional data unrelated to route-selection, or else information that supplements route-selection while still allowing speakers to make safe (if perhaps sub-optimal) route selections if they ignore that attribute. Right? If so, why isn't the correct behaviour for a speaker that recognises a partial, optional attribute as malformed to simply fallback to the same behaviour as a BGP speaker that doesn't recognise the attribute? I.e. can we reduce the numbers of possible different classes of behaviours from: 1. speakers that don't recognise the attribute - speakers that recognise and attribute is: 2. well-formed 3. malformed, error behaviour attribute specific to: 1. speakers that don't recognise the attribute 2. speakers that recognise the attribute (well-formed being implied) + Generalised error behaviour for optional attrs on input processing: if partial: discard else: notify ?? I'm probably tilting at windmills as usual, but is there perhaps some value to trying to generalise things a bit more and reduce the number of attribute-specific behaviours? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: I never liked you, and I always will. -Samuel Goldwyn From paul@jakma.org Wed Apr 15 07:02:16 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 033623A6E7A for ; Wed, 15 Apr 2009 07:02:16 -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 ZnMtFkoUx0Z8 for ; Wed, 15 Apr 2009 07:02:15 -0700 (PDT) Received: from hibernia.jakma.org (cl-9.dub-01.ie.sixxs.net [IPv6:2001:770:100:8::2]) by core3.amsl.com (Postfix) with ESMTP id 798FC28C1F8 for ; Wed, 15 Apr 2009 07:01:50 -0700 (PDT) Received: from melandri.gla.jakma.org (IDENT:U2FsdGVkX19vIVfLhD49NJoUMMjNaS+C41l+M034fRY@melandri.jakma.org [81.168.24.37]) (authenticated bits=0) by hibernia.jakma.org (8.14.3/8.14.2) with ESMTP id n3FE2rht008186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 15:03:00 +0100 Date: Wed, 15 Apr 2009 15:02:52 +0100 (BST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: "John G. Scudder" In-Reply-To: Message-ID: References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.1.1 (hibernia.jakma.org [212.17.55.49]); Wed, 15 Apr 2009 15:03:00 +0100 (IST) Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive 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, 15 Apr 2009 14:02:16 -0000 Oh.. The point being, that much thought will have gone into the backward-compatibility issues for new attributes, so why not re-use that effort by having the error-case be fallback to that compatibility mode (a deployment that should see much more testing and use than error-cases)? --paulj On Wed, 15 Apr 2009, Paul Jakma wrote: > Hi, > > I have a question nagging me, possibly just philosophical. The text (of 01) > says: > > "In the case of an optional transitive attribute which has no > effect on route > selection or installation, the malformed attribute MAY instead be > discarded and the UPDATE message continue to be processed. " > > my question is, to what extent (if any) can a speaker simply assume that any > Partial-bit attribute automatically "has no effect on route selection". > > I.e. an optional attribute by definition contains either optional data > unrelated to route-selection, or else information that supplements > route-selection while still allowing speakers to make safe (if perhaps > sub-optimal) route selections if they ignore that attribute. > > Right? > > If so, why isn't the correct behaviour for a speaker that recognises a > partial, optional attribute as malformed to simply fallback to the same > behaviour as a BGP speaker that doesn't recognise the attribute? > > I.e. can we reduce the numbers of possible different classes of behaviours > from: > > 1. speakers that don't recognise the attribute > - speakers that recognise and attribute is: > 2. well-formed > 3. malformed, error behaviour attribute specific > > to: > > 1. speakers that don't recognise the attribute > 2. speakers that recognise the attribute (well-formed being implied) > > + > > Generalised error behaviour for optional attrs on input processing: > if partial: discard > else: notify > > ?? > > I'm probably tilting at windmills as usual, but is there perhaps some value > to trying to generalise things a bit more and reduce the number of > attribute-specific behaviours? > > regards, > -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: When you're dining out and you suspect something's wrong, you're probably right. From robert@raszuk.net Wed Apr 15 07:13: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 DB0E228C1E2 for ; Wed, 15 Apr 2009 07:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] 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 sV7gPp3JVcLc for ; Wed, 15 Apr 2009 07:13:23 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 455F628C1D2 for ; Wed, 15 Apr 2009 07:13:23 -0700 (PDT) Received: (qmail 19727 invoked by uid 399); 15 Apr 2009 14:14:33 -0000 Received: from unknown (HELO ?192.168.1.53?) (83.5.242.222) by mail37.opentransfer.com with SMTP; 15 Apr 2009 14:14:33 -0000 Message-ID: <49E5EBC4.8060304@raszuk.net> Date: Wed, 15 Apr 2009 07:14:28 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Paul Jakma References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:13:27 -0000 Hi Paul, > I.e. an optional attribute by definition contains either optional data > unrelated to route-selection, or else information that supplements > route-selection while still allowing speakers to make safe (if perhaps > sub-optimal) route selections if they ignore that attribute. > > Right? Not always ... Let take an example Route Target extended communities attribute in L3VPNs. While those indeed are not part of best path selection in the same time thore are critical to the route importing and therefor propagating updates without them is quite pointless if not harmful. (Harmful case would be when best path is selected for those nets which do not have a valid RTs attached as opposed to those which do). Cheers, R. From paul@jakma.org Wed Apr 15 07:20:14 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 144F128C207 for ; Wed, 15 Apr 2009 07:20:14 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2tOYw+tBavN for ; Wed, 15 Apr 2009 07:20:13 -0700 (PDT) Received: from hibernia.jakma.org (cl-9.dub-01.ie.sixxs.net [IPv6:2001:770:100:8::2]) by core3.amsl.com (Postfix) with ESMTP id E4F4628C178 for ; Wed, 15 Apr 2009 07:20:12 -0700 (PDT) Received: from melandri.gla.jakma.org (IDENT:U2FsdGVkX1/q+IJXYP+62cYK+QC1QGOd3H2hxdPv1e0@melandri.jakma.org [81.168.24.37]) (authenticated bits=0) by hibernia.jakma.org (8.14.3/8.14.2) with ESMTP id n3FELFVS008569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 15:21:22 +0100 Date: Wed, 15 Apr 2009 15:21:15 +0100 (BST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Robert Raszuk In-Reply-To: <49E5EBC4.8060304@raszuk.net> Message-ID: References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <49E5EBC4.8060304@raszuk.net> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.1.1 (hibernia.jakma.org [212.17.55.49]); Wed, 15 Apr 2009 15:21:23 +0100 (IST) Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive 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, 15 Apr 2009 14:20:14 -0000 On Wed, 15 Apr 2009, Robert Raszuk wrote: > While those indeed are not part of best path selection in the same > time thore are critical to the route importing and therefor > propagating updates without them is quite pointless if not harmful. > (Harmful case would be when best path is selected for those nets > which do not have a valid RTs attached as opposed to those which > do). Hmm, so what happens if a route with this attribute transits a speaker that doesn't recognise them? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Photographing a volcano is just about the most miserable thing you can do. -- Robert B. Goodman [Who has clearly never tried to use a PDP-10. Ed.] From robert@raszuk.net Wed Apr 15 07:25:01 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 382E828C222 for ; Wed, 15 Apr 2009 07:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 Yhxl1fabjBXM for ; Wed, 15 Apr 2009 07:25:00 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id 6D9983A69FC for ; Wed, 15 Apr 2009 07:25:00 -0700 (PDT) Received: (qmail 29183 invoked by uid 399); 15 Apr 2009 14:26:12 -0000 Received: from unknown (HELO ?192.168.1.53?) (83.5.242.222) by mail37.opentransfer.com with SMTP; 15 Apr 2009 14:26:12 -0000 Message-ID: <49E5EE81.3010309@raszuk.net> Date: Wed, 15 Apr 2009 07:26:09 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Paul Jakma References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <49E5EBC4.8060304@raszuk.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:25:01 -0000 Paul, In theory it should be fine. Example: RR passing it .. they will get to the other side PE just fine and PE will use them for import. RR does not perform any import action of L3VPN routes, but it does perform best path selection. Cheers, R. > On Wed, 15 Apr 2009, Robert Raszuk wrote: > >> While those indeed are not part of best path selection in the same >> time thore are critical to the route importing and therefor >> propagating updates without them is quite pointless if not harmful. >> (Harmful case would be when best path is selected for those nets which >> do not have a valid RTs attached as opposed to those which do). > > Hmm, so what happens if a route with this attribute transits a speaker > that doesn't recognise them? > > regards, From paul@jakma.org Wed Apr 15 07:57:03 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 D93D43A6E86 for ; Wed, 15 Apr 2009 07:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 hiXB52lsaKW7 for ; Wed, 15 Apr 2009 07:57:03 -0700 (PDT) Received: from hibernia.jakma.org (cl-9.dub-01.ie.sixxs.net [IPv6:2001:770:100:8::2]) by core3.amsl.com (Postfix) with ESMTP id B91793A6E0B for ; Wed, 15 Apr 2009 07:57:02 -0700 (PDT) Received: from melandri.gla.jakma.org (IDENT:U2FsdGVkX19hW5fqOreWU1fXpLlRshvHL8SurG9Oaik@melandri.jakma.org [81.168.24.37]) (authenticated bits=0) by hibernia.jakma.org (8.14.3/8.14.2) with ESMTP id n3FEw476009266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 15:58:12 +0100 Date: Wed, 15 Apr 2009 15:58:03 +0100 (BST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: Robert Raszuk In-Reply-To: <49E5EE81.3010309@raszuk.net> Message-ID: References: <20090301133533.BB8843A68A8@core3.amsl.com> <9DDDE3C1-923E-4B3B-80BC-47B900900040@juniper.net> <49E5EBC4.8060304@raszuk.net> <49E5EE81.3010309@raszuk.net> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.1.1 (hibernia.jakma.org [212.17.55.49]); Wed, 15 Apr 2009 15:58:12 +0100 (IST) Cc: idr List Subject: Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive 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, 15 Apr 2009 14:57:03 -0000 On Wed, 15 Apr 2009, Robert Raszuk wrote: > Paul, > > In theory it should be fine. Example: RR passing it .. they will get to the > other side PE just fine and PE will use them for import. RR does not perform > any import action of L3VPN routes, but it does perform best path selection. So what's the correct action for the receiving PE to take if the extended-community attribute is malformed? What about if it's not present? Some specific technology may have interesting requirements - it can always override general behaviours in its own RFCs. But why can't a general-case BGP RFC just specify fallback for partials? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Thou hast seen nothing yet. -- Miguel de Cervantes From enkechen@cisco.com Wed Apr 15 16:26: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 66FBE3A68DC for ; Wed, 15 Apr 2009 16:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Q1AWCtlIi484 for ; Wed, 15 Apr 2009 16:26:30 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 73B9A3A6846 for ; Wed, 15 Apr 2009 16:26:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,194,1238976000"; d="scan'208";a="153741637" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2009 23:27:43 +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 n3FNRh8l013067; Wed, 15 Apr 2009 16:27:43 -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.13.8) with ESMTP id n3FNRhgj012090; Wed, 15 Apr 2009 23:27:43 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 16:27:42 -0700 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 16:27:42 -0700 Message-ID: <49E66D6E.6090001@cisco.com> Date: Wed, 15 Apr 2009 16:27:42 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: Samita Chakrabarti References: <065b01c9adba$56d5bc20$04813460$@com> In-Reply-To: <065b01c9adba$56d5bc20$04813460$@com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Apr 2009 23:27:42.0595 (UTC) FILETIME=[C63E7530:01C9BE21] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3269; t=1239838063; x=1240702063; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20Clarification=20points=20for=20rfc4893- bis |Sender:=20; bh=5RoL7fnDPq0tLhILolqqkDA9ZawbSxOBxuuN2n9aV5c=; b=OgzJ/Tq8SFzRxnsr34C+N0PGH6rlN7ZuCbrTtAFP5XtStFuPJ7bYqrReTM CTruGPgNkoPiej36c+q7zqjtKX9QeoItN069FPLolHyjFC/CBV4RVE+cjlZg XEkqusc0FM; Authentication-Results: sj-dkim-4; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: idr@ietf.org Subject: Re: [Idr] Clarification points for rfc4893-bis 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, 15 Apr 2009 23:26:31 -0000 Hi, Samita: Thanks for your comments and suggestion. Please see my replies inlined. Samita Chakrabarti wrote: > > Hi Enke, > > This is a follow-up from the idr meeting comments. I’d like to thank > you for your kind consideration in taking into some of the comments > addressed in draft-chakrabarti-idr-rfc4893-mod. > > Here are few cases that I propose to clarify in the next revision of > the rfc4893-bis and I think these will be helpful for new readers and > implementers especially considering the fact that 2byte ASes and 4byte > ASes are going to co-exist for sometime. > > Clarification 1: > > Section 3: “My AS Number” field > > Currently it says: > > " and "We denote this special AS number as AS_TRANS for ease of > > description in the rest of this specification. This AS number is > > also placed in the "My Autonomous System" field of the OPEN message > > originated by a NEW BGP speaker, if the speaker does not have a > > (globally unique) 2-octet AS number." > > The clarification would be useful : 1) When 4-byte AS number capability message is > present and the receiver is able to process the capability message, > should it ignore the AS number field in the OPEN message and use the AS-number present in the capability message? How about the following addition in Section 4.1: When a NEW BGP speaker processes an OPEN message from another NEW BGP speaker, it MUST take the Autonomous System number encoded in the Capability Value field of the Capability in lieu of the "My Autonomous System" field of the OPEN message. > > > Clarification 2: > Minor nit: "truly 4-octet" should be defined as a quantity higher > than 65535. Will replace "truly 4-octet" by "non-mappable 4-octet AS number". > > Should the NEW BGP speaker send a NOTIFICATION message when it > receives a OPEN message with AS_TRANS but without any corresponding > capability message ? Note that although AS_TRANS(23456) is a > reserved number now, it is still possible to receive a OPEN message > with AS_TRANS value from an OLD BGP speaker or from a ill-behaving > NEW BGP speaker. > > Proposal for a NOTIFICATION message > > When two BGP speakers correspond with each other by sending AS_TRANS > value in the 'My AS number' field, then the OPEN message MUST contain > the 4-octet AS number capability option. If the 4-octet capability > is missing in OPEN message where the 'My AS Number' field contains > AS_TRANS value, a NEW BGP speaker-receiver SHOULD send a notification > with code=2, subcode=2 [bad peer AS] to the sender of the OPEN > message. We could be at the risk of over-specifying here. (Note that RFC 4271 does not cover the possible misuse of reserved / non-allocated AS numbers.) > > > > Clarification on section 6 (Transition) > > How about some more text on PE-CE cases? Especially the AS_OVERRIDE > issue as identified in > > http://www.ietf.org/proceedings/08mar/slides/idr-4/idr-4.htm [ Please > check-out slide 11] > As AS_OVERRIDE is something that is not covered in RFC 4271, I think that we should leave it out due to the lack of background information / reference. -- Enke From root@core3.amsl.com Fri Apr 17 07:15: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 1244D3A6836; Fri, 17 Apr 2009 07: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: <20090417141502.1244D3A6836@core3.amsl.com> Date: Fri, 17 Apr 2009 07:15:02 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-optional-transitive-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, 17 Apr 2009 14:15: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 : Error Handling for Optional Transitive BGP Attributes Author(s) : J. Scudder, E. Chen Filename : draft-ietf-idr-optional-transitive-00.txt Pages : 8 Date : 2009-04-16 According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable in the case of optional transitive attributes. This document revises BGP's error-handling rules for optional transitive attributes, and provides guidelines for the authors of documents defining new optional transitive attributes. It also revises the error handling procedures for several existing optional transitive attributes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-optional-transitive-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-optional-transitive-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-17071123.I-D@ietf.org> --NextPart-- From jgs@juniper.net Fri Apr 17 08:12:54 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 02BEC3A6DF5 for ; Fri, 17 Apr 2009 08:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 cTE8UHNyuf9D for ; Fri, 17 Apr 2009 08:12:53 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 16C083A6DB7 for ; Fri, 17 Apr 2009 08:12:53 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSeicvkq7+auPtI+RLm3/clGzoZhyBC03@postini.com; Fri, 17 Apr 2009 08:14:07 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 17 Apr 2009 08:11:45 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 08:11:45 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 08:11:45 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:11:44 -0700 Received: from [172.16.13.201] ([172.16.13.201]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3HFBiM35616 for ; Fri, 17 Apr 2009 08:11:44 -0700 (PDT) (envelope-from jgs@juniper.net) Message-ID: <57A2B5A4-570F-4F19-A15A-5F36E852D42C@juniper.net> From: "John G. Scudder" To: idr List In-Reply-To: <20090417141502.1244D3A6836@core3.amsl.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 11:11:43 -0400 References: <20090417141502.1244D3A6836@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 17 Apr 2009 15:11:44.0575 (UTC) FILETIME=[D1E874F0:01C9BF6E] Subject: Re: [Idr] I-D Action:draft-ietf-idr-optional-transitive-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, 17 Apr 2009 15:12:54 -0000 FYI the changes in this version other than the name change are to incorporate the various editorial suggestions we've received and to remove the checks for zero AS number/BGP identifier in the AGGREGATOR attribute (section 4.1). The reason for the latter is that in short, the check was overzealous: - RFC 4271 doesn't mandate this check. Thus we can't expect current implementations to do it. - AGGREGATOR is widely (probably universally) supported so we never expect PARTIAL to be set. - Thus, if the check is mandated, if someone does inject an update with an AGGREGATOR with zero ASN or BGP ID, it would traverse "old" routers just fine, but would cause a session reset when it hits a "new" router (i.e. one supporting the draft). This is exactly the opposite of what we are trying to achieve! Hence, check removed. Regards, --John On Apr 17, 2009, at 10:15 AM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Inter-Domain Routing Working Group > of the IETF. > > > Title : Error Handling for Optional Transitive BGP > Attributes > Author(s) : J. Scudder, E. Chen > Filename : draft-ietf-idr-optional-transitive-00.txt > Pages : 8 > Date : 2009-04-16 > > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable in the case of optional transitive > attributes. This document revises BGP's error-handling rules for > optional transitive attributes, and provides guidelines for the > authors of documents defining new optional transitive attributes. It > also revises the error handling procedures for several existing > optional transitive attributes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-optional-transitive-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. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From pmohapat@cisco.com Fri Apr 17 08:53:13 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 D6ADD3A6DB7 for ; Fri, 17 Apr 2009 08:53:13 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0Od7qlPHNur for ; Fri, 17 Apr 2009 08:53:13 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id F403F3A6DB0 for ; Fri, 17 Apr 2009 08:53:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,205,1238976000"; d="scan'208";a="155972970" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 17 Apr 2009 15:54:26 +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 n3HFsQ0A002728; Fri, 17 Apr 2009 08:54:26 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3HFsQuG005085; Fri, 17 Apr 2009 15:54:26 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:54:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Apr 2009 08:54:25 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54091BA6C7@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49E511F3.4010706@raszuk.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rfernando-idr-link-bandwidth-00.txt asIDR WGdocument Thread-Index: Acm9Uq3pqm1HkFFgRJ+Cro+26GtBRACIU/aw References: <00275A5B436CA441900CB10936742A3801F86AFB@FRVELSMBS22.ad2.ad.alcatel.com> <00275A5B436CA441900CB10936742A38020B7831@FRVELSMBS22.ad2.ad.alcatel.com><49E4FA02.90209@raszuk.net><00275A5B436CA441900CB10936742A38020B7835@FRVELSMBS22.ad2.ad.alcatel.com> <49E511F3.4010706@raszuk.net> From: "Pradosh Mohapatra (pmohapat)" To: , "PAPADIMITRIOU Dimitri" X-OriginalArrivalTime: 17 Apr 2009 15:54:26.0511 (UTC) FILETIME=[C8F0DDF0:01C9BF74] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1778; t=1239983666; x=1240847666; 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]=20draft-rfernando-idr-link-bandwi dth-00.txt=20asIDR=09WGdocument |Sender:=20; bh=nIa9H68mzL4lEXYC4U+DvzdbNb8xmki82WHcVWoW0/c=; b=OBCmViNJRBj95VQmUIDpXVmULfyKl3yrbWVs/OlCe50ibmeyqAl1Xy/C0H DIPuNMLCL8UuxYVkfXlK/XKIV7OrkQz/EtielskqJXQcbs1zchtM9O7PVzek Sh07PES1Pi; Authentication-Results: sj-dkim-3; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt asIDR WGdocument 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, 17 Apr 2009 15:53:13 -0000 | >=20 | > "When a BGP speaker receives multiple paths from its=20 | internal peers,=20 | > it could select more than one path to send traffic to. | >=20 | > [...] | >=20 | > The first scenario is when the candidate paths are=20 | identical until and=20 | > including the IGP distance step in the BGP decision process." | >=20 | > On the other hand, per 9.1.2.2 (4271) a speaker "selects"=20 | only one of=20 | > these routes for inclusion in the associated Loc-RIB=20 | (reaching point f=20 | > the BGP ID tie breaker and subsequent applies). |=20 | Well I see your point. 4271 does not talk about multipath.=20 | And neither this draft :) This draft just enhances the multipath. |=20 | The multipath alone as local box implementation matter may=20 | have not been spec-ed out as such. This is the point you are=20 | perhaps questioning. |=20 | If you are correct. The draft enhancing "multipath" should=20 | either define what it is or bring the reference to other=20 | document defining it. And such definition does not need to be=20 | a poem. It will just suffice to include one paragraph on what=20 | makes a path a multipath candidate and what are the=20 | exceptions if you have tunneled core deployed. |=20 | > Wouldn't it be worth clarifying this "implicit relaxation"=20 | of the > selection rule (as a protocol specifies=20 | messages/format but also > procedures) ? |=20 | Agreed. That would/should be part of general multipath definition. I agree. If there is enough interest to document generic multipath mechanism, we should start a separate conversation. This document is specific to link bandwidth for internal paths and we have listed the criteria for selecting the multipaths in the revised version. - Pradosh From yakov@juniper.net Fri Apr 17 09:01:10 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 5468A3A6DD7 for ; Fri, 17 Apr 2009 09:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 9YNuxcQXJKVv for ; Fri, 17 Apr 2009 09:01:08 -0700 (PDT) Received: from chip3og61.obsmtp.com (chip3og61.obsmtp.com [64.18.14.187]) by core3.amsl.com (Postfix) with ESMTP id B21583A6962 for ; Fri, 17 Apr 2009 09:00:35 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob61.postini.com ([64.18.6.12]) with SMTP ID DSNKSein5gE3xBTvcyWhMkVc586YCugOzvp1@postini.com; Fri, 17 Apr 2009 09:01:52 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 17 Apr 2009 08:58:01 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 08:58:02 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 08:58:01 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:58:00 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3HFw0M59642; Fri, 17 Apr 2009 08:58:00 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200904171558.n3HFw0M59642@magenta.juniper.net> To: Rex Fernando In-Reply-To: References: X-MH-In-Reply-To: Rex Fernando message dated "Tue, 14 Apr 2009 10:45:27 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <89725.1239983880.1@juniper.net> Date: Fri, 17 Apr 2009 08:58:00 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 17 Apr 2009 15:58:00.0599 (UTC) FILETIME=[488C1A70:01C9BF75] Cc: "idr@ietf.org" Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR WGdocument 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, 17 Apr 2009 16:01:10 -0000 Rex, > Hi Dimitri, > > The revised version includes the following changes that you suggested we make: > > (a) Note the fact that the value carried in the link-bandwidth extended > community does not change with traffic levels (text added to section 2). > > (b) Clarify the scenarios under which link bandwidth can be safely deployed > (clarified in section 3) > > I've attached the revised draft and the diff. Please resubmit the revised draft as draft-ietf-idr-link-bandwidth-00.txt Yakov. > > Thanks, > - Rex > > | -----Original Message----- > | From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel- > | lucent.be] > | Sent: Saturday, March 28, 2009 10:08 AM > | To: Rex Fernando; Yakov Rekhter; idr@ietf.org > | Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt as IDR > | WGdocument > | =20 > | Hi Fernando: > | =20 > | > -----Original Message----- > | > From: Rex Fernando [mailto:rex@juniper.net] > | > Sent: Friday, March 27, 2009 8:57 PM > | > To: PAPADIMITRIOU Dimitri; Yakov Rekhter; idr@ietf.org > | > Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt > | > as IDR WGdocument > | > > | > Hi Dimitri, > | > > | > | The Link Bandwidth Community used to be part of the BGP Extended > | > | Communities Attribute document (now RFC4360) until it was > | > removed in v09 > | > | after review. At that it was stated that in order to perform > | > | BW-proportional BGP load-balancing, BGP multipath load > | > balancing should > | > | be first documented. Isn't this condition still valid in > | > the present > | > | case and the corr.mechanisms to be documented beyond > | > limited deployment > | > | consideration part of Section 3? > | > > | > The draft lists the cases (although not in so many words) > | > where link bandwidth can be safely deployed i.e. when the > | > candidate paths are identical until the IGP distance step in > | > path selection or you have a tunneled network. Either of > | > these would ensure loop freedom. And that's all there is to it. > | > > | > We'll be happy to omit the word "multipath" from the draft > | > since it lacks prior definition and expand on the deployment > | > scenarios a bit if you feel strongly about it. > | =20 > | I think we have first to agree on the definition of "link bandwidth" > | =20 > | - either consider the link bandwidth as the "nominal link capacity" > | which is thus a fixed and configured value (equivalent to link cost) > | that does not result in variability in the multipath selection process > | at the border router (PE1 in the slide material) beside local policy > | decision. this would lead to a control-driven usage of this attribute. > | =20 > | - or consider the link bandwidth as the "available link bandwidth" aka > | "residual capacity" which thus leaves possibility for varying the > | multipath selection process over time depending on the actual value of > | this attribute. this would lead to a traffic-driven usage of this > | attribute. > | =20 > | I would be advisable that you clarify on this point to see how to > | consider Section 3 statement: > | =20 > | "The usage of this community is restricted to the cases where BGP > | multipath can be safely deployed." > | =20 > | Thanks, > | -dimitri. > | =20 > | > - Rex > | > > | > > > --_003_DBDEC20E6E29304D8AE5EAA493609B3555C17B706BEMBX02HQjnprn_ > Content-Type: text/plain; name="draft-rfernando-idr-link-bandwidth-00.txt" > Content-Description: draft-rfernando-idr-link-bandwidth-00.txt > Content-Disposition: attachment; > filename="draft-rfernando-idr-link-bandwidth-00.txt"; size=8717; > creation-date="Tue, 14 Apr 2009 10:32:02 GMT"; > modification-date="Tue, 14 Apr 2009 10:33:24 GMT" > Content-Transfer-Encoding: base64 > > TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg > ICAgUC4gTW9oYXBhdHJhDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg > ICAgICAgICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMNCkludGVuZGVkIHN0YXR1czogU3RhbmRh > cmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBGZXJuYW5kbw0KRXhwaXJl > czogU2VwdGVtYmVyIDQsIDIwMDkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKdW5pcGVy > IE5ldHdvcmtzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg > ICAgICAgICAgICAgIE1hcmNoIDMsIDIwMDkNCg0KDQogICAgICAgICAgICAgICAgIEJHUCBMaW5r > IEJhbmR3aWR0aCBFeHRlbmRlZCBDb21tdW5pdHkNCiAgICAgICAgICAgICAgIGRyYWZ0LXJmZXJu > YW5kby1pZHItbGluay1iYW5kd2lkdGgtMDAudHh0DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0K > ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZv > cm1hbmNlIHdpdGggdGhlDQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LiAgVGhp > cyBkb2N1bWVudCBtYXkgY29udGFpbiBtYXRlcmlhbA0KICAgZnJvbSBJRVRGIERvY3VtZW50cyBv > ciBJRVRGIENvbnRyaWJ1dGlvbnMgcHVibGlzaGVkIG9yIG1hZGUgcHVibGljbHkNCiAgIGF2YWls > YWJsZSBiZWZvcmUgTm92ZW1iZXIgMTAsIDIwMDguICBUaGUgcGVyc29uKHMpIGNvbnRyb2xsaW5n > IHRoZQ0KICAgY29weXJpZ2h0IGluIHNvbWUgb2YgdGhpcyBtYXRlcmlhbCBtYXkgbm90IGhhdmUg > Z3JhbnRlZCB0aGUgSUVURg0KICAgVHJ1c3QgdGhlIHJpZ2h0IHRvIGFsbG93IG1vZGlmaWNhdGlv > bnMgb2Ygc3VjaCBtYXRlcmlhbCBvdXRzaWRlIHRoZQ0KICAgSUVURiBTdGFuZGFyZHMgUHJvY2Vz > cy4gIFdpdGhvdXQgb2J0YWluaW5nIGFuIGFkZXF1YXRlIGxpY2Vuc2UgZnJvbQ0KICAgdGhlIHBl > cnNvbihzKSBjb250cm9sbGluZyB0aGUgY29weXJpZ2h0IGluIHN1Y2ggbWF0ZXJpYWxzLCB0aGlz > DQogICBkb2N1bWVudCBtYXkgbm90IGJlIG1vZGlmaWVkIG91dHNpZGUgdGhlIElFVEYgU3RhbmRh > cmRzIFByb2Nlc3MsIGFuZA0KICAgZGVyaXZhdGl2ZSB3b3JrcyBvZiBpdCBtYXkgbm90IGJlIGNy > ZWF0ZWQgb3V0c2lkZSB0aGUgSUVURiBTdGFuZGFyZHMNCiAgIFByb2Nlc3MsIGV4Y2VwdCB0byBm > b3JtYXQgaXQgZm9yIHB1YmxpY2F0aW9uIGFzIGFuIFJGQyBvciB0bw0KICAgdHJhbnNsYXRlIGl0 > IGludG8gbGFuZ3VhZ2VzIG90aGVyIHRoYW4gRW5nbGlzaC4NCg0KICAgSW50ZXJuZXQtRHJhZnRz > IGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRh > c2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3Rl > IHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1l > bnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRy > YWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBt > YXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMg > YXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJh > ZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g > YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 > LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8x > aWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93 > IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9z > aGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBTZXB0 > ZW1iZXIgNCwgMjAwOS4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKGMpIDIw > MDkgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNCiAgIGRvY3Vt > ZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQoNCg0KDQpNb2hhcGF0cmEgJiBG > ZXJuYW5kbyAgICBFeHBpcmVzIFNlcHRlbWJlciA0LCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2Ug > MV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgTGluayBCYW5kd2lkdGggICAgICAg > ICAgICAgICAgICAgTWFyY2ggMjAwOQ0KDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0 > byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zpc2lvbnMgUmVsYXRp > bmcgdG8gSUVURiBEb2N1bWVudHMgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQogICBwdWJsaWNh > dGlvbiBvZiB0aGlzIGRvY3VtZW50IChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWlu > Zm8pLg0KICAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5 > IGRlc2NyaWJlIHlvdXIgcmlnaHRzDQogICBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdCB0 > byB0aGlzIGRvY3VtZW50Lg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJl > cyBhbiBhcHBsaWNhdGlvbiBvZiBCR1AgZXh0ZW5kZWQgY29tbXVuaXRpZXMNCiAgIHRoYXQgYWxs > b3dzIGEgcm91dGVyIHRvIHBlcmZvcm0gdW5lcXVhbCBjb3N0IGxvYWQgYmFsYW5jaW5nLg0KDQoN > ClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4g > LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMw0KICAgICAxLjEuICBSZXF1aXJl > bWVudHMgTGFuZ3VhZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzDQog > ICAyLiAgTGluayBCYW5kd2lkdGggRXh0ZW5kZWQgQ29tbXVuaXR5IC4gLiAuIC4gLiAuIC4gLiAu > IC4gLiAuIC4gLiAuIDMNCiAgIDMuICBEZXBsb3ltZW50IENvbnNpZGVyYXRpb25zIC4gLiAuIC4g > LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMw0KICAgNC4gIEFja25vd2xlZGdtZW50cyAu > IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0DQogICA1LiAg > SUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu > IC4gLiAuIDQNCiAgIDYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4g > LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNA0KICAgNy4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAu > IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0DQogICBBdXRob3JzJyBB > ZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu > IDQNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN > Cg0KTW9oYXBhdHJhICYgRmVybmFuZG8gICAgRXhwaXJlcyBTZXB0ZW1iZXIgNCwgMjAwOSAgICAg > ICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExpbmsg > QmFuZHdpZHRoICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDkNCg0KDQoxLiAgSW50cm9kdWN0 > aW9uDQoNCiAgIFdoZW4gYSBCR1Agc3BlYWtlciByZWNlaXZlcyBtdWx0aXBsZSBwYXRocyBmcm9t > IGl0cyBpbnRlcm5hbCBwZWVycywNCiAgIGl0IGNvdWxkIHNlbGVjdCBtb3JlIHRoYW4gb25lIHBh > dGggdG8gc2VuZCB0cmFmZmljIHRvLiAgSW4gZG9pbmcgc28sDQogICBpdCBtaWdodCBiZSB1c2Vm > dWwgdG8gcHJvdmlkZSB0aGUgc3BlYWtlciB3aXRoIGluZm9ybWF0aW9uIHRoYXQgd291bGQNCiAg > IGhlbHAgaXQgZGlzdHJpYnV0ZSB0aGUgdHJhZmZpYyB1bmVxdWFsbHkgYmFzZWQgb24gdGhlIGNv > c3Qgb2YgdGhlDQogICBleHRlcm5hbCAoRE1aKSBsaW5rLiAgVGhpcyBkb2N1bWVudCBzdWdnZXN0 > cyB0aGF0IHRoZSBleHRlcm5hbCBsaW5rDQogICBiYW5kd2lkdGggYmUgY2FycmllZCBpbiB0aGUg > bmV0d29yayB1c2luZyBhIG5ldyBleHRlbmRlZCBjb21tdW5pdHkNCiAgIFtSRkM0MzYwXSAtIHRo > ZSBsaW5rIGJhbmR3aWR0aCBleHRlbmRlZCBjb21tdW5pdHkuDQoNCjEuMS4gIFJlcXVpcmVtZW50 > cyBMYW5ndWFnZQ0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJ > UkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAi > UkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQg > YXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0u > DQoNCg0KMi4gIExpbmsgQmFuZHdpZHRoIEV4dGVuZGVkIENvbW11bml0eQ0KDQogICBXaGVuIGEg > QkdQIHNwZWFrZXIgcmVjZWl2ZXMgYSByb3V0ZSBmcm9tIGEgZGlyZWN0bHkgY29ubmVjdGVkDQog > ICBleHRlcm5hbCBuZWlnaGJvciAodGhlIGV4dGVybmFsIG5laWdoYm9yIHRoYXQgaXMgb25lIElQ > IGhvcCBhd2F5KSBhbmQNCiAgIGFkdmVydGlzZXMgdGhpcyByb3V0ZSAodmlhIElCR1ApIHRvIGlu > dGVybmFsIG5laWdoYm9ycywgYXMgcGFydCBvZg0KICAgdGhpcyBhZHZlcnRpc2VtZW50IHRoZSBy > b3V0ZXIgbWF5IGNhcnJ5IHRoZSBiYW5kd2lkdGggb2YgdGhlIGxpbmsNCiAgIHRoYXQgY29ubmVj > dHMgdGhlIHJvdXRlciB3aXRoIHRoZSBleHRlcm5hbCBuZWlnaGJvci4gIFRoZSBiYW5kd2lkdGgN > CiAgIG9mIHN1Y2ggYSBsaW5rIGlzIGNhcnJpZWQgaW4gdGhlIExpbmsgQmFuZHdpZHRoIENvbW11 > bml0eS4gIFRoZQ0KICAgY29tbXVuaXR5IGlzIG9wdGlvbmFsIG5vbi10cmFuc2l0aXZlLiAgQSBi > b3JkZXIgcm91dGVyIE1VU1Qgc3RyaXAgdGhlDQogICBsaW5rIGJhbmR3aWR0aCBjb21tdW5pdHkg > ZnJvbSBhIHJvdXRlIHdoZW4gaXQgYWR2ZXJ0aXNlcyB0aGUgcm91dGUgdG8NCiAgIGFuIGV4dGVy > bmFsIG5laWdoYm9yLiAgDQoNCiAgIEl0IGlzIG5vdGV3b3J0aHkgdGhhdCB0aGUgYmFuZHdpZHRo > IGNhcnJpZWQgaW4gdGhlIExpbmsgQmFuZHdpZHRoDQogICBleHRlbmRlZCBjb21tdW5pdHkgaXMg > dGhlIGNvbmZpZ3VyZWQgYmFuZHdpZHRoIG9mIHRoZSBFQkdQIGxpbmsuDQogICBJdCBkb2VzIG5v > dCBkZXBlbmQgb24gdGhlIGFtb3VudCBvZiB0cmFmZmljIHRyYW5zaXRpbmcgdGhhdCBsaW5rLg0K > DQogICBUaGUgdmFsdWUgb2YgdGhlIGhpZ2gtb3JkZXIgb2N0ZXQgb2YgdGhlIGV4dGVuZGVkIFR5 > cGUgRmllbGQgaXMNCiAgIDB4NDAuICBUaGUgdmFsdWUgb2YgdGhlIGxvdy1vcmRlciBvY3RldCBv > ZiB0aGUgZXh0ZW5kZWQgdHlwZSBmaWVsZA0KICAgZm9yIHRoaXMgY29tbXVuaXR5IGlzIDB4MDQu > ICBUaGUgdmFsdWUgb2YgdGhlIEdsb2JhbCBBZG1pbmlzdHJhdG9yDQogICBzdWJmaWVsZCBpbiB0 > aGUgVmFsdWUgRmllbGQgU0hPVUxEIHJlcHJlc2VudCB0aGUgQXV0b25vbW91cyBTeXN0ZW0NCiAg > IG9mIHRoZSByb3V0ZXIgdGhhdCBhdHRhY2hlcyB0aGUgTGluayBCYW5kd2lkdGggQ29tbXVuaXR5 > LiAgSWYgZm91cg0KICAgb2N0ZXQgQVMgbnVtYmVyaW5nIHNjaGVtZSBpcyB1c2VkIFtSRkM0ODkz > XSwgQVNfVFJBTlMgc2hvdWxkIGJlDQogICB1c2VkIGluIHRoZSBHbG9iYWwgQWRtaW5pc3RyYXRv > ciBzdWJmaWVsZC4gIFRoZSBiYW5kd2lkdGggb2YgdGhlDQogICBsaW5rIGlzIGV4cHJlc3NlZCBh > cyA0IG9jdGV0cyBpbiBJRUVFIGZsb2F0aW5nIHBvaW50IGZvcm1hdCwgdW5pdHMNCiAgIGJlaW5n > IGJ5dGVzIHBlciBzZWNvbmQuICBJdCBpcyBjYXJyaWVkIGluIHRoZSBMb2NhbCBBZG1pbmlzdHJh > dG9yDQogICBzdWJmaWVsZCBvZiB0aGUgVmFsdWUgRmllbGQuDQoNCg0KMy4gIERlcGxveW1lbnQg > Q29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyB0byB1c2UgdGhlIExp > bmsgQmFuZHdpZHRoIGV4dGVuZGVkDQogICBjb21tdW5pdHkgZm9yIHRoZSBwdXJwb3NlIG9mIGxv > YWQgYmFsYW5jaW5nIGluIHRoZSBmb2xsb3dpbmcgdHdvDQogICBzY2VuYXJpb3MuIFRoZSBmaXJz > dCBzY2VuYXJpbyBpcyB3aGVuIHRoZSBjYW5kaWRhdGUgcGF0aHMgYXJlDQogICBpZGVudGljYWwg > dW50aWwgYW5kIGluY2x1ZGluZyB0aGUgSUdQIGRpc3RhbmNlIHN0ZXAgaW4gdGhlIEJHUA0KICAg > ZGVjaXNpb24gcHJvY2Vzcy4gIFRoZSBzZWNvbmQgc2NlbmFyaW8gaXMgd2hlbiB0aGUgdHJhZmZp > YyBnb2VzDQogICB2aWEgYSB0dW5uZWxlZCBuZXR3b3JrLCBpbiB3aGljaCBjYXNlIHRoZSBjYW5k > aWRhdGUgcGF0aHMgYXJlDQogICBpZGVudGljYWwgZm9yIGFsbCBzdGVwcyBiZWZvcmUgdGhlIElH > UCBkaXN0YW5jZSBzdGVwIGluIHRoZSBCR1ANCiAgIGRlY2lzaW9uIHByb2Nlc3MuICBVc2Ugb2Yg > dGhpcyBjb21tdW5pdHkgZm9yIG90aGVyIHNjZW5hcmlvcyBpcw0KICAgb3V0c2lkZSB0aGUgc2Nv > cGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgSWYgdGhlcmUgYXJlIG11bHRpcGxlIHBhdGhzIHRv > IHJlYWNoIGEgZGVzdGluYXRpb24gYW5kIGlmIG9ubHkgc29tZQ0KICAgb2YgdGhlbSBoYXZlIGxp > bmsgYmFuZHdpZHRoIGNvbW11bml0eSwgdGhlIHJlY2VpdmVyIHNob3VsZCBub3QNCiAgIHBlcmZv > cm0gdW5lcXVhbCBjb3N0IGxvYWQNCg0KDQoNCk1vaGFwYXRyYSAmIEZlcm5hbmRvICAgIEV4cGly > ZXMgU2VwdGVtYmVyIDQsIDIwMDkgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQt > RHJhZnQgICAgICAgICAgICAgICBMaW5rIEJhbmR3aWR0aCAgICAgICAgICAgICAgICAgICBNYXJj > aCAyMDA5DQoNCg0KICAgYmFsYW5jaW5nIGJhc2VkIG9uIGxpbmsgYmFuZHdpZHRocy4NCg0KDQo0 > LiAgQWNrbm93bGVkZ21lbnRzDQoNCiAgIFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsg > WWFrb3YgUmVraHRlciwgU3JpaGFyaSBTYW5nbGkgYW5kIERhbg0KICAgVGFwcGFuIGZvciBwcm9w > b3NpbmcgdW5lcXVhbCBjb3N0IGxvYWQgYmFsYW5jaW5nIGFzIG9uZSBwb3NzaWJsZQ0KICAgYXBw > bGljYXRpb24gb2YgdGhlIGV4dGVuZGVkIGNvbW11bml0eSBhdHRyaWJ1dGUuDQoNCg0KNS4gIElB > TkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc3BlY2lmaWMg > YXBwbGljYXRpb24gb2YgdGhlIHR3by1vY3RldCBBUw0KICAgc3BlY2lmaWMgZXh0ZW5kZWQgY29t > bXVuaXR5LiAgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gYXNzaWduIGEgc3ViLSB0eXBlDQogICB2YWx1 > ZSBvZiAweDA0IGZvciB0aGUgbGluayBiYW5kd2lkdGggZXh0ZW5kZWQgY29tbXVuaXR5Lg0KDQoN > CiAgICAgIE5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVmFs > dWUNCiAgICAgIC0tLS0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg > LS0tLS0NCiAgICAgIG5vbi10cmFuc2l0aXZlIExpbmsgQmFuZHdpZHRoIEV4dC4gQ29tbXVuaXR5 > ICAweDQwMDQNCg0KDQoNCjYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGVyZSBh > cmUgbm8gYWRkaXRpb25hbCBzZWN1cml0eSByaXNrcyBpbnRyb2R1Y2VkIGJ5IHRoaXMgZGVzaWdu > Lg0KDQoNCjcuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0gIEJyYWRuZXIs > IFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAg > ICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQog > ICBbUkZDNDM2MF0gIFNhbmdsaSwgUy4sIFRhcHBhbiwgRC4sIGFuZCBZLiBSZWtodGVyLCAiQkdQ > IEV4dGVuZGVkDQogICAgICAgICAgICAgIENvbW11bml0aWVzIEF0dHJpYnV0ZSIsIFJGQyA0MzYw > LCBGZWJydWFyeSAyMDA2Lg0KDQogICBbUkZDNDg5M10gIFZvaHJhLCBRLiBhbmQgRS4gQ2hlbiwg > IkJHUCBTdXBwb3J0IGZvciBGb3VyLW9jdGV0IEFTDQogICAgICAgICAgICAgIE51bWJlciBTcGFj > ZSIsIFJGQyA0ODkzLCBNYXkgMjAwNy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTW9oYXBh > dHJhICYgRmVybmFuZG8gICAgRXhwaXJlcyBTZXB0ZW1iZXIgNCwgMjAwOSAgICAgICAgICAgICAg > IFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIExpbmsgQmFuZHdpZHRo > ICAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDkNCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0K > ICAgUHJhZG9zaCBNb2hhcGF0cmENCiAgIENpc2NvIFN5c3RlbXMNCiAgIDE3MCBXLiBUYXNtYW4g > RHJpdmUNCiAgIFNhbiBKb3NlLCBDQSAgOTUxMzQNCiAgIFVTQQ0KDQogICBQaG9uZToNCiAgIEVt > YWlsOiBwbW9oYXBhdEBjaXNjby5jb20NCg0KDQogICBSZXggRmVybmFuZG8NCiAgIEp1bmlwZXIg > TmV0d29ya3MNCiAgIDExOTQgTi4gTWF0aGlsZGEgQXZlDQogICBTdW5ueXZhbGUsIENBICA5NDA4 > OQ0KICAgVVNBDQoNCiAgIFBob25lOg0KICAgRW1haWw6IHJleEBqdW5pcGVyLm5ldA0KDQo= > > --_003_DBDEC20E6E29304D8AE5EAA493609B3555C17B706BEMBX02HQjnprn_ > Content-Type: text/plain; name="diffs.txt" > Content-Description: diffs.txt > Content-Disposition: attachment; filename="diffs.txt"; size=3706; > creation-date="Tue, 14 Apr 2009 10:32:50 GMT"; > modification-date="Tue, 14 Apr 2009 10:33:33 GMT" > Content-Transfer-Encoding: base64 > > DQoqKiogZHJhZnQtcmZlcm5hbmRvLWlkci1saW5rLWJhbmR3aWR0aC0wMC50eHQub3JpZwkyMDA5 > LTA0LTE0IDA4OjM1OjU0LjQ0MzU4NDAwMCAtMDcwMA0KLS0tIGRyYWZ0LXJmZXJuYW5kby1pZHIt > bGluay1iYW5kd2lkdGgtMDAudHh0CTIwMDktMDQtMTQgMDg6MzU6MjguNjU5ODI4MDAwIC0wNzAw > DQoqKioqKioqKioqKioqKioNCioqKiAxNDAsMTY2ICoqKioNCiAgICAgb2Ygc3VjaCBhIGxpbmsg > aXMgY2FycmllZCBpbiB0aGUgTGluayBCYW5kd2lkdGggQ29tbXVuaXR5LiAgVGhlDQogICAgIGNv > bW11bml0eSBpcyBvcHRpb25hbCBub24tdHJhbnNpdGl2ZS4gIEEgYm9yZGVyIHJvdXRlciBNVVNU > IHN0cmlwIHRoZQ0KICAgICBsaW5rIGJhbmR3aWR0aCBjb21tdW5pdHkgZnJvbSBhIHJvdXRlIHdo > ZW4gaXQgYWR2ZXJ0aXNlcyB0aGUgcm91dGUgdG8NCiEgICAgYW4gZXh0ZXJuYWwgbmVpZ2hib3Iu > ICBUaGUgdmFsdWUgb2YgdGhlIGhpZ2gtb3JkZXIgb2N0ZXQgb2YgdGhlDQohICAgIGV4dGVuZGVk > IFR5cGUgRmllbGQgaXMgMHg0MC4gIFRoZSB2YWx1ZSBvZiB0aGUgbG93LW9yZGVyIG9jdGV0IG9m > IHRoZQ0KISAgICBleHRlbmRlZCB0eXBlIGZpZWxkIGZvciB0aGlzIGNvbW11bml0eSBpcyAweDA0 > LiAgVGhlIHZhbHVlIG9mIHRoZQ0KISAgICBHbG9iYWwgQWRtaW5pc3RyYXRvciBzdWJmaWVsZCBp > biB0aGUgVmFsdWUgRmllbGQgU0hPVUxEIHJlcHJlc2VudCB0aGUNCiEgICAgQXV0b25vbW91cyBT > eXN0ZW0gb2YgdGhlIHJvdXRlciB0aGF0IGF0dGFjaGVzIHRoZSBMaW5rIEJhbmR3aWR0aA0KISAg > ICBDb21tdW5pdHkuICBJZiBmb3VyIG9jdGV0IEFTIG51bWJlcmluZyBzY2hlbWUgaXMgdXNlZCBb > UkZDNDg5M10sDQohICAgIEFTX1RSQU5TIHNob3VsZCBiZSB1c2VkIGluIHRoZSBHbG9iYWwgQWRt > aW5pc3RyYXRvciBzdWJmaWVsZC4gIFRoZQ0KISAgICBiYW5kd2lkdGggb2YgdGhlIGxpbmsgaXMg > ZXhwcmVzc2VkIGFzIDQgb2N0ZXRzIGluIElFRUUgZmxvYXRpbmcgcG9pbnQNCiEgICAgZm9ybWF0 > LCB1bml0cyBiZWluZyBieXRlcyBwZXIgc2Vjb25kLiAgSXQgaXMgY2FycmllZCBpbiB0aGUgTG9j > YWwNCiEgICAgQWRtaW5pc3RyYXRvciBzdWJmaWVsZCBvZiB0aGUgVmFsdWUgRmllbGQuDQogIA0K > ICANCiAgMy4gIERlcGxveW1lbnQgQ29uc2lkZXJhdGlvbnMNCiAgDQohICAgIFRoZSB1c2FnZSBv > ZiB0aGlzIGNvbW11bml0eSBpcyByZXN0cmljdGVkIHRvIHRoZSBjYXNlcyB3aGVyZSBCR1ANCiEg > ICAgbXVsdGlwYXRoIGNhbiBiZSBzYWZlbHkgZGVwbG95ZWQuICBJbiBvdGhlciB3b3JkcywgdGhl > IElHUCBkaXN0YW5jZQ0KISAgICBiZXR3ZWVuIHRoZSBsb2FkIGJhbGFuY2luZyByb3V0ZXIgYW5k > IHRoZSBleGl0IHBvaW50cyBzaG91bGQgYmUgdGhlDQohICAgIHNhbWUuICBBbHRlcm5hdGl2ZWx5 > LCB0aGUgcGF0aCBiZXR3ZWVuIHRoZSBsb2FkIHNoYXJpbmcgcm91dGVyIGFuZA0KISAgICB0aGUg > ZXhpdCBwb2ludHMgY291bGQgYmUgbGFiZWwgc3dpdGNoZWQuICBJZiB0aGVyZSBhcmUgbXVsdGlw > bGUgcGF0aHMNCiEgICAgdG8gcmVhY2ggYSBkZXN0aW5hdGlvbiBhbmQgaWYgb25seSBzb21lIG9m > IHRoZW0gaGF2ZSBsaW5rIGJhbmR3aWR0aA0KISAgICBjb21tdW5pdHksIHRoZSByZWNlaXZlciBz > aG91bGQgbm90IHBlcmZvcm0gdW5lcXVhbCBjb3N0IGxvYWQNCiAgDQogIA0KICANCi0tLSAxNDAs > MTc4IC0tLS0NCiAgICAgb2Ygc3VjaCBhIGxpbmsgaXMgY2FycmllZCBpbiB0aGUgTGluayBCYW5k > d2lkdGggQ29tbXVuaXR5LiAgVGhlDQogICAgIGNvbW11bml0eSBpcyBvcHRpb25hbCBub24tdHJh > bnNpdGl2ZS4gIEEgYm9yZGVyIHJvdXRlciBNVVNUIHN0cmlwIHRoZQ0KICAgICBsaW5rIGJhbmR3 > aWR0aCBjb21tdW5pdHkgZnJvbSBhIHJvdXRlIHdoZW4gaXQgYWR2ZXJ0aXNlcyB0aGUgcm91dGUg > dG8NCiEgICAgYW4gZXh0ZXJuYWwgbmVpZ2hib3IuICANCiEgDQohICAgIEl0IGlzIG5vdGV3b3J0 > aHkgdGhhdCB0aGUgYmFuZHdpZHRoIGNhcnJpZWQgaW4gdGhlIExpbmsgQmFuZHdpZHRoDQohICAg > IGV4dGVuZGVkIGNvbW11bml0eSBpcyB0aGUgY29uZmlndXJlZCBiYW5kd2lkdGggb2YgdGhlIEVC > R1AgbGluay4NCiEgICAgSXQgZG9lcyBub3QgZGVwZW5kIG9uIHRoZSBhbW91bnQgb2YgdHJhZmZp > YyB0cmFuc2l0aW5nIHRoYXQgbGluay4NCiEgDQohICAgIFRoZSB2YWx1ZSBvZiB0aGUgaGlnaC1v > cmRlciBvY3RldCBvZiB0aGUgZXh0ZW5kZWQgVHlwZSBGaWVsZCBpcw0KISAgICAweDQwLiAgVGhl > IHZhbHVlIG9mIHRoZSBsb3ctb3JkZXIgb2N0ZXQgb2YgdGhlIGV4dGVuZGVkIHR5cGUgZmllbGQN > CiEgICAgZm9yIHRoaXMgY29tbXVuaXR5IGlzIDB4MDQuICBUaGUgdmFsdWUgb2YgdGhlIEdsb2Jh > bCBBZG1pbmlzdHJhdG9yDQohICAgIHN1YmZpZWxkIGluIHRoZSBWYWx1ZSBGaWVsZCBTSE9VTEQg > cmVwcmVzZW50IHRoZSBBdXRvbm9tb3VzIFN5c3RlbQ0KISAgICBvZiB0aGUgcm91dGVyIHRoYXQg > YXR0YWNoZXMgdGhlIExpbmsgQmFuZHdpZHRoIENvbW11bml0eS4gIElmIGZvdXINCiEgICAgb2N0 > ZXQgQVMgbnVtYmVyaW5nIHNjaGVtZSBpcyB1c2VkIFtSRkM0ODkzXSwgQVNfVFJBTlMgc2hvdWxk > IGJlDQohICAgIHVzZWQgaW4gdGhlIEdsb2JhbCBBZG1pbmlzdHJhdG9yIHN1YmZpZWxkLiAgVGhl > IGJhbmR3aWR0aCBvZiB0aGUNCiEgICAgbGluayBpcyBleHByZXNzZWQgYXMgNCBvY3RldHMgaW4g > SUVFRSBmbG9hdGluZyBwb2ludCBmb3JtYXQsIHVuaXRzDQohICAgIGJlaW5nIGJ5dGVzIHBlciBz > ZWNvbmQuICBJdCBpcyBjYXJyaWVkIGluIHRoZSBMb2NhbCBBZG1pbmlzdHJhdG9yDQohICAgIHN1 > YmZpZWxkIG9mIHRoZSBWYWx1ZSBGaWVsZC4NCiAgDQogIA0KICAzLiAgRGVwbG95bWVudCBDb25z > aWRlcmF0aW9ucw0KICANCiEgICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyB0byB1c2UgdGhlIExp > bmsgQmFuZHdpZHRoIGV4dGVuZGVkDQohICAgIGNvbW11bml0eSBmb3IgdGhlIHB1cnBvc2Ugb2Yg > bG9hZCBiYWxhbmNpbmcgaW4gdGhlIGZvbGxvd2luZyB0d28NCiEgICAgc2NlbmFyaW9zLiBUaGUg > Zmlyc3Qgc2NlbmFyaW8gaXMgd2hlbiB0aGUgY2FuZGlkYXRlIHBhdGhzIGFyZQ0KISAgICBpZGVu dGljYWwgdW50aWwgYW5kIGluY2x1ZGluZyB0aGUgSUdQIGRpc3RhbmNlIHN0ZXAgaW4gdGhlIEJH > UA0KISAgICBkZWNpc2lvbiBwcm9jZXNzLiAgVGhlIHNlY29uZCBzY2VuYXJpbyBpcyB3aGVuIHRo > ZSB0cmFmZmljIGdvZXMNCiEgICAgdmlhIGEgdHVubmVsZWQgbmV0d29yaywgaW4gd2hpY2ggY2Fz > ZSB0aGUgY2FuZGlkYXRlIHBhdGhzIGFyZQ0KISAgICBpZGVudGljYWwgZm9yIGFsbCBzdGVwcyBi > ZWZvcmUgdGhlIElHUCBkaXN0YW5jZSBzdGVwIGluIHRoZSBCR1ANCiEgICAgZGVjaXNpb24gcHJv > Y2Vzcy4gIFVzZSBvZiB0aGlzIGNvbW11bml0eSBmb3Igb3RoZXIgc2NlbmFyaW9zIGlzDQohICAg > IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQohIA0KISAgICBJZiB0aGVyZSBh > cmUgbXVsdGlwbGUgcGF0aHMgdG8gcmVhY2ggYSBkZXN0aW5hdGlvbiBhbmQgaWYgb25seSBzb21l > DQohICAgIG9mIHRoZW0gaGF2ZSBsaW5rIGJhbmR3aWR0aCBjb21tdW5pdHksIHRoZSByZWNlaXZl > ciBzaG91bGQgbm90DQohICAgIHBlcmZvcm0gdW5lcXVhbCBjb3N0IGxvYWQNCiAgDQogIA0KICAN > Cg== > > --_003_DBDEC20E6E29304D8AE5EAA493609B3555C17B706BEMBX02HQjnprn_-- From ferit.yegenoglu@lmco.com Fri Apr 17 12:53:26 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 5AA903A6923 for ; Fri, 17 Apr 2009 12:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.762 X-Spam-Level: X-Spam-Status: No, score=-7.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_HI=-8] 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 Njih66o10KQJ for ; Fri, 17 Apr 2009 12:53:25 -0700 (PDT) Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by core3.amsl.com (Postfix) with ESMTP id 4E1F33A6829 for ; Fri, 17 Apr 2009 12:53:25 -0700 (PDT) Received: from emss03g01.ems.lmco.com (relay3.ems.lmco.com [141.240.4.144])by mailgw2a.lmco.com (LM-6) with ESMTP id n3HJsX4S004399; Fri, 17 Apr 2009 15:54:34 -0400 (EDT) Received: from CONVERSION2-DAEMON.lmco.com by lmco.com (PMDF V6.3-x14 #31428) id <0KI900F01GMX81@lmco.com>; Fri, 17 Apr 2009 15:54:33 -0400 (EDT) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.3-x14 #31428) with ESMTP id <0KI900CV4GMQ5F@lmco.com>; Fri, 17 Apr 2009 15:54:28 -0400 (EDT) Received: from emss09m07.us.lmco.com ([158.183.26.40]) by EMSS09I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Apr 2009 15:54:27 -0400 Date: Fri, 17 Apr 2009 15:53:32 -0400 From: "Yegenoglu, Ferit" In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D54091BA6C7@xmb-sjc-215.amer.cisco.com> To: "Pradosh Mohapatra (pmohapat)" , robert@raszuk.net, PAPADIMITRIOU Dimitri Message-id: <79E4059BC98EAF48BBE42FCF392DAA52131B8734@emss09m07.us.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-Topic: [Idr] draft-rfernando-idr-link-bandwidth-00.txt asIDR WGdocument Thread-Index: Acm9Uq3pqm1HkFFgRJ+Cro+26GtBRACIU/awAAgvzvA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <00275A5B436CA441900CB10936742A3801F86AFB@FRVELSMBS22.ad2.ad.alcatel.com> <00275A5B436CA441900CB10936742A38020B7831@FRVELSMBS22.ad2.ad.alcatel.com> <49E4FA02.90209@raszuk.net> <00275A5B436CA441900CB10936742A38020B7835@FRVELSMBS22.ad2.ad.alcatel.com> <49E511F3.4010706@raszuk.net> <04CAD96D4C5A3D48B1919248A8FE0D54091BA6C7@xmb-sjc-215.amer.cisco.com> X-OriginalArrivalTime: 17 Apr 2009 19:54:27.0123 (UTC) FILETIME=[505FE030:01C9BF96] Cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt asIDR WGdocument 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, 17 Apr 2009 19:53:26 -0000 Pradosh/Rex - Can you please clarify what you mean by "If there are multiple paths to reach a destination and if only some of them have link bandwidth community, the receiver should not perform unequal cost load balancing based on link bandwidths."? Does this mean that if there are multiple paths to the destination and if all have the link bandwidth community the receiver can do unequal cost load balancing based on link bandwidths? I thought the Link Bandwidth extended community should be used for the purpose of load balancing only when the IGP costs are identical. Thanks, Ferit -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Pradosh Mohapatra (pmohapat) Sent: Friday, April 17, 2009 11:54 AM To: robert@raszuk.net; PAPADIMITRIOU Dimitri Cc: Yakov Rekhter; idr@ietf.org Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt asIDR WGdocument | > | > "When a BGP speaker receives multiple paths from its | internal peers, | > it could select more than one path to send traffic to. | > | > [...] | > | > The first scenario is when the candidate paths are | identical until and | > including the IGP distance step in the BGP decision process." | > | > On the other hand, per 9.1.2.2 (4271) a speaker "selects" | only one of | > these routes for inclusion in the associated Loc-RIB | (reaching point f | > the BGP ID tie breaker and subsequent applies). | | Well I see your point. 4271 does not talk about multipath. | And neither this draft :) This draft just enhances the multipath. | | The multipath alone as local box implementation matter may | have not been spec-ed out as such. This is the point you are | perhaps questioning. | | If you are correct. The draft enhancing "multipath" should | either define what it is or bring the reference to other | document defining it. And such definition does not need to be | a poem. It will just suffice to include one paragraph on what | makes a path a multipath candidate and what are the | exceptions if you have tunneled core deployed. | | > Wouldn't it be worth clarifying this "implicit relaxation" | of the > selection rule (as a protocol specifies | messages/format but also > procedures) ? | | Agreed. That would/should be part of general multipath definition. I agree. If there is enough interest to document generic multipath mechanism, we should start a separate conversation. This document is specific to link bandwidth for internal paths and we have listed the criteria for selecting the multipaths in the revised version. - Pradosh _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From robert@raszuk.net Fri Apr 17 13:33:44 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 D33893A6D99 for ; Fri, 17 Apr 2009 13:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 3ZFBxEbn44xJ for ; Fri, 17 Apr 2009 13:33:44 -0700 (PDT) Received: from mail37.opentransfer.com (mail37.opentransfer.com [76.162.254.37]) by core3.amsl.com (Postfix) with SMTP id B874C3A6E28 for ; Fri, 17 Apr 2009 13:33:43 -0700 (PDT) Received: (qmail 27870 invoked by uid 399); 17 Apr 2009 20:34:57 -0000 Received: from unknown (HELO ?192.168.1.53?) (83.24.38.220) by mail37.opentransfer.com with SMTP; 17 Apr 2009 20:34:57 -0000 Message-ID: <49E8E7ED.5070205@raszuk.net> Date: Fri, 17 Apr 2009 13:34:53 -0700 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Yegenoglu, Ferit" References: <00275A5B436CA441900CB10936742A3801F86AFB@FRVELSMBS22.ad2.ad.alcatel.com> <00275A5B436CA441900CB10936742A38020B7831@FRVELSMBS22.ad2.ad.alcatel.com> <49E4FA02.90209@raszuk.net> <00275A5B436CA441900CB10936742A38020B7835@FRVELSMBS22.ad2.ad.alcatel.com> <49E511F3.4010706@raszuk.net> <04CAD96D4C5A3D48B1919248A8FE0D54091BA6C7@xmb-sjc-215.amer.cisco.com> <79E4059BC98EAF48BBE42FCF392DAA52131B8734@emss09m07.us.lmco.com> In-Reply-To: <79E4059BC98EAF48BBE42FCF392DAA52131B8734@emss09m07.us.lmco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt asIDR WGdocument X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert@raszuk.net List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 20:33:44 -0000 Hi Ferit, For real and true IP networks you are correct ! But for tunneled networks (IP tunneling or for that matter mpls) the condition of multipath candidate having equal IGP cost to reach it can be safely relaxed. In most of the implementations I am familiar with there are knobs already today allowing you to ignore this equal IGP to the BGP next hop check. Cheers, R. > Pradosh/Rex - > > Can you please clarify what you mean by "If there are multiple paths to > reach a destination and if only some of them have link bandwidth > community, the receiver should not perform unequal cost load balancing > based on link bandwidths."? > > Does this mean that if there are multiple paths to the destination and > if all have the link bandwidth community the receiver can do unequal > cost load balancing based on link bandwidths? I thought the Link > Bandwidth extended community should be used for the purpose of load > balancing only when the IGP costs are identical. > > Thanks, > Ferit > > > > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Pradosh Mohapatra (pmohapat) > Sent: Friday, April 17, 2009 11:54 AM > To: robert@raszuk.net; PAPADIMITRIOU Dimitri > Cc: Yakov Rekhter; idr@ietf.org > Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt asIDR > WGdocument > > | > > | > "When a BGP speaker receives multiple paths from its > | internal peers, > | > it could select more than one path to send traffic to. > | > > | > [...] > | > > | > The first scenario is when the candidate paths are > | identical until and > | > including the IGP distance step in the BGP decision process." > | > > | > On the other hand, per 9.1.2.2 (4271) a speaker "selects" > | only one of > | > these routes for inclusion in the associated Loc-RIB > | (reaching point f > | > the BGP ID tie breaker and subsequent applies). > | > | Well I see your point. 4271 does not talk about multipath. > | And neither this draft :) This draft just enhances the multipath. > | > | The multipath alone as local box implementation matter may > | have not been spec-ed out as such. This is the point you are > | perhaps questioning. > | > | If you are correct. The draft enhancing "multipath" should > | either define what it is or bring the reference to other > | document defining it. And such definition does not need to be > | a poem. It will just suffice to include one paragraph on what > | makes a path a multipath candidate and what are the > | exceptions if you have tunneled core deployed. > | > | > Wouldn't it be worth clarifying this "implicit relaxation" > | of the > selection rule (as a protocol specifies > | messages/format but also > procedures) ? > | > | Agreed. That would/should be part of general multipath definition. > > I agree. If there is enough interest to document generic multipath > mechanism, we should start a separate conversation. This document > is specific to link bandwidth for internal paths and we have listed > the criteria for selecting the multipaths in the revised version. > > - Pradosh > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From enkechen@cisco.com Fri Apr 17 14:14: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 A14CD3A6E4F for ; Fri, 17 Apr 2009 14:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 VYbNbWn9UNHV for ; Fri, 17 Apr 2009 14:14:30 -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 B29B03A6844 for ; Fri, 17 Apr 2009 14:14:30 -0700 (PDT) X-Files: draft-chen-rfc4893bis-03.txt, Attached Message Part : 253 X-IronPort-AV: E=Sophos;i="4.40,206,1238976000"; d="txt'208?scan'208,208";a="173289732" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 17 Apr 2009 21:15:44 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3HLFiCL024825; Fri, 17 Apr 2009 14:15:44 -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.13.8) with ESMTP id n3HLFisU018932; Fri, 17 Apr 2009 21:15:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 14:15:44 -0700 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 14:15:44 -0700 Message-ID: <49E8F180.6070100@cisco.com> Date: Fri, 17 Apr 2009 14:15:44 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: Inter-Domain Routing List Content-Type: multipart/mixed; boundary="------------060908010706000402010405" X-OriginalArrivalTime: 17 Apr 2009 21:15:44.0253 (UTC) FILETIME=[AB5EDAD0:01C9BFA1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2465; t=1240002944; x=1240866944; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20[Fwd=3A=20I-D=20Action=3Adraft-chen-rfc4893bis- 03.txt] |Sender:=20; bh=HOzWBkW+AklOnRMiKB5Lsv1CH2PYVo54qc7m5lwQj/U=; b=pAIQfLWHu9GZC0ayCokZJ5YpMofcfOjmDibTYdDkcYTKdAlhSKAfmUf/Tw sZ5ZMMEsO+RoWEnrjFmAHUXF3LoK4NqB5lTJmDz/5TM69RacqUk9pgosp9kL OBvHFVMlS9; Authentication-Results: sj-dkim-3; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Quaizar Vohra , skh@ghs.com, Yakov Rekhter Subject: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-03.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, 17 Apr 2009 21:14:32 -0000 This is a multi-part message in MIME format. --------------060908010706000402010405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, folks: The revised draft includes the following changes: o In Sect. 4.1 clarify the handling of two AS numbers in an OPEN message. o In Sect. 4.2.2 correct the text on the AS4_AGGREGATE attribute. o In Sect. 6 remove the check of AS_number / BGP Identifier being zero for the AS4_AGGREGATE attribute (to be consistent with the AGGREGATE attribute in draft-ietf-idr-optional-transitive-00.txt). Thanks. -- Enke -------- Original Message -------- Subject: I-D Action:draft-chen-rfc4893bis-03.txt Date: Fri, 17 Apr 2009 14:00:01 -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 : BGP Support for Four-octet AS Number Space Author(s) : Q. Vohra, E. Chen Filename : draft-chen-rfc4893bis-03.txt Pages : 11 Date : 2009-04-17 Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-rfc4893bis-03.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. --------------060908010706000402010405 Content-Type: Message/External-body; name="draft-chen-rfc4893bis-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-chen-rfc4893bis-03.txt" Content-Type: text/plain Content-ID: <2009-04-17135914.I-D@ietf.org> --------------060908010706000402010405 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 --------------060908010706000402010405-- From yakov@juniper.net Fri Apr 17 14:34:54 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 E9E243A6B7B for ; Fri, 17 Apr 2009 14:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 jKYoaQk7--60 for ; Fri, 17 Apr 2009 14:34:54 -0700 (PDT) Received: from chip3og59.obsmtp.com (chip3og59.obsmtp.com [64.18.14.183]) by core3.amsl.com (Postfix) with ESMTP id CECD328C150 for ; Fri, 17 Apr 2009 14:34:53 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob59.postini.com ([64.18.6.12]) with SMTP ID DSNKSej2CZwRQAcnAfwjUK5IIpU2dMtwqf0U@postini.com; Fri, 17 Apr 2009 14:36:08 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 17 Apr 2009 14:33:58 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 14:33:58 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 14:33:58 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 14:33:57 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3HLXuM47141; Fri, 17 Apr 2009 14:33:56 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200904172133.n3HLXuM47141@magenta.juniper.net> To: Enke Chen In-Reply-To: <49E8F180.6070100@cisco.com> References: <49E8F180.6070100@cisco.com> X-MH-In-Reply-To: Enke Chen message dated "Fri, 17 Apr 2009 14:15:44 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <33124.1240004036.1@juniper.net> Date: Fri, 17 Apr 2009 14:33:56 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 17 Apr 2009 21:33:57.0080 (UTC) FILETIME=[36BF0580:01C9BFA4] Cc: Inter-Domain Routing List , skh@ghs.com, Quaizar Vohra Subject: Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-03.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, 17 Apr 2009 21:34:55 -0000 Enke, > Hi, folks: > > The revised draft includes the following changes: > > o In Sect. 4.1 clarify the handling of two AS numbers in an OPEN > message. > > o In Sect. 4.2.2 correct the text on the AS4_AGGREGATE attribute. > > o In Sect. 6 remove the check of AS_number / BGP Identifier being > zero for the AS4_AGGREGATE attribute (to be consistent with the > AGGREGATE attribute in draft-ietf-idr-optional-transitive-00.txt). Please re-submit draft-chen-rfc4893bis-03.txt as draft-ietf-idr-rfc4893bis-00.txt. Yakov. > > Thanks. -- Enke > > -------- Original Message -------- > Subject: I-D Action:draft-chen-rfc4893bis-03.txt > Date: Fri, 17 Apr 2009 14:00:01 -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 directorie s. > > Title : BGP Support for Four-octet AS Number Space > Author(s) : Q. Vohra, E. Chen > Filename : draft-chen-rfc4893bis-03.txt > Pages : 11 > Date : 2009-04-17 > > Currently the Autonomous System (AS) number is encoded as a two-octet > entity in BGP. This document describes extensions to BGP to carry the > Autonomous System number as a four-octet entity. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-rfc4893bis-03.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. > > > > --------------060908010706000402010405 > Content-Type: Message/External-body; > name="draft-chen-rfc4893bis-03.txt" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="draft-chen-rfc4893bis-03.txt" > > Content-Type: text/plain > Content-ID: <2009-04-17135914.I-D@ietf.org> > > > > --------------060908010706000402010405 > 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 > > > --------------060908010706000402010405-- From root@core3.amsl.com Fri Apr 17 15: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 4BB443A6ABD; Fri, 17 Apr 2009 15: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: <20090417220001.4BB443A6ABD@core3.amsl.com> Date: Fri, 17 Apr 2009 15:00:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-rfc4893bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 22: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 : BGP Support for Four-octet AS Number Space Author(s) : Q. Vohra, E. Chen Filename : draft-ietf-idr-rfc4893bis-00.txt Pages : 11 Date : 2009-04-17 Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-rfc4893bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-17144848.I-D@ietf.org> --NextPart-- From samitac@ipinfusion.com Fri Apr 17 15:06:07 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 B829D3A68DF for ; Fri, 17 Apr 2009 15:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 KujuHNlswG9Z for ; Fri, 17 Apr 2009 15:06:06 -0700 (PDT) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by core3.amsl.com (Postfix) with SMTP id B6A773A69C4 for ; Fri, 17 Apr 2009 15:05:58 -0700 (PDT) Received: from [68.142.194.244] by n14.bullet.mail.mud.yahoo.com with NNFMP; 17 Apr 2009 22:07:12 -0000 Received: from [68.142.201.66] by t2.bullet.mud.yahoo.com with NNFMP; 17 Apr 2009 22:07:12 -0000 Received: from [127.0.0.1] by omp418.mail.mud.yahoo.com with NNFMP; 17 Apr 2009 22:07:12 -0000 X-Yahoo-Newman-Id: 663840.72452.bm@omp418.mail.mud.yahoo.com Received: (qmail 54939 invoked from network); 17 Apr 2009 22:07:12 -0000 Received: from unknown (HELO samitacD630) (samitac@65.223.109.250 with login) by smtp103.sbc.mail.sp1.yahoo.com with SMTP; 17 Apr 2009 22:07:11 -0000 X-YMail-OSG: sBMiBngVM1nHlcfLssh2UJqibnU7KI9jeinBfeeTT7R.6O9abFQJLqu4_lIwU_jW0pIZhhDFmLw_za.YltF84omB5SrI7GzGIooy50OKQMz0JIbYCmrjhzAdu9fIeNA8.B6nuqgP3CASgsW5WLpsVZ1wB3dcn4WJ239JSV0b.ChAdJDm02ESHkpr6.S.s4lXhewIQA_d_5hcYt8jWzToly0d460UoRMNaS3v8B97GWCdHXTLNHsOXAg2PqYc7L3r6Vkm26QLANK23CDMgagxBSIHsw1Bl.NlF4Vo.rv.6ZLh630H X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'Enke Chen'" References: <065b01c9adba$56d5bc20$04813460$@com> <49E66D6E.6090001@cisco.com> In-Reply-To: <49E66D6E.6090001@cisco.com> Date: Fri, 17 Apr 2009 15:07:12 -0700 Message-ID: <013a01c9bfa8$dcaf0b80$960d2280$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm+IangOWVvXteqTNGMeDF4URqCigBhHN6Q Content-Language: en-us Cc: idr@ietf.org Subject: Re: [Idr] Clarification points for rfc4893-bis 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, 17 Apr 2009 22:06:07 -0000 Hi Enke, > How about the following addition in Section 4.1: > > When a NEW BGP speaker processes an OPEN message from another NEW BGP > speaker, it MUST take the Autonomous System number encoded in the Capability > Value field of the Capability in lieu of the "My Autonomous System" field of > the OPEN message. > [SC>] Looks good. > > Proposal for a NOTIFICATION message > > > > When two BGP speakers correspond with each other by sending AS_TRANS > > value in the 'My AS number' field, then the OPEN message MUST contain > > the 4-octet AS number capability option. If the 4-octet capability > > is missing in OPEN message where the 'My AS Number' field contains > > AS_TRANS value, a NEW BGP speaker-receiver SHOULD send a notification > > with code=2, subcode=2 [bad peer AS] to the sender of the OPEN > > message. > > We could be at the risk of over-specifying here. (Note that RFC 4271 does > not cover the possible misuse of reserved / non-allocated AS numbers.) [SC>] [SC>] I see that RFC4271 does not cover the misuse of reserved/non-allocated AS numbers and some deployments internally might be using AS_TRANS number in the OLD BGP speakers. But then at that time there was no concept of 4byte AS number either since RFC4271 assumes 2-byte AS value. The NEW BGP speakers anyway are not supposed to send/receive AS_TRANS in "My ASN" without the 4-byte capability - hence a notification makes sense during the OPEN message negotiation. It would be useful from debugging purpose in the field during transition. > > > > > > > Clarification on section 6 (Transition) > > > > How about some more text on PE-CE cases? Especially the AS_OVERRIDE > > issue as identified in > > > > http://www.ietf.org/proceedings/08mar/slides/idr-4/idr-4.htm [ Please > > check-out slide 11] > > > > As AS_OVERRIDE is something that is not covered in RFC 4271, I think that we > should leave it out due to the lack of background information / reference. > [SC>] We can always add some text for information in Appendix section if it does not belong to the body. Although it is not part of the main BGP(RFC 4271) specification, it will help the implementers to provide as wide spectrum as possible to plan for the implementation change. Thanks very much for your consideration. -Samita From enkechen@cisco.com Fri Apr 17 15:36:10 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 215E03A68D1 for ; Fri, 17 Apr 2009 15:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 S430EZ+98gL7 for ; Fri, 17 Apr 2009 15:36:08 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3B1153A68FE for ; Fri, 17 Apr 2009 15:35:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,206,1238976000"; d="scan'208";a="154524711" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 17 Apr 2009 22:37:07 +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 n3HMb7f8010597; Fri, 17 Apr 2009 15:37:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3HMb7vF026254; Fri, 17 Apr 2009 22:37:07 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 15:37:07 -0700 Received: from enke-linux.cisco.com ([128.107.130.57]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 15:37:06 -0700 Message-ID: <49E90492.6080800@cisco.com> Date: Fri, 17 Apr 2009 15:37:06 -0700 From: Enke Chen User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: Samita Chakrabarti References: <065b01c9adba$56d5bc20$04813460$@com> <49E66D6E.6090001@cisco.com> <013a01c9bfa8$dcaf0b80$960d2280$@com> In-Reply-To: <013a01c9bfa8$dcaf0b80$960d2280$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2009 22:37:06.0644 (UTC) FILETIME=[09809940:01C9BFAD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3283; t=1240007827; x=1240871827; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=enkechen@cisco.com; z=From:=20Enke=20Chen=20 |Subject:=20Re=3A=20Clarification=20points=20for=20rfc4893- bis |Sender:=20; bh=ACRRVcXKcAxT3AvJDzakUAQYO+buPgWdIz6u32OEKzA=; b=OI5J1JAoAc1WirVXI+Bf5oGGjS90vs21qh2+NGkTrJH+zrEX8eM64e94Ua AHxqG2P/NtEO7R4DS95faoRGT4PvZtZ8vkrR2hXnQBd/tBC1T+HdqrhBiBug bc9SJfQA1x; Authentication-Results: sj-dkim-4; header.From=enkechen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: idr@ietf.org Subject: Re: [Idr] Clarification points for rfc4893-bis 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, 17 Apr 2009 22:36:10 -0000 Hi, Samita: Samita Chakrabarti wrote: > Hi Enke, > > > [snip] >>> Proposal for a NOTIFICATION message >>> >>> When two BGP speakers correspond with each other by sending AS_TRANS >>> value in the 'My AS number' field, then the OPEN message MUST contain >>> the 4-octet AS number capability option. If the 4-octet capability >>> is missing in OPEN message where the 'My AS Number' field contains >>> AS_TRANS value, a NEW BGP speaker-receiver SHOULD send a notification >>> with code=2, subcode=2 [bad peer AS] to the sender of the OPEN >>> message. >>> >> We could be at the risk of over-specifying here. (Note that RFC 4271 does >> not cover the possible misuse of reserved / non-allocated AS numbers.) >> > [SC>] > [SC>] I see that RFC4271 does not cover the misuse of > reserved/non-allocated AS numbers and some deployments internally might be > using AS_TRANS number in the OLD BGP speakers. But then at that time there > was no concept of 4byte AS number either since RFC4271 assumes 2-byte AS > value. > The NEW BGP speakers anyway are not supposed to send/receive AS_TRANS in "My > ASN" without the 4-byte capability - hence a notification makes sense > during the OPEN message negotiation. It would be useful from debugging > purpose in the field during transition. > We can not mandate or change what an OLD speaker does :-) The revised text in draft-ietf-idr-rfc4893bis-00.txt makes it explicit that "My ASN" filed does not matter when the capability is carried in the OPEN: ---------------------------------------------------------------------- 4.1. Interaction Between NEW BGP Speakers A BGP speaker that supports 4-octet Autonomous System numbers SHOULD advertise this to its peers using the BGP Capability Advertisements. The Autonomous System number of the BGP speaker MUST be carried in the capability value field of the advertised capability. When a NEW BGP speaker processes an OPEN message from another NEW BGP speaker, it MUST use the Autonomous System number encoded in the Capability Value field of the Capability in lieu of the "My Autonomous System" field of the OPEN message. ----------------------------------------------------------------------- > > >>> Clarification on section 6 (Transition) >>> >>> How about some more text on PE-CE cases? Especially the AS_OVERRIDE >>> issue as identified in >>> >>> http://www.ietf.org/proceedings/08mar/slides/idr-4/idr-4.htm [ Please >>> check-out slide 11] >>> >>> >> As AS_OVERRIDE is something that is not covered in RFC 4271, I think that >> > we > >> should leave it out due to the lack of background information / reference. >> >> > > [SC>] We can always add some text for information in Appendix section if it > does not belong to the body. Although it is not part of the main BGP(RFC > 4271) specification, it will help the implementers to provide as wide > spectrum as possible to plan for the implementation change. > I am in favor of leaving the "exotic" features such as AS_OVERRIDE, AS_PREPEND, etc. to the implementation. Clearly an implementation needs to make the necessary changes when the AS number is enlarged. Thanks. -- Enke From Dimitri.Papadimitriou@alcatel-lucent.be Fri Apr 17 16:06: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 8D3C43A6A40 for ; Fri, 17 Apr 2009 16:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 C+GvX0tyvbbS for ; Fri, 17 Apr 2009 16:06:57 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 7632D3A6900 for ; Fri, 17 Apr 2009 16:06:57 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3HN86hD016262; Sat, 18 Apr 2009 01:08:06 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 18 Apr 2009 01:08:06 +0200 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: Sat, 18 Apr 2009 01:08:05 +0200 Message-ID: <00275A5B436CA441900CB10936742A380211741B@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54091BA6C7@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rfernando-idr-link-bandwidth-00.txt asIDR WGdocument Thread-Index: Acm9Uq3pqm1HkFFgRJ+Cro+26GtBRACIU/awAAHFnMA= References: <00275A5B436CA441900CB10936742A3801F86AFB@FRVELSMBS22.ad2.ad.alcatel.com> <00275A5B436CA441900CB10936742A38020B7831@FRVELSMBS22.ad2.ad.alcatel.com><49E4FA02.90209@raszuk.net><00275A5B436CA441900CB10936742A38020B7835@FRVELSMBS22.ad2.ad.alcatel.com> <49E511F3.4010706@raszuk.net> <04CAD96D4C5A3D48B1919248A8FE0D54091BA6C7@xmb-sjc-215.amer.cisco.com> From: "PAPADIMITRIOU Dimitri" To: "Pradosh Mohapatra (pmohapat)" , X-OriginalArrivalTime: 17 Apr 2009 23:08:06.0124 (UTC) FILETIME=[5DD6BAC0:01C9BFB1] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: Yakov Rekhter , idr@ietf.org Subject: Re: [Idr] draft-rfernando-idr-link-bandwidth-00.txt asIDR WGdocument 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, 17 Apr 2009 23:06:58 -0000 =20 Pradosh & Robert: > -----Original Message----- > From: Pradosh Mohapatra (pmohapat) [mailto:pmohapat@cisco.com]=20 > Sent: Friday, April 17, 2009 5:54 PM > To: robert@raszuk.net; PAPADIMITRIOU Dimitri > Cc: Yakov Rekhter; idr@ietf.org > Subject: RE: [Idr] draft-rfernando-idr-link-bandwidth-00.txt=20 > asIDR WGdocument >=20 > | >=20 > | > "When a BGP speaker receives multiple paths from its=20 > | internal peers,=20 > | > it could select more than one path to send traffic to. > | >=20 > | > [...] > | >=20 > | > The first scenario is when the candidate paths are=20 > | identical until and=20 > | > including the IGP distance step in the BGP decision process." > | >=20 > | > On the other hand, per 9.1.2.2 (4271) a speaker "selects"=20 > | only one of=20 > | > these routes for inclusion in the associated Loc-RIB=20 > | (reaching point f=20 > | > the BGP ID tie breaker and subsequent applies). > |=20 > | Well I see your point. 4271 does not talk about multipath.=20 > | And neither this draft :) This draft just enhances the multipath. This is what I point out in the original post. > | The multipath alone as local box implementation matter may=20 > | have not been spec-ed out as such. This is the point you are=20 > | perhaps questioning. > |=20 > | If you are correct. The draft enhancing "multipath" should=20 > | either define what it is or bring the reference to other=20 > | document defining it. And such definition does not need to be=20 > | a poem. It will just suffice to include one paragraph on what=20 > | makes a path a multipath candidate and what are the=20 > | exceptions if you have tunneled core deployed. This is the necessary but sufficient condition to have the mechanism specified in this document "interoperable". I mean in the sense that independently of the actual implementation of the procedure itself, for identical preconditions, the postconditions (that indicates the state changes by invoking this procedure) must be identical.=20 > | > Wouldn't it be worth clarifying this "implicit relaxation"=20 > | of the > selection rule (as a protocol specifies=20 > | messages/format but also > procedures) ? > |=20 > | Agreed. That would/should be part of general multipath definition. >=20 > I agree. If there is enough interest to document generic multipath > mechanism, we should start a separate conversation. This document > is specific to link bandwidth for internal paths and we have listed > the criteria for selecting the multipaths in the revised version. Indeed, but a criterion is by definition the element on which a decision process is based (toward an intended objective). Hence, criterion and decision process are intrisically related. Note also as it is not defined elsewhere, it can not be referenced. -dimitri. > - Pradosh >=20 From john@jlc.net Sat Apr 18 17:50:21 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 364FF3A6C0F for ; Sat, 18 Apr 2009 17:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=0.923, 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 F40WTfMsfVlk for ; Sat, 18 Apr 2009 17:50:20 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 66B1B3A6C02 for ; Sat, 18 Apr 2009 17:50:20 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8516A33C30; Sat, 18 Apr 2009 20:51:33 -0400 (EDT) Date: Sat, 18 Apr 2009 20:51:33 -0400 From: John Leslie To: idr@ietf.org Message-ID: <20090419005133.GA77973@verdi> References: <20090417220001.4BB443A6ABD@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090417220001.4BB443A6ABD@core3.amsl.com> User-Agent: Mutt/1.4.1i Subject: Re: [Idr] I-D Action:draft-ietf-idr-rfc4893bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 00:50:21 -0000 Internet-Drafts@ietf.org wrote: > > Title : BGP Support for Four-octet AS Number Space > Author(s) : Q. Vohra, E. Chen > Filename : draft-ietf-idr-rfc4893bis-00.txt > Pages : 11 > Date : 2009-04-17 > > Currently the Autonomous System (AS) number is encoded as a two-octet > entity in BGP. This document describes extensions to BGP to carry the > Autonomous System number as a four-octet entity. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc4893bis-00.txt Under 4893bis, it is clearly possible that a NEW speaker may encounter a (4-byte) AS_PATH that contains AS_TRANS. I believe 4893bis calls for that to never match a NEW speaker's ASN. To reduce confusion, I suggest adding the following text: " " Loop-detection is an important feature of BGP, and implementors " may question whether AS_TRANS should match every ASN > 65535 to " ensure loops are detected. There are two loop-detection issues: " " 1) Routing-information-loops can fill the RIB and cause a router " to fail; " " 2) Forwarding-loops can cause packets to follow the forwarding " loop until TTL is exhausted. " " Routing-information-loops will necessarily be detected by some " ASN < 65536 speaker, so matching AS_TRANS to any ASN > 65535 is " unnecessary to avoid these. " " Forwarding-loops are not necessarily correlated with the AS_PATH " information, and will generally primarily affect one "weak-link" " router within the loop. OTOH, matching AS_TRANS to every " ASN > 65535 would sometimes cause particular CIDR blocks to become " unreachable. " " Thus, matching AS_TRANS to every ASN > 65535 is not recommended. " Implementors may wish to consider a configuration switch to enable " such matching for "weak-link" routers, but any such switch should " default to OFF. -- John Leslie From paul@jakma.org Sun Apr 19 03:46:38 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 B1DB73A69B0 for ; Sun, 19 Apr 2009 03:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 TetcURkQEhAk for ; Sun, 19 Apr 2009 03:46:38 -0700 (PDT) Received: from hibernia.jakma.org (cl-9.dub-01.ie.sixxs.net [IPv6:2001:770:100:8::2]) by core3.amsl.com (Postfix) with ESMTP id A00A63A69AB for ; Sun, 19 Apr 2009 03:46:37 -0700 (PDT) Received: from melandri.gla.jakma.org (melandri.jakma.org [81.168.24.37]) (authenticated bits=0) by hibernia.jakma.org (8.14.3/8.14.2) with ESMTP id n3JAlVH7032329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Apr 2009 11:47:48 +0100 Date: Sun, 19 Apr 2009 11:47:30 +0100 (BST) From: Paul Jakma X-X-Sender: paul@localhost.localdomain To: John Leslie In-Reply-To: <20090419005133.GA77973@verdi> Message-ID: References: <20090417220001.4BB443A6ABD@core3.amsl.com> <20090419005133.GA77973@verdi> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Mail-Copies-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.1.1 (hibernia.jakma.org [212.17.55.49]); Sun, 19 Apr 2009 11:47:49 +0100 (IST) Cc: idr@ietf.org Subject: Re: [Idr] I-D Action:draft-ietf-idr-rfc4893bis-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 10:46:38 -0000 On Sat, 18 Apr 2009, John Leslie wrote: > " Routing-information-loops will necessarily be detected by some s/necessarily/likely/ > " ASN < 65536 speaker, so matching AS_TRANS to any ASN > 65535 is > " unnecessary to avoid these. s/.*/probably \0/ As far as I know, there is no /harm/ in early-catching of these cases. I'm mystified why people would argue that it shouldn't be done. But hey.. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Everything can be filed under "miscellaneous". From yakov@juniper.net Tue Apr 21 13:29:08 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 32D8228C19B for ; Tue, 21 Apr 2009 13:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 x2Mq2H+9Qqwh for ; Tue, 21 Apr 2009 13:29:07 -0700 (PDT) Received: from chip3og50.obsmtp.com (chip3og50.obsmtp.com [64.18.14.165]) by core3.amsl.com (Postfix) with ESMTP id 160703A7061 for ; Tue, 21 Apr 2009 13:29:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob50.postini.com ([64.18.6.12]) with SMTP ID DSNKSe4s32ysdecfKGC7O6K5+9lVP7BDxQMI@postini.com; Tue, 21 Apr 2009 13:30:24 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 21 Apr 2009 13:16:12 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 13:16:13 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 13:16:12 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 13:16:12 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3LKGAM79414 for ; Tue, 21 Apr 2009 13:16:11 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200904212016.n3LKGAM79414@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51059.1240344970.1@juniper.net> Date: Tue, 21 Apr 2009 13:16:10 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 21 Apr 2009 20:16:12.0228 (UTC) FILETIME=[03EE1840:01C9C2BE] Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document 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, 21 Apr 2009 20:29:08 -0000 Folks, While we had a fair amount of e-mail exchange related to draft-rosen-idr-aigp-00.txt, it is not clear whether we have a consensus on adopting it as an IDR WG document. To reach a closure on this, I would like to ask you to send either "yes" or "no" e-mail ("yes" means accept, "no" means do not accept). The deadline is May 6, 2009. Also, keep in mind that silence counts as a lack of interest, and a lack of interest means that that the document should not be adopted as an IDR WG document. Yakov. ------- Forwarded Message Date: Wed, 25 Mar 2009 06:51:28 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Folks, We received a request to accept draft-rosen-idr-aigp-00.txt as an IDR WG document. The deadline for comments on this request is April 8, 2009. If anyone is aware of the IPR related to the draft, please follow the procedurs of rfc3979. Yakov. - ------- Forwarded Message Date: Tue, 24 Mar 2009 22:09:29 -0700 From: "Pradosh Mohapatra (pmohapat)" To: "idr" Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document The authors would like to request that draft-rosen-idr-aigp-00.txt be adopted as an IDR WG document. We presented it yesterday @ IDR. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr - ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message From yakov@juniper.net Tue Apr 21 13:57:11 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 0558228C325 for ; Tue, 21 Apr 2009 13:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 DQrudngWeKKe for ; Tue, 21 Apr 2009 13:57:10 -0700 (PDT) Received: from chip3og57.obsmtp.com (chip3og57.obsmtp.com [64.18.14.179]) by core3.amsl.com (Postfix) with ESMTP id C617828C320 for ; Tue, 21 Apr 2009 13:57:09 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob57.postini.com ([64.18.6.12]) with SMTP ID DSNKSe4zZrjnwH5IRuImCV3IZlzqx7sebGwY@postini.com; Tue, 21 Apr 2009 13:58:27 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Tue, 21 Apr 2009 13:44:13 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 13:44:14 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 13:44:13 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 13:44:13 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n3LKiDM94817 for ; Tue, 21 Apr 2009 13:44:13 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200904212044.n3LKiDM94817@magenta.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <55461.1240346653.1@juniper.net> Date: Tue, 21 Apr 2009 13:44:13 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 21 Apr 2009 20:44:13.0076 (UTC) FILETIME=[EDCB2540:01C9C2C1] Subject: [Idr] flow-spec rule ordering - WG LC 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, 21 Apr 2009 20:57:11 -0000 Folks, This is to complete the IDR WG Last Call on the cnages made to the flowspec draft (07 version). We received no objections to the changes. Yakov. ------- Forwarded Message Date: Mon, 06 Apr 2009 11:05:15 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] flow-spec rule ordering Folks, This is to start the IDR WG Last Call on the changes made to the flowspec draft (07 version), as described below. Note that the scope of this Last Call is limited to just these changes, and *nothing else*. This Last Call ends April 20, 2009. Yakov. - ------- Forwarded Message Date: Mon, 06 Apr 2009 10:58:13 -0700 From: Pedro Marques To: Subject: [Idr] flow-spec rule ordering The more recent draft (07) has a change in the rule ordering text. Given that the document has passed last call the chairs and IESG believe that there should be last call on this specific change. Before The previous text implied that on when applying filters, least specific destination IP addresses in destination and source prefix would have priority. The most recent document: - - - More specific IP destination/source prefixes have priority. e.g. If the following rules are present rule 1 destination prefix 10.0.1/24 rule 2 destination prefix 10.0.1.1/32 rule 3 destination prefix 10.0.1/24 source prefix 20.0/16 rule 4 destination prefix 10.0.1/24 source prefix 20.0.1/24 With the previous text the order of rules would be: [1, 2, 3, 4] With the 07 text the order is: [2, 4, 3, 1] Please look at the complete text in the document and raise any concerns that you may have. thanks, Pedro. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr - ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message From root@core3.amsl.com Tue Apr 21 16: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 17EBB3A68BD; Tue, 21 Apr 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: <20090421230002.17EBB3A68BD@core3.amsl.com> Date: Tue, 21 Apr 2009 16:00:02 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-link-bandwidth-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: Tue, 21 Apr 2009 23: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 Link Bandwidth Extended Community Author(s) : P. Mohapatra, R. Fernando Filename : draft-ietf-idr-link-bandwidth-00.txt Pages : 5 Date : 2009-04-21 This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-link-bandwidth-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-link-bandwidth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-21155517.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Apr 21 16: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 A453128C343; Tue, 21 Apr 2009 16: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: <20090421233001.A453128C343@core3.amsl.com> Date: Tue, 21 Apr 2009 16:30:01 -0700 (PDT) Cc: idr@ietf.org Subject: [Idr] I-D Action:draft-ietf-idr-flow-spec-08.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: Tue, 21 Apr 2009 23: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 : Dissemination of flow specification rules Author(s) : P. Roque Marques, et al. Filename : draft-ietf-idr-flow-spec-08.txt Pages : 24 Date : 2009-04-21 This document defines a new BGP NLRI encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more-specific components of the traffic aggregate defined by an IP destination prefix. Additionally it defines two applications of that encoding format. One that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial of service attacks. And a second application to traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the Border Gateway Protocol (BGP), thereby reusing protocol algorithms, operational experience and administrative processes such as inter-provider peering agreements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-idr-flow-spec-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-21162123.I-D@ietf.org> --NextPart-- From prvs=356bcd5ee=jheitz@redback.com Wed Apr 22 14:39:45 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 989813A6FB0 for ; Wed, 22 Apr 2009 14:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 2fPEquflZozn for ; Wed, 22 Apr 2009 14:39:45 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id F35763A6C2E for ; Wed, 22 Apr 2009 14:39:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,232,1239001200"; d="scan'208";a="1135888" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 22 Apr 2009 14:41:02 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 36EBBBC040F for ; Wed, 22 Apr 2009 14:41:02 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30969-06 for ; Wed, 22 Apr 2009 14:41:02 -0700 (PDT) Received: from [155.53.112.59] (unknown [155.53.112.59]) by prattle.redback.com (Postfix) with ESMTP id C2CB51BBE81 for ; Wed, 22 Apr 2009 14:41:01 -0700 (PDT) Message-ID: <49EF8EED.9060803@redback.com> Date: Wed, 22 Apr 2009 14:41:01 -0700 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Idr] AS number in draft-marques-idr-best-external-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: Wed, 22 Apr 2009 21:41:38 -0000 draft-marques-idr-best-external-01.txt section 2 describes a table of routes with AS numbers and how to group them by AS number to find the best external. What is that AS number? Is it the AS number of the peer from which the update message was received or something else? How is the AS relevant to determine if the route was received from inside or outside the cluster? -- Jakob Heitz. From pmohapat@cisco.com Wed Apr 22 23:37:36 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 391C83A6C8D for ; Wed, 22 Apr 2009 23:37:36 -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 JO-12CCJtyS9 for ; Wed, 22 Apr 2009 23:37:35 -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 40B473A6BBD for ; Wed, 22 Apr 2009 23:37:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,234,1238976000"; d="scan'208";a="175644434" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 23 Apr 2009 06:38:53 +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 n3N6criZ030258; Wed, 22 Apr 2009 23:38:53 -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.13.8) with ESMTP id n3N6cr55017614; Thu, 23 Apr 2009 06:38:53 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.1830); Wed, 22 Apr 2009 23:38:52 -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: Wed, 22 Apr 2009 23:38:51 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540925079F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <49EF8EED.9060803@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] AS number in draft-marques-idr-best-external-01.txt Thread-Index: AcnDk2HQSOceXdEwTPyH3Qw2txmpOAASlqdQ References: <49EF8EED.9060803@redback.com> From: "Pradosh Mohapatra (pmohapat)" To: "Jakob Heitz" , X-OriginalArrivalTime: 23 Apr 2009 06:38:52.0769 (UTC) FILETIME=[2AF5FD10:01C9C3DE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=611; t=1240468733; x=1241332733; 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]=20AS=20number=20in=20draft-marque s-idr-best-external-01.txt |Sender:=20; bh=/IUUesPb3Z32fJxHqPNsGUo/Q72M3AOUqs7YnsjkC2U=; b=FhCO2disQHnYwzY1OzbLGDPaIPERUl4in7fGbT46zxmyuWjx/RfAbAso5Q /fbxPldCTPBOLsXdCauSZJiarLSYkHwXOLvJ7hBh7mu3+TPv3h2xwfzmLqp/ TZWV9bgZKG; Authentication-Results: sj-dkim-3; header.From=pmohapat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Idr] AS number in draft-marques-idr-best-external-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: Thu, 23 Apr 2009 06:37:36 -0000 Hi Jakob, | draft-marques-idr-best-external-01.txt section 2 describes a=20 | table of routes with AS numbers and how to group them by AS=20 | number to find the best external. |=20 | What is that AS number? Is it the AS number of the peer from=20 | which the update message was received or something else? Yes, it is the peer AS number. The significance of peer AS is for MED comparison rules. | How is the AS relevant to determine if the route was received=20 | from inside or outside the cluster? It is not relevant to determine routes internal or external to a RR cluster. - Pradosh From uttaro@att.com Thu Apr 23 03: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 BB08E3A723B for ; Thu, 23 Apr 2009 03:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.282 X-Spam-Level: X-Spam-Status: No, score=-106.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv7MTlEkZfwe for ; Thu, 23 Apr 2009 03:24:25 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id EE40A3A7217 for ; Thu, 23 Apr 2009 03:24:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: uttaro@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1240482341!34812603!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 26111 invoked from network); 23 Apr 2009 10:25:42 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-8.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Apr 2009 10:25:42 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3NAPfjl029009; Thu, 23 Apr 2009 06:25:41 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3NAPY0e028970; Thu, 23 Apr 2009 06:25:35 -0400 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: Thu, 23 Apr 2009 06:25:34 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD701E9B7C6@misout7msgusr7e.ugd.att.com> In-Reply-To: <200904212016.n3LKGAM79414@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcnCwAoGFQKo2rg4SumWrxeo7E2d7QBPbsog References: <200904212016.n3LKGAM79414@magenta.juniper.net> From: "UTTARO, JAMES, ATTLABS" To: "Yakov Rekhter" , Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document 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, 23 Apr 2009 10:24:25 -0000 Yes.. Jim Uttaro=20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Yakov Rekhter Sent: Tuesday, April 21, 2009 4:16 PM To: idr@ietf.org Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Folks, While we had a fair amount of e-mail exchange related to draft-rosen-idr-aigp-00.txt, it is not clear whether we have a consensus on adopting it as an IDR WG document. To reach a closure on this, I would like to ask you to send either "yes" or "no" e-mail ("yes" means accept, "no" means do not accept). The deadline is May 6, 2009. Also, keep in mind that silence counts as a lack of interest, and a lack of interest means that that the document should not be adopted as an IDR WG document. Yakov. ------- Forwarded Message Date: Wed, 25 Mar 2009 06:51:28 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Folks, We received a request to accept draft-rosen-idr-aigp-00.txt as an IDR WG document. The deadline for comments on this request is April 8, 2009. If anyone is aware of the IPR related to the draft, please follow the procedurs of rfc3979. Yakov. - ------- Forwarded Message Date: Tue, 24 Mar 2009 22:09:29 -0700 From: "Pradosh Mohapatra (pmohapat)" To: "idr" Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document The authors would like to request that draft-rosen-idr-aigp-00.txt be adopted as an IDR WG document. We presented it yesterday @ IDR. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr - ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From neil@domino.org Thu Apr 23 12:12:52 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 A0B133A6FA9 for ; Thu, 23 Apr 2009 12:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.283 X-Spam-Level: X-Spam-Status: No, score=0.283 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 2wSqewG187Ro for ; Thu, 23 Apr 2009 12:12:51 -0700 (PDT) Received: from php.domino.org (jail0080.vps.exonetric.net [82.138.248.198]) by core3.amsl.com (Postfix) with ESMTP id C11C93A68FB for ; Thu, 23 Apr 2009 12:12:51 -0700 (PDT) Received: from Inbox (unknown [149.254.216.5]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by php.domino.org (Postfix) with ESMTP id 2EED1A6F7D; Thu, 23 Apr 2009 20:14:00 +0100 (BST) MIME-Version: 1.0 content-class: From: "Neil J. McRae" Date: Thu, 23 Apr 2009 20:14:38 +0100 Importance: normal X-Priority: 3 To: Yakov Rekhter , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Message-Id: <20090423191401.2EED1A6F7D@php.domino.org> Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document 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, 23 Apr 2009 19:12:52 -0000 No. -----Original Message----- From: Yakov Rekhter Sent: 21 April 2009 21:16 To: idr@ietf.org Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Folks, While we had a fair amount of e-mail exchange related to draft-rosen-idr-aigp-00.txt, it is not clear whether we have a consensus on adopting it as an IDR WG document. To reach a closure on this, I would like to ask you to send either "yes" or "no" e-mail ("yes" means accept, "no" means do not accept). The deadline is May 6, 2009. Also, keep in mind that silence counts as a lack of interest, and a lack of interest means that that the document should not be adopted as an IDR WG document. Yakov. ------- Forwarded Message Date: Wed, 25 Mar 2009 06:51:28 -0700 From: Yakov Rekhter To: idr@ietf.org Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Folks, We received a request to accept draft-rosen-idr-aigp-00.txt as an IDR WG document. The deadline for comments on this request is April 8, 2009. If anyone is aware of the IPR related to the draft, please follow the procedurs of rfc3979. Yakov. - ------- Forwarded Message Date: Tue, 24 Mar 2009 22:09:29 -0700 From: "Pradosh Mohapatra (pmohapat)" To: "idr" Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document The authors would like to request that draft-rosen-idr-aigp-00.txt be adopted as an IDR WG document. We presented it yesterday @ IDR. _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr - ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From mprodrigues@juniper.net Sun Apr 26 19:05:38 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 AE2EB3A67B5 for ; Sun, 26 Apr 2009 19:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 0r+kJ0tQLjl0 for ; Sun, 26 Apr 2009 19:05:37 -0700 (PDT) Received: from chip3og62.obsmtp.com (chip3og62.obsmtp.com [64.18.14.201]) by core3.amsl.com (Postfix) with ESMTP id A16003A6A7E for ; Sun, 26 Apr 2009 19:05:37 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob62.postini.com ([64.18.6.12]) with SMTP ID DSNKSfUTQeNlgfEHCECozb0eOzPZke8IwW1/@postini.com; Sun, 26 Apr 2009 19:06:58 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Sun, 26 Apr 2009 19:04:58 -0700 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 19:04:58 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Apr 2009 19:04:58 -0700 Received: from emailwf3.jnpr.net ([10.10.2.45]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Apr 2009 22:04:56 -0400 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: Sun, 26 Apr 2009 22:04:54 -0400 Message-ID: <295627243C91274CBCE3C52BBB7E3D8602918CFF@emailwf3.jnpr.net> In-Reply-To: <200904212016.n3LKGAM79414@magenta.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document Thread-Index: AcnCwAcbXCYNn5Z7T2aJ8p2V6gLiUQEHH1Uw References: <200904212016.n3LKGAM79414@magenta.juniper.net> From: Marco Rodrigues To: "Yakov Rekhter" , X-OriginalArrivalTime: 27 Apr 2009 02:04:56.0237 (UTC) FILETIME=[8FAD3DD0:01C9C6DC] Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document 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, 27 Apr 2009 02:05:38 -0000 Yes. -mpr > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > Yakov Rekhter > Sent: Tuesday, April 21, 2009 4:16 PM > To: idr@ietf.org > Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document >=20 > Folks, >=20 > While we had a fair amount of e-mail exchange related to > draft-rosen-idr-aigp-00.txt, it is not clear whether we have a > consensus on adopting it as an IDR WG document. >=20 > To reach a closure on this, I would like to ask you to send either > "yes" or "no" e-mail ("yes" means accept, "no" means do not accept). > The deadline is May 6, 2009. >=20 > Also, keep in mind that silence counts as a lack of interest, and > a lack of interest means that that the document should not be adopted > as an IDR WG document. >=20 > Yakov. > ------- Forwarded Message >=20 > Date: Wed, 25 Mar 2009 06:51:28 -0700 > From: Yakov Rekhter > To: idr@ietf.org > Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document >=20 > Folks, >=20 > We received a request to accept draft-rosen-idr-aigp-00.txt as an > IDR WG document. The deadline for comments on this request is April > 8, 2009. >=20 > If anyone is aware of the IPR related to the draft, please follow > the procedurs of rfc3979. >=20 > Yakov. > - ------- Forwarded Message >=20 > Date: Tue, 24 Mar 2009 22:09:29 -0700 > From: "Pradosh Mohapatra (pmohapat)" > To: "idr" > Subject: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document >=20 > The authors would like to request that draft-rosen-idr-aigp-00.txt > be adopted as an IDR WG document. We presented it yesterday @ IDR. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > - ------- End of Forwarded Message >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > ------- End of Forwarded Message >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From erosen@cisco.com Mon Apr 27 06:19: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 75CEB3A6F79 for ; Mon, 27 Apr 2009 06:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 AymUr23dSIE3 for ; Mon, 27 Apr 2009 06:19:48 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7BAF33A69FA for ; Mon, 27 Apr 2009 06:19:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,254,1238976000"; d="scan'208";a="42804133" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Apr 2009 13:21:08 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3RDL8jE004788; Mon, 27 Apr 2009 09:21:08 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3RDL8ct005275; Mon, 27 Apr 2009 13:21:08 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n3RDL7Ll023583; Mon, 27 Apr 2009 09:21:08 -0400 To: Yakov Rekhter In-reply-to: Your message of Tue, 21 Apr 2009 13:16:10 -0700. <200904212016.n3LKGAM79414@magenta.juniper.net> Date: Mon, 27 Apr 2009 09:21:07 -0400 Message-ID: <23582.1240838467@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8; t=1240838468; x=1241702468; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20[Idr]=20draft-rosen-idr-aigp-00.txt=20a s=20IDR=20WG=20document=20 |Sender:=20 |To:=20Yakov=20Rekhter=20; bh=OmvpDLDealzZwz3ImLQ0qjJd1hhZs3VAg0OC5Yw2Z/c=; b=DfOFf0C9drwfSzsxCtRbjD3f0KXvwsGwFzllgUrAvrxWe+MfiwO2hTYkIQ rGplEuPfkRCC9Dmqw3zD+XP6OZiA6WiwnrUYw96eSPK3MaIQl4kx26NxYgik rwT/bFzkXQ; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: idr@ietf.org Subject: Re: [Idr] draft-rosen-idr-aigp-00.txt as IDR WG document X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 27 Apr 2009 13:19:49 -0000 Yes.