On Thu, Mar 01, 2018 at 10:54:08AM +0900, Randy Bush wrote: > >> question for ops: > >> > >> did you even know this was happening, that "set community" might not > >> replace ALL well known communities?" > >> > >> the reasom i ask is, as you see in the draft, we are hesitant to > >> propose changing behavior for existing wks as it might impact ops. > >> but if we were not aware of this behavior, then maybe change is ok, > >> in fact desirable. > >> > >> i did not realize this was going on. jay, who discovered it, was > >> surprised. > > > > NTT noticed this type of inconsistency between some vendors somewhere > > in July 2016. A customer used a combination of NTT-specific BGP > > communities to influence traffic, together with > > NO_ADVERTISE. Unbeknownst to us, this combination of communities > > resulted in network behavior that made the customer happy. > > > > Further down the timeline, the customer was migrated to another > > vendor's routing platform (or got a new circuit on a new platform, > > don't recall) and suddenly noticed that the previously working > > combinatory trick no longer worked. At that point investigation showed > > that "set community" does not do the same thing on all platforms, and > > we had to figure out a way to make things consistent. > > > > Our currently routing policy is to allow (not delete) some of the > > well-known communities, and squash (remove) a bunch of > > not-so-well-know communities and unsupported well-known communities, > > and let potential-future-well-known communitie pass-through to try to > > not stiffle innovation. For each new well-known community we'll have > > to decide whether to remove it or let it pass-through. > > not sure if you and/or your customer(s) would be made unhappy if current > behavior in some vendor(s), where "set" does not remove some wkcs, was > changed to remove all.
I'm not sure either. NTT's thinking is shifting to "delete as little as you can, preserve as much of other people's communities", which precludes the use of "set community" anyhow. I hope that in the 'large community' era, life will be simpler where you can just delete "2914:*:*", and perhaps "65535:* except 65535:0" on sessions where you don't want to honor NTT-specific communities and WKCs (except GRACEFUL_SHUTDOWN) and leave the rest. Oh.. that's already quite involved. :-) I know of other carriers who are not interested in preserving any community information and heavily rely on "set community" == 'delete'. But... at the same time those same carriers are interested in honoring GRACEFUL_SHUTDOWN. If the concept of "set community X" == "delete everything & set X" had actually been a thing in the last 10 years it would've prevented that example I mentioned. On the other hand, "set community X" == "delete everything" also removes WKC an operator might want to honor, so perhaps the (unreliable) concept of "set community X" is outdated and needs to be replaced with a different construct all together. Trouble with WKC is that some you want to remove, some you want to honor, and some you just want to pass-through without taking any action. "set community" isn't a great fit for cherry-picking. Kind regards, Job _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
