> On Oct 2, 2019, at 7:45 PM, Rob Foehl <[email protected]> wrote: > > On Thu, 26 Sep 2019, Jeffrey Haas wrote: >>> On Sep 26, 2019, at 6:43 PM, Warren Kumari <[email protected]> wrote: >>> >>> This is nice, but what would make it more useful would be if it also >>> reported if there are *useful* AS_SETS / if the AS_SET means anything. >>> >>> For example, from Jared's email below: >>> AS path: 14061 3356 6762 23487 27738 27738 27738 27738 27738 27738 >>> {27738} -- the 27738 AS already shows up as a non-AS_SET in the path. >> >> This one is on the buggy end of things, but still reasonably valid. It >> smells like something that passed through remove-private of some flavor. > > I'd wager this explains nearly all of the "set of one" instances seen in the > wild -- there are currently a half dozen or so with a set containing a > private AS at the end of the path. > >> It'd be interesting to find out what code these folk are running. Hopefully >> not one of my bugs. :-) > > I've never had an interaction with AS_SET that could be described as anything > other than broken -- like, ever, from any vendor. I'd prefer to see them > disappear entirely, but if that doesn't happen, at least having a > "no-as-sets-under-any-circumstances" policy knob would be helpful…
I think back in the days when ANS was still a major player and if you were routed depended upon did you follow the rules that Curtis required, they were still valid. I think in most modern cases they’re likely not intended or some weird hybrid AS_SET+CONFED setup, likely with remove-private as Jeff speculates. I’ve not yet composed e-mail to the people originating these, but it shouldn’t be hard to contact them. They may not know about the issue. (Generally operators lack awareness of what they route). - Jared _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
