Re: FC Mgmt mib

[Arvind Prabhudev <arvindp@cisco.com>]

Hello Keith,

Very sorry for the delay.

Your suggested 3 changes will meet our needs.

My initial hesitancy to consider us as the 'bridge' port was because we
are not a B-port as in FC-BB-2. We transport FC over GigE. Our port is a
wire extender. So if we expand the description of 'bridge' to explicitly
state that it could be a wire-extender port too, we could forgo the need
for 'tunnel' code point.

We do need the draft FC mib to allow us to report BB-credit and data field
size info. And probably generalising fcmEPortTable is not a bad idea if we
are sure that B-ports and E-ports share a common set of parameters and
nothing will be added to one which will not be applicable to another.

thanks,
Arvind

>>>>>
Date: Wed, 29 May 2002 15:38:47 -0700
From: charissa.willard@sanvalley.com

For FC over IP a port can be either a B_port or an E_port. A B_port
supports Class F frames and thus could at least use the Class F BB_Credit
object that you specified in fcmEPortTable.

The MIB defines the FcUnitFunction type of 'bridge' as "encapsulates FC
frames within another protocol". Doesn't this imply "tunneling"?

Since a B_port is transparent to the Fabric, just providing a table for
B_Ports may provide a solution for other devices/ports that are
transparent to the Fabric and need an object for BB_Credit.
<<<<<


On Fri, 24 May 2002, Keith McCloghrie wrote:

> 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
> >
>