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

From: Nevil Brownlee <[email-masked]>
Date: Mon, 08 Mar 2010 15:12:49 +1300

Hi all:

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

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?

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?

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!

Cheers, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: Paul Aitken <[email-masked]>
Date: Mon, 08 Mar 2010 22:42:56 +0000

Nevil,

>    extension.  Is there support for such a generalisation?

Yes, very much so. We have customer need for this. It would be far 
preferable for us to standardise through IPFIX than to go down a 
proprietary route.

Note that there is precedent for this, since the IPFIX info model 
already contains some non-IP fields - eg, MPLS, MAC address, VLAN.

>    Does it provide enough detail?

Actually, the dataLinkFrameSize and dataLinkFrameSection definitions are 
simply verbatim copies from the old draft-ietf-psamp-info-09.

>    Should there be more than just three?

I would propose an extensible IANA sub-registry.

Cheers,
P.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Shingo KASHIMA <[email-masked]>
Date: Wed, 10 Mar 2010 01:20:11 +0900

Hi Nevil and all,

Thank you for your comments.

Please see our comments in-line.

> especially as used in providing layer-2 VPN services (IEEE 802.1ad

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.

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

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

>     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 <[email-masked]>
NTT Information Sharing Platform Lab.

---

From: "Dharani Vilwanathan (dharani)" <[email-masked]>
Date: Tue, 9 Mar 2010 14:17:18 -0800

Hi Nevil/Paul,

I too would like to convey that there is a need for obtaining layer 2
info in IPFIX records along with rest of the IP fields of a flow.

We would like to make sure this will be of interest to IPFIX working
group and community, because Yaonan, Laxmi and I are working on various
ethernet types and see if we can address missing fields. We would like
to bring this to IPFIX forum once we have the details. 

Thanks
dharani

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Aitken (paitken)
Sent: Monday, March 08, 2010 2:43 PM
To: Nevil Brownlee
Cc: IPFIX Working Group
Subject: Re: [IPFIX] Comments
ondraft-kashima-ipfix-data-link-layer-monitoring-01.txt

Nevil,

> This draft introuces three new IPFIX Information Elements (IEs) that 
> would enable IPFIX to be used for monitoring (parts of) in 

> especially as used in providing layer-2 VPN services (IEEE 802.1ad and

> 802.1ah).

Cheers,
P.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Nevil Brownlee <[email-masked]>
Date: Wed, 10 Mar 2010 11:24:14 +1300

Hi Dharani:

I agree that being able to report on Layer 2 is important and useful -
we just need to work out the best strategy to document/standardise it.

Cheers, Nevil

---

From: "Dharani Vilwanathan (dharani)" <[email-masked]>
Date: Tue, 9 Mar 2010 14:39:28 -0800

Hi Nevil,

Thanks for the quick response and thanks for sharing your thoughts.

Regards
dharani 

-----Original Message-----
From: Nevil Brownlee [mailto:[email-masked]] 
Sent: Tuesday, March 09, 2010 2:24 PM
To: Dharani Vilwanathan (dharani)
Cc: Paul Aitken (paitken); IPFIX Working Group
Subject: Re: [IPFIX] Comments

Hi Dharani:

Cheers, Nevil

Dharani Vilwanathan (dharani) wrote:
> group and community, because Yaonan, Laxmi and I are working on 
> various ethernet types and see if we can address missing fields. We 
> would like to bring this to IPFIX forum once we have the details.
> 
> Thanks
> dharani
> 

>> and