From andrewl at exodus.net Mon Jul 1 20:43:21 2002 From: andrewl at exodus.net (andrewl at exodus.net) Date: Mon, 1 Jul 2002 13:43:21 -0700 Subject: Last call for bgp-redistribution In-Reply-To: ; from mknopper@cisco.com on Thu, Jun 20, 2002 at 06:44:06PM -0400 References: Message-ID: <20020701134321.B27005@demiurge.exodus.net> Greetings, In going through this draft I have a couple of questions/concerns. 1) In the prefix/length community represented in Figure 6, how will IPv6 addresses be represented? 2) Given the (necessary) complexity of the community set, I believe most vendors will choose to implement the entire set in their code base. I can think of a number of issues that would come up with existing code that I'll need to discuss with specific vendors. But, that aside, I think we need to add a section which encourages implementors to provide an efficent filtering/on/off syntax for this feature set. I can see things now, where this is on, and memory consumption and convergence time grows when every customer who can is sending us a whole mess of large, extended communities. Perhaps a section like: Filtering and Precedence In order to allow operators maximum control over their policies, implementations of this draft should provide a robust filtering syntax. Filtering should include both type and action filters. For example: Deny/Permit All Redistribution Communities Deny/Permit Action Type (Prepend|No_Export|Do not announce) Deny/Permit/Limit Action Parameters (# of Prepends) Deny/Permit BGP Speakers_Filter Type (ASN|Prefix) Precendence of this community set in route processing should be adjustable. An operator should be able to configure the router to interpret these well known community values at any point in the policy-processing order. The default precedence should be processing these communities before processing other, manually configured, policies. 3) As part of the implementation report, I would very much like to see a discussion on the impact a lot of these attributes have on convergence times and router memory consumption, so operators know what to expect. 4) Section 2.2, end of first paragraph: ...and parameter should ignore all the redistribution communities concerning this action type and parameter. *change to* ...and parameter should ignore all the redistribution communities concerning this action type and parameter. This ignore action MUST be logged. Andrew On Thu, Jun 20, 2002 at 06:44:06PM -0400, Mark Knopper wrote: > User-Agent: Microsoft-Entourage/10.1.0.2006 > Date: Thu, 20 Jun 2002 18:44:06 -0400 > Subject: Last call for bgp-redistribution > From: Mark Knopper > To: > Precedence: bulk > X-OriginalArrivalTime: 20 Jun 2002 22:53:42.0085 (UTC) FILETIME=[53021750:01C218AD] > > This is a Last Call for draft-ietf-ptomaine-bgp-redistribution-00.txt to be > moved to Proposed Standard. The immediate reason is to cause the IANA to > assign extended community type codes/values as specified in the draft. > > The deadline for comments (2 weeks) is July 5. > > Mark > From mknopper at cisco.com Thu Jul 11 21:41:08 2002 From: mknopper at cisco.com (Mark Knopper) Date: Thu, 11 Jul 2002 17:41:08 -0400 Subject: Yokohama ptomaine agenda Message-ID: Prefix Taxonomy Ongoing Measurement & Inter Network Experiment (ptomaine) TUESDAY, July 16 at 1300-1400 Room 503 ======================================= CO-CHAIRS: Sean Doran Mark Knopper AGENDA: 1. Administrivia 7 minutes General Discussion: ptomaine at shrubbery.net To Subscribe: majordomo at shrubbery.net In Body: subscribe ptomaine Archive: http://www.shrubbery.net/ptomaine Scribe? Blue Sheets Agenda Bashing 2. Discuss Working Group Drafts: a. draft-ietf-ptomaine-bgp-redistribution-00.txt (15 mins - O. Bonaventure et. al.) b. draft-ietf-ptomaine-nopeer-00.txt (10 mins - Geoff Huston) 3. Presentation on BGP trends (20 mins - Cengiz A. ) 4. Charter review & call for contributions (8 mins) From mknopper at cisco.com Tue Jul 16 08:00:49 2002 From: mknopper at cisco.com (Mark Knopper) Date: Tue, 16 Jul 2002 04:00:49 -0400 Subject: draft ptomaine minutes In-Reply-To: <15667.47527.413000.429316@gargle.gargle.HOWL> Message-ID: Hi. Here are draft minutes of the Ptomaine meeting. Thanks to Sean McCreary for being Official Scribe, and to Hal Peterson for unofficial notes. Please note item 2(a) below, and send comments to the list on the IPv6 EC issue for the redist-communities draft. Also please send any corrections or comments. Mark ====== Prefix Taxonomy Ongoing Measurement & Inter Network Experiment (ptomaine) - Minutes Agenda slides here: http://bgp.nu/~mak/ptomaine_yokohama.ppt http://bgp.nu/~mak/ptomaine_yokohama.pdf TUESDAY, July 16 at 1300-1400 Room 503 ======================================= CO-CHAIRS: Sean Doran [not present] Mark Knopper AGENDA: 1. Administrivia 7 minutes General Discussion: ptomaine at shrubbery.net To Subscribe: majordomo at shrubbery.net In Body: subscribe ptomaine Archive: http://www.shrubbery.net/ptomaine Scribe? [Thanks to Sean McCreary.] Blue Sheets Agenda Bashing 2. Discuss Working Group Drafts: a. draft-ietf-ptomaine-bgp-redistribution-00.txt (15 mins - O. Bonaventure et. al.) Andrew Lange on representing IPv6 in redistribution communities. Problem is that there isn't enough space in the 64-bit EC value to represent 128-bit IPv6 addresses. Andrew proposes variable-length ECs. This is a proposal to modify extended communities set to have: one octet length field variable length data field eliminating regular type force all communities to have type and subtype type defines format of data field subtype would provide clarification of interpretation He will send email to IDR list with detailed proposal. He proposes to hold this ptomaine draft until it can be updated with the final EC solution. Hal Peterson: Changing syntax and semantics of extended communities out of scope. What we have now solves existing problems, so we should proceed rather than waiting for IDR to approve changes to extended communities. There was no consensus to these opposing viewpoints, and document authors were not present. Therefore we will take the discussion to the mailing list. > Question on list: what about convergence time impact of redist > communities? Mark asks for information, but does not see need to hold > draft for it. > > Also on the list, somebody suggested adding a wildcard for `always add > NO_EXPORT'. > > tbarron: concern about community pollution; it is a valuable feature > of the proposal that redist community is defined as nontransitive. > That is value above and beyond the codification of existing practice. Andrew Lange: `pollution' of routing table with excessive communities is a configuration error, the example presented at NANOG will be cleaned up by stripping communities at their ISP's boundary b. draft-ietf-ptomaine-nopeer-00.txt (10 mins - Geoff Huston) Consensus by hum (and approval by Randy as AD) to progress this document as BCP. IANA considerations (to reserve a well-known community value) can go forward in a BCP. Mark will issue last call on list. 3. Presentation on BGP trends (20 mins - Cengiz A. ) Slides can (currently) be found here: http://bgp.nu/~mak/cengiz.pdf Cengiz Alaettinoglu presented `Recent BGP Trends', an update of the talk he gave at the London IETF The data was from RIPE/RIS, containing all BGP messages not just table snapshots Time period: Dec 2000 - July 2002 Routing table growth rate has slowed dramatically, both in absolute slope and in big-Oh. `Historic' prefixes: classful prefixes that are usually replaced by a covering CIDR aggregate prefix in the core routing table Without CIDR, routing table would be 5x larger to hold all the `historic' prefixes Growth rate in historic prefixes is slowing Cengiz suggests this indicates new advertisements are not appearing in the core table due to a preexisting covering aggregate prefix? Cengiz' taxonomy of prefixes: Multi-homing Engineered prefixes Punching holes Regular prefixes Number of engineered and hole prefixes have decreased Number of multihomed prefixes with multiple origins not growing BGP churn per router: last year churn was slightly decreasing Trend has continued churn per prefix decreasing even faster So overall stability is improving, total variability decreasing Most churn (>75%) was from peering loss This continues to be a problem, although the collected uptime data is for multihop peerings, which are likely to be less stable than conventional ones Summary: Table growing BGP churn decreasing, decelerating engineered prefixes no longer churn more than their share peering loss/reestablishment still a problem Geoff: do you differentiate between advertisements/withdrawals and path changes Path changes are becoming more stable, but withdrawal numbers increased substantially in April 2002 This may have to do with large-scale changes in the core, with the demise of some carriers. Dan Massey presented a graph of BGP message classification from RIPE/RIS data Randy Bush: 95% of the session resets are due to measurement artifacts (EBGP multihop) rather than real problems Dan: We don't see session resets from non-multihop peerings either Geoff's graphs can be found at http://bgp.potaroo.net Randy, Mark and others called for others to post any current BGP measurements or analysis to the ptomaine list. 4. Charter review & call for contributions (8 mins) Mark revisited the charter: This working group has a role to play, but doesn't have any outstanding standardization issues to discuss Last milestone in the charter was dated FEB 02 If no more documents are submitted, then working group should go dormant in a month Questioner: Ptomaine has been a useful forum for measurement presentations like Geoff's. Randy (AD) agreed. Mark: Ptomaine fills a role like the CIDR deployment working group did David Ward: One month is too short an interval to close down the working group It would be better to just not meet for awhile, but keep the mailing list and the working group open Ed Kern: You could always just consider a recharter. That could take more than a year. From bqu at infonet.fundp.ac.be Tue Jul 16 11:42:11 2002 From: bqu at infonet.fundp.ac.be (Bruno Quoitin) Date: Tue, 16 Jul 2002 13:42:11 +0200 Subject: draft ptomaine minutes References: Message-ID: <3D340693.9030100@infonet.fundp.ac.be> Hi. >>tbarron: concern about community pollution; it is a valuable feature >>of the proposal that redist community is defined as nontransitive. >>That is value above and beyond the codification of existing practice. >> > >Andrew Lange: `pollution' of routing table with excessive communities is a > configuration error, the example presented at NANOG will be cleaned > up by stripping communities at their ISP's boundary > Already a consequence of NANOG25 (drastic decrease of the number of communities in Route-Views tables) ? http://alpha.infonet.fundp.ac.be/anabgp/index2.html Bruno -- Bruno Quoitin Infonet Group University of Namur http://www.infonet.fundp.ac.be From mknopper at cisco.com Wed Jul 17 07:26:28 2002 From: mknopper at cisco.com (Mark Knopper) Date: Wed, 17 Jul 2002 03:26:28 -0400 Subject: last call for draft-nopeer Message-ID: This is a Last Call for draft-ietf-ptomaine-nopeer-00.txt to be moved to Best Current Practice (BCP), as agreed at the working group meeting. The deadline for comments (2 weeks) is July 31. Mark From post-ptomaine at partan.com Wed Jul 24 18:05:47 2002 From: post-ptomaine at partan.com (Andrew Partan) Date: Wed, 24 Jul 2002 14:05:47 -0400 Subject: Last call for bgp-redistribution In-Reply-To: ; from mknopper@cisco.com on Thu, Jun 20, 2002 at 06:44:06PM -0400 References: Message-ID: <20020724140547.A17575@partan.com> On Thu, Jun 20, 2002 at 06:44:06PM -0400, Mark Knopper wrote: > This is a Last Call for draft-ietf-ptomaine-bgp-redistribution-00.txt to be > moved to Proposed Standard. The immediate reason is to cause the IANA to > assign extended community type codes/values as specified in the draft. > > The deadline for comments (2 weeks) is July 5. Late late comments... In the Abstract it says there are three types of redistribution communities. In section 2, it lists 4 types. As you read further, you realize that its really 6 (prepend/no_export/no annouce) x (all peer but these/just these peers). I think the Abstract and section 2 should be cleaned up to be more accurate. Typo in section 2.3. In "A router should apply the policies defined by the redistribution communities to the routes that is has selected", s/routes that is/routes that it/. Someplace it should be spelled out how to match all peers (or no peers) - use prefix/length of ... I think some uses of the prefix/length should be added - its not immediately obvious why its there. I think we should add a note along the lines of this: An ISP may choose not to honor this community from some peers - for instace, an ISP may choose to only honor this community if sent by its customers. An implementation should therefore provide a knob so that an ISP can drop this community from some peers. --asp From gih at telstra.net Wed Jul 24 23:53:27 2002 From: gih at telstra.net (Geoff Huston) Date: Thu, 25 Jul 2002 09:53:27 +1000 Subject: Last call for bgp-redistribution In-Reply-To: <20020724140547.A17575@partan.com> References: Message-ID: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> At 02:05 PM 7/24/2002 -0400, Andrew Partan wrote: >I think we should add a note along the lines of this: > An ISP may choose not to honor this community from some > peers - for instace, an ISP may choose to only honor this > community if sent by its customers. An implementation > should therefore provide a knob so that an ISP can drop this > community from some peers. I agree that this would be a useful addition to the document Geoff From tbarron at cisco.com Thu Jul 25 14:50:38 2002 From: tbarron at cisco.com (Tom Barron) Date: Thu, 25 Jul 2002 09:50:38 -0500 Subject: Scope of Communities [was: Re: Last call for bgp-redistribution] In-Reply-To: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> References: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> Message-ID: <15680.4158.196798.586875@dhcp-64-101-210-162.cisco.com> >>>>> On Thu, 25 Jul 2002 09:53:27 +1000, Geoff Huston said: Geoff> At 02:05 PM 7/24/2002 -0400, Andrew Partan wrote: >> I think we should add a note along the lines of this: >> An ISP may choose not to honor this community from some >> peers - for instace, an ISP may choose to only honor this >> community if sent by its customers. An implementation >> should therefore provide a knob so that an ISP can drop this >> community from some peers. Geoff> I agree that this would be a useful addition to the document Geoff> Geoff Let me turn this conversation a bit and follow up on a hallway conversation with Geoff. Irrespective of whether one honors a redistribution community or not, one SHOULD strip this community before readvertising the route in question. (Of course one may decide not to readvertise, whether because of local policy or because one is honoring redistribution community action value 010b.) One SHOULD strip redistribution communities because they are *non-transitive* extended communities. What about ordinary, nonextended communities - which have no "transitive" bit. (Remember that this bit is independent of the general transitivity of BGP attributes ....) When should ordinary communities be stripped and when should they be left intact? It seems clear to me that many communities should not be propagated to the general Internet. If I use communities to mark ingress points so I can fool with the route selection process elsewhere in my iBGP domain, then I should strip those communities on egress from my network; likewise, if I for some reason do not strip them, a neighboring AS would be advised to strip them on ingress. Similarly, if my customers signal desired local pref settings, prepends, and no-exports by sending me communities according to a scheme that I've laid out and published, I ought to strip these before readvertising to another AS, and another AS for whom they have no significance would be advised to strip them on ingress if for some reason they show up there. But certain communities not of my own definition SHOULD be kept intact and be allowed to transit my AS when I readvertise routes. Talking to Geoff in Yokohama, I think NOPEER is an an example of one of these. If I receive a route marked with NOPEER and I choose to readvertise it (e.g. I got it from someone who pays me for transit and I'm readvertising to someone I pay for transit), then I SHOULD leave the NOPEER community intact when I readvertise. What other communities fall into this category - communities with global significance which SHOULD be allowed to transit ASes to the general Internet whenever the routes to which they are attached transit? - Tom From jhaas at nexthop.com Thu Jul 25 15:17:28 2002 From: jhaas at nexthop.com (Jeffrey Haas) Date: Thu, 25 Jul 2002 11:17:28 -0400 Subject: Last call for bgp-redistribution In-Reply-To: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net>; from gih@telstra.net on Thu, Jul 25, 2002 at 09:53:27AM +1000 References: <20020724140547.A17575@partan.com> <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> Message-ID: <20020725111728.C3597@nexthop.com> On Thu, Jul 25, 2002 at 09:53:27AM +1000, Geoff Huston wrote: > I agree that this would be a useful addition to the document While we are on the topic, if we're going to talk about allowing knob twiddling, do we want to specify all of the knobs or just the knob as a whole? IOW, we have no-export, as-path-prepend, etc. knobs or the whole redistribution feature as a whole. > Geoff -- Jeff Haas NextHop Technologies From jhaas at nexthop.com Thu Jul 25 16:50:41 2002 From: jhaas at nexthop.com (Jeffrey Haas) Date: Thu, 25 Jul 2002 12:50:41 -0400 Subject: Scope of Communities [was: Re: Last call for bgp-redistribution] In-Reply-To: <15680.4158.196798.586875@dhcp-64-101-210-162.cisco.com>; from tbarron@cisco.com on Thu, Jul 25, 2002 at 09:50:38AM -0500 References: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> <15680.4158.196798.586875@dhcp-64-101-210-162.cisco.com> Message-ID: <20020725125041.G3597@nexthop.com> On Thu, Jul 25, 2002 at 09:50:38AM -0500, Tom Barron wrote: > It seems clear to me that many communities should not be propagated > to the general Internet. Andrew Partan posted a nice set of rules-of-thumb to this list a while ago on this very topic > likewise, if I > for some reason do not strip them, a neighboring AS would be advised to > strip them on ingress. That would depend. You could leave specific communities with your AS number on a route to indicate to the Internet that "I did *this* to the route." One imagined use for this is "I think this connection is congested, I'm going to use it, but *you* might not want to". > But certain communities not of my own definition SHOULD be kept > intact and be allowed to transit my AS when I readvertise routes. > Talking to Geoff in Yokohama, I think NOPEER is an an example of > one of these. If I receive a route marked with NOPEER and I choose > to readvertise it (e.g. I got it from someone who pays me for transit > and I'm readvertising to someone I pay for transit), then I SHOULD > leave the NOPEER community intact when I readvertise. IMO, the well-known communities (NO_EXPORT, etc.), should be left unmolested. > - Tom -- Jeff Haas NextHop Technologies From tbarron at cisco.com Thu Jul 25 17:33:09 2002 From: tbarron at cisco.com (Tom Barron) Date: Thu, 25 Jul 2002 12:33:09 -0500 Subject: Scope of Communities [was: Re: Last call for bgp-redistribution] In-Reply-To: <20020725125041.G3597@nexthop.com> References: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> <15680.4158.196798.586875@dhcp-64-101-210-162.cisco.com> <20020725125041.G3597@nexthop.com> Message-ID: <15680.13909.557504.824415@dhcp-64-101-210-162.cisco.com> Jeff, Thanks for the reply. Some followup inline. >>>>> On Thu, 25 Jul 2002 12:50:41 -0400, Jeffrey Haas said: Jeffrey> On Thu, Jul 25, 2002 at 09:50:38AM -0500, Tom Barron wrote: >> It seems clear to me that many communities should not be propagated >> to the general Internet. Jeffrey> Andrew Partan posted a nice set of rules-of-thumb to this list a while Jeffrey> ago on this very topic Maybe Andrew will repost with commentary :-) >> likewise, if I >> for some reason do not strip them, a neighboring AS would be advised to >> strip them on ingress. Jeffrey> That would depend. You could leave specific communities with your AS Jeffrey> number on a route to indicate to the Internet that "I did *this* Jeffrey> to the route." Jeffrey> One imagined use for this is "I think this connection is congested, Jeffrey> I'm going to use it, but *you* might not want to". One *could* do this, but I see no RFC or BCP that even suggests it. Nor do I know of operators who really do this. What I do see is occasional pollution by folks who inadvertently leave communities in place that were intended only for their own use or only for use by them and their customers. I'm probing this area because it seems to me that historically community attributes - unlike, say, ASPATH - have had semantics defined with fairly local scope, but that with NOPEER (and perhaps some of the transitive extended communities) communities may have more global reach. I don't see clear consensus or documentation at least of propagation behavior for communities with global significance. If I read you correctly, you are suggesting that even those communities that I think have only local significance may really have meaning to the general Internet and might ought to be preserved - more like ASPATH after all. >> But certain communities not of my own definition SHOULD be kept >> intact and be allowed to transit my AS when I readvertise routes. >> Talking to Geoff in Yokohama, I think NOPEER is an an example of >> one of these. If I receive a route marked with NOPEER and I choose >> to readvertise it (e.g. I got it from someone who pays me for transit >> and I'm readvertising to someone I pay for transit), then I SHOULD >> leave the NOPEER community intact when I readvertise. Jeffrey> IMO, the well-known communities (NO_EXPORT, etc.), should be left Jeffrey> unmolested. Umm, I agree except that I shouldn't be readvertising NO_EXPORT, NO_ADVERTISE, or NO_EXPORT_SUBCONFED across an AS boundary anyway! I'm interested in cases where the route is readvertised. Are there other communities than NOPEER that have global significance except those that quash the readvertisement anyway? - Tom From jhaas at nexthop.com Thu Jul 25 18:09:36 2002 From: jhaas at nexthop.com (Jeffrey Haas) Date: Thu, 25 Jul 2002 14:09:36 -0400 Subject: Scope of Communities [was: Re: Last call for bgp-redistribution] In-Reply-To: <15680.13909.557504.824415@dhcp-64-101-210-162.cisco.com>; from tbarron@cisco.com on Thu, Jul 25, 2002 at 12:33:09PM -0500 References: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> <15680.4158.196798.586875@dhcp-64-101-210-162.cisco.com> <20020725125041.G3597@nexthop.com> <15680.13909.557504.824415@dhcp-64-101-210-162.cisco.com> Message-ID: <20020725140936.I3597@nexthop.com> On Thu, Jul 25, 2002 at 12:33:09PM -0500, Tom Barron wrote: > Maybe Andrew will repost with commentary :-) Attached to this message. > One *could* do this, but I see no RFC or BCP that even suggests it. But the base communities spec doesn't preclude it. Specifically, it only talks about "these routes have common properties" and doesn't really talk about when as is marked in there whether it needs to be *for* as or *to* as . Common practice is that they are just *to* when observed outside of the AS in question. > I don't see > clear consensus or documentation at least of propagation behavior for > communities with global significance. And aside from rules-of-thumb like Andrew Partan's (which seem to be what people generally try to do), such behavior isn't documented even for the ones of local significance. > If I read you correctly, you are suggesting that even those communities > that I think have only local significance may really have meaning to the > general Internet and might ought to be preserved - more like ASPATH after > all. If we are going to preclude an AS from marking a route with a community with its own AS, we should: o Make sure no one ever does this. o Document it as a BCP (preferably with the rules of thumb) and for vendors: o Implement the BCP as a simple knob. > Umm, I agree except that I shouldn't be readvertising NO_EXPORT, > NO_ADVERTISE, or NO_EXPORT_SUBCONFED across an AS boundary anyway! Unfortunately, it is common practice for some ISPs to discard all communities, even the well-known ones, upon ingress. This results in unintended route leaks. > I'm interested in cases where the route is readvertised. Are there other > communities than NOPEER that have global significance except those that > quash the readvertisement anyway? IMO: o Communities with global significance probably should be well-known only. o Communities with local significance should follow Andrew's BCP o Communities that have significance only to your immediately adjacent peers should use non-transitive extended communities. > - Tom -- Jeff Haas NextHop Technologies -------------- next part -------------- Date: Wed, 20 Mar 2002 17:30:17 -0500 From: Andrew Partan To: "Martin, Christian" Cc: ptomaine at shrubbery.net Subject: Re: BGP TTL Message-ID: <20020320173017.A9705 at partan.com> On Wed, Mar 20, 2002 at 03:25:23PM -0500, Martin, Christian wrote: > Perhaps communities should become mandatory transitive attributes? That is not a good idea. You still need to block communities you use internally so others can't effect your router. Ideal provider config is - strip all communities you use for internal markers on input - act on all communities you tell you customers they may use - strip all your communities on output - let all other communities thru untouched --asp From tbarron at cisco.com Thu Jul 25 18:45:54 2002 From: tbarron at cisco.com (Tom Barron) Date: Thu, 25 Jul 2002 13:45:54 -0500 Subject: Scope of Communities [was: Re: Last call for bgp-redistribution] In-Reply-To: <20020725140936.I3597@nexthop.com> References: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> <15680.4158.196798.586875@dhcp-64-101-210-162.cisco.com> <20020725125041.G3597@nexthop.com> <15680.13909.557504.824415@dhcp-64-101-210-162.cisco.com> <20020725140936.I3597@nexthop.com> Message-ID: <15680.18274.30731.241160@dhcp-64-101-210-162.cisco.com> >>>>> On Thu, 25 Jul 2002 14:09:36 -0400, Jeffrey Haas said: Jeffrey> On Thu, Jul 25, 2002 at 12:33:09PM -0500, Tom Barron wrote: >> Maybe Andrew will repost with commentary :-) Jeffrey> Attached to this message. Thanks. Will remark on it later. >> One *could* do this, but I see no RFC or BCP that even suggests it. Jeffrey> But the base communities spec doesn't preclude it. Agreed. I'm thinking that as communities such as NOPEER and transitive extended communities emerge, some BCP may be in order precisely because the base spec doesn't settle this kind of issue. Jeffrey> Specifically, it only talks about "these routes have common properties" Jeffrey> and doesn't really talk about when as is marked in there Jeffrey> whether it needs to be *for* as or *to* as . Common Jeffrey> practice is that they are just *to* when observed outside of the AS Jeffrey> in question. Yes, common practice is that the community is *to* the AS *and* that it's just one AS-hop away. That's why I considered it, ahem, innovative to suggest that one would leave communities in place on egress to mark *from*. But now I think I see that your point is really congruent with my saying that the base spec underdetermines the BCP. >> I don't see >> clear consensus or documentation at least of propagation behavior for >> communities with global significance. Jeffrey> And aside from rules-of-thumb like Andrew Partan's (which seem to Jeffrey> be what people generally try to do), such behavior isn't documented Jeffrey> even for the ones of local significance. Right. >> If I read you correctly, you are suggesting that even those communities >> that I think have only local significance may really have meaning to the >> general Internet and might ought to be preserved - more like ASPATH after >> all. Jeffrey> If we are going to preclude an AS from marking a route with a Jeffrey> community with its own AS, we should: Jeffrey> o Make sure no one ever does this. Jeffrey> o Document it as a BCP (preferably with the rules of thumb) Jeffrey> and for vendors: Jeffrey> o Implement the BCP as a simple knob. Yes, precisely. >> Umm, I agree except that I shouldn't be readvertising NO_EXPORT, >> NO_ADVERTISE, or NO_EXPORT_SUBCONFED across an AS boundary anyway! I meant to say, one shouldn't be readvertising the *routes* that one receives with NO_EXPORT, NO_ADVERTISE, or NO_EXPORT_SUBCONFED across an AS boundary, so that they don't pose the problem that interests me. Jeffrey> Unfortunately, it is common practice for some ISPs to discard all Jeffrey> communities, even the well-known ones, upon ingress. This results Jeffrey> in unintended route leaks. And of course I agree that one should not strip the WKCs on ingress. >> I'm interested in cases where the route is readvertised. Are there other >> communities than NOPEER that have global significance except those that >> quash the readvertisement anyway? Jeffrey> IMO: Jeffrey> o Communities with global significance probably should be Jeffrey> well-known only. I'm inclined to this view myself. I believe - someone correct me out there if I am wrong! - that this means that NOPEER is the only community of global significance that should get propagated to the general Internet. I may set NO_EXPORT when I advertise a route across an AS boundary, but the AS receiving it should not readvertise the route anyway, so its scope is limited even though its significance is global. (I distinguish between global significance and global scope because as my colleague Hal Peterson has taught me, only so many communities will fit in a single update message.) Jeffrey> o Communities with local significance should follow Andrew's BCP Please see below. Jeffrey> o Communities that have significance only to your immediately adjacent Jeffrey> peers should use non-transitive extended communities. Today extended communities are rarely used except for stuff like PPVPN (of course the draft is only now at last call). You may be suggesting that BCP would be to migrate to extended communities where transitivity and nontransitivity are explicit, and where (as in redistribution communities) well-known values would be used to encode signalling that is today done on a more ad-hoc basis. If that is what your are suggesting, I tend to agree. Andrew> Ideal provider config is Andrew> - strip all communities you use for internal markers on input Andrew> - act on all communities you tell you customers they may use Andrew> - strip all your communities on output Andrew> - let all other communities thru untouched What about this variant (Andrew?) - strip all communities on input except * communities you tell your customers they may use * well-known communities - act on well-known communities and communities you tell your customers they may use - strip all communities on output except * well-known communities * communities you have deliberately added to signal to the next AS Thanks, - Tom From jhaas at nexthop.com Fri Jul 26 14:35:30 2002 From: jhaas at nexthop.com (Jeffrey Haas) Date: Fri, 26 Jul 2002 10:35:30 -0400 Subject: Scope of Communities [was: Re: Last call for bgp-redistribution] In-Reply-To: <15680.18274.30731.241160@dhcp-64-101-210-162.cisco.com>; from tbarron@cisco.com on Thu, Jul 25, 2002 at 01:45:54PM -0500 References: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> <15680.4158.196798.586875@dhcp-64-101-210-162.cisco.com> <20020725125041.G3597@nexthop.com> <15680.13909.557504.824415@dhcp-64-101-210-162.cisco.com> <20020725140936.I3597@nexthop.com> <15680.18274.30731.241160@dhcp-64-101-210-162.cisco.com> Message-ID: <20020726103530.B7985@nexthop.com> On Thu, Jul 25, 2002 at 01:45:54PM -0500, Tom Barron wrote: > Yes, common practice is that the community is *to* the AS *and* that it's > just one AS-hop away. I'm curious if the "one AS-hop away" observation is true. To arbitrarily pick on some ISPs, lets say I buy transit from UUNet and FooISP. I know that FooISP buys service from UUNet. Why should I be able to put communities that say "deprefer this route" that are UUNet specific and inject them out FooISP? > That's why I considered it, ahem, innovative to > suggest that one would leave communities in place on egress to mark *from*. The question is, do we want to preclude doing this? > But now I think I see that your point is really congruent with my saying > that the base spec underdetermines the BCP. More likely that this "novelty" is something that someone hasn't found a good use for, and maybe just qualify that with a "yet". Let me give another example that might be useful from an old NANOG discussion. AboveNet was blackholing a certain IP address in a netblock that they were otherwise cleanly routing. This cause people who were using said route themselves grief if they were trying to get to said address. AboveNet *could* have tacked on a community that said "this route is unclean, use at your own risk." 6461:1313 or some such. :-) > (I distinguish between global significance and global scope because as > my colleague Hal Peterson has taught me, only so many communities will fit > in a single update message.) Hopefully, the implementation allows for a reasonable number of them. Ideally, the number stays small due to a couple of factors: o Operators clean up the ones of local significance. o AS Paths are short. Each AS in the middle should only need to add a few communities. > Today extended communities are rarely used except for stuff like PPVPN (of > course the draft is only now at last call). You may be suggesting that BCP > would be to migrate to extended communities where transitivity and > nontransitivity are explicit, and where (as in redistribution communities) > well-known values would be used to encode signalling that is today done on > a more ad-hoc basis. If that is what your are suggesting, I tend to agree. According to the recent implementation report, extended communities are pretty well supported in upcoming releases. > What about this variant (Andrew?) I'm not Andrew, but this still sounds good. > > - strip all communities on input except > * communities you tell your customers they may use > * well-known communities > > - act on well-known communities and communities you tell your > customers they may use > > - strip all communities on output except > * well-known communities > * communities you have deliberately added to signal > to the next AS -- Jeff Haas NextHop Technologies From tbarron at cisco.com Fri Jul 26 15:40:30 2002 From: tbarron at cisco.com (Tom Barron) Date: Fri, 26 Jul 2002 10:40:30 -0500 Subject: Scope of Communities [was: Re: Last call for bgp-redistribution] In-Reply-To: <20020726103530.B7985@nexthop.com> References: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> <15680.4158.196798.586875@dhcp-64-101-210-162.cisco.com> <20020725125041.G3597@nexthop.com> <15680.13909.557504.824415@dhcp-64-101-210-162.cisco.com> <20020725140936.I3597@nexthop.com> <15680.18274.30731.241160@dhcp-64-101-210-162.cisco.com> <20020726103530.B7985@nexthop.com> Message-ID: <15681.28014.852681.387665@gargle.gargle.HOWL> >>>>> On Fri, 26 Jul 2002 10:35:30 -0400, Jeffrey Haas said: Jeff> I'm not Andrew, but this still sounds good. >> >> - strip all communities on input except >> * communities you tell your customers they may use >> * well-known communities >> >> - act on well-known communities and communities you tell your >> customers they may use >> >> - strip all communities on output except >> * well-known communities >> * communities you have deliberately added to signal >> to the next AS But note that this variant strips communities not of my own definition if they aren't WellKnown. I like this policy, but it would damage your multi-AS-hop signalling cases, as an AS in the path of such signalling would strip off the communities in question. I'm inclined to say that where there is a genuine need to use communities to signal further than an immediate AS-AS boundary, one ought to follow Geoff and seek to get that community recognized as a WKC. Then the above policy would do no damage. I'd be inclined to back off, however, if it turns out that - contrary to my experience - there is indeed already significant use of ad-hoc, locally significant communities to signal information further than the immediate AS-AS boundary. Before asking, say, NANOG, I want to make sure that we frame the issue well .... Thanks, - Tom From ww at styx.org Fri Jul 26 16:01:28 2002 From: ww at styx.org (William Waites) Date: Fri, 26 Jul 2002 12:01:28 -0400 Subject: Scope of Communities [was: Re: Last call for bgp-redistribution] In-Reply-To: <20020726103530.B7985@nexthop.com>; from jhaas@nexthop.com on Fri, Jul 26, 2002 at 10:35:30AM -0400 References: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> <15680.4158.196798.586875@dhcp-64-101-210-162.cisco.com> <20020725125041.G3597@nexthop.com> <15680.13909.557504.824415@dhcp-64-101-210-162.cisco.com> <20020725140936.I3597@nexthop.com> <15680.18274.30731.241160@dhcp-64-101-210-162.cisco.com> <20020726103530.B7985@nexthop.com> Message-ID: <20020726120128.V24000@styx.org> On Fri, Jul 26, 2002 at 10:35:30AM -0400, Jeffrey Haas wrote: > > Let me give another example that might be useful from an old NANOG > discussion. AboveNet was blackholing a certain IP address in a netblock > that they were otherwise cleanly routing. This cause people who > were using said route themselves grief if they were trying to get to > said address. AboveNet *could* have tacked on a community that said > "this route is unclean, use at your own risk." 6461:1313 or some such. :-) I'm not sure I understand why it seems to be the common practice today to strip routes of their communities on ingres. Tagging a route with a community adds information -- I might not know the meaning of the information, but if I do there might be some way I can make use of it, as the example you give illustrates. Is it not best to try to preserve as much information as possible about a route, modulo scaling issues? I think it can be argued that O(sum of all AS path lengths compared to number of routes) == O(sum of all community attributes compared to number of routes) (at worst) at least as far as memory footprint goes. So I don't think there are scaling problems associated with keeping the information around. Is there a compelling reason to strip comminities off of the routes at all in the transit path? -w From tbarron at cisco.com Fri Jul 26 16:37:47 2002 From: tbarron at cisco.com (Tom Barron) Date: Fri, 26 Jul 2002 11:37:47 -0500 Subject: Scope of Communities [was: Re: Last call for bgp-redistribution] In-Reply-To: <20020726120128.V24000@styx.org> References: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> <15680.4158.196798.586875@dhcp-64-101-210-162.cisco.com> <20020725125041.G3597@nexthop.com> <15680.13909.557504.824415@dhcp-64-101-210-162.cisco.com> <20020725140936.I3597@nexthop.com> <15680.18274.30731.241160@dhcp-64-101-210-162.cisco.com> <20020726103530.B7985@nexthop.com> <20020726120128.V24000@styx.org> Message-ID: <15681.31451.662760.559388@gargle.gargle.HOWL> >>>>> On Fri, 26 Jul 2002 12:01:28 -0400, William Waites said: William> On Fri, Jul 26, 2002 at 10:35:30AM -0400, Jeffrey Haas wrote: >> >> Let me give another example that might be useful from an old NANOG >> discussion. AboveNet was blackholing a certain IP address in a netblock >> that they were otherwise cleanly routing. This cause people who >> were using said route themselves grief if they were trying to get to >> said address. AboveNet *could* have tacked on a community that said >> "this route is unclean, use at your own risk." 6461:1313 or some such. :-) William> I'm not sure I understand why it seems to be the common William> practice today to strip routes of their communities on William> ingres. Tagging a route with a community adds information William> -- I might not know the meaning of the information, but William> if I do there might be some way I can make use of it, as William> the example you give illustrates. Is it not best to try William> to preserve as much information as possible about a route, William> modulo scaling issues? William> I think it can be argued that William> O(sum of all AS path lengths compared to number of routes) == William> O(sum of all community attributes compared to number of routes) William> (at worst) at least as far as memory footprint goes. William> So I don't think there are scaling problems associated William> with keeping the information around. William> Is there a compelling reason to strip comminities off of the William> routes at all in the transit path? William> -w As an operator, I'm motivated by a desire to write routing policy against a known background - to match against routes containing communities that mean something to me, either because they are of my own definition or because they are well known communities, and not to have to worry about whether my match clauses are true or false in the presence of communities that are only of local significance elsewhere. As an implementor, I have some concern about the number of communities that can be carried in an update message, especially the number of extended communities. Today this probably isn't an issue, but see the commmunity pollution example in Bruno's NANOG25 talk (http://www.nanog.org/mtg-0206/bruno.html). - Tom From crimson at gweep.net Fri Jul 26 18:24:34 2002 From: crimson at gweep.net (Joe Provo) Date: Fri, 26 Jul 2002 14:24:34 -0400 Subject: Scope of Communities [was: Re: Last call for bgp-redistribution] In-Reply-To: <20020726120128.V24000@styx.org>; from ww@styx.org on Fri, Jul 26, 2002 at 12:01:28PM -0400 References: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> <15680.4158.196798.586875@dhcp-64-101-210-162.cisco.com> <20020725125041.G3597@nexthop.com> <15680.13909.557504.824415@dhcp-64-101-210-162.cisco.com> <20020725140936.I3597@nexthop.com> <15680.18274.30731.241160@dhcp-64-101-210-162.cisco.com> <20020726103530.B7985@nexthop.com> <20020726120128.V24000@styx.org> Message-ID: <20020726142434.A93006@gweep.net> [way behind, but this thread piqued interest as an operator] On Fri, Jul 26, 2002 at 12:01:28PM -0400, William Waites wrote: [snip] > Is there a compelling reason to strip comminities off of the > routes at all in the transit path? To not have straggling bits of control data that one did not intend in one's network altering things nondeterministically. If one is using any specific attributie gfor control, one needs to have an FSM of sorts (why one vendor got beat up badly for their BGP tie-breaker varying from what they published for many years). Operators who are not using certain control knobs may be letting them trickle unmolested and in their ignorance allowing folks to remote- control their networks. Just because something is a common control knob (like well-known communikties) doesn't mean everyone uses them. But you can be sure the folks who intend to use them scrub everything but the ones they intend to use. That's just simple engineering of the steady-state. Of course, there will be operators who decide for/against (and change one way or the other based on customer demand) the use of any control knobs. As with bogon filtering, a leaf ASes isn't going to be *guarenteed* any action (honouring of prefixes, communities, etc) beyond the reach of your contracts. IMO, putting the capability out there knowing it will address some of the problems and will be used some of the time is compelling. Major providers have been trending toward expanding and publishing their existing act-on-peer communities (two I watch have updated their public docs in the last two weeks). I think that represents a strong trend of desire for leaf ASes to have control without the tragedy of the commons triggered by other approaches; the concept is widely accepted and it would be easier for the leaf ASes to manage (and the network operators) should these approaches be standardized. Wow, I guess a long way of agreeing yes that "all intended transitive communities should be blessed as Well-Known". Hope was relevant, back to my hole now. joe -- crimson at sidehack.gweep.net * jprovo at gnu.ai.mit.edu * jzp at rsuc.gweep.net RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From jhaas at nexthop.com Fri Jul 26 18:23:13 2002 From: jhaas at nexthop.com (Jeffrey Haas) Date: Fri, 26 Jul 2002 14:23:13 -0400 Subject: Scope of Communities [was: Re: Last call for bgp-redistribution] In-Reply-To: <20020726120128.V24000@styx.org>; from ww@STYX.ORG on Fri, Jul 26, 2002 at 12:01:28PM -0400 References: <5.1.0.14.2.20020725095250.00b35890@kahuna.telstra.net> <15680.4158.196798.586875@dhcp-64-101-210-162.cisco.com> <20020725125041.G3597@nexthop.com> <15680.13909.557504.824415@dhcp-64-101-210-162.cisco.com> <20020725140936.I3597@nexthop.com> <15680.18274.30731.241160@dhcp-64-101-210-162.cisco.com> <20020726103530.B7985@nexthop.com> <20020726120128.V24000@styx.org> Message-ID: <20020726142313.K7985@nexthop.com> Trimming to:/cc: list. On Fri, Jul 26, 2002 at 12:01:28PM -0400, William Waites wrote: > I'm not sure I understand why it seems to be the common > practice today to strip routes of their communities on > ingres. The impression I have been given from chatting with random operators is that some implementations behave poorly memory-wise in response to the presence of large numbers of communities. > I think it can be argued that > > O(sum of all AS path lengths compared to number of routes) == > O(sum of all community attributes compared to number of routes) The pathological case is you'll have a distinct community set per route-instance learned per-peer. In other words, you may find that this causes you to waste more memory on a per route-instance basis than you otherwise would. And operators are already annoyed at the number of prefixes in the system. In practice, I think we see that the number of community sets is pretty reasonable and they tend to be occur multiple times. This makes them refcountable to save memory. Additionally, community sets tend to be shared with common path attribute sets, so the entire path attribute set is refcountable. This may vary depending on the route mixture. A snapshot of several core border routers would be instructive. A quick look at route-views shows the following: : 120597 network entries and 5576578 paths using 211972329 bytes of memory 1757 bytes per network entry : 949768 BGP path attribute entries using 49387936 bytes of memory 52 bytes per path attribute entry : 740005 BGP AS-PATH entries using 18332774 bytes of memory roughly 25 bytes per AS-PATH entry : 3724 BGP community entries using 128818 bytes of memory roughly 35 bytes per community entry. > -w -- Jeff Haas NextHop Technologies