Rare project developers

[Alexander Gall <>]

On Fri, 25 Feb 2022 10:50:11 +0100, mc36 <> said:

> thinking about it further, if we use the names instead of ids,
> then how will the virtual constructs that remain look alike in the config...
> think about tunnels, bvi, if exported, and so on...
> one still have to write something then to these...

Thanks for all the feedback. I must admit that I'm only looking at a
fraction of the freerouter featutres and it's hard for me to see where
my suggestions might conflict with the things I don't know about.

I think it all boils down to to this: my desire is to free the user as
much as possible form assigning numbers to things that only have
meaning to the various data-planes and would prefer to leave this to
freerouter.  It doesn't mean that we would no longer need any of the
data-plane specific config things, just possibly fewer and with less
information supplied by the user.

For example, in the case of sub-interfaces I'm pretty sure that we
only need "export-port" for the physical ports and everything else can
be inferred from that. For example, if "sdn1" has such an
"export-port" in p4lang, it is clear that all it's sub-interfaces are
also on that data-plane and no explicit "export-ports" are needed to
be completely equivalent to what we have now.

For a bundle, I guess it would also be implicit by looking at the
physical ports.

For other virual ports for which we can't say unambiguoulsy which
data-plane is going to implement them, we will still have to use
explicit configurations.

There may be other constructs that I'm not aware of for which this
would be a problem. I'd be curious what those are and why exactly that
would be a problem.

-- 
Alex

> same goes to the validation on the export-port, if we introduce the 
> auto-subif id allocation:
> so then these tunnels the id field should disappear where keeping the rest 
> because for hairpins,
> the speed -1 have a special meaning instructing freerouter to pass the 
> packets through the dataplane
> instead of speaking routing protocols directly within it's own memory....
> regards,
> cs


> On 2/25/22 10:31, mc36 wrote:
>> hi,
>> still interesting questions....
>> so let's assume for now if we drop the portid thingy completely from the 
>> export-port stanzas....
>> for this to happen, we have to use the sdn--portname mapping from the 
>> dataplanes...
>> then p4lang server loses the possibility to validate the config before the 
>> dataplane connects in....
>> right now i see it making life harder to test the dataplanes indepently.. 
>> right now i have several
>> dataplane vms that use portid0..3 and the tests written for them using the 
>> portid mapping...
>> if we drop the portid stuff, it'll make testing almost impossible because
>> tofino reports X/0, bmv2 reports bmv2-portX, xdp reports xdp-portX,
>> p4pcap reports enoX, and p4dpdk reports 0000:0X.0...
>> so one cannot write a common test case for all the dataplanes....
>> the same issue will appear if you swap the p4pcap and p4dpdk dataplanes
>> on a physical box... (they are normally fully interchangeable!)
>> regarding subinterfaces and the dynamic port range, it's not impossible to 
>> achieve,
>> the only missing part here is the dataplanes need to report the available 
>> subinterface
>> id range they can accommodate without confusing them to physical port 
>> ids...
>> regards,
>> cs
>> 
>> 
>> 
>> On 2/25/22 10:04, Alexander Gall wrote:
>>> Hi
>>> 
>>> On Mon, 21 Feb 2022 17:57:12 +0100, mc36 <> said:
>>> 
>>>> hi,
>>>> this question falls from the trivial:
>>>> right now, bffwd, as name suggests, only forwards messages from text to 
>>>> grpc...
>>>> this is a one-way communication... the only reverse path is counter 
>>>> reporting...
>>>> and this id appears on packets from cpuport's first 16 bits, this is how 
>>>> the
>>>> dataplane signals that which port got the packet that is decided for 
>>>> upper processing...
>>>> (on the cpuport, the reverse path also have this id to signal where the 
>>>> packet need to be sent...)
>>>> and this id is clearly not a single point of assignment because there 
>>>> are virtual
>>>> constructs like subinterface, dialer, virtualppp, pwether, bvi, tunnel 
>>>> and friends
>>>> which are clearly not in the dataplane, moreover we have dynamically 
>>>> created virtual-access
>>>> interfaces from pppoe, l2tp, vpls, evpn and friends... and tofino is not 
>>>> the only one,
>>>> on ebpf and dpdk we use the kernel's/dpdk's assigned handle...
>>> 
>>> Ok, so it's not entirely trivial :)   Maybe we can't avoid that the
>>> user needs to deal with data-plane-dependent identifiers completely,
>>> but I think we should try to avoid it as much as possible.
>>> 
>>>> to have a string at that location, i only see the following idea:
>>>> the dataplanes could report the id to string mapping during startup
>>>> then freerouter can store it and translate internally...
>>> 
>>> Yes, I think we should do that.
>>> 
>>>> but then one still have to deal with the virtual constructs and assign 
>>>> them a usable id...
>>>> (in case of tofino, one that is cannot never ever be a physical port id 
>>>> to steal the traffic...)
>>> 
>>> And that's exactly the kind of problem we should try to avoid
>>> IMHO. Let's look at sub-interfaces, for example:
>>> 
>>> interface sdn1
>>> interface sdn1.99
>>> 
>>> server p4lang p4
>>> export-port sdn1 128 100 0 0 0
>>> export-port sdn1.99 200 0 0 0 0
>>> 
>>> This generates two different messages to the forwarder. The first one
>>> 
>>> "state 128 100 0 0 0"
>>> 
>>> and the second one
>>> 
>>> "portvlan_add 200 128 99"
>>> 
>>> The user has to understand that 128 is the physical port ID of the
>>> fron-plate port where he has plugged in a cable that he wants to be
>>> assoicated with the interface sdn1. He also needs to understand that
>>> he can assign any port ID to sdn1.99 as long as it doesn't overlap
>>> with any physical port ID, which depends on the exact Tofino model he
>>> uses.   For example, the range from 200 upward may be free for a 2-pipe
>>> Tofino, but it isn't for a 4-pipe Tofino. He also needs to understand
>>> that the parameters following the port ID for a sub-interface are
>>> ignored.
>>> 
>>> There is just a lot of potential for confusion and mistakes (what if a
>>> user *does* pick a physical port ID for a sub-interface?). I haven't
>>> thought this through to the end, but it appears to me that we should
>>> be able to let the selection of the port ID for sub-interfaces
>>> entirely up to freerouter, then we wouldn't need an export-port stanza
>>> for them at all.   This is trivial if the data-plane exposes the
>>> port-name-to-ID mapping for all its ports, but it would also be
>>> possible without that by using different number-spaces for these two
>>> things (with corresponding logic in the P4 code to be able to make
>>> that distinction).
>>> 
>>> Similarly, I don't see a fundamental reason why we should not be able
>>> to treat all other "virtual" ports like this.
>>> 
>>> Is there anything here that I'm missing completely?
>>>