Rare project developers

[Frédéric LOUI <>]

Hi Alexander,

Can you create a GitHub issue 
[here](https://github.com/rare-freertr/freeRtr/issues)

So that we could keep track of all of these interesting development ?

Thanks for checking the code !
Frederic

> Le 26 avr. 2023 à 14:08, mc36 <> a écrit :
> 
> good point, thanks.. 
> 
> on the next week i'll add the invertser logic...
> 
> br,
> cs
> 
> Get BlueMail for Android
> On Apr 26, 2023, at 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 
>