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

[Shingo KASHIMA <[e-mail]>]

Hi Dharani,

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


On Tue, 16 Feb 2010 10:52:45 -0800
"Dharani Vilwanathan (dharani)" <[e-mail]> san wrote:

> 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.

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?


>  
> - 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.

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.


>  
> - 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.
> <<<<---------- 

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
> document more precise.

Thank you.


>  
> -  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 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
> the types.

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
> just unsigned8? 

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
> datalink header length? 

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
> unsigned16?

In next draft, we would like to revise to 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."

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.
>  
> Thanks
> dharani
>  


Regards,
Shingo

--- 
Shingo KASHIMA  <[e-mail]>
NTT Information Sharing Platform Lab.