There is a difference if you have to read an unsigned int 16 or unsigned eight from the packet stream, and flags are set to 1 by default, which is not found in the standard.
Also, as a counterexample, looking at the FRR open source code ensures that extended flags are only set if used and corresponding integers are read/written. I'm just afraid that arguing won't help in your case. It is, of course, a great pity that the manufacturer does not seem to care about the interoperability of its device. The handling will then probably also affect other areas and Co. That doesn't look very customer friendly. Luckily you can choose your manufacturer. Of course, you can also open a ticket with Extreme again if you sign a valid support contract. Which I always appreciate with Brocade and now Extreme; once you get past the first barrier of "do you think it's a bug?", you quickly have contact with support or engineering, who can really familiarize themselves with your problem and ultimately fix it. In addition, there is the first-class release/change log, where every small bug can also be found. Unfortunately, in the early days of the SLX, we found and reported many "startup" bugs, and everything was always fixed, it's running for good now. And with NetIron systems, we have BGP sessions with 900 days and more uptime... In this sense: Buy something good with appropriate support :-) On 30 Jun 2023, at 14:41, Bogdan-Stefan Rotariu wrote: > Ok, so, this is te answer from Mikrotik regarding the extended-length. > > "extended length" is not really related to this issue. That flag only signals > how length value is encoded. "extended length" does not determine on how ASNs > are encoded. > > Regarding length itself, RFC does not define that extended length attribute > MUST not be used when length is less than 255. "MAY" and "MUST" meaning is > not the same. > _______________________________________________ foundry-nsp mailing list foundry-nsp@puck.nether.net http://puck.nether.net/mailman/listinfo/foundry-nsp
