<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Thanks Andrew, <br>
    </p>
    <p>inline comments. Captured this as an agenda for our next work
      group call discussion <a
        href="https://github.com/openbmc/openbmc/wiki/OpenBMC-PMCI-WG">https://github.com/openbmc/openbmc/wiki/OpenBMC-PMCI-WG</a></p>
    <p>Regards,</p>
    <p>Richard<br>
    </p>
    <div class="moz-cite-prefix">On 6/5/2020 7:51 AM, Andrew Jeffery
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:8f92dcfd-c6b3-4625-a158-17e03a940687@www.fastmail.com">
      <pre class="moz-quote-pre" wrap="">Hi Richard,

I've trimmed out all the bits we agree on.

On Thu, 4 Jun 2020, at 19:35, Thomaiyar, Richard Marian wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">On 6/3/2020 8:10 AM, Andrew Jeffery wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Hi Richard,
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
On Tue, 2 Jun 2020, at 02:43, Thomaiyar, Richard Marian wrote:
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">All,
</pre>
          </blockquote>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
 MCTP specification doesn’t restrict communication without EID 
assignment. i.e. MCTP devices can communicate with each other, even 
without EID’s (Spec limits bridging MCTP commands only – Sec 8.2 
Special Endpoints in DSP0236). The scenario can happen in following 
cases
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Before we jump ahead, as far as I can see this is only a problem in 
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">libmctp for 
local bus communications involving at least one device requiring 
dynamic 
address allocation.  [Richard]: Intentionally didn't talk about static 
EID - networks as this problems won't be there. If you meant to say 
that libmctp is not designed to handle non-static network case, let me 
know. I brought this topic to cover it in libmctp.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Let's not get ahead of ourselves :)

I _intend_ libmctp to handle non-static network cases just fine. We need to do 
some work though, mainly implementing support for routing.
</pre>
    </blockquote>
    [Richard]: we are on the same page then.<br>
    <blockquote type="cite"
      cite="mid:8f92dcfd-c6b3-4625-a158-17e03a940687@www.fastmail.com">
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">1. MCTP Bus owner available only in Main power and not on stand-by. In 
</pre>
          </blockquote>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">this case, devices are required to communicate using NULL EID, till 
main power is applied.
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Again, only for communication involving a device that requires dynamic EID 
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">allocation.  [Richard]: Yes.
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">2. Till the EID’s are assigned by the Bus Owner, devices can 
</pre>
          </blockquote>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">communicate with NULL EID(Source & Dest). 
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Agreed, except for in the static case there's no need to do this 
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">because we 
know the EIDs.  [Richard]: Now for dynamic only EID case, how this will 
happen is the question here.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
It is handled by the provisional EID proposal.
</pre>
    </blockquote>
    <br>
    <blockquote type="cite"
      cite="mid:8f92dcfd-c6b3-4625-a158-17e03a940687@www.fastmail.com">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">Even Bus owner, when it sends 
</pre>
          </blockquote>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">out SetEID or query GetEID, it must send with NULL EID (for Dest – Sec 
12.3 Set Endpoint ID, 8.17.6 – Reclaiming EID’s from hot-plug devices 
in DSP0236)
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Here's an extract from 8.17.6:
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">Attempting to access each endpoint can be accomplished by issuing the Get 
</pre>
          </blockquote>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">Endpoint ID command to the physical address of each device and comparing the 
returned result to the existing entry in the routing table. If there is no 
response to the command, or if there is a mismatch with the existing routing 
information, the entry should be cleared and the corresponding EID or EID 
range should be returned to the "pool" for re-assignment.
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Note that it says "can be accomplished" and "or if there is a mismatch". So
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">"must send with NULL EID" is too strong here - if we know an EID we can
use it.

This is where breaking down the process of sending a command into the 
three 
phases becomes useful: The application uses the EID to specify the 
device it 
wants to talk to in the Command Generation phase, while the Message 
Routing 
phase performs the mapping of EID to physical device address. If 
necessary, the 
EID in the message can be substituted with 0 in the Message Routing 
phase.
 [Richard]: Not really. This section 8.17.6 talks about reclaiming. i.e 
Basically, in this case, don't send GetEID command based on EID to 
physical address mapping, instead send GetEID to the needed physical 
address with Dest EID Null, and cross verify it's EID.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
That's an option but not a necessity as far as I read it. And if it's not a 
necessity, we can still use our current understanding of the EID to perform the 
EID to physical address mapping in the routing phase. If we're unsure of the 
device's assigned EID, we can always mark what know as was its previous address 
as provisional before sending the GetEID command. The provisional mark will 
cause the routing layer to replace the message's destination EID with 0 after 
resolving the physical address.</pre>
    </blockquote>
    <p>[Richard]: If you are saying to use different flag / field, apart
      from mctp_eid_t for it, then we are on the same page here, and can
      talk about how that must be done. The main agreement we need to
      make here is whether same mctp_eid_t must be used or not. <br>
    </p>
    <blockquote type="cite"
      cite="mid:8f92dcfd-c6b3-4625-a158-17e03a940687@www.fastmail.com">
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">This needs to be 
performed, to figure out whether EID of the device changed due to card 
replacement or reset etc. If we don't send with Dest EID as 0, then 
device may drop the packet, if there is mismatch with it's EID.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
This is why in the provisional EID proposal we substitute the supplied EID with 
0 in the routing layer.
</pre>
    </blockquote>
    <br>
    <blockquote type="cite"
      cite="mid:8f92dcfd-c6b3-4625-a158-17e03a940687@www.fastmail.com">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">Similarly, as EndPoint device, need physical address of the bus owner, 
