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

[Shingo KASHIMA <[e-mail]>]

Hi Paul,

Thanks for your reply.

Please find my answer in-line.

On Mon, 08 Nov 2010 22:12:34 +0000
Paul Aitken <[e-mail]> wrote:

> Kashima-san,
> 
> 
> > I will refer to "Export of Structured Data in IPFIX
> > (draft-ietf-ipfix-structured-data-03.txt)".
> > Is that right ?
> 
> Yes, thanks.
> 
> 
> >>> 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?
> >
> > 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
> >           ~~~~~~~~~
> 
> This is an excellent question for the working group to consider :-)
> You may wish to add such a slide to your presentation?

Yes! I will add this point to my presentation.



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

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


> 
> P.
> 

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