Subject: RE: [ipfix-eval] Discussion of Candidate Protocols

From: "Harrington, David" <[email-masked]>
Date: Wed, 9 Oct 2002 13:40:52 -0400

Hi,

Comments inline.

> -----Original Message-----
> From: Jeff Meyer [mailto:[email-masked]]
... 
>   My advocacy for IPDR's XML-Schema based approach to data modelling
> is based on the following two shortcomings I see with MIBs as 
> they stand
> today for accounting information like IPFIX:
> 
>    1.  SMI's definition language is based on a subset of 
> ASN.1, although this has stood in good stead these years, I would submit
that the 
> toolset available
>      for processing XML documents is larger and will continue 
> to outpace ASN.1.     In the SMIng draft, the issues on p. 52 state:
>        
> 
>    Learn from ODL, XML, ODBMS -  Look at the ODL proposal from TINAC.
>       Look at the XML schema work from W3C.  Look at the ODBMS work.
> 
In order to properly understand context, it is important to identify WHICH
draft you are referring to, and to understand how that draft fits into the
work of the WG. The draft you reference is one proposal that has been
submitted to the WG for consideration. If I submitted a proposal to the
IPFIX WG and my proposal included a statement "learn from Fortran" that
wouldn't imply that the IPFIX WG agreed that Fortran was the language of
choice. If you look at the RFC produced by the SMING WG, which shows the
requirements that the WG agrees on, you will find no mention of XML.

That is not to say that the members of the WG aren't looking at XML and
other languages for good ideas (as the proceedings show), but they have
explicitly chosen to continue using ASN.1 until it is shown that ASN.1
cannot provide the necessary expressiveness. 

But I'm not arguing for ASN.1, nor am I arguing against XML. I believe the
benefit of having available tools must be considered when selecting a data
definition language.

> 
>  2. SMIv1 and v2 all require each use of an identifier to
>    have an OID bound to it.  In section 3.3 of the SMIng 
>    draft they explicitly state that OIDs should not be used
>    for any bindings other than SNMP or COPS.

An OID is simply a compact mechanism for identifying/addressing a data
element. The OID 1.3.6.1.2.25.3.6.1.1.6 is more compact on the wire than
iso.org.dod.internet.mib-2.host.hrDevice.hrDiskStorageTable.hrDiskStorageEnt
ry.hrDiskStorageAccess.6 (although obviously not as user-friendly).

The SMIng draft you cite is only an individual submission. They do not
explicitly state that OIDs should not be used for any bindings other than
SNMP or COPS. In the limited universe of mappings they discuss, only SNMP
and COPS/PR currently use OIDs. Protocol-specific mappings are done outside
the protocol-independent modeling portions in their proposed design. OIDs
should not be used in the protocol-independent modeling portions of their
design, because OIDs are protocol-specific.

Section 3.3 says:

   The ObjectIdentifier base type represents administratively assigned
   names for use with SNMP and COPS-PR.  This type SHOULD NOT be used in
   protocol independant SMIng modules.  It is meant to be used in SNMP
   and COPS-PR mappings of attributes of type Pointer (Section 3.2).
> 
>  So I believe that the IPDR XML-Schema subset defined today
> will address the needs of IPFIX.  I believe the proposed 
> protocol using this data model will efficiently address the
> transfer and other requirements.
> 
> > I am missing the point about how OIDs hinder fine-grained 
> counters. An 
> > OID is used to name an object such as a counter. I don't think the 
> > naming has a significant effect on how fine-grained the counter is. 
> > Are you asserting that somehow XML-naming better supports 
> fine-grained 
> > counters?
> >
> 
> If you want to define the information produced by IPFIX in a 
> MIB, then I 
> would
> expect it to be in the form of a table definition, since a given 
> category of IPFIX
> "records" will all have the same field information.
> 
> In defining a table in SNMP, you need to address SNMPs 
> requirement about
> being able to lexicographically order each information item.  So the 
> indexing
> scheme would need srcip,dstip,srcport,dstport and time at 
> least to make a
> unique index.
> 
> In the XML model you define the record information (using the 
> complexType
> declaration) and there is no requirement around defining an 
> indexing scheme.
> 
> So I not saying it couldn't be done, just that it introduces 
> information 
> which
> is not (in my opinion) useful for the IPFIX requirements.

That would be one way to design the table, but you could also define the
table with a unique integer index, so exporting a particular fine-grained
counter's value would require using a varbind with an OID to identify the
table, the column and the instance  (FlowTableEntry.FGCounter.4) plus the
type and value of the counter instance. 

The varbind does not require all the src,dst,etc information be encoded in
each counter update, althoguh you might want it reported once so the
receiver knows which flow the index refers to. If the difficulty of
multi-field lexicographical indexing is the answer, then I think the issue
is merely a misunderstanding of indexing requirements.

But let's talk about your proposal. How does using XML's complexType
declaration better support fine-grained counters? Can you compare how to
export the value of the same counter instance I used above using your
proposal? When you define XML record information, aren't you in fact
describing the equivalent of a row of SNMP data? and when you want to
reference a particular field, isn't that roughly the same as identifying a
table column in SNMP? and when you identify a counter instance in XML isn't
that roughly the same as identifying a counter instance in SNMP?

In either case, you need to identify the table, the field, and the instance
in order to identify the element whose value is being exported. So I'm not
seeing the difference.

> 
> > >    But the essential concept of MIBs, which SMIng is also
> > > looking at revising is important.
> >
> > I disagree that SMIng is looking at revising the essential 
> concept of 
> > MIBs. They are looking at revising the SMI to improve 
> ease-of-use and 
> > add object-orientation. The essential concept of MIBs as 
> "data models 
> > that are extensible without protocol changes" remains the same.
> >
> 
> One key revision is the restriction of OID usage to SNMP and COPS. 
>  IPFIX does
> not need OIDs.

