Rare project developers

[mc36 <>]

hi,
so imho just use the existing infra that we have in bffwd, that is, the tons 
of parameters,
the self.srv6 and friends, which already protect against accidental 
programming...
it could serve to protect against accidental counter readings too...
regarding the capability, some have 1:1 mapping from that already existing 
list, some dont...
these mostly belong to a given table's existence, and you should fill them by 
checking if
the table exists or not... to have the same capability list that exists 
already in the
test cases 
(https://github.com/mc36/freeRouter/blob/cf0bac40f82fb3383f5982f80d3de08d35a3de70/cfg/p4lang-rout011.tst#L78)
and in the dataplane vm descriptors 
(https://github.com/mc36/freeRouter/blob/cf0bac40f82fb3383f5982f80d3de08d35a3de70/cfg/p4lang304.ini#L1)
and is actively used to select that which vm is usable to exercise the given 
test...
so well for that, we'll need the info it the given table exists, and if the 
given
table have a given action... for example, mcast table could have _bier 
action, then
it indicates the bier capability... but that's a huge file with a lot of 
ifdef-s within...
the other bad guy is tunneling, which is a single table but a lot of ifdefs 
within...
but other features are much easier to detect, for example, pure existence of 
tbl_ipv4_acl
indicates that inacl is here...
and some capabilities are cannot disabled, like routing, vlan, hairpin, and 
bundle...
regards,
cs


On 2/2/22 18:49, Fr  d  ric LOUI wrote:
> 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