Rare project developers

[Frédéric LOUI <>]

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
>