Rare project developers

[Alexander Zubkov <>]

Actually, I found more references in the RFC that it is a local role, so they actually took care about it. I was not attentive when checking it today. :)

Here the possible defined roles are described as if they define the local role:

https://datatracker.ietf.org/doc/html/rfc9234#section-4-2

And here in the table for capability values it is stated "for the local AS" in the header:

https://datatracker.ietf.org/doc/html/rfc9234#values

On Wed, Apr 26, 2023, 08:37 Alexander Zubkov <> wrote:

Hi,

Yes, something like that. I would not say that you "should" enable the force option, because everything will work the same without it. Only your peer will be able not to set role on its side.

I've rechecked the RFC just to be sure. It indeed says you can use this option to require the peer to send its role to you, otherwise the session shouldn't go up. But if both peers send roles, they need to be checked, no matter if strict mode is enabled or not.

https://datatracker.ietf.org/doc/html/rfc9234#section-4.2-5

And I think there can be another problem. Yesterday I mentioned also that you use the notation "neighbor ... role <role>" which resembles like you are setting the peer's role. And I thought that it might be just inverse logic (in RFC you announce local role) or just confusing definition of "local" (not neighbor's role). I digged a bit deeper into that now, and it seems you interpret it as the neighbors's role. For example here you set the OTC attribute if the configured role is "customer":

https://github.com/rare-freertr/freeRtr/blob/de37285db573e671ee84738072ef1afd21837f92/src/net/freertr/rtr/rtrBgpGroup.java#L845

But if you use reverse logic in the configuration, you need to "inverse" the role when sending your role during bgp session open. But you do not do it, for example here:

https://github.com/rare-freertr/freeRtr/blob/3940d3dbc4951370e30b3b26db6fe05e2cf408bf/src/net/freertr/rtr/rtrBgpSpeak.java#L1649

But I might have misinterpreted something in the code.

Here is the reference to the RFC:

https://datatracker.ietf.org/doc/html/rfc9234#section-4-1

It says:

> One of the Roles described below SHOULD be configured at the local AS ... based on the local AS's knowledge of **its** Role.

I only now see that this moment is really cryptic in the RFC. Because I read it after I saw implementation in Bird and RFC presentations where they clearly tell about "local" role, so I was biased when reading it. I'll try to report this problem to the authors.

In the sense of that I believe it would be better not to use the inverse logic in the configuration, because it will contradict how it is done in other bgp implementations and could lead to configuration mistakes.

On Wed, Apr 26, 2023, 07:13 mc36 <> wrote:

hi...

thanks for digging into the sources...

so the main idea behind the force boolean is the incrementan implementation:

the provider could enable at least the attribute placement withoutbthe customer support... ;)

afterwards when the customer enables the open message, the provider should reconfigure the with the enforcement...

afterwaeds, nornally no way from 'escape'.... ;)

br,

cs

Get BlueMail for Android

On Apr 25, 2023, at 17:13, Alexander Zubkov <> wrote:

Hi!

Great news! What is the first version of freeRTr supporting RFC9234? So I could indicate it on the slides.

I peeked a bit at the realization and it seems to me there is a little problem there:

If I understand RFC correctly roles matching should always be checked. And role enforce mode requires the peer to set the role on its side. So in case of neigh. leakForce is true peerLeakRole should be set. And peerLeakRole != ned should be checked always when both peers advertise its role, i.e. neigh. leakRole >= 0 and peerLeakRole >= 0.

PS. Your git repository history is not very user-friendly with those "automatic commits". :)

On Tue, Apr 25, 2023 at 11:57 AM Frédéric LOUI < > wrote:

Hi Alex !

I hope you are doing well.
I had the chance to sync with Csaba MATE (In CC) , freeRTr lead developer and he told me that RFC9234
Is ready to be tested :-)

Please have a look here:
http://sources.freertr.org/cfg/rout-bgp521.tst

All the best
Frederic

> Le 31 mars 2023 à 21:54, Alexander Zubkov < > a écrit :
>
> Great news!
> BTW, have you already implemented RFC9234 in your router? If so, I'll surely mention it in my presentation at CSNOG (if I'll have a slot, of course).
>
> On Fri, Mar 31, 2023 at 7:06 PM Frédéric LOUI < > wrote:
> Well yes, it is a shame …
>
> But I hope to have more stuff to share with the community.
>
> And also I need to tell you that thanks to you we have a containelrlab images running !
> https://github.com/rare-freertr/freeRtr-containerlab
>
> I just need now to update containerlab documentation. :)
>
> Cheers
> Frederic