From smd at clock.org Fri Jun 15 13:13:59 2001 From: smd at clock.org (Sean M. Doran) Date: Fri, 15 Jun 2001 06:13:59 -0700 (PDT) Subject: random idea: constraint communities Message-ID: <20010615131359.4D2B9C7909@cesium.clock.org> Gosh, email on Ptomaine - growth of the routing table list, relevant to a discussion at the last BoF. :-) :-) In order to solve Geoff's "action-at-a-distance" problem wrt leaked longer prefixes, I was wondering if anyone could sanity-check an idea that occurred to me in the shower today. Well-known-community-PREFIX: 65535. Suffix=ASN to which we DO NOT ANNOUNCE 65534. ASN to which we DO ANNOUNCE The semantics of the first community seems straightforward: routers which see 65535:1755 will not announce the NLRI to AS 1755. This is an anti-generalization of an existing well-known community, and a consolidation of lots of ASN:XXX private communities that have the same (but non-transitive, and non-global) semantics. The problem is what to do in a router which cannot grok communities, or these specific communities. Perhaps routers in 1755 in this example should discard prefixes they receive with 65535:1755 set. WRT the 2nd prefix, we only announce to ASes explicitly enumerated by 65534-prefixed communities; we do not announce to ASes not so enumerated. The problem here is what happens if a router which does not constrain reannouncement hears the NLRI because it is in an AS explicitly listed with a 65534-prefixed community. (i.e., a "leak") I figure that these two tools should give people like Geoff a chance to influence cooperative ASes some hops away from himself, by sending them "tailored" (e.g. more-specifics) routing information without that information necessarily becoming global. Sean. From apb at cequrux.com Fri Jun 15 16:00:14 2001 From: apb at cequrux.com (Alan Barrett) Date: Fri, 15 Jun 2001 18:00:14 +0200 (SAST) Subject: random idea: constraint communities In-Reply-To: <20010615131359.4D2B9C7909@cesium.clock.org> Message-ID: On Fri, 15 Jun 2001, Sean M. Doran wrote: > In order to solve Geoff's "action-at-a-distance" problem wrt leaked > longer prefixes, I was wondering if anyone could sanity-check an idea > that occurred to me in the shower today. > > Well-known-community-PREFIX: 65535. Suffix=ASN to which we DO NOT ANNOUNCE > 65534. ASN to which we DO ANNOUNCE Looks sane to me. > The problem here is what happens if a router which does not > constrain reannouncement hears the NLRI because it is in an AS > explicitly listed with a 65534-prefixed community. (i.e., a > "leak") I would worry more about leaks that involve deletion of the community attributes. If the community attributes are not deleted, then other ASes that receive the route, but can tell that they should not have received it, can simply drop it. Big leaks (affecting many routes) are likely to be found and fixed soon, but small leaks acould easily go undetected for a long time. Small leaks might not be a serious a problem. You can sometimes tell (by comparing the AS-path with the list of DO-ANNOUNCE communities) that some particular neighbour should be the end of the line. you can tell that, you can turn on the no-export community in your announcements to that neighbour. This might reduce the number of leaks. --apb (Alan Barrett) From randy at psg.com Fri Jun 15 16:06:41 2001 From: randy at psg.com (Randy Bush) Date: Fri, 15 Jun 2001 09:06:41 -0700 Subject: random idea: constraint communities References: <20010615131359.4D2B9C7909@cesium.clock.org> Message-ID: > Well-known-community-PREFIX: 65535. Suffix=ASN to which we DO NOT ANNOUNCE > 65534. ASN to which we DO ANNOUNCE don't you want those target asns to be a set with more than one element? randy From arnold at nipper.de Fri Jun 15 16:35:02 2001 From: arnold at nipper.de (Nipper, Arnold) Date: Fri, 15 Jun 2001 18:35:02 +0200 Subject: random idea: constraint communities References: <20010615131359.4D2B9C7909@cesium.clock.org> Message-ID: <007f01c0f5b9$21363750$0190a8c0@nipper.de> randy wrote: > > Well-known-community-PREFIX: 65535. Suffix=ASN to which we DO NOT ANNOUNCE > > 65534. ASN to which we DO ANNOUNCE > > don't you want those target asns to be a set with more than one element? > yes, Arnold From yakov at juniper.net Fri Jun 15 16:37:51 2001 From: yakov at juniper.net (Yakov Rekhter) Date: Fri, 15 Jun 2001 09:37:51 -0700 Subject: random idea: constraint communities In-Reply-To: Your message of "Fri, 15 Jun 2001 09:06:41 PDT." Message-ID: <200106151637.JAA25646@red.juniper.net> > > Well-known-community-PREFIX: 65535. Suffix=ASN to which we DO NOT ANNOUNCE > > 65534. ASN to which we DO ANNOUNCE > > don't you want those target asns to be a set with more than one element? may be even go as far as suggesting something along the lines of dist_list_incl, and dist_list_excl ... Yakov. From randy at psg.com Fri Jun 15 16:39:46 2001 From: randy at psg.com (Randy Bush) Date: Fri, 15 Jun 2001 09:39:46 -0700 Subject: random idea: constraint communities References: <20010615131359.4D2B9C7909@cesium.clock.org> <007f01c0f5b9$21363750$0190a8c0@nipper.de> Message-ID: >>> Well-known-community-PREFIX: 65535. Suffix=ASN to which we DO NOT ANNOUNCE >>> 65534. ASN to which we DO ANNOUNCE >> don't you want those target asns to be a set with more than one element? > yes i fear that i was probably too terse again. o the set would be large o the fine-grained, per-as tuning, as opposed to the peer/transit dichotomy which i proposed, could make this terribly hard to debug in reality, and might lead to exciting routing anomalies randy From jhaas at nexthop.com Mon Jun 18 15:02:47 2001 From: jhaas at nexthop.com (Jeffrey Haas) Date: Mon, 18 Jun 2001 11:02:47 -0400 Subject: random idea: constraint communities In-Reply-To: <20010615131359.4D2B9C7909@cesium.clock.org>; from smd@clock.org on Fri, Jun 15, 2001 at 06:13:59AM -0700 References: <20010615131359.4D2B9C7909@cesium.clock.org> Message-ID: <20010618110247.E16885@nexthop.com> On Fri, Jun 15, 2001 at 06:13:59AM -0700, Sean M. Doran wrote: > The problem is what to do in a router which cannot grok communities, > or these specific communities. Perhaps routers in 1755 in this example > should discard prefixes they receive with 65535:1755 set. Yakov already cited the IDRP mechanism. Communities could be deployed today, but would require lots of provider cooperation. Randy's issue (large set) might be addressed by making the filter something like a transitive as-path ORF filter. Some gentlemen had made a suggestion similar to this in the expired draft draft-black-prop-path-00.txt. This didn't have all the flexibility of a full aspath regex filter, but had more flexibility than the dist-list-incl filter of IDRP. For those of you not on the IDR list, I had enquired about previous work in a mechanism to limit the AS diameter of route announcements with more specific (covered) routes in mind. However, I'm not certain how effective such a thing would be in the real Internet. IDRP had a similar mechanism (RD_HOP_COUNT) but different semantics. > Sean. -- Jeff Haas NextHop Technologies From randy at psg.com Fri Jun 29 16:34:38 2001 From: randy at psg.com (Randy Bush) Date: Fri, 29 Jun 2001 09:34:38 -0700 Subject: requirements draft revision References: <20010628022658.J15973@buddha.home.automagic.org> <20010628211637.C39517@layer8.net> <15164.20475.466248.770826@redcs1.procket.com> Message-ID: [ note that i have moved this thread to the ptomain list, where at least my comment is more appropriate ] i agree with most of your logic and definitely with your conclusion. but i do have one quibble. > If your real requirement is to extend the policy control of the > destination, then you must also accept the fact that there must be > distribution about the policy requests of the destination to the transit > domains. However, distributing this information is exactly what is causing > the indigestion in the routing subsystem today. part of the problem is HOW it is distributed, by announcing new/different prefixes, not THAT it is distributed. i.e. we could get a bit of leverage by reducing the scope of distribution a la the DO_NOT_ANNOUNCE_TO_PEERS community. randy From tli at Procket.com Fri Jun 29 18:13:12 2001 From: tli at Procket.com (Tony Li) Date: Fri, 29 Jun 2001 11:13:12 -0700 Subject: requirements draft revision In-Reply-To: References: <20010628022658.J15973@buddha.home.automagic.org> <20010628211637.C39517@layer8.net> <15164.20475.466248.770826@redcs1.procket.com> Message-ID: <15164.50488.778322.841952@redcs1.procket.com> Randy, Excellent point. It is the _global_ distribution of policy information that is undigestible. Local (and therefore limited) distribution has some hope of scalability. Tony Randy Bush writes: | [ note that i have moved this thread to the ptomain list, where at least | my comment is more appropriate ] | | i agree with most of your logic and definitely with your conclusion. but i | do have one quibble. | | > If your real requirement is to extend the policy control of the | > destination, then you must also accept the fact that there must be | > distribution about the policy requests of the destination to the transit | > domains. However, distributing this information is exactly what is causing | > the indigestion in the routing subsystem today. | | part of the problem is HOW it is distributed, by announcing new/different | prefixes, not THAT it is distributed. i.e. we could get a bit of leverage | by reducing the scope of distribution a la the DO_NOT_ANNOUNCE_TO_PEERS | community. | | randy From tli at Procket.com Fri Jun 29 18:29:03 2001 From: tli at Procket.com (Tony Li) Date: Fri, 29 Jun 2001 11:29:03 -0700 Subject: requirements draft revision In-Reply-To: References: <20010628022658.J15973@buddha.home.automagic.org> <20010628211637.C39517@layer8.net> <15164.20475.466248.770826@redcs1.procket.com> Message-ID: <200106291829.LAA07884@redcs1.procket.com> Randy, Excellent point. It is the _global_ distribution of policy information that is undigestible. Local (and therefore limited) distribution has some hope of scalability. Tony Randy Bush writes: | [ note that i have moved this thread to the ptomain list, where at least | my comment is more appropriate ] | | i agree with most of your logic and definitely with your conclusion. but i | do have one quibble. | | > If your real requirement is to extend the policy control of the | > destination, then you must also accept the fact that there must be | > distribution about the policy requests of the destination to the transit | > domains. However, distributing this information is exactly what is causing | > the indigestion in the routing subsystem today. | | part of the problem is HOW it is distributed, by announcing new/different | prefixes, not THAT it is distributed. i.e. we could get a bit of leverage | by reducing the scope of distribution a la the DO_NOT_ANNOUNCE_TO_PEERS | community. | | randy