Re: FC Mgmt mib

[Keith McCloghrie <kzm@cisco.com>]

The updated MIB is at:

  ftp://ftp-eng.cisco.com/ftp/kzm/pub/draft-ietf-ips-fcmgmt-mib-02.txt

I will submit it to be a new I-D in a few days if I don't recieve
any comments.  Hopefully, this is now ready for WG Last Call.

Thanks,
Keith.
 
> 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
> > > 
> > 
>