Re: I-D ACTION:draft-ietf-ips-scsi-mib-04.txt

[Mark Bakke <mbakke@cisco.com>]

"KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote:
> 
> > 1) Read/Write counters
> >
> > Counter32 (counting MB transferred) wrap at about 1000 hours
> > on 10Gbps links.
> > Can we the MIB use a Counter64 instead?
> 
> We want to accommodate SNMPv1 agents (which can't implement Counter64), so
> we can add an optional counter64.  Thanks for the reminder!

Since we are back to an optional counter64, should it be in
bytes instead of MB?

> 
> > 2) Virtualization
> >
> > An attempt was made to list all LU's which are part of a LUN.
> > In my opinion, the ultimate mechanism to represent
> > hierarchical volumes is via a volume manager MIB. For the
> > time being it will be useful to associate a {start LBA, end
> > LBA} vector with each LU to allow for most simplistic
> > virtualization mapping.
> 
> I'm not sure what you mean.  The MIB lists all the LU's that are contained
> within a Target device, and then a table of all the LUN mappings for those
> LU's.  I don't really think of "LU's being part of a LUN" - the MIB doesn't
> try to accommodate virtualization, we agree that virtualization is better
> represented via another MIB.  This MIB is an attempt to represent the simple
> (average?) SCSI device.  Section 3.4 states that this MIB is not meant to
> address virtual devices, merely the "visible SCSI attributes" (what a host
> will see).

I agree with Marj.  Note that even target mapping (e.g. map a FC target
to an iSCSI target) or LUN mapping are outside the scope of a SCSI MIB.

> Regards,
> Marjorie Krueger
> Networked Storage Architecture
> Networked Storage Solutions
> Hewlett-Packard

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054