Rare project developers

[Alexander Gall <>]

I guess I'll wait a bit with the packaging until this issue is
settled?

-- 
Alex

On Wed, 2 Feb 2022 18:49:00 +0100, Frédéric LOUI <> 
said:

> Hi,
> I’m working on bf_forwarder.py regarding this capability detection.

> Is it ok if I send you the following message:
> ‘capability <capability list>’

> 'capability | copp acl nat vlan bundle bridge pppoe hairpin gre l2tp route 
> mpls vpls evpn eompls gretap pppoetap l2tptap vxlan ipip macsec ipsec 
> pckoudp openvpn wireguard srv6 pbr qos flwspc mroute duplab bier amt nsh 
> polka'

>> From there I have to things to consider:

> 1- From that point I won’t receive any message related to unsupported 
> capability
> 2- Or will I still receive message for unsupported dataplane capability ?

> I can do -1- or -2- or both. 
> -1- is obviously quicker. -2- little bit more subtle as I have to teach the 
> dataplane msg<—>capability awareness.

> -2- is better as you won’t have to change anything except notify the user 
> that the configuration will result in NO-OP.
> -1- will force to somehow process capability list and send (ro not) 
> corresponding message

> Please let me know which you prefer and I’ll implement it ASAP.

> PS: I need this capability list anyway as I need to process (or not) 
> counters so in any case I’ll implement capability detection at bf_forwarder 
> level.
      

> All the best,
> Frederic

>> Le 2 févr. 2022 à 18:36, mc36 <> a écrit :
>> 
>> hi,
>> 
>> after the today discussions, started with alex and simon, and it 
>> progressed with flout, and the decision
>> is made that the dataplanes will send the detected capabilities to the 
>> control plane... at the moment the
>> tofino is the one who is have moving features, but already have a 
>> beginning with the configurable --srv6=0
>> and friends... these will become autodetected by table existence checks, 
>> and reported...
>> 
>> imho i won't deal with this info further as if the bffwd fills the 
>> detected capabilities correctly,
>> it'll cut down the unable-to-program grpc errors simply because it does 
>> not tries to program the
>> offending entries... for such a situations, a simple unknown-command 
>> message could be sent, echoing
>> the original message... which should be logged on terminals/syslogs/etc in 
>> freerouter...
>> and in the rare cases, if we still get grpc errors, they sould be reported 
>> too in a let's say
>> unable2fulfill message, again with the original request...
>> 
>> the p4dpdk and p4pcap already send the capabilities, with this commit:
>> and the sender side: 
>> https://github.com/mc36/freeRouter/commit/30ec54539156d9b5db447f771a341ade424201fc
>> and they don't have to deal with unable-to-program and sorry-notunderstood 
>> messages, fortunately... :)
>> the only thing that can happen if malloc returns null, but then they 
>> simply terminate....
>> 
>> from now, freerouter barely processes the capabilities starting this point:
>> https://github.com/mc36/freeRouter/commit/a1ed7c2953a12130576d8a62499eec2e7868a543
>> 
>> (it also contains a clear command as bffwd moved out of freerouter's 
>> startup territory on
>> the latest nix builds, and this is equivalent to the "clear ip cef *" in 
>> freerouter.... :)
>> 
>> so for now, this is what we have:
>> 
>> noti#
>> noti#show p4lang p4
>> info userReader.cmdEnter:userReader.java:1032 command noti#show p4lang p4  
>> from local:telnet <loop> 23 -> 127.0.0.1 59440
>> 2022-02-02 18:26:08
>> category   | value
>> peer       | 127.0.0.1
>> ready      | 3
>> capability | copp acl nat vlan bundle bridge pppoe hairpin gre l2tp route 
>> mpls vpls evpn eompls gretap pppoetap l2tptap vxlan ipip macsec ipsec 
>> pckoudp openvpn wireguard srv6 pbr qos flwspc mroute duplab bier amt nsh 
>> polka
>> platform   | p4emu/openssl/pcap
>> since      | 2022-02-02 18:17:56
>> for        | 00:08:12
>> 
>> noti#clear p4lang p4
>> 2022-02-02 18:26:13
>> noti#
>> warning servP4lang.srvAccept:servP4lang.java:641 neighbor 127.0.0.1 up
>> noti#
>> 
>> regards,
>> cs
>>