Subject: Re: [IPFIX] draft-kashima-ipfix-data-link-layer-monitoring

From: Paul Aitken <[email-masked]>
Date: Mon, 08 Nov 2010 16:02:35 +0000

Kashima-san,

I reviewed the draft. Please find some feedback inline.

> 1. Introduction
>
>    While these renovations provide flexibility, scalability, and

I think you mean "innovations".

> 3. Future Traffic Measurement
>
>    The device (Exporter) filters and/or samples Ethernet frames using
>    PSAMP Selector, extracts the header of the frame, and exports the
>    header information encoded by IPFIX protocol to the Collector.

Actually the exporter doesn't do this; the metering process does. A 
combination of MP and exporter is required.

>    Furthermore, the device (Exporter) filters and samples traffic for
>    each VPN using a Composite Selector of PSAMP [RFC5475].  This makes
>    it possible to change the granularity of the traffic monitoring for
>    each VPN.

Same comment again. Also, consider adding some details of the PSAMP process.

> 4.2. dataLinkFrameSection
>
>
>    Description:
>
>       This Information Element carries n octets from the data link frame
>       of a selected frame, starting dataLinkFrameOffset octets into the
>       frame.
>
>       When the dataLinkFrameSectionObservedOctets field corresponding to
>       this Information Element does not exist, this Information Element
>       MUST have a variable length and MUST NOT be padded.  In this case,
>       the size of the exported section may be constrained due to
>       limitations in the IPFIX protocol.

I would relax the "MUST have a variable length" to a SHOULD, since fixed 
length sections may be exported.

>       When the dataLinkFrameSectionObservedOctets field corresponding to
>       this Information Element exists, this Information Element MAY have
>       a fixed length and MAY be padded, or MAY have a variable length.
>
>       The dataLinkFrameSectionObservedOctets expresses how much data was
>       observed, while the remainder is padding.

These two paragraphs follow the one above. I would write them in exactly 
the opposite order: 3, 2, 1.

>       Further Information Elements, i.e., dataLinkFrameType and
>       dataLinkFrameSize are needed to specify the data link type and the
>       size of the data link frame of this Information Element.  A set of
>       these Information Elements MAY be contained in a structured data
>       type, as expressed in another IPFIX WG draft.

You should specify the draft and include a reference.

> 4.4. dataLinkFrameOffset
>
>
>    Description:
>
>       This Information Element specifies the offset of the observed
>       dataLinkFrameSection within the data link frame.  If this
>       Information Element is omitted, it defaults to zero.

I thought the intention was to create a generic "offset" field which 
could be used with any packet section?

> 4.5. dataLinkFrameSectionObservedOctets
>
>
>    Description:
>
>       This Information Element specifies the observed length of the
>       dataLinkFrameSection.
>
>       This Information Element is especially needed for NetFlow version
>       9 [RFC3954] because NetFlow does not support a variable-length
>       Information Element.

I think it would be better to say "This Information Element specifies 
the observed length of the dataLinkFrameSection when padding is used", 
and remove the second paragraph.

> 6. IANA Considerations
>
>
>    This document requests that the Information Element IDs are allocated
>    as shown in section 4.
>
>    In addition, the dataLinkFrameType Information Element requires the
>    creation of new IANA registries.

I think only one new registry is needed for this. However, Nevil is 
leading some discussion whether the values should be defined in the IE 
description, rather than in separate registries.

> Appendix C. Template Formats Example
>
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |        Set ID (0x0002)        |             Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      Template ID (0x0103)     |      Field Count (0x0006)     |

The field count is 8.

>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   ingressInterface (0x000A)   |     Field Length (0x0004)     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   egressInterface (0x000E)    |     Field Length (0x0004)     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |observationTimeSeconds (0x0142)|     Field Length (0x0008)     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   dataLinkFrameSize (0x0138)  |     Field Length (0x0002)     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | dataLinkFrameSection (0x013B) |     Field Length (0xFFFF)     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   dataLinkFrameType (0x015B)  |     Field Length (0x0002)     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  dataLinkFrameOffset (0x015C) |     Field Length (0x0002)     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | dataLinkFrameSection (0x015D) |     Field Length (0x0002)     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Call it "dataLinkFrameSectionOO" (OO = Observed Octets). Else 0x015D 
looks like the earlier 0x013B.

