Thank you, I will not argue anymore as there is not so much interest from Mikrotik.
Yes, RR is an option, but a bad RR implementation is worst than no RR.
Mikrotik last answer is related to the BIRD/FRR issue from 2021:
"That bird problem is completely unrelated. They did not use 2bytes for the length field when extended length bit was set. RouterOS does not do that, length is encoded properly.”
Unfortunately we do not have any support for the CERs and ICXs we have within our network since Brocade got split in many pieces so we cannot ask Extreme Networks anything regarding CER. We do have 2+ years sessions up the CER’s, I cannot say nothing wrong about Netiron.
In the last days I’ve been testing Mikrotik’s CHR 6 release, Junipers vRR, Cisco IOS xRV, none of these generate issues to the CER and neither are affected by the Mikrotik. The only software in my testing that was affected by this is the Netiron, Dell 4032F prints the error and discards the prefix.
Thank you again for your great interest in this issue.
> On 30 Jun 2023, at 17:08, Jörg Kost <jk@ip-clear.de> wrote:
>
> 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.
>>
Yes, RR is an option, but a bad RR implementation is worst than no RR.
Mikrotik last answer is related to the BIRD/FRR issue from 2021:
"That bird problem is completely unrelated. They did not use 2bytes for the length field when extended length bit was set. RouterOS does not do that, length is encoded properly.”
Unfortunately we do not have any support for the CERs and ICXs we have within our network since Brocade got split in many pieces so we cannot ask Extreme Networks anything regarding CER. We do have 2+ years sessions up the CER’s, I cannot say nothing wrong about Netiron.
In the last days I’ve been testing Mikrotik’s CHR 6 release, Junipers vRR, Cisco IOS xRV, none of these generate issues to the CER and neither are affected by the Mikrotik. The only software in my testing that was affected by this is the Netiron, Dell 4032F prints the error and discards the prefix.
Thank you again for your great interest in this issue.
> On 30 Jun 2023, at 17:08, Jörg Kost <jk@ip-clear.de> wrote:
>
> 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.
>>