I don't know anybody that is arguing for OIDs for IPFIX. I'm merely trying
to understand the points of your initial mail, and to correct
misunderstandings of what SMIng is doing.

As mentioned above, the draft you read is only one proposal, and it has
placed a restriction on its own design. The SMING WG is making no such
revision to mibs, nor are they revising the essential concept of mibs; they
are merely extending the SMI to be more expressive and user-friendly.

dbh

---

From: Jeff Meyer <[email-masked]>
Date: Fri, 11 Oct 2002 05:39:42 -0700

Hi,

Let me try to illustrate by example the difference between the IPDR
technique of XML-Schema based definition of information items and
the current SNMP SMI model.  And the rationale for "not just using
SMI".

The bottom line is that IPDR XML-Schema promotes the use of the
same name when the same information item appears in multiple "tables"
whereas SMI, by nature of SNMP's indexing scheme ends up redeclaring the
same item if it appears in more than one table.

Consider MIB-II, the numeric identifier of the interface card in MIB-II is
used in the interface table, as well as the IP address table, the
route table and the net to media table.

So it is defined four times as:

   ifIndex
   ipAdEntIfIndex
   ipRouteIfIndex
   ipNetToMediaIfIndex

And you end up with descriptions of these secondary redefinitions
with statements like:

  "The index value which uniquely identifies the
   interface to which this entry is applicable.  The
   interface identified by a particular value of this
   index is the same interface as identified by the
   same value of ifIndex."

The interface identifier is also used in many other MIBs, and
all are required to redefine this information element, because
of the way SNMP accesses information.  This makes sense for
SNMP, but since we aren't using SNMP as the mover of information,
it is an annoyance. 

Renaming the same item, makes correlation and information management
more complex than simply calling the same thing by a single name.

In the IPFIX space we will have at least two logical tables,
to which the flow exporter may be adding rows:

  - one for IPv6
  - one for IPv4

In the initial IPDR XML-Schema defined for IPFIX, the names of
the fields which are common to both tables are defined only
once.  E.g.  there is only a definition of "sourcePort" not
an "ipV4sourcePort" and a "ipV6sourcePort".

Regards,

  Jeff Meyer

Harrington, David wrote:

> > ASN.1, although this has stood in good stead these years, I would 
> submit that the
> > toolset available
> In order to properly understand context, it is important to identify 
> WHICH draft you are referring to, and to understand how that draft 
> fits into the work of the WG. The draft you reference is one proposal 
> that has been submitted to the WG for consideration. If I submitted a 
> proposal to the IPFIX WG and my proposal included a statement "learn 
> from Fortran" that wouldn't imply that the IPFIX WG agreed that 
> Fortran was the language of choice. If you look at the RFC produced by 
> the SMING WG, which shows the requirements that the WG agrees on, you 
> will find no mention of XML.
>
> That is not to say that the members of the WG aren't looking at XML 
> and other languages for good ideas (as the proceedings show), but they 
> have explicitly chosen to continue using ASN.1 until it is shown that 
> ASN.1 cannot provide the necessary expressiveness.
>
> But I'm not arguing for ASN.1, nor am I arguing against XML. I believe 
> the benefit of having available tools must be considered when 
> selecting a data definition language.
>
> >
> iso.org.dod.internet.mib-2.host.hrDevice.hrDiskStorageTable.hrDiskStorageEntry.hrDiskStorageAccess.6 
> (although obviously not as user-friendly).
>
> explicitly state that OIDs should not be used for any bindings other 
> than SNMP or COPS. In the limited universe of mappings they discuss, 
> only SNMP and COPS/PR currently use OIDs. Protocol-specific mappings 
> are done outside the protocol-independent modeling portions in their 
> proposed design. OIDs should not be used in the protocol-independent 
> modeling portions of their design, because OIDs are protocol-specific.
>
> Section 3.3 says:
>
> That would be one way to design the table, but you could also define 
> the table with a unique integer index, so exporting a particular 
> fine-grained counter's value would require using a varbind with an OID 
> to identify the table, the column and the instance  
> (FlowTableEntry.FGCounter.4) plus the type and value of the counter 
> instance.
>
> The varbind does not require all the src,dst,etc information be 
> encoded in each counter update, althoguh you might want it reported 
> once so the receiver knows which flow the index refers to. If the 
> difficulty of multi-field lexicographical indexing is the answer, then 
> I think the issue is merely a misunderstanding of indexing requirements.
>
> declaration better support fine-grained counters? Can you compare how 
> to export the value of the same counter instance I used above using 
> your proposal? When you define XML record information, aren't you in 
> fact describing the equivalent of a row of SNMP data? and when you 
> want to reference a particular field, isn't that roughly the same as 
> identifying a table column in SNMP? and when you identify a counter 
> instance in XML isn't that roughly the same as identifying a counter 
> instance in SNMP?
>
> In either case, you need to identify the table, the field, and the 
> instance in order to identify the element whose value is being 
> exported. So I'm not seeing the difference.
>
> >
> I don't know anybody that is arguing for OIDs for IPFIX. I'm merely 
> trying to understand the points of your initial mail, and to correct 
> As mentioned above, the draft you read is only one proposal, and it 
> has placed a restriction on its own design. The SMING WG is making no 
> such revision to mibs, nor are they revising the essential concept of 
> mibs; they are merely extending the SMI to be more expressive and 
> user-friendly.
>
> dbh
>

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/