Re: Porting OpenBSD MPLS to FreeBSD

Hi Neel, it is exciting to see the topic coming alive again.

Once you think is good/ready for testing, or when you require it,  i can 
avail hardware , routers and traffic generator to take the stack for a ride.

Count me in for testing, reporting, etc.

Best regards.

Santi

On 12/6/21 18:40, Rodney W. Grimes wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> Hi Alexander,
>>
>> On 2021-12-04 10:42, Alexander V. Chernikov wrote:
>>>> * Is porting OpenBSD MPLS to FreeBSD feasible, or are we better off
>>>> doing a from-scratch implementation based on netgraph?
>>> It depends. MPLS implementaiton can be splitted into multiple logical
>>> parts - dataplane (input, control, output, forward) and control plane
>>> (programming ip routes+mpls and mpls-only fowarding state). Some parts
>>> of the former can indeed be imported from OpenBSD. However, most of
>>> the control plane part have to be written from scratch. Finally, it
>>> may be desired to maintain an programming interface close to the one
>>> already implemented in major routing SW (frr, bird) - I guess that
>>> would be simpler to achieve with native, non-netgraph implementation.
>> Thanks for your description. I haven't started work yet, but I'd
>> probably import the dataplane from OpenBSD where I can and do a new
>> control plane, maybe that with a FRR/Bird-compatible API.
> When you get to working with FRR let me know, I am a member of
> the CI infustructure team there and can hook you up directly
> with very knowledgeable FRR developers.
>
>> I wasn't too keen on using netgraph anyways, I felt it was unnecessary
>> complexity.
> True, but with that complexity comes an ulmost unlimited flexiablity.
>
>> If I were to work on this, would I be better off starting with the
>> dataplane or control plane?
> I concur with Alexander on this, dataplace first, with an eye on how
> FRR/Bird interact with the dataplane.
>
>>>> * Would some of the other committers here be willing to mentor/help me
>>>> if needed?
>>> I?d love to. Most of my the routing-related stack changes (modular
>>> lookup framework, nexthops, rtsock cleanups) were done to enable
>>> efficient kernel-based MPLS implementation.
>> Thanks!
>>
>> -Neel (nc@)
>>
>>