Skip to Content.

rare-dev - Re: [rare-dev] capability and platform info from the dataplanes...

Subject: Rare project developers

List archive


Re: [rare-dev] capability and platform info from the dataplanes...


Chronological Thread 
  • From: Frédéric LOUI <>
  • To:
  • Subject: Re: [rare-dev] capability and platform info from the dataplanes...
  • Date: Thu, 3 Feb 2022 11:21:50 +0100
  • Dkim-filter: OpenDKIM Filter v2.10.3 zmtaauth01.partage.renater.fr 8B2951404A2

Please go ahead with the packaging.

There should not be major change and also more importantly you’d have your
continuous build in place.

In any case I’ll warn you about the changes. :)

> Le 3 févr. 2022 à 11:12, Alexander Gall <> a écrit :
>
>
> 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
>>>




Archive powered by MHonArc 2.6.19.

Top of Page