headers
Nevil Brownlee | 1 Feb 2012 10:39
Picon
Picon
Favicon

[IPFIX] Flow Selection Techniques draft


Hi all:

The Flow Selection Techniques discussed in Quebec (IETF 81) last year
(-07) generated considerable discussion.  Versions -08 and -09 include
many changes, which I believe greatly improve the draft.

However, since Quebec there's been very little discussion of this
draft.  We're at the point where I'd like to get it submitted; please
would some of you have a look at the changes, and send some comments
to the list [easiest way to see them is to use the diff2 view of
version -08].

Also, there was some earlier discussion of IPR issues for this draft.
Nick Duffield pointed out that "PSAMP addressed this issue by making all
the selection methods optional."  The way I read the draft, it has a
long list of selection algorithms, and it's up to an implementor to
choose which to implement, however I didn't spot any definite statement
that all of them are optional.  I'd like to hear comments about this
too - do we feel that it's OK as it is, or should there be a more
definite statement on this?

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 Zeala
_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nevil Brownlee | 1 Feb 2012 11:03
Picon
Picon
Favicon

[IPFIX] Start of new WGLC for Flow Selection Techniques draft


Hi again all:

I should have said this in my last post - In Taipei we said "this
needs a new WGLC,"  this is the notice that it starts today, and
will finish on Wednesday, 15 February.

I need at least two emails supporting it, so do please have a look,
even if you only say "looks OK now!"

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

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
Permalink | Reply | 1 comment |
headers
Paul Aitken | 1 Feb 2012 16:33
Picon
Favicon
Gravatar

[IPFIX] exporting VLANs in IPFIX

Dear all,

IANA's IPFIX registry contains some nearly-identical fields for 
exporting VLAN IDs:

58  vlanId  unsigned16  identifier  current

         The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag
         Control Information field that was attached to the IP packet.
         See IEEE.802-1Q.2003.
         [RFC5102]

243  dot1qVlanId  unsigned16  identifier  current

         The value of the 12-bit VLAN Identifier portion of the Tag
         Control Information field of an Ethernet frame as described in
         section 3.5.5 of [IEEE.802-3.2005].  The structure and semantics
         within the Tag Control Information field are defined in IEEE
         P802.1Q.  In case of a QinQ frame, it represents the outer tag's
         VLAN identifier and in case of an IEEE 802.1ad frame it
         represents the Service VLAN identifier in the S-TAG Tag Control
         Information (TCI) field as described in [IEEE.802-1ad.2005].
         Units = octets
         [IEEE.802-3.2005]
         [ipfix-iana <at> cisco.com]

59  postVlanId  unsigned16  identifier  current

         The definition of this Information Element is identical
         to the definition of Information Element
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Trammell | 1 Feb 2012 16:35
Picon
Picon

Re: [IPFIX] exporting VLANs in IPFIX

Hi, Paul,

This seems like a reasonable thing to do.

Cheers,

Brian

On Feb 1, 2012, at 4:33 PM, Paul Aitken wrote:

> Dear all,
> 
> IANA's IPFIX registry contains some nearly-identical fields for exporting VLAN IDs:
> 
> 
> 58  vlanId  unsigned16  identifier  current
> 
>        The IEEE 802.1Q VLAN identifier (VID) extracted from the Tag
>        Control Information field that was attached to the IP packet.
>        See IEEE.802-1Q.2003.
>        [RFC5102]
> 
> 
> 243  dot1qVlanId  unsigned16  identifier  current
> 
>        The value of the 12-bit VLAN Identifier portion of the Tag
>        Control Information field of an Ethernet frame as described in
>        section 3.5.5 of [IEEE.802-3.2005].  The structure and semantics
>        within the Tag Control Information field are defined in IEEE
>        P802.1Q.  In case of a QinQ frame, it represents the outer tag's
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Aitken | 1 Feb 2012 16:37
Picon
Favicon
Gravatar

[IPFIX] Fwd: New Version Notification for draft-aitken-ipfix-unobserved-fields-00.txt

FYI:

-------- Original Message -------- Subject: Date: From: To: CC:
New Version Notification for draft-aitken-ipfix-unobserved-fields-00.txt
Mon, 30 Jan 2012 08:48:26 -0800
internet-drafts <at> ietf.org
paitken <at> cisco.com
paitken <at> cisco.com


A new version of I-D, draft-aitken-ipfix-unobserved-fields-00.txt has been successfully submitted by Paul Aitken and posted to the IETF repository. Filename: draft-aitken-ipfix-unobserved-fields Revision: 00 Title: Reporting Unobserved Fields in IPFIX Creation date: 2012-01-30 WG ID: Individual Submission Number of pages: 13 Abstract: The IPFIX protocol is designed to export information about observations, and lacks a method for reporting that observations are unavailable. This document discusses several methods for reporting when fields are unavailable, reviews the advantages and disadvantage of each, and recommends methods which should be used. The IETF Secretariat 
_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
Permalink | Reply | 0 comments |
headers
Brian Trammell | 3 Feb 2012 18:44
Picon
Picon

Re: [IPFIX] RFC 5101bis - UDP checksum

Hi, Paul,

This seems reasonable, and I see no problem at all with adding it, but I'm not really sure if there's a win... A
couple of comments on that point.

First, practically, I'm not aware of a UDP stack that doesn't do checksums by default (though I have limited
experience with embedded systems and none at all on routers), so I would assume an implementor would have
to go out of their way to switch UDP checksum calculation off. 

