Rare project developers

["Moises R. N. Ribeiro" <>]

Csaba,


I am not sure I've grasped what you have in mind...so, here come the (usual) 
silly and naive questions/comments/requests: 

Config interlock/lockdown sounds interesting, however, can you 
overseen/comment on how stiff the whole config system becomes with such 
interdependent approach? Oh, you see, TACACS and other centralization (for 
authentication/coordination/orchestration) measures will follow soon...thus, 
it is possible that this modification you're proposing now may push freeRtr 
away from the pure distributed approach you'd managed to preserve.    

GRE seems to be your interconnection default/paradigm for the backplane 
"virtual bus/cabling. On the backplane "connector/port" itself, will it be a 
single entrance or multiple points of attachment? It sounds like an entrance 
(bridge_id) that can be turned (internally) into multi-port 
element/user/local port (by that bridge), right? 

Provided that info in the backplane header are "blindly applied to the packet 
processing state", what are your thoughts on backplane (route) loops? How 
that could be prevented/detected/mitigated? A user decide to 
stitch/interconnect backplanes not using L3 elements...Or is it compulsory to 
have VRFs (and they would drop packets by TTL) to do that? I'm assuming that 
"bridge" is Br-like element in virtualized environments. What exactly is a 
"switch"? Is it a fully functional L2 element with STP, for instance?  

Finally, I am trying to think of what kind of expressiveness (i.e., 
topologies/slices/architectures) your proposal enables to be implemented 
using the elements IDs you mentioned (e.g, switch, VRF, bridge, 
nexthop)...any illustrative example in mind to help us visualize that?


Regards,
Moises 


----- Mensagem original -----
De: "cs" <>
Para: "Moises Renato Nunes Ribeiro" <>
Cc: "edgardcunha" <>, "Everson Borges" 
<>, "gabrieltetznermenegueti16" 
<>, "rare-dev" <>
Enviadas: Quarta-feira, 4 de maio de 2022 10:44:35
Assunto: Re: brainstorming about stacking in rare/freertr

hi,

On 5/4/22 13:24, Moises R. N. Ribeiro wrote:
> 
> Not sure how it works in blades and stacks, perhaps permission to config 
> "backplane networking" should require a second level security password. 
> Sort of admin/SU to play with parameters that are beyond tenant (regular 
> user, not privileged user) scope.
> 
not a bad idea, i was also thinking to introduce a kind of lockdown under 
various config modes... :)
until that, freerouter have tacacs command authorization, that is, every 
command could be forbidden by a central authority...

> Apparently, you are creating a backplane protocol/encapsulation and will 
> stick/remove an extra header to packets that should go through them. In a 
> general case, i.e., not assuming freeRtR network, P2P/overlay/proxy kind of 
> tunnels for stitching freeRtr backplanes of distributed instances do 
> freeRtr would do the trick. PolKA/SR would do that too, in case other 
> instances in between to lead to the destination freeRtr backplane, right? 
> But it requires PolKA/SR-enabled nodes in between. And that might beg for a 
> centralized (PCE-like) control and multidomain strategies the near future.

yeahh so polka also could do the that part to just route the fabric packets 
but still, it seems out of scope for polka...
i'm thinking for now about a header to be inserted after the ethertype (to be 
able to go over a gre for example):

bit<16>target_switch_id
bit<16>target_vrf_id
bit<16>target_bridge_id
bit<16>target_nexthop_id

and in case it's present (that is, the packet arrived from a previously 
backplane configured port),
it just blindly get applied to the packet processing state, and that's all 
what needed in the dataplanes...

br,
cs


> 
> Regards,
> Moises
>    
> 
> ----- Mensagem original -----
> De: "cs" <>
> Para: "Moises Renato Nunes Ribeiro" <>
> Cc: "edgardcunha" <>, "Everson Borges" 
> <>, "gabrieltetznermenegueti16" 
> <>
> Enviadas: Quarta-feira, 4 de maio de 2022 2:04:35
> Assunto: Re: brainstorming about stacking in rare/freertr
> 
> hi,
> 
> On 5/4/22 01:44, Moises R. N. Ribeiro wrote:
> 
>>
>> Did we get it right?
> yeahhh, you got it 100% right...
> 
> 
>> If so, I am afraid to tell you this is "mission impossible"...just give it 
>> up and buy Cisco....freeRtr will never be able to....(just in case you're 
>> driven by challenges and low
>> steam blackmails)   :-)
> i spent the last day thinking through things here & there and i still see 
> it feasible...
> and basically we're almost there, just some very small&(seemingly)easy 
> functionalities are missing:
> - backplane header functionality to the dataplanes to pass the packets back 
> & forth natively...
> - the connection capability between multiple p4 servers to share the 
> local&remote nexthop info...
> 
> br,
> cs
> 
> 
> 
>> Regards,
>> Moises
>> image.png
>>
>>
>>      fyi
>>
>>
>>      -------- Forwarded Message --------
>>      Subject: brainstorming about stacking in rare/freertr
>>      Date: Tue, 3 May 2022 09:09:44 +0200
>>      From: mc36 < <>>
>>      Reply-To:  <>
>>      To:  <> 
>> < <>>
>>
>>      hi,
>>
>>      during the migration to sde990 we started using the port metadata to 
>> silent a warning about casting portid to subifid...
>>      this seems to open up some more possibilities, especially i'm now 
>> thinking about introducing a new have_backplane flag... :)
>>      the idea here is to one would be able to configure a set of switches 
>> to form a cluster at their control and data planes
>>      much like in cisco aci or their stackwise stuff... here are the some 
>> details i'm thinking about right now:
>>      - on the (on the fly configurable!) backplane ports, we'll use a 
>> small prepended backplane header much like on the cpu-port,
>>            but here with the extra field about the target memberid... this 
>> way the solution will handle well the line-card or
>>            multi-chassis modes of operation, because the backplane packets 
>> become routeable based on the memberid alone...
>>      - all the member switches will have configured with an uniform server 
>> p4lang configuration exclusively dealing with
>>            the backplane port(s) properties and nothing else... under the 
>> hood, they'll run a discovery and relay the for-us
>>            packets toward the elected controller, and relay the rest of 
>> the freertr-middleware communication too...
>>      - there would be (pair of) a dedicated servers, also configured as 
>> part of the backplane to be able to be elected,
>>            who will take control over the whole topology, and act as a 
>> single point of configuration...
>>      - think about running a p4emu or p4dpdk instance, and a p4lang to 
>> control that, but with something more
>>      - all the member switches will have a server p4 sw1..swX instances 
>> where you export your ports vrfs and bridges,
>>            but the trick here would be that these vrf and bridge instances 
>> can span multiple switches without any extra
>>            configuration needed...
>>      - this could be achieved in the dataplanes by having a new kind of 
>> nexthop which will prepend the backplane header,
>>            filling in the target member and the remote nexthopid...
>>      - do in this way, we would be able to express even much tricker 
>> things like, at sw1, i express a member/nexthop pointing
>>            to a dpdk3 node where the nexthop involves some crypto and 
>> transmit to a nexthop who's also a backplane kind, with member
>>            to sw5 and nexthop to a local port...
>>
>>      any idea?
>>      thanks,
>>      cs
>>
>>