RE: FC Mgmt mib

[Steve Moffett <smoffett@cisco.com>]

Charissa,
         Thanks for helping us move forward. Please keep us advise if there 
are any other issues with this mib we need to review and resolve on Eports 
and credits. Again,thanks for your response.

Regards,

Steve

At 02:42 PM 6/19/2002 -0700, charissa.willard@sanvalley.com wrote:
>Keith,
>
>That solution sounds good to me.
>
>Thanks,
>Charissa
>
> > -----Original Message-----
> > From: Keith McCloghrie [mailto:kzm@cisco.com]
> > Sent: Wednesday, June 19, 2002 2:39 PM
> > To: charissa.willard@sanvalley.com
> > Cc: kzm@cisco.com; arvindp@cisco.com; ips@ece.cmu.edu;
> > smoffett@cisco.com; sriramnj@cisco.com; nramesh@cisco.com;
> > gklee@cisco.com
> > Subject: Re: FC Mgmt mib
> >
> >
> > Charissa,
> >
> > Sorry for the delay, but I have spoken with Arvind and he agrees
> > that "encapsulates FC frames within another protocol" is a wide
> > enough scope to cover his device, and thus, you're right that no
> > change is needed for the FcUnitFunction TC.
> >
> > Further, the two objects within the current fcmEPortTable (i.e.,
> > fcmEPortClassFCredit and fcmEPortClassFDataFieldSize) can both be
> > applied to Arvind's device.  Now, you comment that
> > fcmEPortClassFCredit
> > applies to B_Ports, and I'm confident that fcmEPortClassFDataFieldSize
> > does also.  Thus, the fcmEPortTable actually applies to E_Ports and
> > B_Ports.  So, rather than have separate tables for B_Ports
> > and E_Ports,
> > with the same objects defined in both (i.e., a duplication), I'd like
> > to use the existing table for both types.  All that is required is to
> > change the name to, say, the fcmInterSwitchPortTable (which is roughly
> > what you suggested in your previous message), and update its
> > definition
> > to say it applies to E_Ports, B_Ports and any other type of port which
> > interfaces to an inter-switch link.
> >
> > If you agree, I'll go ahead and update the MIB.
> >
> > Keith.
> >
> >
> > > Keith,
> > >
> > > >
> > > > 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 ??
> > >
> > > 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.
> > >
> > > Thanks,
> > > Charissa
> > >
> >