>
>                    Figure C-1: Template Fortmat Example

Typo, "Format".

Cheers,
P.

---

From: Shingo KASHIMA <[email-masked]>
Date: Tue, 09 Nov 2010 02:11:10 +0800

Hi Paul,

Thanks for your review.

Please find tree answer for your comments inline.

The answer for the other comments are all
"yes, I will revise as your comments".

> You should specify the draft and include a reference.

I will refer to "Export of Structured Data in IPFIX
(draft-ietf-ipfix-structured-data-03.txt)".
Is that right ?

> could be used with any packet section?

I also think a generic offset is better.
Then IE name should be changed to "sectionOffset".

But we have one problem.
We need to revise existing packet section IE's description.
Is this possible ?
- ipHeaderPacketSection
 carries a series of octets from the start of the IP header
                                 ~~~~~~~~~~~~
- ipPayloadPacketSection
 carries a series of octets from the start of the IP payload
                                 ~~~~~~~~~~~~
- mplsLabelStackSection
 carries the first n octets from the MPLS label stack
         ~~~~~~~~~
- mplsPayloadPacketSection
 carries the first n octets from the MPLS payload
         ~~~~~~~~~

> description, rather than in separate registries.

I see.
To be defined in the IE description seems to be simple and good.

Best Regards,
Shingo.

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

---

From: Paul Aitken <[email-masked]>
Date: Mon, 08 Nov 2010 22:12:34 +0000

Kashima-san,

> (draft-ietf-ipfix-structured-data-03.txt)".

Yes, thanks.

>   carries a series of octets from the start of the IP header

This is an excellent question for the working group to consider :-)
You may wish to add such a slide to your presentation?

> To be defined in the IE description seems to be simple and good.

Consider what happens when a new value is added: the description is changed.

Moving the values into a registry allows the description to remain 
constant - which is good, because the description is basically the 
field's specification, which should not change.

The values in the registry represent the implementation, which is the 
changeable part.

P.

---

From: Shingo KASHIMA <[email-masked]>
Date: Tue, 09 Nov 2010 11:08:52 +0800

Hi Paul,

Thanks for your reply.

Please find my answer in-line.

On Mon, 08 Nov 2010 22:12:34 +0000

> You may wish to add such a slide to your presentation?

Yes! I will add this point to my presentation.

> The values in the registry represent the implementation, which is the 

I see. Your comment is also reasonable.

Then let's see existing IEs.
- flowEndReason includes a value list in its description.
- biflowDirection includes a value list in its description.
Are there IEs which do not include a value list in their description ?

Which is IPFIX IEs registries policy, to be defined in the IE
description or in separate registries ?
We should follow our policy.
Or, dataLinkFrameType is a different kind of IE from existing IEs
such as flowEndReason and biflowDirection ?

Best Regards,
Shingo

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Nov 2010 01:02:53 -0500

> such as flowEndReason and biflowDirection ?

I think he means more like mplsTopLabelType, which has an actual registry for its enumeration values. (See http://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type)

-hadriel

---

From: Shingo KASHIMA <[email-masked]>
Date: Tue, 09 Nov 2010 14:31:15 +0800

Hi Hadriel and all,

Thanks for your information.

I undarstood IPFIX IEs have two kins of enumeration values.

- To be defined as independent type
 e.g. mplsTopLabelType
- To be defined in own description
 e.g. flowEndReason, biflowDirection

On Tue, 9 Nov 2010 01:02:53 -0500

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 9 Nov 2010 03:05:50 -0500

Sure, but a dataLinkFrameType wouldn't be a static list known at the time you define the IE for it.  For example, new frame types are still being added for libpcap (and libpcap has been around for decades).  Methinks you'll want a type-list you can easily expand in the future.

-hadriel

---

From: Shingo KASHIMA <[email-masked]>
Date: Tue, 09 Nov 2010 23:04:28 +0800

Hi Hadriel and all,

Thanks for your comments.
A dataLinkFrameType seems to be just like mplsTopLabelType.

Let's discuss with at tommorow WG meeting.

Best Regards,
Shingo.

On Tue, 9 Nov 2010 03:05:50 -0500