Rare project developers

[mc36 <>]

hi,
https://github.com/rare-freertr/freeRtr/commit/4126700ff9631e32cb9eb57925b332e8890b6f6a
 should fix this...
now what interops do you suggest for the weekly runs? i just spotted that frr 
also have this:
https://docs.frrouting.org/en/latest/bgp.html#bgp-roles-and-only-to-customers

https://github.com/rare-freertr/freeRtr/tree/master/cfg

_should_ list intop9-bgp* as frr-bgp-interops, here is the latest run where 
they are cliclable:

https://groups.io/g/freertr/topic/latest_test_runs/98428978
thx,
cs

On 4/27/23 01:08, Alexander Zubkov wrote:
> Hi Fr  d  ric,
>
> Sure, I will do it!
>
> On Wed, Apr 26, 2023 at 3:16   PM Fr  d  ric LOUI < 
> <>> wrote:
>
>
>     Hi Alexander,
>
>     Can you create a GitHub issue 
> [here](https://github.com/rare-freertr/freeRtr/issues 
> <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 
> <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
>     
> <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
>     
> <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 
> <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 
> <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 
> <https://github.com/rare-freertr/freeRtr-containerlab>
>      > >
>      > > I just need now to update containerlab documentation. :)
>      > >
>      > > Cheers
>      > > Frederic
>      >