</pre>
          </blockquote>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">so that when SetEID is received from secondary/backup bus owner, we 
will know what to do?
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">This isn't dependent on the physical address - the specification says 
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">that if a 
device receives a subsequent SetEID to the first it must respond 
indicating the 
EID it has already been allocated. This has no tie to the physical 
address of 
the device sending the SetEID command. Further, we know both the EID 
and the 
physical address of the device that propagated the SetEID from the 
received 
packet, so the local routing table should simply be updated with the 
information 
captured.  [Richard]: Not really, if the same bus owner sends SetEID, 
we need to accept that, but if the request comes from different one, 
then we can't accept that one. Assume bus owner crashed / reset and 
coming back up, it may start with different EID assignment, based on 
number of devices at that point and devices needs to identify the bus 
owner with UUID or physical address to uuid mapped.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
This isn't what the spec says as I read it. Can you point to the sections that 
made you come to this conclusion about the specific device that's acting as bus 
owner?</pre>
    </blockquote>
    <p>[Richard]: yes, in section 12.3 of the DSP0236. Capturing the
      excerpt below.</p>
    <p><span class="fontstyle0">The Set Endpoint ID command is also used
        to provide the Physical Address and EID of the Bus Owner to<br>
        an Endpoint. An Endpoint that needs to communicate with the Bus
        Owner may capture the physical<br>
        address and EID that was used to deliver the Set Endpoint ID
        message.</span> <br style=" font-style: normal; font-variant:
        normal; font-weight: normal; letter-spacing: normal;
        line-height: normal; orphans: 2; text-align: -webkit-auto;
        text-indent: 0px; text-transform: none; white-space: normal;
        widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto;
        -webkit-text-stroke-width: 0px; ">
    </p>
    <blockquote type="cite"
      cite="mid:8f92dcfd-c6b3-4625-a158-17e03a940687@www.fastmail.com">
      <pre class="moz-quote-pre" wrap="">

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Going the other direction, upon receiving a message with EID 0, 
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">libmctp core 
will populate the routing table with a provisional EID, replace the 
source EID 
0 in the MCTP header with the provisional EID, then propagate the 
message up 
the stack.
 [Richard]: This means that Provisional EID is carved out of the EID 
Pool. With bridging - (Multiple networks), this can't be handled. We 
will end up with real EID for the same provisional EID, and hence we 
won't know when we send back data to which device we need to deliver.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
This case can be detected by the routing layer, however I need to think through 
the impacts some more. I don't think it precludes the provisional EID approach. 
To get a bit more specific, provisional EIDs are only used above the routing 
layer where an inbound message contains a 0 source EID, and for the outbound 
case where the destination EID should be 0. If an inbound message arrives with 
a non-zero source EID then we know it is a legitimately assigned EID and we can 
de-conflict the routing table.

I just need to make sure this works for each scenario.</pre>
    </blockquote>
    [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. <br>
    <blockquote type="cite"
      cite="mid:8f92dcfd-c6b3-4625-a158-17e03a940687@www.fastmail.com">
      <pre class="moz-quote-pre" wrap="">

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap=""> This requires to pass physical addressing information to the MCTP 
</pre>
          </blockquote>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">Control command layer or to the upper layer from libmctp.
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">I think I've demonstrated above that this might not be not necessary. Please 
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">poke holes in what I've proposed!
[Richard]: 

_*For control command handling:*_ As stated, we need a mechanism other 
than EID (Note: I meant we may need to introduce one more field, to 
make the difference - if you are saying that as provisional (i.e. not 
the same mcpt_eid_t then that's what we are saying as binding private). 

_*Now for other Message types*_ say PLDM etc. Other than EID, PLDM 
doesn't use any of the MCTP Transport header, but we still need to 
expose the transport header in the upper API, as other OEM types may 
use it or rely on MCTP transport header for informaiton.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Can you please provide concrete examples of this being necessary?</pre>
    </blockquote>
    [Richard]: For control commands, already stated the scenarios and
    excerpt from specification, let me know if you are looking for any
    other specific concrete examples. <br>
    <blockquote type="cite"
      cite="mid:8f92dcfd-c6b3-4625-a158-17e03a940687@www.fastmail.com">
      <pre class="moz-quote-pre" wrap="">

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Now, having 
said there are cases where devices behind mux 
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
For muxes it should be possible to determine the necessary mux state between 
the routing and the binding. The mux configuration should be encoded as part of 
the physical address. This may mean we need binding "decorators" to handle the 
case.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">or requires special 
handling, now we need to see how to handle the same in terms of API 
(which is second part of this discussion).
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Can you please be more specific here? What do you have in mind?

Cheers,

Andrew
</pre>
    </blockquote>
  </body>
</html>