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

[Paul Aitken <[e-mail]>]

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?


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

P.