FC Mgmt mib

[Arvind Prabhudev <arvindp@cisco.com>]

(This is regarding draft-ietf-ips-fcmgmt-mib-01)

Hello,

I am writing on behalf of a group at Cisco which is developing an optical
box. One of our linecards is aimed at providing Fibre Channel aggregation
while simultaneously extending fibrechannel connectivity to much larger
distances. Fibre channel frames are encapsulated into ethernet frames,
tagged with a flow identifier and these frames are packet multiplexed
over the trunk interface (which operates at the ITU grid frequency).

-------+         +---------+           +---------+         +-------
Regular|   FC    |Our box 1|   GigE    |Our box 2|   FC    |Regular
FC port+---------+ X     Tx+-----------+Ty     Y +---------+FC Port
   A   |         |         |           |         |         |  B
-------+         +---------+           +---------+         +-------

In figure above, FC streams from multiple X & Y ports are ethernet
encapsulated and multiplexed over Tx & Ty ports respectively.

We were considering supporting the draft-ietf-ips-fcmgmt-mib-01 for
providing fibre channel management of our box. We had a few requests in
this regard.

As described above, we do not terminate fibrechannel at the FC-2 level.
We handle only upto FC-1 level. We remain transparent to the fibre channel
connectivity. We feel that there is no appropriate value in the
FcUnitFunctions type that would describe the nature of our box. We
would like to propose a new code point 'transport'.

Secondly, we wanted a means to report the BB Credit on our (X & Y) ports.
There are FcBbCredit objects in fcmFxPortTable & fcmEPortTable through
which we can report this value. But, we are neither an F nor E port. So
would it possible to consider our ports as a new category of 'transport'
ports which do SAN extension and have a separate table for it which has BB
credit object?

The last issue is regarding the fcmLinkTable. It is currently mandatory.
We would prefer that the table was made optional. Ofcourse, the table in
its current form does not preclude not populating it, if nothing was
learnt. Any information about the ID of the source port & node that we are
connected to, which we might discover by potentially snooping the frames,
we would like to report via the PTOPO-MIB (rfc2922).

I hope our inputs could be incorporated into the proposed FC mgmt MIB draft.
Please let us know what you think.

best regards,
Arvind