Re: [GROW] Deprecation of AS_SET and AS_CONFED_SET -- feedback requested

> 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
_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr