Subject: [IPFIX] sectionOffset and sectionObservedOctets

From: Paul Aitken <[email-masked]>
Date: Wed, 01 Aug 2012 13:19:22 +0100

Dear IPFIX experts,

draft-ietf-ipfix-data-link-layer-monitoring-00 defines two new 
Information Elements:

    sectionOffset

       This Information Element specifies the offset of the packet
       section (e.g., dataLinkFrameSection, ipHeaderPacketSection,
       ipPayloadPacketSection, mplsLabelStackSection and
       mplsPayloadPacketSection).  If this Information Element is
       omitted, it defaults to zero.

    sectionObservedOctets

       This Information Element specifies the observed length of the
       packet section (e.g., dataLinkFrameSection, ipHeaderPacketSection,
       ipPayloadPacketSection, mplsLabelStackSection and
       mplsPayloadPacketSection) when padding is used.

       The packet section may be of a fixed size larger than the
       sectionObservedOctets.  In this case, octets in the packet section
       beyond the sectionObservedOctets MUST follow the [RFC5101] rules
       for padding (ie, be composed of zero (0) valued octets).

These are intended for use in conjunction with the new 
"dataLinkFrameSection" Information Element:

       dataLinkFrameSection

       This Information Element carries n octets from the data link frame
       of a selected frame, starting sectionOffset octets into the frame.

       The sectionObservedOctets expresses how much data was observed,
       while the remainder is padding.

Clearly sectionOffset and sectionObservedOctets can apply to all kinds 
of packet section, not just dataLinkFrameSection.

ie, ipHeaderPacketSection, ipPayloadPacketSection, 
mplsLabelStackSection, mplsPayloadPacketSection.

So I'm looking for WG feedback on the best way forward:

1: modify the existing packet section Information Elements Descriptions 
(in a backwards compatible way) to include sectionOffset and 
sectionObservedOctets.

2: deprecate the existing packet section Information Elements and create 
new Information Elements which include sectionOffset and 
sectionObservedOctets.

3: sectionOffset and sectionObservedOctets don’t apply to existing 
packet section Information Elements.

I'll raise this issue while discussing the draft in the WG meeting

Thanks,
P.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 1 Aug 2012 14:17:29 -0700

Hi, Paul, all,

To start the discussion:

Actually, these make so much sense that I had to check the registry to make sure they weren't already there, and was surprised to find they're not. 

As for the sectionObservedOctets, it would be nice if it was made clearer that the observed octets reported is regardless of the offset...

I'd be in favor of option 1 -- I think the changes to ipHeaderPacketSection can be made backward-compatible.

Best regards,

Brian

On Aug 1, 2012, at 5:19 AM, Paul Aitken wrote:

> Dear IPFIX experts,
> 
> draft-ietf-ipfix-data-link-layer-monitoring-00 defines two new Information Elements:
> 
>   sectionOffset
> 
> These are intended for use in conjunction with the new "dataLinkFrameSection" Information Element:
> 
>      dataLinkFrameSection
> 
> Clearly sectionOffset and sectionObservedOctets can apply to all kinds of packet section, not just dataLinkFrameSection.
> 
> ie, ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection, mplsPayloadPacketSection.
> 
> 
> 1: modify the existing packet section Information Elements Descriptions (in a backwards compatible way) to include sectionOffset and sectionObservedOctets.
> 
> 2: deprecate the existing packet section Information Elements and create new Information Elements which include sectionOffset and sectionObservedOctets.
> 
> 3: sectionOffset and sectionObservedOctets don’t apply to existing packet section Information Elements.
> 
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Wed, 01 Aug 2012 22:26:14 +0100

Brian,

> Actually, these make so much sense that I had to check the registry to make sure they weren't already there, and was surprised to find they're not.

:-)

> As for the sectionObservedOctets, it would be nice if it was made clearer that the observed octets reported is regardless of the offset...

Great point, will do.

> I'd be in favor of option 1 -- I think the changes to ipHeaderPacketSection can be made backward-compatible.

Great. I'll propose some example text in one of my slides.

Thanks,
P.