From idr-bounces@ietf.org Sun Jan 01 06:53: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 1Et1mR-0007yO-2U; Sun, 01 Jan 2006 06:53:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et1mO-0007rV-UP for idr@megatron.ietf.org; Sun, 01 Jan 2006 06:53: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 GAA00026 for ; Sun, 1 Jan 2006 06:52:29 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/PsrFM9WMHJ25+BNXPr4bMtapgWm4zbzw=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et1rG-0001gy-IC for idr@ietf.org; Sun, 01 Jan 2006 06:58:43 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19yFf7SqCTt7YhQwsptrk1n2scI+oSFNuc@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k01BrNkx011898; Sun, 1 Jan 2006 11:53:28 GMT Date: Sun, 1 Jan 2006 11:53:23 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1219/Wed Dec 28 22:57:59 2005 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Andrew Lee , 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 On Sat, 31 Dec 2005, Tony Li wrote: > I'm not yet convinced of the above. Consider that most longer > prefixes are now being distributed globally. Folks playing with > the new attribute are likely to want to experiment with it by > slowly contracting scope. Agreed. See the example I gave (Andrew's originally?), the combination of AS_HOPCOUNT with peer:action could give the route /wider/ scope than either of the two methods on their own, which seems unintuitive. > An abrupt change in distribution is likely to result in some > unanticipated results, which would delay, not encourage deployment. A fair point. How likely is it that people are going to experiment with announcements that are currently global scope? Surely such experiments will be carried out on announcements currently with restricted scope (by no-export or by : communities)? > Thus, it seems like many providers might want a more liberal > interpretation of the semantics. Providing the option of a liberal > or strict scoping would seem to give the provider an increased > level of control and thus ease deployment. Yeah... Though, as it stands it seems to interact poorly with one of the few existing restrict-scope traffic-engineering method during transition. Is that interaction more important than difference between "X hopcount means reaches at least X hops" and "X hopcount means reaches /up to/ X hops"? (particularly given the former can never be guaranteed anyway). I don't know. Anyway.. > Tony regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Office Automation: The use of computers to improve efficiency in the office by removing anyone you would want to talk with over coffee. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Jan 01 13:12:59 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 1Et7hT-00046N-Kf; Sun, 01 Jan 2006 13:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et7hR-00046C-5M for idr@megatron.ietf.org; Sun, 01 Jan 2006 13:12:57 -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 NAA26986 for ; Sun, 1 Jan 2006 13:11:45 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et7mL-0002iR-Av for idr@ietf.org; Sun, 01 Jan 2006 13:18:02 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (sccrmhc13) with SMTP id <2006010118123501300o1kkhe>; Sun, 1 Jan 2006 18:12:36 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Sun, 1 Jan 2006 10:12:25 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , 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 > How likely is it that people are going to experiment with > announcements that are currently global scope? Surely such > experiments will be carried out on announcements currently with > restricted scope (by no-export or by : communities)? Well, I'm always horrible at estimating probabilities of group behavior. My hope is that restricting the scope of global prefixes becomes the predominant use of the attribute. Specifically, longer prefixes that are being injected for traffic engineering. I'm guessing that the predominant use would be proxy application by Tier 1 or 2 providers. My $.02, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Jan 01 14:49:42 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 1Et9D4-00060U-85; Sun, 01 Jan 2006 14:49:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et9D2-0005zu-FD for idr@megatron.ietf.org; Sun, 01 Jan 2006 14:49:40 -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 OAA05531 for ; Sun, 1 Jan 2006 14:48:28 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18chHO/Ua/Wtz9EsrIt5nA696lTChUOENI=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et9Hw-0005U4-Ri for idr@ietf.org; Sun, 01 Jan 2006 14:54:46 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19iYIkySKSnezkT/8No246Ib6amj/yi5mI@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k01JnJ7N015135; Sun, 1 Jan 2006 19:49:24 GMT Date: Sun, 1 Jan 2006 19:49:19 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1219/Wed Dec 28 22:57:59 2005 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Andrew Lee , Inter-Domain Routing List 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 On Sun, 1 Jan 2006, Tony Li wrote: > Well, I'm always horrible at estimating probabilities of group > behavior. ;) > My hope is that restricting the scope of global prefixes becomes > the predominant use of the attribute. Specifically, longer > prefixes that are being injected for traffic engineering. I'm > guessing that the predominant use would be proxy application by > Tier 1 or 2 providers. Sure. But if they're restricting scope of a route, they want its scope restricted. The covering global scope prefix will be there anyway. But who knows, indeed :). A more focused answer might be to make just the 'ignore no-export' part of the draft conditional on the AS_HOPCOUNT attribute being complete. Would that be acceptable? That'd solve the no-export concerns while still erring on the liberal-scope side. > My $.02, > Tony regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: You will stop at nothing to reach your objective, but only because your brakes are defective. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Jan 01 20:16:33 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 1EtEJH-0000jV-QS; Sun, 01 Jan 2006 20:16:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtEJF-0000gk-QU for idr@megatron.ietf.org; Sun, 01 Jan 2006 20:16: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 UAA29886 for ; Sun, 1 Jan 2006 20:15:13 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtEOD-0005Ln-MW for idr@ietf.org; Sun, 01 Jan 2006 20:21:34 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (sccrmhc13) with SMTP id <2006010201160301300o1beie>; Mon, 2 Jan 2006 01:16:11 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Sun, 1 Jan 2006 17:15:55 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , Inter-Domain Routing List 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 > A more focused answer might be to make just the 'ignore no-export' > part of the draft conditional on the AS_HOPCOUNT attribute being > complete. Would that be acceptable? That'd solve the no-export > concerns while still erring on the liberal-scope side. Ok, I don't understand what you're suggesting. Here's what I think you're saying. If a prefix has both NO_EXPORT and AS_HOPCOUNT and it's received by an AS, then there are three cases: 1) The AS doesn't support AS_HOPCOUNT and it obeys NO_EXPORT, limiting the prefix to the local domain. 2) The AS does support AS_HOPCOUNT. a) If the hopcount hasn't completed, then the AS would obey NO_EXPORT. b) If the hopcount has completed, then the AS would drop the route. I don't see how the path can ever exit the AS. I'm guessing that I'm being dense, but I'm not seeing how... Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Jan 01 20:38: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 1EtEeZ-0001v4-RM; Sun, 01 Jan 2006 20:38:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtEeX-0001uz-Uu for idr@megatron.ietf.org; Sun, 01 Jan 2006 20:38: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 UAA02397 for ; Sun, 1 Jan 2006 20:37:13 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19lJOWNoxnTSR5Kn+ceoudUZlYGDgmz5YU=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtEjV-00060a-OE for idr@ietf.org; Sun, 01 Jan 2006 20:43:35 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19OBU9DVLeW0boi6q2eUfUkwp4XnC8Q32I@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k021c9f6017754; Mon, 2 Jan 2006 01:38:13 GMT Date: Mon, 2 Jan 2006 01:38:06 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1220/Sun Jan 1 22:25:36 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Andrew Lee , Inter-Domain Routing List 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 On Sun, 1 Jan 2006, Tony Li wrote: > Ok, I don't understand what you're suggesting. Here's what I think you're > saying. > If a prefix has both NO_EXPORT and AS_HOPCOUNT and it's received by an AS, > then there are three cases: > 2) The AS does support AS_HOPCOUNT. > > a) If the hopcount hasn't completed, then the AS would obey NO_EXPORT. Odd, the draft doesn't seem to say this. > b) If the hopcount has completed, then the AS would drop the route. > I don't see how the path can ever exit the AS. I'm guessing that > I'm being dense, but I'm not seeing how... In 3.3: " Systems that receive NLRI with both an AS_HOPCOUNT and NO_EXPORT and which do implement AS_HOPCOUNT will ignore the NO_EXPORT community and propagate the NLRI." In 5.1: " If a BGP speaker receives a route with both the AS_HOPCOUNT attribute and the NO_EXPORT community string attribute, then the normal semantics of NO_EXPORT do not apply and the route should be processed as if NO_EXPORT was not present." Maybe I'm being dense too ;) but that reads to me like AS_HOPCOUNT /always/ overrides NO_EXPORT, which is not good imho (see my X-Y-Z action-community + AS_HOPCOUNT example in previous email). I'm saying AS_HOPCOUNT should override NO_EXPORT *only* if it is complete. If it's partial, then NO_EXPORT, IFF present, should be honoured instead, because there's no way to know how many hops were "missed" in the AS_HOPCOUNT attribute, NO_EXPORT is the only complete "scope-reducer" in such case and should hence be obeyed. Failure could to do so could result in the prefix reaching /further/ than intended by anyone, possibly even result in global scope, where this was never intended for that prefix. > Tony regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Death to all fanatics! _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Jan 01 21:54: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 1EtFqB-0003vi-Qq; Sun, 01 Jan 2006 21:54:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtFq9-0003va-GA for idr@megatron.ietf.org; Sun, 01 Jan 2006 21:54: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 VAA07682 for ; Sun, 1 Jan 2006 21:53:16 -0500 (EST) Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtFv7-0007qG-VJ for idr@ietf.org; Sun, 01 Jan 2006 21:59:39 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (rwcrmhc14) with SMTP id <20060102025411014007skkce>; Mon, 2 Jan 2006 02:54:12 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Sun, 1 Jan 2006 18:54:04 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , Inter-Domain Routing List 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 >> 2) The AS does support AS_HOPCOUNT. >> >> a) If the hopcount hasn't completed, then the AS would obey >> NO_EXPORT. > > Odd, the draft doesn't seem to say this. That was my interpretation of what YOU were suggesting when you said that "AS_HOPCOUNT should override NO_EXPORT *only* if it is complete". Is that incorrect? > Maybe I'm being dense too ;) but that reads to me like AS_HOPCOUNT / > always/ overrides NO_EXPORT, which is not good imho (see my X-Y-Z > action-community + AS_HOPCOUNT example in previous email). I'm > saying AS_HOPCOUNT should override NO_EXPORT *only* if it is complete. Perhaps we might make more progress if you could expand on your proposed semantics a bit. > If it's partial, then NO_EXPORT, IFF present, should be honoured > instead, If AS_HOPCOUNT is partial, the it implies that it transited an AS that did not support AS_HOPCOUNT. But any such AS should have obeyed NO_EXPORT and thus should never have propagated the path in the first place. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jan 02 06:57:18 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 1EtOJS-0005jl-9T; Mon, 02 Jan 2006 06:57:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtOJP-0005jg-W0 for idr@megatron.ietf.org; Mon, 02 Jan 2006 06:57:16 -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 GAA20056 for ; Mon, 2 Jan 2006 06:56:02 -0500 (EST) Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtOOT-0005pz-Kb for idr@ietf.org; Mon, 02 Jan 2006 07:02:30 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 3104FE0435; Mon, 2 Jan 2006 06:57:04 -0500 (EST) Date: Mon, 2 Jan 2006 06:57:04 -0500 From: John Leslie To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Message-ID: <20060102115704.GB18120@verdi> References: <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Andrew Lee , Paul Jakma , Inter-Domain Routing List 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 wrote: > > If AS_HOPCOUNT is partial, the it implies that it transited an AS > that did not support AS_HOPCOUNT. > But any such AS should have obeyed NO_EXPORT and thus should never > have propagated the path in the first place. When I first raised this issue, I was thinking of a particular case (in addition to the general case): - BGP-speaker at the edge advertises with AS_HOPCOUNT (without NO_EXPORT); - ISP-A doesn't know AS_HOPCOUNT, adds NO_EXPORT for whatever reason; - ISP-B recognizes AS_HOPCOUNT, and ignores NO_EXPORT. This particular case feels wrong to me. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jan 02 22:31: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 1EtctT-0005hc-Si; Mon, 02 Jan 2006 22:31:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtctS-0005hG-8h for idr@megatron.ietf.org; Mon, 02 Jan 2006 22:31: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 WAA18678 for ; Mon, 2 Jan 2006 22:30:12 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/XgkVnU/gCv51flIluyc4Xcx5xAGv92b8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etcyd-00086E-KF for idr@ietf.org; Mon, 02 Jan 2006 22:36:49 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19MRUC5VcHrCD8AV1GW7blW8vC04cVDy2M@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k033UupS031073; Tue, 3 Jan 2006 03:31:01 GMT Date: Tue, 3 Jan 2006 03:30:55 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1225/Mon Jan 2 17:54:07 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Andrew Lee , Inter-Domain Routing List 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 On Sun, 1 Jan 2006, Tony Li wrote: > That was my interpretation of what YOU were suggesting Ah, doh, of course. apologies. > when you said that "AS_HOPCOUNT should override NO_EXPORT *only* if > it is complete". Is that incorrect? Yes, that's exactly what I'm arguing for. > Perhaps we might make more progress if you could expand on your proposed > semantics a bit. As above, sorry. > If AS_HOPCOUNT is partial, the it implies that it transited an AS > that did not support AS_HOPCOUNT. But any such AS should have > obeyed NO_EXPORT and thus should never have propagated the path in > the first place. See the examples I gave previously wrt interaction of AS_HOPCOUNT and : communities: X-Y-Z Z sends prefix with both AS_HOPCOUNT (count >= 2), and also community Y:n (where AS Y will attach no-export community for any prefix which has Y:n community attached). Y does not support AS_HOPCOUNT. X receives the advertisement and ignores no-export, as the draft currently stands. The prefix might now have have global scope, particularly in early days of AS_HOPCOUNT deployment (where it may never transit through sufficient other AS_HOPCOUNT capable speakers to be stopped). The prefix has /wider/ scope because of the combination of AS_HOPCOUNT and : communities, wider than it could ever have with either method (presuming everyone supported AS_HOPCOUNT). It'd be a surprising effect of AS_HOPCOUNT possibly. See also the example I gave where Y has some AS_HOPCOUNT capable speakers, and some not. Making the NO_EXPORT override be conditional on AS_HOPCOUNT being a complete attribute would solve this case, while not restricting scope of AS_HOPCOUNTed prefixes unneccesarily, I think. (that was your objection to my earlier 'partial -> set to 0' proposal). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: They are called computers simply because computation is the only significant job that has so far been given to them. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 03 17:46:12 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 1Etuuy-0004kW-Pa; Tue, 03 Jan 2006 17:46:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etuuw-0004kO-3v for idr@megatron.ietf.org; Tue, 03 Jan 2006 17:46:10 -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 RAA28035 for ; Tue, 3 Jan 2006 17:44:55 -0500 (EST) Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etv0H-00040g-Ld for idr@ietf.org; Tue, 03 Jan 2006 17:51:42 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <20060103224551012007sbaje>; Tue, 3 Jan 2006 22:45:52 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Tue, 3 Jan 2006 14:45:49 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , Inter-Domain Routing List 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 Paul, > See the examples I gave previously wrt interaction of AS_HOPCOUNT > and : communities: > > X-Y-Z > > Z sends prefix with both AS_HOPCOUNT (count >= 2), and also > community Y:n (where AS Y will attach no-export community for any > prefix which has Y:n community attached). Y does not support > AS_HOPCOUNT. X receives the advertisement and ignores no-export, as > the draft currently stands. > > The prefix might now have have global scope, particularly in early > days of AS_HOPCOUNT deployment (where it may never transit through > sufficient other AS_HOPCOUNT capable speakers to be stopped). The > prefix has /wider/ scope because of the combination of AS_HOPCOUNT > and : communities, wider than it could ever have with > either method (presuming everyone supported AS_HOPCOUNT). It'd be a > surprising effect of AS_HOPCOUNT possibly. Understood, and this is certainly a bad side effect of AS_HOPCOUNT and Y:n interaction. > Making the NO_EXPORT override be conditional on AS_HOPCOUNT being a > complete attribute would solve this case, while not restricting > scope of AS_HOPCOUNTed prefixes unneccesarily, I think. (that was > your objection to my earlier 'partial -> set to 0' proposal). Yes, but as I pointed out, making the NO_EXPORT override be conditional on AS_HOPCOUNT being complete breaks the NO_EXPORT override for everyone who is NOT depending on Y:n semantics. This begs the question: how many folks are reliant on Y:n semantics? Or should we simply remove the interaction between AS_HOPCOUNT and NO_EXPORT? Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 03 21:24:18 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 1EtyK2-0005EC-NT; Tue, 03 Jan 2006 21:24:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtyK0-0005E4-96 for idr@megatron.ietf.org; Tue, 03 Jan 2006 21:24:16 -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 VAA21982 for ; Tue, 3 Jan 2006 21:23:02 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtyPL-0002e7-Bw for idr@ietf.org; Tue, 03 Jan 2006 21:29:51 -0500 Received: from [205.168.100.52] (unknown [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 88739642D4 for ; Tue, 3 Jan 2006 19:23:53 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <732A8281-5ED8-4A56-ADF6-B4EE0EEBFACF@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Tue, 3 Jan 2006 19:24:00 -0700 To: Inter-Domain Routing List X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit 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 On Jan 3, 2006, at 3:45 PM, Tony Li wrote: > > > Yes, but as I pointed out, making the NO_EXPORT override be > conditional on AS_HOPCOUNT being > complete breaks the NO_EXPORT override for everyone who is NOT > depending on Y:n semantics. > This begs the question: how many folks are reliant on Y:n > semantics? Or should we simply remove > the interaction between AS_HOPCOUNT and NO_EXPORT? Tony, I've got a couple of concerns with the current specification, a few high-level points are provided here as the detailed text below is admittedly overly verbose (in part because I was trying to wrap my head around the various scenarios - which I'm still not sure I have). I have read the entire thread to date and don't believe I'm duplicating much... In short, I'd definitely prefer that AS_HOPCOUNT and NO_EXPORT interaction be removed entirely. I believe the corner cases where it'd be useful are fewer than the cases where it could adversely effect existing deployments. I'd also think that adapting AS_HOPCOUNT behavior to be much more akin to that of the NO_EXPORT community string may be desirable. I.e., make AS_HOPCOUNT an egress policy function rather than an ingress one - as expanded on in the text below. Finally, I'd strongly suggest that Member-ASes of an AS confederation NOT be treated like standard external peers, but rather, that the AS_HOPCOUNT functions only apply to Member-ASes that are advertising a route to eBGP peers outside of the local confederation. My reasoning for this is that IBGP AS properties that are only visible within an AS would now result in routes only being propagated throughout a subset of a given AS, or an AS_HOPCOUNT being decremented multiple times in a seemingly single A (AUTONOMOUS) System.... Imagine a case where a multi-homed AS wanted to employ AS_HOPCOUNT to scope traffic two ASes upstream from it's two providers. One of it's upstream providers employs route reflection or a full mesh iBGP, while the other has confederations. As you can imagine, the confederation could result in the route never being advertised outside of the AS, or entirely within the AS if employing confederations, while still being propagated via the other provider. In short, it results in behavior that would be seemingly non-deterministic without intimate knowledge of the the internal BGP routing architectures of the networks in questions. I suspect in this case implementers could provide a knob to decrement AS_HOPCOUNT when advertising to other Member-ASes of the same AS confederation, but it's not something I'd recommend as normal default behavior. I'm still a fan of AS_HOPCOUNT and believe it's a good idea, FWIW. Further comments below... -danny As currently specified, (if I'm interpreting correctly) an eBGP speaker upon receipt of NLRI that contains both the AS_HOPCOUNT attribute and NO_EXPORT community: - if it doesn't understand the AS_HOPCOUNT attribute processing will continue as usual per it's an optional transitive attribute and NO_EXPORT will likely result in the NLRI NOT being propagated outside the local AS. (note that this required that the eBGP peer transmit both the NO_EXPORT community AND the AS_HOPCOUNT attribute) - if it does understand AS_HOPCOUNT it will ignore the NO_EXPORT (actually, behave as if it doesn't exist?) community and propagate the route ---> IF the AS_HOPCOUNT value is non-zero. - NO_EXPORT remains only applicable between adjacent ASes (by it's very nature)? I don't see anywhere here that it states NO_EXPORT should be carried indefinitely if the AS_HOPCOUNT attribute is present? With that, I'm honestly not sure I understand here where value is gained by coupling the NO_EXPORT community with the AS_HOPCOUNT attribute, can you further expand for me? On that point In section 3.3 the draft states: " Further control can be achieved by considering the implications of using both AS_HOPCOUNT and NO_EXPORT simultaneously. Since NO_EXPORT is widely deployed, understood by almost all implementations, and since AS_HOPCOUNT is not deployed, we can make use of the overlap in their semantics to provide a powerful transition mechanism." This introduces a bit of confusion. With the AS_HOPCOUNT attribute a route would be dropped as an ingress policy function (i.e., when receiving a route from an eBGP peer with an AS_HOPCOUNT value of 0). Whereas, NO_EXPORT is applied as an egress policy function (i.e., don't announce a route to an eBGP peer if the NO_EXPORT community string is present), the latter of which has the advantage of allowing me to tell an adjacent AS something and being quite confident that it will not be propagated beyond their AS. I.e., it seems non-intuitive to tell someone something if I know they're going to ignore it. However, if I know they're going to use it but not tell anyone else (e.g., as with NO_EXPORT), that makes sense. So what this would mean is that if I wanted to employ this in a similar manner to NO_EXPORT with an adjacent peer that supported the new attribute, I'd set the AS_HOPCOUNT attribute to 1, it'd be decremented on ingress to the adjacent AS AND advertised to ASes further upstream - *where it previously was not*, and on ingress to those ASes IF they support the AS_HOPCOUNT attribute they'll discard the route (a route that would have never been advertised had the AS_HOPCOUNT behavior not been introduced per the NO_EXPORT community that existed on ingress to the second AS in the path). If they do not support the attribute the route will be propagated indefinitely. Perhaps we'd be better off here if we changed the rules a bit such that NLRI with an AS_HOPCOUNT value of 1 (or 0) MUST NOT be advertised to eBGP peers, then the semantics overlap much more cleanly with that of the NO_EXPORT community string. I'm trying to think of a case where this might break if BGP speakers don't support it but nothing comes to mind at the moment....? Along the same lines, the issue that most of this thread has been pertaining to regarding ignoring NO_EXPORT if the AS_HOPCOUNT attribute is present, that concerns me. Primarily because if a downstream AS attaches the NO_EXPORT community to a route but has no knowledge of the existing AS_HOPCOUNT attribute, then the NO_EXPORT community will be ignored. According to the text here in section 5.1: "If a BGP speaker receives a route with both the AS_HOPCOUNT attribute and the NO_EXPORT community string attribute, then the normal semantics of NO_EXPORT do not apply and the route should be processed as if NO_EXPORT was not present." This has several implications. The first is that my reading of this leads me to believe that the NO_EXPORT community string should be removed from the route. So, if a transit AS added the NO_EXPORT community fully intending for the adjacent to propagate the route entirely throughout the local AS, but didn't recognize the AS_HOPCOUNT value then policy just changed without their knowledge and the route MAY be dropped on ingress to the AS, rather than egress (or in some external AS), depending on the value of the AS_HOPCOUNT attribute. I'd really prefer that the interactions between AS_HOPCOUNT and NO_EXPORT be removed altogether as I suspect that this will likely result in inadvertent propagation of prefixes that were previously scoped by NO_EXPORT (e.g., as was mentioned in the case where a transit AS doesn't support AS_HOPCOUNT but attached NO_EXPORT for whatever reason). Or, for example, all the routes that MAY be leaked while I'm upgrading my egress routers to support AS_HOPCOUNT while the ingress routers have stripped the NO_EXPORT community. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 04 02:04: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 1Eu2h9-0008Jp-ND; Wed, 04 Jan 2006 02:04:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu2h6-0008JM-Ub for idr@megatron.ietf.org; Wed, 04 Jan 2006 02:04: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 CAA18539 for ; Wed, 4 Jan 2006 02:03:09 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu2mK-00037J-TF for idr@ietf.org; Wed, 04 Jan 2006 02:09:50 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 03 Jan 2006 23:01:58 -0800 X-IronPort-AV: i="3.99,328,1131350400"; d="scan'208"; a="246795856:sNHT842385182" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k04720XX020499; Tue, 3 Jan 2006 23:02:00 -0800 (PST) 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.211); Tue, 3 Jan 2006 23:01:57 -0800 Received: from [10.21.99.33] ([10.21.99.33]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Jan 2006 23:01:56 -0800 Message-ID: <43BB72E4.4050604@cisco.com> Date: Tue, 03 Jan 2006 23:01:56 -0800 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> In-Reply-To: <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2006 07:01:56.0929 (UTC) FILETIME=[C0374B10:01C610FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 wrote: > > Yes, but as I pointed out, making the NO_EXPORT override be > conditional on AS_HOPCOUNT being > complete breaks the NO_EXPORT override for everyone who is NOT > depending on Y:n semantics. > This begs the question: how many folks are reliant on Y:n semantics? > Or should we simply remove > the interaction between AS_HOPCOUNT and NO_EXPORT? Hi, Tony: It seems to me that removing the interaction between AS_HOPCOUNT and NO_EXPORT would make things simpler and cleaner. So I am in favor of the revision. Also as Danny pointed out, having the AS_HOPCOUNT as an outbound policy (rather than an inbound policy) would make it consistent with the commonly understood practice of NO_EXPORT. It seems to be a good idea. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 04 06:43:09 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 1Eu72r-0007Ms-DL; Wed, 04 Jan 2006 06:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu72p-0007Mj-EP for idr@megatron.ietf.org; Wed, 04 Jan 2006 06:43:07 -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 GAA17047 for ; Wed, 4 Jan 2006 06:41:52 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19vAHLuAVJMFJnxJgi7x3iqX+IArFgUr88=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu78G-0004BR-O7 for idr@ietf.org; Wed, 04 Jan 2006 06:48:47 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+6K5cIciFv/PyUa9eLCjBGVWXQhlhE1cw@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k04BgbYs020439; Wed, 4 Jan 2006 11:42:45 GMT Date: Wed, 4 Jan 2006 11:42:36 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1227/Tue Jan 3 22:11:54 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Andrew Lee , Inter-Domain Routing List 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 On Tue, 3 Jan 2006, Tony Li wrote: > Understood, and this is certainly a bad side effect of AS_HOPCOUNT > and Y:n interaction. > Yes, but as I pointed out, making the NO_EXPORT override be > conditional on AS_HOPCOUNT being complete breaks the NO_EXPORT > override for everyone who is NOT depending on Y:n semantics. I don't quite see that. Could you expand on this (apologies if you did already)? It will work for fine for the combination of NO_EXPORT and AS_HOPCOUNT evisaged in the draft. Where the originator sets both. AS_HOPCOUNT will always be complete. > This begs the question: how many folks are reliant on Y:n > semantics? Or should we simply remove the interaction between > AS_HOPCOUNT and NO_EXPORT? I think the draft is right to try modify no-export behaviour depending on AS_HOPCOUNT. Lets try find the best way to do so, no? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Life is a gamble at terrible odds, if it was a bet you wouldn't take it. -- Tom Stoppard, "Rosencrantz and Guildenstern are Dead" _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 04 09:28:52 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 1Eu9dD-0002qV-Rt; Wed, 04 Jan 2006 09:28:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu9dC-0002pQ-Pd for idr@megatron.ietf.org; Wed, 04 Jan 2006 09:28:50 -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 JAA06883 for ; Wed, 4 Jan 2006 09:27:34 -0500 (EST) Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu9ig-0001xi-Gu for idr@ietf.org; Wed, 04 Jan 2006 09:34:31 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 146C9E045A; Wed, 4 Jan 2006 09:28:39 -0500 (EST) Date: Wed, 4 Jan 2006 09:28:39 -0500 From: John Leslie To: Paul Jakma Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Message-ID: <20060104142839.GD85080@verdi> References: <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Inter-Domain Routing List 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 Paul Jakma wrote: > > I think the draft is right to try modify no-export behaviour > depending on AS_HOPCOUNT. Lets try find the best way to do so, no? I believe that any interaction between AS_HOPCOUNT and NO_EXPORT should be limited to _setting_ NO_EXPORT. Clearing it seems to introduce too much risk of propagating farther than intended. That said, I can imagine a use for setting NO_EXPORT in the case where AS_HOPCOUNT will reach its limit after one more hop: when the next hop is suspected of not implementing AS_HOPCOUNT. Of course, this only helps during the "transition" to full implementation of AS_HOPCOUNT -- but that transition, IMHO, will take a minimum of five years, and any predictability we can add during the transition is (IMHO) a good thing. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 04 18:28:00 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 1EuI2y-0006LW-6Z; Wed, 04 Jan 2006 18:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuI2w-0006LO-QT for idr@megatron.ietf.org; Wed, 04 Jan 2006 18:27: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 SAA18857 for ; Wed, 4 Jan 2006 18:26:43 -0500 (EST) Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuI8V-0007o1-LX for idr@ietf.org; Wed, 04 Jan 2006 18:33:44 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2006010423274001200jmiv2e>; Wed, 4 Jan 2006 23:27:40 +0000 In-Reply-To: <43BB72E4.4050604@cisco.com> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> <43BB72E4.4050604@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Wed, 4 Jan 2006 13:59:14 -0800 To: Enke Chen X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 Enke, > It seems to me that removing the interaction between AS_HOPCOUNT > and NO_EXPORT would make things simpler and cleaner. So I am in > favor of the revision. Duly noted. > Also as Danny pointed out, having the AS_HOPCOUNT as an outbound > policy (rather than an inbound policy) would make it consistent > with the commonly understood practice of NO_EXPORT. It seems to be > a good idea. No objection from me. I should point out that regardless of the way the draft describes the semantics, the implementation is free to implement this as an inbound or outbound policy, as it sees fit. For example, given the current text, an implementation could pre-compute the ingress policy that a neighbor would implement and filter the prefix on the outbound side, effectively making this an outbound policy. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 04 18:33:10 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 1EuI7y-0007CF-JQ; Wed, 04 Jan 2006 18:33:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuI7x-0007CA-An for idr@megatron.ietf.org; Wed, 04 Jan 2006 18:33:09 -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 SAA19591 for ; Wed, 4 Jan 2006 18:31:54 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuIDW-00082F-1v for idr@ietf.org; Wed, 04 Jan 2006 18:38:55 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2006010423325401200jjrfde>; Wed, 4 Jan 2006 23:32:58 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <42941B1F-360A-4B19-8E0E-6A13CAEFB1F0@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Wed, 4 Jan 2006 15:32:39 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Andrew Lee , Inter-Domain Routing List 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 >> Yes, but as I pointed out, making the NO_EXPORT override be >> conditional on AS_HOPCOUNT being complete breaks the NO_EXPORT >> override for everyone who is NOT depending on Y:n semantics. > > I don't quite see that. Could you expand on this (apologies if you > did already)? > > It will work for fine for the combination of NO_EXPORT and > AS_HOPCOUNT evisaged in the draft. Where the originator sets both. > AS_HOPCOUNT will always be complete. We must have some miscommunication on the word "complete". When an originator sets AS_HOPCOUNT, I would assume that they would set it to some non-zero small integer. It would only be complete when it had subsequently traversed multiple ASs and the value had been decremented to zero. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 04 18:50:55 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 1EuIP9-0005u4-4r; Wed, 04 Jan 2006 18:50:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuIP7-0005tI-7d for idr@megatron.ietf.org; Wed, 04 Jan 2006 18:50:53 -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 SAA22050 for ; Wed, 4 Jan 2006 18:49:38 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19a1io/9ek0109WPVp1sMeoMJhldmC9J1g=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuIUf-0000Sq-Rm for idr@ietf.org; Wed, 04 Jan 2006 18:56:39 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+GL5/5E/KjOU8HpUZndq6kfL9M9gNFWv8@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k04NofVe029751; Wed, 4 Jan 2006 23:50:45 GMT Date: Wed, 4 Jan 2006 23:50:40 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: <42941B1F-360A-4B19-8E0E-6A13CAEFB1F0@tony.li> Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> <42941B1F-360A-4B19-8E0E-6A13CAEFB1F0@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1229/Wed Jan 4 15:08:11 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Andrew Lee , Inter-Domain Routing List 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 On Wed, 4 Jan 2006, Tony Li wrote: > We must have some miscommunication on the word "complete". I think so. It was the "completed" word in your other email that threw me into thinking you were referring to some language in the draft. > When an originator sets AS_HOPCOUNT, I would assume that they would > set it to some non-zero small integer. It would only be complete > when it had subsequently traversed multiple ASs and the value had > been decremented to zero. Ah, in every case where I've used "complete" or "partial", I've been referring to the Partial bit in the attribute flags header. > Tony regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: All intelligent species own cats. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jan 05 00:51: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 1EuO22-0000uL-Um; Thu, 05 Jan 2006 00:51:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuO20-0000u1-S4 for idr@megatron.ietf.org; Thu, 05 Jan 2006 00:51: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 AAA26165 for ; Thu, 5 Jan 2006 00:50:09 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuO7c-0003mh-L1 for idr@ietf.org; Thu, 05 Jan 2006 00:57:14 -0500 Received: from yxu1a20.hopcount.ca ([199.212.90.20]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EuO1X-000E9a-0Q; Thu, 05 Jan 2006 05:50:55 +0000 In-Reply-To: <732A8281-5ED8-4A56-ADF6-B4EE0EEBFACF@tcb.net> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> <732A8281-5ED8-4A56-ADF6-B4EE0EEBFACF@tcb.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <78082F50-87EC-4693-9BD5-FBDDAD086DDE@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Thu, 5 Jan 2006 00:50:52 -0500 To: Danny McPherson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 On 3-Jan-2006, at 21:24, Danny McPherson wrote: > I've got a couple of concerns with the current specification, a few > high-level points are provided here as the detailed text below is > admittedly overly verbose (in part because I was trying to wrap my > head around the various scenarios - which I'm still not sure I have). > I have read the entire thread to date and don't believe I'm > duplicating > much... The NO_EXPORT/AS_HOPCOUNT interaction described in the current draft were based on an old (unsubmitted) draft I wrote which was conceived very much from the perspective of trying to conservatively restrict propagation of routes covering the addresses of anycast services. (Apologies for not speaking up sooner; my traditional New Year's hangover was concatenated with influenza.) The motivations for abusing NO_EXPORT in this way were that the implications for a leak from an anycast node in a region with poor external connectivity are often serious, and in many cases not propagating the prefix as widely as we could is preferable to accidentally propagating it globally. For example, propagating the covering route for F.ROOT-SERVERS.NET from ISC's anycast node in Nairobi could be bad for many people, both inside and outside Kenya. Export policies are frequently designed and implemented to prevent peer routes leaking to transit providers for obvious reasons; however, in practice, we find ourselves deploying infrastructure in regions where the concept of "export policy" is not well-known, and BGP configurations are apparently copied verbatim from the backs of cereal boxes. Not all of these regions are those that would be normally considered to be in the developing world. Hence, we like the paranoid approach of setting NO_EXPORT on 192.5.5.0/24 from our local nodes, since the peers most likely to leak are also the peers least likely to know how to remove it, or to even notice it is there. We soak up queries from the client population that we miss with this conservative propagation strategy on a smaller number of bigger, well- connected anycast nodes. There has been various discussion over the past week or so about how the unusual interaction between NO_EXPORT and AS_HOPCOUNT specified in this draft could cause confusion, e.g. by those practicing proxy application of NO_EXPORT, which for routes which also happen to carry AS_HOPCOUNT might not prevent the route from being exported. Breaking deployed expectations of NO_EXPORT does indeed seem bad. Since the whole NO_EXPORT/AS_HOPCOUNT interaction is a bit of a cheap short- cut, designed to allow use of AS_HOPCOUNT without waiting for widespread adoption of the AS_HOPCOUNT mechanism, perhaps the collateral ugliness is not justified. As someone else here suggested (and as Tony pointed out to me) changing the AS_HOPCOUNT attribute to represent an upper bound on the length of an AS_PATH (and discarding the NO_EXPORT interaction) might be a useful compromise, since a prefix leaked by a non-AS_HOPCOUNT- aware speaker would continue to accrue AS_PATH length through non- AS_HOPCOUNT-aware routers, and would be suppressed by the first AS_HOPCOUNT-aware speaker it came across. The only other mechanism that occurred to me was to replace the current proposed NO_EXPORT interaction with a capabilities negotiation in the specification such that an AS_HOPCOUNT-capable speaker would append a NO_EXPORT community-string attribute to routes carrying AS_HOPCOUNT in the case where it exports routes towards a non-AS_HOPCOUNT-capable speaker. This would provide a more conservative strategy for route propagation, but it seems dirtier than using AS_HOPCOUNT to bound an AS_PATH length. It also doesn't support the alternative, more leak-tolerant semantics achieved in the current proposal by adding AS_HOPCOUNT without NO_EXPORT. Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jan 05 01:06:52 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 1EuOGy-0006wg-6w; Thu, 05 Jan 2006 01:06:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuOGw-0006wA-Tu for idr@megatron.ietf.org; Thu, 05 Jan 2006 01:06:50 -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 BAA27644 for ; Thu, 5 Jan 2006 01:05:35 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuOMY-0004JA-Nv for idr@ietf.org; Thu, 05 Jan 2006 01:12:40 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 46C0F64367; Wed, 4 Jan 2006 23:06:28 -0700 (MST) In-Reply-To: <78082F50-87EC-4693-9BD5-FBDDAD086DDE@isc.org> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> <732A8281-5ED8-4A56-ADF6-B4EE0EEBFACF@tcb.net> <78082F50-87EC-4693-9BD5-FBDDAD086DDE@isc.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80CB3777-FCC2-4388-800E-E72FB585233F@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Wed, 4 Jan 2006 23:06:39 -0700 To: Joe Abley X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 On Jan 4, 2006, at 10:50 PM, Joe Abley wrote: > > As someone else here suggested (and as Tony pointed out to me) > changing the AS_HOPCOUNT attribute to represent an upper bound on > the length of an AS_PATH (and discarding the NO_EXPORT interaction) > might be a useful compromise, since a prefix leaked by a non- > AS_HOPCOUNT-aware speaker would continue to accrue AS_PATH length > through non-AS_HOPCOUNT-aware routers, and would be suppressed by > the first AS_HOPCOUNT-aware speaker it came across. I like this idea much better as well, assuming it accounts for private AS, AS confederation path segments, AS sets, etc.. > The only other mechanism that occurred to me was to replace the > current proposed NO_EXPORT interaction with a capabilities > negotiation in the specification such that an AS_HOPCOUNT-capable > speaker would append a NO_EXPORT community-string attribute to > routes carrying AS_HOPCOUNT in the case where it exports routes > towards a non-AS_HOPCOUNT-capable speaker. This would provide a > more conservative strategy for route propagation, but it seems > dirtier than using AS_HOPCOUNT to bound an AS_PATH length. It also > doesn't support the alternative, more leak-tolerant semantics > achieved in the current proposal by adding AS_HOPCOUNT without > NO_EXPORT. Not only would this require some more dynamic knowledge (e.g., BGP Capabilities functions) of what capabilities the neighbor supports, it's something that may vary even within a single AS. I agree - I like the idea of examining the AS path and using that mechanism instead... -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jan 05 03:57: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 1EuQw5-0002XO-4d; Thu, 05 Jan 2006 03:57:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQw3-0002XJ-Nh for idr@megatron.ietf.org; Thu, 05 Jan 2006 03:57:27 -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 DAA13742 for ; Thu, 5 Jan 2006 03:56:10 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuR1g-0001Gu-Oz for idr@ietf.org; Thu, 05 Jan 2006 04:03:18 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2006010508570601200jk0cpe>; Thu, 5 Jan 2006 08:57:06 +0000 In-Reply-To: <80CB3777-FCC2-4388-800E-E72FB585233F@tcb.net> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> <732A8281-5ED8-4A56-ADF6-B4EE0EEBFACF@tcb.net> <78082F50-87EC-4693-9BD5-FBDDAD086DDE@isc.org> <80CB3777-FCC2-4388-800E-E72FB58! 5233F@tcb.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A3B5B0E-9BA1-4DB4-B888-D133209AC923@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Thu, 5 Jan 2006 00:57:03 -0800 To: Danny McPherson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 >> As someone else here suggested (and as Tony pointed out to me) >> changing the AS_HOPCOUNT attribute to represent an upper bound on >> the length of an AS_PATH (and discarding the NO_EXPORT >> interaction) might be a useful compromise, since a prefix leaked >> by a non-AS_HOPCOUNT-aware speaker would continue to accrue >> AS_PATH length through non-AS_HOPCOUNT-aware routers, and would be >> suppressed by the first AS_HOPCOUNT-aware speaker it came across. > > I like this idea much better as well, assuming it accounts for private > AS, AS confederation path segments, AS sets, etc.. Danny, I would word it so that the hopcount explicitly does NOT count private ASs or confederation ASs. AS sets would still count as one hop per set member. Does that match what you're saying? Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jan 05 09:42: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 1EuWJW-00041t-K3; Thu, 05 Jan 2006 09:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWJU-00040A-Kd for idr@megatron.ietf.org; Thu, 05 Jan 2006 09:42:00 -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 JAA22009 for ; Thu, 5 Jan 2006 09:40:44 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuWPB-0004kR-6m for idr@ietf.org; Thu, 05 Jan 2006 09:47:54 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 4DB2F642DD; Thu, 5 Jan 2006 07:41:40 -0700 (MST) In-Reply-To: <2A3B5B0E-9BA1-4DB4-B888-D133209AC923@tony.li> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> <732A8281-5ED8-4A56-ADF6-B4EE0EEBFACF@tcb.net> <78082F50-87EC-4693-9BD5-FBDDAD086DDE@isc.org> <80CB3777-FCC2-4388-800E-E72FB585 233F@tcb.net> <2A3B5B0E-9BA1-4DB4-B888-D133209AC923@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Thu, 5 Jan 2006 07:41:51 -0700 To: Tony Li X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 On Jan 5, 2006, at 1:57 AM, Tony Li wrote: > > Danny, > > I would word it so that the hopcount explicitly does NOT count > private ASs or confederation ASs. > AS sets would still count as one hop per set member. > > Does that match what you're saying? Yes! -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jan 09 14:04:44 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 1Ew2Jw-0005oX-EP; Mon, 09 Jan 2006 14:04:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2Ju-0005oS-Th for idr@megatron.ietf.org; Mon, 09 Jan 2006 14:04:42 -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 OAA12519 for ; Mon, 9 Jan 2006 14:03:23 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew2QS-0008E9-DN for idr@ietf.org; Mon, 09 Jan 2006 14:11:29 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0D596C27F69 for ; Mon, 9 Jan 2006 11:04:24 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16768-07 for ; Mon, 9 Jan 2006 11:04:23 -0800 (PST) Received: from [155.53.44.78] (horizon.redback.com [155.53.44.78]) by prattle.redback.com (Postfix) with ESMTP id 879B6C27F6A for ; Mon, 9 Jan 2006 11:04:23 -0800 (PST) Message-ID: <43C2B3B7.6030504@redback.com> Date: Mon, 09 Jan 2006 11:04:23 -0800 From: Vikram Reddy User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Idr] BGP4 FSM question 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 Hello folks, I had a question about the FSM in BGP-4. I am not sure, but was there was a problem in BGP 4 (RFC 177) with the FSM collision detection rules? According to what I vaguely remember, there was particular sequence of message passing between peers which would result in both of them getting stuck in the active state. This was supposed to be addressed in the later idr drafts. Could you please comment on this and let me know if I am right or wrong? Thanks. Vikram. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jan 09 14:45:26 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 1Ew2xK-0001Ue-Py; Mon, 09 Jan 2006 14:45:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2xJ-0001Sw-1j for idr@megatron.ietf.org; Mon, 09 Jan 2006 14:45: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 OAA15965 for ; Mon, 9 Jan 2006 14:44:05 -0500 (EST) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew33q-00015f-NK for idr@ietf.org; Mon, 09 Jan 2006 14:52:12 -0500 Received: from [192.168.0.2] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with SMTP id <2006010919450001400sbsrle>; Mon, 9 Jan 2006 19:45:03 +0000 In-Reply-To: <43C2B3B7.6030504@redback.com> References: <43C2B3B7.6030504@redback.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] BGP4 FSM question Date: Mon, 9 Jan 2006 11:44:56 -0800 To: Vikram Reddy X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Please see draft-ietf-idr-bgp4-26.txt Tony On Jan 9, 2006, at 11:04 AM, Vikram Reddy wrote: > Hello folks, > > I had a question about the FSM in BGP-4. > I am not sure, but was there was a problem > in BGP 4 (RFC 177) with the FSM collision detection rules? > > According to what I vaguely remember, there was particular > sequence of message passing between peers which > would result in both of them getting stuck in the > active state. > > This was supposed to be addressed in the later idr drafts. > > Could you please comment on this and let me know if > I am right or wrong? > > Thanks. > Vikram. > > _______________________________________________ > 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 Jan 09 15:22: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 1Ew3Wk-0003VX-MQ; Mon, 09 Jan 2006 15:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew3Wi-0003TN-KH for idr@megatron.ietf.org; Mon, 09 Jan 2006 15:22:00 -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 PAA19456 for ; Mon, 9 Jan 2006 15:20:42 -0500 (EST) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew3dG-0002ER-HF for idr@ietf.org; Mon, 09 Jan 2006 15:28:47 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id BB37619C5; Mon, 9 Jan 2006 20:21:36 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 271kaiuVI0334Mo2; Mon, 09 Jan 2006 20:21:35 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 264kaiuVh0334Mo2; Mon, 09 Jan 2006 20:21:33 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Mon, 09 Jan 2006 20:21:33 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID821kaiuVh4928Xo2 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by GW1.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 13:21:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 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] BGP4 FSM question Date: Mon, 9 Jan 2006 13:21:29 -0700 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F0202C62633@VS4.EXCHPROD.USA.NET> Thread-Topic: [Idr] BGP4 FSM question Thread-Index: AcYVVrCANcPEBmX6SMC3ig+T9MYIiAAA2GmQ From: "Susan Hares" To: "Tony Li" , "Vikram Reddy" X-OriginalArrivalTime: 09 Jan 2006 20:21:32.0528 (UTC) FILETIME=[47F77F00:01C6155A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable 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 Vikram: Collision state was fixed by working group. Please see draft. Draft is at RFC level. Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Tony Li Sent: Monday, January 09, 2006 2:45 PM To: Vikram Reddy Cc: idr@ietf.org Subject: Re: [Idr] BGP4 FSM question Please see draft-ietf-idr-bgp4-26.txt Tony On Jan 9, 2006, at 11:04 AM, Vikram Reddy wrote: > Hello folks, > > I had a question about the FSM in BGP-4. > I am not sure, but was there was a problem > in BGP 4 (RFC 177) with the FSM collision detection rules? > > According to what I vaguely remember, there was particular > sequence of message passing between peers which > would result in both of them getting stuck in the > active state. > > This was supposed to be addressed in the later idr drafts. > > Could you please comment on this and let me know if > I am right or wrong? > > Thanks. > Vikram. > > _______________________________________________ > 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 10 06:02: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 1EwHGa-0002h8-DE; Tue, 10 Jan 2006 06:02:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwHGY-0002fQ-Ms for idr@megatron.ietf.org; Tue, 10 Jan 2006 06:02:14 -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 GAA21949 for ; Tue, 10 Jan 2006 06:00:55 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwHNE-0004zG-DI for idr@ietf.org; Tue, 10 Jan 2006 06:09:09 -0500 Received: by xproxy.gmail.com with SMTP id s9so2683754wxc for ; Tue, 10 Jan 2006 03:02:10 -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=JXoSbQmGrThx4hSZ3iFJZD35zWI0yuCqpKQ7fqC4s3CygNb2dNSWN31a/HAYE6Y4YlDcq9GxZTsp16Bm1qwWOilEKoUveJSC7KbKJDZQH7d3ViO4QKNlPYD71AjLPDBAHGYeygHBkFHxvpd727nuqt0Vqyt4WlZ7PWtZfbG/Ens= Received: by 10.70.91.7 with SMTP id o7mr6324399wxb; Tue, 10 Jan 2006 03:02:09 -0800 (PST) Received: by 10.70.70.13 with HTTP; Tue, 10 Jan 2006 03:02:09 -0800 (PST) Message-ID: Date: Tue, 10 Jan 2006 16:32:09 +0530 From: Maneesh Chawla To: idr@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Idr] Aggregation and dampening 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="===============1145428218==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --===============1145428218== Content-Type: multipart/alternative; boundary="----=_Part_14029_15889227.1136890929981" ------=_Part_14029_15889227.1136890929981 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All, I have a question on aggregation and dampening. Consider the topology, R1-----R3-------R4 | | R2------| 1. R1 and R2 are advertising 66.0.0.0/32 and 66.0.0.1/32 to R3 respectively= . 2. R3 is aggregating the routes (with the as-set command ) and advertising to R4. Since it is using the as-set option, all the path attributes are considered and if one of the routes flap , say the route from R2, the aggregate flap to R4 will flap. 3. Now , connfigure dampening also on R3. Is it right to expect that now when the route from R2 flaps, it should be damped so as to not affect the aggregate ? To put it more elaboratively , say the route from R2 flaps and reaches supress value and is thereby suppressed, should it still contribute to the aggregate or stop contributing to the aggregate ? Is this implementation specific ? Thanks Maneesh p.s : Sorry , if it is a very basic question in this forum. ------=_Part_14029_15889227.1136890929981 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All,
           I h= ave a question on aggregation and dampening.

Consider the topology,<= br>
R1-----R3-------R4
       &nbs= p;  |
          |
R= 2------|


1. R1 and R2 are advertising 66.0.0.0/32 and 66.0.0.1/32 to R3 re= spectively.
2. R3 is aggregating the routes (with the as-set command ) a= nd advertising to R4. Since it is using the as-set option, all the path att= ributes are considered and if one of the routes flap , say the route from R= 2, the aggregate flap to R4 will flap.
3. Now , connfigure dampening also on R3.
  
 &n= bsp;      Is it right to expect that now when the = route from R2 flaps, it should be damped so as to not affect the aggregate = ? To put it more elaboratively , say  the route from R2 flaps and reac= hes supress value and is thereby suppressed, should it still contribute to = the aggregate or stop contributing to the aggregate ?
        Is this implementation speci= fic ?

Thanks
Maneesh

p.s : Sorry , if it is a very basic q= uestion in this forum.
        &= nbsp;
------=_Part_14029_15889227.1136890929981-- --===============1145428218== 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 --===============1145428218==-- From idr-bounces@ietf.org Tue Jan 10 06:41:59 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 1EwHt0-0002ix-U2; Tue, 10 Jan 2006 06:41:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwHsz-0002ip-IB for idr@megatron.ietf.org; Tue, 10 Jan 2006 06:41:57 -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 GAA23804 for ; Tue, 10 Jan 2006 06:40:38 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwHzc-0005tw-8G for idr@ietf.org; Tue, 10 Jan 2006 06:48:53 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISV000J0KZZPR@szxga02-in.huawei.com> for idr@ietf.org; Tue, 10 Jan 2006 19:52:48 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISV00BUIKZZ82@szxga02-in.huawei.com> for idr@ietf.org; Tue, 10 Jan 2006 19:52:47 +0800 (CST) Received: from AnjanKumar ([10.18.4.90]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISV00D2UKZQEJ@szxml02-in.huawei.com>; Tue, 10 Jan 2006 19:52:39 +0800 (CST) Date: Tue, 10 Jan 2006 17:11:21 +0530 From: Anjan Subject: RE: [Idr] Aggregation and dampening In-reply-to: To: "'Maneesh Chawla'" , idr@ietf.org Message-id: <000501c615da$c82a5870$5a04120a@china.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: anjanhg@huawei.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1936300343==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============1936300343== Content-type: multipart/alternative; boundary="Boundary_(ID_TZxtm6+OKF3xaH4R7VOBvA)" This is a multi-part message in MIME format. --Boundary_(ID_TZxtm6+OKF3xaH4R7VOBvA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi Maneesh, I feel Dampening should be considered irrespective of what you are doing in aggregation. When dampening is configured, route can take two values Dampened or History. Dampened route is valid to advertise. History route is not valid to advertise. So whether the route can be considered for aggregation or not, depends on this state - dampened or history. With specific answer to your question, If the route is in Dampened state it should contribute for Aggregation. If it is in History state it should not contribute for Aggregation. Any different opinion in the group? Regards, Anjan ************************************************************************ *************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Maneesh Chawla Sent: Tuesday, January 10, 2006 4:32 PM To: idr@ietf.org Subject: [Idr] Aggregation and dampening Hi All, I have a question on aggregation and dampening. Consider the topology, R1-----R3-------R4 | | R2------| 1. R1 and R2 are advertising 66.0.0.0/32 and 66.0.0.1/32 to R3 respectively. 2. R3 is aggregating the routes (with the as-set command ) and advertising to R4. Since it is using the as-set option, all the path attributes are considered and if one of the routes flap , say the route from R2, the aggregate flap to R4 will flap. 3. Now , connfigure dampening also on R3. Is it right to expect that now when the route from R2 flaps, it should be damped so as to not affect the aggregate ? To put it more elaboratively , say the route from R2 flaps and reaches supress value and is thereby suppressed, should it still contribute to the aggregate or stop contributing to the aggregate ? Is this implementation specific ? Thanks Maneesh p.s : Sorry , if it is a very basic question in this forum. --Boundary_(ID_TZxtm6+OKF3xaH4R7VOBvA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi Maneesh,

 

I feel Dampening should be considered irrespective of what you are doing in aggregation.

When dampening is configured, route can take two values Dampened or History.

Dampened route is valid to advertise.  History route is not valid to advertise.

 

So whether the route can be considered for aggregation or not, depends on this state – dampened or history.

 

With specific answer to your question, If the route is in Dampened state it should contribute for Aggregation.

If it is in History state it should not contribute for Aggregation.

 

Any different opinion in the group?

 

Regards,

Anjan

 

 

 

***************************************************************************************

            This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Maneesh Chawla
Sent: Tuesday, January 10, 2006 4:32 PM
To: idr@ietf.org
Subject: [Idr] Aggregation and dampening

 

Hi All,
           I have a question on aggregation and dampening.

Consider the topology,

R1-----R3-------R4
          |
          |
R2------|


1. R1 and R2 are advertising 66.0.0.0/32 and 66.0.0.1/32 to R3 respectively.
2. R3 is aggregating the routes (with the as-set command ) and advertising to R4. Since it is using the as-set option, all the path attributes are considered and if one of the routes flap , say the route from R2, the aggregate flap to R4 will flap.
3. Now , connfigure dampening also on R3.
  
        Is it right to expect that now when the route from R2 flaps, it should be damped so as to not affect the aggregate ? To put it more elaboratively , say  the route from R2 flaps and reaches supress value and is thereby suppressed, should it still contribute to the aggregate or stop contributing to the aggregate ?
        Is this implementation specific ?

Thanks
Maneesh

p.s : Sorry , if it is a very basic question in this forum.
         

--Boundary_(ID_TZxtm6+OKF3xaH4R7VOBvA)-- --===============1936300343== 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 --===============1936300343==-- From idr-bounces@ietf.org Tue Jan 10 06:57: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 1EwI7u-0006Nd-0b; Tue, 10 Jan 2006 06:57:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwI7r-0006NV-Us for idr@megatron.ietf.org; Tue, 10 Jan 2006 06:57: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 GAA24630 for ; Tue, 10 Jan 2006 06:56:00 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwIDo-0006Fs-Ru for idr@ietf.org; Tue, 10 Jan 2006 07:04:15 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISV00050LOMPR@szxga02-in.huawei.com> for idr@ietf.org; Tue, 10 Jan 2006 20:07:35 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISV0005NLOMU7@szxga02-in.huawei.com> for idr@ietf.org; Tue, 10 Jan 2006 20:07:34 +0800 (CST) Received: from AnjanKumar ([10.18.4.90]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISV00BV4LU7SJ@szxml01-in.huawei.com>; Tue, 10 Jan 2006 20:10:56 +0800 (CST) Date: Tue, 10 Jan 2006 17:26:15 +0530 From: Anjan Subject: RE: [Idr] Aggregation and dampening In-reply-to: <000501c615da$c82a5870$5a04120a@china.huawei.com> To: "'Maneesh Chawla'" , idr@ietf.org Message-id: <000501c615dc$dcc2f330$5a04120a@china.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: anjanhg@huawei.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2032315856==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============2032315856== Content-type: multipart/alternative; boundary="Boundary_(ID_Khtg2uogK/Clok/SWEwfNQ)" This is a multi-part message in MIME format. --Boundary_(ID_Khtg2uogK/Clok/SWEwfNQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Sorry, Dampened route I mean here is the 'route that just came out of Dampened state'.. ************************************************************************ *************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Anjan Sent: Tuesday, January 10, 2006 5:11 PM To: 'Maneesh Chawla'; idr@ietf.org Subject: RE: [Idr] Aggregation and dampening Hi Maneesh, I feel Dampening should be considered irrespective of what you are doing in aggregation. When dampening is configured, route can take two values Dampened or History. Dampened route is valid to advertise. History route is not valid to advertise. So whether the route can be considered for aggregation or not, depends on this state - dampened or history. With specific answer to your question, If the route is in Dampened state it should contribute for Aggregation. If it is in History state it should not contribute for Aggregation. Any different opinion in the group? Regards, Anjan ************************************************************************ *************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Maneesh Chawla Sent: Tuesday, January 10, 2006 4:32 PM To: idr@ietf.org Subject: [Idr] Aggregation and dampening Hi All, I have a question on aggregation and dampening. Consider the topology, R1-----R3-------R4 | | R2------| 1. R1 and R2 are advertising 66.0.0.0/32 and 66.0.0.1/32 to R3 respectively. 2. R3 is aggregating the routes (with the as-set command ) and advertising to R4. Since it is using the as-set option, all the path attributes are considered and if one of the routes flap , say the route from R2, the aggregate flap to R4 will flap. 3. Now , connfigure dampening also on R3. Is it right to expect that now when the route from R2 flaps, it should be damped so as to not affect the aggregate ? To put it more elaboratively , say the route from R2 flaps and reaches supress value and is thereby suppressed, should it still contribute to the aggregate or stop contributing to the aggregate ? Is this implementation specific ? Thanks Maneesh p.s : Sorry , if it is a very basic question in this forum. --Boundary_(ID_Khtg2uogK/Clok/SWEwfNQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Sorry, Dampened route I mean here is the ‘route that just came out of Dampened state’..

 

***************************************************************************************

            This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Anjan
Sent: Tuesday, January 10, 2006 5:11 PM
To: 'Maneesh Chawla'; idr@ietf.org
Subject: RE: [Idr] Aggregation and dampening

 

Hi Maneesh,

 

I feel Dampening should be considered irrespective of what you are doing in aggregation.

When dampening is configured, route can take two values Dampened or History.

Dampened route is valid to advertise.  History route is not valid to advertise.

 

So whether the route can be considered for aggregation or not, depends on this state – dampened or history.

 

With specific answer to your question, If the route is in Dampened state it should contribute for Aggregation.

If it is in History state it should not contribute for Aggregation.

 

Any different opinion in the group?

 

Regards,

Anjan

 

 

 

***************************************************************************************

            This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Maneesh Chawla
Sent: Tuesday, January 10, 2006 4:32 PM
To: idr@ietf.org
Subject: [Idr] Aggregation and dampening

 

Hi All,
           I have a question on aggregation and dampening.

Consider the topology,

R1-----R3-------R4
          |
          |
R2------|


1. R1 and R2 are advertising 66.0.0.0/32 and 66.0.0.1/32 to R3 respectively.
2. R3 is aggregating the routes (with the as-set command ) and advertising to R4. Since it is using the as-set option, all the path attributes are considered and if one of the routes flap , say the route from R2, the aggregate flap to R4 will flap.
3. Now , connfigure dampening also on R3.
  
        Is it right to expect that now when the route from R2 flaps, it should be damped so as to not affect the aggregate ? To put it more elaboratively , say  the route from R2 flaps and reaches supress value and is thereby suppressed, should it still contribute to the aggregate or stop contributing to the aggregate ?
        Is this implementation specific ?

Thanks
Maneesh

p.s : Sorry , if it is a very basic question in this forum.
         

--Boundary_(ID_Khtg2uogK/Clok/SWEwfNQ)-- --===============2032315856== 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 --===============2032315856==-- From idr-bounces@ietf.org Tue Jan 10 15:36:17 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 1EwQE5-0005YT-64; Tue, 10 Jan 2006 15:36:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQE4-0005YA-CH for idr@megatron.ietf.org; Tue, 10 Jan 2006 15:36:16 -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 PAA06208 for ; Tue, 10 Jan 2006 15:34:55 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQKp-00077f-7M for idr@ietf.org; Tue, 10 Jan 2006 15:43:16 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2006011020355901200jqoqje>; Tue, 10 Jan 2006 20:36:00 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Inter-Domain Routing List From: Tony Li Date: Tue, 10 Jan 2006 12:35:57 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 folks, Based on the discussion that we've had so far, the authors of the AS_HOPCOUNT draft would like to make some substantive changes to the draft. The chairs have asked that we poll you to ensure that we have rough consensus on the new direction. The primary technical points of these changes: - Convert AS_HOPCOUNT from being decremented at each AS boundary and instead have it be a static upper bound on the AS path length. - Rename the attribute to AS_PATHLIMIT. - Completely remove the interaction with NO_EXPORT. There are, of course, a number of details more fully explained in the revised draft, but before we are allowed to present you with the revision, we need to have your approval on the above. Could folks please comment to the list within the next two weeks as to whether or not this direction is acceptable? As this is to help gauge consensus, both positive and negative comments are solicited. Regards, Joe & Rex & Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 10 15:53:12 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 1EwQUS-0001UR-Jx; Tue, 10 Jan 2006 15:53:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQUR-0001UM-Go for idr@megatron.ietf.org; Tue, 10 Jan 2006 15:53:11 -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 PAA07281 for ; Tue, 10 Jan 2006 15:51:50 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQbC-0007bJ-CM for idr@ietf.org; Tue, 10 Jan 2006 16:00:11 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 485A72301B1 for ; Tue, 10 Jan 2006 12:52:54 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13849-02 for ; Tue, 10 Jan 2006 12:52:53 -0800 (PST) Received: from [155.53.44.78] (horizon.redback.com [155.53.44.78]) by prattle.redback.com (Postfix) with ESMTP id BDD722301AD for ; Tue, 10 Jan 2006 12:52:47 -0800 (PST) Message-ID: <43C41E9F.7080007@redback.com> Date: Tue, 10 Jan 2006 12:52:47 -0800 From: Vikram Reddy User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Idr] Cisco BGP question 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 Hello folks, I have a question about Cisco's implementation of BGP. Is automatic start enabled by default in Cisco BGP? i.e if a BGP session goes to idle, does Cisco generate BGP start events automatically or is it only with manual intervention. If the default is not to automatically generate start events, what is the command to enable it on Cisco. Thanks, Vikram. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 10 15:57:59 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 1EwQZ5-0002fc-Bm; Tue, 10 Jan 2006 15:57:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQZ3-0002fO-KQ for idr@megatron.ietf.org; Tue, 10 Jan 2006 15:57:57 -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 PAA07847 for ; Tue, 10 Jan 2006 15:56:36 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQfo-0007uV-Dv for idr@ietf.org; Tue, 10 Jan 2006 16:04:57 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id A31C0642DD for ; Tue, 10 Jan 2006 13:57:29 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7267AF7C-6671-4379-9FDC-7BC693F8B35F@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Tue, 10 Jan 2006 13:57:43 -0700 To: Inter-Domain Routing List X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit 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 On Jan 10, 2006, at 1:35 PM, Tony Li wrote: > > Could folks please comment to the list within the next two weeks as > to whether or not this direction > is acceptable? As this is to help gauge consensus, both positive > and negative comments are > solicited. For sake of progress: I'm in favor of all these changes to the draft... -------------- For sake of other: I'm surprised you're being asked to poll the WG before instituting them. Out of curiosity, how many hands are required to move forward? And is there some pre-determined percentage of in-favor/not-in-favor that dictates reasonable consensus in the face of contention? It's just that I'd really rather not see the noise - if folks take issue with these changes shouldn't they comment when said issues are being discussed? -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 10 16:00: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 1EwQbW-0003Dd-Bq; Tue, 10 Jan 2006 16:00:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQbU-0003DY-ES for idr@megatron.ietf.org; Tue, 10 Jan 2006 16:00: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 PAA08285 for ; Tue, 10 Jan 2006 15:59:07 -0500 (EST) Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQiF-000880-N5 for idr@ietf.org; Tue, 10 Jan 2006 16:07:28 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2006011021001401200jovr4e>; Tue, 10 Jan 2006 21:00:15 +0000 In-Reply-To: <43C41E9F.7080007@redback.com> References: <43C41E9F.7080007@redback.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0DB0660B-408E-4EA9-8BDF-E7564D67B3F6@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Cisco BGP question Date: Tue, 10 Jan 2006 13:00:12 -0800 To: Vikram Reddy X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Please contact Cisco technical support. Tony On Jan 10, 2006, at 12:52 PM, Vikram Reddy wrote: > Hello folks, > > I have a question about Cisco's implementation of BGP. > > Is automatic start enabled by default in Cisco BGP? > i.e if a BGP session goes to idle, does Cisco > generate BGP start events automatically or is it only > with manual intervention. > > If the default is not to automatically generate start events, > what is the command to enable it on Cisco. > > Thanks, > Vikram. > > _______________________________________________ > 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 Tue Jan 10 17:37:42 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 1EwS7a-0000Yy-1L; Tue, 10 Jan 2006 17:37:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwS7Y-0000Yt-3M for idr@megatron.ietf.org; Tue, 10 Jan 2006 17:37:40 -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 RAA15269 for ; Tue, 10 Jan 2006 17:36:20 -0500 (EST) Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwSEI-0002gO-G8 for idr@ietf.org; Tue, 10 Jan 2006 17:44:41 -0500 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id E198C3442; Tue, 10 Jan 2006 22:37:12 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 493kaJwlL0364Mo1; Tue, 10 Jan 2006 22:37:11 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 489kaJwlJ0364Mo1; Tue, 10 Jan 2006 22:37:09 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.27I); Tue, 10 Jan 2006 22:37:09 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID618kaJwlJ2112Xo1 Received: from localhost ([65.247.36.31]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 Jan 2006 15:37:09 -0700 Date: Tue, 10 Jan 2006 17:37:08 -0500 From: Jeffrey Haas To: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Message-ID: <20060110223708.GB12691@nexthop.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 10 Jan 2006 22:37:09.0345 (UTC) FILETIME=[644CFD10:01C61636] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Inter-Domain Routing List 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, Apologies for not chiming in earlier. Vacations and all that. :-) My comments for the proposed feature are interspersed and cover a number of previous e-mails. On Tue, Jan 10, 2006 at 12:35:57PM -0800, Tony Li wrote: > - Convert AS_HOPCOUNT from being decremented at each AS boundary and > instead have it > be a static upper bound on the AS path length. > > - Rename the attribute to AS_PATHLIMIT. I prefer the decrement behavior. > - Completely remove the interaction with NO_EXPORT. I would agree. John Leslie brought up an interesting case that it woule be safe to simply set NO_EXPORT when hopcount was 1 and we are propagating the route. It helps to guarantee that the next AS will not propagate it, even if it doesn't understand the AS_HOPCOUNT attribute. Another comment (Danny I think) spoke about where we check the value. If the value was checked upon egress, then we can avoid sending the route to a downstream BGP speaker that may not understand the attribute. (Checking the value upon ingress in addition to egress is probably a safe thing to do.) Another previous comment suggests that we may not simply want to rely on the behavior of BGP speakers that understand the feature to decrement the value, but that we may wish to decrement it when we think that it may not have been decremented for us. If confederations weren't a condition upon which the value was decremented, then it would be possible to use the number of distinct ASes after the advisory value to determine if the count was what we expected. In the following example, presume that the BGP speaker doesn't propagate the route if the decremented value would be zero. (Change from the spec in-line with my comments above.) E.g.: A --- B --- C --- D --- E If A sets the value to 2, we would expect B and C to receive the route and AS-A would be in the attribute. If C doesn't understand the attribute, but D does, D can examine the AS_PATH C B A and determine that the expected hop count has already been exceeded. Padding would need to be accounted for, so padding would need to be ignored when determining the number of ASes that have been transited. Other comments: The 4 byte AS number in the attribute is probably a good idea. However, we should carefully explain the behavior when the 4 byte AS must be utilized by a 2byte speaker. Like Danny, I would prefer that confederation boundaries be ignored for purposes of the count. However, this is also something I expect that vendors may prefer to implement a knob to affect the behavior. I think it would be good to specify behavior when aggregating routes containing this attribute. Your text regarding ATOMIC_AGGREGATE seems very 1771'ish. The current text on ATOMIC_AGGREGATE isn't quite as stringent on how this attribute is set. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 10 18:00:34 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 1EwSTi-0005pf-Ej; Tue, 10 Jan 2006 18:00:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwSTg-0005pa-MY for idr@megatron.ietf.org; Tue, 10 Jan 2006 18:00:33 -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 RAA16911 for ; Tue, 10 Jan 2006 17:59:13 -0500 (EST) Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwSaS-0003RF-UQ for idr@ietf.org; Tue, 10 Jan 2006 18:07:34 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2006011023001001200jqb1le>; Tue, 10 Jan 2006 23:00:11 +0000 In-Reply-To: <20060110223708.GB12691@nexthop.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <20060110223708.GB12691@nexthop.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Tue, 10 Jan 2006 15:00:08 -0800 To: Jeffrey Haas X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 Jeffrey, > Another comment (Danny I think) spoke about where we check the > value. If the value was checked upon egress, then we can avoid > sending the route to a downstream BGP speaker that may not understand > the attribute. This is also addressed in the revised draft, but is actually more of an implementation issue. > (Checking the value upon ingress in addition to egress is probably > a safe thing to do.) Yes, the revised draft specifies both checks. > Another previous comment suggests that we may not simply want to rely > on the behavior of BGP speakers that understand the feature to > decrement the value, but that we may wish to decrement it when > we think that it may not have been decremented for us. If > confederations > weren't a condition upon which the value was decremented, then it > would be possible to use the number of distinct ASes after the > advisory value to determine if the count was what we expected. This was exactly why we were shifting to a static value and way from decrement. > The 4 byte AS number in the attribute is probably a good idea. > However, we should carefully explain the behavior when the 4 byte > AS must be utilized by a 2byte speaker. The draft references the encoding rules used in the 4 octet draft. > Like Danny, I would prefer that confederation boundaries be ignored > for purposes of the count. However, this is also something I expect > that vendors may prefer to implement a knob to affect the behavior. The revised draft specifies that confederations be ignored. Extensions on top of this are, as you note, optional and perhaps inevitable. > I think it would be good to specify behavior when aggregating routes > containing this attribute. > > Your text regarding ATOMIC_AGGREGATE seems very 1771'ish. The current > text on ATOMIC_AGGREGATE isn't quite as stringent on how this > attribute is set. You'll pardon me if my paranoia regarding deaggregation hasn't abated in the last 15 years. ;-) If you feel additional text is warranted, contributions are most welcome. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 10 19:38:21 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 1EwU0L-0003cd-71; Tue, 10 Jan 2006 19:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwU0I-0003cY-TX for idr@megatron.ietf.org; Tue, 10 Jan 2006 19:38:19 -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 TAA25587 for ; Tue, 10 Jan 2006 19:36:58 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19/5jkSo7hMyfBRTxJIQ/Msv+76A6VH6u8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwU75-0006xs-8u for idr@ietf.org; Tue, 10 Jan 2006 19:45:21 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+wPzMTr5Z9Fb1UHM6fhYv8PGDRIc61rds@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k0B0bhMi016497; Wed, 11 Jan 2006 00:37:50 GMT Date: Wed, 11 Jan 2006 00:37:43 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT In-Reply-To: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Message-ID: References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="299119927-197416382-1136939863=:3405" X-Virus-Scanned: ClamAV 0.87.1/1237/Tue Jan 10 15:53:20 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Inter-Domain Routing List 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --299119927-197416382-1136939863=:3405 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by hibernia.jakma.org id k0B0bhMi016497 Content-Transfer-Encoding: quoted-printable On Tue, 10 Jan 2006, Tony Li wrote: > - Convert AS_HOPCOUNT from being decremented at each AS boundary=20 > and instead have it be a static upper bound on the AS path length. Hmm, a simple decrement seems nicer. I hate dependencies between attributes, particularly (here) on the=20 relatively vague property of path length. If you have to depend on=20 some other attribute, I'd prefer the no-export interaction/dependency=20 to this one. My =E2=82=AC0.02 anyway. regards, --=20 Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: On Thanksgiving Day all over America, families sit down to dinner at the same moment -- halftime. --299119927-197416382-1136939863=:3405 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 --299119927-197416382-1136939863=:3405-- From idr-bounces@ietf.org Tue Jan 10 21:14:04 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 1EwVUy-0000lM-Ca; Tue, 10 Jan 2006 21:14:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwVUx-0000lF-6c for idr@megatron.ietf.org; Tue, 10 Jan 2006 21:14:03 -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 VAA01735 for ; Tue, 10 Jan 2006 21:12:42 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwVbj-0001Ge-3C for idr@ietf.org; Tue, 10 Jan 2006 21:21:06 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2006 18:12:50 -0800 X-IronPort-AV: i="3.99,352,1131350400"; d="scan'208"; a="248245940:sNHT3593341874" Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0B2CoWF002410; Tue, 10 Jan 2006 18:12:50 -0800 (PST) Message-ID: <43C469A2.8000005@cisco.com> Date: Tue, 10 Jan 2006 18:12:50 -0800 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> In-Reply-To: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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, Tony: Tony Li wrote: > > Hi folks, > > Based on the discussion that we've had so far, the authors of the > AS_HOPCOUNT draft would > like to make some substantive changes to the draft. The chairs have > asked that we poll you to > ensure that we have rough consensus on the new direction. The primary > technical points of > these changes: > > - Convert AS_HOPCOUNT from being decremented at each AS boundary and > instead have it > be a static upper bound on the AS path length. It is not clear to me how this would work with "ASPATH prepend", especially in an environment where some routers recognize the new attribute, and some do not (thus can not adjust the hopcount with prepend). More specifically, consider a routing announcement from A --> B --> C -- > D --> E, each has its own AS (say a, b, c, d, e respectively). 1) Router A recognizes the attribute, and set the hopcount to 5 with the intention for the announcement to reach E. 2) Router B does not recognize the attribute, thus would pass the new attribute. But it does AS prepend toward C, and the ASPATH would be: b b b b a 3) Router C recognize the attribute, and would not advertise the route to D due to the hopcount. On the other hand, the AS_HOPCOUNT as a decrementor does not have this loss of connectivity issue. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 10 21:23:59 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 1EwVeY-0003uR-WC; Tue, 10 Jan 2006 21:23:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwVeX-0003u7-2j for idr@megatron.ietf.org; Tue, 10 Jan 2006 21:23:57 -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 VAA02346 for ; Tue, 10 Jan 2006 21:22:35 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwVlK-0001X5-It for idr@ietf.org; Tue, 10 Jan 2006 21:30:59 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2006 21:23:47 -0500 X-IronPort-AV: i="3.99,352,1131339600"; d="scan'208"; a="79989641:sNHT30693868" Received: from RussPC (rtp-vpn2-288.cisco.com [10.82.241.32]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0B2NfJg007959; Tue, 10 Jan 2006 21:23:44 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Tue, 10 Jan 2006 21:23:43 -0500 X-PGP-Universal: processed; by RussPC on Tue, 10 Jan 2006 21:23:43 -0500 Message-ID: <43C46C27.9020002@cisco.com> Date: Tue, 10 Jan 2006 21:23:35 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Enke Chen Subject: Re: [Idr] Next revision of AS_HOPCOUNT References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <43C469A2.8000005@cisco.com> In-Reply-To: <43C469A2.8000005@cisco.com> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Inter-Domain Routing List , Tony Li 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Based on the discussion that we've had so far, the authors of the >> AS_HOPCOUNT draft would >> like to make some substantive changes to the draft. The chairs have >> asked that we poll you to >> ensure that we have rough consensus on the new direction. The primary >> technical points of >> these changes: >> >> - Convert AS_HOPCOUNT from being decremented at each AS boundary and >> instead have it >> be a static upper bound on the AS path length. > > It is not clear to me how this would work with "ASPATH prepend", > especially in an environment where some routers recognize the new > attribute, and some do not (thus can not adjust the hopcount with prepend). > > More specifically, consider a routing announcement from A --> B --> C -- > > D --> E, each has its own AS (say a, b, c, d, e respectively). > > 1) Router A recognizes the attribute, and set the hopcount to 5 with the > intention for the announcement to reach E. > 2) Router B does not recognize the attribute, thus would pass the new > attribute. But it does AS prepend toward C, and the ASPATH would be: b b > b b a > 3) Router C recognize the attribute, and would not advertise the route > to D due to the hopcount. > > On the other hand, the AS_HOPCOUNT as a decrementor does not have this > loss of connectivity issue. It seems to me that what you want is the "absolute length" of the AS Path--the number of unique AS' in the path--rather than the "literal length." I know most implemenations (no implementations?) can do this today, but the absolute length seems like the only way to actually make the as hop count work in all situations. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8RsLxEdu7FIVPTkEQLvJQCgjrvrHZGwcrHl5noaXyg7/HWDFXUAoMov kyDY2aCYTaqV4Slggkn87RtV =kzMf -----END PGP SIGNATURE----- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 10 21:28:46 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 1EwVjC-0004Nm-L8; Tue, 10 Jan 2006 21:28:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwVjB-0004Ne-B8 for idr@megatron.ietf.org; Tue, 10 Jan 2006 21:28:45 -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 VAA02727 for ; Tue, 10 Jan 2006 21:27:24 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwVpy-0001fx-WB for idr@ietf.org; Tue, 10 Jan 2006 21:35:48 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2006 18:28:34 -0800 X-IronPort-AV: i="3.99,352,1131350400"; d="scan'208"; a="248253409:sNHT31803228" Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0B2SYWF009101; Tue, 10 Jan 2006 18:28:34 -0800 (PST) Message-ID: <43C46D52.9090707@cisco.com> Date: Tue, 10 Jan 2006 18:28:34 -0800 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ White Subject: Re: [Idr] Next revision of AS_HOPCOUNT References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <43C469A2.8000005@cisco.com> <43C46C27.9020002@cisco.com> In-Reply-To: <43C46C27.9020002@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Tony Li 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 Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > > >>>Based on the discussion that we've had so far, the authors of the >>>AS_HOPCOUNT draft would >>>like to make some substantive changes to the draft. The chairs have >>>asked that we poll you to >>>ensure that we have rough consensus on the new direction. The primary >>>technical points of >>>these changes: >>> >>>- Convert AS_HOPCOUNT from being decremented at each AS boundary and >>>instead have it >>>be a static upper bound on the AS path length. >>> >>> >>It is not clear to me how this would work with "ASPATH prepend", >>especially in an environment where some routers recognize the new >>attribute, and some do not (thus can not adjust the hopcount with prepend). >> >>More specifically, consider a routing announcement from A --> B --> C -- >> > D --> E, each has its own AS (say a, b, c, d, e respectively). >> >>1) Router A recognizes the attribute, and set the hopcount to 5 with the >>intention for the announcement to reach E. >>2) Router B does not recognize the attribute, thus would pass the new >>attribute. But it does AS prepend toward C, and the ASPATH would be: b b >>b b a >>3) Router C recognize the attribute, and would not advertise the route >>to D due to the hopcount. >> >>On the other hand, the AS_HOPCOUNT as a decrementor does not have this >>loss of connectivity issue. >> >> > >It seems to me that what you want is the "absolute length" of the AS >Path--the number of unique AS' in the path--rather than the "literal >length." I know most implemenations (no implementations?) can do this >today, but the absolute length seems like the only way to actually make >the as hop count work in all situations. > > What if the prepend is "x y z" instead? It seems to me that the "decrementor" as previously defined is simpler. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 10 21:49:37 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 1EwW3N-0003hV-0k; Tue, 10 Jan 2006 21:49:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwW3M-0003hQ-4D for idr@megatron.ietf.org; Tue, 10 Jan 2006 21:49:36 -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 VAA04257 for ; Tue, 10 Jan 2006 21:48:15 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwWAB-0002IW-9t for idr@ietf.org; Tue, 10 Jan 2006 21:56:39 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 10 Jan 2006 18:49:27 -0800 X-IronPort-AV: i="3.99,352,1131350400"; d="scan'208"; a="1765409113:sNHT31477060" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0B2nQQV028380; Tue, 10 Jan 2006 18:49:26 -0800 (PST) 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.211); Tue, 10 Jan 2006 18:49:14 -0800 Received: from [128.107.163.59] ([128.107.163.59]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 Jan 2006 18:49:14 -0800 Message-ID: <43C47242.5030801@cisco.com> Date: Tue, 10 Jan 2006 18:49:38 -0800 From: Keyur User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Enke Chen Subject: Re: [Idr] Next revision of AS_HOPCOUNT References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <43C469A2.8000005@cisco.com> In-Reply-To: <43C469A2.8000005@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2006 02:49:14.0108 (UTC) FILETIME=[9B5CABC0:01C61659] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Tony Li 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 Enke: Enke Chen wrote: > Hi, Tony: > > Tony Li wrote: > >> >> Hi folks, >> >> Based on the discussion that we've had so far, the authors of the >> AS_HOPCOUNT draft would >> like to make some substantive changes to the draft. The chairs have >> asked that we poll you to >> ensure that we have rough consensus on the new direction. The primary >> technical points of >> these changes: >> >> - Convert AS_HOPCOUNT from being decremented at each AS boundary and >> instead have it >> be a static upper bound on the AS path length. > > > > It is not clear to me how this would work with "ASPATH prepend", > especially in an environment where some routers recognize the new > attribute, and some do not (thus can not adjust the hopcount with prepend). > > More specifically, consider a routing announcement from A --> B --> C -- > > D --> E, each has its own AS (say a, b, c, d, e respectively). > > 1) Router A recognizes the attribute, and set the hopcount to 5 with the > intention for the announcement to reach E. > 2) Router B does not recognize the attribute, thus would pass the new > attribute. But it does AS prepend toward C, and the ASPATH would be: b b > b b a Would it be too bad to modify the hopcount at this point to reflect the number of prepend ASes? -Keyur > 3) Router C recognize the attribute, and would not advertise the route > to D due to the hopcount. > > On the other hand, the AS_HOPCOUNT as a decrementor does not have this > loss of connectivity issue. > > -- Enke > > > _______________________________________________ > 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 Tue Jan 10 22:21:15 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 1EwWXz-00049H-Iw; Tue, 10 Jan 2006 22:21:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwWXx-000498-8z for idr@megatron.ietf.org; Tue, 10 Jan 2006 22:21:13 -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 WAA06123 for ; Tue, 10 Jan 2006 22:19:54 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwWel-000375-KY for idr@ietf.org; Tue, 10 Jan 2006 22:28:17 -0500 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EwWXa-0002QP-IQ; Wed, 11 Jan 2006 03:20:51 +0000 In-Reply-To: <43C469A2.8000005@cisco.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <43C469A2.8000005@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A88B2AA-B26A-40BC-BA41-A2DDB4FFE5B2@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Tue, 10 Jan 2006 22:20:49 -0500 To: Enke Chen X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Tony Li 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 On 10-Jan-2006, at 21:12, Enke Chen wrote: > Tony Li wrote: > >> - Convert AS_HOPCOUNT from being decremented at each AS boundary >> and instead have it be a static upper bound on the AS path length. > > not clear to me how this would work with "ASPATH prepend", > especially in an environment where some routers recognize the new > attribute, and some do not (thus can not adjust the hopcount with > prepend). I think the intention of Tony's text is clearer if it is rephrased as "static upper bound on the length of the modified AS_PATH attribute", where the modification referred to is the elimination of private-use numbers, etc. > More specifically, consider a routing announcement from A --> B --> > C -- > D --> E, each has its own AS (say a, b, c, d, e respectively). > > 1) Router A recognizes the attribute, and set the hopcount to 5 > with the intention for the announcement to reach E. > 2) Router B does not recognize the attribute, thus would pass the > new attribute. But it does AS prepend toward C, and the ASPATH > would be: b b b b a > 3) Router C recognize the attribute, and would not advertise the > route to D due to the hopcount. Correct. > On the other hand, the AS_HOPCOUNT as a decrementor does not have > this loss of connectivity issue. When viewed from another angle, AS_HOPCOUNT as decrementor fails to take account of the fact that B is prepending towards C (presumably for a reason). It does not seem inconsistent with the intentions of A's operator for the route to be dropped in this case before it reaches E. Even with more elaborate mechanisms at your disposal, when you're second-guessign the routing policies of remote networks, the best you can do is try to influence propagation. There is no absolute control. Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jan 10 22:30:54 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 1EwWhK-0005rX-Lp; Tue, 10 Jan 2006 22:30:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwWhI-0005qE-Jf for idr@megatron.ietf.org; Tue, 10 Jan 2006 22:30:52 -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 WAA06844 for ; Tue, 10 Jan 2006 22:29:33 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwWo8-0003RH-4T for idr@ietf.org; Tue, 10 Jan 2006 22:37:56 -0500 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EwWh9-0002h2-3f; Wed, 11 Jan 2006 03:30:43 +0000 In-Reply-To: <43C46D52.9090707@cisco.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <43C469A2.8000005@cisco.com> <43C46C27.9020002@cisco.com> <43C46D52.9090707@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <073C64FB-29F9-442C-B8C0-96FD9F5F9384@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Tue, 10 Jan 2006 22:30:41 -0500 To: Enke Chen X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Tony Li , Russ White 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 On 10-Jan-2006, at 21:28, Enke Chen wrote: > It seems to me that the "decrementor" as previously defined is > simpler. I think they are both fairly simple. I think that bounding the AS_PATH length has greater chance of being useful in the short term for applications where propagating too little is greatly preferred over propagating too widely (e.g. "local nodes" providing anycast service distribution): the AS-count variable (AS_PATH) continues to happen in routers without this new functionality. By comparison, the decrementor behaviour (without the NO_EXPORT interaction, which was intended to bridge the implementation gap) will need quite substantial deployment before it can be used for the anycast node application. Clearly anycast nodes are not the only potential consumers of this mechanism, but it seems like a shame not to accommodate their requirements if we can. Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 00:18:33 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 1EwYIP-0003Cq-1W; Wed, 11 Jan 2006 00:13:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwYIM-0003Cl-Rn for idr@megatron.ietf.org; Wed, 11 Jan 2006 00:13:14 -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 AAA13002 for ; Wed, 11 Jan 2006 00:11:54 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwYPB-0006J3-R9 for idr@ietf.org; Wed, 11 Jan 2006 00:20:19 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2006011105125401100dcmn4e>; Wed, 11 Jan 2006 05:12:55 +0000 In-Reply-To: <43C46D52.9090707@cisco.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <43C469A2.8000005@cisco.com> <43C46C27.9020002@cisco.com> <43C46D52.9090707@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Tue, 10 Jan 2006 21:12:53 -0800 To: Enke Chen X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Russ White 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 > It seems to me that the "decrementor" as previously defined is > simpler. In addition to Joe's comments... The problem that we had with decrementing the hopcount is that the semantics of this got VERY messy when we also tried to take into account partial deployment. Which AS's decrement? Which routers within the AS decrement? It all depends on the software rev of each individual router. You could have two routers from the same AS that advertise the same prefix to you with two different hopcounts, all based on the same original advertisement. Having a static constant in the attribute is simpler, in that the first receiver that supports PATHLIMIT that sees a too-long AS_PATH can discard the route. There is no ambiguity about the semantics. Yes, we need to deal with prepend, but whatever way we choose, the semantics are straightforward. And if there is *ANYTHING* that my years of experience have taught me, it's to favor the straightforward semantics. ;-) Tony p.s. I should also point out that this issue was discussed on the mailing list a few weeks ago. The consensus on this issue seemed pretty clear to me. Folks in favor of decrement were NOT speaking up. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 00:46: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 1EwYoc-0005zl-OV; Wed, 11 Jan 2006 00:46:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwYoa-0005zT-Qx for idr@megatron.ietf.org; Wed, 11 Jan 2006 00:46:32 -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 AAA15234 for ; Wed, 11 Jan 2006 00:45:12 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwYvR-0007Io-Bs for idr@ietf.org; Wed, 11 Jan 2006 00:53:37 -0500 Received: by xproxy.gmail.com with SMTP id s9so52080wxc for ; Tue, 10 Jan 2006 21:46:31 -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=tvqz7oGVV5B17YB86ZEr8zMNx8BicArrN1XEtTcC3TuHHu7sKTLMd+uNphqXdNYF1Lelr3vCDr7uq1O0DtDY3eZ7KtW/fRwRUP6qvxzYkBf9BoQTw0kQc25MRAHjd2HJro/MpqbvXrSDwnNrAgZmIrHR1utRunh5XAt1Rn/bi1g= Received: by 10.70.62.19 with SMTP id k19mr449979wxa; Tue, 10 Jan 2006 21:46:31 -0800 (PST) Received: by 10.70.70.13 with HTTP; Tue, 10 Jan 2006 21:46:31 -0800 (PST) Message-ID: Date: Wed, 11 Jan 2006 11:16:31 +0530 From: Maneesh Chawla To: anjanhg@huawei.com Subject: Re: [Idr] Aggregation and dampening In-Reply-To: <000501c615dc$dcc2f330$5a04120a@china.huawei.com> MIME-Version: 1.0 References: <000501c615da$c82a5870$5a04120a@china.huawei.com> <000501c615dc$dcc2f330$5a04120a@china.huawei.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb 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: , Content-Type: multipart/mixed; boundary="===============1887269048==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --===============1887269048== Content-Type: multipart/alternative; boundary="----=_Part_33363_23169604.1136958391489" ------=_Part_33363_23169604.1136958391489 Content-Type: text/plain; charset=WINDOWS-1252 Content-Disposition: inline Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmVwbHkgQW5qYW4uCkkgYW0gc29ycnkgSSBmb3Jnb3QgdG8gbWVudGlv biB0aGF0IHdoZW4gSSBhZ2dyZWdhdGUgSSB1c2UgdGhlCiJzdW1tYXJ5LW9ubHkiIG9wdGlvbiBz byBpbiB0aGlzIGNhc2UgdGhlIGNvbnRyaWJ1dGluZyByb3V0ZXMgYXJlIGFscmVhZHkKc3VwcHJl c3NlZC4gTm93ICwgd2hhdCBzaG91bGQgaGFwcGVuIHdoZW4gZGFtcGVuaW5nIGlzIGNvbmZpZ3Vy ZWQgPwoKVGhhbmtzCk1hbmVlc2gKCk9uIDEvMTAvMDYsIEFuamFuIDxhbmphbmhnQGh1YXdlaS5j b20+IHdyb3RlOgo+Cj4gIFNvcnJ5LCBEYW1wZW5lZCByb3V0ZSBJIG1lYW4gaGVyZSBpcyB0aGUg J3JvdXRlIHRoYXQganVzdCBjYW1lIG91dCBvZgo+IERhbXBlbmVkIHN0YXRlJy4uCj4KPgo+Cj4K PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKPgo+ICAgICAgICAgICAgIFRoaXMgZS1t YWlsIGFuZCBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbgo+IGZy b20gSFVBV0VJLCB3aGljaCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0 eSB3aG9zZSBhZGRyZXNzCj4gaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkKPiAoaW5jbHVkaW5nLCBidXQgbm90IGxp bWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLAo+IG9y IGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50J3MpIGlzCj4gcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQo+IHBob25lIG9yIGVtYWlsIGltbWVkaWF0 ZWx5IGFuZCBkZWxldGUgaXQhCj4KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ICpGcm9t OiogaWRyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gKk9u IEJlaGFsZiBPZiAqCj4gQW5qYW4KPiAqU2VudDoqIFR1ZXNkYXksIEphbnVhcnkgMTAsIDIwMDYg NToxMSBQTQo+ICpUbzoqICdNYW5lZXNoIENoYXdsYSc7IGlkckBpZXRmLm9yZwo+ICpTdWJqZWN0 OiogUkU6IFtJZHJdIEFnZ3JlZ2F0aW9uIGFuZCBkYW1wZW5pbmcKPgo+Cj4KPiBIaSBNYW5lZXNo LAo+Cj4KPgo+IEkgZmVlbCBEYW1wZW5pbmcgc2hvdWxkIGJlIGNvbnNpZGVyZWQgaXJyZXNwZWN0 aXZlIG9mIHdoYXQgeW91IGFyZSBkb2luZwo+IGluIGFnZ3JlZ2F0aW9uLgo+Cj4gV2hlbiBkYW1w ZW5pbmcgaXMgY29uZmlndXJlZCwgcm91dGUgY2FuIHRha2UgdHdvIHZhbHVlcyBEYW1wZW5lZCBv cgo+IEhpc3RvcnkuCj4KPiBEYW1wZW5lZCByb3V0ZSBpcyB2YWxpZCB0byBhZHZlcnRpc2UuICBI aXN0b3J5IHJvdXRlIGlzIG5vdCB2YWxpZCB0bwo+IGFkdmVydGlzZS4KPgo+Cj4KPiBTbyB3aGV0 aGVyIHRoZSByb3V0ZSBjYW4gYmUgY29uc2lkZXJlZCBmb3IgYWdncmVnYXRpb24gb3Igbm90LCBk ZXBlbmRzIG9uCj4gdGhpcyBzdGF0ZSCWIGRhbXBlbmVkIG9yIGhpc3RvcnkuCj4KPgo+Cj4gV2l0 aCBzcGVjaWZpYyBhbnN3ZXIgdG8geW91ciBxdWVzdGlvbiwgSWYgdGhlIHJvdXRlIGlzIGluIERh bXBlbmVkIHN0YXRlCj4gaXQgc2hvdWxkIGNvbnRyaWJ1dGUgZm9yIEFnZ3JlZ2F0aW9uLgo+Cj4g SWYgaXQgaXMgaW4gSGlzdG9yeSBzdGF0ZSBpdCBzaG91bGQgbm90IGNvbnRyaWJ1dGUgZm9yIEFn Z3JlZ2F0aW9uLgo+Cj4KPgo+IEFueSBkaWZmZXJlbnQgb3BpbmlvbiBpbiB0aGUgZ3JvdXA/Cj4K Pgo+Cj4gUmVnYXJkcywKPgo+IEFuamFuCj4KPgo+Cj4KPgo+Cj4KPgo+ICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKgo+Cj4gICAgICAgICAgICAgVGhpcyBlLW1haWwgYW5kIGF0dGFjaG1l bnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uCj4gZnJvbSBIVUFXRUksIHdoaWNo IGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MK PiBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBo ZXJlaW4gaW4gYW55IHdheQo+IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwg b3IgcGFydGlhbCBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sCj4gb3IgZGlzc2VtaW5hdGlvbikg YnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQncykgaXMKPiBwcm9o aWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGJ5Cj4gcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBp dCEKPgo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gKkZyb206KiBpZHItYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpNYW5l ZXNoCj4gQ2hhd2xhCj4gKlNlbnQ6KiBUdWVzZGF5LCBKYW51YXJ5IDEwLCAyMDA2IDQ6MzIgUE0K PiAqVG86KiBpZHJAaWV0Zi5vcmcKPiAqU3ViamVjdDoqIFtJZHJdIEFnZ3JlZ2F0aW9uIGFuZCBk YW1wZW5pbmcKPgo+Cj4KPiBIaSBBbGwsCj4gICAgICAgICAgICBJIGhhdmUgYSBxdWVzdGlvbiBv biBhZ2dyZWdhdGlvbiBhbmQgZGFtcGVuaW5nLgo+Cj4gQ29uc2lkZXIgdGhlIHRvcG9sb2d5LAo+ Cj4gUjEtLS0tLVIzLS0tLS0tLVI0Cj4gICAgICAgICAgIHwKPiAgICAgICAgICAgfAo+IFIyLS0t LS0tfAo+Cj4KPiAxLiBSMSBhbmQgUjIgYXJlIGFkdmVydGlzaW5nIDY2LjAuMC4wLzMyIGFuZCA2 Ni4wLjAuMS8zMiB0byBSMwo+IHJlc3BlY3RpdmVseS4KPiAyLiBSMyBpcyBhZ2dyZWdhdGluZyB0 aGUgcm91dGVzICh3aXRoIHRoZSBhcy1zZXQgY29tbWFuZCApIGFuZCBhZHZlcnRpc2luZwo+IHRv IFI0LiBTaW5jZSBpdCBpcyB1c2luZyB0aGUgYXMtc2V0IG9wdGlvbiwgYWxsIHRoZSBwYXRoIGF0 dHJpYnV0ZXMgYXJlCj4gY29uc2lkZXJlZCBhbmQgaWYgb25lIG9mIHRoZSByb3V0ZXMgZmxhcCAs IHNheSB0aGUgcm91dGUgZnJvbSBSMiwgdGhlCj4gYWdncmVnYXRlIGZsYXAgdG8gUjQgd2lsbCBm bGFwLgo+IDMuIE5vdyAsIGNvbm5maWd1cmUgZGFtcGVuaW5nIGFsc28gb24gUjMuCj4KPiAgICAg ICAgIElzIGl0IHJpZ2h0IHRvIGV4cGVjdCB0aGF0IG5vdyB3aGVuIHRoZSByb3V0ZSBmcm9tIFIy IGZsYXBzLCBpdAo+IHNob3VsZCBiZSBkYW1wZWQgc28gYXMgdG8gbm90IGFmZmVjdCB0aGUgYWdn cmVnYXRlID8gVG8gcHV0IGl0IG1vcmUKPiBlbGFib3JhdGl2ZWx5ICwgc2F5ICB0aGUgcm91dGUg ZnJvbSBSMiBmbGFwcyBhbmQgcmVhY2hlcyBzdXByZXNzIHZhbHVlIGFuZAo+IGlzIHRoZXJlYnkg c3VwcHJlc3NlZCwgc2hvdWxkIGl0IHN0aWxsIGNvbnRyaWJ1dGUgdG8gdGhlIGFnZ3JlZ2F0ZSBv ciBzdG9wCj4gY29udHJpYnV0aW5nIHRvIHRoZSBhZ2dyZWdhdGUgPwo+ICAgICAgICAgSXMgdGhp cyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyA/Cj4KPiBUaGFua3MKPiBNYW5lZXNoCj4KPiBwLnMg OiBTb3JyeSAsIGlmIGl0IGlzIGEgdmVyeSBiYXNpYyBxdWVzdGlvbiBpbiB0aGlzIGZvcnVtLgo+ Cj4K ------=_Part_33363_23169604.1136958391489 Content-Type: text/html; charset=WINDOWS-1252 Content-Disposition: inline Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmVwbHkgQW5qYW4uPGJyPkkgYW0gc29ycnkgSSBmb3Jnb3QgdG8gbWVu dGlvbiB0aGF0IHdoZW4gSSBhZ2dyZWdhdGUgSSB1c2UgdGhlICZxdW90O3N1bW1hcnktb25seSZx dW90OyBvcHRpb24gc28gaW4gdGhpcyBjYXNlIHRoZSBjb250cmlidXRpbmcgcm91dGVzIGFyZSBh bHJlYWR5IHN1cHByZXNzZWQuIE5vdyAsIHdoYXQgc2hvdWxkIGhhcHBlbiB3aGVuIGRhbXBlbmlu ZyBpcyBjb25maWd1cmVkID8KPGJyPjxicj5UaGFua3M8YnI+TWFuZWVzaDxicj48YnI+PGRpdj48 c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDEvMTAvMDYsIDxiIGNsYXNzPSJnbWFpbF9zZW5k ZXJuYW1lIj5BbmphbjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmphbmhnQGh1YXdlaS5jb20i PmFuamFuaGdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIw NCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4K CgoKCgoKCgoKCgoKCgo8ZGl2PgoKPHA+PGZvbnQgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIiBz aXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWw7 IGNvbG9yOiBuYXZ5OyI+U29ycnksIERhbXBlbmVkIHJvdXRlIEkgbWVhbiBoZXJlIGlzIHRoZSAn cm91dGUKdGhhdCBqdXN0IGNhbWUgb3V0IG9mIERhbXBlbmVkIHN0YXRlJy4uPC9zcGFuPjwvZm9u dD48L3A+PHNwYW4gY2xhc3M9InEiPgoKPHA+PGZvbnQgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFs IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJp YWw7IGNvbG9yOiBuYXZ5OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8ZGl2PgoKPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0OiAyN3B0OyB0ZXh0LWluZGVudDogLTI3cHQ7IGxpbmUtaGVpZ2h0OiAx MnB0OyI+PGZvbnQgY29sb3I9ImJsYWNrIiBmYWNlPSJBcmlhbCIgc2l6ZT0iMSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogOHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBibGFjazsiPioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKgo8L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0eWxl PSJtYXJnaW4tbGVmdDogMjdwdDsgdGV4dC1pbmRlbnQ6IC0yN3B0OyBsaW5lLWhlaWdodDogMTJw dDsiPjxmb250IGNvbG9yPSJibGFjayIgZmFjZT0iQXJpYWwiIHNpemU9IjEiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDhwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogYmxhY2s7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhpcwplLW1haWwgYW5kIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGlu Zm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCBpcwppbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVy c29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZQpvZiB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1 dCBub3QgbGltaXRlZCB0bywKdG90YWwgb3IgcGFydGlhbCBkaXNjbG9zdXJlLCByZXByb2R1Y3Rp b24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIKdGhhbiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50J3MpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGlu CmVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRp YXRlbHkgYW5kIGRlbGV0ZSBpdCE8L3NwYW4+PC9mb250PjwvcD4KCjwvZGl2PgoKPC9zcGFuPjxk aXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzEwOGI0NTJiMDBhYTUxYmRfMiI+PHAgc3R5bGU9Im1h cmdpbi1sZWZ0OiAwLjVpbjsiPjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYTsiPi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPgo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5Gcm9t Ojwvc3Bhbj48L2I+IDxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50 LHRoaXMpIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT4KW21haWx0bzo8YSBocmVmPSJtYWlsdG86 aWRyLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9w LmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSA8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5PbiBCZWhhbGYgT2YgPC9z cGFuPjwvYj5Bbmphbjxicj4KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+U2Vu dDo8L3NwYW4+PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDEwLCAyMDA2CjU6MTEgUE08YnI+CjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPlRvOjwvc3Bhbj48L2I+ICc8L3NwYW4+PC9m b250Pjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYTsiPk1hbmVlc2ggQ2hhd2xhPC9zcGFuPjwvZm9udD48 Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBUYWhvbWE7Ij4KJzsgPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUYWhv bWEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBU YWhvbWE7Ij48YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgb25j bGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmlkckBp ZXRmLm9yZzwvYT48L3NwYW4+CjwvZm9udD48Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWE7Ij48YnI+Cjxi PjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6 IFtJZHJdIEFnZ3JlZ2F0aW9uIGFuZApkYW1wZW5pbmc8L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNp emU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250 PjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2eSIg ZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij5IaSBNYW5lZXNoLDwvc3Bhbj48L2ZvbnQ+PC9w PgoKPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OiAwLjVpbjsiPjxmb250IGNvbG9yPSJuYXZ5IiBmYWNl PSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0OiAwLjVpbjsiPjxmb250IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIg c2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFs OyBjb2xvcjogbmF2eTsiPkkgZmVlbCBEYW1wZW5pbmcgc2hvdWxkCmJlIGNvbnNpZGVyZWQgaXJy ZXNwZWN0aXZlIG9mIHdoYXQgeW91IGFyZSBkb2luZyBpbiBhZ2dyZWdhdGlvbi48L3NwYW4+PC9m b250PjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2 eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij5XaGVuIGRhbXBlbmluZyBpcwpjb25maWd1 cmVkLCByb3V0ZSBjYW4gdGFrZSB0d28gdmFsdWVzIERhbXBlbmVkIG9yIEhpc3RvcnkuPC9zcGFu PjwvZm9udD48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDAuNWluOyI+PGZvbnQgY29sb3I9 Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+RGFtcGVuZWQgcm91dGUgaXMgdmFs aWQKdG8gYWR2ZXJ0aXNlLiZuYnNwOyBIaXN0b3J5IHJvdXRlIGlzIG5vdCB2YWxpZCB0byBhZHZl cnRpc2UuPC9zcGFuPjwvZm9udD48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDAuNWluOyI+ PGZvbnQgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+Jm5ic3A7PC9z cGFuPjwvZm9udD48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDAuNWluOyI+PGZvbnQgY29s b3I9Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+U28gd2hldGhlciB0aGUgcm91 dGUgY2FuCmJlIGNvbnNpZGVyZWQgZm9yIGFnZ3JlZ2F0aW9uIG9yIG5vdCwgZGVwZW5kcyBvbiB0 aGlzIHN0YXRlIJYgZGFtcGVuZWQgb3IKaGlzdG9yeS48L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwi IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlh bDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0eWxlPSJtYXJn aW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6 IG5hdnk7Ij5XaXRoIHNwZWNpZmljIGFuc3dlciB0bwp5b3VyIHF1ZXN0aW9uLCBJZiB0aGUgcm91 dGUgaXMgaW4gRGFtcGVuZWQgc3RhdGUgaXQgc2hvdWxkIGNvbnRyaWJ1dGUgZm9yCkFnZ3JlZ2F0 aW9uLjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OiAwLjVpbjsiPjxm b250IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPklmIGl0IGlzIGlu IEhpc3Rvcnkgc3RhdGUKaXQgc2hvdWxkIG5vdCBjb250cmlidXRlIGZvciBBZ2dyZWdhdGlvbi48 L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBj b2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9m b250PjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2 eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij5BbnkgZGlmZmVyZW50IG9waW5pb24gaW4K dGhlIGdyb3VwPzwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OiAwLjVp bjsiPjxmb250IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OiAwLjVpbjsiPjxmb250 IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPlJlZ2FyZHMsPC9zcGFu PjwvZm9udD48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDAuNWluOyI+PGZvbnQgY29sb3I9 Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+QW5qYW48L3NwYW4+PC9mb250Pjwv cD4KCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2eSIgZmFj ZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwi IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlh bDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0eWxlPSJtYXJn aW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6 IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxkaXY+Cgo8cCBzdHlsZT0ibWFyZ2lu LWxlZnQ6IDYzcHQ7IHRleHQtaW5kZW50OiAtMjdwdDsgbGluZS1oZWlnaHQ6IDEycHQ7Ij48Zm9u dCBjb2xvcj0iYmxhY2siIGZhY2U9IkFyaWFsIiBzaXplPSIxIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiA4cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IGJsYWNrOyI+KioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqCjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1s ZWZ0OiA2M3B0OyB0ZXh0LWluZGVudDogLTI3cHQ7IGxpbmUtaGVpZ2h0OiAxMnB0OyI+PGZvbnQg Y29sb3I9ImJsYWNrIiBmYWNlPSJBcmlhbCIgc2l6ZT0iMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBibGFjazsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwpUaGlz IGUtbWFpbCBhbmQgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24g ZnJvbSBIVUFXRUksIHdoaWNoCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50 aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkKdXNlIG9mIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1p dGVkCnRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlz c2VtaW5hdGlvbikgYnkgcGVyc29ucwpvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQn cykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwKaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSBwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQg ZGVsZXRlIGl0ITwvc3Bhbj48L2ZvbnQ+PC9wPgoKPC9kaXY+Cgo8cCBzdHlsZT0ibWFyZ2luLWxl ZnQ6IDFpbjsiPjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYTsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPgo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5Gcm9tOjwvc3Bhbj48 L2I+IDxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi IG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5p ZHItYm91bmNlc0BpZXRmLm9yZzwvYT4KW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5F eHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj48 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvYj5N YW5lZXNoCkNoYXdsYTxicj4KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+U2Vu dDo8L3NwYW4+PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDEwLCAyMDA2CjQ6MzIgUE08YnI+CjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPlRvOjwvc3Bhbj48L2I+IDxhIGhyZWY9Im1h aWx0bzppZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpz Lk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aWRyQGlldGYub3JnPC9hPjxicj4KPGI+ PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+U3ViamVjdDo8L3NwYW4+PC9iPiBbSWRy XSBBZ2dyZWdhdGlvbiBhbmQKZGFtcGVuaW5nPC9zcGFuPjwvZm9udD48L3A+Cgo8cCBzdHlsZT0i bWFyZ2luLWxlZnQ6IDFpbjsiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgoK PHAgc3R5bGU9Im1hcmdpbi1sZWZ0OiAxaW47Ij48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij5IaSBBbGwsPGJyPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg SSBoYXZlIGEgcXVlc3Rpb24Kb24gYWdncmVnYXRpb24gYW5kIGRhbXBlbmluZy48YnI+Cjxicj4K Q29uc2lkZXIgdGhlIHRvcG9sb2d5LDxicj4KPGJyPgpSMS0tLS0tUjMtLS0tLS0tUjQ8YnI+CiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PGJy PgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fDxicj4KUjItLS0tLS18PGJyPgo8YnI+Cjxicj4KMS4gUjEgYW5kIFIyIGFyZSBhZHZlcnRpc2lu ZyA8YSBocmVmPSJodHRwOi8vNjYuMC4wLjAvMzIiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJy ZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+NjYuMC4wLjAvMzI8 L2E+IGFuZCA8YSBocmVmPSJodHRwOi8vNjYuMC4wLjEvMzIiIHRhcmdldD0iX2JsYW5rIiBvbmNs aWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+CjY2LjAu MC4xLzMyPC9hPiB0byBSMyByZXNwZWN0aXZlbHkuPGJyPgoyLiBSMyBpcyBhZ2dyZWdhdGluZyB0 aGUgcm91dGVzICh3aXRoIHRoZSBhcy1zZXQgY29tbWFuZCApIGFuZCBhZHZlcnRpc2luZyB0bwpS NC4gU2luY2UgaXQgaXMgdXNpbmcgdGhlIGFzLXNldCBvcHRpb24sIGFsbCB0aGUgcGF0aCBhdHRy aWJ1dGVzIGFyZSBjb25zaWRlcmVkCmFuZCBpZiBvbmUgb2YgdGhlIHJvdXRlcyBmbGFwICwgc2F5 IHRoZSByb3V0ZSBmcm9tIFIyLCB0aGUgYWdncmVnYXRlIGZsYXAgdG8gUjQKd2lsbCBmbGFwLiA8 YnI+CjMuIE5vdyAsIGNvbm5maWd1cmUgZGFtcGVuaW5nIGFsc28gb24gUjMuIDxicj4KJm5ic3A7 Jm5ic3A7IDxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElz IGl0IHJpZ2h0IHRvIGV4cGVjdCB0aGF0IG5vdyB3aGVuCnRoZSByb3V0ZSBmcm9tIFIyIGZsYXBz LCBpdCBzaG91bGQgYmUgZGFtcGVkIHNvIGFzIHRvIG5vdCBhZmZlY3QgdGhlIGFnZ3JlZ2F0ZQo/ IFRvIHB1dCBpdCBtb3JlIGVsYWJvcmF0aXZlbHkgLCBzYXkmbmJzcDsgdGhlIHJvdXRlIGZyb20g UjIgZmxhcHMgYW5kIHJlYWNoZXMKc3VwcmVzcyB2YWx1ZSBhbmQgaXMgdGhlcmVieSBzdXBwcmVz c2VkLCBzaG91bGQgaXQgc3RpbGwgY29udHJpYnV0ZSB0byB0aGUKYWdncmVnYXRlIG9yIHN0b3Ag Y29udHJpYnV0aW5nIHRvIHRoZSBhZ2dyZWdhdGUgPyA8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJcyB0aGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljID88 YnI+Cjxicj4KVGhhbmtzPGJyPgpNYW5lZXNoPGJyPgo8YnI+CnAucyA6IFNvcnJ5ICwgaWYgaXQg aXMgYSB2ZXJ5IGJhc2ljIHF1ZXN0aW9uIGluIHRoaXMgZm9ydW0uPGJyPgombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvZm9udD48 L3A+Cgo8L3NwYW4+PC9kaXY+PC9kaXY+CgoKCgoKPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K ------=_Part_33363_23169604.1136958391489-- --===============1887269048== 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 --===============1887269048==-- From idr-bounces@ietf.org Wed Jan 11 00:52:19 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 1EwYuB-0006pv-Ak; Wed, 11 Jan 2006 00:52:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwYuA-0006pp-3y for idr@megatron.ietf.org; Wed, 11 Jan 2006 00:52:18 -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 AAA15526 for ; Wed, 11 Jan 2006 00:50:58 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwZ0z-0007RQ-Iy for idr@ietf.org; Wed, 11 Jan 2006 00:59:23 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0B5q0YG024531; Wed, 11 Jan 2006 07:52:00 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0B5pxFm024528; Wed, 11 Jan 2006 07:51:59 +0200 Date: Wed, 11 Jan 2006 07:51:59 +0200 (EET) From: Pekka Savola To: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT In-Reply-To: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Message-ID: References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1237/Tue Jan 10 17:53:20 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Inter-Domain Routing List 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 On Tue, 10 Jan 2006, Tony Li wrote: > - Convert AS_HOPCOUNT from being decremented at each AS boundary and instead > have it > be a static upper bound on the AS path length. > > - Rename the attribute to AS_PATHLIMIT. > > - Completely remove the interaction with NO_EXPORT. I think this is exactly the direction to follow. This lessens my concerns of this attribute considerably. The simpler, the better. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 08:26:00 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 1EwfzE-0008Pa-A0; Wed, 11 Jan 2006 08:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfzD-0008PL-4v for idr@megatron.ietf.org; Wed, 11 Jan 2006 08:25: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 IAA11815 for ; Wed, 11 Jan 2006 08:24:38 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewg65-0002jB-Vv for idr@ietf.org; Wed, 11 Jan 2006 08:33:07 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2006 05:25:47 -0800 X-IronPort-AV: i="3.99,355,1131350400"; d="scan'208"; a="248352561:sNHT30981970" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0BDPlc1016575 for ; Wed, 11 Jan 2006 05:25:47 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 08:25:47 -0500 Received: from [64.100.131.122] ([64.100.131.122]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 08:25:46 -0500 In-Reply-To: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4163a865ee13bc4646a47ae2f228ec97@cisco.com> Content-Transfer-Encoding: 7bit From: Dana Blair Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 08:25:45 -0500 To: Inter-Domain Routing List X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 11 Jan 2006 13:25:46.0988 (UTC) FILETIME=[8817AAC0:01C616B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 On Jan 10, 2006, at 3:35 PM, Tony Li wrote: > > Hi folks, > > Based on the discussion that we've had so far, the authors of the > AS_HOPCOUNT draft would > like to make some substantive changes to the draft. The chairs have > asked that we poll you to > ensure that we have rough consensus on the new direction. The primary > technical points of > these changes: > > - Convert AS_HOPCOUNT from being decremented at each AS boundary and > instead have it > be a static upper bound on the AS path length. This is necessary for partial deployment. > > - Rename the attribute to AS_PATHLIMIT. I don't have an opinion on renaming as long as the draft moves forward. > > - Completely remove the interaction with NO_EXPORT. I'm not expert enough (yet) to have an opinion on NO_EXPORT. Dana > > There are, of course, a number of details more fully explained in the > revised draft, but before we > are allowed to present you with the revision, we need to have your > approval on the above. > > Could folks please comment to the list within the next two weeks as to > whether or not this direction > is acceptable? As this is to help gauge consensus, both positive and > negative comments are > solicited. > > Regards, > Joe & Rex & 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 Jan 11 10:33:37 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 1Ewhyj-0006do-63; Wed, 11 Jan 2006 10:33:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewhyh-0006dj-3h for idr@megatron.ietf.org; Wed, 11 Jan 2006 10:33:35 -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 KAA20449 for ; Wed, 11 Jan 2006 10:32:13 -0500 (EST) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewi5Y-0006UZ-Nm for idr@ietf.org; Wed, 11 Jan 2006 10:40:44 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id F2FFF1C44; Wed, 11 Jan 2006 15:33:07 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 268kakPhg0204Mo2; Wed, 11 Jan 2006 15:33:06 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 265kakPhe0266Mo2; Wed, 11 Jan 2006 15:33:04 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Wed, 11 Jan 2006 15:33:04 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID492kakPhe4616Xo2 Received: from localhost ([65.247.36.31]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 08:33:04 -0700 Date: Wed, 11 Jan 2006 10:33:03 -0500 From: Jeffrey Haas To: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Message-ID: <20060111153303.GB22020@nexthop.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <20060110223708.GB12691@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 11 Jan 2006 15:33:04.0407 (UTC) FILETIME=[50595270:01C616C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Inter-Domain Routing List 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, On Tue, Jan 10, 2006 at 03:00:08PM -0800, Tony Li wrote: > This was exactly why we were shifting to a static value and way from > decrement. I don't have a strong enough opinion on wanting the decrement to warrant a serious objection, just a preference. I think I'll buy into your argument that the fewer routers that have to worry about actually changing the attribute, the better. I withdraw my previous support for using decrement. I would definitely like to see more language about how we do the counting. Absolute path length seems to be the wrong choice. I think that Russ's verbiage about distinct ASes is close. I'd suggest that we count any recurring adjacent sequences of an AS in one or more AS_SEQUENCEs as length 1 and simply count an entire AS_SET, regardless of content, as length 1. Ergo: 1 1 1 2 3 3 2 [5 6 7] would count as length 5. Yes, there's an intentional loop in there. > >The 4 byte AS number in the attribute is probably a good idea. > >However, we should carefully explain the behavior when the 4 byte > >AS must be utilized by a 2byte speaker. > > The draft references the encoding rules used in the 4 octet draft. This is somewhat problematic when dealing with a 2 byte speaker with AS_TRANS in the AS_PATH. Without peeking into the NEW_AS_PATH, you can't tell if multiple occurrences are distinct ASes or not. This affects how I'd expect path length counting to occur. Of course, if you're counting absolute path length, that changes things. (I'm really hoping you're not counting absolute path length.) > You'll pardon me if my paranoia regarding deaggregation hasn't abated in > the last 15 years. ;-) If you feel additional text is warranted, > contributions are most welcome. Let's just say I share your paranoia. However, the current BGP RFC-to-be doesn't use that particular verbiage and this leaves this document out of "harmony". I say this mostly because no one seems to implement ATOMIC_AGGREGATE in the way that suggested in 1771. Additionally, per some e-mail chains a few years ago, adding ATOMIC_AGGREGATE on an outbound-only basis isn't sufficient. Safest to just pretend we don't deaggregate since it leads to madness. > Tony -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 10:52:14 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 1EwiGk-0003X4-Jw; Wed, 11 Jan 2006 10:52:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiGj-0003Ww-0Q for idr@megatron.ietf.org; Wed, 11 Jan 2006 10:52:13 -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 KAA21585 for ; Wed, 11 Jan 2006 10:50:53 -0500 (EST) From: sandy@tislabs.com Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwiNX-0006zT-FM for idr@ietf.org; Wed, 11 Jan 2006 10:59:23 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0BFpVUv026728 for ; Wed, 11 Jan 2006 10:51:31 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA83aGWZ; Wed, 11 Jan 06 10:50:27 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0BFqlit023843; Wed, 11 Jan 2006 10:52:47 -0500 (EST) Date: Wed, 11 Jan 2006 10:52:47 -0500 (EST) Message-Id: <200601111552.k0BFqlit023843@tislabs.com> To: jhaas@nexthop.com, tony.li@tony.li Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Another aspect of decrementing hop count vs "absolute" path length. If one uses a decrementing hop count and there is a security mechanism in place that tries provides protections that would allow ASes many hops away to verify the integrity of what you sent (i.e., the portion of what they receive that is what you sent), then the hop count would have to be excluded from that protection. It would be legitimately changing, so you could not protect its integrity. That probably would leave open opportunities for bad/stupid/broken guys to modify the field inappropriately, with ill effect. (Like the TTL field in IP is not covered by IPSEC because it changes at each hop.) If one had an static absolute path length, its integrity could be protected over many hops. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 11:33:38 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 1Ewiuo-0001Ya-7d; Wed, 11 Jan 2006 11:33:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewium-0001YU-Fa for idr@megatron.ietf.org; Wed, 11 Jan 2006 11:33:36 -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 LAA24642 for ; Wed, 11 Jan 2006 11:32:16 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewj1g-0008JB-Q2 for idr@ietf.org; Wed, 11 Jan 2006 11:40:47 -0500 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EwiuT-0007qB-5k; Wed, 11 Jan 2006 16:33:17 +0000 In-Reply-To: <200601111552.k0BFqlit023843@tislabs.com> References: <200601111552.k0BFqlit023843@tislabs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 11:33:16 -0500 To: sandy@tislabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, tony.li@tony.li 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 On 11-Jan-2006, at 10:52, sandy@tislabs.com wrote: > That probably would leave open opportunities for bad/stupid/broken > guys to modify the field inappropriately, with ill effect. The other main mechanism which restricts route propagation (the NO_EXPORT community string attribute) is trivial to strip from routes, overriding the intentions of the previous AS in the path. In general, surely every AS has a legitimate case for modifying the attributes on prefixes to suit its own needs. What kind of modification would you consider inappropriate? > If one had an static absolute path length, its integrity could be > protected over many hops. I would expect any AS to be able to remove an AS_PATHLIMIT attribute if that suited their local policy, substituting a new one if desired. In that context, I'm not sure what integrity there is to preserve? Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 11:40:41 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 1Ewj1d-0002Ef-O9; Wed, 11 Jan 2006 11:40:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewj1c-0002Ea-0i for idr@megatron.ietf.org; Wed, 11 Jan 2006 11:40:40 -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 LAA25041 for ; Wed, 11 Jan 2006 11:39:19 -0500 (EST) Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewj8W-0008W2-Sx for idr@ietf.org; Wed, 11 Jan 2006 11:47:50 -0500 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id 87DF815E3; Wed, 11 Jan 2006 16:40:15 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 508kakqOm0364Mo1; Wed, 11 Jan 2006 16:40:13 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 505kakqOL0308Mo1; Wed, 11 Jan 2006 16:40:11 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.27I); Wed, 11 Jan 2006 16:40:11 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID241kakqOL1751Xo1 Received: from localhost ([65.247.36.31]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 09:40:11 -0700 Date: Wed, 11 Jan 2006 11:40:10 -0500 From: Jeffrey Haas To: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Message-ID: <20060111164010.GE22020@nexthop.com> References: <200601111552.k0BFqlit023843@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 11 Jan 2006 16:40:11.0130 (UTC) FILETIME=[B0767DA0:01C616CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: idr@ietf.org, tony.li@tony.li, sandy@tislabs.com 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 On Wed, Jan 11, 2006 at 11:33:16AM -0500, Joe Abley wrote: > The other main mechanism which restricts route propagation (the > NO_EXPORT community string attribute) is trivial to strip from > routes, overriding the intentions of the previous AS in the path. In > general, surely every AS has a legitimate case for modifying the > attributes on prefixes to suit its own needs. Some might argue the appropriateness of stripping the current well known communities as potential security issues. At best, you're outright ignoring your peer's requirements to not propagate things. However, rpsec might be a better place for this particular operational discussion. > I would expect any AS to be able to remove an AS_PATHLIMIT attribute > if that suited their local policy, substituting a new one if desired. > In that context, I'm not sure what integrity there is to preserve? One component would simply be ensuring that someone doesn't put someone else's AS number in the hoplimit field. The mechanism by which your ensure that integrity is probably better discussed in rpsec. (However, I'll agree with Sandy that this makes things "easier" for some of the things we've discussed on rpsec.) The behavior of mis-setting values in this field are already discussed with Tony's usual wit in the security considerations of the draft. :-) -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 12:04:58 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 1EwjP8-00020m-Bt; Wed, 11 Jan 2006 12:04:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwjP6-00020a-V0 for idr@megatron.ietf.org; Wed, 11 Jan 2006 12:04:57 -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 MAA26930 for ; Wed, 11 Jan 2006 12:03:36 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwjW2-0000ww-Gk for idr@ietf.org; Wed, 11 Jan 2006 12:12:07 -0500 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EwjOw-0007z5-40; Wed, 11 Jan 2006 17:04:46 +0000 In-Reply-To: <20060111164010.GE22020@nexthop.com> References: <200601111552.k0BFqlit023843@tislabs.com> <20060111164010.GE22020@nexthop.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 12:04:45 -0500 To: Jeffrey Haas X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Tony Li , sandy@tislabs.com 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 On 11-Jan-2006, at 11:40, Jeffrey Haas wrote: > On Wed, Jan 11, 2006 at 11:33:16AM -0500, Joe Abley wrote: >> The other main mechanism which restricts route propagation (the >> NO_EXPORT community string attribute) is trivial to strip from >> routes, overriding the intentions of the previous AS in the path. In >> general, surely every AS has a legitimate case for modifying the >> attributes on prefixes to suit its own needs. > > Some might argue the appropriateness of stripping the current > well known communities as potential security issues. True; however, many operators might also argue that their ability to impose their own policy on the routes they choose to accept and propagate is more important. > At best, you're > outright ignoring your peer's requirements to not propagate things. Perhaps it's more realistic to call them "requests" rather then "requirements". > However, rpsec might be a better place for this particular operational > discussion. Agreed; apologies for the tangent. Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 12:26:53 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 1EwjkL-0003y5-1O; Wed, 11 Jan 2006 12:26:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwjkJ-0003xs-Ro for idr@megatron.ietf.org; Wed, 11 Jan 2006 12:26:51 -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 MAA28581 for ; Wed, 11 Jan 2006 12:25:31 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwjrF-0001d9-P4 for idr@ietf.org; Wed, 11 Jan 2006 12:34:03 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id DF61F642D4 for ; Wed, 11 Jan 2006 10:26:29 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <200601111552.k0BFqlit023843@tislabs.com> <20060111164010.GE22020@nexthop.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <196D7592-5E31-4481-A596-B6D717F02A52@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 10:26:44 -0700 To: Inter-Domain Routing List X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit 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 On Jan 11, 2006, at 10:04 AM, Joe Abley wrote: > > True; however, many operators might also argue that their ability > to impose their own policy on the routes they choose to accept and > propagate is more important. Absolutely. I suspect many operators (I know of several first hand) that reset all community values received from eBGP peers and MAY reapply well- known communities on ingress, but avoid carrying any additional communities that have no meaning within their routing domain (e.g., to avoid effects on update packing, etc..). -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 12:56:58 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 1EwkDR-000347-V8; Wed, 11 Jan 2006 12:56:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwkDQ-00033n-UZ for idr@megatron.ietf.org; Wed, 11 Jan 2006 12:56:56 -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 MAA00536 for ; Wed, 11 Jan 2006 12:55:36 -0500 (EST) From: sandy@tislabs.com Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwkKM-0002Wn-Ns for idr@ietf.org; Wed, 11 Jan 2006 13:04:08 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0BHuPu1017215 for ; Wed, 11 Jan 2006 12:56:25 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAaja44G; Wed, 11 Jan 06 12:53:29 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0BHtv58029071; Wed, 11 Jan 2006 12:55:57 -0500 (EST) Date: Wed, 11 Jan 2006 12:55:57 -0500 (EST) Message-Id: <200601111755.k0BHtv58029071@tislabs.com> To: idr@ietf.org Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sandy@tislabs.com 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 >The other main mechanism which restricts route propagation (the >NO_EXPORT community string attribute) is trivial to strip from >routes, overriding the intentions of the previous AS in the path. In >general, surely every AS has a legitimate case for modifying the >attributes on prefixes to suit its own needs. As I understand it, the NO_EXPORT attribute is intended just for your immediate neighbor, and is not supposed to be propagated elsewhere. There's this "MUST NOT be advertised" in the spec. Security mechanisms typically try to ensure that behavior matches the spec or assumptions in the specs. So the trivial strippability (and subsequent propagation) would be a security vulnerability. >What kind of modification would you consider inappropriate? Oh, you know, any modification in violation of what the spec says should be done. Like changing the value from 3 to 15 (in the static upper bound case) or incrementing the value by 6 instead of decrementing by 1 (in the decremented case). It is tough to operate a distributed system when you are putting values in packets that are supposed to elicit certain behaviors in all recipients and some recipients break the rules and do something else entirely. >I would expect any AS to be able to remove an AS_PATHLIMIT attribute >if that suited their local policy, substituting a new one if desired. AS_PATHLIMIT is a value that is supposed to affect ASes some distance away and prevent propagation of information past a certain point. Saying in the spec "but other ASes are free to do anything they want to this field" seems to me to limit its usefulness. It would make "the control that we hope to achieve" (to quote the i-d) a rather undeterministic sort of control. Why bother with a "oh, who knows, this might have some effect someplaces, then again, maybe not" specification for what the field means? Or maybe you intend the field to be advice rather than prescription? If you would rather have a more deterministic semantics for the field, then you probably would want some integrity protection for the value. If you want to permit a "maybe, maybe not" semantics to the field, then you don't need the integrity. If you set a AS_PATHLIMIT of 4 and the AS four hops away strips that and adds a AS_PATHLIMIT of 15, would that be OK? You write into the spec whether that would be OK, and the security protections try to make the decision enforceable. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 13:45:49 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 1Ewkyi-0008NV-Up; Wed, 11 Jan 2006 13:45:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewkyh-0008NO-AA for idr@megatron.ietf.org; Wed, 11 Jan 2006 13:45:47 -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 NAA02889 for ; Wed, 11 Jan 2006 13:44:26 -0500 (EST) From: sandy@tislabs.com Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewl5e-0003i3-Ud for idr@ietf.org; Wed, 11 Jan 2006 13:52:59 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0BIjJxG026646 for ; Wed, 11 Jan 2006 13:45:19 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAWpaq5Z; Wed, 11 Jan 06 13:44:58 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0BIRhbf000350; Wed, 11 Jan 2006 13:27:43 -0500 (EST) Date: Wed, 11 Jan 2006 13:27:43 -0500 (EST) Message-Id: <200601111827.k0BIRhbf000350@tislabs.com> To: idr@ietf.org Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sandy@tislabs.com 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 >The mechanism >by which your ensure that integrity is probably better discussed in >rpsec. RRPSEC might be the place the discuss the integrity mechanism, but making a choice between a static PATHLIMIT and a decrementing HOPCOUNT is better made here. Adding a snipit of thought to security consequences to the choice is, to me, appropriate here. And, of course, there's the question of what integrity means here. If you really want the field completely mutable by other ASes, then the definition of "integrity" is rather broad. >The behavior of mis-setting values in this field are already >discussed with Tony's usual wit in the security considerations of >the draft. :-) W-e-e-l-l. Tony says that those routers who attach this attribute could have used "normal policy mechanisms" to filter out the route. But I thought the whole point was that normal policy mechanisms did not provide the control desired. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 14:33: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 1EwliP-0005F2-Pz; Wed, 11 Jan 2006 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwliN-0005Es-Sb for idr@megatron.ietf.org; Wed, 11 Jan 2006 14:32: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 OAA05515 for ; Wed, 11 Jan 2006 14:31:39 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwlpK-0004yI-Lx for idr@ietf.org; Wed, 11 Jan 2006 14:40:12 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 7821E642D4 for ; Wed, 11 Jan 2006 12:32:31 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601111755.k0BHtv58029071@tislabs.com> References: <200601111755.k0BHtv58029071@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 12:32:45 -0700 To: Inter-Domain List Routing X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit 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 On Jan 11, 2006, at 10:55 AM, sandy@tislabs.com wrote: >> The other main mechanism which restricts route propagation (the >> NO_EXPORT community string attribute) is trivial to strip from >> routes, overriding the intentions of the previous AS in the path. In >> general, surely every AS has a legitimate case for modifying the >> attributes on prefixes to suit its own needs. > > As I understand it, the NO_EXPORT attribute is intended just > for your immediate neighbor, and is not supposed to be propagated > elsewhere. That'd be NO_ADVERTISE. > There's this "MUST NOT be advertised" in the spec. In reality, NO_EXPORT in practice is employed to convey to AN ADJACENT AS that the route should not be advertised to BGP peers outside of that AS (i.e., eBGP peers). > Security mechanisms typically try to ensure that behavior matches > the spec or assumptions in the specs. So the trivial strippability > (and subsequent propagation) would be a security vulnerability. In this case, deployability is dictated by each operators policy independently. I.e., you desire for this to be the intended function and hope your peers respect that behavior. However, if your peer disagrees with you about how they should operate their network (e.g., not accepting MEDs, modifying paths, stripping communities) then their not having the capability to enforce their own policies would be a security vulnerability. Fortunately, most folks realize this and leave it as a matter of implementation support and each network operators policies. > Oh, you know, any modification in violation of what the spec says > should be done. Like changing the value from 3 to 15 (in the static > upper bound case) or incrementing the value by 6 instead of > decrementing by 1 (in the decremented case). > > It is tough to operate a distributed system when you are putting > values in packets that are supposed to elicit certain behaviors > in all recipients and some recipients break the rules and do > something else entirely. This distributed system is enabled and controlled by the folks operating the networks, not providing those folks with the capabilities to implement what policies they see fit for their environment (i.e., rather than allowing their peers/competitors to manipulate their network policies) is, well, not an option. This is no different than any other attribute. For example, if an upstream chooses not to announce a route, well, there's little we can do about that. > >> I would expect any AS to be able to remove an AS_PATHLIMIT attribute >> if that suited their local policy, substituting a new one if desired. > > AS_PATHLIMIT is a value that is supposed to affect ASes some distance > away and prevent propagation of information past a certain point. > Saying in the spec "but other ASes are free to do anything they want > to this field" seems to me to limit its usefulness. It would make > "the control that we hope to achieve" (to quote the i-d) a rather > undeterministic sort of control. Why bother with a "oh, who knows, > this might have some effect someplaces, then again, maybe not" > specification for what the field means? > > Or maybe you intend the field to be advice rather than prescription? > If you would rather have a more deterministic semantics for > the field, then you probably would want some integrity protection > for the value. > > If you want to permit a "maybe, maybe not" semantics to the field, > then you don't need the integrity. > > If you set a AS_PATHLIMIT of 4 and the AS four hops away strips that > and adds a AS_PATHLIMIT of 15, would that be OK? Sure, why not? If I'm the 4th AS and have reason to do so? I own my network resources? -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 14:52:07 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 1Ewm0t-0001qj-Ny; Wed, 11 Jan 2006 14:52:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewm0r-0001qe-Iw for idr@megatron.ietf.org; Wed, 11 Jan 2006 14:52:05 -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 OAA07242 for ; Wed, 11 Jan 2006 14:50:44 -0500 (EST) Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewm7m-0005Vc-2s for idr@ietf.org; Wed, 11 Jan 2006 14:59:17 -0500 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id BD5BA1C86; Wed, 11 Jan 2006 19:51:38 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 969kakTzK0149Mo1; Wed, 11 Jan 2006 19:51:37 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 966kakTzj0149Mo1; Wed, 11 Jan 2006 19:51:35 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.27I); Wed, 11 Jan 2006 19:51:35 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com gw3.EXCHPROD.USA.NET X-USANET-MsgId: XID433kakTzj1998Xo1 Received: from localhost ([65.247.36.31]) by gw3.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 12:51:35 -0700 Date: Wed, 11 Jan 2006 14:51:34 -0500 From: Jeffrey Haas To: Danny McPherson Subject: Re: [Idr] Next revision of AS_HOPCOUNT Message-ID: <20060111195133.GF22020@nexthop.com> References: <200601111755.k0BHtv58029071@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 11 Jan 2006 19:51:35.0318 (UTC) FILETIME=[6D928360:01C616E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Inter-Domain List Routing 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 On Wed, Jan 11, 2006 at 12:32:45PM -0700, Danny McPherson wrote: > >If you set a AS_PATHLIMIT of 4 and the AS four hops away strips that > >and adds a AS_PATHLIMIT of 15, would that be OK? > > Sure, why not? If I'm the 4th AS and have reason to do so? I own > my network resources? But you don't own the resources of the person who'll eventually receive the traffic. I can certainly see a shady economic argument that you'd want to disrespect control communities, even well recognized ones, in order to sink more traffic across your network. In many cases, this would lead to increased revenue being exchanged between AS 3 and AS 4. AS 1, on the other hand, receives more traffic than they may have wanted on that link. In the case where different routes that would affect flow across your network (A and B), I can see some justification to ignore downstream preferences because you may want to manage your own resources. This justification is vague because AS_PATH is usually a bigger knob to adjust these flows. In the case of communities, I can see the semi-justification that some policy languages make it difficult to "strip everything but well known communities". I can see the justification that you'd want to decrease the length in order to further constrain the diameter to which the routes propagate. I'm having a difficult time seeing (aside from the reasons above) why you'd otherwise want to increase the diameter of propagation. If you could expand on such possible reasons, I think a lot of us would appreciate it. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 15:46:09 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 1EwmrB-0001Ul-Ku; Wed, 11 Jan 2006 15:46:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmrA-0001Ug-Eo for idr@megatron.ietf.org; Wed, 11 Jan 2006 15:46:08 -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 PAA11465 for ; Wed, 11 Jan 2006 15:44:47 -0500 (EST) From: sandy@tislabs.com Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewmy6-000732-5b for idr@ietf.org; Wed, 11 Jan 2006 15:53:21 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0BKjbUS020405 for ; Wed, 11 Jan 2006 15:45:37 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAdoaqMN; Wed, 11 Jan 06 15:44:54 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0BKd1L6006109; Wed, 11 Jan 2006 15:39:01 -0500 (EST) Date: Wed, 11 Jan 2006 15:39:01 -0500 (EST) Message-Id: <200601112039.k0BKd1L6006109@tislabs.com> To: idr@ietf.org Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sandy@tislabs.com 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 >> As I understand it, the NO_EXPORT attribute is intended just >> for your immediate neighbor, and is not supposed to be propagated >> elsewhere. > >That'd be NO_ADVERTISE. >> There's this "MUST NOT be advertised" in the spec. > >In reality, NO_EXPORT in practice is employed to convey to >AN ADJACENT AS that the route should not be advertised to >BGP peers outside of that AS (i.e., eBGP peers). Yes, sorry, inexact use of terminology. When I said neighbors, I meant your external peer, I wasn't thinking of iBGP neighbors. >This is no different than any other attribute. For example, if >an upstream chooses not to announce a route, well, there's >little we can do about that. Sending an update to your (ebgp) neighbor is not a prescription of what he/she/it does with that update. Sending an AS_HOPCOUNT/ AS_PATHLIMIT or a community of NO_EXPORT is a prescription of what your (ebgp) neighbor is supposed to do with that update. So they are really very different. >> If you set a AS_PATHLIMIT of 4 and the AS four hops away strips that >> and adds a AS_PATHLIMIT of 15, would that be OK? > >Sure, why not? If I'm the 4th AS and have reason to do so? I own >my network resources? Then you mean the HOPCOUNT/PATHLIMIT to be advice or a request, and you can't expect anything particular to happen. You should make this clear in the draft text. In particular, you should remove all "MUST" and "MUST NOT" from the text. It makes no sense to say "MUST advertise an AS_HOPCOUNT attribute of one less than the value received", if replacing the value with any other value is OK. It makes no sense to say "If the attribute value is zero, the path MUST be ignored without further processing", if the BGP speaker can chose to ignore the limit and propagate. Are you sure you know what you want here? The language of the draft sounds like certainty and determinism is desired, but you are saying that no integrity protections are desired because local policy might do anything it wanted. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 16:34:41 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 1Ewnc9-00014k-Mh; Wed, 11 Jan 2006 16:34:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewnc8-00014f-NT for idr@megatron.ietf.org; Wed, 11 Jan 2006 16:34:40 -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 QAA15781 for ; Wed, 11 Jan 2006 16:33:18 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewnj6-0000aq-H0 for idr@ietf.org; Wed, 11 Jan 2006 16:41:53 -0500 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ewnbr-000Ck1-Tx; Wed, 11 Jan 2006 21:34:24 +0000 In-Reply-To: <200601112039.k0BKd1L6006109@tislabs.com> References: <200601112039.k0BKd1L6006109@tislabs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <381E1D27-6DED-4E2F-9CC8-0D30C42ECB69@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 16:34:22 -0500 To: sandy@tislabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 On 11-Jan-2006, at 15:39, sandy@tislabs.com wrote: >>> If you set a AS_PATHLIMIT of 4 and the AS four hops away strips that >>> and adds a AS_PATHLIMIT of 15, would that be OK? >> >> Sure, why not? If I'm the 4th AS and have reason to do so? I own >> my network resources? > > Then you mean the HOPCOUNT/PATHLIMIT to be advice or a request, > and you can't expect anything particular to happen. Correct. Ditto for NO_EXPORT and MED (to choose two other attributes that are commonly meddled-with). > You should make this clear in the draft text. In particular, > you should remove all "MUST" and "MUST NOT" from the text. I don't think so. The draft specifies the required behaviour for an implementation in the case where the attribute is present. Those requirements are orthogonal to whether or not an operator of an AS decides to implement policy which removes particular attributes which were added elsewhere. This is no different to the processing of NO_EXPORT. The semantics of how a BGP speaker should process a route with the NO_EXPORT community string attribute attached are described clearly, using normative text, in RFC 1997. There is nothing to stop people removing NO_EXPORT from routes as suits their local policy, however, just as there is nothing to stop people adding NO_EXPORT to routes whose originators intended them to propagate further. > Are you sure you know what you want here? The language of the > draft sounds like certainty and determinism is desired, but > you are saying that no integrity protections are desired because > local policy might do anything it wanted. Influencing other peoples' policy is a necessarily inexact science. Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 16:39:10 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 1EwngU-000239-8T; Wed, 11 Jan 2006 16:39:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwngT-000234-De for idr@megatron.ietf.org; Wed, 11 Jan 2006 16:39:09 -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 QAA16148 for ; Wed, 11 Jan 2006 16:37:47 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwnnR-0000kI-Dh for idr@ietf.org; Wed, 11 Jan 2006 16:46:22 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 0896D642D4 for ; Wed, 11 Jan 2006 14:38:45 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060111195133.GF22020@nexthop.com> References: <200601111755.k0BHtv58029071@tislabs.com> <20060111195133.GF22020@nexthop.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D9FF0F3-1CF3-4089-BED7-24BCEE941FC6@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 14:38:58 -0700 To: Inter-Domain List Routing X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit 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 On Jan 11, 2006, at 12:51 PM, Jeffrey Haas wrote: > > > But you don't own the resources of the person who'll eventually > receive the traffic. I can certainly see a shady economic argument > that you'd want to disrespect control communities, even well > recognized > ones, in order to sink more traffic across your network. or vice versa.. I wouldn't call it shady though, I'd call it practical and reality. > In many > cases, this would lead to increased revenue being exchanged between > AS 3 and AS 4. AS 1, on the other hand, receives more traffic than > they may have wanted on that link. > > In the case where different routes that would affect flow across > your network (A and B), I can see some justification to ignore > downstream preferences because you may want to manage your own > resources. This justification is vague because AS_PATH is usually > a bigger knob to adjust these flows. > > In the case of communities, I can see the semi-justification that > some policy languages make it difficult to "strip everything but > well known communities". > > I can see the justification that you'd want to decrease the length > in order to further constrain the diameter to which the routes > propagate. > > I'm having a difficult time seeing (aside from the reasons above) > why you'd otherwise want to increase the diameter of propagation. > If you could expand on such possible reasons, I think a lot of us > would appreciate it. I could make arguments for each of the above but it's futile. My point is simply that as a network operator I have policies that I employ on my network that are driven by both technical AND business requirements, either of which may drive me to ignore, strip or manipulate any attribute that could have an impact on the operations of my business. In short, I decide what route I provide transit for and how I'll permit the TE-associated attributes of those routes impact my network resources - AND who I allow to modify those resources. Now, with that said, operators of course realize what makes practical sense and what doesn't, and they clearly factor that into their policies. The fact that BGP provides this capability is a large contributor to it's success, IMO. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 16:47: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 1Ewnol-0005u3-PN; Wed, 11 Jan 2006 16:47:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewnok-0005ty-BJ for idr@megatron.ietf.org; Wed, 11 Jan 2006 16:47:42 -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 QAA16687 for ; Wed, 11 Jan 2006 16:46:19 -0500 (EST) From: sandy@tislabs.com Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewnvh-00010u-Hv for idr@ietf.org; Wed, 11 Jan 2006 16:54:54 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0BLlBjO002624 for ; Wed, 11 Jan 2006 16:47:12 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAj4aq3e; Wed, 11 Jan 06 16:46:32 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0BLmwiX009305; Wed, 11 Jan 2006 16:48:58 -0500 (EST) Date: Wed, 11 Jan 2006 16:48:58 -0500 (EST) Message-Id: <200601112148.k0BLmwiX009305@tislabs.com> To: idr@ietf.org Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sandy@tislabs.com 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 >The draft specifies the required behaviour for an implementation in >the case where the attribute is present. Those requirements are >orthogonal to whether or not an operator of an AS decides to >implement policy which removes particular attributes which were added >elsewhere. Sounds to me like you are quibbling - if the AS removes the attribute and creates a new lookalike with a value that would not follow the spec, then it is OK. I don't think "this isn't a modification, it is a deletion and insertion" is necessarily always justified. Or maybe you don't realize that I'm talking about changing the value in an existing attribute. So - suppose you create a PATHLIMIT of 4 and *two* hops away, someone changes the limit to 15? I.E., not a new attribute, keeping your AS number in the attribute and all that. Is that still OK with you? If we're talking about HOPCOUNT, if you create a HOPCOUNT of 4 and two hops away someone adds 6? Still OK? These aren't at the limit you've specified for the propagation of the route, the changes are somewhere along the way. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 16:48: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 1EwnpR-0006GB-T6; Wed, 11 Jan 2006 16:48:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwnpQ-0006G6-H6 for idr@megatron.ietf.org; Wed, 11 Jan 2006 16:48:24 -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 QAA16784 for ; Wed, 11 Jan 2006 16:47:02 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwnwP-000136-JI for idr@ietf.org; Wed, 11 Jan 2006 16:55:37 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id E124A642D4 for ; Wed, 11 Jan 2006 14:48:09 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601112039.k0BKd1L6006109@tislabs.com> References: <200601112039.k0BKd1L6006109@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8D5829D6-668C-43BC-84AC-05EF6C41B83E@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 14:48:24 -0700 To: Inter-Domain Routing List X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit 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 On Jan 11, 2006, at 1:39 PM, sandy@tislabs.com wrote: >>> As I understand it, the NO_EXPORT attribute is intended just >>> for your immediate neighbor, and is not supposed to be propagated >>> elsewhere. >> >> That'd be NO_ADVERTISE. >>> There's this "MUST NOT be advertised" in the spec. >> >> In reality, NO_EXPORT in practice is employed to convey to >> AN ADJACENT AS that the route should not be advertised to >> BGP peers outside of that AS (i.e., eBGP peers). > > Yes, sorry, inexact use of terminology. When I said neighbors, > I meant your external peer, I wasn't thinking of iBGP neighbors. > >> This is no different than any other attribute. For example, if >> an upstream chooses not to announce a route, well, there's >> little we can do about that. > > Sending an update to your (ebgp) neighbor is not a prescription > of what he/she/it does with that update. Sending an AS_HOPCOUNT/ > AS_PATHLIMIT or a community of NO_EXPORT is a prescription of > what your (ebgp) neighbor is supposed to do with that update. > So they are really very different. No, it's a prescription of what *you'd like your neighbor* to do with the update. > Then you mean the HOPCOUNT/PATHLIMIT to be advice or a request, > and you can't expect anything particular to happen. Like it or not, isn't that the way routing in the Internet works today? > You should make this clear in the draft text. In particular, > you should remove all "MUST" and "MUST NOT" from the text. > It makes no sense to say "MUST advertise an AS_HOPCOUNT attribute > of one less than the value received", if replacing the value > with any other value is OK. It makes no sense to say > "If the attribute value is zero, the path MUST be ignored > without further processing", if the BGP speaker can chose to > ignore the limit and propagate. This applies to ALL attributes deployed today - why the exception here? > Are you sure you know what you want here? The language of the > draft sounds like certainty and determinism is desired, but > you are saying that no integrity protections are desired because > local policy might do anything it wanted. Again, like it or not, that's the nature of routing in the Internet today. Think about it.. What if someone downstream wanted to manipulate a competitors traffic flows and they couldn't do anything about it? First and foremost, operators have to protect their networks and employ policies that make good technical and business sense. Then they can permit and employ features such as this. In reality, most likely would support it, e.g., for the reasons outlined in the draft, but determinism is a bit of a misnomer in the real world when your considering thousands of companies globally, all with different legal, regulatory, business and economic motivations. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 19:01:56 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 1Ewpue-0004Ie-Iv; Wed, 11 Jan 2006 19:01:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewpuc-0004Hk-ID for idr@megatron.ietf.org; Wed, 11 Jan 2006 19:01: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 TAA27270 for ; Wed, 11 Jan 2006 19:00:34 -0500 (EST) Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewq1Z-0005gr-Sr for idr@ietf.org; Wed, 11 Jan 2006 19:09:09 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with SMTP id <2006011200013601400evknfe>; Thu, 12 Jan 2006 00:01:37 +0000 In-Reply-To: <200601112148.k0BLmwiX009305@tislabs.com> References: <200601112148.k0BLmwiX009305@tislabs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 16:01:34 -0800 To: sandy@tislabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Ok, this conversation, while interesting, is getting more than a wee bit off topic. Can we please take it to RPSEC? The entire issue of what RPSEC will protect, how it can protect mutable attributes and not force a full re-engineering of the entire Internet is NOT something that we should be solving here. PATHLIMIT is certainly intended to be one of those mutable attributes, either because it is being decrement, applied by proxy, or both. Tony On Jan 11, 2006, at 1:48 PM, sandy@tislabs.com wrote: >> The draft specifies the required behaviour for an implementation in >> the case where the attribute is present. Those requirements are >> orthogonal to whether or not an operator of an AS decides to >> implement policy which removes particular attributes which were added >> elsewhere. > > Sounds to me like you are quibbling - if the AS removes the > attribute and creates a new lookalike with a value that would > not follow the spec, then it is OK. > > I don't think "this isn't a modification, it is a deletion and > insertion" is necessarily always justified. > > Or maybe you don't realize that I'm talking about changing the > value in an existing attribute. > > So - suppose you create a PATHLIMIT of 4 and *two* hops away, > someone changes the limit to 15? I.E., not a new attribute, > keeping your AS number in the attribute and all that. Is that > still OK with you? If we're talking about HOPCOUNT, if you > create a HOPCOUNT of 4 and two hops away someone adds 6? > Still OK? These aren't at the limit you've specified for the > propagation of the route, the changes are somewhere along the way. > > --Sandy > > _______________________________________________ > 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 Jan 11 19:11:05 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 1Ewq3V-000249-HJ; Wed, 11 Jan 2006 19:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewq3T-00021y-TP for idr@megatron.ietf.org; Wed, 11 Jan 2006 19:11:03 -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 TAA28948 for ; Wed, 11 Jan 2006 19:09:43 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwqAS-0006MX-0M for idr@ietf.org; Wed, 11 Jan 2006 19:18:17 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2006011200103801100dk3c9e>; Thu, 12 Jan 2006 00:10:38 +0000 In-Reply-To: <200601111827.k0BIRhbf000350@tislabs.com> References: <200601111827.k0BIRhbf000350@tislabs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 16:10:36 -0800 To: sandy@tislabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 On Jan 11, 2006, at 10:27 AM, sandy@tislabs.com wrote: > W-e-e-l-l. Tony says that those routers who attach this attribute > could have used "normal policy mechanisms" to filter out the route. > But I thought the whole point was that normal policy mechanisms > did not provide the control desired. The point is that this does not create a new security hole, as manually configured route filters could result in the same restrictions on propagation today, but would require TONS more coordination and other management hair. Thus, the new attribute does not make the security situation appreciably worse than it is today. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 11 19:16:18 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 1Ewq8Y-0004Ib-A6; Wed, 11 Jan 2006 19:16:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewq8V-0004HP-S8 for idr@megatron.ietf.org; Wed, 11 Jan 2006 19:16:16 -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 TAA29334 for ; Wed, 11 Jan 2006 19:14:55 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwqFV-0006XM-7C for idr@ietf.org; Wed, 11 Jan 2006 19:23:30 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc13) with SMTP id <2006011200160201300o7klse>; Thu, 12 Jan 2006 00:16:03 +0000 In-Reply-To: <20060111153303.GB22020@nexthop.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <20060110223708.GB12691@nexthop.com> <20060111153303.GB22020@nexthop.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 16:16:00 -0800 To: Jeffrey Haas X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 Jeff, > I would definitely like to see more language about how we do the > counting. Absolute path length seems to be the wrong choice. I > think that > Russ's verbiage about distinct ASes is close. I'd suggest that > we count any recurring adjacent sequences of an AS in one or more > AS_SEQUENCEs as length 1 and simply count an entire AS_SET, regardless > of content, as length 1. > > Ergo: > > 1 1 1 2 3 3 2 [5 6 7] > > would count as length 5. Yes, there's an intentional loop in there. Well, the language that I'm proposing is slightly different in intent and result. Regardless, when the revised draft is issued, I'd welcome alternate proposals and contributions of specific language that capture WG consensus. > This is somewhat problematic when dealing with a 2 byte speaker > with AS_TRANS in the AS_PATH. Without peeking into the NEW_AS_PATH, > you can't tell if multiple occurrences are distinct ASes or not. This > affects how I'd expect path length counting to occur. Good point. Let's also put that on the agenda. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jan 12 10:05:48 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 1Ex41M-0005j5-7z; Thu, 12 Jan 2006 10:05:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex41K-0005i6-JS for idr@megatron.ietf.org; Thu, 12 Jan 2006 10:05:46 -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 KAA23296 for ; Thu, 12 Jan 2006 10:04:25 -0500 (EST) From: sandy@tislabs.com Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex48O-0006l8-Rk for idr@ietf.org; Thu, 12 Jan 2006 10:13:09 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0CF5D4q001946 for ; Thu, 12 Jan 2006 10:05:13 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAATTaONd; Thu, 12 Jan 06 10:04:39 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0CF782A023718; Thu, 12 Jan 2006 10:07:08 -0500 (EST) Date: Thu, 12 Jan 2006 10:07:08 -0500 (EST) Message-Id: <200601121507.k0CF782A023718@tislabs.com> To: sandy@tislabs.com, tony.li@tony.li Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 >Can we please take it to RPSEC? >... >PATHLIMIT is certainly intended to be one of those mutable attributes, >either because it is being decrement, applied by proxy, or both. If the PATHLIMIT is intended to be mutable, then the conversation can cease here and you don't need to take anything to RPSEC - if the intent is to let anyone modify the attribute in any way, there there is no integrity security needed. Making that clear in the spec would, IMHO, a good thing. It would be easy to read "PATHLIMIT" and "MUST advertise an AS_HOPCOUNT atribute of one less than the value received" and "If the attribute value is zero, the path MUST be ignored without further processing" and think something more deterministic was going on than a mutable attribute that was advice only. >The entire issue of what RPSEC will >protect, how it can protect mutable attributes and not force a full >re-engineering >of the entire Internet is NOT something that we should be solving here. RPSEC is charged with threat models and security analysis and requirements, with "routing protocol designers" charged with using the RPSEC products to ensure security in their protocols. At least, that's what the charter says now. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jan 12 18:00: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 1ExBQp-0000yD-Ql; Thu, 12 Jan 2006 18:00:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBQo-0000y8-Pn for idr@megatron.ietf.org; Thu, 12 Jan 2006 18:00:34 -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 RAA03271 for ; Thu, 12 Jan 2006 17:59:14 -0500 (EST) Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExBY0-0007K1-6H for idr@ietf.org; Thu, 12 Jan 2006 18:08:01 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with SMTP id <2006011223001401400f2h83e>; Thu, 12 Jan 2006 23:00:15 +0000 In-Reply-To: <200601121507.k0CF782A023718@tislabs.com> References: <200601121507.k0CF782A023718@tislabs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7628B617-9CAF-4A87-B26D-766D60B4CE03@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Thu, 12 Jan 2006 15:00:11 -0800 To: sandy@tislabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 > If the PATHLIMIT is intended to be mutable, then the conversation > can cease here and you don't need to take anything to RPSEC - > if the intent is to let anyone modify the attribute in any way, > there there is no integrity security needed. > > Making that clear in the spec would, IMHO, a good thing. > It would be easy to read "PATHLIMIT" and "MUST advertise > an AS_HOPCOUNT atribute of one less than the value received" > and "If the attribute value is zero, the path MUST be ignored > without further processing" and think something more deterministic > was going on than a mutable attribute that was advice only. Please see section 5.2. We clearly state that AS_HOPCOUNT may be used in a proxy fashion. I believe that it's a rush to the other side of the spectrum to say that no integrity security is needed. There are a number of mutable attributes necessary for fully functioning BGP (e.g., AS_PATH, communities). Hopefully whatever solution RPSEC selects to protect these attributes will also be useable for AS_HOPCOUNT or AS_PATHLIMIT. > > The entire issue of what RPSEC will >> protect, how it can protect mutable attributes and not force a full >> re-engineering >> of the entire Internet is NOT something that we should be solving >> here. > > RPSEC is charged with threat models and security analysis and > requirements, with "routing protocol designers" charged with > using the RPSEC products to ensure security in their protocols. > At least, that's what the charter says now. Hopefully someone, somewhere will actually have responsibility for coming up with some actual, workable security mechanisms and specifications for implementations that still provide inter-domain routing functionality in a manner that is actually useful and deployable sometime before the heat death of the universe. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jan 12 18:18:40 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 1ExBiK-000737-Q8; Thu, 12 Jan 2006 18:18:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBiJ-000732-2O for idr@megatron.ietf.org; Thu, 12 Jan 2006 18:18:39 -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 SAA04613 for ; Thu, 12 Jan 2006 18:17:18 -0500 (EST) From: sandy@tislabs.com Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExBpU-0007xW-H5 for idr@ietf.org; Thu, 12 Jan 2006 18:26:05 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0CNI7mW021712 for ; Thu, 12 Jan 2006 18:18:07 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAlVaOzQ; Thu, 12 Jan 06 18:18:05 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0CNKYLx013759; Thu, 12 Jan 2006 18:20:34 -0500 (EST) Date: Thu, 12 Jan 2006 18:20:34 -0500 (EST) Message-Id: <200601122320.k0CNKYLx013759@tislabs.com> To: sandy@tislabs.com, tony.li@tony.li Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 >Please see section 5.2. We clearly state that AS_HOPCOUNT may >be used in a proxy fashion. Should the text I quoted from elsewhere in the document be modified to be consistent? >I believe that it's a rush to the other side of the spectrum to say that >no integrity security is needed. There are a number of mutable >attributes necessary for fully functioning BGP (e.g., AS_PATH, >communities). Hopefully whatever solution RPSEC selects to >protect these attributes will also be useable for AS_HOPCOUNT or >AS_PATHLIMIT. The AS_PATH is mutable, but the decision of what mutations are permitted is one of the stumbling blocks in determining a solution. If you go by the "MUST/MUST NOT" in the bgp spec, you come up with one idea of what is permitted. If you go by the what vendors allow you to configure your routers to do, you come up with a much different idea of what is permitted. But whichever modification rule for AS_PATH you follow, there may not be sufficient match to the semantics of the HOPCOUNT/PATHLIMIT to make the security protections for AS_PATH also protect the HOPCOUNT/PATHLIMIT. You imply you think that there is integrity required. But the conclusion I've reached from other email is that people want any AS to be allowed to strip, replace, or modify the HOPCOUNT/PATHLIMIT. What sort of integrity do you see that would still allow that? (Question, not dig. Really - what integrity requirement do you see? Limitation on who could strip/replacy/modify?) --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jan 12 19:05:24 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 1ExCRY-0005JX-Fm; Thu, 12 Jan 2006 19:05:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExCRW-0005J1-Ll for idr@megatron.ietf.org; Thu, 12 Jan 2006 19:05:22 -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 TAA09972 for ; Thu, 12 Jan 2006 19:04:01 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExCYf-0001mA-6O for idr@ietf.org; Thu, 12 Jan 2006 19:12:49 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2006011300044301100dch52e>; Fri, 13 Jan 2006 00:04:45 +0000 In-Reply-To: <200601122320.k0CNKYLx013759@tislabs.com> References: <200601122320.k0CNKYLx013759@tislabs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Thu, 12 Jan 2006 16:04:41 -0800 To: sandy@tislabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Sandy, >> Please see section 5.2. We clearly state that AS_HOPCOUNT may >> be used in a proxy fashion. > > Should the text I quoted from elsewhere in the document be > modified to be consistent? Please see the revised version when I am permitted to post it. If you have comments on that version, then we should discuss them. > But whichever modification rule for AS_PATH you follow, there > may not be sufficient match to the semantics of the HOPCOUNT/PATHLIMIT > to make the security protections for AS_PATH also protect the > HOPCOUNT/PATHLIMIT. That is true. However, as there are no proposed mechanisms for AS_PATH, I don't see much point in arguing about whether the not-yet-proposed semantics are sufficient or not. > You imply you think that there is integrity required. But the > conclusion I've reached from other email is that people want any > AS to be allowed to strip, replace, or modify the HOPCOUNT/PATHLIMIT. > What sort of integrity do you see that would still allow that? > (Question, not dig. Really - what integrity requirement do you see? > Limitation on who could strip/replacy/modify?) Well, as I tried to point out, I think that you're leaping to all sorts of conclusions, mostly unwarranted. With regard to AS_PATHLIMIT, I would like to see several properties. For one example, if an AS attaches AS_PATHLIMIT, I would like to know that the AS number that it attaches is its AS number and no other. There are a number of other security properties that I would like to see, but again, they are general properties that should be applicable to all BGP path attributes, not just AS_PATHLIMIT. As such, I would prefer to discuss them as part of RPSEC. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jan 13 09:33:38 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 1ExPzm-0007Hc-CT; Fri, 13 Jan 2006 09:33:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPzk-0007HX-Of for idr@megatron.ietf.org; Fri, 13 Jan 2006 09:33:36 -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 JAA09647 for ; Fri, 13 Jan 2006 09:32:14 -0500 (EST) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExQ72-0005fY-3L for idr@ietf.org; Fri, 13 Jan 2006 09:41:11 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id 153431B0B; Fri, 13 Jan 2006 14:33:14 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 644kamohN0170Mo2; Fri, 13 Jan 2006 14:33:13 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 641kamohL0038Mo2; Fri, 13 Jan 2006 14:33:11 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Fri, 13 Jan 2006 14:33:11 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID237kamohL4366Xo2 Received: from localhost ([65.247.36.31]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 07:33:11 -0700 Date: Fri, 13 Jan 2006 09:33:10 -0500 From: Jeffrey Haas To: sandy@tislabs.com Subject: Re: [Idr] Next revision of AS_HOPCOUNT Message-ID: <20060113143310.GY22020@nexthop.com> References: <200601122320.k0CNKYLx013759@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601122320.k0CNKYLx013759@tislabs.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 13 Jan 2006 14:33:11.0286 (UTC) FILETIME=[47821160:01C6184E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 On Thu, Jan 12, 2006 at 06:20:34PM -0500, sandy@tislabs.com wrote: > You imply you think that there is integrity required. But the > conclusion I've reached from other email is that people want any > AS to be allowed to strip, replace, or modify the HOPCOUNT/PATHLIMIT. > What sort of integrity do you see that would still allow that? I may be misusing security taxonomy, but I think the property we'd be interested in for this case is accountability. Knowing who made the change is often a good start to take some form of action when someone acts contrary to your expectations. > --Sandy -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jan 13 12:09:11 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 1ExSQJ-0007fa-Jo; Fri, 13 Jan 2006 12:09:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExSQH-0007fV-G9 for idr@megatron.ietf.org; Fri, 13 Jan 2006 12:09:09 -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 MAA22259 for ; Fri, 13 Jan 2006 12:07:45 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExSXc-0003aa-20 for idr@ietf.org; Fri, 13 Jan 2006 12:16:44 -0500 Received: from pc6 (1Cust90.tnt104.lnd4.gbr.da.uu.net [213.116.56.90]) by ranger.systems.pipex.net (Postfix) with SMTP id 66950E000120; Fri, 13 Jan 2006 17:08:48 +0000 (GMT) Message-ID: <037901c6185b$39938ea0$0601a8c0@pc6> From: "Tom Petch" To: "Inter-Domain Routing List" , "Tony Li" References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Fri, 13 Jan 2006 15:53:01 +0100 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch 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 ----- Original Message ----- From: "Tony Li" To: "Inter-Domain Routing List" Sent: Tuesday, January 10, 2006 9:35 PM Subject: [Idr] Next revision of AS_HOPCOUNT > > Based on the discussion that we've had so far, the authors of the > AS_HOPCOUNT draft would > like to make some substantive changes to the draft. The chairs have > asked that we poll you to > ensure that we have rough consensus on the new direction. The > primary technical points of > these changes: > > - Convert AS_HOPCOUNT from being decremented at each AS boundary and > instead have it be a static upper bound on the AS path length. > Yes, I think that is absolutely right. Decrementing counts was fine when the community was smaller and closer knit, more trustworthy perhaps. In the present heterogeneous world, I think static upper bound the right approach. It is also easier to secure whatever form security ultimately takes. > - Rename the attribute to AS_PATHLIMIT. > Fits in with the abouve > - Completely remove the interaction with NO_EXPORT. > Not sure that this is completely possible; to take the view that any reason not to advertise means do not advertise is a form of interaction, which might conflict with the use of AS_PATHLIMIT (no, I haven't got a concrete example of when this would happen) Tom Petch. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jan 13 12:50:14 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 1ExT42-0002WA-5i; Fri, 13 Jan 2006 12:50:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExT41-0002Vi-0d for idr@megatron.ietf.org; Fri, 13 Jan 2006 12:50:13 -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 MAA24788 for ; Fri, 13 Jan 2006 12:48:51 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExTBM-0004vD-5g for idr@ietf.org; Fri, 13 Jan 2006 12:57:49 -0500 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExT3O-0007zR-D6; Fri, 13 Jan 2006 17:49:34 +0000 In-Reply-To: <037901c6185b$39938ea0$0601a8c0@pc6> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <037901c6185b$39938ea0$0601a8c0@pc6> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Fri, 13 Jan 2006 12:49:32 -0500 To: Tom Petch X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Tony Li 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 On 13-Jan-2006, at 09:53, Tom Petch wrote: >> - Completely remove the interaction with NO_EXPORT. > > Not sure that this is completely possible; to take the view that > any reason not > to advertise means do not advertise is a form of interaction, which > might > conflict with the use of AS_PATHLIMIT (no, I haven't got a concrete > example of > when this would happen) I think what Tony meant by his sentence above was that the interaction specified in draft-idr-as-hopcount-00 would be removed as part of this revision. No greater philosophical message should be inferred :-) Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jan 13 13:05:14 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 1ExTIY-0006IC-7c; Fri, 13 Jan 2006 13:05:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTIV-0006HH-Sy for idr@megatron.ietf.org; Fri, 13 Jan 2006 13:05:11 -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 NAA25667 for ; Fri, 13 Jan 2006 13:03:50 -0500 (EST) Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExTPp-0005TF-ET for idr@ietf.org; Fri, 13 Jan 2006 13:12:48 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id E1CB5E0438; Fri, 13 Jan 2006 13:04:56 -0500 (EST) Date: Fri, 13 Jan 2006 13:04:56 -0500 From: John Leslie To: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Message-ID: <20060113180456.GD89985@verdi> References: <200601122320.k0CNKYLx013759@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Tony Li wrote: >>> Please see section 5.2. We clearly state that AS_HOPCOUNT may >>> be used in a proxy fashion. >> > Sandy, > >> Should the text I quoted from elsewhere in the document be >> modified to be consistent? > > Please see the revised version when I am permitted to post it. If you > have comments on that version, then we should discuss them. Will somebody please own up to telling Tony he may not publish the revised draft to the list? This is taking on a Kafka-esque feeling that we're expected to agree we have consensus on something before we're allowed to find out what it is we're consenting to. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jan 13 13:43: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 1ExTt7-0006oh-GO; Fri, 13 Jan 2006 13:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTt6-0006oE-Bk for idr@megatron.ietf.org; Fri, 13 Jan 2006 13:43:00 -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 NAA27824 for ; Fri, 13 Jan 2006 13:41:38 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExU0S-0006gp-4v for idr@ietf.org; Fri, 13 Jan 2006 13:50:37 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2006011318423101100dg33ve>; Fri, 13 Jan 2006 18:42:42 +0000 In-Reply-To: <20060113180456.GD89985@verdi> References: <200601122320.k0CNKYLx013759@tislabs.com> <20060113180456.GD89985@verdi> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <88A63304-9B44-4957-B358-E617A73147A0@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Fri, 13 Jan 2006 10:42:01 -0800 To: John Leslie X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 > Will somebody please own up to telling Tony he may not publish the > revised draft to the list? This was the directive of our esteemed chairs. Apparently this is now the modus operandi of the IETF when one wants to re-architect a draft. > This is taking on a Kafka-esque feeling that we're expected to > agree we have consensus on something before we're allowed to find > out what it is we're consenting to. I wholeheartedly agree. Furthermore, I'm trying to play by the rules as stated, which for those that know me, adds to the surreal tableau. ;-) Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jan 13 13:51:48 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 1ExU1c-00013R-OE; Fri, 13 Jan 2006 13:51:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExU1a-00013J-Fl for idr@megatron.ietf.org; Fri, 13 Jan 2006 13:51:46 -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 NAA28427 for ; Fri, 13 Jan 2006 13:50:24 -0500 (EST) Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExU8x-00070w-5E for idr@ietf.org; Fri, 13 Jan 2006 13:59:23 -0500 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id CC7121B84; Fri, 13 Jan 2006 18:51:20 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 954kamszT0017Mo1; Fri, 13 Jan 2006 18:51:19 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 952kamszq0472Mo1; Fri, 13 Jan 2006 18:51:17 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.27I); Fri, 13 Jan 2006 18:51:17 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID094kamszR1327Xo1 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by GW2.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 11:51:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 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] Next revision of AS_HOPCOUNT Date: Fri, 13 Jan 2006 11:51:10 -0700 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F0202DAA753@VS4.EXCHPROD.USA.NET> Thread-Topic: [Idr] Next revision of AS_HOPCOUNT Thread-Index: AcYYcYbXxop6ipkHTGiizz6fW+Ec6QAACphw From: "Susan Hares" To: "Tony Li" , "John Leslie" X-OriginalArrivalTime: 13 Jan 2006 18:51:13.0764 (UTC) FILETIME=[53C8BA40:01C61872] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable 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 Guys:=20 Sorry for the kafka-esque feeling. =20 We had agreement 20-30 people the work group on the last draft that it was useful work. And no one strongly objected.=20 Just floating by the changes to those same parties to make sure we're still on-track is the goal. And to make sure new objections don't get too strong.=20 Don't get too bound up in the process.=20 If it aids, we can just send a note to all those who agreed previous and go from there. I or Tony can do that and publish the results to the list.=20 Cheers, Sue Hares=20 Co-chair =20 -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Tony Li Sent: Friday, January 13, 2006 1:42 PM To: John Leslie Cc: idr@ietf.org Subject: Re: [Idr] Next revision of AS_HOPCOUNT > Will somebody please own up to telling Tony he may not publish the > revised draft to the list? This was the directive of our esteemed chairs. Apparently this is now the modus operandi of the IETF when one wants to re-architect a draft. > This is taking on a Kafka-esque feeling that we're expected to > agree we have consensus on something before we're allowed to find > out what it is we're consenting to. I wholeheartedly agree. Furthermore, I'm trying to play by the rules as stated, which for those that know me, adds to the surreal tableau. ;-) 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 Fri Jan 13 16:42:44 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 1ExWh2-0002Pu-9l; Fri, 13 Jan 2006 16:42:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWh1-0002Pj-3M for idr@megatron.ietf.org; Fri, 13 Jan 2006 16:42:43 -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 QAA13696 for ; Fri, 13 Jan 2006 16:41:20 -0500 (EST) From: sandy@tislabs.com Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExWoN-0006CB-Ir for idr@ietf.org; Fri, 13 Jan 2006 16:50:21 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0DLg83K006858 for ; Fri, 13 Jan 2006 16:42:08 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAyAaWyn; Fri, 13 Jan 06 16:42:05 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0DLiZOs029038; Fri, 13 Jan 2006 16:44:35 -0500 (EST) Date: Fri, 13 Jan 2006 16:44:35 -0500 (EST) Message-Id: <200601132144.k0DLiZOs029038@tislabs.com> To: idr@ietf.org Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sandy@tislabs.com 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 >That is true. However, as there are no proposed mechanisms for >AS_PATH, I don't see much point in arguing about whether the >not-yet-proposed semantics are sufficient or not. I know of at least 5, with two of them generalized in the BGP security requirements draft. Some of those match semantics you might choose, some of them do not, depending on what you choose. >For one example, if an >AS attaches AS_PATHLIMIT, I would like to know that the AS number >that it attaches is its AS number and no other. That's good. And then there's more to discuss from there. >As such, I would prefer >to discuss them as part of RPSEC. I would recommend starting the discussion now. The scenario to avoid is: idr to security/rpsec: OK, we've done with the draft. Now tell us how to secure it. security/rpsec to idr: Oh, we see you made the design choice that is really, really hard to protect. Too bad. idr to security/rpsec: Why can't you people ever come up with a deployable security solution!! --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sun Jan 15 12:35:04 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 1EyBfK-0005tv-FC; Sun, 15 Jan 2006 12:27:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyBfE-0005jG-6w for idr@megatron.ietf.org; Sun, 15 Jan 2006 12:27:36 -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 LAA07885 for ; Sun, 15 Jan 2006 11:48:31 -0500 (EST) From: sandy@tislabs.com Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExkxG-0007Wy-3u for idr@ietf.org; Sat, 14 Jan 2006 07:56:27 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0ECm2ch013808 for ; Sat, 14 Jan 2006 07:48:02 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAOza4UA; Sat, 14 Jan 06 07:47:22 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0ECnqoM024568; Sat, 14 Jan 2006 07:49:52 -0500 (EST) Date: Sat, 14 Jan 2006 07:49:52 -0500 (EST) Message-Id: <200601141249.k0ECnqoM024568@tislabs.com> To: idr@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sandy@tislabs.com Subject: [Idr] septuplet birth in idr 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 I haven't seen any mention of the fact on the list, so I thought I'd be the first to congratulate the working group chairs and routing area directors and rfc editors in the emergence of the septuplet set of BGP RFCs after a prolonged confinement. As one of those who were gently nudged, urged, and cattle-proded as needed toward completing the final steps, I want to thank them all. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jan 19 09:00:26 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 1EzaKw-0005xu-Ev; Thu, 19 Jan 2006 09:00:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzaKu-0005xZ-B8 for idr@megatron.ietf.org; Thu, 19 Jan 2006 09:00:24 -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 IAA24964 for ; Thu, 19 Jan 2006 08:58:57 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzaTR-0000F5-1X for idr@ietf.org; Thu, 19 Jan 2006 09:09:14 -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 k0JE061Z074776; Thu, 19 Jan 2006 06:00:06 -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 k0JE06538375; Thu, 19 Jan 2006 06:00:06 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200601191400.k0JE06538375@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <61444.1137679206.1@juniper.net> Date: Thu, 19 Jan 2006 06:00:06 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: skh@nexthop.com Subject: [Idr] IDR WG agenda 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, Its about time to start thinking about agenda items for the next IETF. Please forward any IDR agenda items you might have to me and Sue. If you plan to make a presentation, please also keep in mind the rule "no document - no time slot". Sue & Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Thu Jan 19 10:01:37 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 1EzbI9-0003G1-Gt; Thu, 19 Jan 2006 10:01:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbI8-0003Fw-9o for idr@megatron.ietf.org; Thu, 19 Jan 2006 10:01:36 -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 KAA29176 for ; Thu, 19 Jan 2006 10:00:09 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzbQf-0002Dn-Mu for idr@ietf.org; Thu, 19 Jan 2006 10:10:27 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2006 16:01:25 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0JF0p6C013174; Thu, 19 Jan 2006 16:01:22 +0100 (MET) Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Jan 2006 16:01:09 +0100 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] IDR WG agenda Date: Thu, 19 Jan 2006 16:01:04 +0100 Message-ID: Thread-Topic: [Idr] IDR WG agenda Thread-Index: AcYdAX0aDzOt1n/1So25r2Ed0NO0nQABcnRQ From: "Francois Le Faucheur \(flefauch\)" To: "Yakov Rekhter" , X-OriginalArrivalTime: 19 Jan 2006 15:01:09.0583 (UTC) FILETIME=[2E545DF0:01C61D09] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: idr@ietf.org, "Francois Le Faucheur \(flefauch\)" , "Eric Levy- Abegnoli \(elevyabe\)" , Rajiv Papneja 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, Sue, I'd like to request a slot at next IETF to present: draft-levy-idr-6pe-survey-00.txt , "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)- Implementation Report". This document will be posted very shortly. It reports the results of the implementation survey for the 6PE (aka draft-ooms-v6ops-bgp-tunnel-xx). As discussed, this Implementation Report is in line with the Routing Area's procedures, so we can proceed with RFCization of draft-ooms-v6ops-bgp-tunnel. Thank you Francois >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On=20 >> Behalf Of Yakov Rekhter >> Sent: jeudi 19 janvier 2006 15:00 >> To: idr@ietf.org >> Cc: skh@nexthop.com >> Subject: [Idr] IDR WG agenda >>=20 >> Folks, >> =20 >> Its about time to start thinking about agenda items for the next >> IETF. Please forward any IDR agenda items you might have to=20 >> me and Sue. >>=20 >> If you plan to make a presentation, please also keep in mind the=20 >> rule "no document - no time slot". >>=20 >> Sue & Yakov. >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www1.ietf.org/mailman/listinfo/idr >>=20 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 25 13:13:04 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 1F1p8i-00059M-J0; Wed, 25 Jan 2006 13:13:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1p8d-00054x-2v; Wed, 25 Jan 2006 13:12: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 NAA08240; Wed, 25 Jan 2006 13:11:25 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1pIN-0003LW-L1; Wed, 25 Jan 2006 13:23:03 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F1p8Y-000711-Cc; Wed, 25 Jan 2006 13:12:54 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 25 Jan 2006 13:12:54 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: idr chair , idr mailing list , idr chair , Internet Architecture Board , RFC Editor Subject: [Idr] Protocol Action: 'BGP Route Reflection - An Alternative to Full Mesh IBGP' to Draft 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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org The IESG has approved the following document: - 'BGP Route Reflection - An Alternative to Full Mesh IBGP ' as a Draft 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-rfc2796bis-02.txt Technical Summary This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. Route Reflection relaxes the rule that a route learned via IBGP must not be sent to another IBGP peer, for designated peers called "Route Reflectors". It then replaces the full mesh among IBGP speakers with a single peering to a Route Reflector. This update adds an update to the BGP Decision Process. Working Group Summary There was working group consensus to advance this specification to Draft Standard. Protocol Quality Bill Fenner reviewed this specification for the IESG. There are several known implementations, as described in the accompanying implementation report, available at the following URL: http://www.ietf.org/IESG/Implementations/RFC2796-implementations.txt _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jan 25 18:50:18 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 1F1uP4-0001rN-Id; Wed, 25 Jan 2006 18:50:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1uOq-0001nZ-6l; Wed, 25 Jan 2006 18:50: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 SAA05174; Wed, 25 Jan 2006 18:48:32 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1uYf-0006xV-On; Wed, 25 Jan 2006 19:00:14 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F1uOo-00051x-A0; Wed, 25 Jan 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: Wed, 25 Jan 2006 18:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-cease-subcode-07.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 --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 : Subcodes for BGP Cease Notification Message Author(s) : E. Chen, V. Gillet Filename : draft-ietf-idr-cease-subcode-07.txt Pages : 6 Date : 2006-1-25 This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating network events and diagnosing BGP peering issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-cease-subcode-07.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-cease-subcode-07.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-cease-subcode-07.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-1-25164437.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-cease-subcode-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-cease-subcode-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-25164437.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 Jan 26 13:19:18 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 1F2BiI-0002t9-5T; Thu, 26 Jan 2006 13:19:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Bi8-0002rb-T3 for idr@megatron.ietf.org; Thu, 26 Jan 2006 13:19:09 -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 NAA11904 for ; Thu, 26 Jan 2006 13:17:37 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Bs7-0000CJ-HP for idr@ietf.org; Thu, 26 Jan 2006 13:29:29 -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 k0QIIp561391; Thu, 26 Jan 2006 10:18:51 -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 k0QIIj559998; Thu, 26 Jan 2006 10:18:45 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200601261818.k0QIIj559998@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <90098.1138299525.1@juniper.net> Date: Thu, 26 Jan 2006 10:18:45 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Susan Hares , Ronald Bonica , Rick Wilder , Ross Callon 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, 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 From idr-bounces@ietf.org Thu Jan 26 13:20:58 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 1F2Bju-00039I-K3; Thu, 26 Jan 2006 13:20:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Bjs-000395-Hu for idr@megatron.ietf.org; Thu, 26 Jan 2006 13:20:56 -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 NAA11981 for ; Thu, 26 Jan 2006 13:19: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 1F2Btr-0000Fm-Ri for idr@ietf.org; Thu, 26 Jan 2006 13:31:17 -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 k0QIKb561426; Thu, 26 Jan 2006 10:20:44 -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 k0QIKW560353; Thu, 26 Jan 2006 10:20:32 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200601261820.k0QIKW560353@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <90237.1138299632.1@juniper.net> Date: Thu, 26 Jan 2006 10:20:32 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Susan Hares , Danny McPherson , Stewart Bryant 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, 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 From idr-bounces@ietf.org Thu Jan 26 21:24:54 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 1F2JIE-0000cI-26; Thu, 26 Jan 2006 21:24:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2JIB-0000c4-Td for idr@megatron.ietf.org; Thu, 26 Jan 2006 21:24:52 -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 VAA27559 for ; Thu, 26 Jan 2006 21:23:19 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2JSD-0003Bw-G2 for idr@ietf.org; Thu, 26 Jan 2006 21:35:16 -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 k0R2Od1Z013907; Thu, 26 Jan 2006 18:24:39 -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 k0R2Oc544878; Thu, 26 Jan 2006 18:24:38 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200601270224.k0R2Oc544878@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46192.1138328678.1@juniper.net> Date: Thu, 26 Jan 2006 18:24:38 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: skh@nexthop.com, Ronald Bonica , Rick Wilder , Ross Callon Subject: [Idr] WG Last Call on draft-ietf-l3vpn-bgpvpn-auto-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, 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 From idr-bounces@ietf.org Fri Jan 27 18:50:48 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 1F2dMe-00046O-Lu; Fri, 27 Jan 2006 18:50:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2dLy-0003u2-4F; Fri, 27 Jan 2006 18:50:06 -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 SAA27053; Fri, 27 Jan 2006 18:48:31 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2dWA-0003ul-T5; Fri, 27 Jan 2006 19:00:39 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F2dLu-000693-A6; Fri, 27 Jan 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: Fri, 27 Jan 2006 18:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2858bis-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: , Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Multiprotocol Extensions for BGP-4 Author(s) : T. Bates, et al. Filename : draft-ietf-idr-rfc2858bis-08.txt Pages : 12 Date : 2006-1-27 Currently BGP-4 is capable of carrying routing information only for IPv4. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-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-rfc2858bis-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-rfc2858bis-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-1-27162442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2858bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2858bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-27162442.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 Tue Jan 31 09:37:19 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 1F3wdD-0006Ke-Sa; Tue, 31 Jan 2006 09:37:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3wcz-0006HR-I8 for idr@megatron.ietf.org; Tue, 31 Jan 2006 09:37:18 -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 JAA21139 for ; Tue, 31 Jan 2006 09:35:21 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3wnp-0005HN-S1 for idr@ietf.org; Tue, 31 Jan 2006 09:48:19 -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 k0VEaD525351; Tue, 31 Jan 2006 06:36:13 -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 k0VEZv561392; Tue, 31 Jan 2006 06:35:57 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200601311435.k0VEZv561392@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17051.1138718157.1@juniper.net> Date: Tue, 31 Jan 2006 06:35:57 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 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, 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 From idr-bounces@ietf.org Tue Jan 31 15:50: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 1F42S8-0006KU-Ez; Tue, 31 Jan 2006 15:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F42Rv-0006Dz-Qp; Tue, 31 Jan 2006 15:50:03 -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 PAA26541; Tue, 31 Jan 2006 15:48:26 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F42cx-0004Vo-1w; Tue, 31 Jan 2006 16:01:27 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F42Rt-0000pw-Li; Tue, 31 Jan 2006 15:50:01 -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, 31 Jan 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: idr@ietf.org Subject: [Idr] I-D ACTION: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 --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 : The AS_PATHLIMIT Path Attribute Author(s) : T. Li, et al. Filename : draft-ietf-idr-as-pathlimit-00.txt Pages : 15 Date : 2006-1-31 This document describes the 'AS path limit' (AS_PATHLIMIT) path attribute for BGP. This is an optional, transitive path attribute that is designed to help limit the distribution of routing information in the Internet. By default, prefixes advertised into the BGP graph are distributed freely, and if not blocked by policy will propagate globally. This is harmful to the scalability of the routing subsystem since information that only has a local effect on routing will cause state creation throughout the default-free zone. This attribute can be attached to a particular path to limit its scope to a subset of the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as-pathlimit-00.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-as-pathlimit-00.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-as-pathlimit-00.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-1-31111044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as-pathlimit-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as-pathlimit-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-31111044.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-- Received: from 135736416 ([211.215.114.35]) by nic.merit.edu (8.9.3/8.9.1) with SMTP id FAA01596 for ; Mon, 23 Jan 2006 05:18:55 -0500 (EST) Received: from smapxsmap.net (135584160 [143960768]) by radiomexico.com (Qmailv2) with ESMTP id 9E1E07381F for ; Mon, 23 Jan 2006 10:16:04 -0800 Date: Mon, 23 Jan 2006 10:16:04 -0800 From: "Roomer L. Decision" X-Mailer: The Bat! (v2.00.2) Personal X-Priority: 3 Message-ID: <0484853410.20060123101604@smapxsmap.net> To: Idr Subject: Adobe Software and more. The best price. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------30F835D3DB4FC61" X-Virus-Scanned: Norton This is a multi-part message in MIME format. ------------30F835D3DB4FC61 Content-Type: text/plain Content-Transfer-Encoding: 7bit http://ttemsh.5ttfautcahbwennyo8n0s5n5.coolishjc.com The cheapest and the best OEM software here! Check up our price-list. Win 2k Professional - $59.95 MS Office 2000 PE (2 CD Edition) - $59.95 Microsoft Office 2000 Premium Edition (2 CD) - $59.95 Office 97 SR2 - $40 GoLive CS - $60 MS SQL Server 2000 Enterprise Edition - $60 Win 2000 Pro - $59.95 Windows 2000 Professional - $59.95 Windows XP Professional With SP2 Full Version - $70 MS Office 2000 PE (2 CD Edition) - $59.95 Microsoft Office 2000 Premium Edition (2 CD) - $59.95 MS Office 2000 Premium Edition (2 CD Edition) - $59.95 Windows 2k Professional - $59.95 Win 95 - $49.95 MS Office 97 SR2 - $49.95 Try to click http://ulwrxsj.c00mh101zoil3uc5vxupzccu.oarlocken.com ------------30F835D3DB4FC61 Content-Type: text/html Content-Transfer-Encoding: 7bit
If you are interested in brands like Microsoft, Macromedia, Adobe, Corel etc.
Examine our reduced price.
Special Offers:
Bundle Special:Dreamwaver MX 2004 + Flash MX 2004$109.95
Bundle Special:Photoshop + Premiere + Illustrator $129.95
Bundle Special:Windows XP Pro With SP2 Full Version + Office 2003 Pro (1 CD Edition)$99.95
Special Offer:MS Windows XP Pro + MS Office XP Pro$89.95
 
Microsoft Windows|R|
Win 98 Second Edition $49.95
Win NT 4.0 Terminal Server$49.95
Win XP Pro$69.95
Win 2000 Pro$59.95
Win Millenium $59.95
Win 2000 Adv. Server $69.95
Win NT 4.0 Server $49.95
Win 98$49.95
Win XP Pro With SP2 Full Version$79.95
Win 95$49.95
 
Microsoft|R| Office:
Office XP Pro$79.95
Office 2k Premium Edition (2 CD Edition)$59.95
Microsoft Visio 2003 Pro$69.95
Office 2003 Pro (1 CD)$89.95
Office 97 SR2$49.95
 
Other Microsoft|c| Software:
MS Project 2003 Pro$69.95
MS Streets and Trips 2004 North America (2 CD Edition)$69.95
MS Picture It Premium 9$59.95
MS Visual Studio .NET Architect Edition (8CD)$139.95
MS SQL Server 2k Enterprise Edition$69.95
MS Plus! XP$59.95
MS Works 7$69.95
MS Encarta Encyclopedia Delux 2004 (3 CD Edition)$89.95
MS Exchange 2003 Enterprise Server$69.95
MS Money 2004$69.95
 
Adobe Software for PC:
Adobe PageMaker 7 (2 CD Edition) $69.95
Adobe Photoshop CS with ImageReady CS $99.95
Adobe Acrobat 6 Professional $79.95
Adobe InDesign CS PageMaker Edition (2 CD Edition) $69.95
Adobe Premiere 7 $69.95
Adobe Illustrator 10 $69.95
Adobe Creative Suite Premium (5 CD) $149.95
Adobe Photoshop Elements 3.0 Win $59.95
Adobe Photoshop 7 $69.95
Adobe Creative Suite Standard (3 CD) $129.95
 
Adobe Software for Mac:
Adobe InDesign CS (Apple Macintosh)$69.95
Adobe Actobat 6 Professional (Apple Macintosh)$79.95
Adobe After Effects 6 (Apple Macintosh)$69.95
Adobe LiveMotion 2 (Apple Macintosh)$69.95
Adobe Illustrator CS CE (Apple Macintosh)$69.95
Adobe Premiere 6.5 (Apple Macintosh)$89.95
Adobe Photoshop CS (Apple Macintosh)$99.95
 
Macromedia Software for PC:
Flash MX 2004$69.95
Freehand MX 11$69.95
Fireworks MX 2004$69.95
Dreamwaver MX 2004$69.95
 
Macromedia Software for Mac:
Macromedia Director MX 2004 (Mac)$69.95
Macromedia Studio MX 2004 with Director MX 2004 (Mac)$139.95
Macromedia Flash MX 2004 (Mac)$69.95
Macromedia Dreamweaver MX 2004 (Mac)$69.95
Macromedia Fireworks MX 2004 (Mac)$69.95
Macromedia FreeHand MX (Mac)$69.95
 
Corel Software:
Photo Painter 8$59.95
Draw Graphics Suite 11$59.95
WordPerfect Office $69.95
 

Follow link
------------30F835D3DB4FC61-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA25850 for ; Thu, 19 Jan 2006 10:07:05 -0500 (EST) 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 1EzbI9-0003G1-DX; Thu, 19 Jan 2006 10:01:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbI8-0003Fw-9o for idr@megatron.ietf.org; Thu, 19 Jan 2006 10:01:36 -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 KAA29176 for ; Thu, 19 Jan 2006 10:00:09 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzbQf-0002Dn-Mu for idr@ietf.org; Thu, 19 Jan 2006 10:10:27 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2006 16:01:25 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0JF0p6C013174; Thu, 19 Jan 2006 16:01:22 +0100 (MET) Received: from xmb-ams-333.cisco.com ([144.254.231.78]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Jan 2006 16:01:09 +0100 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" Subject: RE: [Idr] IDR WG agenda Date: Thu, 19 Jan 2006 16:01:04 +0100 Message-ID: Thread-Topic: [Idr] IDR WG agenda Thread-Index: AcYdAX0aDzOt1n/1So25r2Ed0NO0nQABcnRQ From: "Francois Le Faucheur \(flefauch\)" To: "Yakov Rekhter" , X-OriginalArrivalTime: 19 Jan 2006 15:01:09.0583 (UTC) FILETIME=[2E545DF0:01C61D09] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: idr@ietf.org, "Francois Le Faucheur \(flefauch\)" , "Eric Levy- Abegnoli \(elevyabe\)" , Rajiv Papneja 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id KAA25850 Yakov, Sue, I'd like to request a slot at next IETF to present: draft-levy-idr-6pe-survey-00.txt , "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)- Implementation Report". This document will be posted very shortly. It reports the results of the implementation survey for the 6PE (aka draft-ooms-v6ops-bgp-tunnel-xx). As discussed, this Implementation Report is in line with the Routing Area's procedures, so we can proceed with RFCization of draft-ooms-v6ops-bgp-tunnel. Thank you Francois >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On >> Behalf Of Yakov Rekhter >> Sent: jeudi 19 janvier 2006 15:00 >> To: idr@ietf.org >> Cc: skh@nexthop.com >> Subject: [Idr] IDR WG agenda >> >> Folks, >> >> Its about time to start thinking about agenda items for the next >> IETF. Please forward any IDR agenda items you might have to >> me and Sue. >> >> If you plan to make a presentation, please also keep in mind the >> rule "no document - no time slot". >> >> Sue & 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 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA24816 for ; Thu, 19 Jan 2006 09:10:13 -0500 (EST) 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 1EzaKw-0005xu-B2; Thu, 19 Jan 2006 09:00:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzaKu-0005xZ-B8 for idr@megatron.ietf.org; Thu, 19 Jan 2006 09:00:24 -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 IAA24964 for ; Thu, 19 Jan 2006 08:58:57 -0500 (EST) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzaTR-0000F5-1X for idr@ietf.org; Thu, 19 Jan 2006 09:09:14 -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 k0JE061Z074776; Thu, 19 Jan 2006 06:00:06 -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 k0JE06538375; Thu, 19 Jan 2006 06:00:06 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200601191400.k0JE06538375@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <61444.1137679206.1@juniper.net> Date: Thu, 19 Jan 2006 06:00:06 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: skh@nexthop.com Subject: [Idr] IDR WG agenda 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, Its about time to start thinking about agenda items for the next IETF. Please forward any IDR agenda items you might have to me and Sue. If you plan to make a presentation, please also keep in mind the rule "no document - no time slot". Sue & Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from 143696680 ([218.82.49.183]) by nic.merit.edu (8.9.3/8.9.1) with SMTP id AAA19568 for ; Thu, 19 Jan 2006 00:24:39 -0500 (EST) Received: from u2club.com (141445064 [141602368]) by cinemexicano.com (Qmailv2) with ESMTP id 2EEED11C68 for ; Thu, 19 Jan 2006 05:21:59 -0800 Date: Thu, 19 Jan 2006 05:21:59 -0800 From: "Daemons L. Accretion" X-Mailer: The Bat! (v2.00.7) Personal X-Priority: 3 Message-ID: <1133109299.20060119052159@u2club.com> To: Idr Subject: Looking for a cheap high-quality software? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------7417E2D986318E7" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) This is a multi-part message in MIME format. ------------7417E2D986318E7 Content-Type: text/plain Content-Transfer-Encoding: 7bit http://fgdxl.e71gkjki2ik87wwpfzwr1eew.tableityji.com Looking for cheap licensed software ? Buy OEM and dont think more! Check out our prices. Win XP Professional With SP2 Full Version - $79.95 Microsoft Office 2000 PE (2 CD) - $59.95 Photoshop CS with ImageReady CS - $90 Win 2k Adv. Server - $69.95 MS Visio 2003 Pro - $69.95 Windows 2000 Advanced Server - $60 MS Picture It Premium 9 - $50 Windows XP Pro - $69.95 Illustrator CS CE - $60 Illustrator 10 - $60 Studio MX 2004 with Director MX 2004 - $130 Extensis Portfolio 7.0 - $50 Fireworks MX 2004 - $60 Corel Painter 8 - $50 Office 2000 Premium Edition (2CD) - $50 Try to look http://fgdxl.e71gkjki2ik87wwpfzwr1eew.tableityji.com ------------7417E2D986318E7 Content-Type: text/html Content-Transfer-Encoding: 7bit
Popular software at low prices.
Check our reduced price.
Special Offers:
Bundle Special:Dreamwaver MX 2004 + Flash MX 2004$109.95
Bundle Special:Win XP Professional With SP2 Full Version + Office 2003 Professional (1 CD)$99.95
Bundle Special:Photoshop + Premiere + Illustrator $129.95
Special Offer:MS Win XP Professional + MS Office XP Professional$89.95
 
Microsoft Windows|R|
Windows XP Pro With SP2 Full Version$79.95
Windows 98$49.95
Windows XP Pro$69.95
Windows NT 4.0 Server $49.95
Windows 2000 Advanced Server $69.95
Windows 2000 Pro$59.95
Windows 98 SE $49.95
Windows Millenium $59.95
 
Microsoft|c| Office|R|:
Office XP Pro$79.95
Office 2003 Pro (1 CD)$89.95
Office 2000 Premium Edition (2 CD Edition)$59.95
 
Other Microsoft Software:
Microsoft SQL Server 2k Enterprise Edition$69.95
Microsoft Encarta Encyclopedia Delux 2004 (3 CD)$89.95
Microsoft Plus! XP$59.95
Microsoft Streets and Trips 2004 North America (2 CD)$69.95
Microsoft Visual Studio .NET Architect Edition (8CD)$139.95
Microsoft Project 2003 Pro$69.95
Microsoft Picture It Premium 9$59.95
Microsoft Money 2004$69.95
Microsoft Exchange 2003 Enterprise Server$69.95
Microsoft Works 7$69.95
 
Adobe Software for PC:
Adobe Creative Suite Standard (3 CD) $129.95
Adobe Photoshop CS with ImageReady CS $99.95
Adobe Acrobat 6 Professional $79.95
Adobe PageMaker 7 (2 CD) $69.95
Adobe Creative Suite Premium (5 CD) $149.95
Adobe Illustrator 10 $69.95
Adobe Premiere 7 $69.95
Adobe InDesign CS PageMaker Edition (2 CD) $69.95
Adobe Photoshop 7 $69.95
 
Adobe Software for Mac:
Actobat 6.0 Pro (Apple Macintosh)$79.95
Photoshop CS (Apple Macintosh)$99.95
After Effects 6.0 (Apple Macintosh)$69.95
Premiere 6.5 (Apple Macintosh)$89.95
LiveMotion 2 (Apple Macintosh)$69.95
Illustrator CS CE (Apple Macintosh)$69.95
InDesign CS (Apple Macintosh)$69.95
 
Macromedia Software for PC:
Dreamwaver MX 2004$69.95
Flash MX 2004$69.95
Fireworks MX 2004$69.95
Freehand MX 11$69.95
 
Macromedia Software for Mac:
Macromedia Fireworks MX 2004 (Mac)$69.95
Macromedia FreeHand MX (Mac)$69.95
Macromedia Dreamweaver MX 2004 (Mac)$69.95
Macromedia Director MX 2004 (Mac)$69.95
Macromedia Studio MX 2004 with Director MX 2004 (Mac)$139.95
Macromedia Flash MX 2004 (Mac)$69.95
 
Corel Software:
Corel Draw Graphics Suite 11$59.95
Corel Draw Graphics Suite 11 (Mac)$59.95
Corel Photo Painter 8.0$59.95
Corel WordPerfect Office $69.95
Corel Photo Painter 8.0 (Mac)$59.95
 

Come to site
------------7417E2D986318E7-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA28582 for ; Sun, 15 Jan 2006 12:35:36 -0500 (EST) 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 1EyBfK-0005tv-CP; Sun, 15 Jan 2006 12:27:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyBfE-0005jG-6w for idr@megatron.ietf.org; Sun, 15 Jan 2006 12:27:36 -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 LAA07885 for ; Sun, 15 Jan 2006 11:48:31 -0500 (EST) From: sandy@tislabs.com Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExkxG-0007Wy-3u for idr@ietf.org; Sat, 14 Jan 2006 07:56:27 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0ECm2ch013808 for ; Sat, 14 Jan 2006 07:48:02 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAOza4UA; Sat, 14 Jan 06 07:47:22 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0ECnqoM024568; Sat, 14 Jan 2006 07:49:52 -0500 (EST) Date: Sat, 14 Jan 2006 07:49:52 -0500 (EST) Message-Id: <200601141249.k0ECnqoM024568@tislabs.com> To: idr@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sandy@tislabs.com Subject: [Idr] septuplet birth in idr 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 I haven't seen any mention of the fact on the list, so I thought I'd be the first to congratulate the working group chairs and routing area directors and rfc editors in the emergence of the septuplet set of BGP RFCs after a prolonged confinement. As one of those who were gently nudged, urged, and cattle-proded as needed toward completing the final steps, I want to thank them all. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from -1219017088 ([220.165.62.105]) by nic.merit.edu (8.9.3/8.9.1) with SMTP id HAA16108 for ; Sat, 14 Jan 2006 07:48:18 -0500 (EST) Received: from sesmail.com (-1218936328 [-1218693688]) by leehom.net (Qmailv2) with ESMTP id 90E460FC20 for ; Sat, 14 Jan 2006 12:46:01 -0800 Date: Sat, 14 Jan 2006 12:46:01 -0800 From: "Jam U. Opera" X-Mailer: The Bat! (v2.00.3) Personal X-Priority: 3 Message-ID: <6312915217.20060114124601@sesmail.com> To: Idr Subject: Looking for cheap licensed software ? Buy OEM and dont think more! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------54109C434D83312" X-RAV-Antivirus: This e-mail has been scanned for viruses on host: leehom.net This is a multi-part message in MIME format. ------------54109C434D83312 Content-Type: text/plain Content-Transfer-Encoding: 7bit http://vwpfroi.qfv2vue3dzdk18q1rbqld888.circuitynb.com Want to work stable? You need to buy licensed WINDOWS. Please check our reduced price. Win 2000 Advanced Server - $69.95 Quark Xpress 6 Passport Multilanguage - $60 Photoshop CS with ImageReady CS - $90 Microsoft Office 2k PE (2 CD) - $59.95 Illustrator CS CE - $60 Win 95 - $49.95 Flash MX 2004 - $60 Norton System Works 2003 - $50 Win XP Pro With SP2 Full Version - $79.95 MS Visio 2003 Professional - $69.95 MS Office 2000 PE (2 CD Edition) - $59.95 Norton System Works 2003 - $50 Windows 2000 Professional - $50 PageMaker 7 (2CD) - $60 PageMaker 7 (2CD) - $60 Check it http://knd.4tryr8azrdryxm4f57mh94m4.passkeyih.com ------------54109C434D83312 Content-Type: text/html Content-Transfer-Encoding: 7bit
YAHOO software news
Please check our reduced price.
Special Offers:
Special Offer:Microsoft Windows XP Pro + Microsoft Office XP Pro$89.95
Bundle Special:Dreamwaver MX 2004 + Flash MX 2004$109.95
Bundle Special:Windows XP Pro With SP2 Full Version + Office 2003 Pro (1 CD)$99.95
Bundle Special:Photoshop + Premiere + Illustrator $129.95
 
Microsoft Windows
Windows XP Pro$69.95
Windows 98 SE $49.95
Windows XP Pro With SP2 Full Version$79.95
Windows 2k Pro$59.95
Windows Millenium $59.95
Windows NT 4.0 Server $49.95
Windows 2k Adv. Server $69.95
 
Microsoft Office:
FileMaker 7.0 Pro$69.95
Office 2003 Pro (1 CD Edition)$89.95
Microsoft Visio 2003 Pro$69.95
Office 97 SR2$49.95
Office 2k PE (2 CD Edition)$59.95
Office XP Pro$79.95
 
Other Microsoft Software:
MS Works 7$69.95
MS Money 2004$69.95
MS Visual Studio .NET Architect Edition (8CD)$139.95
MS Exchange 2003 Enterprise Server$69.95
MS Picture It Premium 9$59.95
MS Plus! XP$59.95
MS Encarta Encyclopedia Delux 2004 (3 CD Edition)$89.95
MS Streets and Trips 2004 North America (2 CD)$69.95
MS Project 2003 Professional$69.95
MS SQL Server 2k Enterprise Edition$69.95
 
Adobe Software for PC:
PageMaker 7 (2 CD Edition) $69.95
Premiere 7 $69.95
Creative Suite Standard (3 CD) $129.95
Creative Suite Premium (5 CD) $149.95
InDesign CS PageMaker Edition (2 CD Edition) $69.95
Acrobat 6 Pro $79.95
Photoshop CS with ImageReady CS $99.95
Photoshop 7 $69.95
 
Adobe Software for Mac:
InDesign CS (Apple Macintosh)$69.95
Actobat 6 Pro (Apple Macintosh)$79.95
LiveMotion 2 (Apple Macintosh)$69.95
Illustrator CS CE (Apple Macintosh)$69.95
Premiere 6.5 (Apple Macintosh)$89.95
After Effects 6 (Apple Macintosh)$69.95
Photoshop CS (Apple Macintosh)$99.95
 
Macromedia Software for PC:
Macromedia Dreamwaver MX 2004$69.95
Macromedia Fireworks MX 2004$69.95
Macromedia Freehand MX 11$69.95
Macromedia Flash MX 2004$69.95
 
Macromedia Software for Mac:
Macromedia Fireworks MX 2004 (Apple Macintosh)$69.95
Macromedia FreeHand MX (Apple Macintosh)$69.95
Macromedia Studio MX 2004 with Director MX 2004 (Apple Macintosh)$139.95
Macromedia Dreamweaver MX 2004 (Apple Macintosh)$69.95
Macromedia Director MX 2004 (Apple Macintosh)$69.95
Macromedia Flash MX 2004 (Apple Macintosh)$69.95
 
Corel Software:
Photo Painter 8.0$59.95
WordPerfect Office $69.95
Draw Graphics Suite 11 (Mac)$59.95
Photo Painter 8.0 (Mac)$59.95
Draw Graphics Suite 11$59.95
 

Link bellow
------------54109C434D83312-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA08955 for ; Fri, 13 Jan 2006 16:45:13 -0500 (EST) 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 1ExWh2-0002Pu-7D; Fri, 13 Jan 2006 16:42:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWh1-0002Pj-3M for idr@megatron.ietf.org; Fri, 13 Jan 2006 16:42:43 -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 QAA13696 for ; Fri, 13 Jan 2006 16:41:20 -0500 (EST) From: sandy@tislabs.com Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExWoN-0006CB-Ir for idr@ietf.org; Fri, 13 Jan 2006 16:50:21 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0DLg83K006858 for ; Fri, 13 Jan 2006 16:42:08 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAyAaWyn; Fri, 13 Jan 06 16:42:05 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0DLiZOs029038; Fri, 13 Jan 2006 16:44:35 -0500 (EST) Date: Fri, 13 Jan 2006 16:44:35 -0500 (EST) Message-Id: <200601132144.k0DLiZOs029038@tislabs.com> To: idr@ietf.org Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sandy@tislabs.com 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 >That is true. However, as there are no proposed mechanisms for >AS_PATH, I don't see much point in arguing about whether the >not-yet-proposed semantics are sufficient or not. I know of at least 5, with two of them generalized in the BGP security requirements draft. Some of those match semantics you might choose, some of them do not, depending on what you choose. >For one example, if an >AS attaches AS_PATHLIMIT, I would like to know that the AS number >that it attaches is its AS number and no other. That's good. And then there's more to discuss from there. >As such, I would prefer >to discuss them as part of RPSEC. I would recommend starting the discussion now. The scenario to avoid is: idr to security/rpsec: OK, we've done with the draft. Now tell us how to secure it. security/rpsec to idr: Oh, we see you made the design choice that is really, really hard to protect. Too bad. idr to security/rpsec: Why can't you people ever come up with a deployable security solution!! --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07609 for ; Fri, 13 Jan 2006 13:55:48 -0500 (EST) 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 1ExU1c-00013R-KG; Fri, 13 Jan 2006 13:51:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExU1a-00013J-Fl for idr@megatron.ietf.org; Fri, 13 Jan 2006 13:51:46 -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 NAA28427 for ; Fri, 13 Jan 2006 13:50:24 -0500 (EST) Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExU8x-00070w-5E for idr@ietf.org; Fri, 13 Jan 2006 13:59:23 -0500 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id CC7121B84; Fri, 13 Jan 2006 18:51:20 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 954kamszT0017Mo1; Fri, 13 Jan 2006 18:51:19 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 952kamszq0472Mo1; Fri, 13 Jan 2006 18:51:17 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.27I); Fri, 13 Jan 2006 18:51:17 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID094kamszR1327Xo1 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by GW2.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 11:51:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Idr] Next revision of AS_HOPCOUNT Date: Fri, 13 Jan 2006 11:51:10 -0700 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F0202DAA753@VS4.EXCHPROD.USA.NET> Thread-Topic: [Idr] Next revision of AS_HOPCOUNT Thread-Index: AcYYcYbXxop6ipkHTGiizz6fW+Ec6QAACphw From: "Susan Hares" To: "Tony Li" , "John Leslie" X-OriginalArrivalTime: 13 Jan 2006 18:51:13.0764 (UTC) FILETIME=[53C8BA40:01C61872] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA07609 Guys: Sorry for the kafka-esque feeling. We had agreement 20-30 people the work group on the last draft that it was useful work. And no one strongly objected. Just floating by the changes to those same parties to make sure we're still on-track is the goal. And to make sure new objections don't get too strong. Don't get too bound up in the process. If it aids, we can just send a note to all those who agreed previous and go from there. I or Tony can do that and publish the results to the list. Cheers, Sue Hares Co-chair -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Tony Li Sent: Friday, January 13, 2006 1:42 PM To: John Leslie Cc: idr@ietf.org Subject: Re: [Idr] Next revision of AS_HOPCOUNT > Will somebody please own up to telling Tony he may not publish the > revised draft to the list? This was the directive of our esteemed chairs. Apparently this is now the modus operandi of the IETF when one wants to re-architect a draft. > This is taking on a Kafka-esque feeling that we're expected to > agree we have consensus on something before we're allowed to find > out what it is we're consenting to. I wholeheartedly agree. Furthermore, I'm trying to play by the rules as stated, which for those that know me, adds to the surreal tableau. ;-) 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 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07564 for ; Fri, 13 Jan 2006 13:46:43 -0500 (EST) 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 1ExTt7-0006oh-C4; Fri, 13 Jan 2006 13:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTt6-0006oE-Bk for idr@megatron.ietf.org; Fri, 13 Jan 2006 13:43:00 -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 NAA27824 for ; Fri, 13 Jan 2006 13:41:38 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExU0S-0006gp-4v for idr@ietf.org; Fri, 13 Jan 2006 13:50:37 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2006011318423101100dg33ve>; Fri, 13 Jan 2006 18:42:42 +0000 In-Reply-To: <20060113180456.GD89985@verdi> References: <200601122320.k0CNKYLx013759@tislabs.com> <20060113180456.GD89985@verdi> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <88A63304-9B44-4957-B358-E617A73147A0@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Fri, 13 Jan 2006 10:42:01 -0800 To: John Leslie X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 > Will somebody please own up to telling Tony he may not publish the > revised draft to the list? This was the directive of our esteemed chairs. Apparently this is now the modus operandi of the IETF when one wants to re-architect a draft. > This is taking on a Kafka-esque feeling that we're expected to > agree we have consensus on something before we're allowed to find > out what it is we're consenting to. I wholeheartedly agree. Furthermore, I'm trying to play by the rules as stated, which for those that know me, adds to the surreal tableau. ;-) Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07246 for ; Fri, 13 Jan 2006 13:06:54 -0500 (EST) 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 1ExTIY-0006IC-3r; Fri, 13 Jan 2006 13:05:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTIV-0006HH-Sy for idr@megatron.ietf.org; Fri, 13 Jan 2006 13:05:11 -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 NAA25667 for ; Fri, 13 Jan 2006 13:03:50 -0500 (EST) Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExTPp-0005TF-ET for idr@ietf.org; Fri, 13 Jan 2006 13:12:48 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id E1CB5E0438; Fri, 13 Jan 2006 13:04:56 -0500 (EST) Date: Fri, 13 Jan 2006 13:04:56 -0500 From: John Leslie To: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Message-ID: <20060113180456.GD89985@verdi> References: <200601122320.k0CNKYLx013759@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Tony Li wrote: >>> Please see section 5.2. We clearly state that AS_HOPCOUNT may >>> be used in a proxy fashion. >> > Sandy, > >> Should the text I quoted from elsewhere in the document be >> modified to be consistent? > > Please see the revised version when I am permitted to post it. If you > have comments on that version, then we should discuss them. Will somebody please own up to telling Tony he may not publish the revised draft to the list? This is taking on a Kafka-esque feeling that we're expected to agree we have consensus on something before we're allowed to find out what it is we're consenting to. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA07139 for ; Fri, 13 Jan 2006 12:51:15 -0500 (EST) 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 1ExT42-0002WA-14; Fri, 13 Jan 2006 12:50:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExT41-0002Vi-0d for idr@megatron.ietf.org; Fri, 13 Jan 2006 12:50:13 -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 MAA24788 for ; Fri, 13 Jan 2006 12:48:51 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExTBM-0004vD-5g for idr@ietf.org; Fri, 13 Jan 2006 12:57:49 -0500 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ExT3O-0007zR-D6; Fri, 13 Jan 2006 17:49:34 +0000 In-Reply-To: <037901c6185b$39938ea0$0601a8c0@pc6> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <037901c6185b$39938ea0$0601a8c0@pc6> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Fri, 13 Jan 2006 12:49:32 -0500 To: Tom Petch X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Tony Li 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 On 13-Jan-2006, at 09:53, Tom Petch wrote: >> - Completely remove the interaction with NO_EXPORT. > > Not sure that this is completely possible; to take the view that > any reason not > to advertise means do not advertise is a form of interaction, which > might > conflict with the use of AS_PATHLIMIT (no, I haven't got a concrete > example of > when this would happen) I think what Tony meant by his sentence above was that the interaction specified in draft-idr-as-hopcount-00 would be removed as part of this revision. No greater philosophical message should be inferred :-) Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA06815 for ; Fri, 13 Jan 2006 12:10:34 -0500 (EST) 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 1ExSQJ-0007fa-Dq; Fri, 13 Jan 2006 12:09:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExSQH-0007fV-G9 for idr@megatron.ietf.org; Fri, 13 Jan 2006 12:09:09 -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 MAA22259 for ; Fri, 13 Jan 2006 12:07:45 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExSXc-0003aa-20 for idr@ietf.org; Fri, 13 Jan 2006 12:16:44 -0500 Received: from pc6 (1Cust90.tnt104.lnd4.gbr.da.uu.net [213.116.56.90]) by ranger.systems.pipex.net (Postfix) with SMTP id 66950E000120; Fri, 13 Jan 2006 17:08:48 +0000 (GMT) Message-ID: <037901c6185b$39938ea0$0601a8c0@pc6> From: "Tom Petch" To: "Inter-Domain Routing List" , "Tony Li" References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Fri, 13 Jan 2006 15:53:01 +0100 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch 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 ----- Original Message ----- From: "Tony Li" To: "Inter-Domain Routing List" Sent: Tuesday, January 10, 2006 9:35 PM Subject: [Idr] Next revision of AS_HOPCOUNT > > Based on the discussion that we've had so far, the authors of the > AS_HOPCOUNT draft would > like to make some substantive changes to the draft. The chairs have > asked that we poll you to > ensure that we have rough consensus on the new direction. The > primary technical points of > these changes: > > - Convert AS_HOPCOUNT from being decremented at each AS boundary and > instead have it be a static upper bound on the AS path length. > Yes, I think that is absolutely right. Decrementing counts was fine when the community was smaller and closer knit, more trustworthy perhaps. In the present heterogeneous world, I think static upper bound the right approach. It is also easier to secure whatever form security ultimately takes. > - Rename the attribute to AS_PATHLIMIT. > Fits in with the abouve > - Completely remove the interaction with NO_EXPORT. > Not sure that this is completely possible; to take the view that any reason not to advertise means do not advertise is a form of interaction, which might conflict with the use of AS_PATHLIMIT (no, I haven't got a concrete example of when this would happen) Tom Petch. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA05699 for ; Fri, 13 Jan 2006 09:36:11 -0500 (EST) 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 1ExPzm-0007Hc-9o; Fri, 13 Jan 2006 09:33:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExPzk-0007HX-Of for idr@megatron.ietf.org; Fri, 13 Jan 2006 09:33:36 -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 JAA09647 for ; Fri, 13 Jan 2006 09:32:14 -0500 (EST) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExQ72-0005fY-3L for idr@ietf.org; Fri, 13 Jan 2006 09:41:11 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id 153431B0B; Fri, 13 Jan 2006 14:33:14 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 644kamohN0170Mo2; Fri, 13 Jan 2006 14:33:13 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 641kamohL0038Mo2; Fri, 13 Jan 2006 14:33:11 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Fri, 13 Jan 2006 14:33:11 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID237kamohL4366Xo2 Received: from localhost ([65.247.36.31]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 07:33:11 -0700 Date: Fri, 13 Jan 2006 09:33:10 -0500 From: Jeffrey Haas To: sandy@tislabs.com Subject: Re: [Idr] Next revision of AS_HOPCOUNT Message-ID: <20060113143310.GY22020@nexthop.com> References: <200601122320.k0CNKYLx013759@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601122320.k0CNKYLx013759@tislabs.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 13 Jan 2006 14:33:11.0286 (UTC) FILETIME=[47821160:01C6184E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 On Thu, Jan 12, 2006 at 06:20:34PM -0500, sandy@tislabs.com wrote: > You imply you think that there is integrity required. But the > conclusion I've reached from other email is that people want any > AS to be allowed to strip, replace, or modify the HOPCOUNT/PATHLIMIT. > What sort of integrity do you see that would still allow that? I may be misusing security taxonomy, but I think the property we'd be interested in for this case is accountability. Knowing who made the change is often a good start to take some form of action when someone acts contrary to your expectations. > --Sandy -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA28620 for ; Thu, 12 Jan 2006 19:06:51 -0500 (EST) 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 1ExCRY-0005JX-Ao; Thu, 12 Jan 2006 19:05:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExCRW-0005J1-Ll for idr@megatron.ietf.org; Thu, 12 Jan 2006 19:05:22 -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 TAA09972 for ; Thu, 12 Jan 2006 19:04:01 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExCYf-0001mA-6O for idr@ietf.org; Thu, 12 Jan 2006 19:12:49 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2006011300044301100dch52e>; Fri, 13 Jan 2006 00:04:45 +0000 In-Reply-To: <200601122320.k0CNKYLx013759@tislabs.com> References: <200601122320.k0CNKYLx013759@tislabs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Thu, 12 Jan 2006 16:04:41 -0800 To: sandy@tislabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Sandy, >> Please see section 5.2. We clearly state that AS_HOPCOUNT may >> be used in a proxy fashion. > > Should the text I quoted from elsewhere in the document be > modified to be consistent? Please see the revised version when I am permitted to post it. If you have comments on that version, then we should discuss them. > But whichever modification rule for AS_PATH you follow, there > may not be sufficient match to the semantics of the HOPCOUNT/PATHLIMIT > to make the security protections for AS_PATH also protect the > HOPCOUNT/PATHLIMIT. That is true. However, as there are no proposed mechanisms for AS_PATH, I don't see much point in arguing about whether the not-yet-proposed semantics are sufficient or not. > You imply you think that there is integrity required. But the > conclusion I've reached from other email is that people want any > AS to be allowed to strip, replace, or modify the HOPCOUNT/PATHLIMIT. > What sort of integrity do you see that would still allow that? > (Question, not dig. Really - what integrity requirement do you see? > Limitation on who could strip/replacy/modify?) Well, as I tried to point out, I think that you're leaping to all sorts of conclusions, mostly unwarranted. With regard to AS_PATHLIMIT, I would like to see several properties. For one example, if an AS attaches AS_PATHLIMIT, I would like to know that the AS number that it attaches is its AS number and no other. There are a number of other security properties that I would like to see, but again, they are general properties that should be applicable to all BGP path attributes, not just AS_PATHLIMIT. As such, I would prefer to discuss them as part of RPSEC. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA28270 for ; Thu, 12 Jan 2006 18:23:37 -0500 (EST) 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 1ExBiK-000737-Ms; Thu, 12 Jan 2006 18:18:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBiJ-000732-2O for idr@megatron.ietf.org; Thu, 12 Jan 2006 18:18:39 -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 SAA04613 for ; Thu, 12 Jan 2006 18:17:18 -0500 (EST) From: sandy@tislabs.com Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExBpU-0007xW-H5 for idr@ietf.org; Thu, 12 Jan 2006 18:26:05 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0CNI7mW021712 for ; Thu, 12 Jan 2006 18:18:07 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAlVaOzQ; Thu, 12 Jan 06 18:18:05 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0CNKYLx013759; Thu, 12 Jan 2006 18:20:34 -0500 (EST) Date: Thu, 12 Jan 2006 18:20:34 -0500 (EST) Message-Id: <200601122320.k0CNKYLx013759@tislabs.com> To: sandy@tislabs.com, tony.li@tony.li Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 >Please see section 5.2. We clearly state that AS_HOPCOUNT may >be used in a proxy fashion. Should the text I quoted from elsewhere in the document be modified to be consistent? >I believe that it's a rush to the other side of the spectrum to say that >no integrity security is needed. There are a number of mutable >attributes necessary for fully functioning BGP (e.g., AS_PATH, >communities). Hopefully whatever solution RPSEC selects to >protect these attributes will also be useable for AS_HOPCOUNT or >AS_PATHLIMIT. The AS_PATH is mutable, but the decision of what mutations are permitted is one of the stumbling blocks in determining a solution. If you go by the "MUST/MUST NOT" in the bgp spec, you come up with one idea of what is permitted. If you go by the what vendors allow you to configure your routers to do, you come up with a much different idea of what is permitted. But whichever modification rule for AS_PATH you follow, there may not be sufficient match to the semantics of the HOPCOUNT/PATHLIMIT to make the security protections for AS_PATH also protect the HOPCOUNT/PATHLIMIT. You imply you think that there is integrity required. But the conclusion I've reached from other email is that people want any AS to be allowed to strip, replace, or modify the HOPCOUNT/PATHLIMIT. What sort of integrity do you see that would still allow that? (Question, not dig. Really - what integrity requirement do you see? Limitation on who could strip/replacy/modify?) --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA28166 for ; Thu, 12 Jan 2006 18:04:26 -0500 (EST) 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 1ExBQp-0000yD-Kj; Thu, 12 Jan 2006 18:00:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBQo-0000y8-Pn for idr@megatron.ietf.org; Thu, 12 Jan 2006 18:00:34 -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 RAA03271 for ; Thu, 12 Jan 2006 17:59:14 -0500 (EST) Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExBY0-0007K1-6H for idr@ietf.org; Thu, 12 Jan 2006 18:08:01 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with SMTP id <2006011223001401400f2h83e>; Thu, 12 Jan 2006 23:00:15 +0000 In-Reply-To: <200601121507.k0CF782A023718@tislabs.com> References: <200601121507.k0CF782A023718@tislabs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7628B617-9CAF-4A87-B26D-766D60B4CE03@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Thu, 12 Jan 2006 15:00:11 -0800 To: sandy@tislabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 > If the PATHLIMIT is intended to be mutable, then the conversation > can cease here and you don't need to take anything to RPSEC - > if the intent is to let anyone modify the attribute in any way, > there there is no integrity security needed. > > Making that clear in the spec would, IMHO, a good thing. > It would be easy to read "PATHLIMIT" and "MUST advertise > an AS_HOPCOUNT atribute of one less than the value received" > and "If the attribute value is zero, the path MUST be ignored > without further processing" and think something more deterministic > was going on than a mutable attribute that was advice only. Please see section 5.2. We clearly state that AS_HOPCOUNT may be used in a proxy fashion. I believe that it's a rush to the other side of the spectrum to say that no integrity security is needed. There are a number of mutable attributes necessary for fully functioning BGP (e.g., AS_PATH, communities). Hopefully whatever solution RPSEC selects to protect these attributes will also be useable for AS_HOPCOUNT or AS_PATHLIMIT. > > The entire issue of what RPSEC will >> protect, how it can protect mutable attributes and not force a full >> re-engineering >> of the entire Internet is NOT something that we should be solving >> here. > > RPSEC is charged with threat models and security analysis and > requirements, with "routing protocol designers" charged with > using the RPSEC products to ensure security in their protocols. > At least, that's what the charter says now. Hopefully someone, somewhere will actually have responsibility for coming up with some actual, workable security mechanisms and specifications for implementations that still provide inter-domain routing functionality in a manner that is actually useful and deployable sometime before the heat death of the universe. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA23928 for ; Thu, 12 Jan 2006 10:08:46 -0500 (EST) 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 1Ex41M-0005j5-3v; Thu, 12 Jan 2006 10:05:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex41K-0005i6-JS for idr@megatron.ietf.org; Thu, 12 Jan 2006 10:05:46 -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 KAA23296 for ; Thu, 12 Jan 2006 10:04:25 -0500 (EST) From: sandy@tislabs.com Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex48O-0006l8-Rk for idr@ietf.org; Thu, 12 Jan 2006 10:13:09 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0CF5D4q001946 for ; Thu, 12 Jan 2006 10:05:13 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAATTaONd; Thu, 12 Jan 06 10:04:39 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0CF782A023718; Thu, 12 Jan 2006 10:07:08 -0500 (EST) Date: Thu, 12 Jan 2006 10:07:08 -0500 (EST) Message-Id: <200601121507.k0CF782A023718@tislabs.com> To: sandy@tislabs.com, tony.li@tony.li Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 >Can we please take it to RPSEC? >... >PATHLIMIT is certainly intended to be one of those mutable attributes, >either because it is being decrement, applied by proxy, or both. If the PATHLIMIT is intended to be mutable, then the conversation can cease here and you don't need to take anything to RPSEC - if the intent is to let anyone modify the attribute in any way, there there is no integrity security needed. Making that clear in the spec would, IMHO, a good thing. It would be easy to read "PATHLIMIT" and "MUST advertise an AS_HOPCOUNT atribute of one less than the value received" and "If the attribute value is zero, the path MUST be ignored without further processing" and think something more deterministic was going on than a mutable attribute that was advice only. >The entire issue of what RPSEC will >protect, how it can protect mutable attributes and not force a full >re-engineering >of the entire Internet is NOT something that we should be solving here. RPSEC is charged with threat models and security analysis and requirements, with "routing protocol designers" charged with using the RPSEC products to ensure security in their protocols. At least, that's what the charter says now. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from -1212964096 ([61.180.32.198]) by nic.merit.edu (8.9.3/8.9.1) with SMTP id IAA23165 for ; Thu, 12 Jan 2006 08:28:51 -0500 (EST) Received: from notimexico.com (-1209158184 [-1209888160]) by news.com (Qmailv2) with ESMTP id F9A657DA0A for ; Thu, 12 Jan 2006 13:26:22 -0800 Date: Thu, 12 Jan 2006 13:26:22 -0800 From: "Sass S. Spoonerism" X-Mailer: The Bat! (v2.00.5) Personal X-Priority: 3 Message-ID: <4662106856.20060112132622@notimexico.com> To: Idr Subject: Popular software at low prices. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------D29081C24196FE5" X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) This is a multi-part message in MIME format. ------------D29081C24196FE5 Content-Type: text/plain Content-Transfer-Encoding: 7bit Please visit our OEM software supertore! Check out our price-list. Windows 2000 Adv. Server - $69.95 Dreamweaver MX 2004 - $60 Win XP Professional - $69.95 Microsoft Office 2000 Premium Edition (2 CD Edition) - $59.95 Microsoft Office 2003 Professional (1 CD Edition) - $89.95 Win NT 4.0 Terminal Server - $49.95 Windows XP Pro - $69.95 Corel Draw Graphics Suite 11 - $50 Illustrator 10 - $60 Microsoft Office 2000 Premium Edition (2 CD) - $59.95 Windows 98 Second Edition - $49.95 Office 2000 Premium Edition (2CD) - $50 Fireworks MX 2004 - $60 Windows 2000 Professional - $59.95 Win 2000 Advanced Server - $69.95 Press link ------------D29081C24196FE5 Content-Type: text/html Content-Transfer-Encoding: 7bit
The cheapest and the best OEM software here!
Please check our reduced price.
Special Offers:
Bundle Special:Photoshop + Premiere + Illustrator $129.95
Bundle Special:Macromedia Dreamwaver MX 2004 + Macromedia Flash MX 2004$109.95
Bundle Special:MS Win XP Pro + MS Office XP Pro$89.95
Bundle Special:Win XP Pro With SP2 Full Version + Office 2003 Pro (1 CD Edition)$99.95
 
Microsoft Windows|R|
Win Millenium $59.95
Win 2000 Pro$59.95
Win 98 Second Edition $49.95
Win XP Pro$69.95
Win 2000 Adv. Server $69.95
Win XP Pro With SP2 Full Version$79.95
Win NT 4.0 Server $49.95
 
Microsoft|R| Office|R|:
MS Visio 2003 Professional$69.95
FileMaker 7.0 Professional$69.95
Office XP Professional$79.95
Office 97 SR2$49.95
Office 2003 Professional (1 CD Edition)$89.95
Office 2k Premium Edition (2 CD)$59.95
 
Other Microsoft Software:
Microsoft SQL Server 2k Enterprise Edition$69.95
Microsoft Works 7$69.95
Microsoft Picture It Premium 9$59.95
Microsoft Project 2003 Pro$69.95
Microsoft Exchange 2003 Enterprise Server$69.95
Microsoft Visual Studio .NET Architect Edition (8CD)$139.95
Microsoft Plus! XP$59.95
Microsoft Money 2004$69.95
Microsoft Streets and Trips 2004 North America (2 CD)$69.95
Microsoft Encarta Encyclopedia Delux 2004 (3 CD Edition)$89.95
 
Adobe Software for PC:
InDesign CS PageMaker Edition (2 CD Edition) $69.95
Photoshop CS with ImageReady CS $99.95
Creative Suite Premium (5 CD Edition) $149.95
Acrobat 6 Professional $79.95
Photoshop 7 $69.95
Creative Suite Standard (3 CD Edition) $129.95
PageMaker 7 (2 CD Edition) $69.95
Premiere 7 $69.95
 
Adobe Software for Mac:
Adobe LiveMotion 2.0 (Apple Macintosh)$69.95
Adobe Actobat 6.0 Professional (Apple Macintosh)$79.95
Adobe After Effects 6.0 (Apple Macintosh)$69.95
Adobe Premiere 6.5 (Apple Macintosh)$89.95
Adobe Illustrator CS CE (Apple Macintosh)$69.95
Adobe InDesign CS (Apple Macintosh)$69.95
Adobe Photoshop CS (Apple Macintosh)$99.95
 
Macromedia Software for PC:
Macromedia Fireworks MX 2004$69.95
Macromedia Dreamwaver MX 2004$69.95
Macromedia Freehand MX 11$69.95
Macromedia Flash MX 2004$69.95
 
Macromedia Software for Mac:
Fireworks MX 2004 (Apple Macintosh)$69.95
Director MX 2004 (Apple Macintosh)$69.95
Dreamweaver MX 2004 (Apple Macintosh)$69.95
FreeHand MX (Apple Macintosh)$69.95
Studio MX 2004 with Director MX 2004 (Apple Macintosh)$139.95
Flash MX 2004 (Apple Macintosh)$69.95
 
Corel Software:
Draw Graphics Suite 11.0$59.95
Photo Painter 8$59.95
WordPerfect Office $69.95
 

Try to look
------------D29081C24196FE5-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA16921 for ; Wed, 11 Jan 2006 19:16:25 -0500 (EST) 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 1Ewq8Y-0004Ib-7W; Wed, 11 Jan 2006 19:16:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewq8V-0004HP-S8 for idr@megatron.ietf.org; Wed, 11 Jan 2006 19:16:16 -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 TAA29334 for ; Wed, 11 Jan 2006 19:14:55 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwqFV-0006XM-7C for idr@ietf.org; Wed, 11 Jan 2006 19:23:30 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc13) with SMTP id <2006011200160201300o7klse>; Thu, 12 Jan 2006 00:16:03 +0000 In-Reply-To: <20060111153303.GB22020@nexthop.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <20060110223708.GB12691@nexthop.com> <20060111153303.GB22020@nexthop.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 16:16:00 -0800 To: Jeffrey Haas X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 Jeff, > I would definitely like to see more language about how we do the > counting. Absolute path length seems to be the wrong choice. I > think that > Russ's verbiage about distinct ASes is close. I'd suggest that > we count any recurring adjacent sequences of an AS in one or more > AS_SEQUENCEs as length 1 and simply count an entire AS_SET, regardless > of content, as length 1. > > Ergo: > > 1 1 1 2 3 3 2 [5 6 7] > > would count as length 5. Yes, there's an intentional loop in there. Well, the language that I'm proposing is slightly different in intent and result. Regardless, when the revised draft is issued, I'd welcome alternate proposals and contributions of specific language that capture WG consensus. > This is somewhat problematic when dealing with a 2 byte speaker > with AS_TRANS in the AS_PATH. Without peeking into the NEW_AS_PATH, > you can't tell if multiple occurrences are distinct ASes or not. This > affects how I'd expect path length counting to occur. Good point. Let's also put that on the agenda. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA16852 for ; Wed, 11 Jan 2006 19:12:02 -0500 (EST) 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 1Ewq3V-000249-Dp; Wed, 11 Jan 2006 19:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewq3T-00021y-TP for idr@megatron.ietf.org; Wed, 11 Jan 2006 19:11:03 -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 TAA28948 for ; Wed, 11 Jan 2006 19:09:43 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwqAS-0006MX-0M for idr@ietf.org; Wed, 11 Jan 2006 19:18:17 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2006011200103801100dk3c9e>; Thu, 12 Jan 2006 00:10:38 +0000 In-Reply-To: <200601111827.k0BIRhbf000350@tislabs.com> References: <200601111827.k0BIRhbf000350@tislabs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 16:10:36 -0800 To: sandy@tislabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 On Jan 11, 2006, at 10:27 AM, sandy@tislabs.com wrote: > W-e-e-l-l. Tony says that those routers who attach this attribute > could have used "normal policy mechanisms" to filter out the route. > But I thought the whole point was that normal policy mechanisms > did not provide the control desired. The point is that this does not create a new security hole, as manually configured route filters could result in the same restrictions on propagation today, but would require TONS more coordination and other management hair. Thus, the new attribute does not make the security situation appreciably worse than it is today. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA16839 for ; Wed, 11 Jan 2006 19:04:47 -0500 (EST) 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 1Ewpue-0004Ie-Ce; Wed, 11 Jan 2006 19:01:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewpuc-0004Hk-ID for idr@megatron.ietf.org; Wed, 11 Jan 2006 19:01: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 TAA27270 for ; Wed, 11 Jan 2006 19:00:34 -0500 (EST) Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewq1Z-0005gr-Sr for idr@ietf.org; Wed, 11 Jan 2006 19:09:09 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with SMTP id <2006011200013601400evknfe>; Thu, 12 Jan 2006 00:01:37 +0000 In-Reply-To: <200601112148.k0BLmwiX009305@tislabs.com> References: <200601112148.k0BLmwiX009305@tislabs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 16:01:34 -0800 To: sandy@tislabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Ok, this conversation, while interesting, is getting more than a wee bit off topic. Can we please take it to RPSEC? The entire issue of what RPSEC will protect, how it can protect mutable attributes and not force a full re-engineering of the entire Internet is NOT something that we should be solving here. PATHLIMIT is certainly intended to be one of those mutable attributes, either because it is being decrement, applied by proxy, or both. Tony On Jan 11, 2006, at 1:48 PM, sandy@tislabs.com wrote: >> The draft specifies the required behaviour for an implementation in >> the case where the attribute is present. Those requirements are >> orthogonal to whether or not an operator of an AS decides to >> implement policy which removes particular attributes which were added >> elsewhere. > > Sounds to me like you are quibbling - if the AS removes the > attribute and creates a new lookalike with a value that would > not follow the spec, then it is OK. > > I don't think "this isn't a modification, it is a deletion and > insertion" is necessarily always justified. > > Or maybe you don't realize that I'm talking about changing the > value in an existing attribute. > > So - suppose you create a PATHLIMIT of 4 and *two* hops away, > someone changes the limit to 15? I.E., not a new attribute, > keeping your AS number in the attribute and all that. Is that > still OK with you? If we're talking about HOPCOUNT, if you > create a HOPCOUNT of 4 and two hops away someone adds 6? > Still OK? These aren't at the limit you've specified for the > propagation of the route, the changes are somewhere along the way. > > --Sandy > > _______________________________________________ > 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 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA15779 for ; Wed, 11 Jan 2006 16:53:27 -0500 (EST) 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 1EwnpR-0006GB-QA; Wed, 11 Jan 2006 16:48:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwnpQ-0006G6-H6 for idr@megatron.ietf.org; Wed, 11 Jan 2006 16:48:24 -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 QAA16784 for ; Wed, 11 Jan 2006 16:47:02 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwnwP-000136-JI for idr@ietf.org; Wed, 11 Jan 2006 16:55:37 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id E124A642D4 for ; Wed, 11 Jan 2006 14:48:09 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601112039.k0BKd1L6006109@tislabs.com> References: <200601112039.k0BKd1L6006109@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8D5829D6-668C-43BC-84AC-05EF6C41B83E@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 14:48:24 -0700 To: Inter-Domain Routing List X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit 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 On Jan 11, 2006, at 1:39 PM, sandy@tislabs.com wrote: >>> As I understand it, the NO_EXPORT attribute is intended just >>> for your immediate neighbor, and is not supposed to be propagated >>> elsewhere. >> >> That'd be NO_ADVERTISE. >>> There's this "MUST NOT be advertised" in the spec. >> >> In reality, NO_EXPORT in practice is employed to convey to >> AN ADJACENT AS that the route should not be advertised to >> BGP peers outside of that AS (i.e., eBGP peers). > > Yes, sorry, inexact use of terminology. When I said neighbors, > I meant your external peer, I wasn't thinking of iBGP neighbors. > >> This is no different than any other attribute. For example, if >> an upstream chooses not to announce a route, well, there's >> little we can do about that. > > Sending an update to your (ebgp) neighbor is not a prescription > of what he/she/it does with that update. Sending an AS_HOPCOUNT/ > AS_PATHLIMIT or a community of NO_EXPORT is a prescription of > what your (ebgp) neighbor is supposed to do with that update. > So they are really very different. No, it's a prescription of what *you'd like your neighbor* to do with the update. > Then you mean the HOPCOUNT/PATHLIMIT to be advice or a request, > and you can't expect anything particular to happen. Like it or not, isn't that the way routing in the Internet works today? > You should make this clear in the draft text. In particular, > you should remove all "MUST" and "MUST NOT" from the text. > It makes no sense to say "MUST advertise an AS_HOPCOUNT attribute > of one less than the value received", if replacing the value > with any other value is OK. It makes no sense to say > "If the attribute value is zero, the path MUST be ignored > without further processing", if the BGP speaker can chose to > ignore the limit and propagate. This applies to ALL attributes deployed today - why the exception here? > Are you sure you know what you want here? The language of the > draft sounds like certainty and determinism is desired, but > you are saying that no integrity protections are desired because > local policy might do anything it wanted. Again, like it or not, that's the nature of routing in the Internet today. Think about it.. What if someone downstream wanted to manipulate a competitors traffic flows and they couldn't do anything about it? First and foremost, operators have to protect their networks and employ policies that make good technical and business sense. Then they can permit and employ features such as this. In reality, most likely would support it, e.g., for the reasons outlined in the draft, but determinism is a bit of a misnomer in the real world when your considering thousands of companies globally, all with different legal, regulatory, business and economic motivations. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA15760 for ; Wed, 11 Jan 2006 16:51:16 -0500 (EST) 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 1Ewnol-0005u3-NC; Wed, 11 Jan 2006 16:47:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewnok-0005ty-BJ for idr@megatron.ietf.org; Wed, 11 Jan 2006 16:47:42 -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 QAA16687 for ; Wed, 11 Jan 2006 16:46:19 -0500 (EST) From: sandy@tislabs.com Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewnvh-00010u-Hv for idr@ietf.org; Wed, 11 Jan 2006 16:54:54 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0BLlBjO002624 for ; Wed, 11 Jan 2006 16:47:12 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAj4aq3e; Wed, 11 Jan 06 16:46:32 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0BLmwiX009305; Wed, 11 Jan 2006 16:48:58 -0500 (EST) Date: Wed, 11 Jan 2006 16:48:58 -0500 (EST) Message-Id: <200601112148.k0BLmwiX009305@tislabs.com> To: idr@ietf.org Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sandy@tislabs.com 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 >The draft specifies the required behaviour for an implementation in >the case where the attribute is present. Those requirements are >orthogonal to whether or not an operator of an AS decides to >implement policy which removes particular attributes which were added >elsewhere. Sounds to me like you are quibbling - if the AS removes the attribute and creates a new lookalike with a value that would not follow the spec, then it is OK. I don't think "this isn't a modification, it is a deletion and insertion" is necessarily always justified. Or maybe you don't realize that I'm talking about changing the value in an existing attribute. So - suppose you create a PATHLIMIT of 4 and *two* hops away, someone changes the limit to 15? I.E., not a new attribute, keeping your AS number in the attribute and all that. Is that still OK with you? If we're talking about HOPCOUNT, if you create a HOPCOUNT of 4 and two hops away someone adds 6? Still OK? These aren't at the limit you've specified for the propagation of the route, the changes are somewhere along the way. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA15669 for ; Wed, 11 Jan 2006 16:40:55 -0500 (EST) 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 1EwngU-000239-6C; Wed, 11 Jan 2006 16:39:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwngT-000234-De for idr@megatron.ietf.org; Wed, 11 Jan 2006 16:39:09 -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 QAA16148 for ; Wed, 11 Jan 2006 16:37:47 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwnnR-0000kI-Dh for idr@ietf.org; Wed, 11 Jan 2006 16:46:22 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 0896D642D4 for ; Wed, 11 Jan 2006 14:38:45 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <20060111195133.GF22020@nexthop.com> References: <200601111755.k0BHtv58029071@tislabs.com> <20060111195133.GF22020@nexthop.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D9FF0F3-1CF3-4089-BED7-24BCEE941FC6@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 14:38:58 -0700 To: Inter-Domain List Routing X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit 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 On Jan 11, 2006, at 12:51 PM, Jeffrey Haas wrote: > > > But you don't own the resources of the person who'll eventually > receive the traffic. I can certainly see a shady economic argument > that you'd want to disrespect control communities, even well > recognized > ones, in order to sink more traffic across your network. or vice versa.. I wouldn't call it shady though, I'd call it practical and reality. > In many > cases, this would lead to increased revenue being exchanged between > AS 3 and AS 4. AS 1, on the other hand, receives more traffic than > they may have wanted on that link. > > In the case where different routes that would affect flow across > your network (A and B), I can see some justification to ignore > downstream preferences because you may want to manage your own > resources. This justification is vague because AS_PATH is usually > a bigger knob to adjust these flows. > > In the case of communities, I can see the semi-justification that > some policy languages make it difficult to "strip everything but > well known communities". > > I can see the justification that you'd want to decrease the length > in order to further constrain the diameter to which the routes > propagate. > > I'm having a difficult time seeing (aside from the reasons above) > why you'd otherwise want to increase the diameter of propagation. > If you could expand on such possible reasons, I think a lot of us > would appreciate it. I could make arguments for each of the above but it's futile. My point is simply that as a network operator I have policies that I employ on my network that are driven by both technical AND business requirements, either of which may drive me to ignore, strip or manipulate any attribute that could have an impact on the operations of my business. In short, I decide what route I provide transit for and how I'll permit the TE-associated attributes of those routes impact my network resources - AND who I allow to modify those resources. Now, with that said, operators of course realize what makes practical sense and what doesn't, and they clearly factor that into their policies. The fact that BGP provides this capability is a large contributor to it's success, IMO. -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA15658 for ; Wed, 11 Jan 2006 16:36:58 -0500 (EST) 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 1Ewnc9-00014k-KD; Wed, 11 Jan 2006 16:34:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewnc8-00014f-NT for idr@megatron.ietf.org; Wed, 11 Jan 2006 16:34:40 -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 QAA15781 for ; Wed, 11 Jan 2006 16:33:18 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewnj6-0000aq-H0 for idr@ietf.org; Wed, 11 Jan 2006 16:41:53 -0500 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ewnbr-000Ck1-Tx; Wed, 11 Jan 2006 21:34:24 +0000 In-Reply-To: <200601112039.k0BKd1L6006109@tislabs.com> References: <200601112039.k0BKd1L6006109@tislabs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <381E1D27-6DED-4E2F-9CC8-0D30C42ECB69@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 16:34:22 -0500 To: sandy@tislabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 On 11-Jan-2006, at 15:39, sandy@tislabs.com wrote: >>> If you set a AS_PATHLIMIT of 4 and the AS four hops away strips that >>> and adds a AS_PATHLIMIT of 15, would that be OK? >> >> Sure, why not? If I'm the 4th AS and have reason to do so? I own >> my network resources? > > Then you mean the HOPCOUNT/PATHLIMIT to be advice or a request, > and you can't expect anything particular to happen. Correct. Ditto for NO_EXPORT and MED (to choose two other attributes that are commonly meddled-with). > You should make this clear in the draft text. In particular, > you should remove all "MUST" and "MUST NOT" from the text. I don't think so. The draft specifies the required behaviour for an implementation in the case where the attribute is present. Those requirements are orthogonal to whether or not an operator of an AS decides to implement policy which removes particular attributes which were added elsewhere. This is no different to the processing of NO_EXPORT. The semantics of how a BGP speaker should process a route with the NO_EXPORT community string attribute attached are described clearly, using normative text, in RFC 1997. There is nothing to stop people removing NO_EXPORT from routes as suits their local policy, however, just as there is nothing to stop people adding NO_EXPORT to routes whose originators intended them to propagate further. > Are you sure you know what you want here? The language of the > draft sounds like certainty and determinism is desired, but > you are saying that no integrity protections are desired because > local policy might do anything it wanted. Influencing other peoples' policy is a necessarily inexact science. Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA15319 for ; Wed, 11 Jan 2006 15:46:59 -0500 (EST) 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 1EwmrB-0001Ul-IZ; Wed, 11 Jan 2006 15:46:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmrA-0001Ug-Eo for idr@megatron.ietf.org; Wed, 11 Jan 2006 15:46:08 -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 PAA11465 for ; Wed, 11 Jan 2006 15:44:47 -0500 (EST) From: sandy@tislabs.com Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewmy6-000732-5b for idr@ietf.org; Wed, 11 Jan 2006 15:53:21 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0BKjbUS020405 for ; Wed, 11 Jan 2006 15:45:37 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAdoaqMN; Wed, 11 Jan 06 15:44:54 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0BKd1L6006109; Wed, 11 Jan 2006 15:39:01 -0500 (EST) Date: Wed, 11 Jan 2006 15:39:01 -0500 (EST) Message-Id: <200601112039.k0BKd1L6006109@tislabs.com> To: idr@ietf.org Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sandy@tislabs.com 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 >> As I understand it, the NO_EXPORT attribute is intended just >> for your immediate neighbor, and is not supposed to be propagated >> elsewhere. > >That'd be NO_ADVERTISE. >> There's this "MUST NOT be advertised" in the spec. > >In reality, NO_EXPORT in practice is employed to convey to >AN ADJACENT AS that the route should not be advertised to >BGP peers outside of that AS (i.e., eBGP peers). Yes, sorry, inexact use of terminology. When I said neighbors, I meant your external peer, I wasn't thinking of iBGP neighbors. >This is no different than any other attribute. For example, if >an upstream chooses not to announce a route, well, there's >little we can do about that. Sending an update to your (ebgp) neighbor is not a prescription of what he/she/it does with that update. Sending an AS_HOPCOUNT/ AS_PATHLIMIT or a community of NO_EXPORT is a prescription of what your (ebgp) neighbor is supposed to do with that update. So they are really very different. >> If you set a AS_PATHLIMIT of 4 and the AS four hops away strips that >> and adds a AS_PATHLIMIT of 15, would that be OK? > >Sure, why not? If I'm the 4th AS and have reason to do so? I own >my network resources? Then you mean the HOPCOUNT/PATHLIMIT to be advice or a request, and you can't expect anything particular to happen. You should make this clear in the draft text. In particular, you should remove all "MUST" and "MUST NOT" from the text. It makes no sense to say "MUST advertise an AS_HOPCOUNT attribute of one less than the value received", if replacing the value with any other value is OK. It makes no sense to say "If the attribute value is zero, the path MUST be ignored without further processing", if the BGP speaker can chose to ignore the limit and propagate. Are you sure you know what you want here? The language of the draft sounds like certainty and determinism is desired, but you are saying that no integrity protections are desired because local policy might do anything it wanted. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA14877 for ; Wed, 11 Jan 2006 14:52:16 -0500 (EST) 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 1Ewm0t-0001qj-Jl; Wed, 11 Jan 2006 14:52:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewm0r-0001qe-Iw for idr@megatron.ietf.org; Wed, 11 Jan 2006 14:52:05 -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 OAA07242 for ; Wed, 11 Jan 2006 14:50:44 -0500 (EST) Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewm7m-0005Vc-2s for idr@ietf.org; Wed, 11 Jan 2006 14:59:17 -0500 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id BD5BA1C86; Wed, 11 Jan 2006 19:51:38 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 969kakTzK0149Mo1; Wed, 11 Jan 2006 19:51:37 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 966kakTzj0149Mo1; Wed, 11 Jan 2006 19:51:35 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.27I); Wed, 11 Jan 2006 19:51:35 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com gw3.EXCHPROD.USA.NET X-USANET-MsgId: XID433kakTzj1998Xo1 Received: from localhost ([65.247.36.31]) by gw3.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 12:51:35 -0700 Date: Wed, 11 Jan 2006 14:51:34 -0500 From: Jeffrey Haas To: Danny McPherson Subject: Re: [Idr] Next revision of AS_HOPCOUNT Message-ID: <20060111195133.GF22020@nexthop.com> References: <200601111755.k0BHtv58029071@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 11 Jan 2006 19:51:35.0318 (UTC) FILETIME=[6D928360:01C616E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Inter-Domain List Routing 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 On Wed, Jan 11, 2006 at 12:32:45PM -0700, Danny McPherson wrote: > >If you set a AS_PATHLIMIT of 4 and the AS four hops away strips that > >and adds a AS_PATHLIMIT of 15, would that be OK? > > Sure, why not? If I'm the 4th AS and have reason to do so? I own > my network resources? But you don't own the resources of the person who'll eventually receive the traffic. I can certainly see a shady economic argument that you'd want to disrespect control communities, even well recognized ones, in order to sink more traffic across your network. In many cases, this would lead to increased revenue being exchanged between AS 3 and AS 4. AS 1, on the other hand, receives more traffic than they may have wanted on that link. In the case where different routes that would affect flow across your network (A and B), I can see some justification to ignore downstream preferences because you may want to manage your own resources. This justification is vague because AS_PATH is usually a bigger knob to adjust these flows. In the case of communities, I can see the semi-justification that some policy languages make it difficult to "strip everything but well known communities". I can see the justification that you'd want to decrease the length in order to further constrain the diameter to which the routes propagate. I'm having a difficult time seeing (aside from the reasons above) why you'd otherwise want to increase the diameter of propagation. If you could expand on such possible reasons, I think a lot of us would appreciate it. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA14766 for ; Wed, 11 Jan 2006 14:33:29 -0500 (EST) 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 1EwliP-0005F2-N3; Wed, 11 Jan 2006 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwliN-0005Es-Sb for idr@megatron.ietf.org; Wed, 11 Jan 2006 14:32: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 OAA05515 for ; Wed, 11 Jan 2006 14:31:39 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwlpK-0004yI-Lx for idr@ietf.org; Wed, 11 Jan 2006 14:40:12 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 7821E642D4 for ; Wed, 11 Jan 2006 12:32:31 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <200601111755.k0BHtv58029071@tislabs.com> References: <200601111755.k0BHtv58029071@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 12:32:45 -0700 To: Inter-Domain List Routing X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit 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 On Jan 11, 2006, at 10:55 AM, sandy@tislabs.com wrote: >> The other main mechanism which restricts route propagation (the >> NO_EXPORT community string attribute) is trivial to strip from >> routes, overriding the intentions of the previous AS in the path. In >> general, surely every AS has a legitimate case for modifying the >> attributes on prefixes to suit its own needs. > > As I understand it, the NO_EXPORT attribute is intended just > for your immediate neighbor, and is not supposed to be propagated > elsewhere. That'd be NO_ADVERTISE. > There's this "MUST NOT be advertised" in the spec. In reality, NO_EXPORT in practice is employed to convey to AN ADJACENT AS that the route should not be advertised to BGP peers outside of that AS (i.e., eBGP peers). > Security mechanisms typically try to ensure that behavior matches > the spec or assumptions in the specs. So the trivial strippability > (and subsequent propagation) would be a security vulnerability. In this case, deployability is dictated by each operators policy independently. I.e., you desire for this to be the intended function and hope your peers respect that behavior. However, if your peer disagrees with you about how they should operate their network (e.g., not accepting MEDs, modifying paths, stripping communities) then their not having the capability to enforce their own policies would be a security vulnerability. Fortunately, most folks realize this and leave it as a matter of implementation support and each network operators policies. > Oh, you know, any modification in violation of what the spec says > should be done. Like changing the value from 3 to 15 (in the static > upper bound case) or incrementing the value by 6 instead of > decrementing by 1 (in the decremented case). > > It is tough to operate a distributed system when you are putting > values in packets that are supposed to elicit certain behaviors > in all recipients and some recipients break the rules and do > something else entirely. This distributed system is enabled and controlled by the folks operating the networks, not providing those folks with the capabilities to implement what policies they see fit for their environment (i.e., rather than allowing their peers/competitors to manipulate their network policies) is, well, not an option. This is no different than any other attribute. For example, if an upstream chooses not to announce a route, well, there's little we can do about that. > >> I would expect any AS to be able to remove an AS_PATHLIMIT attribute >> if that suited their local policy, substituting a new one if desired. > > AS_PATHLIMIT is a value that is supposed to affect ASes some distance > away and prevent propagation of information past a certain point. > Saying in the spec "but other ASes are free to do anything they want > to this field" seems to me to limit its usefulness. It would make > "the control that we hope to achieve" (to quote the i-d) a rather > undeterministic sort of control. Why bother with a "oh, who knows, > this might have some effect someplaces, then again, maybe not" > specification for what the field means? > > Or maybe you intend the field to be advice rather than prescription? > If you would rather have a more deterministic semantics for > the field, then you probably would want some integrity protection > for the value. > > If you want to permit a "maybe, maybe not" semantics to the field, > then you don't need the integrity. > > If you set a AS_PATHLIMIT of 4 and the AS four hops away strips that > and adds a AS_PATHLIMIT of 15, would that be OK? Sure, why not? If I'm the 4th AS and have reason to do so? I own my network resources? -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA14392 for ; Wed, 11 Jan 2006 13:46:52 -0500 (EST) 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 1Ewkyi-0008NV-S9; Wed, 11 Jan 2006 13:45:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewkyh-0008NO-AA for idr@megatron.ietf.org; Wed, 11 Jan 2006 13:45:47 -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 NAA02889 for ; Wed, 11 Jan 2006 13:44:26 -0500 (EST) From: sandy@tislabs.com Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewl5e-0003i3-Ud for idr@ietf.org; Wed, 11 Jan 2006 13:52:59 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0BIjJxG026646 for ; Wed, 11 Jan 2006 13:45:19 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAWpaq5Z; Wed, 11 Jan 06 13:44:58 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0BIRhbf000350; Wed, 11 Jan 2006 13:27:43 -0500 (EST) Date: Wed, 11 Jan 2006 13:27:43 -0500 (EST) Message-Id: <200601111827.k0BIRhbf000350@tislabs.com> To: idr@ietf.org Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sandy@tislabs.com 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 >The mechanism >by which your ensure that integrity is probably better discussed in >rpsec. RRPSEC might be the place the discuss the integrity mechanism, but making a choice between a static PATHLIMIT and a decrementing HOPCOUNT is better made here. Adding a snipit of thought to security consequences to the choice is, to me, appropriate here. And, of course, there's the question of what integrity means here. If you really want the field completely mutable by other ASes, then the definition of "integrity" is rather broad. >The behavior of mis-setting values in this field are already >discussed with Tony's usual wit in the security considerations of >the draft. :-) W-e-e-l-l. Tony says that those routers who attach this attribute could have used "normal policy mechanisms" to filter out the route. But I thought the whole point was that normal policy mechanisms did not provide the control desired. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA14003 for ; Wed, 11 Jan 2006 12:57:23 -0500 (EST) 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 1EwkDR-000347-T1; Wed, 11 Jan 2006 12:56:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwkDQ-00033n-UZ for idr@megatron.ietf.org; Wed, 11 Jan 2006 12:56:56 -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 MAA00536 for ; Wed, 11 Jan 2006 12:55:36 -0500 (EST) From: sandy@tislabs.com Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwkKM-0002Wn-Ns for idr@ietf.org; Wed, 11 Jan 2006 13:04:08 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0BHuPu1017215 for ; Wed, 11 Jan 2006 12:56:25 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAaja44G; Wed, 11 Jan 06 12:53:29 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0BHtv58029071; Wed, 11 Jan 2006 12:55:57 -0500 (EST) Date: Wed, 11 Jan 2006 12:55:57 -0500 (EST) Message-Id: <200601111755.k0BHtv58029071@tislabs.com> To: idr@ietf.org Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sandy@tislabs.com 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 >The other main mechanism which restricts route propagation (the >NO_EXPORT community string attribute) is trivial to strip from >routes, overriding the intentions of the previous AS in the path. In >general, surely every AS has a legitimate case for modifying the >attributes on prefixes to suit its own needs. As I understand it, the NO_EXPORT attribute is intended just for your immediate neighbor, and is not supposed to be propagated elsewhere. There's this "MUST NOT be advertised" in the spec. Security mechanisms typically try to ensure that behavior matches the spec or assumptions in the specs. So the trivial strippability (and subsequent propagation) would be a security vulnerability. >What kind of modification would you consider inappropriate? Oh, you know, any modification in violation of what the spec says should be done. Like changing the value from 3 to 15 (in the static upper bound case) or incrementing the value by 6 instead of decrementing by 1 (in the decremented case). It is tough to operate a distributed system when you are putting values in packets that are supposed to elicit certain behaviors in all recipients and some recipients break the rules and do something else entirely. >I would expect any AS to be able to remove an AS_PATHLIMIT attribute >if that suited their local policy, substituting a new one if desired. AS_PATHLIMIT is a value that is supposed to affect ASes some distance away and prevent propagation of information past a certain point. Saying in the spec "but other ASes are free to do anything they want to this field" seems to me to limit its usefulness. It would make "the control that we hope to achieve" (to quote the i-d) a rather undeterministic sort of control. Why bother with a "oh, who knows, this might have some effect someplaces, then again, maybe not" specification for what the field means? Or maybe you intend the field to be advice rather than prescription? If you would rather have a more deterministic semantics for the field, then you probably would want some integrity protection for the value. If you want to permit a "maybe, maybe not" semantics to the field, then you don't need the integrity. If you set a AS_PATHLIMIT of 4 and the AS four hops away strips that and adds a AS_PATHLIMIT of 15, would that be OK? You write into the spec whether that would be OK, and the security protections try to make the decision enforceable. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA13857 for ; Wed, 11 Jan 2006 12:37:35 -0500 (EST) 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 1EwjkK-0003y5-VW; Wed, 11 Jan 2006 12:26:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwjkJ-0003xs-Ro for idr@megatron.ietf.org; Wed, 11 Jan 2006 12:26:51 -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 MAA28581 for ; Wed, 11 Jan 2006 12:25:31 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwjrF-0001d9-P4 for idr@ietf.org; Wed, 11 Jan 2006 12:34:03 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id DF61F642D4 for ; Wed, 11 Jan 2006 10:26:29 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <200601111552.k0BFqlit023843@tislabs.com> <20060111164010.GE22020@nexthop.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <196D7592-5E31-4481-A596-B6D717F02A52@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 10:26:44 -0700 To: Inter-Domain Routing List X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit 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 On Jan 11, 2006, at 10:04 AM, Joe Abley wrote: > > True; however, many operators might also argue that their ability > to impose their own policy on the routes they choose to accept and > propagate is more important. Absolutely. I suspect many operators (I know of several first hand) that reset all community values received from eBGP peers and MAY reapply well- known communities on ingress, but avoid carrying any additional communities that have no meaning within their routing domain (e.g., to avoid effects on update packing, etc..). -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA13760 for ; Wed, 11 Jan 2006 12:17:10 -0500 (EST) 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 1EwjP8-00020m-9B; Wed, 11 Jan 2006 12:04:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwjP6-00020a-V0 for idr@megatron.ietf.org; Wed, 11 Jan 2006 12:04:57 -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 MAA26930 for ; Wed, 11 Jan 2006 12:03:36 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwjW2-0000ww-Gk for idr@ietf.org; Wed, 11 Jan 2006 12:12:07 -0500 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EwjOw-0007z5-40; Wed, 11 Jan 2006 17:04:46 +0000 In-Reply-To: <20060111164010.GE22020@nexthop.com> References: <200601111552.k0BFqlit023843@tislabs.com> <20060111164010.GE22020@nexthop.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 12:04:45 -0500 To: Jeffrey Haas X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Tony Li , sandy@tislabs.com 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 On 11-Jan-2006, at 11:40, Jeffrey Haas wrote: > On Wed, Jan 11, 2006 at 11:33:16AM -0500, Joe Abley wrote: >> The other main mechanism which restricts route propagation (the >> NO_EXPORT community string attribute) is trivial to strip from >> routes, overriding the intentions of the previous AS in the path. In >> general, surely every AS has a legitimate case for modifying the >> attributes on prefixes to suit its own needs. > > Some might argue the appropriateness of stripping the current > well known communities as potential security issues. True; however, many operators might also argue that their ability to impose their own policy on the routes they choose to accept and propagate is more important. > At best, you're > outright ignoring your peer's requirements to not propagate things. Perhaps it's more realistic to call them "requests" rather then "requirements". > However, rpsec might be a better place for this particular operational > discussion. Agreed; apologies for the tangent. Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA13476 for ; Wed, 11 Jan 2006 11:44:11 -0500 (EST) 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 1Ewj1d-0002Ef-L3; Wed, 11 Jan 2006 11:40:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewj1c-0002Ea-0i for idr@megatron.ietf.org; Wed, 11 Jan 2006 11:40:40 -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 LAA25041 for ; Wed, 11 Jan 2006 11:39:19 -0500 (EST) Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewj8W-0008W2-Sx for idr@ietf.org; Wed, 11 Jan 2006 11:47:50 -0500 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id 87DF815E3; Wed, 11 Jan 2006 16:40:15 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 508kakqOm0364Mo1; Wed, 11 Jan 2006 16:40:13 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 505kakqOL0308Mo1; Wed, 11 Jan 2006 16:40:11 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.27I); Wed, 11 Jan 2006 16:40:11 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID241kakqOL1751Xo1 Received: from localhost ([65.247.36.31]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 09:40:11 -0700 Date: Wed, 11 Jan 2006 11:40:10 -0500 From: Jeffrey Haas To: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Message-ID: <20060111164010.GE22020@nexthop.com> References: <200601111552.k0BFqlit023843@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 11 Jan 2006 16:40:11.0130 (UTC) FILETIME=[B0767DA0:01C616CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: idr@ietf.org, tony.li@tony.li, sandy@tislabs.com 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 On Wed, Jan 11, 2006 at 11:33:16AM -0500, Joe Abley wrote: > The other main mechanism which restricts route propagation (the > NO_EXPORT community string attribute) is trivial to strip from > routes, overriding the intentions of the previous AS in the path. In > general, surely every AS has a legitimate case for modifying the > attributes on prefixes to suit its own needs. Some might argue the appropriateness of stripping the current well known communities as potential security issues. At best, you're outright ignoring your peer's requirements to not propagate things. However, rpsec might be a better place for this particular operational discussion. > I would expect any AS to be able to remove an AS_PATHLIMIT attribute > if that suited their local policy, substituting a new one if desired. > In that context, I'm not sure what integrity there is to preserve? One component would simply be ensuring that someone doesn't put someone else's AS number in the hoplimit field. The mechanism by which your ensure that integrity is probably better discussed in rpsec. (However, I'll agree with Sandy that this makes things "easier" for some of the things we've discussed on rpsec.) The behavior of mis-setting values in this field are already discussed with Tony's usual wit in the security considerations of the draft. :-) -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA13456 for ; Wed, 11 Jan 2006 11:38:29 -0500 (EST) 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 1Ewiuo-0001Ya-5R; Wed, 11 Jan 2006 11:33:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewium-0001YU-Fa for idr@megatron.ietf.org; Wed, 11 Jan 2006 11:33:36 -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 LAA24642 for ; Wed, 11 Jan 2006 11:32:16 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewj1g-0008JB-Q2 for idr@ietf.org; Wed, 11 Jan 2006 11:40:47 -0500 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EwiuT-0007qB-5k; Wed, 11 Jan 2006 16:33:17 +0000 In-Reply-To: <200601111552.k0BFqlit023843@tislabs.com> References: <200601111552.k0BFqlit023843@tislabs.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 11:33:16 -0500 To: sandy@tislabs.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, tony.li@tony.li 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 On 11-Jan-2006, at 10:52, sandy@tislabs.com wrote: > That probably would leave open opportunities for bad/stupid/broken > guys to modify the field inappropriately, with ill effect. The other main mechanism which restricts route propagation (the NO_EXPORT community string attribute) is trivial to strip from routes, overriding the intentions of the previous AS in the path. In general, surely every AS has a legitimate case for modifying the attributes on prefixes to suit its own needs. What kind of modification would you consider inappropriate? > If one had an static absolute path length, its integrity could be > protected over many hops. I would expect any AS to be able to remove an AS_PATHLIMIT attribute if that suited their local policy, substituting a new one if desired. In that context, I'm not sure what integrity there is to preserve? Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12984 for ; Wed, 11 Jan 2006 10:52:37 -0500 (EST) 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 1EwiGk-0003X4-Fm; Wed, 11 Jan 2006 10:52:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwiGj-0003Ww-0Q for idr@megatron.ietf.org; Wed, 11 Jan 2006 10:52:13 -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 KAA21585 for ; Wed, 11 Jan 2006 10:50:53 -0500 (EST) From: sandy@tislabs.com Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwiNX-0006zT-FM for idr@ietf.org; Wed, 11 Jan 2006 10:59:23 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0BFpVUv026728 for ; Wed, 11 Jan 2006 10:51:31 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA83aGWZ; Wed, 11 Jan 06 10:50:27 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0BFqlit023843; Wed, 11 Jan 2006 10:52:47 -0500 (EST) Date: Wed, 11 Jan 2006 10:52:47 -0500 (EST) Message-Id: <200601111552.k0BFqlit023843@tislabs.com> To: jhaas@nexthop.com, tony.li@tony.li Subject: Re: [Idr] Next revision of AS_HOPCOUNT X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Another aspect of decrementing hop count vs "absolute" path length. If one uses a decrementing hop count and there is a security mechanism in place that tries provides protections that would allow ASes many hops away to verify the integrity of what you sent (i.e., the portion of what they receive that is what you sent), then the hop count would have to be excluded from that protection. It would be legitimately changing, so you could not protect its integrity. That probably would leave open opportunities for bad/stupid/broken guys to modify the field inappropriately, with ill effect. (Like the TTL field in IP is not covered by IPSEC because it changes at each hop.) If one had an static absolute path length, its integrity could be protected over many hops. --Sandy _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12757 for ; Wed, 11 Jan 2006 10:37:37 -0500 (EST) 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 1Ewhyj-0006do-3b; Wed, 11 Jan 2006 10:33:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewhyh-0006dj-3h for idr@megatron.ietf.org; Wed, 11 Jan 2006 10:33:35 -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 KAA20449 for ; Wed, 11 Jan 2006 10:32:13 -0500 (EST) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewi5Y-0006UZ-Nm for idr@ietf.org; Wed, 11 Jan 2006 10:40:44 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id F2FFF1C44; Wed, 11 Jan 2006 15:33:07 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 268kakPhg0204Mo2; Wed, 11 Jan 2006 15:33:06 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 265kakPhe0266Mo2; Wed, 11 Jan 2006 15:33:04 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Wed, 11 Jan 2006 15:33:04 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID492kakPhe4616Xo2 Received: from localhost ([65.247.36.31]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 08:33:04 -0700 Date: Wed, 11 Jan 2006 10:33:03 -0500 From: Jeffrey Haas To: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Message-ID: <20060111153303.GB22020@nexthop.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <20060110223708.GB12691@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 11 Jan 2006 15:33:04.0407 (UTC) FILETIME=[50595270:01C616C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Inter-Domain Routing List 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, On Tue, Jan 10, 2006 at 03:00:08PM -0800, Tony Li wrote: > This was exactly why we were shifting to a static value and way from > decrement. I don't have a strong enough opinion on wanting the decrement to warrant a serious objection, just a preference. I think I'll buy into your argument that the fewer routers that have to worry about actually changing the attribute, the better. I withdraw my previous support for using decrement. I would definitely like to see more language about how we do the counting. Absolute path length seems to be the wrong choice. I think that Russ's verbiage about distinct ASes is close. I'd suggest that we count any recurring adjacent sequences of an AS in one or more AS_SEQUENCEs as length 1 and simply count an entire AS_SET, regardless of content, as length 1. Ergo: 1 1 1 2 3 3 2 [5 6 7] would count as length 5. Yes, there's an intentional loop in there. > >The 4 byte AS number in the attribute is probably a good idea. > >However, we should carefully explain the behavior when the 4 byte > >AS must be utilized by a 2byte speaker. > > The draft references the encoding rules used in the 4 octet draft. This is somewhat problematic when dealing with a 2 byte speaker with AS_TRANS in the AS_PATH. Without peeking into the NEW_AS_PATH, you can't tell if multiple occurrences are distinct ASes or not. This affects how I'd expect path length counting to occur. Of course, if you're counting absolute path length, that changes things. (I'm really hoping you're not counting absolute path length.) > You'll pardon me if my paranoia regarding deaggregation hasn't abated in > the last 15 years. ;-) If you feel additional text is warranted, > contributions are most welcome. Let's just say I share your paranoia. However, the current BGP RFC-to-be doesn't use that particular verbiage and this leaves this document out of "harmony". I say this mostly because no one seems to implement ATOMIC_AGGREGATE in the way that suggested in 1771. Additionally, per some e-mail chains a few years ago, adding ATOMIC_AGGREGATE on an outbound-only basis isn't sufficient. Safest to just pretend we don't deaggregate since it leads to madness. > Tony -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA11394 for ; Wed, 11 Jan 2006 08:26:49 -0500 (EST) 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 1EwfzE-0008Pa-6L; Wed, 11 Jan 2006 08:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfzD-0008PL-4v for idr@megatron.ietf.org; Wed, 11 Jan 2006 08:25: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 IAA11815 for ; Wed, 11 Jan 2006 08:24:38 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewg65-0002jB-Vv for idr@ietf.org; Wed, 11 Jan 2006 08:33:07 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2006 05:25:47 -0800 X-IronPort-AV: i="3.99,355,1131350400"; d="scan'208"; a="248352561:sNHT30981970" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0BDPlc1016575 for ; Wed, 11 Jan 2006 05:25:47 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 08:25:47 -0500 Received: from [64.100.131.122] ([64.100.131.122]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 08:25:46 -0500 In-Reply-To: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4163a865ee13bc4646a47ae2f228ec97@cisco.com> Content-Transfer-Encoding: 7bit From: Dana Blair Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Wed, 11 Jan 2006 08:25:45 -0500 To: Inter-Domain Routing List X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 11 Jan 2006 13:25:46.0988 (UTC) FILETIME=[8817AAC0:01C616B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 On Jan 10, 2006, at 3:35 PM, Tony Li wrote: > > Hi folks, > > Based on the discussion that we've had so far, the authors of the > AS_HOPCOUNT draft would > like to make some substantive changes to the draft. The chairs have > asked that we poll you to > ensure that we have rough consensus on the new direction. The primary > technical points of > these changes: > > - Convert AS_HOPCOUNT from being decremented at each AS boundary and > instead have it > be a static upper bound on the AS path length. This is necessary for partial deployment. > > - Rename the attribute to AS_PATHLIMIT. I don't have an opinion on renaming as long as the draft moves forward. > > - Completely remove the interaction with NO_EXPORT. I'm not expert enough (yet) to have an opinion on NO_EXPORT. Dana > > There are, of course, a number of details more fully explained in the > revised draft, but before we > are allowed to present you with the revision, we need to have your > approval on the above. > > Could folks please comment to the list within the next two weeks as to > whether or not this direction > is acceptable? As this is to help gauge consensus, both positive and > negative comments are > solicited. > > Regards, > Joe & Rex & 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 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA08488 for ; Wed, 11 Jan 2006 00:53:25 -0500 (EST) 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 1EwYuB-0006pv-5k; Wed, 11 Jan 2006 00:52:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwYuA-0006pp-3y for idr@megatron.ietf.org; Wed, 11 Jan 2006 00:52:18 -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 AAA15526 for ; Wed, 11 Jan 2006 00:50:58 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwZ0z-0007RQ-Iy for idr@ietf.org; Wed, 11 Jan 2006 00:59:23 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0B5q0YG024531; Wed, 11 Jan 2006 07:52:00 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0B5pxFm024528; Wed, 11 Jan 2006 07:51:59 +0200 Date: Wed, 11 Jan 2006 07:51:59 +0200 (EET) From: Pekka Savola To: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT In-Reply-To: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Message-ID: References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1237/Tue Jan 10 17:53:20 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Inter-Domain Routing List 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 On Tue, 10 Jan 2006, Tony Li wrote: > - Convert AS_HOPCOUNT from being decremented at each AS boundary and instead > have it > be a static upper bound on the AS path length. > > - Rename the attribute to AS_PATHLIMIT. > > - Completely remove the interaction with NO_EXPORT. I think this is exactly the direction to follow. This lessens my concerns of this attribute considerably. The simpler, the better. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA08473 for ; Wed, 11 Jan 2006 00:49:04 -0500 (EST) 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 1EwYoc-0005zl-GJ; Wed, 11 Jan 2006 00:46:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwYoa-0005zT-Qx for idr@megatron.ietf.org; Wed, 11 Jan 2006 00:46:32 -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 AAA15234 for ; Wed, 11 Jan 2006 00:45:12 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwYvR-0007Io-Bs for idr@ietf.org; Wed, 11 Jan 2006 00:53:37 -0500 Received: by xproxy.gmail.com with SMTP id s9so52080wxc for ; Tue, 10 Jan 2006 21:46:31 -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=tvqz7oGVV5B17YB86ZEr8zMNx8BicArrN1XEtTcC3TuHHu7sKTLMd+uNphqXdNYF1Lelr3vCDr7uq1O0DtDY3eZ7KtW/fRwRUP6qvxzYkBf9BoQTw0kQc25MRAHjd2HJro/MpqbvXrSDwnNrAgZmIrHR1utRunh5XAt1Rn/bi1g= Received: by 10.70.62.19 with SMTP id k19mr449979wxa; Tue, 10 Jan 2006 21:46:31 -0800 (PST) Received: by 10.70.70.13 with HTTP; Tue, 10 Jan 2006 21:46:31 -0800 (PST) Message-ID: Date: Wed, 11 Jan 2006 11:16:31 +0530 From: Maneesh Chawla To: anjanhg@huawei.com Subject: Re: [Idr] Aggregation and dampening In-Reply-To: <000501c615dc$dcc2f330$5a04120a@china.huawei.com> MIME-Version: 1.0 References: <000501c615da$c82a5870$5a04120a@china.huawei.com> <000501c615dc$dcc2f330$5a04120a@china.huawei.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb 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: , Content-Type: multipart/mixed; boundary="===============1887269048==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --===============1887269048== Content-Type: multipart/alternative; boundary="----=_Part_33363_23169604.1136958391489" ------=_Part_33363_23169604.1136958391489 Content-Type: text/plain; charset=WINDOWS-1252 Content-Disposition: inline Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmVwbHkgQW5qYW4uCkkgYW0gc29ycnkgSSBmb3Jnb3QgdG8gbWVudGlv biB0aGF0IHdoZW4gSSBhZ2dyZWdhdGUgSSB1c2UgdGhlCiJzdW1tYXJ5LW9ubHkiIG9wdGlvbiBz byBpbiB0aGlzIGNhc2UgdGhlIGNvbnRyaWJ1dGluZyByb3V0ZXMgYXJlIGFscmVhZHkKc3VwcHJl c3NlZC4gTm93ICwgd2hhdCBzaG91bGQgaGFwcGVuIHdoZW4gZGFtcGVuaW5nIGlzIGNvbmZpZ3Vy ZWQgPwoKVGhhbmtzCk1hbmVlc2gKCk9uIDEvMTAvMDYsIEFuamFuIDxhbmphbmhnQGh1YXdlaS5j b20+IHdyb3RlOgo+Cj4gIFNvcnJ5LCBEYW1wZW5lZCByb3V0ZSBJIG1lYW4gaGVyZSBpcyB0aGUg J3JvdXRlIHRoYXQganVzdCBjYW1lIG91dCBvZgo+IERhbXBlbmVkIHN0YXRlJy4uCj4KPgo+Cj4K PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKPgo+ICAgICAgICAgICAgIFRoaXMgZS1t YWlsIGFuZCBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbgo+IGZy b20gSFVBV0VJLCB3aGljaCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0 eSB3aG9zZSBhZGRyZXNzCj4gaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkKPiAoaW5jbHVkaW5nLCBidXQgbm90IGxp bWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLAo+IG9y IGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50J3MpIGlzCj4gcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQo+IHBob25lIG9yIGVtYWlsIGltbWVkaWF0 ZWx5IGFuZCBkZWxldGUgaXQhCj4KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ICpGcm9t OiogaWRyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gKk9u IEJlaGFsZiBPZiAqCj4gQW5qYW4KPiAqU2VudDoqIFR1ZXNkYXksIEphbnVhcnkgMTAsIDIwMDYg NToxMSBQTQo+ICpUbzoqICdNYW5lZXNoIENoYXdsYSc7IGlkckBpZXRmLm9yZwo+ICpTdWJqZWN0 OiogUkU6IFtJZHJdIEFnZ3JlZ2F0aW9uIGFuZCBkYW1wZW5pbmcKPgo+Cj4KPiBIaSBNYW5lZXNo LAo+Cj4KPgo+IEkgZmVlbCBEYW1wZW5pbmcgc2hvdWxkIGJlIGNvbnNpZGVyZWQgaXJyZXNwZWN0 aXZlIG9mIHdoYXQgeW91IGFyZSBkb2luZwo+IGluIGFnZ3JlZ2F0aW9uLgo+Cj4gV2hlbiBkYW1w ZW5pbmcgaXMgY29uZmlndXJlZCwgcm91dGUgY2FuIHRha2UgdHdvIHZhbHVlcyBEYW1wZW5lZCBv cgo+IEhpc3RvcnkuCj4KPiBEYW1wZW5lZCByb3V0ZSBpcyB2YWxpZCB0byBhZHZlcnRpc2UuICBI aXN0b3J5IHJvdXRlIGlzIG5vdCB2YWxpZCB0bwo+IGFkdmVydGlzZS4KPgo+Cj4KPiBTbyB3aGV0 aGVyIHRoZSByb3V0ZSBjYW4gYmUgY29uc2lkZXJlZCBmb3IgYWdncmVnYXRpb24gb3Igbm90LCBk ZXBlbmRzIG9uCj4gdGhpcyBzdGF0ZSCWIGRhbXBlbmVkIG9yIGhpc3RvcnkuCj4KPgo+Cj4gV2l0 aCBzcGVjaWZpYyBhbnN3ZXIgdG8geW91ciBxdWVzdGlvbiwgSWYgdGhlIHJvdXRlIGlzIGluIERh bXBlbmVkIHN0YXRlCj4gaXQgc2hvdWxkIGNvbnRyaWJ1dGUgZm9yIEFnZ3JlZ2F0aW9uLgo+Cj4g SWYgaXQgaXMgaW4gSGlzdG9yeSBzdGF0ZSBpdCBzaG91bGQgbm90IGNvbnRyaWJ1dGUgZm9yIEFn Z3JlZ2F0aW9uLgo+Cj4KPgo+IEFueSBkaWZmZXJlbnQgb3BpbmlvbiBpbiB0aGUgZ3JvdXA/Cj4K Pgo+Cj4gUmVnYXJkcywKPgo+IEFuamFuCj4KPgo+Cj4KPgo+Cj4KPgo+ICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKgo+Cj4gICAgICAgICAgICAgVGhpcyBlLW1haWwgYW5kIGF0dGFjaG1l bnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uCj4gZnJvbSBIVUFXRUksIHdoaWNo IGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MK PiBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBo ZXJlaW4gaW4gYW55IHdheQo+IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwg b3IgcGFydGlhbCBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sCj4gb3IgZGlzc2VtaW5hdGlvbikg YnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQncykgaXMKPiBwcm9o aWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGJ5Cj4gcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBp dCEKPgo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gKkZyb206KiBpZHItYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpNYW5l ZXNoCj4gQ2hhd2xhCj4gKlNlbnQ6KiBUdWVzZGF5LCBKYW51YXJ5IDEwLCAyMDA2IDQ6MzIgUE0K PiAqVG86KiBpZHJAaWV0Zi5vcmcKPiAqU3ViamVjdDoqIFtJZHJdIEFnZ3JlZ2F0aW9uIGFuZCBk YW1wZW5pbmcKPgo+Cj4KPiBIaSBBbGwsCj4gICAgICAgICAgICBJIGhhdmUgYSBxdWVzdGlvbiBv biBhZ2dyZWdhdGlvbiBhbmQgZGFtcGVuaW5nLgo+Cj4gQ29uc2lkZXIgdGhlIHRvcG9sb2d5LAo+ Cj4gUjEtLS0tLVIzLS0tLS0tLVI0Cj4gICAgICAgICAgIHwKPiAgICAgICAgICAgfAo+IFIyLS0t LS0tfAo+Cj4KPiAxLiBSMSBhbmQgUjIgYXJlIGFkdmVydGlzaW5nIDY2LjAuMC4wLzMyIGFuZCA2 Ni4wLjAuMS8zMiB0byBSMwo+IHJlc3BlY3RpdmVseS4KPiAyLiBSMyBpcyBhZ2dyZWdhdGluZyB0 aGUgcm91dGVzICh3aXRoIHRoZSBhcy1zZXQgY29tbWFuZCApIGFuZCBhZHZlcnRpc2luZwo+IHRv IFI0LiBTaW5jZSBpdCBpcyB1c2luZyB0aGUgYXMtc2V0IG9wdGlvbiwgYWxsIHRoZSBwYXRoIGF0 dHJpYnV0ZXMgYXJlCj4gY29uc2lkZXJlZCBhbmQgaWYgb25lIG9mIHRoZSByb3V0ZXMgZmxhcCAs IHNheSB0aGUgcm91dGUgZnJvbSBSMiwgdGhlCj4gYWdncmVnYXRlIGZsYXAgdG8gUjQgd2lsbCBm bGFwLgo+IDMuIE5vdyAsIGNvbm5maWd1cmUgZGFtcGVuaW5nIGFsc28gb24gUjMuCj4KPiAgICAg ICAgIElzIGl0IHJpZ2h0IHRvIGV4cGVjdCB0aGF0IG5vdyB3aGVuIHRoZSByb3V0ZSBmcm9tIFIy IGZsYXBzLCBpdAo+IHNob3VsZCBiZSBkYW1wZWQgc28gYXMgdG8gbm90IGFmZmVjdCB0aGUgYWdn cmVnYXRlID8gVG8gcHV0IGl0IG1vcmUKPiBlbGFib3JhdGl2ZWx5ICwgc2F5ICB0aGUgcm91dGUg ZnJvbSBSMiBmbGFwcyBhbmQgcmVhY2hlcyBzdXByZXNzIHZhbHVlIGFuZAo+IGlzIHRoZXJlYnkg c3VwcHJlc3NlZCwgc2hvdWxkIGl0IHN0aWxsIGNvbnRyaWJ1dGUgdG8gdGhlIGFnZ3JlZ2F0ZSBv ciBzdG9wCj4gY29udHJpYnV0aW5nIHRvIHRoZSBhZ2dyZWdhdGUgPwo+ICAgICAgICAgSXMgdGhp cyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyA/Cj4KPiBUaGFua3MKPiBNYW5lZXNoCj4KPiBwLnMg OiBTb3JyeSAsIGlmIGl0IGlzIGEgdmVyeSBiYXNpYyBxdWVzdGlvbiBpbiB0aGlzIGZvcnVtLgo+ Cj4K ------=_Part_33363_23169604.1136958391489 Content-Type: text/html; charset=WINDOWS-1252 Content-Disposition: inline Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmVwbHkgQW5qYW4uPGJyPkkgYW0gc29ycnkgSSBmb3Jnb3QgdG8gbWVu dGlvbiB0aGF0IHdoZW4gSSBhZ2dyZWdhdGUgSSB1c2UgdGhlICZxdW90O3N1bW1hcnktb25seSZx dW90OyBvcHRpb24gc28gaW4gdGhpcyBjYXNlIHRoZSBjb250cmlidXRpbmcgcm91dGVzIGFyZSBh bHJlYWR5IHN1cHByZXNzZWQuIE5vdyAsIHdoYXQgc2hvdWxkIGhhcHBlbiB3aGVuIGRhbXBlbmlu ZyBpcyBjb25maWd1cmVkID8KPGJyPjxicj5UaGFua3M8YnI+TWFuZWVzaDxicj48YnI+PGRpdj48 c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDEvMTAvMDYsIDxiIGNsYXNzPSJnbWFpbF9zZW5k ZXJuYW1lIj5BbmphbjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmphbmhnQGh1YXdlaS5jb20i PmFuamFuaGdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIw NCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4K CgoKCgoKCgoKCgoKCgo8ZGl2PgoKPHA+PGZvbnQgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIiBz aXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWw7 IGNvbG9yOiBuYXZ5OyI+U29ycnksIERhbXBlbmVkIHJvdXRlIEkgbWVhbiBoZXJlIGlzIHRoZSAn cm91dGUKdGhhdCBqdXN0IGNhbWUgb3V0IG9mIERhbXBlbmVkIHN0YXRlJy4uPC9zcGFuPjwvZm9u dD48L3A+PHNwYW4gY2xhc3M9InEiPgoKPHA+PGZvbnQgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFs IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJp YWw7IGNvbG9yOiBuYXZ5OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cgo8ZGl2PgoKPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0OiAyN3B0OyB0ZXh0LWluZGVudDogLTI3cHQ7IGxpbmUtaGVpZ2h0OiAx MnB0OyI+PGZvbnQgY29sb3I9ImJsYWNrIiBmYWNlPSJBcmlhbCIgc2l6ZT0iMSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogOHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBibGFjazsiPioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKgo8L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0eWxl PSJtYXJnaW4tbGVmdDogMjdwdDsgdGV4dC1pbmRlbnQ6IC0yN3B0OyBsaW5lLWhlaWdodDogMTJw dDsiPjxmb250IGNvbG9yPSJibGFjayIgZmFjZT0iQXJpYWwiIHNpemU9IjEiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDhwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogYmxhY2s7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhpcwplLW1haWwgYW5kIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGlu Zm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCBpcwppbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVy c29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZQpvZiB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1 dCBub3QgbGltaXRlZCB0bywKdG90YWwgb3IgcGFydGlhbCBkaXNjbG9zdXJlLCByZXByb2R1Y3Rp b24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIKdGhhbiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50J3MpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGlu CmVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRp YXRlbHkgYW5kIGRlbGV0ZSBpdCE8L3NwYW4+PC9mb250PjwvcD4KCjwvZGl2PgoKPC9zcGFuPjxk aXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzEwOGI0NTJiMDBhYTUxYmRfMiI+PHAgc3R5bGU9Im1h cmdpbi1sZWZ0OiAwLjVpbjsiPjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYTsiPi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPgo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5Gcm9t Ojwvc3Bhbj48L2I+IDxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50 LHRoaXMpIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT4KW21haWx0bzo8YSBocmVmPSJtYWlsdG86 aWRyLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9w LmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSA8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5PbiBCZWhhbGYgT2YgPC9z cGFuPjwvYj5Bbmphbjxicj4KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+U2Vu dDo8L3NwYW4+PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDEwLCAyMDA2CjU6MTEgUE08YnI+CjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPlRvOjwvc3Bhbj48L2I+ICc8L3NwYW4+PC9m b250Pjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYTsiPk1hbmVlc2ggQ2hhd2xhPC9zcGFuPjwvZm9udD48 Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBUYWhvbWE7Ij4KJzsgPC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJUYWhv bWEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBU YWhvbWE7Ij48YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgb25j bGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmlkckBp ZXRmLm9yZzwvYT48L3NwYW4+CjwvZm9udD48Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWE7Ij48YnI+Cjxi PjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6 IFtJZHJdIEFnZ3JlZ2F0aW9uIGFuZApkYW1wZW5pbmc8L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNp emU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250 PjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2eSIg ZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij5IaSBNYW5lZXNoLDwvc3Bhbj48L2ZvbnQ+PC9w PgoKPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OiAwLjVpbjsiPjxmb250IGNvbG9yPSJuYXZ5IiBmYWNl PSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0OiAwLjVpbjsiPjxmb250IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIg c2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFs OyBjb2xvcjogbmF2eTsiPkkgZmVlbCBEYW1wZW5pbmcgc2hvdWxkCmJlIGNvbnNpZGVyZWQgaXJy ZXNwZWN0aXZlIG9mIHdoYXQgeW91IGFyZSBkb2luZyBpbiBhZ2dyZWdhdGlvbi48L3NwYW4+PC9m b250PjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2 eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij5XaGVuIGRhbXBlbmluZyBpcwpjb25maWd1 cmVkLCByb3V0ZSBjYW4gdGFrZSB0d28gdmFsdWVzIERhbXBlbmVkIG9yIEhpc3RvcnkuPC9zcGFu PjwvZm9udD48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDAuNWluOyI+PGZvbnQgY29sb3I9 Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+RGFtcGVuZWQgcm91dGUgaXMgdmFs aWQKdG8gYWR2ZXJ0aXNlLiZuYnNwOyBIaXN0b3J5IHJvdXRlIGlzIG5vdCB2YWxpZCB0byBhZHZl cnRpc2UuPC9zcGFuPjwvZm9udD48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDAuNWluOyI+ PGZvbnQgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+Jm5ic3A7PC9z cGFuPjwvZm9udD48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDAuNWluOyI+PGZvbnQgY29s b3I9Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+U28gd2hldGhlciB0aGUgcm91 dGUgY2FuCmJlIGNvbnNpZGVyZWQgZm9yIGFnZ3JlZ2F0aW9uIG9yIG5vdCwgZGVwZW5kcyBvbiB0 aGlzIHN0YXRlIJYgZGFtcGVuZWQgb3IKaGlzdG9yeS48L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwi IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlh bDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0eWxlPSJtYXJn aW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6 IG5hdnk7Ij5XaXRoIHNwZWNpZmljIGFuc3dlciB0bwp5b3VyIHF1ZXN0aW9uLCBJZiB0aGUgcm91 dGUgaXMgaW4gRGFtcGVuZWQgc3RhdGUgaXQgc2hvdWxkIGNvbnRyaWJ1dGUgZm9yCkFnZ3JlZ2F0 aW9uLjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OiAwLjVpbjsiPjxm b250IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPklmIGl0IGlzIGlu IEhpc3Rvcnkgc3RhdGUKaXQgc2hvdWxkIG5vdCBjb250cmlidXRlIGZvciBBZ2dyZWdhdGlvbi48 L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBj b2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9m b250PjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2 eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij5BbnkgZGlmZmVyZW50IG9waW5pb24gaW4K dGhlIGdyb3VwPzwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OiAwLjVp bjsiPjxmb250IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OiAwLjVpbjsiPjxmb250 IGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogbmF2eTsiPlJlZ2FyZHMsPC9zcGFu PjwvZm9udD48L3A+Cgo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6IDAuNWluOyI+PGZvbnQgY29sb3I9 Im5hdnkiIGZhY2U9IkFyaWFsIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBuYXZ5OyI+QW5qYW48L3NwYW4+PC9mb250Pjwv cD4KCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2eSIgZmFj ZT0iQXJpYWwiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiBBcmlhbDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwi IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlh bDsgY29sb3I6IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0eWxlPSJtYXJn aW4tbGVmdDogMC41aW47Ij48Zm9udCBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6 IG5hdnk7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxkaXY+Cgo8cCBzdHlsZT0ibWFyZ2lu LWxlZnQ6IDYzcHQ7IHRleHQtaW5kZW50OiAtMjdwdDsgbGluZS1oZWlnaHQ6IDEycHQ7Ij48Zm9u dCBjb2xvcj0iYmxhY2siIGZhY2U9IkFyaWFsIiBzaXplPSIxIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiA4cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbDsgY29sb3I6IGJsYWNrOyI+KioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqCjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHAgc3R5bGU9Im1hcmdpbi1s ZWZ0OiA2M3B0OyB0ZXh0LWluZGVudDogLTI3cHQ7IGxpbmUtaGVpZ2h0OiAxMnB0OyI+PGZvbnQg Y29sb3I9ImJsYWNrIiBmYWNlPSJBcmlhbCIgc2l6ZT0iMSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOHB0OyBmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiBibGFjazsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwpUaGlz IGUtbWFpbCBhbmQgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24g ZnJvbSBIVUFXRUksIHdoaWNoCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50 aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkKdXNlIG9mIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1p dGVkCnRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlz c2VtaW5hdGlvbikgYnkgcGVyc29ucwpvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQn cykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwKaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSBwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQg ZGVsZXRlIGl0ITwvc3Bhbj48L2ZvbnQ+PC9wPgoKPC9kaXY+Cgo8cCBzdHlsZT0ibWFyZ2luLWxl ZnQ6IDFpbjsiPjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYTsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPgo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5Gcm9tOjwvc3Bhbj48 L2I+IDxhIGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi IG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5p ZHItYm91bmNlc0BpZXRmLm9yZzwvYT4KW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5F eHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj48 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvYj5N YW5lZXNoCkNoYXdsYTxicj4KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+U2Vu dDo8L3NwYW4+PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDEwLCAyMDA2CjQ6MzIgUE08YnI+CjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPlRvOjwvc3Bhbj48L2I+IDxhIGhyZWY9Im1h aWx0bzppZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpz Lk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aWRyQGlldGYub3JnPC9hPjxicj4KPGI+ PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+U3ViamVjdDo8L3NwYW4+PC9iPiBbSWRy XSBBZ2dyZWdhdGlvbiBhbmQKZGFtcGVuaW5nPC9zcGFuPjwvZm9udD48L3A+Cgo8cCBzdHlsZT0i bWFyZ2luLWxlZnQ6IDFpbjsiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgoK PHAgc3R5bGU9Im1hcmdpbi1sZWZ0OiAxaW47Ij48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij5IaSBBbGwsPGJyPgombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg SSBoYXZlIGEgcXVlc3Rpb24Kb24gYWdncmVnYXRpb24gYW5kIGRhbXBlbmluZy48YnI+Cjxicj4K Q29uc2lkZXIgdGhlIHRvcG9sb2d5LDxicj4KPGJyPgpSMS0tLS0tUjMtLS0tLS0tUjQ8YnI+CiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PGJy PgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fDxicj4KUjItLS0tLS18PGJyPgo8YnI+Cjxicj4KMS4gUjEgYW5kIFIyIGFyZSBhZHZlcnRpc2lu ZyA8YSBocmVmPSJodHRwOi8vNjYuMC4wLjAvMzIiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJy ZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+NjYuMC4wLjAvMzI8 L2E+IGFuZCA8YSBocmVmPSJodHRwOi8vNjYuMC4wLjEvMzIiIHRhcmdldD0iX2JsYW5rIiBvbmNs aWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+CjY2LjAu MC4xLzMyPC9hPiB0byBSMyByZXNwZWN0aXZlbHkuPGJyPgoyLiBSMyBpcyBhZ2dyZWdhdGluZyB0 aGUgcm91dGVzICh3aXRoIHRoZSBhcy1zZXQgY29tbWFuZCApIGFuZCBhZHZlcnRpc2luZyB0bwpS NC4gU2luY2UgaXQgaXMgdXNpbmcgdGhlIGFzLXNldCBvcHRpb24sIGFsbCB0aGUgcGF0aCBhdHRy aWJ1dGVzIGFyZSBjb25zaWRlcmVkCmFuZCBpZiBvbmUgb2YgdGhlIHJvdXRlcyBmbGFwICwgc2F5 IHRoZSByb3V0ZSBmcm9tIFIyLCB0aGUgYWdncmVnYXRlIGZsYXAgdG8gUjQKd2lsbCBmbGFwLiA8 YnI+CjMuIE5vdyAsIGNvbm5maWd1cmUgZGFtcGVuaW5nIGFsc28gb24gUjMuIDxicj4KJm5ic3A7 Jm5ic3A7IDxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElz IGl0IHJpZ2h0IHRvIGV4cGVjdCB0aGF0IG5vdyB3aGVuCnRoZSByb3V0ZSBmcm9tIFIyIGZsYXBz LCBpdCBzaG91bGQgYmUgZGFtcGVkIHNvIGFzIHRvIG5vdCBhZmZlY3QgdGhlIGFnZ3JlZ2F0ZQo/ IFRvIHB1dCBpdCBtb3JlIGVsYWJvcmF0aXZlbHkgLCBzYXkmbmJzcDsgdGhlIHJvdXRlIGZyb20g UjIgZmxhcHMgYW5kIHJlYWNoZXMKc3VwcmVzcyB2YWx1ZSBhbmQgaXMgdGhlcmVieSBzdXBwcmVz c2VkLCBzaG91bGQgaXQgc3RpbGwgY29udHJpYnV0ZSB0byB0aGUKYWdncmVnYXRlIG9yIHN0b3Ag Y29udHJpYnV0aW5nIHRvIHRoZSBhZ2dyZWdhdGUgPyA8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJcyB0aGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljID88 YnI+Cjxicj4KVGhhbmtzPGJyPgpNYW5lZXNoPGJyPgo8YnI+CnAucyA6IFNvcnJ5ICwgaWYgaXQg aXMgYSB2ZXJ5IGJhc2ljIHF1ZXN0aW9uIGluIHRoaXMgZm9ydW0uPGJyPgombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvZm9udD48 L3A+Cgo8L3NwYW4+PC9kaXY+PC9kaXY+CgoKCgoKPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K ------=_Part_33363_23169604.1136958391489-- --===============1887269048== 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 --===============1887269048==-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA08233 for ; Wed, 11 Jan 2006 00:13:34 -0500 (EST) 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 1EwYIO-0003Cq-Pn; Wed, 11 Jan 2006 00:13:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwYIM-0003Cl-Rn for idr@megatron.ietf.org; Wed, 11 Jan 2006 00:13:14 -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 AAA13002 for ; Wed, 11 Jan 2006 00:11:54 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwYPB-0006J3-R9 for idr@ietf.org; Wed, 11 Jan 2006 00:20:19 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2006011105125401100dcmn4e>; Wed, 11 Jan 2006 05:12:55 +0000 In-Reply-To: <43C46D52.9090707@cisco.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <43C469A2.8000005@cisco.com> <43C46C27.9020002@cisco.com> <43C46D52.9090707@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Tue, 10 Jan 2006 21:12:53 -0800 To: Enke Chen X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Russ White 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 > It seems to me that the "decrementor" as previously defined is > simpler. In addition to Joe's comments... The problem that we had with decrementing the hopcount is that the semantics of this got VERY messy when we also tried to take into account partial deployment. Which AS's decrement? Which routers within the AS decrement? It all depends on the software rev of each individual router. You could have two routers from the same AS that advertise the same prefix to you with two different hopcounts, all based on the same original advertisement. Having a static constant in the attribute is simpler, in that the first receiver that supports PATHLIMIT that sees a too-long AS_PATH can discard the route. There is no ambiguity about the semantics. Yes, we need to deal with prepend, but whatever way we choose, the semantics are straightforward. And if there is *ANYTHING* that my years of experience have taught me, it's to favor the straightforward semantics. ;-) Tony p.s. I should also point out that this issue was discussed on the mailing list a few weeks ago. The consensus on this issue seemed pretty clear to me. Folks in favor of decrement were NOT speaking up. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA07578 for ; Tue, 10 Jan 2006 22:30:55 -0500 (EST) 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 1EwWhK-0005rX-I5; Tue, 10 Jan 2006 22:30:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwWhI-0005qE-Jf for idr@megatron.ietf.org; Tue, 10 Jan 2006 22:30:52 -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 WAA06844 for ; Tue, 10 Jan 2006 22:29:33 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwWo8-0003RH-4T for idr@ietf.org; Tue, 10 Jan 2006 22:37:56 -0500 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EwWh9-0002h2-3f; Wed, 11 Jan 2006 03:30:43 +0000 In-Reply-To: <43C46D52.9090707@cisco.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <43C469A2.8000005@cisco.com> <43C46C27.9020002@cisco.com> <43C46D52.9090707@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <073C64FB-29F9-442C-B8C0-96FD9F5F9384@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Tue, 10 Jan 2006 22:30:41 -0500 To: Enke Chen X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Tony Li , Russ White 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 On 10-Jan-2006, at 21:28, Enke Chen wrote: > It seems to me that the "decrementor" as previously defined is > simpler. I think they are both fairly simple. I think that bounding the AS_PATH length has greater chance of being useful in the short term for applications where propagating too little is greatly preferred over propagating too widely (e.g. "local nodes" providing anycast service distribution): the AS-count variable (AS_PATH) continues to happen in routers without this new functionality. By comparison, the decrementor behaviour (without the NO_EXPORT interaction, which was intended to bridge the implementation gap) will need quite substantial deployment before it can be used for the anycast node application. Clearly anycast nodes are not the only potential consumers of this mechanism, but it seems like a shame not to accommodate their requirements if we can. Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA07507 for ; Tue, 10 Jan 2006 22:24:27 -0500 (EST) 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 1EwWXz-00049H-9e; Tue, 10 Jan 2006 22:21:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwWXx-000498-8z for idr@megatron.ietf.org; Tue, 10 Jan 2006 22:21:13 -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 WAA06123 for ; Tue, 10 Jan 2006 22:19:54 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwWel-000375-KY for idr@ietf.org; Tue, 10 Jan 2006 22:28:17 -0500 Received: from octopus.hopcount.ca ([199.212.90.5]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EwWXa-0002QP-IQ; Wed, 11 Jan 2006 03:20:51 +0000 In-Reply-To: <43C469A2.8000005@cisco.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <43C469A2.8000005@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A88B2AA-B26A-40BC-BA41-A2DDB4FFE5B2@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Tue, 10 Jan 2006 22:20:49 -0500 To: Enke Chen X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Tony Li 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 On 10-Jan-2006, at 21:12, Enke Chen wrote: > Tony Li wrote: > >> - Convert AS_HOPCOUNT from being decremented at each AS boundary >> and instead have it be a static upper bound on the AS path length. > > not clear to me how this would work with "ASPATH prepend", > especially in an environment where some routers recognize the new > attribute, and some do not (thus can not adjust the hopcount with > prepend). I think the intention of Tony's text is clearer if it is rephrased as "static upper bound on the length of the modified AS_PATH attribute", where the modification referred to is the elimination of private-use numbers, etc. > More specifically, consider a routing announcement from A --> B --> > C -- > D --> E, each has its own AS (say a, b, c, d, e respectively). > > 1) Router A recognizes the attribute, and set the hopcount to 5 > with the intention for the announcement to reach E. > 2) Router B does not recognize the attribute, thus would pass the > new attribute. But it does AS prepend toward C, and the ASPATH > would be: b b b b a > 3) Router C recognize the attribute, and would not advertise the > route to D due to the hopcount. Correct. > On the other hand, the AS_HOPCOUNT as a decrementor does not have > this loss of connectivity issue. When viewed from another angle, AS_HOPCOUNT as decrementor fails to take account of the fact that B is prepending towards C (presumably for a reason). It does not seem inconsistent with the intentions of A's operator for the route to be dropped in this case before it reaches E. Even with more elaborate mechanisms at your disposal, when you're second-guessign the routing policies of remote networks, the best you can do is try to influence propagation. There is no absolute control. Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA07100 for ; Tue, 10 Jan 2006 21:53:43 -0500 (EST) 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 1EwW3M-0003hV-UT; Tue, 10 Jan 2006 21:49:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwW3M-0003hQ-4D for idr@megatron.ietf.org; Tue, 10 Jan 2006 21:49:36 -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 VAA04257 for ; Tue, 10 Jan 2006 21:48:15 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwWAB-0002IW-9t for idr@ietf.org; Tue, 10 Jan 2006 21:56:39 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 10 Jan 2006 18:49:27 -0800 X-IronPort-AV: i="3.99,352,1131350400"; d="scan'208"; a="1765409113:sNHT31477060" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0B2nQQV028380; Tue, 10 Jan 2006 18:49:26 -0800 (PST) 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.211); Tue, 10 Jan 2006 18:49:14 -0800 Received: from [128.107.163.59] ([128.107.163.59]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 Jan 2006 18:49:14 -0800 Message-ID: <43C47242.5030801@cisco.com> Date: Tue, 10 Jan 2006 18:49:38 -0800 From: Keyur User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Enke Chen Subject: Re: [Idr] Next revision of AS_HOPCOUNT References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <43C469A2.8000005@cisco.com> In-Reply-To: <43C469A2.8000005@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2006 02:49:14.0108 (UTC) FILETIME=[9B5CABC0:01C61659] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Tony Li 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 Enke: Enke Chen wrote: > Hi, Tony: > > Tony Li wrote: > >> >> Hi folks, >> >> Based on the discussion that we've had so far, the authors of the >> AS_HOPCOUNT draft would >> like to make some substantive changes to the draft. The chairs have >> asked that we poll you to >> ensure that we have rough consensus on the new direction. The primary >> technical points of >> these changes: >> >> - Convert AS_HOPCOUNT from being decremented at each AS boundary and >> instead have it >> be a static upper bound on the AS path length. > > > > It is not clear to me how this would work with "ASPATH prepend", > especially in an environment where some routers recognize the new > attribute, and some do not (thus can not adjust the hopcount with prepend). > > More specifically, consider a routing announcement from A --> B --> C -- > > D --> E, each has its own AS (say a, b, c, d, e respectively). > > 1) Router A recognizes the attribute, and set the hopcount to 5 with the > intention for the announcement to reach E. > 2) Router B does not recognize the attribute, thus would pass the new > attribute. But it does AS prepend toward C, and the ASPATH would be: b b > b b a Would it be too bad to modify the hopcount at this point to reflect the number of prepend ASes? -Keyur > 3) Router C recognize the attribute, and would not advertise the route > to D due to the hopcount. > > On the other hand, the AS_HOPCOUNT as a decrementor does not have this > loss of connectivity issue. > > -- Enke > > > _______________________________________________ > 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 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA06905 for ; Tue, 10 Jan 2006 21:29:19 -0500 (EST) 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 1EwVjC-0004Nm-I1; Tue, 10 Jan 2006 21:28:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwVjB-0004Ne-B8 for idr@megatron.ietf.org; Tue, 10 Jan 2006 21:28:45 -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 VAA02727 for ; Tue, 10 Jan 2006 21:27:24 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwVpy-0001fx-WB for idr@ietf.org; Tue, 10 Jan 2006 21:35:48 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2006 18:28:34 -0800 X-IronPort-AV: i="3.99,352,1131350400"; d="scan'208"; a="248253409:sNHT31803228" Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0B2SYWF009101; Tue, 10 Jan 2006 18:28:34 -0800 (PST) Message-ID: <43C46D52.9090707@cisco.com> Date: Tue, 10 Jan 2006 18:28:34 -0800 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ White Subject: Re: [Idr] Next revision of AS_HOPCOUNT References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <43C469A2.8000005@cisco.com> <43C46C27.9020002@cisco.com> In-Reply-To: <43C46C27.9020002@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List , Tony Li 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 Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > > >>>Based on the discussion that we've had so far, the authors of the >>>AS_HOPCOUNT draft would >>>like to make some substantive changes to the draft. The chairs have >>>asked that we poll you to >>>ensure that we have rough consensus on the new direction. The primary >>>technical points of >>>these changes: >>> >>>- Convert AS_HOPCOUNT from being decremented at each AS boundary and >>>instead have it >>>be a static upper bound on the AS path length. >>> >>> >>It is not clear to me how this would work with "ASPATH prepend", >>especially in an environment where some routers recognize the new >>attribute, and some do not (thus can not adjust the hopcount with prepend). >> >>More specifically, consider a routing announcement from A --> B --> C -- >> > D --> E, each has its own AS (say a, b, c, d, e respectively). >> >>1) Router A recognizes the attribute, and set the hopcount to 5 with the >>intention for the announcement to reach E. >>2) Router B does not recognize the attribute, thus would pass the new >>attribute. But it does AS prepend toward C, and the ASPATH would be: b b >>b b a >>3) Router C recognize the attribute, and would not advertise the route >>to D due to the hopcount. >> >>On the other hand, the AS_HOPCOUNT as a decrementor does not have this >>loss of connectivity issue. >> >> > >It seems to me that what you want is the "absolute length" of the AS >Path--the number of unique AS' in the path--rather than the "literal >length." I know most implemenations (no implementations?) can do this >today, but the absolute length seems like the only way to actually make >the as hop count work in all situations. > > What if the prepend is "x y z" instead? It seems to me that the "decrementor" as previously defined is simpler. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA06899 for ; Tue, 10 Jan 2006 21:26:32 -0500 (EST) 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 1EwVeY-0003uR-SV; Tue, 10 Jan 2006 21:23:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwVeX-0003u7-2j for idr@megatron.ietf.org; Tue, 10 Jan 2006 21:23:57 -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 VAA02346 for ; Tue, 10 Jan 2006 21:22:35 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwVlK-0001X5-It for idr@ietf.org; Tue, 10 Jan 2006 21:30:59 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2006 21:23:47 -0500 X-IronPort-AV: i="3.99,352,1131339600"; d="scan'208"; a="79989641:sNHT30693868" Received: from RussPC (rtp-vpn2-288.cisco.com [10.82.241.32]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0B2NfJg007959; Tue, 10 Jan 2006 21:23:44 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Tue, 10 Jan 2006 21:23:43 -0500 X-PGP-Universal: processed; by RussPC on Tue, 10 Jan 2006 21:23:43 -0500 Message-ID: <43C46C27.9020002@cisco.com> Date: Tue, 10 Jan 2006 21:23:35 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Enke Chen Subject: Re: [Idr] Next revision of AS_HOPCOUNT References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <43C469A2.8000005@cisco.com> In-Reply-To: <43C469A2.8000005@cisco.com> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Inter-Domain Routing List , Tony Li 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Based on the discussion that we've had so far, the authors of the >> AS_HOPCOUNT draft would >> like to make some substantive changes to the draft. The chairs have >> asked that we poll you to >> ensure that we have rough consensus on the new direction. The primary >> technical points of >> these changes: >> >> - Convert AS_HOPCOUNT from being decremented at each AS boundary and >> instead have it >> be a static upper bound on the AS path length. > > It is not clear to me how this would work with "ASPATH prepend", > especially in an environment where some routers recognize the new > attribute, and some do not (thus can not adjust the hopcount with prepend). > > More specifically, consider a routing announcement from A --> B --> C -- > > D --> E, each has its own AS (say a, b, c, d, e respectively). > > 1) Router A recognizes the attribute, and set the hopcount to 5 with the > intention for the announcement to reach E. > 2) Router B does not recognize the attribute, thus would pass the new > attribute. But it does AS prepend toward C, and the ASPATH would be: b b > b b a > 3) Router C recognize the attribute, and would not advertise the route > to D due to the hopcount. > > On the other hand, the AS_HOPCOUNT as a decrementor does not have this > loss of connectivity issue. It seems to me that what you want is the "absolute length" of the AS Path--the number of unique AS' in the path--rather than the "literal length." I know most implemenations (no implementations?) can do this today, but the absolute length seems like the only way to actually make the as hop count work in all situations. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8RsLxEdu7FIVPTkEQLvJQCgjrvrHZGwcrHl5noaXyg7/HWDFXUAoMov kyDY2aCYTaqV4Slggkn87RtV =kzMf -----END PGP SIGNATURE----- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA06649 for ; Tue, 10 Jan 2006 21:15:51 -0500 (EST) 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 1EwVUy-0000lM-95; Tue, 10 Jan 2006 21:14:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwVUx-0000lF-6c for idr@megatron.ietf.org; Tue, 10 Jan 2006 21:14:03 -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 VAA01735 for ; Tue, 10 Jan 2006 21:12:42 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwVbj-0001Ge-3C for idr@ietf.org; Tue, 10 Jan 2006 21:21:06 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2006 18:12:50 -0800 X-IronPort-AV: i="3.99,352,1131350400"; d="scan'208"; a="248245940:sNHT3593341874" Received: from [128.107.134.9] (enke-linux.cisco.com [128.107.134.9]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0B2CoWF002410; Tue, 10 Jan 2006 18:12:50 -0800 (PST) Message-ID: <43C469A2.8000005@cisco.com> Date: Tue, 10 Jan 2006 18:12:50 -0800 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> In-Reply-To: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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, Tony: Tony Li wrote: > > Hi folks, > > Based on the discussion that we've had so far, the authors of the > AS_HOPCOUNT draft would > like to make some substantive changes to the draft. The chairs have > asked that we poll you to > ensure that we have rough consensus on the new direction. The primary > technical points of > these changes: > > - Convert AS_HOPCOUNT from being decremented at each AS boundary and > instead have it > be a static upper bound on the AS path length. It is not clear to me how this would work with "ASPATH prepend", especially in an environment where some routers recognize the new attribute, and some do not (thus can not adjust the hopcount with prepend). More specifically, consider a routing announcement from A --> B --> C -- > D --> E, each has its own AS (say a, b, c, d, e respectively). 1) Router A recognizes the attribute, and set the hopcount to 5 with the intention for the announcement to reach E. 2) Router B does not recognize the attribute, thus would pass the new attribute. But it does AS prepend toward C, and the ASPATH would be: b b b b a 3) Router C recognize the attribute, and would not advertise the route to D due to the hopcount. On the other hand, the AS_HOPCOUNT as a decrementor does not have this loss of connectivity issue. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA06050 for ; Tue, 10 Jan 2006 19:41:38 -0500 (EST) 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 1EwU0L-0003cd-3q; Tue, 10 Jan 2006 19:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwU0I-0003cY-TX for idr@megatron.ietf.org; Tue, 10 Jan 2006 19:38:19 -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 TAA25587 for ; Tue, 10 Jan 2006 19:36:58 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19/5jkSo7hMyfBRTxJIQ/Msv+76A6VH6u8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwU75-0006xs-8u for idr@ietf.org; Tue, 10 Jan 2006 19:45:21 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+wPzMTr5Z9Fb1UHM6fhYv8PGDRIc61rds@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k0B0bhMi016497; Wed, 11 Jan 2006 00:37:50 GMT Date: Wed, 11 Jan 2006 00:37:43 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT In-Reply-To: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Message-ID: References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="299119927-197416382-1136939863=:3405" X-Virus-Scanned: ClamAV 0.87.1/1237/Tue Jan 10 15:53:20 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Inter-Domain Routing List 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --299119927-197416382-1136939863=:3405 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by hibernia.jakma.org id k0B0bhMi016497 Content-Transfer-Encoding: quoted-printable On Tue, 10 Jan 2006, Tony Li wrote: > - Convert AS_HOPCOUNT from being decremented at each AS boundary=20 > and instead have it be a static upper bound on the AS path length. Hmm, a simple decrement seems nicer. I hate dependencies between attributes, particularly (here) on the=20 relatively vague property of path length. If you have to depend on=20 some other attribute, I'd prefer the no-export interaction/dependency=20 to this one. My =E2=82=AC0.02 anyway. regards, --=20 Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: On Thanksgiving Day all over America, families sit down to dinner at the same moment -- halftime. --299119927-197416382-1136939863=:3405 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 --299119927-197416382-1136939863=:3405-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA05326 for ; Tue, 10 Jan 2006 18:03:37 -0500 (EST) 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 1EwSTi-0005pf-CN; Tue, 10 Jan 2006 18:00:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwSTg-0005pa-MY for idr@megatron.ietf.org; Tue, 10 Jan 2006 18:00:33 -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 RAA16911 for ; Tue, 10 Jan 2006 17:59:13 -0500 (EST) Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwSaS-0003RF-UQ for idr@ietf.org; Tue, 10 Jan 2006 18:07:34 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2006011023001001200jqb1le>; Tue, 10 Jan 2006 23:00:11 +0000 In-Reply-To: <20060110223708.GB12691@nexthop.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> <20060110223708.GB12691@nexthop.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Tue, 10 Jan 2006 15:00:08 -0800 To: Jeffrey Haas X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 Jeffrey, > Another comment (Danny I think) spoke about where we check the > value. If the value was checked upon egress, then we can avoid > sending the route to a downstream BGP speaker that may not understand > the attribute. This is also addressed in the revised draft, but is actually more of an implementation issue. > (Checking the value upon ingress in addition to egress is probably > a safe thing to do.) Yes, the revised draft specifies both checks. > Another previous comment suggests that we may not simply want to rely > on the behavior of BGP speakers that understand the feature to > decrement the value, but that we may wish to decrement it when > we think that it may not have been decremented for us. If > confederations > weren't a condition upon which the value was decremented, then it > would be possible to use the number of distinct ASes after the > advisory value to determine if the count was what we expected. This was exactly why we were shifting to a static value and way from decrement. > The 4 byte AS number in the attribute is probably a good idea. > However, we should carefully explain the behavior when the 4 byte > AS must be utilized by a 2byte speaker. The draft references the encoding rules used in the 4 octet draft. > Like Danny, I would prefer that confederation boundaries be ignored > for purposes of the count. However, this is also something I expect > that vendors may prefer to implement a knob to affect the behavior. The revised draft specifies that confederations be ignored. Extensions on top of this are, as you note, optional and perhaps inevitable. > I think it would be good to specify behavior when aggregating routes > containing this attribute. > > Your text regarding ATOMIC_AGGREGATE seems very 1771'ish. The current > text on ATOMIC_AGGREGATE isn't quite as stringent on how this > attribute is set. You'll pardon me if my paranoia regarding deaggregation hasn't abated in the last 15 years. ;-) If you feel additional text is warranted, contributions are most welcome. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA05064 for ; Tue, 10 Jan 2006 17:42:52 -0500 (EST) 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 1EwS7Z-0000Yy-UU; Tue, 10 Jan 2006 17:37:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwS7Y-0000Yt-3M for idr@megatron.ietf.org; Tue, 10 Jan 2006 17:37:40 -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 RAA15269 for ; Tue, 10 Jan 2006 17:36:20 -0500 (EST) Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwSEI-0002gO-G8 for idr@ietf.org; Tue, 10 Jan 2006 17:44:41 -0500 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id E198C3442; Tue, 10 Jan 2006 22:37:12 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 493kaJwlL0364Mo1; Tue, 10 Jan 2006 22:37:11 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 489kaJwlJ0364Mo1; Tue, 10 Jan 2006 22:37:09 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.27I); Tue, 10 Jan 2006 22:37:09 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID618kaJwlJ2112Xo1 Received: from localhost ([65.247.36.31]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 Jan 2006 15:37:09 -0700 Date: Tue, 10 Jan 2006 17:37:08 -0500 From: Jeffrey Haas To: Tony Li Subject: Re: [Idr] Next revision of AS_HOPCOUNT Message-ID: <20060110223708.GB12691@nexthop.com> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 10 Jan 2006 22:37:09.0345 (UTC) FILETIME=[644CFD10:01C61636] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Inter-Domain Routing List 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, Apologies for not chiming in earlier. Vacations and all that. :-) My comments for the proposed feature are interspersed and cover a number of previous e-mails. On Tue, Jan 10, 2006 at 12:35:57PM -0800, Tony Li wrote: > - Convert AS_HOPCOUNT from being decremented at each AS boundary and > instead have it > be a static upper bound on the AS path length. > > - Rename the attribute to AS_PATHLIMIT. I prefer the decrement behavior. > - Completely remove the interaction with NO_EXPORT. I would agree. John Leslie brought up an interesting case that it woule be safe to simply set NO_EXPORT when hopcount was 1 and we are propagating the route. It helps to guarantee that the next AS will not propagate it, even if it doesn't understand the AS_HOPCOUNT attribute. Another comment (Danny I think) spoke about where we check the value. If the value was checked upon egress, then we can avoid sending the route to a downstream BGP speaker that may not understand the attribute. (Checking the value upon ingress in addition to egress is probably a safe thing to do.) Another previous comment suggests that we may not simply want to rely on the behavior of BGP speakers that understand the feature to decrement the value, but that we may wish to decrement it when we think that it may not have been decremented for us. If confederations weren't a condition upon which the value was decremented, then it would be possible to use the number of distinct ASes after the advisory value to determine if the count was what we expected. In the following example, presume that the BGP speaker doesn't propagate the route if the decremented value would be zero. (Change from the spec in-line with my comments above.) E.g.: A --- B --- C --- D --- E If A sets the value to 2, we would expect B and C to receive the route and AS-A would be in the attribute. If C doesn't understand the attribute, but D does, D can examine the AS_PATH C B A and determine that the expected hop count has already been exceeded. Padding would need to be accounted for, so padding would need to be ignored when determining the number of ASes that have been transited. Other comments: The 4 byte AS number in the attribute is probably a good idea. However, we should carefully explain the behavior when the 4 byte AS must be utilized by a 2byte speaker. Like Danny, I would prefer that confederation boundaries be ignored for purposes of the count. However, this is also something I expect that vendors may prefer to implement a knob to affect the behavior. I think it would be good to specify behavior when aggregating routes containing this attribute. Your text regarding ATOMIC_AGGREGATE seems very 1771'ish. The current text on ATOMIC_AGGREGATE isn't quite as stringent on how this attribute is set. -- Jeff Haas NextHop Technologies _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA04287 for ; Tue, 10 Jan 2006 16:06:19 -0500 (EST) 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 1EwQbW-0003Dd-7H; Tue, 10 Jan 2006 16:00:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQbU-0003DY-ES for idr@megatron.ietf.org; Tue, 10 Jan 2006 16:00: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 PAA08285 for ; Tue, 10 Jan 2006 15:59:07 -0500 (EST) Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQiF-000880-N5 for idr@ietf.org; Tue, 10 Jan 2006 16:07:28 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2006011021001401200jovr4e>; Tue, 10 Jan 2006 21:00:15 +0000 In-Reply-To: <43C41E9F.7080007@redback.com> References: <43C41E9F.7080007@redback.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0DB0660B-408E-4EA9-8BDF-E7564D67B3F6@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] Cisco BGP question Date: Tue, 10 Jan 2006 13:00:12 -0800 To: Vikram Reddy X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Please contact Cisco technical support. Tony On Jan 10, 2006, at 12:52 PM, Vikram Reddy wrote: > Hello folks, > > I have a question about Cisco's implementation of BGP. > > Is automatic start enabled by default in Cisco BGP? > i.e if a BGP session goes to idle, does Cisco > generate BGP start events automatically or is it only > with manual intervention. > > If the default is not to automatically generate start events, > what is the command to enable it on Cisco. > > Thanks, > Vikram. > > _______________________________________________ > 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 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA04265 for ; Tue, 10 Jan 2006 16:05:08 -0500 (EST) 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 1EwQZ5-0002fc-9G; Tue, 10 Jan 2006 15:57:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQZ3-0002fO-KQ for idr@megatron.ietf.org; Tue, 10 Jan 2006 15:57:57 -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 PAA07847 for ; Tue, 10 Jan 2006 15:56:36 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQfo-0007uV-Dv for idr@ietf.org; Tue, 10 Jan 2006 16:04:57 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id A31C0642DD for ; Tue, 10 Jan 2006 13:57:29 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> References: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7267AF7C-6671-4379-9FDC-7BC693F8B35F@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] Next revision of AS_HOPCOUNT Date: Tue, 10 Jan 2006 13:57:43 -0700 To: Inter-Domain Routing List X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit 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 On Jan 10, 2006, at 1:35 PM, Tony Li wrote: > > Could folks please comment to the list within the next two weeks as > to whether or not this direction > is acceptable? As this is to help gauge consensus, both positive > and negative comments are > solicited. For sake of progress: I'm in favor of all these changes to the draft... -------------- For sake of other: I'm surprised you're being asked to poll the WG before instituting them. Out of curiosity, how many hands are required to move forward? And is there some pre-determined percentage of in-favor/not-in-favor that dictates reasonable consensus in the face of contention? It's just that I'd really rather not see the noise - if folks take issue with these changes shouldn't they comment when said issues are being discussed? -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA04217 for ; Tue, 10 Jan 2006 16:02:31 -0500 (EST) 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 1EwQUS-0001UR-Hb; Tue, 10 Jan 2006 15:53:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQUR-0001UM-Go for idr@megatron.ietf.org; Tue, 10 Jan 2006 15:53:11 -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 PAA07281 for ; Tue, 10 Jan 2006 15:51:50 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQbC-0007bJ-CM for idr@ietf.org; Tue, 10 Jan 2006 16:00:11 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 485A72301B1 for ; Tue, 10 Jan 2006 12:52:54 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13849-02 for ; Tue, 10 Jan 2006 12:52:53 -0800 (PST) Received: from [155.53.44.78] (horizon.redback.com [155.53.44.78]) by prattle.redback.com (Postfix) with ESMTP id BDD722301AD for ; Tue, 10 Jan 2006 12:52:47 -0800 (PST) Message-ID: <43C41E9F.7080007@redback.com> Date: Tue, 10 Jan 2006 12:52:47 -0800 From: Vikram Reddy User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Idr] Cisco BGP question 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 Hello folks, I have a question about Cisco's implementation of BGP. Is automatic start enabled by default in Cisco BGP? i.e if a BGP session goes to idle, does Cisco generate BGP start events automatically or is it only with manual intervention. If the default is not to automatically generate start events, what is the command to enable it on Cisco. Thanks, Vikram. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA03666 for ; Tue, 10 Jan 2006 15:40:26 -0500 (EST) 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 1EwQE5-0005YT-3L; Tue, 10 Jan 2006 15:36:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQE4-0005YA-CH for idr@megatron.ietf.org; Tue, 10 Jan 2006 15:36:16 -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 PAA06208 for ; Tue, 10 Jan 2006 15:34:55 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQKp-00077f-7M for idr@ietf.org; Tue, 10 Jan 2006 15:43:16 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2006011020355901200jqoqje>; Tue, 10 Jan 2006 20:36:00 +0000 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <5CDD0013-80AC-4947-AA89-2EDB6BE36181@tony.li> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Inter-Domain Routing List From: Tony Li Date: Tue, 10 Jan 2006 12:35:57 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 folks, Based on the discussion that we've had so far, the authors of the AS_HOPCOUNT draft would like to make some substantive changes to the draft. The chairs have asked that we poll you to ensure that we have rough consensus on the new direction. The primary technical points of these changes: - Convert AS_HOPCOUNT from being decremented at each AS boundary and instead have it be a static upper bound on the AS path length. - Rename the attribute to AS_PATHLIMIT. - Completely remove the interaction with NO_EXPORT. There are, of course, a number of details more fully explained in the revised draft, but before we are allowed to present you with the revision, we need to have your approval on the above. Could folks please comment to the list within the next two weeks as to whether or not this direction is acceptable? As this is to help gauge consensus, both positive and negative comments are solicited. Regards, Joe & Rex & Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA28666 for ; Tue, 10 Jan 2006 06:59:14 -0500 (EST) 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 1EwI7t-0006Nd-QC; Tue, 10 Jan 2006 06:57:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwI7r-0006NV-Us for idr@megatron.ietf.org; Tue, 10 Jan 2006 06:57: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 GAA24630 for ; Tue, 10 Jan 2006 06:56:00 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwIDo-0006Fs-Ru for idr@ietf.org; Tue, 10 Jan 2006 07:04:15 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISV00050LOMPR@szxga02-in.huawei.com> for idr@ietf.org; Tue, 10 Jan 2006 20:07:35 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISV0005NLOMU7@szxga02-in.huawei.com> for idr@ietf.org; Tue, 10 Jan 2006 20:07:34 +0800 (CST) Received: from AnjanKumar ([10.18.4.90]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISV00BV4LU7SJ@szxml01-in.huawei.com>; Tue, 10 Jan 2006 20:10:56 +0800 (CST) Date: Tue, 10 Jan 2006 17:26:15 +0530 From: Anjan Subject: RE: [Idr] Aggregation and dampening In-reply-to: <000501c615da$c82a5870$5a04120a@china.huawei.com> To: "'Maneesh Chawla'" , idr@ietf.org Message-id: <000501c615dc$dcc2f330$5a04120a@china.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: anjanhg@huawei.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2032315856==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============2032315856== Content-type: multipart/alternative; boundary="Boundary_(ID_Khtg2uogK/Clok/SWEwfNQ)" This is a multi-part message in MIME format. --Boundary_(ID_Khtg2uogK/Clok/SWEwfNQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Sorry, Dampened route I mean here is the 'route that just came out of Dampened state'.. ************************************************************************ *************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Anjan Sent: Tuesday, January 10, 2006 5:11 PM To: 'Maneesh Chawla'; idr@ietf.org Subject: RE: [Idr] Aggregation and dampening Hi Maneesh, I feel Dampening should be considered irrespective of what you are doing in aggregation. When dampening is configured, route can take two values Dampened or History. Dampened route is valid to advertise. History route is not valid to advertise. So whether the route can be considered for aggregation or not, depends on this state - dampened or history. With specific answer to your question, If the route is in Dampened state it should contribute for Aggregation. If it is in History state it should not contribute for Aggregation. Any different opinion in the group? Regards, Anjan ************************************************************************ *************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Maneesh Chawla Sent: Tuesday, January 10, 2006 4:32 PM To: idr@ietf.org Subject: [Idr] Aggregation and dampening Hi All, I have a question on aggregation and dampening. Consider the topology, R1-----R3-------R4 | | R2------| 1. R1 and R2 are advertising 66.0.0.0/32 and 66.0.0.1/32 to R3 respectively. 2. R3 is aggregating the routes (with the as-set command ) and advertising to R4. Since it is using the as-set option, all the path attributes are considered and if one of the routes flap , say the route from R2, the aggregate flap to R4 will flap. 3. Now , connfigure dampening also on R3. Is it right to expect that now when the route from R2 flaps, it should be damped so as to not affect the aggregate ? To put it more elaboratively , say the route from R2 flaps and reaches supress value and is thereby suppressed, should it still contribute to the aggregate or stop contributing to the aggregate ? Is this implementation specific ? Thanks Maneesh p.s : Sorry , if it is a very basic question in this forum. --Boundary_(ID_Khtg2uogK/Clok/SWEwfNQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Sorry, Dampened route I mean here is the ‘route that just came out of Dampened state’..

 

***************************************************************************************

            This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Anjan
Sent: Tuesday, January 10, 2006 5:11 PM
To: 'Maneesh Chawla'; idr@ietf.org
Subject: RE: [Idr] Aggregation and dampening

 

Hi Maneesh,

 

I feel Dampening should be considered irrespective of what you are doing in aggregation.

When dampening is configured, route can take two values Dampened or History.

Dampened route is valid to advertise.  History route is not valid to advertise.

 

So whether the route can be considered for aggregation or not, depends on this state – dampened or history.

 

With specific answer to your question, If the route is in Dampened state it should contribute for Aggregation.

If it is in History state it should not contribute for Aggregation.

 

Any different opinion in the group?

 

Regards,

Anjan

 

 

 

***************************************************************************************

            This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Maneesh Chawla
Sent: Tuesday, January 10, 2006 4:32 PM
To: idr@ietf.org
Subject: [Idr] Aggregation and dampening

 

Hi All,
           I have a question on aggregation and dampening.

Consider the topology,

R1-----R3-------R4
          |
          |
R2------|


1. R1 and R2 are advertising 66.0.0.0/32 and 66.0.0.1/32 to R3 respectively.
2. R3 is aggregating the routes (with the as-set command ) and advertising to R4. Since it is using the as-set option, all the path attributes are considered and if one of the routes flap , say the route from R2, the aggregate flap to R4 will flap.
3. Now , connfigure dampening also on R3.
  
        Is it right to expect that now when the route from R2 flaps, it should be damped so as to not affect the aggregate ? To put it more elaboratively , say  the route from R2 flaps and reaches supress value and is thereby suppressed, should it still contribute to the aggregate or stop contributing to the aggregate ?
        Is this implementation specific ?

Thanks
Maneesh

p.s : Sorry , if it is a very basic question in this forum.
         

--Boundary_(ID_Khtg2uogK/Clok/SWEwfNQ)-- --===============2032315856== 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 --===============2032315856==-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA28585 for ; Tue, 10 Jan 2006 06:42:15 -0500 (EST) 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 1EwHt0-0002ix-QP; Tue, 10 Jan 2006 06:41:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwHsz-0002ip-IB for idr@megatron.ietf.org; Tue, 10 Jan 2006 06:41:57 -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 GAA23804 for ; Tue, 10 Jan 2006 06:40:38 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwHzc-0005tw-8G for idr@ietf.org; Tue, 10 Jan 2006 06:48:53 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISV000J0KZZPR@szxga02-in.huawei.com> for idr@ietf.org; Tue, 10 Jan 2006 19:52:48 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISV00BUIKZZ82@szxga02-in.huawei.com> for idr@ietf.org; Tue, 10 Jan 2006 19:52:47 +0800 (CST) Received: from AnjanKumar ([10.18.4.90]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISV00D2UKZQEJ@szxml02-in.huawei.com>; Tue, 10 Jan 2006 19:52:39 +0800 (CST) Date: Tue, 10 Jan 2006 17:11:21 +0530 From: Anjan Subject: RE: [Idr] Aggregation and dampening In-reply-to: To: "'Maneesh Chawla'" , idr@ietf.org Message-id: <000501c615da$c82a5870$5a04120a@china.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: anjanhg@huawei.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1936300343==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org This is a multi-part message in MIME format. --===============1936300343== Content-type: multipart/alternative; boundary="Boundary_(ID_TZxtm6+OKF3xaH4R7VOBvA)" This is a multi-part message in MIME format. --Boundary_(ID_TZxtm6+OKF3xaH4R7VOBvA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi Maneesh, I feel Dampening should be considered irrespective of what you are doing in aggregation. When dampening is configured, route can take two values Dampened or History. Dampened route is valid to advertise. History route is not valid to advertise. So whether the route can be considered for aggregation or not, depends on this state - dampened or history. With specific answer to your question, If the route is in Dampened state it should contribute for Aggregation. If it is in History state it should not contribute for Aggregation. Any different opinion in the group? Regards, Anjan ************************************************************************ *************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Maneesh Chawla Sent: Tuesday, January 10, 2006 4:32 PM To: idr@ietf.org Subject: [Idr] Aggregation and dampening Hi All, I have a question on aggregation and dampening. Consider the topology, R1-----R3-------R4 | | R2------| 1. R1 and R2 are advertising 66.0.0.0/32 and 66.0.0.1/32 to R3 respectively. 2. R3 is aggregating the routes (with the as-set command ) and advertising to R4. Since it is using the as-set option, all the path attributes are considered and if one of the routes flap , say the route from R2, the aggregate flap to R4 will flap. 3. Now , connfigure dampening also on R3. Is it right to expect that now when the route from R2 flaps, it should be damped so as to not affect the aggregate ? To put it more elaboratively , say the route from R2 flaps and reaches supress value and is thereby suppressed, should it still contribute to the aggregate or stop contributing to the aggregate ? Is this implementation specific ? Thanks Maneesh p.s : Sorry , if it is a very basic question in this forum. --Boundary_(ID_TZxtm6+OKF3xaH4R7VOBvA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi Maneesh,

 

I feel Dampening should be considered irrespective of what you are doing in aggregation.

When dampening is configured, route can take two values Dampened or History.

Dampened route is valid to advertise.  History route is not valid to advertise.

 

So whether the route can be considered for aggregation or not, depends on this state – dampened or history.

 

With specific answer to your question, If the route is in Dampened state it should contribute for Aggregation.

If it is in History state it should not contribute for Aggregation.

 

Any different opinion in the group?

 

Regards,

Anjan

 

 

 

***************************************************************************************

            This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Maneesh Chawla
Sent: Tuesday, January 10, 2006 4:32 PM
To: idr@ietf.org
Subject: [Idr] Aggregation and dampening

 

Hi All,
           I have a question on aggregation and dampening.

Consider the topology,

R1-----R3-------R4
          |
          |
R2------|


1. R1 and R2 are advertising 66.0.0.0/32 and 66.0.0.1/32 to R3 respectively.
2. R3 is aggregating the routes (with the as-set command ) and advertising to R4. Since it is using the as-set option, all the path attributes are considered and if one of the routes flap , say the route from R2, the aggregate flap to R4 will flap.
3. Now , connfigure dampening also on R3.
  
        Is it right to expect that now when the route from R2 flaps, it should be damped so as to not affect the aggregate ? To put it more elaboratively , say  the route from R2 flaps and reaches supress value and is thereby suppressed, should it still contribute to the aggregate or stop contributing to the aggregate ?
        Is this implementation specific ?

Thanks
Maneesh

p.s : Sorry , if it is a very basic question in this forum.
         

--Boundary_(ID_TZxtm6+OKF3xaH4R7VOBvA)-- --===============1936300343== 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 --===============1936300343==-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA28397 for ; Tue, 10 Jan 2006 06:05:01 -0500 (EST) 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 1EwHGa-0002h8-AC; Tue, 10 Jan 2006 06:02:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwHGY-0002fQ-Ms for idr@megatron.ietf.org; Tue, 10 Jan 2006 06:02:14 -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 GAA21949 for ; Tue, 10 Jan 2006 06:00:55 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwHNE-0004zG-DI for idr@ietf.org; Tue, 10 Jan 2006 06:09:09 -0500 Received: by xproxy.gmail.com with SMTP id s9so2683754wxc for ; Tue, 10 Jan 2006 03:02:10 -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=JXoSbQmGrThx4hSZ3iFJZD35zWI0yuCqpKQ7fqC4s3CygNb2dNSWN31a/HAYE6Y4YlDcq9GxZTsp16Bm1qwWOilEKoUveJSC7KbKJDZQH7d3ViO4QKNlPYD71AjLPDBAHGYeygHBkFHxvpd727nuqt0Vqyt4WlZ7PWtZfbG/Ens= Received: by 10.70.91.7 with SMTP id o7mr6324399wxb; Tue, 10 Jan 2006 03:02:09 -0800 (PST) Received: by 10.70.70.13 with HTTP; Tue, 10 Jan 2006 03:02:09 -0800 (PST) Message-ID: Date: Tue, 10 Jan 2006 16:32:09 +0530 From: Maneesh Chawla To: idr@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Idr] Aggregation and dampening 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="===============1145428218==" Sender: idr-bounces@ietf.org Errors-To: idr-bounces@ietf.org --===============1145428218== Content-Type: multipart/alternative; boundary="----=_Part_14029_15889227.1136890929981" ------=_Part_14029_15889227.1136890929981 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All, I have a question on aggregation and dampening. Consider the topology, R1-----R3-------R4 | | R2------| 1. R1 and R2 are advertising 66.0.0.0/32 and 66.0.0.1/32 to R3 respectively= . 2. R3 is aggregating the routes (with the as-set command ) and advertising to R4. Since it is using the as-set option, all the path attributes are considered and if one of the routes flap , say the route from R2, the aggregate flap to R4 will flap. 3. Now , connfigure dampening also on R3. Is it right to expect that now when the route from R2 flaps, it should be damped so as to not affect the aggregate ? To put it more elaboratively , say the route from R2 flaps and reaches supress value and is thereby suppressed, should it still contribute to the aggregate or stop contributing to the aggregate ? Is this implementation specific ? Thanks Maneesh p.s : Sorry , if it is a very basic question in this forum. ------=_Part_14029_15889227.1136890929981 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All,
           I h= ave a question on aggregation and dampening.

Consider the topology,<= br>
R1-----R3-------R4
       &nbs= p;  |
          |
R= 2------|


1. R1 and R2 are advertising 66.0.0.0/32 and 66.0.0.1/32 to R3 re= spectively.
2. R3 is aggregating the routes (with the as-set command ) a= nd advertising to R4. Since it is using the as-set option, all the path att= ributes are considered and if one of the routes flap , say the route from R= 2, the aggregate flap to R4 will flap.
3. Now , connfigure dampening also on R3.
  
 &n= bsp;      Is it right to expect that now when the = route from R2 flaps, it should be damped so as to not affect the aggregate = ? To put it more elaboratively , say  the route from R2 flaps and reac= hes supress value and is thereby suppressed, should it still contribute to = the aggregate or stop contributing to the aggregate ?
        Is this implementation speci= fic ?

Thanks
Maneesh

p.s : Sorry , if it is a very basic q= uestion in this forum.
        &= nbsp;
------=_Part_14029_15889227.1136890929981-- --===============1145428218== 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 --===============1145428218==-- Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA17945 for ; Mon, 9 Jan 2006 15:26:07 -0500 (EST) 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 1Ew3Wk-0003VX-Id; Mon, 09 Jan 2006 15:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew3Wi-0003TN-KH for idr@megatron.ietf.org; Mon, 09 Jan 2006 15:22:00 -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 PAA19456 for ; Mon, 9 Jan 2006 15:20:42 -0500 (EST) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew3dG-0002ER-HF for idr@ietf.org; Mon, 09 Jan 2006 15:28:47 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id BB37619C5; Mon, 9 Jan 2006 20:21:36 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 271kaiuVI0334Mo2; Mon, 09 Jan 2006 20:21:35 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 264kaiuVh0334Mo2; Mon, 09 Jan 2006 20:21:33 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Mon, 09 Jan 2006 20:21:33 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID821kaiuVh4928Xo2 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by GW1.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 13:21:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Idr] BGP4 FSM question Date: Mon, 9 Jan 2006 13:21:29 -0700 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F0202C62633@VS4.EXCHPROD.USA.NET> Thread-Topic: [Idr] BGP4 FSM question Thread-Index: AcYVVrCANcPEBmX6SMC3ig+T9MYIiAAA2GmQ From: "Susan Hares" To: "Tony Li" , "Vikram Reddy" X-OriginalArrivalTime: 09 Jan 2006 20:21:32.0528 (UTC) FILETIME=[47F77F00:01C6155A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id PAA17945 Vikram: Collision state was fixed by working group. Please see draft. Draft is at RFC level. Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Tony Li Sent: Monday, January 09, 2006 2:45 PM To: Vikram Reddy Cc: idr@ietf.org Subject: Re: [Idr] BGP4 FSM question Please see draft-ietf-idr-bgp4-26.txt Tony On Jan 9, 2006, at 11:04 AM, Vikram Reddy wrote: > Hello folks, > > I had a question about the FSM in BGP-4. > I am not sure, but was there was a problem > in BGP 4 (RFC 177) with the FSM collision detection rules? > > According to what I vaguely remember, there was particular > sequence of message passing between peers which > would result in both of them getting stuck in the > active state. > > This was supposed to be addressed in the later idr drafts. > > Could you please comment on this and let me know if > I am right or wrong? > > Thanks. > Vikram. > > _______________________________________________ > 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA17700 for ; Mon, 9 Jan 2006 14:45:45 -0500 (EST) 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 1Ew2xK-0001Ue-Lf; Mon, 09 Jan 2006 14:45:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2xJ-0001Sw-1j for idr@megatron.ietf.org; Mon, 09 Jan 2006 14:45: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 OAA15965 for ; Mon, 9 Jan 2006 14:44:05 -0500 (EST) Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew33q-00015f-NK for idr@ietf.org; Mon, 09 Jan 2006 14:52:12 -0500 Received: from [192.168.0.2] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with SMTP id <2006010919450001400sbsrle>; Mon, 9 Jan 2006 19:45:03 +0000 In-Reply-To: <43C2B3B7.6030504@redback.com> References: <43C2B3B7.6030504@redback.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] BGP4 FSM question Date: Mon, 9 Jan 2006 11:44:56 -0800 To: Vikram Reddy X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Please see draft-ietf-idr-bgp4-26.txt Tony On Jan 9, 2006, at 11:04 AM, Vikram Reddy wrote: > Hello folks, > > I had a question about the FSM in BGP-4. > I am not sure, but was there was a problem > in BGP 4 (RFC 177) with the FSM collision detection rules? > > According to what I vaguely remember, there was particular > sequence of message passing between peers which > would result in both of them getting stuck in the > active state. > > This was supposed to be addressed in the later idr drafts. > > Could you please comment on this and let me know if > I am right or wrong? > > Thanks. > Vikram. > > _______________________________________________ > 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 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA17507 for ; Mon, 9 Jan 2006 14:09:35 -0500 (EST) 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 1Ew2Jw-0005oX-4N; Mon, 09 Jan 2006 14:04:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew2Ju-0005oS-Th for idr@megatron.ietf.org; Mon, 09 Jan 2006 14:04:42 -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 OAA12519 for ; Mon, 9 Jan 2006 14:03:23 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew2QS-0008E9-DN for idr@ietf.org; Mon, 09 Jan 2006 14:11:29 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0D596C27F69 for ; Mon, 9 Jan 2006 11:04:24 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16768-07 for ; Mon, 9 Jan 2006 11:04:23 -0800 (PST) Received: from [155.53.44.78] (horizon.redback.com [155.53.44.78]) by prattle.redback.com (Postfix) with ESMTP id 879B6C27F6A for ; Mon, 9 Jan 2006 11:04:23 -0800 (PST) Message-ID: <43C2B3B7.6030504@redback.com> Date: Mon, 09 Jan 2006 11:04:23 -0800 From: Vikram Reddy User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [Idr] BGP4 FSM question 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 Hello folks, I had a question about the FSM in BGP-4. I am not sure, but was there was a problem in BGP 4 (RFC 177) with the FSM collision detection rules? According to what I vaguely remember, there was particular sequence of message passing between peers which would result in both of them getting stuck in the active state. This was supposed to be addressed in the later idr drafts. Could you please comment on this and let me know if I am right or wrong? Thanks. Vikram. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA28314 for ; Thu, 5 Jan 2006 09:44:03 -0500 (EST) 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 1EuWJW-00041t-Fc; Thu, 05 Jan 2006 09:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWJU-00040A-Kd for idr@megatron.ietf.org; Thu, 05 Jan 2006 09:42:00 -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 JAA22009 for ; Thu, 5 Jan 2006 09:40:44 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuWPB-0004kR-6m for idr@ietf.org; Thu, 05 Jan 2006 09:47:54 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 4DB2F642DD; Thu, 5 Jan 2006 07:41:40 -0700 (MST) In-Reply-To: <2A3B5B0E-9BA1-4DB4-B888-D133209AC923@tony.li> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> <732A8281-5ED8-4A56-ADF6-B4EE0EEBFACF@tcb.net> <78082F50-87EC-4693-9BD5-FBDDAD086DDE@isc.org> <80CB3777-FCC2-4388-800E-E72FB585 233F@tcb.net> <2A3B5B0E-9BA1-4DB4-B888-D133209AC923@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Thu, 5 Jan 2006 07:41:51 -0700 To: Tony Li X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 On Jan 5, 2006, at 1:57 AM, Tony Li wrote: > > Danny, > > I would word it so that the hopcount explicitly does NOT count > private ASs or confederation ASs. > AS sets would still count as one hop per set member. > > Does that match what you're saying? Yes! -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA26193 for ; Thu, 5 Jan 2006 04:02:42 -0500 (EST) 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 1EuQw5-0002XO-0H; Thu, 05 Jan 2006 03:57:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQw3-0002XJ-Nh for idr@megatron.ietf.org; Thu, 05 Jan 2006 03:57:27 -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 DAA13742 for ; Thu, 5 Jan 2006 03:56:10 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuR1g-0001Gu-Oz for idr@ietf.org; Thu, 05 Jan 2006 04:03:18 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2006010508570601200jk0cpe>; Thu, 5 Jan 2006 08:57:06 +0000 In-Reply-To: <80CB3777-FCC2-4388-800E-E72FB585233F@tcb.net> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> <732A8281-5ED8-4A56-ADF6-B4EE0EEBFACF@tcb.net> <78082F50-87EC-4693-9BD5-FBDDAD086DDE@isc.org> <80CB3777-FCC2-4388-800E-E72FB58! 5233F@tcb.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A3B5B0E-9BA1-4DB4-B888-D133209AC923@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Thu, 5 Jan 2006 00:57:03 -0800 To: Danny McPherson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 >> As someone else here suggested (and as Tony pointed out to me) >> changing the AS_HOPCOUNT attribute to represent an upper bound on >> the length of an AS_PATH (and discarding the NO_EXPORT >> interaction) might be a useful compromise, since a prefix leaked >> by a non-AS_HOPCOUNT-aware speaker would continue to accrue >> AS_PATH length through non-AS_HOPCOUNT-aware routers, and would be >> suppressed by the first AS_HOPCOUNT-aware speaker it came across. > > I like this idea much better as well, assuming it accounts for private > AS, AS confederation path segments, AS sets, etc.. Danny, I would word it so that the hopcount explicitly does NOT count private ASs or confederation ASs. AS sets would still count as one hop per set member. Does that match what you're saying? Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA24952 for ; Thu, 5 Jan 2006 01:14:03 -0500 (EST) 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 1EuOGx-0006wg-TM; Thu, 05 Jan 2006 01:06:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuOGw-0006wA-Tu for idr@megatron.ietf.org; Thu, 05 Jan 2006 01:06:50 -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 BAA27644 for ; Thu, 5 Jan 2006 01:05:35 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuOMY-0004JA-Nv for idr@ietf.org; Thu, 05 Jan 2006 01:12:40 -0500 Received: from [205.168.100.52] (dhcp3.tcb.net [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 46C0F64367; Wed, 4 Jan 2006 23:06:28 -0700 (MST) In-Reply-To: <78082F50-87EC-4693-9BD5-FBDDAD086DDE@isc.org> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> <732A8281-5ED8-4A56-ADF6-B4EE0EEBFACF@tcb.net> <78082F50-87EC-4693-9BD5-FBDDAD086DDE@isc.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80CB3777-FCC2-4388-800E-E72FB585233F@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Wed, 4 Jan 2006 23:06:39 -0700 To: Joe Abley X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 On Jan 4, 2006, at 10:50 PM, Joe Abley wrote: > > As someone else here suggested (and as Tony pointed out to me) > changing the AS_HOPCOUNT attribute to represent an upper bound on > the length of an AS_PATH (and discarding the NO_EXPORT interaction) > might be a useful compromise, since a prefix leaked by a non- > AS_HOPCOUNT-aware speaker would continue to accrue AS_PATH length > through non-AS_HOPCOUNT-aware routers, and would be suppressed by > the first AS_HOPCOUNT-aware speaker it came across. I like this idea much better as well, assuming it accounts for private AS, AS confederation path segments, AS sets, etc.. > The only other mechanism that occurred to me was to replace the > current proposed NO_EXPORT interaction with a capabilities > negotiation in the specification such that an AS_HOPCOUNT-capable > speaker would append a NO_EXPORT community-string attribute to > routes carrying AS_HOPCOUNT in the case where it exports routes > towards a non-AS_HOPCOUNT-capable speaker. This would provide a > more conservative strategy for route propagation, but it seems > dirtier than using AS_HOPCOUNT to bound an AS_PATH length. It also > doesn't support the alternative, more leak-tolerant semantics > achieved in the current proposal by adding AS_HOPCOUNT without > NO_EXPORT. Not only would this require some more dynamic knowledge (e.g., BGP Capabilities functions) of what capabilities the neighbor supports, it's something that may vary even within a single AS. I agree - I like the idea of examining the AS path and using that mechanism instead... -danny _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA24844 for ; Thu, 5 Jan 2006 00:55:25 -0500 (EST) 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 1EuO22-0000uL-Pz; Thu, 05 Jan 2006 00:51:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuO20-0000u1-S4 for idr@megatron.ietf.org; Thu, 05 Jan 2006 00:51: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 AAA26165 for ; Thu, 5 Jan 2006 00:50:09 -0500 (EST) Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuO7c-0003mh-L1 for idr@ietf.org; Thu, 05 Jan 2006 00:57:14 -0500 Received: from yxu1a20.hopcount.ca ([199.212.90.20]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EuO1X-000E9a-0Q; Thu, 05 Jan 2006 05:50:55 +0000 In-Reply-To: <732A8281-5ED8-4A56-ADF6-B4EE0EEBFACF@tcb.net> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> <732A8281-5ED8-4A56-ADF6-B4EE0EEBFACF@tcb.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <78082F50-87EC-4693-9BD5-FBDDAD086DDE@isc.org> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Thu, 5 Jan 2006 00:50:52 -0500 To: Danny McPherson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 On 3-Jan-2006, at 21:24, Danny McPherson wrote: > I've got a couple of concerns with the current specification, a few > high-level points are provided here as the detailed text below is > admittedly overly verbose (in part because I was trying to wrap my > head around the various scenarios - which I'm still not sure I have). > I have read the entire thread to date and don't believe I'm > duplicating > much... The NO_EXPORT/AS_HOPCOUNT interaction described in the current draft were based on an old (unsubmitted) draft I wrote which was conceived very much from the perspective of trying to conservatively restrict propagation of routes covering the addresses of anycast services. (Apologies for not speaking up sooner; my traditional New Year's hangover was concatenated with influenza.) The motivations for abusing NO_EXPORT in this way were that the implications for a leak from an anycast node in a region with poor external connectivity are often serious, and in many cases not propagating the prefix as widely as we could is preferable to accidentally propagating it globally. For example, propagating the covering route for F.ROOT-SERVERS.NET from ISC's anycast node in Nairobi could be bad for many people, both inside and outside Kenya. Export policies are frequently designed and implemented to prevent peer routes leaking to transit providers for obvious reasons; however, in practice, we find ourselves deploying infrastructure in regions where the concept of "export policy" is not well-known, and BGP configurations are apparently copied verbatim from the backs of cereal boxes. Not all of these regions are those that would be normally considered to be in the developing world. Hence, we like the paranoid approach of setting NO_EXPORT on 192.5.5.0/24 from our local nodes, since the peers most likely to leak are also the peers least likely to know how to remove it, or to even notice it is there. We soak up queries from the client population that we miss with this conservative propagation strategy on a smaller number of bigger, well- connected anycast nodes. There has been various discussion over the past week or so about how the unusual interaction between NO_EXPORT and AS_HOPCOUNT specified in this draft could cause confusion, e.g. by those practicing proxy application of NO_EXPORT, which for routes which also happen to carry AS_HOPCOUNT might not prevent the route from being exported. Breaking deployed expectations of NO_EXPORT does indeed seem bad. Since the whole NO_EXPORT/AS_HOPCOUNT interaction is a bit of a cheap short- cut, designed to allow use of AS_HOPCOUNT without waiting for widespread adoption of the AS_HOPCOUNT mechanism, perhaps the collateral ugliness is not justified. As someone else here suggested (and as Tony pointed out to me) changing the AS_HOPCOUNT attribute to represent an upper bound on the length of an AS_PATH (and discarding the NO_EXPORT interaction) might be a useful compromise, since a prefix leaked by a non-AS_HOPCOUNT- aware speaker would continue to accrue AS_PATH length through non- AS_HOPCOUNT-aware routers, and would be suppressed by the first AS_HOPCOUNT-aware speaker it came across. The only other mechanism that occurred to me was to replace the current proposed NO_EXPORT interaction with a capabilities negotiation in the specification such that an AS_HOPCOUNT-capable speaker would append a NO_EXPORT community-string attribute to routes carrying AS_HOPCOUNT in the case where it exports routes towards a non-AS_HOPCOUNT-capable speaker. This would provide a more conservative strategy for route propagation, but it seems dirtier than using AS_HOPCOUNT to bound an AS_PATH length. It also doesn't support the alternative, more leak-tolerant semantics achieved in the current proposal by adding AS_HOPCOUNT without NO_EXPORT. Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA22599 for ; Wed, 4 Jan 2006 18:51:42 -0500 (EST) 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 1EuIP9-0005u4-1n; Wed, 04 Jan 2006 18:50:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuIP7-0005tI-7d for idr@megatron.ietf.org; Wed, 04 Jan 2006 18:50:53 -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 SAA22050 for ; Wed, 4 Jan 2006 18:49:38 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19a1io/9ek0109WPVp1sMeoMJhldmC9J1g=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuIUf-0000Sq-Rm for idr@ietf.org; Wed, 04 Jan 2006 18:56:39 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+GL5/5E/KjOU8HpUZndq6kfL9M9gNFWv8@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k04NofVe029751; Wed, 4 Jan 2006 23:50:45 GMT Date: Wed, 4 Jan 2006 23:50:40 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: <42941B1F-360A-4B19-8E0E-6A13CAEFB1F0@tony.li> Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> <42941B1F-360A-4B19-8E0E-6A13CAEFB1F0@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1229/Wed Jan 4 15:08:11 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Andrew Lee , Inter-Domain Routing List 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 On Wed, 4 Jan 2006, Tony Li wrote: > We must have some miscommunication on the word "complete". I think so. It was the "completed" word in your other email that threw me into thinking you were referring to some language in the draft. > When an originator sets AS_HOPCOUNT, I would assume that they would > set it to some non-zero small integer. It would only be complete > when it had subsequently traversed multiple ASs and the value had > been decremented to zero. Ah, in every case where I've used "complete" or "partial", I've been referring to the Partial bit in the attribute flags header. > Tony regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: All intelligent species own cats. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA22509 for ; Wed, 4 Jan 2006 18:34:12 -0500 (EST) 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 1EuI7y-0007CF-FO; Wed, 04 Jan 2006 18:33:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuI7x-0007CA-An for idr@megatron.ietf.org; Wed, 04 Jan 2006 18:33:09 -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 SAA19591 for ; Wed, 4 Jan 2006 18:31:54 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuIDW-00082F-1v for idr@ietf.org; Wed, 04 Jan 2006 18:38:55 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2006010423325401200jjrfde>; Wed, 4 Jan 2006 23:32:58 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <42941B1F-360A-4B19-8E0E-6A13CAEFB1F0@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Wed, 4 Jan 2006 15:32:39 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Andrew Lee , Inter-Domain Routing List 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 >> Yes, but as I pointed out, making the NO_EXPORT override be >> conditional on AS_HOPCOUNT being complete breaks the NO_EXPORT >> override for everyone who is NOT depending on Y:n semantics. > > I don't quite see that. Could you expand on this (apologies if you > did already)? > > It will work for fine for the combination of NO_EXPORT and > AS_HOPCOUNT evisaged in the draft. Where the originator sets both. > AS_HOPCOUNT will always be complete. We must have some miscommunication on the word "complete". When an originator sets AS_HOPCOUNT, I would assume that they would set it to some non-zero small integer. It would only be complete when it had subsequently traversed multiple ASs and the value had been decremented to zero. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA22479 for ; Wed, 4 Jan 2006 18:29:04 -0500 (EST) 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 1EuI2y-0006LW-36; Wed, 04 Jan 2006 18:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuI2w-0006LO-QT for idr@megatron.ietf.org; Wed, 04 Jan 2006 18:27: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 SAA18857 for ; Wed, 4 Jan 2006 18:26:43 -0500 (EST) Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuI8V-0007o1-LX for idr@ietf.org; Wed, 04 Jan 2006 18:33:44 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2006010423274001200jmiv2e>; Wed, 4 Jan 2006 23:27:40 +0000 In-Reply-To: <43BB72E4.4050604@cisco.com> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> <43BB72E4.4050604@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Wed, 4 Jan 2006 13:59:14 -0800 To: Enke Chen X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 Enke, > It seems to me that removing the interaction between AS_HOPCOUNT > and NO_EXPORT would make things simpler and cleaner. So I am in > favor of the revision. Duly noted. > Also as Danny pointed out, having the AS_HOPCOUNT as an outbound > policy (rather than an inbound policy) would make it consistent > with the commonly understood practice of NO_EXPORT. It seems to be > a good idea. No objection from me. I should point out that regardless of the way the draft describes the semantics, the implementation is free to implement this as an inbound or outbound policy, as it sees fit. For example, given the current text, an implementation could pre-compute the ingress policy that a neighbor would implement and filter the prefix on the outbound side, effectively making this an outbound policy. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA19299 for ; Wed, 4 Jan 2006 09:29:06 -0500 (EST) 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 1Eu9dD-0002qV-N1; Wed, 04 Jan 2006 09:28:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu9dC-0002pQ-Pd for idr@megatron.ietf.org; Wed, 04 Jan 2006 09:28:50 -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 JAA06883 for ; Wed, 4 Jan 2006 09:27:34 -0500 (EST) Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu9ig-0001xi-Gu for idr@ietf.org; Wed, 04 Jan 2006 09:34:31 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 146C9E045A; Wed, 4 Jan 2006 09:28:39 -0500 (EST) Date: Wed, 4 Jan 2006 09:28:39 -0500 From: John Leslie To: Paul Jakma Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Message-ID: <20060104142839.GD85080@verdi> References: <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Inter-Domain Routing List 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 Paul Jakma wrote: > > I think the draft is right to try modify no-export behaviour > depending on AS_HOPCOUNT. Lets try find the best way to do so, no? I believe that any interaction between AS_HOPCOUNT and NO_EXPORT should be limited to _setting_ NO_EXPORT. Clearing it seems to introduce too much risk of propagating farther than intended. That said, I can imagine a use for setting NO_EXPORT in the case where AS_HOPCOUNT will reach its limit after one more hop: when the next hop is suspected of not implementing AS_HOPCOUNT. Of course, this only helps during the "transition" to full implementation of AS_HOPCOUNT -- but that transition, IMHO, will take a minimum of five years, and any predictability we can add during the transition is (IMHO) a good thing. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA18366 for ; Wed, 4 Jan 2006 06:43:59 -0500 (EST) 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 1Eu72r-0007Ms-8a; Wed, 04 Jan 2006 06:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu72p-0007Mj-EP for idr@megatron.ietf.org; Wed, 04 Jan 2006 06:43:07 -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 GAA17047 for ; Wed, 4 Jan 2006 06:41:52 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19vAHLuAVJMFJnxJgi7x3iqX+IArFgUr88=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu78G-0004BR-O7 for idr@ietf.org; Wed, 04 Jan 2006 06:48:47 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+6K5cIciFv/PyUa9eLCjBGVWXQhlhE1cw@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k04BgbYs020439; Wed, 4 Jan 2006 11:42:45 GMT Date: Wed, 4 Jan 2006 11:42:36 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1227/Tue Jan 3 22:11:54 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Andrew Lee , Inter-Domain Routing List 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 On Tue, 3 Jan 2006, Tony Li wrote: > Understood, and this is certainly a bad side effect of AS_HOPCOUNT > and Y:n interaction. > Yes, but as I pointed out, making the NO_EXPORT override be > conditional on AS_HOPCOUNT being complete breaks the NO_EXPORT > override for everyone who is NOT depending on Y:n semantics. I don't quite see that. Could you expand on this (apologies if you did already)? It will work for fine for the combination of NO_EXPORT and AS_HOPCOUNT evisaged in the draft. Where the originator sets both. AS_HOPCOUNT will always be complete. > This begs the question: how many folks are reliant on Y:n > semantics? Or should we simply remove the interaction between > AS_HOPCOUNT and NO_EXPORT? I think the draft is right to try modify no-export behaviour depending on AS_HOPCOUNT. Lets try find the best way to do so, no? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Life is a gamble at terrible odds, if it was a bet you wouldn't take it. -- Tom Stoppard, "Rosencrantz and Guildenstern are Dead" _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA15982 for ; Wed, 4 Jan 2006 02:05:17 -0500 (EST) 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 1Eu2h9-0008Jp-KD; Wed, 04 Jan 2006 02:04:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu2h6-0008JM-Ub for idr@megatron.ietf.org; Wed, 04 Jan 2006 02:04: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 CAA18539 for ; Wed, 4 Jan 2006 02:03:09 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu2mK-00037J-TF for idr@ietf.org; Wed, 04 Jan 2006 02:09:50 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 03 Jan 2006 23:01:58 -0800 X-IronPort-AV: i="3.99,328,1131350400"; d="scan'208"; a="246795856:sNHT842385182" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k04720XX020499; Tue, 3 Jan 2006 23:02:00 -0800 (PST) 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.211); Tue, 3 Jan 2006 23:01:57 -0800 Received: from [10.21.99.33] ([10.21.99.33]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Jan 2006 23:01:56 -0800 Message-ID: <43BB72E4.4050604@cisco.com> Date: Tue, 03 Jan 2006 23:01:56 -0800 From: Enke Chen User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> In-Reply-To: <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2006 07:01:56.0929 (UTC) FILETIME=[C0374B10:01C610FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Inter-Domain Routing List 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 wrote: > > Yes, but as I pointed out, making the NO_EXPORT override be > conditional on AS_HOPCOUNT being > complete breaks the NO_EXPORT override for everyone who is NOT > depending on Y:n semantics. > This begs the question: how many folks are reliant on Y:n semantics? > Or should we simply remove > the interaction between AS_HOPCOUNT and NO_EXPORT? Hi, Tony: It seems to me that removing the interaction between AS_HOPCOUNT and NO_EXPORT would make things simpler and cleaner. So I am in favor of the revision. Also as Danny pointed out, having the AS_HOPCOUNT as an outbound policy (rather than an inbound policy) would make it consistent with the commonly understood practice of NO_EXPORT. It seems to be a good idea. -- Enke _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA14041 for ; Tue, 3 Jan 2006 21:29:16 -0500 (EST) 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 1EtyK2-0005EC-K4; Tue, 03 Jan 2006 21:24:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtyK0-0005E4-96 for idr@megatron.ietf.org; Tue, 03 Jan 2006 21:24:16 -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 VAA21982 for ; Tue, 3 Jan 2006 21:23:02 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtyPL-0002e7-Bw for idr@ietf.org; Tue, 03 Jan 2006 21:29:51 -0500 Received: from [205.168.100.52] (unknown [205.168.100.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 88739642D4 for ; Tue, 3 Jan 2006 19:23:53 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <732A8281-5ED8-4A56-ADF6-B4EE0EEBFACF@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Tue, 3 Jan 2006 19:24:00 -0700 To: Inter-Domain Routing List X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit 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 On Jan 3, 2006, at 3:45 PM, Tony Li wrote: > > > Yes, but as I pointed out, making the NO_EXPORT override be > conditional on AS_HOPCOUNT being > complete breaks the NO_EXPORT override for everyone who is NOT > depending on Y:n semantics. > This begs the question: how many folks are reliant on Y:n > semantics? Or should we simply remove > the interaction between AS_HOPCOUNT and NO_EXPORT? Tony, I've got a couple of concerns with the current specification, a few high-level points are provided here as the detailed text below is admittedly overly verbose (in part because I was trying to wrap my head around the various scenarios - which I'm still not sure I have). I have read the entire thread to date and don't believe I'm duplicating much... In short, I'd definitely prefer that AS_HOPCOUNT and NO_EXPORT interaction be removed entirely. I believe the corner cases where it'd be useful are fewer than the cases where it could adversely effect existing deployments. I'd also think that adapting AS_HOPCOUNT behavior to be much more akin to that of the NO_EXPORT community string may be desirable. I.e., make AS_HOPCOUNT an egress policy function rather than an ingress one - as expanded on in the text below. Finally, I'd strongly suggest that Member-ASes of an AS confederation NOT be treated like standard external peers, but rather, that the AS_HOPCOUNT functions only apply to Member-ASes that are advertising a route to eBGP peers outside of the local confederation. My reasoning for this is that IBGP AS properties that are only visible within an AS would now result in routes only being propagated throughout a subset of a given AS, or an AS_HOPCOUNT being decremented multiple times in a seemingly single A (AUTONOMOUS) System.... Imagine a case where a multi-homed AS wanted to employ AS_HOPCOUNT to scope traffic two ASes upstream from it's two providers. One of it's upstream providers employs route reflection or a full mesh iBGP, while the other has confederations. As you can imagine, the confederation could result in the route never being advertised outside of the AS, or entirely within the AS if employing confederations, while still being propagated via the other provider. In short, it results in behavior that would be seemingly non-deterministic without intimate knowledge of the the internal BGP routing architectures of the networks in questions. I suspect in this case implementers could provide a knob to decrement AS_HOPCOUNT when advertising to other Member-ASes of the same AS confederation, but it's not something I'd recommend as normal default behavior. I'm still a fan of AS_HOPCOUNT and believe it's a good idea, FWIW. Further comments below... -danny As currently specified, (if I'm interpreting correctly) an eBGP speaker upon receipt of NLRI that contains both the AS_HOPCOUNT attribute and NO_EXPORT community: - if it doesn't understand the AS_HOPCOUNT attribute processing will continue as usual per it's an optional transitive attribute and NO_EXPORT will likely result in the NLRI NOT being propagated outside the local AS. (note that this required that the eBGP peer transmit both the NO_EXPORT community AND the AS_HOPCOUNT attribute) - if it does understand AS_HOPCOUNT it will ignore the NO_EXPORT (actually, behave as if it doesn't exist?) community and propagate the route ---> IF the AS_HOPCOUNT value is non-zero. - NO_EXPORT remains only applicable between adjacent ASes (by it's very nature)? I don't see anywhere here that it states NO_EXPORT should be carried indefinitely if the AS_HOPCOUNT attribute is present? With that, I'm honestly not sure I understand here where value is gained by coupling the NO_EXPORT community with the AS_HOPCOUNT attribute, can you further expand for me? On that point In section 3.3 the draft states: " Further control can be achieved by considering the implications of using both AS_HOPCOUNT and NO_EXPORT simultaneously. Since NO_EXPORT is widely deployed, understood by almost all implementations, and since AS_HOPCOUNT is not deployed, we can make use of the overlap in their semantics to provide a powerful transition mechanism." This introduces a bit of confusion. With the AS_HOPCOUNT attribute a route would be dropped as an ingress policy function (i.e., when receiving a route from an eBGP peer with an AS_HOPCOUNT value of 0). Whereas, NO_EXPORT is applied as an egress policy function (i.e., don't announce a route to an eBGP peer if the NO_EXPORT community string is present), the latter of which has the advantage of allowing me to tell an adjacent AS something and being quite confident that it will not be propagated beyond their AS. I.e., it seems non-intuitive to tell someone something if I know they're going to ignore it. However, if I know they're going to use it but not tell anyone else (e.g., as with NO_EXPORT), that makes sense. So what this would mean is that if I wanted to employ this in a similar manner to NO_EXPORT with an adjacent peer that supported the new attribute, I'd set the AS_HOPCOUNT attribute to 1, it'd be decremented on ingress to the adjacent AS AND advertised to ASes further upstream - *where it previously was not*, and on ingress to those ASes IF they support the AS_HOPCOUNT attribute they'll discard the route (a route that would have never been advertised had the AS_HOPCOUNT behavior not been introduced per the NO_EXPORT community that existed on ingress to the second AS in the path). If they do not support the attribute the route will be propagated indefinitely. Perhaps we'd be better off here if we changed the rules a bit such that NLRI with an AS_HOPCOUNT value of 1 (or 0) MUST NOT be advertised to eBGP peers, then the semantics overlap much more cleanly with that of the NO_EXPORT community string. I'm trying to think of a case where this might break if BGP speakers don't support it but nothing comes to mind at the moment....? Along the same lines, the issue that most of this thread has been pertaining to regarding ignoring NO_EXPORT if the AS_HOPCOUNT attribute is present, that concerns me. Primarily because if a downstream AS attaches the NO_EXPORT community to a route but has no knowledge of the existing AS_HOPCOUNT attribute, then the NO_EXPORT community will be ignored. According to the text here in section 5.1: "If a BGP speaker receives a route with both the AS_HOPCOUNT attribute and the NO_EXPORT community string attribute, then the normal semantics of NO_EXPORT do not apply and the route should be processed as if NO_EXPORT was not present." This has several implications. The first is that my reading of this leads me to believe that the NO_EXPORT community string should be removed from the route. So, if a transit AS added the NO_EXPORT community fully intending for the adjacent to propagate the route entirely throughout the local AS, but didn't recognize the AS_HOPCOUNT value then policy just changed without their knowledge and the route MAY be dropped on ingress to the AS, rather than egress (or in some external AS), depending on the value of the AS_HOPCOUNT attribute. I'd really prefer that the interactions between AS_HOPCOUNT and NO_EXPORT be removed altogether as I suspect that this will likely result in inadvertent propagation of prefixes that were previously scoped by NO_EXPORT (e.g., as was mentioned in the case where a transit AS doesn't support AS_HOPCOUNT but attached NO_EXPORT for whatever reason). Or, for example, all the routes that MAY be leaked while I'm upgrading my egress routers to support AS_HOPCOUNT while the ingress routers have stripped the NO_EXPORT community. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA12246 for ; Tue, 3 Jan 2006 17:47:42 -0500 (EST) 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 1Etuuy-0004kW-0z; Tue, 03 Jan 2006 17:46:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etuuw-0004kO-3v for idr@megatron.ietf.org; Tue, 03 Jan 2006 17:46:10 -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 RAA28035 for ; Tue, 3 Jan 2006 17:44:55 -0500 (EST) Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etv0H-00040g-Ld for idr@ietf.org; Tue, 03 Jan 2006 17:51:42 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <20060103224551012007sbaje>; Tue, 3 Jan 2006 22:45:52 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <242F1EB6-1111-4E3F-9C6F-F4568E6185D0@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Tue, 3 Jan 2006 14:45:49 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , Inter-Domain Routing List 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 Paul, > See the examples I gave previously wrt interaction of AS_HOPCOUNT > and : communities: > > X-Y-Z > > Z sends prefix with both AS_HOPCOUNT (count >= 2), and also > community Y:n (where AS Y will attach no-export community for any > prefix which has Y:n community attached). Y does not support > AS_HOPCOUNT. X receives the advertisement and ignores no-export, as > the draft currently stands. > > The prefix might now have have global scope, particularly in early > days of AS_HOPCOUNT deployment (where it may never transit through > sufficient other AS_HOPCOUNT capable speakers to be stopped). The > prefix has /wider/ scope because of the combination of AS_HOPCOUNT > and : communities, wider than it could ever have with > either method (presuming everyone supported AS_HOPCOUNT). It'd be a > surprising effect of AS_HOPCOUNT possibly. Understood, and this is certainly a bad side effect of AS_HOPCOUNT and Y:n interaction. > Making the NO_EXPORT override be conditional on AS_HOPCOUNT being a > complete attribute would solve this case, while not restricting > scope of AS_HOPCOUNTed prefixes unneccesarily, I think. (that was > your objection to my earlier 'partial -> set to 0' proposal). Yes, but as I pointed out, making the NO_EXPORT override be conditional on AS_HOPCOUNT being complete breaks the NO_EXPORT override for everyone who is NOT depending on Y:n semantics. This begs the question: how many folks are reliant on Y:n semantics? Or should we simply remove the interaction between AS_HOPCOUNT and NO_EXPORT? Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA04741 for ; Mon, 2 Jan 2006 22:33:02 -0500 (EST) 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 1EtctT-0005hc-O6; Mon, 02 Jan 2006 22:31:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtctS-0005hG-8h for idr@megatron.ietf.org; Mon, 02 Jan 2006 22:31: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 WAA18678 for ; Mon, 2 Jan 2006 22:30:12 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/XgkVnU/gCv51flIluyc4Xcx5xAGv92b8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etcyd-00086E-KF for idr@ietf.org; Mon, 02 Jan 2006 22:36:49 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19MRUC5VcHrCD8AV1GW7blW8vC04cVDy2M@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k033UupS031073; Tue, 3 Jan 2006 03:31:01 GMT Date: Tue, 3 Jan 2006 03:30:55 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1225/Mon Jan 2 17:54:07 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Andrew Lee , Inter-Domain Routing List 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 On Sun, 1 Jan 2006, Tony Li wrote: > That was my interpretation of what YOU were suggesting Ah, doh, of course. apologies. > when you said that "AS_HOPCOUNT should override NO_EXPORT *only* if > it is complete". Is that incorrect? Yes, that's exactly what I'm arguing for. > Perhaps we might make more progress if you could expand on your proposed > semantics a bit. As above, sorry. > If AS_HOPCOUNT is partial, the it implies that it transited an AS > that did not support AS_HOPCOUNT. But any such AS should have > obeyed NO_EXPORT and thus should never have propagated the path in > the first place. See the examples I gave previously wrt interaction of AS_HOPCOUNT and : communities: X-Y-Z Z sends prefix with both AS_HOPCOUNT (count >= 2), and also community Y:n (where AS Y will attach no-export community for any prefix which has Y:n community attached). Y does not support AS_HOPCOUNT. X receives the advertisement and ignores no-export, as the draft currently stands. The prefix might now have have global scope, particularly in early days of AS_HOPCOUNT deployment (where it may never transit through sufficient other AS_HOPCOUNT capable speakers to be stopped). The prefix has /wider/ scope because of the combination of AS_HOPCOUNT and : communities, wider than it could ever have with either method (presuming everyone supported AS_HOPCOUNT). It'd be a surprising effect of AS_HOPCOUNT possibly. See also the example I gave where Y has some AS_HOPCOUNT capable speakers, and some not. Making the NO_EXPORT override be conditional on AS_HOPCOUNT being a complete attribute would solve this case, while not restricting scope of AS_HOPCOUNTed prefixes unneccesarily, I think. (that was your objection to my earlier 'partial -> set to 0' proposal). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: They are called computers simply because computation is the only significant job that has so far been given to them. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA25611 for ; Mon, 2 Jan 2006 07:01:01 -0500 (EST) 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 1EtOJS-0005jl-3p; Mon, 02 Jan 2006 06:57:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtOJP-0005jg-W0 for idr@megatron.ietf.org; Mon, 02 Jan 2006 06:57:16 -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 GAA20056 for ; Mon, 2 Jan 2006 06:56:02 -0500 (EST) Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtOOT-0005pz-Kb for idr@ietf.org; Mon, 02 Jan 2006 07:02:30 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 3104FE0435; Mon, 2 Jan 2006 06:57:04 -0500 (EST) Date: Mon, 2 Jan 2006 06:57:04 -0500 From: John Leslie To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Message-ID: <20060102115704.GB18120@verdi> References: <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Andrew Lee , Paul Jakma , Inter-Domain Routing List 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 wrote: > > If AS_HOPCOUNT is partial, the it implies that it transited an AS > that did not support AS_HOPCOUNT. > But any such AS should have obeyed NO_EXPORT and thus should never > have propagated the path in the first place. When I first raised this issue, I was thinking of a particular case (in addition to the general case): - BGP-speaker at the edge advertises with AS_HOPCOUNT (without NO_EXPORT); - ISP-A doesn't know AS_HOPCOUNT, adds NO_EXPORT for whatever reason; - ISP-B recognizes AS_HOPCOUNT, and ignores NO_EXPORT. This particular case feels wrong to me. -- John Leslie _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA21826 for ; Sun, 1 Jan 2006 21:57:15 -0500 (EST) 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 1EtFqB-0003vi-Gm; Sun, 01 Jan 2006 21:54:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtFq9-0003va-GA for idr@megatron.ietf.org; Sun, 01 Jan 2006 21:54: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 VAA07682 for ; Sun, 1 Jan 2006 21:53:16 -0500 (EST) Received: from rwcrmhc14.comcast.net ([216.148.227.89] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtFv7-0007qG-VJ for idr@ietf.org; Sun, 01 Jan 2006 21:59:39 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (rwcrmhc14) with SMTP id <20060102025411014007skkce>; Mon, 2 Jan 2006 02:54:12 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85FDEE76-20B5-4747-A79E-3D89D674FCB4@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Sun, 1 Jan 2006 18:54:04 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , Inter-Domain Routing List 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 >> 2) The AS does support AS_HOPCOUNT. >> >> a) If the hopcount hasn't completed, then the AS would obey >> NO_EXPORT. > > Odd, the draft doesn't seem to say this. That was my interpretation of what YOU were suggesting when you said that "AS_HOPCOUNT should override NO_EXPORT *only* if it is complete". Is that incorrect? > Maybe I'm being dense too ;) but that reads to me like AS_HOPCOUNT / > always/ overrides NO_EXPORT, which is not good imho (see my X-Y-Z > action-community + AS_HOPCOUNT example in previous email). I'm > saying AS_HOPCOUNT should override NO_EXPORT *only* if it is complete. Perhaps we might make more progress if you could expand on your proposed semantics a bit. > If it's partial, then NO_EXPORT, IFF present, should be honoured > instead, If AS_HOPCOUNT is partial, the it implies that it transited an AS that did not support AS_HOPCOUNT. But any such AS should have obeyed NO_EXPORT and thus should never have propagated the path in the first place. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA21331 for ; Sun, 1 Jan 2006 20:39:05 -0500 (EST) 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 1EtEeZ-0001v4-LF; Sun, 01 Jan 2006 20:38:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtEeX-0001uz-Uu for idr@megatron.ietf.org; Sun, 01 Jan 2006 20:38: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 UAA02397 for ; Sun, 1 Jan 2006 20:37:13 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19lJOWNoxnTSR5Kn+ceoudUZlYGDgmz5YU=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtEjV-00060a-OE for idr@ietf.org; Sun, 01 Jan 2006 20:43:35 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19OBU9DVLeW0boi6q2eUfUkwp4XnC8Q32I@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k021c9f6017754; Mon, 2 Jan 2006 01:38:13 GMT Date: Mon, 2 Jan 2006 01:38:06 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1220/Sun Jan 1 22:25:36 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Andrew Lee , Inter-Domain Routing List 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 On Sun, 1 Jan 2006, Tony Li wrote: > Ok, I don't understand what you're suggesting. Here's what I think you're > saying. > If a prefix has both NO_EXPORT and AS_HOPCOUNT and it's received by an AS, > then there are three cases: > 2) The AS does support AS_HOPCOUNT. > > a) If the hopcount hasn't completed, then the AS would obey NO_EXPORT. Odd, the draft doesn't seem to say this. > b) If the hopcount has completed, then the AS would drop the route. > I don't see how the path can ever exit the AS. I'm guessing that > I'm being dense, but I'm not seeing how... In 3.3: " Systems that receive NLRI with both an AS_HOPCOUNT and NO_EXPORT and which do implement AS_HOPCOUNT will ignore the NO_EXPORT community and propagate the NLRI." In 5.1: " If a BGP speaker receives a route with both the AS_HOPCOUNT attribute and the NO_EXPORT community string attribute, then the normal semantics of NO_EXPORT do not apply and the route should be processed as if NO_EXPORT was not present." Maybe I'm being dense too ;) but that reads to me like AS_HOPCOUNT /always/ overrides NO_EXPORT, which is not good imho (see my X-Y-Z action-community + AS_HOPCOUNT example in previous email). I'm saying AS_HOPCOUNT should override NO_EXPORT *only* if it is complete. If it's partial, then NO_EXPORT, IFF present, should be honoured instead, because there's no way to know how many hops were "missed" in the AS_HOPCOUNT attribute, NO_EXPORT is the only complete "scope-reducer" in such case and should hence be obeyed. Failure could to do so could result in the prefix reaching /further/ than intended by anyone, possibly even result in global scope, where this was never intended for that prefix. > Tony regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Death to all fanatics! _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA21245 for ; Sun, 1 Jan 2006 20:21:09 -0500 (EST) 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 1EtEJH-0000jV-MA; Sun, 01 Jan 2006 20:16:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtEJF-0000gk-QU for idr@megatron.ietf.org; Sun, 01 Jan 2006 20:16: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 UAA29886 for ; Sun, 1 Jan 2006 20:15:13 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtEOD-0005Ln-MW for idr@ietf.org; Sun, 01 Jan 2006 20:21:34 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (sccrmhc13) with SMTP id <2006010201160301300o1beie>; Mon, 2 Jan 2006 01:16:11 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Sun, 1 Jan 2006 17:15:55 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , Inter-Domain Routing List 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 > A more focused answer might be to make just the 'ignore no-export' > part of the draft conditional on the AS_HOPCOUNT attribute being > complete. Would that be acceptable? That'd solve the no-export > concerns while still erring on the liberal-scope side. Ok, I don't understand what you're suggesting. Here's what I think you're saying. If a prefix has both NO_EXPORT and AS_HOPCOUNT and it's received by an AS, then there are three cases: 1) The AS doesn't support AS_HOPCOUNT and it obeys NO_EXPORT, limiting the prefix to the local domain. 2) The AS does support AS_HOPCOUNT. a) If the hopcount hasn't completed, then the AS would obey NO_EXPORT. b) If the hopcount has completed, then the AS would drop the route. I don't see how the path can ever exit the AS. I'm guessing that I'm being dense, but I'm not seeing how... Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA19388 for ; Sun, 1 Jan 2006 14:52:29 -0500 (EST) 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 1Et9D4-00060U-53; Sun, 01 Jan 2006 14:49:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et9D2-0005zu-FD for idr@megatron.ietf.org; Sun, 01 Jan 2006 14:49:40 -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 OAA05531 for ; Sun, 1 Jan 2006 14:48:28 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18chHO/Ua/Wtz9EsrIt5nA696lTChUOENI=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et9Hw-0005U4-Ri for idr@ietf.org; Sun, 01 Jan 2006 14:54:46 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19iYIkySKSnezkT/8No246Ib6amj/yi5mI@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k01JnJ7N015135; Sun, 1 Jan 2006 19:49:24 GMT Date: Sun, 1 Jan 2006 19:49:19 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1219/Wed Dec 28 22:57:59 2005 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Andrew Lee , Inter-Domain Routing List 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 On Sun, 1 Jan 2006, Tony Li wrote: > Well, I'm always horrible at estimating probabilities of group > behavior. ;) > My hope is that restricting the scope of global prefixes becomes > the predominant use of the attribute. Specifically, longer > prefixes that are being injected for traffic engineering. I'm > guessing that the predominant use would be proxy application by > Tier 1 or 2 providers. Sure. But if they're restricting scope of a route, they want its scope restricted. The covering global scope prefix will be there anyway. But who knows, indeed :). A more focused answer might be to make just the 'ignore no-export' part of the draft conditional on the AS_HOPCOUNT attribute being complete. Would that be acceptable? That'd solve the no-export concerns while still erring on the liberal-scope side. > My $.02, > Tony regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: You will stop at nothing to reach your objective, but only because your brakes are defective. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA18893 for ; Sun, 1 Jan 2006 13:14:09 -0500 (EST) 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 1Et7hT-00046N-En; Sun, 01 Jan 2006 13:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et7hR-00046C-5M for idr@megatron.ietf.org; Sun, 01 Jan 2006 13:12:57 -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 NAA26986 for ; Sun, 1 Jan 2006 13:11:45 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et7mL-0002iR-Av for idr@ietf.org; Sun, 01 Jan 2006 13:18:02 -0500 Received: from [192.168.1.44] (pool-71-105-42-249.lsanca.dsl-w.verizon.net[71.105.42.249]) by comcast.net (sccrmhc13) with SMTP id <2006010118123501300o1kkhe>; Sun, 1 Jan 2006 18:12:36 +0000 In-Reply-To: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3DFE2708-EE70-433F-ADEB-7E5D5009D200@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt Date: Sun, 1 Jan 2006 10:12:25 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Andrew Lee , 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 > How likely is it that people are going to experiment with > announcements that are currently global scope? Surely such > experiments will be carried out on announcements currently with > restricted scope (by no-export or by : communities)? Well, I'm always horrible at estimating probabilities of group behavior. My hope is that restricting the scope of global prefixes becomes the predominant use of the attribute. Specifically, longer prefixes that are being injected for traffic engineering. I'm guessing that the predominant use would be proxy application by Tier 1 or 2 providers. My $.02, Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA15983 for ; Sun, 1 Jan 2006 06:54:02 -0500 (EST) 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 1Et1mQ-0007yO-Tw; Sun, 01 Jan 2006 06:53:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Et1mO-0007rV-UP for idr@megatron.ietf.org; Sun, 01 Jan 2006 06:53: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 GAA00026 for ; Sun, 1 Jan 2006 06:52:29 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/PsrFM9WMHJ25+BNXPr4bMtapgWm4zbzw=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Et1rG-0001gy-IC for idr@ietf.org; Sun, 01 Jan 2006 06:58:43 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19yFf7SqCTt7YhQwsptrk1n2scI+oSFNuc@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k01BrNkx011898; Sun, 1 Jan 2006 11:53:28 GMT Date: Sun, 1 Jan 2006 11:53:23 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tony Li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-as-hopcount-00.txt In-Reply-To: <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> Message-ID: References: <20051230011357.GA86351@verdi> <43B4B7D4.4090201@grnoc.iu.edu> <51D57B34-B69D-408E-A22B-13668710E7C1@tony.li> <20051230150103.GC86351@verdi> <43B551C3.8050105@grnoc.iu.edu> <119099BB-94DE-4016-B870-E1B0C69F6075@tony.li> Mail-Copies-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1219/Wed Dec 28 22:57:59 2005 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Andrew Lee , 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 On Sat, 31 Dec 2005, Tony Li wrote: > I'm not yet convinced of the above. Consider that most longer > prefixes are now being distributed globally. Folks playing with > the new attribute are likely to want to experiment with it by > slowly contracting scope. Agreed. See the example I gave (Andrew's originally?), the combination of AS_HOPCOUNT with peer:action could give the route /wider/ scope than either of the two methods on their own, which seems unintuitive. > An abrupt change in distribution is likely to result in some > unanticipated results, which would delay, not encourage deployment. A fair point. How likely is it that people are going to experiment with announcements that are currently global scope? Surely such experiments will be carried out on announcements currently with restricted scope (by no-export or by : communities)? > Thus, it seems like many providers might want a more liberal > interpretation of the semantics. Providing the option of a liberal > or strict scoping would seem to give the provider an increased > level of control and thus ease deployment. Yeah... Though, as it stands it seems to interact poorly with one of the few existing restrict-scope traffic-engineering method during transition. Is that interaction more important than difference between "X hopcount means reaches at least X hops" and "X hopcount means reaches /up to/ X hops"? (particularly given the former can never be guaranteed anyway). I don't know. Anyway.. > Tony regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Office Automation: The use of computers to improve efficiency in the office by removing anyone you would want to talk with over coffee. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr