Subject: [IPFIX] Regarding draft-kashima-ipfix-data-link-layer-monitoring-01.txt

From: "Dharani Vilwanathan (dharani)" <[email-masked]>
Date: Tue, 16 Feb 2010 10:52:45 -0800

Hi Kashima,
 
This is regarding the document:
Data Link Layer Monitoring with IPFIX/PSAMP
http://tools.ietf.org/id/draft-kashima-ipfix-data-link-layer-monitoring-
01.txt
 
After some email exchanges with Ganesh Murthy and Paul Aitken, we
(Yaonan Liang, Laxmi Mukund and self) had a discussion on this document.
We would like to understand the document better and so we would like to
present our comments to you here:
 
- There are many ethernet types mentioned in the document. But they
don't seem to be exhaustive. Some key things like 802.3, WiMax,etc seem
to be missing. Probably we can attempt to cover everything or just
provide a summary of various types with an explicit note.
 
- The document seems to start straight with a couple of ethernet types.
It would be nice if we can start the document more smoothly from an
overall perspective.
 
- In section 2, we have:
 
"This was because, at that time, the
   PSAMP Working Group selected not standardization based on vague
   requirements but standardization that was quickly completed."
 
The sentence can probably be rephrased.
 
- We can probably add "as well" to the end of next paragraph so that it
reads like this:
 
The following Information Elements are necessary for enabling the
   above-mentioned method, which is not limited to Ethernet because the
   method can be applied to other data link protocols as well.
<<<<---------- 
 
-  It looks like there might be some refinements needed to make the
document more precise.
 
-  Is this document an extension of RFC5477 (Info model for Packet
Sampling Exports) and should  it actually be under PSAMP? And because
PSAMP working group seems to be no longer active, we are trying to fit
in this document in IPFIX? Because, if this document is really intended
for IPFIX, we should see how it co-exists with several fields defined by
Paul Aitken, Ganesh Murthy and Marco (please see
http://tools.ietf.org/id/draft-aitken-ipfix-new-infos-03.txt
<http://tools.ietf.org/id/draft-aitken-ipfix-new-infos-03.txt>  content
of which got added to IANA database). But if the document is intended
for PSAMP, then we need to make sure it fits properly in IPFIX.
 
- Section 5.1: Only 3 types are defined. We may have to define rest of
the types.
 
- Section 5.1: Any reason why the type is unsigned32? Why can't it be
just unsigned8? 
        Also, is it correct to say that dataLinkFrameSize is really the
datalink header length? 
 
- Section 5.2: Can the type be as low as needed? Like unsigned8 or
unsigned16?
 
- Section 5.3: The following paragraph is not clear. It may need
rephrasing:
 
"The data for this field MUST NOT be padded.  If insufficient
      octets are available for the length specified in the Template,
      then a new Template MUST be used."
 
Please pass your comments.
 
Thanks
dharani

---

From: Shingo KASHIMA <[email-masked]>
Date: Thu, 18 Feb 2010 14:07:00 +0900

Hi Dharani,

Thank you for your comments.
Please see in-line.

On Tue, 16 Feb 2010 10:52:45 -0800

> It would be nice if we can start the document more smoothly from an

I would like to clarify this document goal.
This document tries to propose simple information elements independent
from ethernet type, also data link layer type. Section data including
ethernet header (or other link layer header) and upper layer headers
can be applied to all of ethernet type (or link layer protocol)
We pick up examples, such as Q-in-Q and MAC-in-MAC, to have readers
understand the issues we would face in near future when monitoring
backbone bridge networks. We might come up with other examples. But, it
does not mean to enumerate the list of ethernet type to be exhaustive. 
Even so, should we complete the list for ethernet types?

> The sentence can probably be rephrased.

In this sentence we just explain why the information
elements ("dataLinkFrameSection" and "dataLinkFrameSize")
have been deleted from <draft-ietf-psamp-info-10.txt>,
but this sentence might be removed in our final document.

>    method can be applied to other data link protocols as well.

Thank you.
In next draft, we would like to revise as your comment.

> -  It looks like there might be some refinements needed to make the

Thank you.

> for PSAMP, then we need to make sure it fits properly in IPFIX.

Section data information element related to link layer had already been
discussed in PSAMP WG, thus we put in PSAMP. But, I do not adhere the
extension of PSAMP info. 

> - Section 5.1: Only 3 types are defined. We may have to define rest of

Sorry for the confusion, this is just example.
In next draft, we would like to use IANAifType 
(http://www.iana.org/assignments/ianaiftype-mib).

> - Section 5.1: Any reason why the type is unsigned32? Why can't it be

In next draft, we would like to use signed32.
because MIB SYNTAX of IANAifType is "INTEGER".

>         Also, is it correct to say that dataLinkFrameSize is really the

No, dataLinkFrameSize is not heder length but frame length.
In case of ethernet, dataLinkFrameSize means a length of
from destination MAC address to FCS (end of a frame).

> - Section 5.2: Can the type be as low as needed? Like unsigned8 or

In next draft, we would like to revise to unsigned16.

>       then a new Template MUST be used."

It's my mistake.
In next draft, we would like to revise as follows.

"The data for this field MUST NOT be padded."

> Please pass your comments.

Regards,
Shingo

--- 
Shingo KASHIMA  <[email-masked]>
NTT Information Sharing Platform Lab.