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

[Shingo KASHIMA <[e-mail]>]

Hi Nevil and all,

Thank you for your comments.

Please see our comments in-line.

> This draft introuces three new IPFIX Information Elements (IEs)
> that would enable IPFIX to be used for monitoring (parts of) in
> data-link-layer parts of packet headers.  It concentrates on Ethernet,
> especially as used in providing layer-2 VPN services (IEEE 802.1ad
> and 802.1ah).

Yes. 

Our interest is not only layer-2 VPN service (Wide-Area Ethernet)
but also cloud service (Data Center Network).
In the newest draft, we added IEEE802.1Qbh as the example of
the extended data link technologies.
http://tools.ietf.org/html/draft-kashima-ipfix-data-link-layer-monitoring-02
"2.2.  Data Center Network Summary"

What we want to say is that this draft can be also applied to
the other data link layer protocols than IEEE 802.1ad/IEEE802.1ah.


> 
> Now that I've read it and thought about it, I have three comments:
> 
> 1. The IPFIX/PSAMP architecture standardises the collection of
>     *IP-related* data, this proposal would extend it to cover data from
>     other parts of a packet's headers.  That would be a significant
>     extension.  Is there support for such a generalisation?

We think the data link layer protocols such as ethernet will be
extended and introduced to various networks, then traffic monitoring
in data link layer becomes more significant.
Though IPFIX/PSAMP is a standard for *IP-related* protocol,
IPFIX/PSAMP architecture is effective and attractive for our large-scale
ethernet networks, e.g. mediation and variouse packet selection.


> 
> 2. It's presented as a simple, minimal extension to IPFIX/PSAMP,
>     simply adding three new IEs PSAMP IEs, i.e with numbers above 338.
>     Does it provide enough detail?  Should there be more than just three?
>     For example, how about having separate IEs for S-VID, C-VID, B-VID
>     and I=SID?  What other IEs are needed for PPP and WiMAX?

I think separated IEs is not bad approach.

In IEEE802.1ah, we need not only {B-VID and I-SID}
but also {B-PCP and I-PCP}*1 at least .
*1{B-PCP and I-PCP}:
  CoS (Class of Service) parameters in {B-TAG and I-TAG}.

In IEEE802.1ad, almost of all header informations have been already
standardized.
- S-VID (=dot1qVlanId)
- S-PCP (=dot1qPriority)
- C-VID (=dot1qCustomerVlanId)
- C-PCP (=dot1qCustomerPriority)


> 
> 3. The description of proposed IE dataLinkFrameType seems rather
>     minimal - eventually we'll want to add more data link types.  For
>     example, the ifType-MIB (www.iana.org/assignments/ianaiftype-mib)
>     has a much longer list.  Maybe we have to choose here between a long
>     list of types, each with its own set of fields, or a short list of
>     very general fields?  A short, simple list seems very appealing!
> 

In the newest draft, we have revised as follows.
"      This Information Element specifies the type of the selected data
       link frame and SHOULD be checked before analyzing higher layer
       protocols.
       The data link layer is defined in [ISO_IEC.7498-1_1994].
       The value matches the value of managed object 'IANAifType' as
       defined in [RFC2863]."

But we have one doubt.
IANAifType means the type of interface, does not mean the type of frame
in a narrow sense.
In particular, IANAifType=ethernetCsmacd(6) means ethernet interfaces,
does not mean ethernet frames.

On the other hand, another registration which differs from IANAifType
takes long time until the standardization finishes.


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