From idr-bounces@ietf.org Wed Feb 01 13:56:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4N9n-0004kQ-Nj; Wed, 01 Feb 2006 13:56:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4N9l-0004jF-Pr for idr@megatron.ietf.org; Wed, 01 Feb 2006 13:56:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22365 for ; Wed, 1 Feb 2006 13:54:55 -0500 (EST) Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4NKn-0008Sv-Fq for idr@ietf.org; Wed, 01 Feb 2006 14:08:08 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with ESMTP id <2006020118561001400kcudle>; Wed, 1 Feb 2006 18:56:10 +0000 Message-ID: <43E10488.7070804@tony.li> Date: Wed, 01 Feb 2006 10:57:12 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: idr@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Idr] Next revision of AS_HOPCOUNT X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi all, Surprisingly, my mailbox wasn't full this morning. For those that didn't notice, the next revision of the AS_HOPCOUNT draft (now AS_PATHLIMIT) has been released. Here's the link: http://www.ietf.org/internet-drafts/draft-ietf-idr-as-pathlimit-00.txt Please comment now... Given our previous discussions, I can't believe that there are no further comments. ;-) Regards, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Feb 01 20:32:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4TKl-0000Te-34; Wed, 01 Feb 2006 20:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4TKj-0000Qn-Fg for idr@megatron.ietf.org; Wed, 01 Feb 2006 20:32:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11147 for ; Wed, 1 Feb 2006 20:30:35 -0500 (EST) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4TVn-0003LU-0a for idr@ietf.org; Wed, 01 Feb 2006 20:43:52 -0500 Received: from h-68-164-152-195.snvacaid.dynamic.covad.net ([68.164.152.195] helo=earthlink.net) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F4TKT-00041a-00; Wed, 01 Feb 2006 20:32:09 -0500 Message-ID: <43E16315.312E28DB@earthlink.net> Date: Wed, 01 Feb 2006 17:40:37 -0800 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Tony Li References: <43E10488.7070804@tony.li> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: [Idr] draft-ietf-idr-as-pathlimit-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Tony Li, et al, 1) Do I implicitly read that this new will also limit looping paths to AS_PATHLIMIT? 2) 5.1 Operations If the AS_PATHLIMIT value exceeds the number of ASes found in the AS_PATH, then the route should not be sent. I must be dsylexic, I would think that you want the number of ASs found to be less or equal to the AS_PATH_LIMIT, Thus... If the number of ASs found in the AS_PATH exceeds the AS_PATHLIMIT value, then the route should not be forwarded. As this also seems backward.. If the attribute value exceeds the number of ASes in the AS_PATH, then the route MUST be ignored without further processing. 3a) Stupid question. Why isn't this AS_PATHLIMIT decremented at each BGP speaker who would examine the route, and when it reaches 0, then the route would be dropped? 3b) Another stupid question What prevents a BGP speaker from changing this value? Why would a speaker want to change the value or why shouldn't a speaker change this value? Mitchell Erblich Tony Li wrote: > > Hi all, > > Surprisingly, my mailbox wasn't full this morning. For those that > didn't notice, the next revision of the AS_HOPCOUNT draft (now > AS_PATHLIMIT) has been released. Here's the link: > > http://www.ietf.org/internet-drafts/draft-ietf-idr-as-pathlimit-00.txt > > Please comment now... Given our previous discussions, I can't believe > that there are no further comments. ;-) > > Regards, > Tony > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Feb 01 21:09:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4TuE-0008Se-Mk; Wed, 01 Feb 2006 21:09:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4TuC-0008OZ-5Z for idr@megatron.ietf.org; Wed, 01 Feb 2006 21:09:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13718 for ; Wed, 1 Feb 2006 21:07:26 -0500 (EST) Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4U5S-0004Wn-8k for idr@ietf.org; Wed, 01 Feb 2006 21:20:43 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with ESMTP id <200602020208420110038lqne>; Thu, 2 Feb 2006 02:08:44 +0000 Message-ID: <43E169E8.6000207@tony.li> Date: Wed, 01 Feb 2006 18:09:44 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Erblichs References: <43E10488.7070804@tony.li> <43E16315.312E28DB@earthlink.net> In-Reply-To: <43E16315.312E28DB@earthlink.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: [Idr] Re: draft-ietf-idr-as-pathlimit-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi, > 1) Do I implicitly read that this new will also > limit looping paths to AS_PATHLIMIT? I'm not sure I understand the question. The additional path attribute is in addition to all existing BGP attributes and mechanisms, and does not replace or supplant any of them. Thus, the normal AS_PATH loop detection should prevent all looping paths even without AS_PATHLIMIT. > 2) 5.1 Operations > If the > AS_PATHLIMIT value exceeds the number of ASes found in the AS_PATH, > then the route should not be sent. > > I must be dsylexic, I would think that you want the number of > ASs found to be less or equal to the AS_PATH_LIMIT, > > Thus... > > If the number of ASs found in the AS_PATH exceeds the > AS_PATHLIMIT value, then the route should not be forwarded. > > As this also seems backward.. > > If the attribute value exceeds the number of ASes in the > AS_PATH, then the route MUST be ignored without further processing. Dyslexia is all mine. Your corrections are what was intended. Sorry about that... > 3a) Stupid question. > > Why isn't this AS_PATHLIMIT decremented at each BGP speaker > who would examine the route, and when it reaches 0, then > the route would be dropped? Not stupid. The original version operated this way and the concerns about partial deployment and the subsequent fluctuating semantics led us to conclude that something a bit more deterministic would be preferred. Please see the mailing list archives for more discussion. > 3b) Another stupid question > > What prevents a BGP speaker from changing this value? Why > would a speaker want to change the value or why shouldn't > a speaker change this value? Right now, there is nothing that prevents a BGP speaker from modifying the value. This is also true for all other BGP attributes until such time as we have some type of cryptographic integrity check in place. There is currently no text here suggesting that an AS cannot modify this value, largely because this seems like something that we want to permit. An AS may well have a policy reason to impose its own limits. The only restriction that we felt was necessary was that any such advertisement should be marked as being originated by the proxy AS. Thus, the language was crafted to explicitly require the originating AS number and to permit deletion or replacement of the attribute. Regards, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Feb 03 03:30:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4wKk-0000XI-AG; Fri, 03 Feb 2006 03:30:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4wKh-0000MG-PP for idr@megatron.ietf.org; Fri, 03 Feb 2006 03:30:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04953 for ; Fri, 3 Feb 2006 03:28:37 -0500 (EST) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4wWA-0003qV-V8 for idr@ietf.org; Fri, 03 Feb 2006 03:42:11 -0500 Received: from h-68-164-152-195.snvacaid.dynamic.covad.net ([68.164.152.195] helo=earthlink.net) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F4wKU-0001bq-00; Fri, 03 Feb 2006 03:30:07 -0500 Message-ID: <43E30E61.7146DC49@earthlink.net> Date: Fri, 03 Feb 2006 00:03:45 -0800 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Tony Li References: <43E10488.7070804@tony.li> <43E16315.312E28DB@earthlink.net> <43E169E8.6000207@tony.li> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: [Idr] Re: draft-ietf-idr-as-pathlimit-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Tony Li, et al, Inline.. This is just a expectation. Mitchell Erblich Tony Li wrote: > > Hi, > > > 1) Do I implicitly read that this new will also > > limit looping paths to AS_PATHLIMIT? > > I'm not sure I understand the question. The additional path attribute > is in addition to all existing BGP attributes and mechanisms, and does > not replace or supplant any of them. Thus, the normal AS_PATH loop > detection should prevent all looping paths even without AS_PATHLIMIT. > I was thinking where the loop is sufficently large that the AS_PATHLIMIT is encountered before normal AS_PATH detection. Wouldn't it then implicitly also duty as an additional means to stop larger loops? Thus, I associate AS_PATHLIMIT equal to a TTL size and decrementing by 1 at each BGP speaker. Thus, am I right that no loops can completely form (loop onto itself) that are larger than AS_PATHLIMIT? Somehow, I think this is a good thing.. But during transient routing loops distances between Provider Edege boundries may increase and the AS_PATHLIMIT may be too short for the route to be propagated to the expected destination.. Mitchell Erblich > > 2) 5.1 Operations > > If the > > AS_PATHLIMIT value exceeds the number of ASes found in the AS_PATH, > > then the route should not be sent. > > > > I must be dsylexic, I would think that you want the number of > > ASs found to be less or equal to the AS_PATH_LIMIT, > > > > Thus... > > > > If the number of ASs found in the AS_PATH exceeds the > > AS_PATHLIMIT value, then the route should not be forwarded. > > > > As this also seems backward.. > > > > If the attribute value exceeds the number of ASes in the > > AS_PATH, then the route MUST be ignored without further processing. > > Dyslexia is all mine. Your corrections are what was intended. Sorry > about that... > > > 3a) Stupid question. > > > > Why isn't this AS_PATHLIMIT decremented at each BGP speaker > > who would examine the route, and when it reaches 0, then > > the route would be dropped? > > Not stupid. > > The original version operated this way and the concerns about partial > deployment and the subsequent fluctuating semantics led us to conclude > that something a bit more deterministic would be preferred. Please see > the mailing list archives for more discussion. > > > 3b) Another stupid question > > > > What prevents a BGP speaker from changing this value? Why > > would a speaker want to change the value or why shouldn't > > a speaker change this value? > > Right now, there is nothing that prevents a BGP speaker from modifying > the value. This is also true for all other BGP attributes until such > time as we have some type of cryptographic integrity check in place. > > There is currently no text here suggesting that an AS cannot modify this > value, largely because this seems like something that we want to > permit. An AS may well have a policy reason to impose its own limits. > The only restriction that we felt was necessary was that any such > advertisement should be marked as being originated by the proxy AS. > Thus, the language was crafted to explicitly require the originating AS > number and to permit deletion or replacement of the attribute. > > Regards, > Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Feb 03 05:35:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4yHk-00050s-W6; Fri, 03 Feb 2006 05:35:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4yHj-00050A-GD for idr@megatron.ietf.org; Fri, 03 Feb 2006 05:35:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13928 for ; Fri, 3 Feb 2006 05:33:44 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4yTG-0007oc-O4 for idr@ietf.org; Fri, 03 Feb 2006 05:47:19 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc13) with ESMTP id <2006020310350301300pms1le>; Fri, 3 Feb 2006 10:35:03 +0000 Message-ID: <43E33212.3060902@tony.li> Date: Fri, 03 Feb 2006 02:36:02 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Erblichs Subject: Re: [Idr] Re: draft-ietf-idr-as-pathlimit-00.txt References: <43E10488.7070804@tony.li> <43E16315.312E28DB@earthlink.net> <43E169E8.6000207@tony.li> <43E30E61.7146DC49@earthlink.net> In-Reply-To: <43E30E61.7146DC49@earthlink.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi Mitchell, > I was thinking where the loop is sufficently large that the > AS_PATHLIMIT is encountered before normal AS_PATH detection. > > Wouldn't it then implicitly also duty as an additional means > to stop larger loops? Thus, I associate AS_PATHLIMIT equal to > a TTL size and decrementing by 1 at each BGP speaker. Well, in the sense that AS_PATHLIMIT restricts the path, it will stop all longer paths, both loops and non-loops. > Thus, am I right that no loops can completely form (loop onto itself) > that are larger than AS_PATHLIMIT? BGP already prevents all inter-AS loops from forming. AS_PATHLIMIT is only operating at the inter-AS level, so it will not do anything to prevent intra-AS transient loops. > Somehow, I think this is a good thing.. But during transient > routing loops distances between Provider Edege boundries may > increase and the AS_PATHLIMIT may be too short for the route > to be propagated to the expected destination.. Presumably, the transient routing loop is within an AS, as part of the IGP converging. Assuming that the duration is sufficiently short, this should not perturb BGP at all. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Feb 12 16:18:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8Oc1-0003L3-7x; Sun, 12 Feb 2006 16:18:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8Oc0-0003J5-4H for idr@megatron.ietf.org; Sun, 12 Feb 2006 16:18:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14840 for ; Sun, 12 Feb 2006 16:16:43 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8OpT-0006Sl-6D for idr@ietf.org; Sun, 12 Feb 2006 16:32:24 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k1CLIH1Z041882 for ; Sun, 12 Feb 2006 13:18:17 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1CLIH515593 for ; Sun, 12 Feb 2006 13:18:17 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200602122118.k1CLIH515593@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <73523.1139779097.1@juniper.net> Date: Sun, 12 Feb 2006 13:18:17 -0800 From: Yakov Rekhter X-Spam-Score: 2.4 (++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Idr] 2858bis and SNPA X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, If any of you has an implementation that uses the SNPA field of MP_REACH, please drop me an e-mail. If we would not get at least two reports of an implementation that uses the SNPA field within the next two weeks we'll need to assume that this field is not used, and therefore has to be deprecated as we move to Draft Standard. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Feb 13 12:54:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8hu7-0007NZ-Vc; Mon, 13 Feb 2006 12:54:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8hu6-0007ND-DJ for idr@megatron.ietf.org; Mon, 13 Feb 2006 12:54:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11107 for ; Mon, 13 Feb 2006 12:52:40 -0500 (EST) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8i7j-0000Lv-7p for idr@ietf.org; Mon, 13 Feb 2006 13:08:33 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id E0E651CC6; Mon, 13 Feb 2006 17:54:13 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 946kBmR3m0108Mo2; Mon, 13 Feb 2006 17:54:12 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 942kBmR3k0110Mo2; Mon, 13 Feb 2006 17:54:10 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Mon, 13 Feb 2006 17:54:10 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com gw3.EXCHPROD.USA.NET X-USANET-MsgId: XID000kBmR3k9507Xo2 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by gw3.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Feb 2006 10:54:09 -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 Subject: RE: [Idr] 2858bis and SNPA Date: Mon, 13 Feb 2006 10:54:06 -0700 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F02035228CA@VS4.EXCHPROD.USA.NET> Thread-Topic: [Idr] 2858bis and SNPA Thread-index: AcYwGl7XJkSvLeCBRkixINQ8ZCHkBQArAh8w From: "Susan Hares" To: "Yakov Rekhter" , X-OriginalArrivalTime: 13 Feb 2006 17:54:09.0780 (UTC) FILETIME=[7DBC7B40:01C630C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Yakov: One of our implementations use the SNPA field of MP_REACH.=20 Count 1.=20 Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Yakov Rekhter Sent: Sunday, February 12, 2006 4:18 PM To: idr@ietf.org Subject: [Idr] 2858bis and SNPA Folks, If any of you has an implementation that uses the SNPA field of MP_REACH, please drop me an e-mail. If we would not get at least two reports of an implementation that uses the SNPA field=20 within the next two weeks we'll need to assume that this field is not used, and therefore has to be deprecated as we move to Draft Standard. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Feb 15 00:18:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9F3f-0002J0-CD; Wed, 15 Feb 2006 00:18:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9F3d-0002Is-HN for idr@megatron.ietf.org; Wed, 15 Feb 2006 00:18:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07836 for ; Wed, 15 Feb 2006 00:16:43 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9FHM-0002Ii-1G for idr@ietf.org; Wed, 15 Feb 2006 00:32:55 -0500 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id VAA25683; Tue, 14 Feb 2006 21:18:03 -0800 (PST) Received: from pfloyd ([10.128.16.175]) by gondor.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 10:48:08 +0530 From: "Manav Bhatia" To: Date: Wed, 15 Feb 2006 10:48:05 +0530 Organization: Riverstone Networks Message-ID: <003401c631ef$33752da0$3a03a8c0@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYx7zNRy4AAGWgaTUarQbzGjokr/g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 15 Feb 2006 05:18:08.0885 (UTC) FILETIME=[355CB250:01C631EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [Idr] Multiple Paths in BGP X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi, Recently there have been proposals in the IDR to extend BGP to advertise multiple paths for a given NLRI. There are various applications that could use this - Passive Route Servers, Interdomain TE, ECMP, MED oscillations, Suboptimal routing with RRs, etc. We have written a draft that proposes a new path attribute MULTIPLE_HOP that can be used to advertise multiple paths in BGP. This draft has been built upon the feedback/suggestions that we received for the earlier versions of our ecmp draft. http://www.ietf.org/internet-drafts/draft-bhatia-bgp-multiple-next-hops-00.t xt We also propose a way for BGP speakers to legitimately do ECMP using the new path attribute defined in the above draft. http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in-bgp-02.txt Would appreciate comments on the above drafts. Thanks, Manav _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Feb 15 21:29:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9YtA-00042U-TG; Wed, 15 Feb 2006 21:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Yt9-00041D-43 for idr@megatron.ietf.org; Wed, 15 Feb 2006 21:28:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07299 for ; Wed, 15 Feb 2006 21:27:11 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Z7H-0007NL-Re for idr@ietf.org; Wed, 15 Feb 2006 21:43:36 -0500 Received: by zproxy.gmail.com with SMTP id 8so72827nzo for ; Wed, 15 Feb 2006 18:28:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=FW5OJgdKFmA0z9xSLyIGJ9Fkkj1HubrbL7dr7S5XmCIMR6GlEwWTF6TOuLjYXNlN2lD6FBz6LD2AaKYq3fGY1w3x0ma5BhKduq9jPsDkYhJHGcAnD33eOIEr9dNWh5TxPJOE2XlZ5DxNqWLxG2zKqh+mfdeXUOmItb3qcpgJWTE= Received: by 10.36.65.19 with SMTP id n19mr463686nza; Wed, 15 Feb 2006 18:28:57 -0800 (PST) Received: by 10.36.72.9 with HTTP; Wed, 15 Feb 2006 18:28:57 -0800 (PST) Message-ID: <6ed23a860602151828mf422d6ay@mail.gmail.com> Date: Thu, 16 Feb 2006 07:58:57 +0530 From: Tom Sanders To: idr@ietf.org Subject: RE: [Idr] Multiple Paths in BGP MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0726921575==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --===============0726921575== Content-Type: multipart/alternative; boundary="----=_Part_2088_28559601.1140056937424" ------=_Part_2088_28559601.1140056937424 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Recently there have been proposals in the IDR to extend BGP to advertise > multiple paths for a given NLRI. There are various applications that coul= d > use this - Passive Route Servers, Interdomain TE, ECMP, MED oscillations, > Suboptimal routing with RRs, etc. I read the drafts but could find nothing pertaining to Interdomain TE. How can the ideas presented in the draft help in doing Interdomain TE? Toms. > > We have written a draft that proposes a new path attribute MULTIPLE_HOP that > can be used to advertise multiple paths in BGP. This draft has been built > upon the feedback/suggestions that we received for the earlier versions o= f > our ecmp draft. > > http://www.ietf.org/internet-drafts/draft-bhatia-bgp-multiple-next-hops-00.= t > xt > > We also propose a way for BGP speakers to legitimately do ECMP using the new > path attribute defined in the above draft. > > http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in-bgp-02.tx= t > > Would appreciate comments on the above drafts. > > Thanks, > Manav > > > -- Toms. ------=_Part_2088_28559601.1140056937424 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

> Recently there have been proposals in the IDR to extend BGP t= o advertise
> multiple paths for a given NLRI. There are various appl= ications that could
> use this - Passive Route Servers, Interdomain T= E, ECMP, MED oscillations,=20
> Suboptimal routing with RRs, etc.
 
I read the drafts but could find nothing pertaining to Interdomain TE.= How can the ideas presented in the draft help in doing Interdomain TE?&nbs= p;
 
Toms.
 
>
> We have written a draft that proposes a new path attribu= te MULTIPLE_HOP that
> can be used to advertise multiple paths in BGP= . This draft has been built
> upon the feedback/suggestions that we r= eceived for the earlier versions of=20
> our ecmp draft.
>
> http://www.ietf.org= /internet-drafts/draft-bhatia-bgp-multiple-next-hops-00.t
> xt
>
> We also propose a way for BGP speakers to = legitimately do ECMP using the new
> path attribute defined in the ab= ove draft.
>
> http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in-bgp-02.txt<= /a>
>
> Would appreciate comments on the above drafts.
>=
> Thanks,
> Manav
>
>
>

--
Toms.
------=_Part_2088_28559601.1140056937424-- --===============0726921575== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============0726921575==-- From idr-bounces@ietf.org Thu Feb 16 02:22:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9dTd-0000nb-TT; Thu, 16 Feb 2006 02:22:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9dSg-0000Fa-EG for idr@megatron.ietf.org; Thu, 16 Feb 2006 02:21:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24176 for ; Thu, 16 Feb 2006 02:20:11 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9dgn-0008ET-LE for idr@ietf.org; Thu, 16 Feb 2006 02:36:38 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k1G7LcX26593; Wed, 15 Feb 2006 23:21:38 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1G7LX512316; Wed, 15 Feb 2006 23:21:33 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200602160721.k1G7LX512316@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94300.1140074493.1@juniper.net> Date: Wed, 15 Feb 2006 23:21:33 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Susan Hares , Stewart Bryant , Danny McPherson Subject: [Idr] WG Last Call on draft-ietf-l2vpn-signaling-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, WG Last Call on draft-ietf-l2vpn-signaling-06.txt is over. There has been no comments during the Last Call. Yakov. ------- Forwarded Message Date: Thu, 26 Jan 2006 10:20:32 -0800 From: Yakov Rekhter To: idr@ietf.org cc: Susan Hares , Danny McPherson , Stewart Bryant Subject: [Idr] WG Last Call on draft-ietf-l2vpn-signaling-06.txt Folks, This is to start the IDR WG Last Call on draft-ietf-l2vpn-signaling-06.txt (as this document has some BGP-related stuff). The Last Call ends Feb 10,2006. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Feb 16 02:24:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9dVP-0000xd-6x; Thu, 16 Feb 2006 02:24:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9dTs-0000q6-OP for idr@megatron.ietf.org; Thu, 16 Feb 2006 02:23:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24223 for ; Thu, 16 Feb 2006 02:21:25 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9di3-0008G7-3U for idr@ietf.org; Thu, 16 Feb 2006 02:37:52 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k1G7N0X26621; Wed, 15 Feb 2006 23:23:00 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1G7Ms512473; Wed, 15 Feb 2006 23:22:54 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200602160722.k1G7Ms512473@merlot.juniper.net> To: idr@ietf.org Subject: [Idr] WG Last Call on draft-ietf-l3vpn-bgpvpn-auto-06.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94317.1140074574.1@juniper.net> Date: Wed, 15 Feb 2006 23:22:54 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: skh@nexthop.com, Ronald Bonica , Rick Wilder , Ross Callon X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, The WG Last Call on draft-ietf-l3vpn-bgpvpn-auto-06.txt is over. There has been no comments on the document during the Last Call. Yakov. ------- Forwarded Message Date: Thu, 26 Jan 2006 18:24:38 -0800 From: Yakov Rekhter To: idr@ietf.org cc: skh@nexthop.com, Ronald Bonica , Rick Wilder , Ross Callon Folks, This is to start the IDR WG Last Call on draft-ietf-l3vpn-bgpvpn-auto-06.txt (as this document has some BGP-related stuff). The Last Call ends Feb 10,2006. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Feb 16 02:26:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9dX9-0001Be-KD; Thu, 16 Feb 2006 02:26:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9dVr-00014H-2f for idr@megatron.ietf.org; Thu, 16 Feb 2006 02:25:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24335 for ; Thu, 16 Feb 2006 02:23:27 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9dk1-0008Jr-2T for idr@ietf.org; Thu, 16 Feb 2006 02:39:54 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k1G7Ow1Z035926; Wed, 15 Feb 2006 23:24:58 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1G7Oj512670; Wed, 15 Feb 2006 23:24:45 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200602160724.k1G7Oj512670@merlot.juniper.net> To: idr@ietf.org Subject: [Idr] draft-ooms-v6ops-bgp-tunnel-06.txt to Proposed Standard MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94378.1140074685.1@juniper.net> Date: Wed, 15 Feb 2006 23:24:45 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Jeremy De Clercq , "Francois Le Faucheur \(flefauch\)" , "Eric Levy- Abegnoli \(elevyabe\)" , stuart.prevost@bt.com, dirk@onesparrow.com, Susan Hares X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Folks, The WG Last Call on draft-ooms-v6ops-bgp-tunnel-06.txt is over. There has been no comments on the document during the Last Call. I'll be sending an e-mail to the IESG requesting to advance the document to Proposed Standard. Yakov. ------- Forwarded Message Date: Tue, 31 Jan 2006 06:35:57 -0800 From: Yakov Rekhter To: idr@ietf.org cc: Jeremy De Clercq , "Francois Le Faucheur \(flefauch\)" , "Eric Levy- Abegnoli \(elevyabe\)" , stuart.prevost@bt.com, dirk@onesparrow.com, Susan Hares Subject: [Idr] draft-ooms-v6ops-bgp-tunnel-06.txt to Proposed Standard Folks, This is to start the IDR WG Last Call on advancing draft-ooms-v6ops-bgp-tunnel-06.txt to a Proposed Standard. The implementation report is in draft-levy-idr-6pe-survey-00.txt. The Last Call ends Feb 15, 2006. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Feb 16 02:29:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9dZk-0001UQ-Au; Thu, 16 Feb 2006 02:29:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9dYP-0001Iv-VR for idr@megatron.ietf.org; Thu, 16 Feb 2006 02:27:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24569 for ; Thu, 16 Feb 2006 02:26:06 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9dma-0008Re-BJ for idr@ietf.org; Thu, 16 Feb 2006 02:42:33 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k1G7RhX26719; Wed, 15 Feb 2006 23:27:43 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1G7RX513036; Wed, 15 Feb 2006 23:27:34 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200602160727.k1G7RX513036@merlot.juniper.net> To: Bill Fenner , Alex Zinin Subject: [Idr] draft-ooms-v6ops-bgp-tunnel-06.txt to Proposed Standard MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94457.1140074853.1@juniper.net> Date: Wed, 15 Feb 2006 23:27:33 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: skh@nexthop.com, idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Bill and Alex, This is to request the IESG to advance draft-ooms-v6ops-bgp-tunnel-06.txt to Proposed Standard. The implementation report is in draft-levy-idr-6pe-survey-00.txt. Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Feb 16 08:22:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9j57-0002jM-IZ; Thu, 16 Feb 2006 08:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9j55-0002hX-F1 for idr@megatron.ietf.org; Thu, 16 Feb 2006 08:21:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22111 for ; Thu, 16 Feb 2006 08:20:11 -0500 (EST) Received: from bay17-f15.bay17.hotmail.com ([64.4.43.65] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9jJG-0004hL-Sj for idr@ietf.org; Thu, 16 Feb 2006 08:36:42 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 Feb 2006 05:21:46 -0800 Message-ID: Received: from 66.77.218.147 by by17fd.bay17.hotmail.msn.com with HTTP; Thu, 16 Feb 2006 13:21:45 GMT X-Originating-IP: [59.145.141.130] X-Originating-Email: [johnsmith0302@hotmail.com] X-Sender: johnsmith0302@hotmail.com In-Reply-To: <6ed23a860602151828mf422d6ay@mail.gmail.com> From: "john smith" To: toms.sanders@gmail.com Subject: RE: [Idr] Multiple Paths in BGP Date: Thu, 16 Feb 2006 13:21:45 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 16 Feb 2006 13:21:46.0651 (UTC) FILETIME=[EFB626B0:01C632FB] X-Spam-Score: 1.7 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org use the reachability itself for interdomain........... >From: Tom Sanders >To: idr@ietf.org >Subject: RE: [Idr] Multiple Paths in BGP >Date: Thu, 16 Feb 2006 07:58:57 +0530 > > > Recently there have been proposals in the IDR to extend BGP to advertise > > multiple paths for a given NLRI. There are various applications that >could > > use this - Passive Route Servers, Interdomain TE, ECMP, MED >oscillations, > > Suboptimal routing with RRs, etc. > >I read the drafts but could find nothing pertaining to Interdomain TE. How >can the ideas presented in the draft help in doing Interdomain TE? > >Toms. > > > > > We have written a draft that proposes a new path attribute MULTIPLE_HOP >that > > can be used to advertise multiple paths in BGP. This draft has been >built > > upon the feedback/suggestions that we received for the earlier versions >of > > > our ecmp draft. > > > > >http://www.ietf.org/internet-drafts/draft-bhatia-bgp-multiple-next-hops-00.t > > xt > > > > We also propose a way for BGP speakers to legitimately do ECMP using the >new > > path attribute defined in the above draft. > > > > >http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in-bgp-02.txt > > > > Would appreciate comments on the above drafts. > > > > Thanks, > > Manav > > > > > > > >-- >Toms. >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www1.ietf.org/mailman/listinfo/idr _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Feb 17 10:04:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA74N-0005kB-Ua; Fri, 17 Feb 2006 09:58:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6rd-0007rm-Cp for idr@megatron.ietf.org; Fri, 17 Feb 2006 09:45:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00485 for ; Fri, 17 Feb 2006 08:59:19 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA1wk-0003zX-Ub for idr@ietf.org; Fri, 17 Feb 2006 04:30:45 -0500 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id BAA21657; Fri, 17 Feb 2006 01:15:31 -0800 (PST) Received: from manav ([10.128.16.143]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 01:15:37 -0800 Message-ID: <020001c633a3$839ae490$0201a8c0@manav> From: "Manav Bhatia" To: "Tom Sanders" , References: <6ed23a860602151828mf422d6ay@mail.gmail.com> Subject: Re: [Idr] Multiple Paths in BGP Date: Fri, 17 Feb 2006 14:51:13 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-OriginalArrivalTime: 17 Feb 2006 09:15:38.0396 (UTC) FILETIME=[B78F05C0:01C633A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org Hi Toms, If you consider using a PCE to aid in the establishment of interdomain LSPs, the PCE would need to collect all interdomain/intradomain routes. Because of the fact that BGP advertises only one best path (which is btw selected based on criterions not based on the QoS/TE parameters), there can be scenarios when a PCE would never get to learn about some of the paths that are available. Those paths would thus never be used by a PCE for computing the primary and the backup interdomain LSPs. With this draft, BGP speakers can advertise multiple paths using the MULTIPLE_HOP path attribute and a PCE can potentially use *all* the paths that are available. Olivier and Cristel should be able to give you more information on this. Thanks, Manav ----- Original Message ----- From: "Tom Sanders" To: Sent: Thursday, February 16, 2006 7:58 AM Subject: RE: [Idr] Multiple Paths in BGP > Recently there have been proposals in the IDR to extend BGP to advertise > multiple paths for a given NLRI. There are various applications that could > use this - Passive Route Servers, Interdomain TE, ECMP, MED oscillations, > Suboptimal routing with RRs, etc. I read the drafts but could find nothing pertaining to Interdomain TE. How can the ideas presented in the draft help in doing Interdomain TE? Toms. > > We have written a draft that proposes a new path attribute MULTIPLE_HOP that > can be used to advertise multiple paths in BGP. This draft has been built > upon the feedback/suggestions that we received for the earlier versions of > our ecmp draft. > > http://www.ietf.org/internet-drafts/draft-bhatia-bgp-multiple-next-hops-00.t > xt > > We also propose a way for BGP speakers to legitimately do ECMP using the new > path attribute defined in the above draft. > > http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in-bgp-02.txt > > Would appreciate comments on the above drafts. > > Thanks, > Manav > > > -- Toms. ---------------------------------------------------------------------------- ---- > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Feb 20 09:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBBwg-0002tK-Vv; Mon, 20 Feb 2006 09:23:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBBwg-0002tF-9p for idr@ietf.org; Mon, 20 Feb 2006 09:23:22 -0500 Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBBwe-00005e-Qf for idr@ietf.org; Mon, 20 Feb 2006 09:23:22 -0500 Received: from [130.104.230.51] (dufy [130.104.230.51]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id k1KELm0u007244; Mon, 20 Feb 2006 15:23:03 +0100 (MET) Message-ID: <43F9CF9F.1070102@info.ucl.ac.be> Date: Mon, 20 Feb 2006 15:18:07 +0100 From: Cristel Pelsser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 X-Accept-Language: en MIME-Version: 1.0 To: Manav Bhatia , idr@ietf.org Subject: Re: Fw: [Idr] Multiple Paths in BGP References: <028401c633aa$ced63700$0201a8c0@manav> In-Reply-To: <028401c633aa$ced63700$0201a8c0@manav> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-INGI-MailScanner-Information: Please contact the ISP for more information X-INGI-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: Olivier Bonaventure X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Manav, Your explanation is correct. Hi Tom and all, We have shown in a paper (http://www.info.ucl.ac.be/~cpe/Pelsser_IPOM.pdf ) and in an IETF draft (http://www.info.ucl.ac.be/~cpe/draft-pelsser-bgp-pce-00.txt ) that the BGP routes learned at a single BGP router are often not sufficient to be able to compute constrained interdomain paths. If a PCE receives all the BGP routes learned inside the AS it has more chances to find an interdomain path that respects given constraints than a simple BGP router. Thus, it is useful for a BGP router to distribute more than one route for each destination to the PCEs inside its AS. Best regards, Cristel Manav Bhatia wrote: >I hope this is correct! :) > >BTW, Would love to know your comments on this draft. Are there things that >you would want to added/modified/deleted in this draft and does this help >you in your purpose? > >Thanks, >Manav >----- Original Message ----- >From: "Manav Bhatia" >To: "Tom Sanders" ; >Sent: Friday, February 17, 2006 2:51 PM >Subject: Re: [Idr] Multiple Paths in BGP > > > > >>Hi Toms, >> >>If you consider using a PCE to aid in the establishment of interdomain >> >> >LSPs, > > >>the PCE would need to collect all interdomain/intradomain routes. >> >>Because of the fact that BGP advertises only one best path (which is btw >>selected based on criterions not based on the QoS/TE parameters), there >> >> >can > > >>be scenarios when a PCE would never get to learn about some of the paths >>that are available. Those paths would thus never be used by a PCE for >>computing the primary and the backup interdomain LSPs. >> >>With this draft, BGP speakers can advertise multiple paths using the >>MULTIPLE_HOP path attribute and a PCE can potentially use *all* the paths >>that are available. >> >>Olivier and Cristel should be able to give you more information on this. >> >>Thanks, >>Manav >> >>----- Original Message ----- >>From: "Tom Sanders" >>To: >>Sent: Thursday, February 16, 2006 7:58 AM >>Subject: RE: [Idr] Multiple Paths in BGP >> >> >> >> >>>Recently there have been proposals in the IDR to extend BGP to advertise >>>multiple paths for a given NLRI. There are various applications that >>> >>> >could > > >>>use this - Passive Route Servers, Interdomain TE, ECMP, MED >>> >>> >oscillations, > > >>>Suboptimal routing with RRs, etc. >>> >>> >>I read the drafts but could find nothing pertaining to Interdomain TE. How >>can the ideas presented in the draft help in doing Interdomain TE? >> >>Toms. >> >> >> >>>We have written a draft that proposes a new path attribute MULTIPLE_HOP >>> >>> >>that >> >> >>>can be used to advertise multiple paths in BGP. This draft has been >>> >>> >built > > >>>upon the feedback/suggestions that we received for the earlier versions >>> >>> >of > > >>>our ecmp draft. >>> >>> >>> >>> >http://www.ietf.org/internet-drafts/draft-bhatia-bgp-multiple-next-hops-00.t > > >>>xt >>> >>>We also propose a way for BGP speakers to legitimately do ECMP using the >>> >>> >>new >> >> >>>path attribute defined in the above draft. >>> >>> >>> >>> >http://www.ietf.org/internet-drafts/draft-bhatia-ecmp-routes-in-bgp-02.txt > > >>>Would appreciate comments on the above drafts. >>> >>>Thanks, >>>Manav >>> >>> >>> >>> >>> >>-- >>Toms. >> >> >> >>-------------------------------------------------------------------------- >> >> >-- > > >>---- >> >> >> >> >>>_______________________________________________ >>>Idr mailing list >>>Idr@ietf.org >>>https://www1.ietf.org/mailman/listinfo/idr >>> >>> >>> -- ''' (0 0) +-------oOO----(_)---------------+ | Cristel Pelsser | | http://www.info.ucl.ac.be/~cpe | +--------------------oOO---------+ |__|__| || || ooO Ooo _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Feb 21 18:50:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBhGj-0002qk-9I; Tue, 21 Feb 2006 18:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBhGd-0002p0-Gv; Tue, 21 Feb 2006 18:50:03 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBhGd-0008JX-1T; Tue, 21 Feb 2006 18:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k1LNo29W008707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FBhGc-00034J-7l; Tue, 21 Feb 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 21 Feb 2006 18:50:02 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-aspath-orf-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Aspath Based Outbound Route Filter for BGP-4 Author(s) : K. Patel, S. Hares Filename : draft-ietf-idr-aspath-orf-08.txt Pages : 4 Date : 2006-2-21 This document defines a new Outbound Router Filter type for BGP, termed "Aspath Outbound Route Filter", that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aspath-orf-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aspath-orf-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-21151432.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aspath-orf-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aspath-orf-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-21151432.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Thu Feb 23 18:10:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCPaJ-0002EW-6S; Thu, 23 Feb 2006 18:09:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCPaH-0002Dw-OP; Thu, 23 Feb 2006 18:09:17 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCPaG-0000Jo-IB; Thu, 23 Feb 2006 18:09:17 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1NN9DBX024291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2006 23:09:13 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FCPaD-0006sL-I3; Thu, 23 Feb 2006 18:09:13 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 23 Feb 2006 18:09:13 -0500 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: idr chair , idr mailing list , idr chair , Internet Architecture Board , RFC Editor Subject: [Idr] Protocol Action: 'Subcodes for BGP Cease Notification Message' to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org The IESG has approved the following document: - 'Subcodes for BGP Cease Notification Message ' as a Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Bill Fenner and Alex Zinin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-cease-subcode-07.txt Technical Summary This document defines several subcodes for the BGP Cease NOTIFICATION message that provide more information to aid network operators in correlating network events and diagnosing BGP peering issues. Working Group Summary The Working Group had consensus to publish this document as Proposed Standard. Protocol Quality Bill Fenner reviewed this document for the IESG. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Feb 23 21:03:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCSIF-0005ow-3A; Thu, 23 Feb 2006 21:02:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCSID-0005o1-PO; Thu, 23 Feb 2006 21:02:49 -0500 Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCSIC-0007Ks-I1; Thu, 23 Feb 2006 21:02:49 -0500 Received: from h-68-164-155-88.snvacaid.dynamic.covad.net ([68.164.155.88] helo=earthlink.net) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FCSIB-0002EJ-00; Thu, 23 Feb 2006 21:02:47 -0500 Message-ID: <43FE6B4D.3C37E177@earthlink.net> Date: Thu, 23 Feb 2006 18:11:25 -0800 From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: The IESG References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: idr chair , idr mailing list , idr chair , Internet Architecture Board , IETF-Announce , RFC Editor Subject: [Idr] Subcodes for BGP Cease Notification Message X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Group, I like to always ask some things after the fact. 4. Subcode Usage It is RECOMMENDED that a BGP speaker behave as though the DampPeerOscillations attribute [BGP-4] was true for this peer when re-trying a BGP connection after the speaker receives a Cease NOTIFICATION message with subcode of "Administrative Shutdown", or "Peer De-configured", or "Connection Rejected", or "Out of Resources". An implementation SHOULD impose an upper bound on the number of consecutive automatic retries. Once this bound is reached, the implementation would stop re-trying any BGP connections until some administrative intervention, i.e., set the AllowAutomaticStart attribute [BGP-4] to FALSE. ---- I understand RECOMMENDED, but would a multiplicative backoff algorithm be a better method of consective retries? Why wasn't this suggested/Recommended? IMO, for the later is iff case #1, some type of issue occured that lost all/most of TCP connections, all of the past peers would bombard the BGP speaker with repeated almost simultaneous connection retries. And Once a upper bound has been reached, why suggest administrative intervention versus a very long retry period? If this other implementation were used, wouldn't it still recover once the issue was resolved at the other BGP speaker without requiring manual intervention at a possibly non-local BGP speaker? Thanks, Mitchell Erblich _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Feb 24 02:25:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCXKm-0001vB-HN; Fri, 24 Feb 2006 02:25:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCXKk-0001t3-Du for idr@ietf.org; Fri, 24 Feb 2006 02:25:46 -0500 Received: from xproxy.gmail.com ([66.249.82.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCXKh-0000LW-UE for idr@ietf.org; Fri, 24 Feb 2006 02:25:46 -0500 Received: by xproxy.gmail.com with SMTP id t13so181408wxc for ; Thu, 23 Feb 2006 23:25:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hM6U5I5VPqeZ/qqIICqvDywuTCmVdwzUyIsakZbGzO8B6lizn37vuOq5j0Iq+mtpTyZvAQctUb35cgIE1LH5ignSekIKqSbO5zspXQ5NrwKkpfuhXiQgHJ59t36PLOYEPZRrjHnpHfpwtwIxmrUVSogsJ0mMSYovvCn31Feq/jE= Received: by 10.70.66.2 with SMTP id o2mr3242606wxa; Thu, 23 Feb 2006 23:25:43 -0800 (PST) Received: by 10.70.69.6 with HTTP; Thu, 23 Feb 2006 23:25:43 -0800 (PST) Message-ID: Date: Fri, 24 Feb 2006 12:55:43 +0530 From: "Maneesh Chawla" To: Erblichs Subject: Re: [Idr] Subcodes for BGP Cease Notification Message In-Reply-To: <43FE6B4D.3C37E177@earthlink.net> MIME-Version: 1.0 References: <43FE6B4D.3C37E177@earthlink.net> X-Spam-Score: 0.1 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: idr chair , idr mailing list , idr chair , Internet Architecture Board , The IESG , IETF-Announce , RFC Editor X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0050029975==" Errors-To: idr-bounces@ietf.org --===============0050029975== Content-Type: multipart/alternative; boundary="----=_Part_11504_11404418.1140765943519" ------=_Part_11504_11404418.1140765943519 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All, Just a little question : Will multiplicative back off combined with upper bound on number of retries be helpful ? Say , case where the administrator on the other BGP speaker has decided to shut it for a definite and longer period of time. In such a case , the BGP speaker would unneccessarily be sending out retries (though backed off multiplicatively). Thanks Maneesh On 2/24/06, Erblichs wrote: > > > Group, > > I like to always ask some things after the fact. > > 4. Subcode Usage > > It is RECOMMENDED that a BGP speaker behave as though the > DampPeerOscillations attribute [BGP-4] was true for this peer when > re-trying a BGP connection after the speaker receives a Cease > NOTIFICATION message with subcode of "Administrative Shutdown", or > > "Peer De-configured", or "Connection Rejected", or "Out of > Resources". An implementation SHOULD impose an upper bound on the > number of consecutive automatic retries. Once this bound is reached, > the implementation would stop re-trying any BGP connections until > some administrative intervention, i.e., set the AllowAutomaticStart > attribute [BGP-4] to FALSE. > > ---- > > I understand RECOMMENDED, but would a multiplicative > backoff algorithm be a better method of consective > retries? Why wasn't this suggested/Recommended? > > IMO, for the later is iff case #1, some type of issue occured > that lost all/most of TCP connections, all of the past peers > would bombard the BGP speaker with repeated almost simultaneous > connection retries. > > And Once a upper bound has been reached, why suggest > administrative > intervention versus a very long retry period? If this other > implementation were used, wouldn't it still recover once the > issue was resolved at the other BGP speaker without requiring > manual intervention at a possibly non-local BGP speaker? > > Thanks, Mitchell Erblich > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr > ------=_Part_11504_11404418.1140765943519 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All,   
      Just a little ques= tion : Will multiplicative back off combined with upper bound on number of = retries be helpful ?
Say , case where the administrator on the other BG= P speaker has decided to shut it for a definite and longer period of time. = In such a case , the BGP speaker would unneccessarily be sending out retrie= s (though backed off multiplicatively).

Thanks
Maneesh

On 2/24/0= 6, Erblichs <erblichs@earthlink.net> wrote:

Group,

        I like to= always ask some things after the fact.

    &nbs= p;   4. Subcode Usage

  It is RECOMMENDED t= hat a BGP speaker behave as though the
   DampPeerOscillations= attribute [BGP-4] was true for this peer when
   re-trying a BGP connection after the speaker receives a Ce= ase
   NOTIFICATION message with subcode of "Administrati= ve Shutdown", or

   "Peer De-configured", o= r "Connection Rejected", or "Out of
   Resources".  An implementation SHOULD impos= e an upper bound on the
   number of consecutive automatic ret= ries. Once this bound is reached,
   the implementation would = stop re-trying any BGP connections until
   some administrative intervention, i.e., set the AllowAutom= aticStart
   attribute [BGP-4] to FALSE.

  &n= bsp;     ----

     = ;   I understand RECOMMENDED, but would a multiplicative
=         backoff algorithm be a bett= er method of consective
        retries? Why wasn't thi= s suggested/Recommended?

       &= nbsp;IMO, for the later is iff case #1, some type of issue occured
 = ;       that lost  all/most of= TCP connections, all of the past peers
     &n= bsp;  would bombard the BGP speaker with repeated almost simultan= eous
        connection retries.
=
        And Once a upper bound = has been reached, why suggest administrative
    &nb= sp;   intervention versus a very long retry period? If this = other
        implementation wer= e used, wouldn't it still recover once the
        issue was resolved at t= he other BGP speaker without requiring
     &nb= sp;  manual intervention at a possibly non-local BGP speaker?
=
        Thanks, Mitchell Erblic= h

_______________________________________________
Idr mailing list
Idr@ietf.orghttps://www1.ietf.o= rg/mailman/listinfo/idr

------=_Part_11504_11404418.1140765943519-- --===============0050029975== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============0050029975==-- From idr-bounces@ietf.org Fri Feb 24 11:40:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCfzv-00031N-0W; Fri, 24 Feb 2006 11:40:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCfzt-000314-11 for idr@ietf.org; Fri, 24 Feb 2006 11:40:49 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCfzr-0000kR-MO for idr@ietf.org; Fri, 24 Feb 2006 11:40:49 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k1OGekX11023; Fri, 24 Feb 2006 08:40:47 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1OGef598332; Fri, 24 Feb 2006 08:40:41 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200602241640.k1OGef598332@merlot.juniper.net> To: Bill Fenner MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26384.1140799241.1@juniper.net> Date: Fri, 24 Feb 2006 08:40:41 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: idr@ietf.org Subject: [Idr] draft-ietf-idr-avoid-transition-04.txt to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Bill, This is to request to advance draft-ietf-idr-avoid-transition-04.txt to Proposed Standard. The implementation report is draft-chen-bgp-avoid-ebgp-transition-survey-00.txt Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Feb 24 21:10:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCosU-00021B-I0; Fri, 24 Feb 2006 21:09:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCosT-00020t-C9 for idr@ietf.org; Fri, 24 Feb 2006 21:09:45 -0500 Received: from lhrga01-in.huawei.com ([57.66.76.5] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCosS-0005vP-33 for idr@ietf.org; Fri, 24 Feb 2006 21:09:45 -0500 Received: from huawei.com ([172.24.2.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV700F91ZYRTA@lhrga01-in.huawei.com> for idr@ietf.org; Sat, 25 Feb 2006 01:54:28 +0000 (GMT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV8002WM0ZY2K@szxga03-in.huawei.com> for idr@ietf.org; Sat, 25 Feb 2006 10:16:47 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV8004L30ZYV3@szxga03-in.huawei.com> for idr@ietf.org; Sat, 25 Feb 2006 10:16:46 +0800 (CST) Received: from z18605 ([10.111.12.131]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV800KOI1EZ4U@szxml01-in.huawei.com> for idr@ietf.org; Sat, 25 Feb 2006 10:25:47 +0800 (CST) Date: Sat, 25 Feb 2006 09:42:25 +0800 From: Zhang Renhai To: idr@ietf.org Message-id: <006b01c639ac$bb442000$830c6f0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Idr] draft-zhang-idr-bgp-entire-routes-reflect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1951814704==" Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============1951814704== Content-type: multipart/alternative; boundary="Boundary_(ID_ylyJgNhMzCLRDMVyjkQmwQ)" This is a multi-part message in MIME format. --Boundary_(ID_ylyJgNhMzCLRDMVyjkQmwQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, Folks This draft has been updated considering the concern how to deal with nexthop change after RR sending more than one route for the same destination to a client. http://www.ietf.org/internet-drafts/draft-zhang-idr-bgp-entire-routes-reflect-02.txt Best regards, Zhang Renhai --Boundary_(ID_ylyJgNhMzCLRDMVyjkQmwQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi, Folks
 
This draft has been updated considering the concern how to deal with nexthop change after RR sending more than one route for the same destination to a client.
 
 
Best regards,
 
Zhang Renhai
 
--Boundary_(ID_ylyJgNhMzCLRDMVyjkQmwQ)-- --===============1951814704== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --===============1951814704==--