OFA_OpenFabrics_Manager Webex meeting invitation: UFM -- additional weekly meeting

[Hefty, Sean]

Some comments on the slides:

Slide 5:
I would say that the provider maps the higher-level request to fabric specific operations.  That is, I would not focus on optimizing performance.

Slide 6 is trying to capture fabric-independent operations that mgmt applications need to perform.  The goal is to abstract the operation away from fabric specific software.  It might help to show that there are common operations, which could be abstracted and are the target of the proposal, as well as fabric-specific operations, which would be out of scope.

For example, inventory works well as a common abstraction.  General link state (up/down) can be common, but detailed link state (initializing?) might be fabric specific.  Events fall into a similar category.  Addressing becomes hard, because there's no common address format.  I'm not clear what is meant by connections -- topology?

A lot of the value of the proposal is in assuming that there's enough commonality between fabrics that a significant number of use cases can be met by an abstraction, versus using fabric specific tools.

It's clear that this could help gen-z and slingshot, or other new fabrics.  I don't see a technical reason why IB couldn't probably map underneath it.  But I also don't see a strong motivation for an IB vendor to assist.

Related to this, is there an Ethernet model that could be used as the abstraction?