Second, given all the various (unavoidable) issues with respect to IPFIX over UDP (mainly related to
template management) which would seem to have occurrence probabilities on the order of magnitude of that
of a transmission error that would be caught by the UDP checksum (at least over MAC layers with which I have
experience), it's not clear why we'd want to say, hey, you can use UDP if you can't afford anything else, but
you can't make it a (very) little bit faster and a (very) little bit less reliable by dropping checksums.

Cheers,

Brian

On Jan 30, 2012, at 9:17 PM, Paul Aitken wrote:

> Dear all,
> 
> Per RFC 768 and RFC 1122, UDP checksums are not mandatory.
> 
> Since the IPv4 checksum is only calculated over the header (not the data) and there is no IPv6 checksum,
5101bis should include a line recommending that UDP checksums are enabled when exporting over UDP.
> 
> P.
> _______________________________________________
> IPFIX mailing list
> IPFIX <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
Permalink | Reply | 1 comment |
headers
internet-drafts | 3 Feb 2012 19:01
Picon
Favicon

[IPFIX] I-D Action: draft-ietf-ipfix-a9n-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the IP Flow Information Export Working Group of the IETF.

	Title           : Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol
	Author(s)       : Brian Trammell
                          Arno Wagner
                          Benoit Claise
	Filename        : draft-ietf-ipfix-a9n-01.txt
	Pages           : 46
	Date            : 2012-02-03

   This document describes the export of aggregated Flow information
   using IPFIX.  An Aggregated Flow is essentially an IPFIX Flow
   representing packets from multiple Original Flows sharing some set of
   common properties.  The document describes Aggregated Flow export
   within the framework of IPFIX Mediators and defines an interoperable,
   implementation-independent method for Aggregated Flow export.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-a9n-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-a9n-01.txt

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
Permalink | Reply | 0 comments |
headers
Brian Trammell | 3 Feb 2012 19:02
Picon
Picon

[IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-a9n-01.txt

Greetings, all,

This is a minor revision of the aggregation draft to point to 5101bis instead of 5101; there are no
substantive content changes. 

I believe this draft is ready for WGLC, as discussed in Taipei.

Thanks, and best regards,

Brian

Begin forwarded message:

> From: internet-drafts <at> ietf.org
> Date: February 3, 2012 7:01:28 PM GMT+01:00
> To: trammell <at> tik.ee.ethz.ch
> Cc: bclaise <at> cisco.com, arno <at> wagner.name, trammell <at> tik.ee.ethz.ch
> Subject: New Version Notification for draft-ietf-ipfix-a9n-01.txt
> 
> A new version of I-D, draft-ietf-ipfix-a9n-01.txt has been successfully submitted by Brian Trammell
and posted to the IETF repository.
> 
> Filename:	 draft-ietf-ipfix-a9n
> Revision:	 01
> Title:		 Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol
> Creation date:	 2012-02-04
> WG ID:		 ipfix
> Number of pages: 46
> 
> Abstract:
>   This document describes the export of aggregated Flow information
>   using IPFIX.  An Aggregated Flow is essentially an IPFIX Flow
>   representing packets from multiple Original Flows sharing some set of
>   common properties.  The document describes Aggregated Flow export
>   within the framework of IPFIX Mediators and defines an interoperable,
>   implementation-independent method for Aggregated Flow export.
> 
> 
> 
> 
> The IETF Secretariat

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
Permalink | Reply | 0 comments |
headers
Paul Aitken | 3 Feb 2012 22:04
Picon
Favicon
Gravatar

Re: [IPFIX] RFC 5101bis - UDP checksum

Brian,

The reason for mentioning it is that someone contacted us last week with 
a proposal not to checksum UDP.

So it'd be great to cover this in an RFC in case it comes up again.

P.

On 03/02/12 17:44, Brian Trammell wrote:
> Hi, Paul,
>
> This seems reasonable, and I see no problem at all with adding it, but I'm not really sure if there's a win...
A couple of comments on that point.
>
> First, practically, I'm not aware of a UDP stack that doesn't do checksums by default (though I have
limited experience with embedded systems and none at all on routers), so I would assume an implementor
would have to go out of their way to switch UDP checksum calculation off.
>
> Second, given all the various (unavoidable) issues with respect to IPFIX over UDP (mainly related to
template management) which would seem to have occurrence probabilities on the order of magnitude of that
of a transmission error that would be caught by the UDP checksum (at least over MAC layers with which I have
experience), it's not clear why we'd want to say, hey, you can use UDP if you can't afford anything else, but
you can't make it a (very) little bit faster and a (very) little bit less reliable by dropping checksums.
>
> Cheers,
>
> Brian
>
>
> On Jan 30, 2012, at 9:17 PM, Paul Aitken wrote:
>
>> Dear all,
>>
>> Per RFC 768 and RFC 1122, UDP checksums are not mandatory.
>>
>> Since the IPv4 checksum is only calculated over the header (not the data) and there is no IPv6 checksum,
5101bis should include a line recommending that UDP checksums are enabled when exporting over UDP.
>>
>> P.
>> _______________________________________________
>> IPFIX mailing list
>> IPFIX <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
Permalink | Reply | 0 comments |
headers
Nevil Brownlee | 5 Feb 2012 15:08
Picon
Picon
Favicon

[IPFIX] WG Last Call for Aggregation and IE-Doctors drafts


Hi all:

As reported in the minutes of our Taipei meeting, the WG Last Call
for
   draft-ietf-ipfix-a9n-01
   draft-ietf-ipfix-ie-doctors-00
starts today, and will end on Monday, 20 February.

As always, we *need* your feedback - please read these and post your
comments to the list, even if you only say "this looks good to me!"

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

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
Permalink | Reply | 2 comments |

Gmane