Re: MCTP Null EID - Physical addressing support - Binding private in API

[Andrew Jeffery]

On Fri, 5 Jun 2020, at 12:53, Thomaiyar, Richard Marian wrote:
> Thanks Andrew, 
> 
> inline comments. Captured this as an agenda for our next work group 
> call discussion https://github.com/openbmc/openbmc/wiki/OpenBMC-PMCI-WG

I noted in another thread that I've pushed patches implementing bridging and 
routing along with the provisional EID concept to gerrit:

https://gerrit.openbmc-project.xyz/q/topic:%2522routing%2522+(status:open+OR+status:merged)+project:openbmc/libmctp

In the end the implementation uses a "provisional" flag in both the mctp_eid_t 
type and the route table as there was one race that couldn't be safely 
eliminated without it.

> 
> [Richard]: We 
> can't know which EID can be used as provisional. It may be real EID in 
> a bridged network. Please educate me, if the same can be achieved 
> without having a conflict. 

Because the conflict shouldn't matter - it can be detected by the binding 
receiving the message by looking up the source EID in the route table and 
checking if the result is a provisional EID.

However, the complication occurs when trying to remove the provisional EID from 
the route table in order to deliver the message received from the endpoint that 
has been formally allocated the same EID. If there's an outstanding command 
whose response hasn't yet been sent which will need the provisional EID entry 
from the table in order for the message to be routed, we can't deliver the 
message received from the endpoint which is non-provisionally assigned the EID. 
It's hard to unwind that properly and still account for issues like deadlocks 
or application crashes which will lead to a denial of service.

So the result is we have a route table with two separate address spaces, one 
for formally assigned EIDs and another for provisional EIDs. This partition is 
managed by a flag on the route table entries in the current implementation.

Andrew