RARE user and assistance email list

[Simon Leinen <>]

Tim Chown writes:
> Implementing bier is great.  There’s a few ietf-ers I know who would be 
> interested to hear :)

oh yes... like our old friend Stig Venaas!?
-- 
Simon.

>> On 2 Feb 2021, at 07:48, mc36 <> wrote:
>> 
>> hi,
>> please find attached the new test runs. news that bmv2
>> got the mldp core and edge features.
>> now the tofino to follow that....
>> regards,
>> cs
>> 
>> 
>> On 2/1/21 10:57 AM, mc36 wrote:
>>> hi,
>>> i just finished (1) the huge refactoring described in my previous mail!
>>> please find attached the fresh test runs with all the dataplanes, the
>>> p4 based ones now use both ingress and egress pipes which was a 
>>> prerequisite
>>> to continue adding nexthop based multicast features to these...
>>> so for now, i'll do so by removing the 'not applicable' from p4
>>> results the last some test runs....
>>> regards,
>>> cs
>>> 
> https://bitbucket.software.geant.org/projects/RARE/repos/rare/commits/05e54cb91a2f5b3ede7f0e0459109b81c689fe47

>>> On 1/30/21 8:07 AM, mc36 wrote:
>>>> hi,
>>>> 
>>>> please find attached the latest test runs with bmv2...
>>>> no new features but the bmv2 p4 code got that huge [1]
>>>> refactoring that i described in the previous mail.
>>>> that is, the decapsulation & routing decision happens
>>>> in ingress and the encapsulation happens in egress.
>>>> 
>>>> now i'll proceed with the tofino code too, it'll be a
>>>> bit more tricky as that guy have completely separate
>>>> two stages with own parser, match-actions and deparser
>>>> too, whereas bmv2 share the all the metadata and headers
>>>> between the stages...
>>>> 
>>>> and after that, when everything passes again on tofino too,
>>>> i'll start adding the newest multicast feature to both p4
>>>> codes, that triggered this whole rework: the lsm edge&core...
>>>> (dpdk code already have it all, so at least i see it working:)
>>>> 
>>>> and when i'm done with the lsm, i'll proceed to bier (not i
>>>> the but but with [2] :), which could be a game-changer for
>>>> those who use multicast because it fully eliminates tree
>>>> building in the core elements for multicast, and as far as
>>>> i know, we'll be the first one who'll have it in hw...
>>>> 
>>>> regards,
>>>> cs
>>>> 
>>>> 1: 
>>>> https://github.com/frederic-loui/RARE/commit/dfb3ff2f3d52dc58f6c38d2b2ae12ed74cc10302
>>>> 
>>>> 2: https://tools.ietf.org/html/rfc8279
>>>> 
>>>> On 1/28/21 9:02 PM, mc36 wrote:
>>>>> hi,
>>>>> please find attached the fresh runs with dpdk.
>>>>> news is the label switched multicast features arrived.
>>>>> it means basically mldp p2mp, mldp mp2mp, rsvp-te p2mp,
>>>>> pim/igmp-mldp interworking, mldp based mvpn and friends...
>>>>> 
>>>>> regarding the bmv2 and tofino dataplane, there was a long
>>>>> conversation about it at the intel community (1), and finally
>>>>> we concluded that we should move away from the current
>>>>> ingress-pipe-only model and do the encapsulation
>>>>> exclusively in the egress pipeline...
>>>>> it'll free up some space in the ingress for more
>>>>> simultaneous features (or bigger lookup tables)
>>>>> and will provide us the flexibility needed for
>>>>> the lsm. the tricky part here is that for pure
>>>>> multicast, there is no nexthop involved in the
>>>>> flooding, and as a quick hack, i replicated the
>>>>> vlan-out table to the egress... but in case of lsm,
>>>>> we'll need the nexthop rewrite info also because lsm
>>>>> is basically unicasted on the link, but mostly i
>>>>> want to get it also done cleanly so nothing left
>>>>> but to move everything from nexthop to the egress...
>>>>> regards,
>>>>> cs
>>>>> 
>>>>> 1:
> https://community.intel.com/t5/Intel-Connectivity-Research/ingress-vs-egress-processing/m-p/1249943#M2025
>>