Re: FC Mgmt mib

[Keith McCloghrie <kzm@cisco.com>]

Arvind,

(Sorry for the delay in responding.)  It seems to me that you are
requesting the following three changes:

1. a new code point for FcUnitFunctions

- I think this is fine, except how about calling it 'tunnel' ??

2. Changing the fcmLinkTable from mandatory to optional

- I think this is fine.

3. A new table for 'tunnel' ports

- I'd rather not add a new table unless it's absolutely necessary.
  How about I just broaden the scope of the fcmEPortTable so that
  it applies not only to E_Ports but also to 'tunnel' ports ??

The MIB will also need a new group for devices supporting 'tunnel'
functionality, which will contain just fcmEPortClassFCredit
and fcmEPortClassFDataFieldSize, right ??

If you agree to the above (and nobody else objects), then I'll go
ahead and update the MIB.

The only other pending changes are an alignment of the meanings of bits
of the FcUnitFunctions TC with the latest update to the meanings in the
GS-4 specification (note that FcUnitFunctions's SYNTAX is unchanged),
and some other typos.

In fact, if anyone else has any changes that they would like to propose
before Last Call, can I request that they raise them now.

Thanks,
Keith.

> From: Arvind Prabhudev <arvindp@cisco.com>
> Message-ID: <Pine.GSO.4.44.0204292043470.9884-100000@pacman.cisco.com>
> Date: Mon, 29 Apr 2002 21:06:40 -0700 (PDT)
> To: ips@ece.umn.edu
> Subject: FC Mgmt mib
> 
> (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
>