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

[Warren Kumari <[e-mail]>]

On Thu, Sep 26, 2019 at 10:52 PM Jeffrey Haas <[e-mail]> wrote:
>
>
>
> On Sep 26, 2019, at 6:43 PM, Warren Kumari <[e-mail]> 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.

Yes, it is valid, but it doesn't "mean" anything more than AS path:
14061 3356 6762 23487 27738 27738 27738 27738 27738 27738 27738 - I
cannot see a scenario where the lack of {} causes loop detection or
anything else to fail.
I *guess* it's possible that there was something like ... 27738 65533
{ 27738 65534 }. The { 27738 65534 } is "interesting" to 65533, and
remote-private could have removed both 65533 and 65534.

Ugh, aggregation for others is ugly (yes, I know, but...)

>
>
> I've also seen a number of instances where the AS_SET contains many
> repeated instances, e.g:
> AS path: 6939 3356 42020 39010 {39275 39275 39275 39275 39275 39275
> 39275 39275 39275 39275} -- this doesn't seem to actually mean
> anything...
>
>
> This one seems very buggy.  The protocol still knows what to do with it.
>
> It'd be interesting to find out what code these folk are running. Hopefully not one of my bugs. :-)

They are all your bugs, Jeff :-)

W

>
> -- Jeff
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf