From majordomo@mil.doit.wisc.edu Mon May 2 06:14:04 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23457 for ; Mon, 2 May 2005 06:14:04 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DSXdc-0004bG-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 May 2005 04:54:52 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DSXdb-0004al-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 02 May 2005 04:54:51 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 11:54:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54EFC.F8C6F2CF" Subject: RE: [ipfix-protocol] new version of the IPFIX protocol draft: draft-ietf-ipfix-protocol-12.txt Date: Mon, 2 May 2005 11:54:45 +0200 Message-ID: Thread-Topic: [ipfix-protocol] new version of the IPFIX protocol draft: draft-ietf-ipfix-protocol-12.txt Thread-Index: AcVEcwbSEFFuJkr1TN6YzgWDMVe5uQKhXzdQ From: "STEPHAN Emile RD-CORE-LAN" To: "Benoit Claise" Cc: X-OriginalArrivalTime: 02 May 2005 09:54:46.0688 (UTC) FILETIME=[F90AB200:01C54EFC] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------_=_NextPart_001_01C54EFC.F8C6F2CF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Benoit, =20 What is the max length of a fixed length field ? Is it 65534 ? Does that = make sense as the max length of an IPFIX msg is 65535 ? =20 At large, in the future IPFIX will need to define new kind of field = types. The current definition of 'Field Length' must be prepared for = that. I propose to reserve the MSB of 'Field Length' for future usage. =20 Regards Emile =20 ________________________________ De : majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] De la = part de Benoit Claise Envoy=E9 : mardi 19 avril 2005 01:43 =C0 : ipfix-protocol@net.doit.wisc.edu; me Cc : Paul Aitken Objet : [ipfix-protocol] new version of the IPFIX protocol draft: = draft-ietf-ipfix-protocol-12.txt =20 Dear all,=20 I just posted a new version of the IPFIX protocol draft, with the = feedback from Paul Aitken's thorough review. Here are the list of changes: - Some cross references were wrong - Flow Record definition exactly similar to the one in [IPFIX-ARCH] - Template definition exactly similar to the one in [IPFIX-ARCH] - As deduced from section 9, the source ID definition now contains: the = source ID MUST NOT be 0 - The Field Length is completed with: The value 65535 is reserved for = variable length Information Element (see section 7). The Field Length = MAY NOT 0.=20 - one mistake corrected in figure O - correction: In most cases the length of the Information Element will = be less than 256 255 octets. - correction: The IPFIX Message Header 16-bit Length field limits the = length of a IPFIX Message to 65536 65535 octets including the header. - section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops ;) = BTW, the TCP sections now speaks of TCP connection as opposed to TCP = association - added the 2 sentences When the TCP connection restarts, the Exporting Process MUST resend=20 all the Template Records. =20 =20 When an TCP connection is closed, the Collecting Process MUST=20 discard all templates received over that connection and stop=20 decoding IPFIX Messages that use those templates.=20 - A couple of mistakes in the examples. =20 I advice to review the changes at = http://ietf.levkowetz.com/drafts/ipfix/, once the draft is published.=20 =20 Regards, Benoit. =20 =20 =20 =20 - A lot of editorial corrections and improvements ------_=_NextPart_001_01C54EFC.F8C6F2CF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Benoit,

 

What is the max length of a = fixed length field ? Is it 65534 ? Does that make sense as the max length of an IPFIX msg = is 65535 ?

 

At large, in the future IPFIX = will need to define new kind of field types. The current definition of =A0'Field = Length' must be prepared for that. I propose to reserve the MSB of 'Field Length' for = future usage.

 

Regards

Emile

 

De : majordomo listserver = [mailto:majordomo@mil.doit.wisc.edu] De la part de Benoit Claise
Envoy=E9 : mardi 19 = avril 2005 01:43
=C0 : ipfix-protocol@net.doit.wisc.edu; me
Cc : Paul Aitken
Objet : = [ipfix-protocol] new version of the IPFIX protocol draft: = draft-ietf-ipfix-protocol-12.txt

 

Dear all,

I just posted a new version of the IPFIX protocol draft, with the = feedback from Paul Aitken's thorough review.

Here are the list of changes:
- Some cross references were wrong
- Flow Record definition exactly similar to the one in [IPFIX-ARCH]
- Template definition exactly similar to the one in [IPFIX-ARCH]
- As deduced from section 9, the source ID definition now contains: the = source ID MUST NOT be 0
- The Field Length is completed with: = The value 65535 is reserved for variable length Information Element (see = section 7). The Field Length MAY NOT 0.
- one mistake corrected in figure O
- correction: In most cases the length of the Information Element will = be less than 256 255 octets.
- correction: The IPFIX Message Header 16-bit Length field limits the = length of a IPFIX Message to 65536 65535 octets including the header.
- section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops ;) = BTW, the TCP sections now speaks of TCP connection as opposed to TCP = association
- added the 2 sentences

=A0=A0 When the TCP connection restarts, the =
Exporting Process MUST resend 
=A0=A0=A0all the Template Records.=A0 =

=A0=A0=A0=A0=A0
=A0=A0=A0When an TCP connection is closed, =
the Collecting Process MUST 
=A0=A0=A0discard all templates received over =
that connection and stop 
=A0=A0=A0decoding IPFIX Messages that use =
those templates. 
- A couple of mistakes in the =
examples.
 
I advice to review the changes at http://ietf.levkowetz.co=
m/drafts/ipfix/, once the draft is published. =

 
Regards, Benoit.

 

=A0=A0=A0=A0=A0

 

 

- A lot of editorial corrections and = improvements

------_=_NextPart_001_01C54EFC.F8C6F2CF-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon May 2 06:28:34 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26186 for ; Mon, 2 May 2005 06:28:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DSXtg-0005PB-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 May 2005 05:11:28 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DSXte-0005P2-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 02 May 2005 05:11:27 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 May 2005 12:11:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [ipfix-protocol] Generalisation of the Reduced Size Encoding Date: Mon, 2 May 2005 12:11:22 +0200 Message-ID: Thread-Topic: Generalisation of the Reduced Size Encoding Thread-Index: AcU7YxFPPSnfL895So61w2OvVnmw9wTmev3g From: "STEPHAN Emile RD-CORE-LAN" To: "Stewart Bryant" , "Benoit Claise" Cc: X-OriginalArrivalTime: 02 May 2005 10:11:23.0569 (UTC) FILETIME=[4B3AAA10:01C54EFF] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Dear Bryant, Benoit Protocol-v12 does not generalise the size encoding reduction to string = and array. This should be added because such kinds of fields are defined = with a length longer that those used (e.g. wlanSsid). Regards Emile > -----Message d'origine----- > De=A0: Stewart Bryant [mailto:stbryant@cisco.com] > Envoy=E9=A0: jeudi 7 avril 2005 13:15 > =C0=A0: STEPHAN Emile RD-CORE-LAN > Cc=A0: Benoit Claise; ipfix-protocol@net.doit.wisc.edu > Objet=A0: Re: [ipfix-protocol] draft-ietf-ipfix-protocol-11.txt: 6.2 = Reduced > Size Encoding of Integer Types >=20 >=20 >=20 > STEPHAN Emile RD-CORE-LAN wrote: > > Dear Benoit, > > > > This section says that an exporter MAY use shorter IE length than in = the > > info model but does not clearly say that in this case it is = mandatory to > > declare these length in the template. >=20 > That is already stated in section 3.2 >=20 > "Field Length > The length of the corresponding encoded Information Element, > in octets. Refer to [IPFIX-INFO]. The field length may be > smaller than the definition in [IPFIX-INFO] if reduced size > encoding is used (see section 7.2)." >=20 >=20 >=20 > > > > I propose to replace the beginning of this section with: > > > > "Information Elements containing integer types in the information > > model MAY be encoded using fewer octets than those implied by their > > type in the information model definition [IPFIX-INFO], in this case = the > > exporter MUST indicate these lengths in the template ... > > >=20 > I don't think that your added text "in this case the > exporter MUST indicate these lengths in the template" >=20 > is needed since you have to send exactly the number of octets > that you declared in the template. >=20 > BTW - the reduction would also apply to a fixed length string > object, say a name, that might be defined as an IE of max length > X (to tell the collector DB the max size it needs to store) > but which the exporter knew woud only ever take Y We should therefore increase the scope to include any > primative type where the collector can figure out the semantics > of a reduced size export. >=20 > Regards >=20 > Stewart >=20 > > > > Regards > > Emile > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in = message > body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon May 2 11:43:32 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27111 for ; Mon, 2 May 2005 11:43:32 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DScxn-0000u2-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 May 2005 10:36:03 -0500 Received: from frontend-2.servers.ua.pt ([193.136.173.3] helo=cgpmail.ua.pt) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DScxm-0000tx-00 for ipfix@net.doit.wisc.edu; Mon, 02 May 2005 10:36:02 -0500 Received: from [193.136.92.53] (HELO av.it.pt) by frontend2.cgpmail.ua.pt (CommuniGate Pro SMTP 4.2.10) with ESMTP id 7788142 for ipfix@net.doit.wisc.edu; Mon, 02 May 2005 16:36:01 +0100 Received: from [193.136.93.189] (account gestip@av.it.pt) by av.it.pt (CommuniGate Pro WebUser 4.2.5) with HTTP id 2637653 for ipfix@net.doit.wisc.edu; Mon, 02 May 2005 16:35:59 +0100 From: "Rui Silva" Subject: [ipfix] field length of inPacketTotalCount To: ipfix@net.doit.wisc.edu X-Mailer: CommuniGate Pro WebUser Interface v.4.2.5 Date: Mon, 02 May 2005 16:35:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit hi everybody in template set ,field length of inPacketTotalCount and others using abstract data type semantics:unsigned64 are right??unsigned64 are 8 octets and field length of this type fields are 4 octets! regards rui silva -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue May 3 06:14:02 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26737 for ; Tue, 3 May 2005 06:14:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DSu7C-0005LD-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 May 2005 04:54:54 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DSu7A-0005L6-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 03 May 2005 04:54:53 -0500 Received: from [193.175.133.240] (luz@kaitos [193.175.133.240]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j439soT11442 for ; Tue, 3 May 2005 11:54:51 +0200 (MEST) Message-ID: <42774A6A.7040106@fokus.fraunhofer.de> Date: Tue, 03 May 2005 11:54:50 +0200 From: Lutz Mark User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Encoding of IPFIX Data Types Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > 6.1.5 string and octetarray > > The data type string represents a finite length string of valid > characters of the Unicode character encoding set. It is expected > that strings will be encoded in UTF-8 format. The string is sent as > an array of octets. The length of the string and the octetArray is > encoded as described in Section 7 (Variable Length Information > Element). The length is followed by that many octets as encoded in > the length. The section implies that you have to use variable length IEs to export strings and octetarrays (or does the text mean that you have to send the length twice? It's not clear to me). I suggest to change the text to allow the export of strings and octetarrays in an IE of fixed length. For example: The data type string represents a finite length string of valid characters of the Unicode character encoding set. It is expected that strings will be encoded in UTF-8 format. The string is sent as an array of octets. The length of the information element specifies the length of the octedarray. Regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue May 3 06:39:51 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28848 for ; Tue, 3 May 2005 06:39:51 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DSuXc-0006t7-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 May 2005 05:22:12 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DSuXb-0006t2-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 03 May 2005 05:22:11 -0500 Received: from [193.175.133.240] (luz@kaitos [193.175.133.240]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j43AMAT16522 for ; Tue, 3 May 2005 12:22:10 +0200 (MEST) Message-ID: <427750D2.4030805@fokus.fraunhofer.de> Date: Tue, 03 May 2005 12:22:10 +0200 From: Lutz Mark User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] 9. The Collecting Process's Side Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > The Collecting Process MUST verify that only one Source ID value is > used inside each stream. If the Collecting Process detects that more > than one Source ID has been received within a stream, it MUST > discard the IPFIX Message, reset the SCTP association, and SHOULD > log the error. this does not map with the behaviour of using IPFIX over TCP. With TCP it is possible to export data of multiple observation domains using only one connection. Is there a motivation for this restriction that also applies to TCP? What about removing this restriction for SCTP? Regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Mou_6120@kanematsuusa.com Tue May 3 07:44:25 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07063 for ; Tue, 3 May 2005 07:44:24 -0400 (EDT) Received: from 201009198021.user.veloxzone.com.br ([201.9.198.21] helo=kanematsuusa.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DSvi0-0001ZX-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 May 2005 06:37:02 -0500 From: "Aleta Moulton" To: "Tivadar Daigle" Subject: =?iso-8859-1?Q?Vl=E0GRA_VAL=EDUM_ClAL=ECS?= Date: Tue, 3 May 2005 07:36:48 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C54EF7.42777060" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C54EF7.42777060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, For a long moment there was silence. Then the great gentleman is dwarfed into insignificance by the fame that followed. It was That's it! cried one of Levasseur's officers. And Cahusac adde I can't find him, bleated Nuttall. He was indignant at his And without giving the Baron time to set the angry question that can to ease his sufferings, or I swear to you that I'll forsake a sensation. Spain and England were variously and unpleasantly vinegary smile. that served him for a bed. deliberately between those two, at point-blank range, and so turn his twisted lips red as the blood for which they thirsted - glare half-mutinous before him, save Hagthorpe, who shrugged and smiled Also, whilst he may have desired to go to France or Holland, he h Have a nice day. ------=_NextPart_000_0013_01C54EF7.42777060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello, Do you want to spend Iess on = your p=EDlIs?
 
Vi=E0GRA V=E0LIUMM C=ECALISS and = many other.
 
Save over 7 0 % with PharmacyyByMAlL STORE.
 
Have a nice day.
 
 
 
 
For a long moment there was silence. Then the great
gentleman = is dwarfed into insignificance by the fame that followed. It
was = That's it! cried one of Levasseur's officers. And Cahusac
adde = I can't find him, bleated Nuttall. He was indignant at
his = And without giving the Baron time to set the angry question
that = can to ease his sufferings, or I swear to you that I'll forsake
a = sensation. Spain and England were variously and
unpleasantly = vinegary
smile. = that served him for a
bed. = deliberately between those two, at point-blank range, and so
turn = his twisted lips red as the blood for which they thirsted -
glare = half-mutinous before him, save Hagthorpe, who shrugged and
smiled = Also, whilst he may have desired to go to France or Holland, he
h =
------=_NextPart_000_0013_01C54EF7.42777060-- From majordomo@mil.doit.wisc.edu Tue May 3 08:27:02 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11354 for ; Tue, 3 May 2005 08:27:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DSwQ4-0002lV-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 May 2005 07:22:32 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DSwQ3-0002lQ-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 03 May 2005 07:22:31 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 03 May 2005 08:22:31 -0400 Received: from cisco.com (dhcp-rea-gp250-64-103-65-209.cisco.com [64.103.65.209]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j43CMRRQ017255; Tue, 3 May 2005 08:22:28 -0400 (EDT) Message-ID: <42776CFE.9050404@cisco.com> Date: Tue, 03 May 2005 13:22:22 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lutz Mark CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Encoding of IPFIX Data Types References: <42774A6A.7040106@fokus.fraunhofer.de> In-Reply-To: <42774A6A.7040106@fokus.fraunhofer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Lutz Mark wrote: > > > 6.1.5 string and octetarray > > > > The data type string represents a finite length string of valid > > characters of the Unicode character encoding set. It is expected > > that strings will be encoded in UTF-8 format. The string is sent as > > an array of octets. The length of the string and the octetArray is > > encoded as described in Section 7 (Variable Length Information > > Element). The length is followed by that many octets as encoded in > > the length. > > The section implies that you have to use variable length IEs to > export strings and octetarrays (or does the text mean that you > have to send the length twice? It's not clear to me). There are three possible ways to send a string: 1) Fixed length 2) Short variable length 3) Long variable length. In case 1, you put the length in the template and the string is always that length, and if your string is shorter you have to pad. In case 2 and 3 you use a special length value in the template which says that the length is encoded at the start of the string. > I suggest to change the text to allow the export of strings and > octetarrays in an IE of fixed length. > > For example: > > The data type string represents a finite length string of valid > characters of the Unicode character encoding set. It is expected > that strings will be encoded in UTF-8 format. The string is sent as > an array of octets. The length of the information element > specifies the length of the octedarray. This is only true for fixed length strings. Regards Stewart > > Regards, > Lutz > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue May 3 09:21:25 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15616 for ; Tue, 3 May 2005 09:21:24 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DSxAq-0004NP-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 May 2005 08:10:52 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DSxAp-0004NC-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 03 May 2005 08:10:51 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 15:10:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix-protocol] Encoding of IPFIX Data Types Date: Tue, 3 May 2005 15:10:26 +0200 Message-ID: Thread-Topic: [ipfix-protocol] Encoding of IPFIX Data Types Thread-Index: AcVP203qmaE1oEQ1RXSGpC4qooC5OgABPU4Q From: "STEPHAN Emile RD-CORE-LAN" To: "Stewart Bryant" , "Lutz Mark" Cc: X-OriginalArrivalTime: 03 May 2005 13:10:32.0707 (UTC) FILETIME=[7CA0B530:01C54FE1] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Dear Stewart, Lutz I suggest that section 6.2 defines the reduced size encoding not only = for integer but for string and array too. That will clarify the link to = section 6.2 in section "3.2 Field Specifier".=20 Regards Emile > -----Message d'origine----- > De=A0: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] De la = part > de Stewart Bryant > Envoy=E9=A0: mardi 3 mai 2005 14:22 > =C0=A0: Lutz Mark > Cc=A0: ipfix-protocol@net.doit.wisc.edu > Objet=A0: Re: [ipfix-protocol] Encoding of IPFIX Data Types >=20 >=20 >=20 > Lutz Mark wrote: >=20 > > > > > 6.1.5 string and octetarray > > > > > > The data type string represents a finite length string of valid > > > characters of the Unicode character encoding set. It is = expected > > > that strings will be encoded in UTF-8 format. The string is = sent as > > > an array of octets. The length of the string and the = octetArray is > > > encoded as described in Section 7 (Variable Length Information > > > Element). The length is followed by that many octets as = encoded in > > > the length. > > > > The section implies that you have to use variable length IEs to > > export strings and octetarrays (or does the text mean that you > > have to send the length twice? It's not clear to me). >=20 >=20 > There are three possible ways to send a string: >=20 > 1) Fixed length > 2) Short variable length > 3) Long variable length. >=20 > In case 1, you put the length in the template and the string > is always that length, and if your string is shorter you have > to pad. >=20 > In case 2 and 3 you use a special length value in the template > which says that the length is encoded at the start of the string. >=20 > > I suggest to change the text to allow the export of strings and > > octetarrays in an IE of fixed length. > > > > For example: > > > > The data type string represents a finite length string of valid > > characters of the Unicode character encoding set. It is expected > > that strings will be encoded in UTF-8 format. The string is sent = as > > an array of octets. The length of the information element > > specifies the length of the octedarray. >=20 > This is only true for fixed length strings. >=20 > Regards >=20 > Stewart >=20 > > > > Regards, > > Lutz > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say "help" in = message > > body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > > "unsubscribe ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > >=20 > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in = message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue May 3 11:15:05 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28982 for ; Tue, 3 May 2005 11:15:05 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DSyzo-0007g2-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 May 2005 10:07:36 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DSyzn-0007fx-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 03 May 2005 10:07:35 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j43F7XK05600; Tue, 3 May 2005 17:07:33 +0200 (CEST) Received: from [10.61.64.235] (ams-clip-vpn-dhcp235.cisco.com [10.61.64.235]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j43F7VK24302; Tue, 3 May 2005 17:07:31 +0200 (CEST) Message-ID: <427793B2.3020007@cisco.com> Date: Tue, 03 May 2005 17:07:30 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lutz Mark CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] 9. The Collecting Process's Side References: <427750D2.4030805@fokus.fraunhofer.de> In-Reply-To: <427750D2.4030805@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Lutz, > > > The Collecting Process MUST verify that only one Source ID value is > > used inside each stream. If the Collecting Process detects that more > > than one Source ID has been received within a stream, it MUST > > discard the IPFIX Message, reset the SCTP association, and SHOULD > > log the error. > > this does not map with the behaviour of using IPFIX over TCP. > With TCP it is possible to export data of multiple observation > domains using only one connection. > > Is there a motivation for this restriction that > also applies to TCP? > > What about removing this restriction for SCTP? As far as I recall, this was specify initially to get some fairness across multiple source ID sending template records from a single exporting process (a distributed platform). However, after thinking about it with Stewart Bryant, we think this is an implementation choice. So we're fine with the removal of this restriction. Then "The Exporting Process MUST NOT transmit IPFIX Messages with more than one Source ID value inside any single stream." in section 8 should also go away. Regards, Benoit. > > Regards, > Lutz > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue May 3 11:41:58 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01742 for ; Tue, 3 May 2005 11:41:57 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DSzO0-0001qA-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 May 2005 10:32:36 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DSzNz-0001q5-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 03 May 2005 10:32:35 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j43FWYh07443; Tue, 3 May 2005 17:32:34 +0200 (CEST) Received: from [10.61.64.235] (ams-clip-vpn-dhcp235.cisco.com [10.61.64.235]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j43FWXK21463; Tue, 3 May 2005 17:32:33 +0200 (CEST) Message-ID: <42779991.7020501@cisco.com> Date: Tue, 03 May 2005 17:32:33 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: STEPHAN Emile RD-CORE-LAN CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] new version of the IPFIX protocol draft: draft-ietf-ipfix-protocol-12.txt References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090607020307040302010702" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------090607020307040302010702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id j43FWYh07443 Content-Transfer-Encoding: quoted-printable Dear Emile, > Dear Benoit, > > =20 > > What is the max length of a fixed length field ? Is it 65534 ? > The draft says: Field Length =20 The length of the corresponding encoded Information Element, =20 in octets. Refer to [IPFIX-INFO]. The field length may be =20 smaller than the definition in [IPFIX-INFO] if reduced size =20 encoding is used (see section 6.2). The value 65535 is =20 reserved for variable length Information Element (see =20 section 7). The Field Length MAY NOT 0.=20 So we don't specify what the maximum length is, we simply say that 65535 = is reserved. Obviously this is below 65535.=20 Anyway, the length is specify by the information model=20 > Does that make sense as the max length of an IPFIX msg is 65535 ? > IMHO, this offers the maximum of flexibility. > =20 > > At large, in the future IPFIX will need to define new kind of field=20 > types. The current definition of 'Field Length' must be prepared for=20 > that. I propose to reserve the MSB of 'Field Length' for future usage. > How to export in UDP an IPFIX Message whose length is above 65535 is not=20 that such a trivial issue! So I propose to start with IPFIX 1.0, get some adoption, see the=20 limitations, and go from there. Regards, Benoit. > =20 > > Regards > > Emile > > =20 > > -----------------------------------------------------------------------= - > > *De :* majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] *De=20 > la part de* Benoit Claise > *Envoy=E9 :* mardi 19 avril 2005 01:43 > *=C0 :* ipfix-protocol@net.doit.wisc.edu; me > *Cc :* Paul Aitken > *Objet :* [ipfix-protocol] new version of the IPFIX protocol draft:=20 > draft-ietf-ipfix-protocol-12.txt > > =20 > > Dear all, > > I just posted a new version of the IPFIX protocol draft, with the=20 > feedback from Paul Aitken's thorough review. > > Here are the list of changes: > - Some cross references were wrong > - Flow Record definition exactly similar to the one in [IPFIX-ARCH] > - Template definition exactly similar to the one in [IPFIX-ARCH] > - As deduced from section 9, the source ID definition now contains:=20 > the source ID MUST NOT be 0 > - The Field Length is completed with:** **The value 65535 is reserved=20 > for variable length Information Element (see section 7). The Field=20 > Length MAY NOT 0. > - one mistake corrected in figure O > - correction: In most cases the length of the Information Element will=20 > be less than 256 **255** octets. > - correction: The IPFIX Message Header 16-bit Length field limits the=20 > length of a IPFIX Message to 65536 **65535** octets including the heade= r. > - section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops=20 > ;) BTW, the TCP sections now speaks of TCP connection as opposed to=20 > TCP association > - added the 2 sentences > > When the TCP connection restarts, the Exporting Process MUST resend=20 > > all the Template Records. =20 > > =20 > > When an TCP connection is closed, the Collecting Process MUST=20 > > discard all templates received over that connection and stop=20 > > decoding IPFIX Messages that use those templates.=20 > >- A couple of mistakes in the examples. > >=20 > >I advice to review the changes at http://ietf.levkowetz.com/drafts/ipfix= /, once the draft is published.=20 > >=20 > >Regards, Benoit. > > =20 > > =20 > > =20 > >** ** > > - A lot of editorial corrections and improvements > --------------090607020307040302010702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Emile,

Dear Benoit,

 

What is the max length of a fixed length field ? Is it 65534 ?

The draft says: 
Field Length  
           The length of the corresponding encoded Information Element,  
           in octets.  Refer to [IPFIX-INFO].  The field length may be  
           smaller than the definition in [IPFIX-INFO] if reduced size  
           encoding is used (see section 6.2).  The value 65535 is    
           reserved for variable length Information Element (see  
           section 7). The Field Length MAY NOT 0. 

So we don't specify what the maximum length is, we simply say that 65535 is reserved. Obviously this is below 65535. 
Anyway, the length is specify by the information model

Does that make sense as the max length of an IPFIX msg is 65535 ?

IMHO, this offers the maximum of flexibility.

 

At large, in the future IPFIX will need to define new kind of field types. The current definition of  'Field Length' must be prepared for that. I propose to reserve the MSB of 'Field Length' for future usage.

How to export in UDP an IPFIX Message whose length is above 65535 is not that such a trivial issue!
So I propose to start with IPFIX 1.0, get some adoption, see the limitations, and go from there.

Regards, Benoit.

 

Regards

Emile

 

De : majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] De la part de Benoit Claise
Envoyé : mardi 19 avril 2005 01:43
À : ipfix-protocol@net.doit.wisc.edu; me
Cc : Paul Aitken
Objet : [ipfix-protocol] new version of the IPFIX protocol draft: draft-ietf-ipfix-protocol-12.txt

 

Dear all,

I just posted a new version of the IPFIX protocol draft, with the feedback from Paul Aitken's thorough review.

Here are the list of changes:
- Some cross references were wrong
- Flow Record definition exactly similar to the one in [IPFIX-ARCH]
- Template definition exactly similar to the one in [IPFIX-ARCH]
- As deduced from section 9, the source ID definition now contains: the source ID MUST NOT be 0
- The Field Length is completed with: The value 65535 is reserved for variable length Information Element (see section 7). The Field Length MAY NOT 0.
- one mistake corrected in figure O
- correction: In most cases the length of the Information Element will be less than 256 255 octets.
- correction: The IPFIX Message Header 16-bit Length field limits the length of a IPFIX Message to 65536 65535 octets including the header.
- section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops ;) BTW, the TCP sections now speaks of TCP connection as opposed to TCP association
- added the 2 sentences

   When the TCP connection restarts, the Exporting Process MUST resend 
   all the Template Records.  
     
   When an TCP connection is closed, the Collecting Process MUST 
   discard all templates received over that connection and stop 
   decoding IPFIX Messages that use those templates. 
- A couple of mistakes in the examples.
 
I advice to review the changes at http://ietf.levkowetz.com/drafts/ipfix/, once the draft is published. 
 
Regards, Benoit.

 

     

 

 

- A lot of editorial corrections and improvements


--------------090607020307040302010702-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue May 3 13:16:17 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11648 for ; Tue, 3 May 2005 13:16:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DT0rT-0005CZ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 May 2005 12:07:07 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DT0rR-0005CU-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 03 May 2005 12:07:05 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 19:06:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55002.8463C96F" Subject: [ipfix-protocol] info model flexibility Date: Tue, 3 May 2005 19:06:57 +0200 Message-ID: Thread-Topic: info model flexibility Thread-Index: AcVP9VYqi2rFjjKOQCqrLh+jmJndHwABSX3g From: "STEPHAN Emile RD-CORE-LAN" To: "Benoit Claise" Cc: , "Juergen Quittek" X-OriginalArrivalTime: 03 May 2005 17:06:59.0485 (UTC) FILETIME=[849B3CD0:01C55002] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------_=_NextPart_001_01C55002.8463C96F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Benoit, =20 The info model (section 2.1) is designed to be managed dynamically by = IANA without moving to a new protocol version. So I consider that more = flexibility must be given to the specification of Information Elements = in the info model. Let's take a real example: Downcasting is currently defined in the protocol specification. = Consequently it will not be possible to use them in the future with new = field types. So Downcasting may be moved in the section 2.1 of the info = model.=20 =20 What about replacing "dataType - One of the types listed in section 3.1 = of this document..." with" dataType - Types listed in section 3.1 of = this document..." ? Or what about defining a downcasting keyword in the = MAY list of this section?=20 =20 Regards Emile ________________________________ De : Benoit Claise [mailto:bclaise@cisco.com]=20 Envoy=E9 : mardi 3 mai 2005 17:33 =C0 : STEPHAN Emile RD-CORE-LAN Cc : ipfix-protocol@net.doit.wisc.edu Objet : Re: [ipfix-protocol] new version of the IPFIX protocol draft: = draft-ietf-ipfix-protocol-12.txt =20 Dear Emile, Dear Benoit, =20 What is the max length of a fixed length field ? Is it 65534 ?=20 The draft says:=20 Field Length =20 The length of the corresponding encoded Information Element, = in octets. Refer to [IPFIX-INFO]. The field length may be =20 smaller than the definition in [IPFIX-INFO] if reduced size =20 encoding is used (see section 6.2). The value 65535 is =20 reserved for variable length Information Element (see =20 section 7). The Field Length MAY NOT 0.=20 =20 So we don't specify what the maximum length is, we simply say that 65535 = is reserved. Obviously this is below 65535.=20 Anyway, the length is specify by the information model=20 Does that make sense as the max length of an IPFIX msg is 65535 ? IMHO, this offers the maximum of flexibility. =20 At large, in the future IPFIX will need to define new kind of field = types. The current definition of 'Field Length' must be prepared for = that. I propose to reserve the MSB of 'Field Length' for future usage. How to export in UDP an IPFIX Message whose length is above 65535 is not = that such a trivial issue! So I propose to start with IPFIX 1.0, get some adoption, see the = limitations, and go from there. Regards, Benoit. =20 Regards Emile =20 ________________________________ De : majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] De la = part de Benoit Claise Envoy=E9 : mardi 19 avril 2005 01:43 =C0 : ipfix-protocol@net.doit.wisc.edu; me Cc : Paul Aitken Objet : [ipfix-protocol] new version of the IPFIX protocol draft: = draft-ietf-ipfix-protocol-12.txt =20 Dear all,=20 I just posted a new version of the IPFIX protocol draft, with the = feedback from Paul Aitken's thorough review. Here are the list of changes: - Some cross references were wrong - Flow Record definition exactly similar to the one in [IPFIX-ARCH] - Template definition exactly similar to the one in [IPFIX-ARCH] - As deduced from section 9, the source ID definition now contains: the = source ID MUST NOT be 0 - The Field Length is completed with: The value 65535 is reserved for = variable length Information Element (see section 7). The Field Length = MAY NOT 0.=20 - one mistake corrected in figure O - correction: In most cases the length of the Information Element will = be less than 256 255 octets. - correction: The IPFIX Message Header 16-bit Length field limits the = length of a IPFIX Message to 65536 65535 octets including the header. - section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops ;) = BTW, the TCP sections now speaks of TCP connection as opposed to TCP = association - added the 2 sentences When the TCP connection restarts, the Exporting Process MUST resend=20 all the Template Records. =20 =20 When an TCP connection is closed, the Collecting Process MUST=20 discard all templates received over that connection and stop=20 decoding IPFIX Messages that use those templates.=20 - A couple of mistakes in the examples. =20 I advice to review the changes at = http://ietf.levkowetz.com/drafts/ipfix/, once the draft is published.=20 =20 Regards, Benoit. =20 =20 =20 =20 - A lot of editorial corrections and improvements =20 ------_=_NextPart_001_01C55002.8463C96F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Benoit,

 

The info model = (section 2.1) is designed to be managed dynamically by IANA without moving to a = new protocol version. So I consider that more flexibility must be given to = the specification of Information Elements in the info model. Let's take a real = example:

Downcasting is currently defined in the protocol = specification. Consequently it will not be possible to use them in the future with new field types. = So Downcasting may be moved in the section 2.1 of the info model.

 

What about replacing "dataType - One of the types = listed in section 3.1 of this document…" with" dataType - Types = listed in section 3.1 of this document…" ? Or what about defining a downcasting keyword in the MAY list of this section?

 

Regards

Emile

De : Benoit Claise = [mailto:bclaise@cisco.com]
Envoy=E9 : mardi 3 = mai 2005 17:33
=C0 : STEPHAN Emile = RD-CORE-LAN
Cc : = ipfix-protocol@net.doit.wisc.edu
Objet : Re: = [ipfix-protocol] new version of the IPFIX protocol draft: = draft-ietf-ipfix-protocol-12.txt

 

Dear Emile,


Dear Benoit,

 

What is the max length of a = fixed length field ? Is it 65534 ?

The draft says: 

Field Length=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0The length =
of the corresponding encoded Information Element,=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0in =
octets.=A0 Refer to [IPFIX-INFO].=A0 The field length may be=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0smaller than =
the definition in [IPFIX-INFO] if reduced size=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0encoding is =
used (see section 6.2).=A0 The value 65535 is=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0reserved for =
variable length Information Element (see=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0section 7). =
The Field Length MAY NOT 0. 
 
So we don't specify what the maximum length =
is, we simply say that 65535 is reserved. Obviously this is below 65535. =

Anyway, the length is specify by the =
information model

Does that make sense as the max = length of an IPFIX msg is 65535 ?

IMHO, this offers the maximum of = flexibility.

 

At large, in the future IPFIX = will need to define new kind of field types. The current definition of  'Field = Length' must be prepared for that. I propose to reserve the MSB of 'Field = Length' for future usage.

How to export in UDP an IPFIX Message whose = length is above 65535 is not that such a trivial = issue!
So I propose to start with IPFIX 1.0, get some adoption, see the = limitations, and go from there.

Regards, Benoit.

 

Regards

Emile

 

De : majordomo listserver [mailto:majordomo@mil.doit.wis= c.edu] De la part de Benoit = Claise
Envoy=E9 : mardi 19 = avril 2005 01:43
=C0 : ipfix-protocol@net.doit.= wisc.edu; me
Cc : Paul Aitken
Objet : = [ipfix-protocol] new version of the IPFIX protocol draft: = draft-ietf-ipfix-protocol-12.txt

 

Dear all,

I just posted a new version of the IPFIX protocol draft, with the = feedback from Paul Aitken's thorough review.

Here are the list of changes:
- Some cross references were wrong
- Flow Record definition exactly similar to the one in [IPFIX-ARCH]
- Template definition exactly similar to the one in [IPFIX-ARCH]
- As deduced from section 9, the source ID definition now contains: the = source ID MUST NOT be 0
- The Field Length is completed with: = The value 65535 is reserved for variable length Information Element (see = section 7). The Field Length MAY NOT 0.
- one mistake corrected in figure O
- correction: In most cases the length of the Information Element will = be less than 256 255 octets.
- correction: The IPFIX Message Header 16-bit Length field limits the = length of a IPFIX Message to 65536 65535 octets including the header.
- section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops ;) = BTW, the TCP sections now speaks of TCP connection as opposed to TCP = association
- added the 2 sentences

   When the TCP connection =
restarts, the Exporting Process MUST resend =

   all the Template =
Records.  
     
   When an TCP connection is =
closed, the Collecting Process MUST 
   discard all templates =
received over that connection and stop 
   decoding IPFIX Messages =
that use those templates. 
- A couple of mistakes in the =
examples.
 
I advice to review the changes at http://ietf.levkowetz.co=
m/drafts/ipfix/, once the draft is published. =

 
Regards, Benoit.



 



      =




 



 



- A lot of editorial corrections and =
improvements

 

------_=_NextPart_001_01C55002.8463C96F-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From info@mail.kqsv05.com Tue May 3 23:38:17 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09961 for ; Tue, 3 May 2005 23:38:16 -0400 (EDT) Received: from [61.106.54.58] (helo=mail.kqsv05.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DTAQe-0001hb-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 May 2005 22:20:05 -0500 Received: (qmail 23948 invoked by uid 510); 3 May 2005 18:25:30 +0900 Date: 3 May 2005 18:25:30 +0900 Message-ID: <20050503092530.23946.qmail@mail.kqsv05.com> From: info@kqsv05.com To: ipfix-list@mil.doit.wisc.edu Subject: $BL5NA(B10000$B1_J,$GM7$s$G$_$h$&!*(B _/_/_/_/_/$B5U1g!y?M:J!y3d@Z!y(BSM$B!yB(2q$$!yD>%aD>EE(B_/_/_/_/_/ _/_/_/_/_/_/ http://awg.webchu.com/?springe _/_/_/_/_/_/ $B!xBg9%I>!V(B10000$B1_!WL5NA%]%$%s%HB#Dh%-%c%s%Z!<%s7QB3@-$,Hs>o$K9b$/!"0l;~@$4V$rFx$o$;$?2M6u@A5a$H$bEvJ}$O0l@Z4X$o$j$,$"$j$^$;$s$N$G0B?4$7$F$4MxMQ2<$5$$!#(B $B!}L5NA$G$?$C$W$jM7$s$GD:$-!"!V$3$3$J$i!*!W$H;W$C$FD:$1$?J}$O0B?4$NA0J'$$$r$4MxMQ2<$5$$!#$?$C$?(B3000$B1_$+$i$4MxMQD:$1$^$9!#(B $B"(Ev%a!<%k$NG[?.5qH]$O$3$A$i"*(B csvbit7q8a9z@ok.kz $B$^$G$*; Wed, 4 May 2005 02:22:41 -0400 (EDT) Received: from smtp.doit.wisc.edu ([144.92.9.43]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DTD3m-00072p-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 May 2005 01:08:38 -0500 Received: from c-24-127-145-89.hsd1.ca.comcast.net (c-24-127-145-89.hsd1.ca.comcast.net [24.127.145.89]) by smtp.doit.wisc.edu (8.13.3/8.12.6) with SMTP id j4468UAK059876 for ; Wed, 4 May 2005 01:08:35 -0500 Message-ID: From: "Richard K. Lee" <53collette@7am.com> To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?SG9ybnkgcGlsbHMgLSAkMi45OS9kb3Nl?= Date: Wed, 04 May 2005 04:59:21 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_69BC487A.5023572B" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0000_69BC487A.5023572B Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_21759091.729B9707" ------=_NextPart_001_0001_21759091.729B9707 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Perfect erection Long duration of effects No prescription needed 2 popular medicines: CIALIS - http://www.horny-pills.com/sv/ VIAGRA - http://www.horny-pills.com/vt/ Discreet packaging _________________________________________________________________________ To change your mail preferences, go here _________________________________________________________________________ ------=_NextPart_001_0001_21759091.729B9707 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Perfect erection
Long duration of effects
No prescription needed

2 popular medicines:
CIALIS - http://www.horny-pills.com/sv/
VIAGRA - http://www.horny-pills.com/vt/

Discreet packaging


_________________________________________________________________________
To change your mail preferences, go here
_________________________________________________________________________

------=_NextPart_001_0001_21759091.729B9707-- ------=_NextPart_000_0000_69BC487A.5023572B-- From majordomo@mil.doit.wisc.edu Wed May 4 04:12:45 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03888 for ; Wed, 4 May 2005 04:12:45 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DTEqp-0003CJ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 May 2005 03:03:23 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DTEqo-0003C9-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 04 May 2005 03:03:22 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4483Lq15123 for ; Wed, 4 May 2005 10:03:21 +0200 (CEST) Received: from [10.61.64.240] (ams-clip-vpn-dhcp240.cisco.com [10.61.64.240]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4483HK07161 for ; Wed, 4 May 2005 10:03:17 +0200 (CEST) Message-ID: <427881C3.90200@cisco.com> Date: Wed, 04 May 2005 10:03:15 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] One correction in the "octets" information elements Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, We realized that the Information Element #1 octetDeltaCount, which is in line with NetFlow version 9, is not correctly specified. 5.9.1 octetDeltaCount Description: The number of octets since the previous report (if any) in incoming packets for this flow at the Observation Point. The number of octets include IP header(s) and IP payload. -> New Description: The number of octets since the previous report (if any) in incoming packets for this flow at the Observation Point. The number of octets exclude the data link header and trailer. This allows to account for the length of MPLS labels, for the ISL bytes, etc... Several I.E. below the 128 should be updated octetDeltaCount #1, postOctetDeltaCount #23, octetTotalCount #85, postMulticastOctetCount #20 And to be consistent amongst the I.E., the I.E. above 128 should be updated as well postOctetTotalCount #160, droppedOctetDeltaCount #132, droppedOctetTotalCount #134 Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 4 05:56:22 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13296 for ; Wed, 4 May 2005 05:56:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DTGXQ-00071Q-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 May 2005 04:51:28 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DTGXP-00071L-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 04 May 2005 04:51:27 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j449pQi23347 for ; Wed, 4 May 2005 11:51:26 +0200 (CEST) Received: from [10.61.64.240] (ams-clip-vpn-dhcp240.cisco.com [10.61.64.240]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j449pQK25225 for ; Wed, 4 May 2005 11:51:26 +0200 (CEST) Message-ID: <42789B1E.7000902@cisco.com> Date: Wed, 04 May 2005 11:51:26 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Source ID 0? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, Question: which source ID to put in the IPFIX Message Header when we export the "The Exporting Process Reliability Statistics Option Template" (section 4.3)? Question: which source ID to put in the IPFIX Message Header when we export from a Collecting Process aggregated data records to another application (hierarchy of Collecting Process)? Question: which source ID to put in the IPFIX Message Header when we export the"The Metering Process Statistics Option Template" (section 4.1) and "The Metering Process Reliability Statistics Option Template" (section 4.2)? Those 2 specific option template already contain the source ID as scope. So we might have an IPFIX Message containing a Source ID X in its header, a data record with Source ID X as scope and a second Source ID Y as scope. This situation might confuse the collector. The idea: let's use the source ID zero. I would propose: 1. To remove the Source ID zero restrictions: "The Source ID MUST NOT be 0" and "IPFIX Messages with a Source ID of zero MUST be discarded by the Collecting Process. " 2. To add the following text in section 3.1, next to the Source ID definition "The Source ID SHOULD be 0 when no specific Source ID is relevant for the entire IPFIX Message. For example, when exporting the Exporting Process Statistics, or in case of hierarchy of Collector when aggregated data records are exported. The Source ID MUST be zero when the IPFIX Message contains data records with different Source ID values defined as scopes. Note: this proposal is inline with Lutz Mark's proposal http://ipfix.doit.wisc.edu/archive/2780.html Any feedback or objections? Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 4 06:33:22 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16128 for ; Wed, 4 May 2005 06:33:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DTH4y-0000aJ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 May 2005 05:26:08 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DTH4w-0000aE-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 04 May 2005 05:26:06 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j44AQ5s26067 for ; Wed, 4 May 2005 12:26:05 +0200 (CEST) Received: from [10.61.64.240] (ams-clip-vpn-dhcp240.cisco.com [10.61.64.240]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j44AQ3K03075 for ; Wed, 4 May 2005 12:26:04 +0200 (CEST) Message-ID: <4278A33B.1010008@cisco.com> Date: Wed, 04 May 2005 12:26:03 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Options Template Record Format section Content-Type: multipart/alternative; boundary="------------090606060808090907080003" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------090606060808090907080003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, It has been brought to my attention that the section 3.4.2 "Options Template Record Format" is not too clear. This is right. The following sentence is misleading: The Options Template Record (and its corresponding Data Record) is used to supply information about the Metering Process rather than supplying information about IP Flows. I would like to propose the following improvements for the section 3.4.2 and 3.4.2.1, mainly done by moving text between the 2 sections. Note that these would be already inline with http://ipfix.doit.wisc.edu/archive/2784.html 3.4.2 Options Template Record Format _ Thanks to the notion of scope, The Options Template Record gives the Exporter the ability to provide additional information to the Collector which would not be possible with Flow Records alone. One Options Template Record example is the "Flow Keys", which reports the Flow Keys for a template, which is defined as the scope. Another example is the "Template configuration", which reports the configuration sampling parameter(s) for the template, which is defined as the scope. _ 3.4.2.1 Scope _ The scope, which is only available in the Options Template Set, gives the context of the reported Information Elements in the Data Records. Note that the IPFIX Message Header already contains the Source ID (the identifier of the Observation Domain). If not zero, this Source ID can be considered as an implicit scope for the Data Records in the IPFIX Message. _ Multiple scope fields MAY be present in the Options Template Record, in which case, the composite scope is the combination of the scopes. For example, if the two scopes are defined as "metering process" and "template", the combined scope is this template for this metering process. The order of the scope fields, as defined in the Options Template Record, is irrelevant in this case. However, if the order of the scope fields in the Option Template Record is relevant, the order of the scope fields MUST be used. For example, if the first scope defines the filtering function, while the second scope defines the sampling function, the order of the scope is important. Applying the sampling function first, followed by the filtering function, would lead to potentially different Data Records than applying the filtering function first, followed by the sampling function. In this case, the Collector deduces the function order by looking at the order of the scope in the Options Template Record. The scope is an Information Element specified in the IPFIX Information Model [IPFIX-INFO]. An IPFIX compliant implementation of the Collecting Process SHOULD support this minimum set of Information Elements as scope: LineCardId, TemplateId, exporterIPv4Address, exporterIPv6Address, and ingressInterface. Note that other Information Elements such as meteringProcessId, exportingProcessId, sourceId, etc. are also valid scopes. The IPFIX protocol doesn't prevent the use of any Information Elements for scope. However some Information Element types don't make sense if specifed as scope. For example: the counter Information Elements. Finally, note that the _Scope Field Count _MAY NOT be zero. Any feedback or objections? Regards, Benoit. --------------090606060808090907080003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

It has been brought to my attention that the section 3.4.2 "Options Template Record Format" is not too clear.
This is right. The following sentence is misleading:
   The Options Template Record (and its corresponding Data Record) is 
   used to supply information about the Metering Process rather than 
   supplying information about IP Flows.
I would like to propose the following improvements for the section 3.4.2 and 3.4.2.1, mainly done by moving text between the 2 sections.
Note that these would be already inline with http://ipfix.doit.wisc.edu/archive/2784.html

3.4.2   Options Template Record Format 
    
   Thanks to the notion of scope, The Options Template Record gives the
   Exporter the ability to provide additional information to the 
   Collector which would not be possible with Flow Records alone. 

   One Options Template Record example is the "Flow Keys", which 
   reports the Flow Keys for a template, which is defined as the scope.  
   Another example is the "Template configuration", which reports the
   configuration sampling parameter(s) for the template, which is 
   defined as the scope. 

 3.4.2.1 Scope  
    
   The scope, which is only available in the Options Template Set, 
   gives the context of the reported Information Elements in the 
   Data Records.  Note that the IPFIX Message Header already contains 
   the Source ID (the identifier of the Observation Domain). If not 
   zero, this Source ID can be considered as an implicit scope for 
   the Data Records in the IPFIX Message. 
    
   Multiple scope fields MAY be present in the Options Template Record, 
   in which case, the composite scope is the combination of the scopes. 
   For example, if the two scopes are defined as "metering process" and 
   "template", the combined scope is this template for this metering 
   process.  The order of the scope fields, as defined in the Options 
   Template Record, is irrelevant in this case. However, if the order 
   of the scope fields in the Option Template Record is relevant, the 
   order of the scope fields MUST be used.  For example, if the first 
   scope defines the filtering function, while the second scope defines 
   the sampling function, the order of the scope is important. Applying 
   the sampling function first, followed by the filtering function, 
   would lead to potentially different Data Records than applying the 
   filtering function first, followed by the sampling function.  In 
   this case, the Collector deduces the function order by looking at 
   the order of the scope in the Options Template Record.  
    
   The scope is an Information Element specified in the IPFIX 
   Information Model [IPFIX-INFO]. An IPFIX compliant implementation of 
   the Collecting Process SHOULD support this minimum set of 
   Information Elements as scope: LineCardId, TemplateId, 
   exporterIPv4Address, exporterIPv6Address, and ingressInterface.  
   Note that other Information Elements such as meteringProcessId, 
   exportingProcessId, sourceId, etc. are also valid scopes. The IPFIX 
   protocol doesn't prevent the use of any Information Elements for 
   scope. However some Information Element types don't make sense if 
   specifed as scope. For example: the counter Information Elements. 
 
   Finally, note that the Scope Field Count MAY NOT be zero.

Any feedback or objections?

Regards, Benoit.







--------------090606060808090907080003-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 4 08:05:34 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25935 for ; Wed, 4 May 2005 08:05:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DTIYl-00045v-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 May 2005 07:00:59 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DTIYk-00045q-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 04 May 2005 07:00:58 -0500 Received: from [192.168.113.33] (dsl-084-059-034-009.arcor-ip.net [84.59.34.9]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j44C0sT23175; Wed, 4 May 2005 14:00:54 +0200 (MEST) Message-ID: <4278B9CA.9090602@fokus.fraunhofer.de> Date: Wed, 04 May 2005 14:02:18 +0200 From: Lutz Mark User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Stewart Bryant CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Encoding of IPFIX Data Types References: <42774A6A.7040106@fokus.fraunhofer.de> <42776CFE.9050404@cisco.com> In-Reply-To: <42776CFE.9050404@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Steward, > There are three possible ways to send a string: > > 1) Fixed length > 2) Short variable length > 3) Long variable length. > > In case 1, you put the length in the template and the string > is always that length, and if your string is shorter you have > to pad. > > In case 2 and 3 you use a special length value in the template > which says that the length is encoded at the start of the string. thank you for the clarification. I suggest to change section 6.1.5. What about: The data type string represents a finite length string of valid characters of the Unicode character encoding set. It is expected that strings will be encoded in UTF-8 format. The string is sent as an array of octets using an information element of fixed or variable length. The length of the information element specifies the length of the octetarray. Best regards, Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 4 08:14:19 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26946 for ; Wed, 4 May 2005 08:14:18 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DTIfY-0004CM-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 May 2005 07:08:00 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DTIfX-0004CB-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 04 May 2005 07:07:59 -0500 Received: from [192.168.113.33] (dsl-084-059-034-009.arcor-ip.net [84.59.34.9]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j44C7tT24664; Wed, 4 May 2005 14:07:55 +0200 (MEST) Message-ID: <4278BB6E.3010008@fokus.fraunhofer.de> Date: Wed, 04 May 2005 14:09:18 +0200 From: Lutz Mark User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: STEPHAN Emile RD-CORE-LAN CC: Stewart Bryant , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Encoding of IPFIX Data Types References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit STEPHAN Emile RD-CORE-LAN wrote: > Dear Stewart, Lutz > > I suggest that section 6.2 defines the reduced size encoding not only for integer but for string and array too. That will clarify the link to section 6.2 in section "3.2 Field Specifier". for me this makes sense. Lutz -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 4 10:40:06 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15955 for ; Wed, 4 May 2005 10:40:05 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DTKdh-0000vd-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 May 2005 09:14:13 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DTKdg-0000vY-00 for ipfix-info@net.doit.wisc.edu; Wed, 04 May 2005 09:14:12 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j44EEAL13451; Wed, 4 May 2005 16:14:10 +0200 (CEST) Received: from [10.61.64.240] (ams-clip-vpn-dhcp240.cisco.com [10.61.64.240]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j44EE9K10611; Wed, 4 May 2005 16:14:10 +0200 (CEST) Message-ID: <4278D8B1.2030003@cisco.com> Date: Wed, 04 May 2005 16:14:09 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny McPherson CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] BGP related Information Elements References: <426E5295.8080602@cisco.com> <7ab543168fd86ef01096ded6d744219f@tcb.net> In-Reply-To: <7ab543168fd86ef01096ded6d744219f@tcb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Danny, > > On Apr 26, 2005, at 8:39 AM, Benoit Claise wrote: > >> >> If I configure the router in AS3 to export the origin AS's (for the >> one familiar with NetFlow), the flow record contains: >> AS1 and AS5, exported in #16 and #17 respectively. This is OK. >> >> If I configure the router in AS3 to export the peer AS's (for the one >> familiar with NetFlow), the flow record contains: >> - AS2 and AS4 (**), exported in #? (*) and #128 (**) respectively >> >> (*) I don't find the respective I.E. >> (** ) attention: according to the current definition, if "bgp >> next-hop self" is configured on the router in AS3, this I.E. will >> report AS3!! > > > And indeed the BGP NEXT_HOP is most always most always within > the local AS, unless on the AS egress border router. I'm not sure > I understand why anyone would want to report on the "origin AS" > value for the BGP NEXT_HOP anyways. Could someone explain this to > me? The BGP NEXT_HOP itself makes sense, but recursive lookups > for the "origin AS" of the BGP NEXT_HOP seems a bit silly to me - > perhaps I'm missing something? > >> So I don't think the current I.E. #128 is useful as we have to know >> on the collector's side whether next-hop self is configured on not! > > > >> I would like to propose that 1. we change #128 to bgpDstPeerASNumber >> with a new definition (to avoid the problem with the next hop-self) >> 2. we change #129 to bgpSrcPeerASNumber. Why changing #129 and not >> using the a new I.E? Because I think it was the intended goal behind >> its definition. >> >> 5.4.6 bgpDstPeerASNumber > > > I'd prefer a name with bgpDstAdjacentASNumber or the like, as this is > still a bit > confusing. Make sense. > >> Description: >> The autonomous system (AS) number of the next AS in the AS path to >> which packets of this flow are forwarded. > > > "next AS" should probably read something like "leftmost" or "first" AS > segment > in the AS_PATH, where the term "segment" is employed to accommodate > either > a single AS or an AS_SET. > >> >> Abstract Data Type: unsigned16 > > > Could be multiple entries with an AS_SET. I think we have a technical problem right now in IPFIX. We can't report an AS_SET. How can we report that the bgpDstAdjacentASNumber is not a single unsigned16, but list of unsigned16? This is not possible! So a quick and dirty solution... why not say: export 0 for AS_SET. Anyway, reporting the AS_SET is not that useful on the collector. If AS_SET = (100, 200, 300), it means that most specific routes of this aggregate prefix comes from either 100, either 200, either 300. > >> Data Type Semantics: identifier >> >> ElementId: 128 >> Status: current >> >> Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a >> definition of the AS number. > > > s/BGB-4/BGP-4/ > > Also, you might want to scrap the RFC 1930 reference and just use > RFC 1771 or ietf-idr-bgp-26.txt. > >> >> 5.4.6 bgpSrcPeerASNumber > > > Same issue.. Something like bgpSrcAdjacentASNumber or the like. > >> >> Description: >> The autonomous system (AS) number of the previous AS in the AS >> path from which packets of this flow arrived. In case of BGP >> asymmetry, the bgpPreviousAsNumber might not be able to >> report the correct value. > > > Note the "Previous" in the name above. Also, should you say something > about > source and destination prefixes here and above, it might help > implementers, per > this would be a "first" or "leftmost" AS segment in the AS_PATH for > the source > IP prefix in the BGP Loc-RIB that contains the source IP prefix, while > above it's > the destination prefix, etc.. Any proposal? Regards, Benoit. > >> >> Data Type Semantics: identifier >> >> ElementId: 129 >> >> Status: current >> >> Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a >> definition of the AS number. > > > Also, in addition to accounting for AS_SETs, we should account for > AS_CONFED_* > segments as well. > > Same as above.. > > -danny > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 4 10:57:15 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17928 for ; Wed, 4 May 2005 10:57:14 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DTKun-0001UX-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 May 2005 09:31:53 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DTKul-0001UF-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 04 May 2005 09:31:52 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j44EVnp14840; Wed, 4 May 2005 16:31:49 +0200 (CEST) Received: from [10.61.64.240] (ams-clip-vpn-dhcp240.cisco.com [10.61.64.240]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j44EVmK02223; Wed, 4 May 2005 16:31:48 +0200 (CEST) Message-ID: <4278DCD4.1080502@cisco.com> Date: Wed, 04 May 2005 16:31:48 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: STEPHAN Emile RD-CORE-LAN CC: ipfix-protocol@net.doit.wisc.edu, Juergen Quittek Subject: [ipfix-protocol] Re: info model flexibility References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080000050903050806010309" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------080000050903050806010309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-bru.cisco.com id j44EVnp14840 Content-Transfer-Encoding: quoted-printable Hi Emile, > Hi Benoit, > > =20 > > The info model (section 2.1) is designed to be managed dynamically by=20 > IANA without moving to a new protocol version. So I consider that more=20 > flexibility must be given to the specification of Information Elements=20 > in the info model. Let's take a real example: > > Downcasting is currently defined in the protocol specification.=20 > Consequently it will not be possible to use them in the future with=20 > new field types. > I don't understand why? > So Downcasting may be moved in the section 2.1 of the info model. > The agreement was that the I.E. must define its maximum length. This was=20 required by the database guys who wanted to be able to define their schem= as. If an exporter doesn't have to use the full length, why export it? This=20 is a protocol issue and not an information model issue. > =20 > > What about replacing "dataType - One of the types listed in section=20 > 3.1 of this document..." with" dataType - Types listed in section 3.1=20 > of this document..." ? > I don't get the point with the more flexibility argument. > Or what about defining a downcasting keyword in the MAY list of this=20 > section? > See above. Regards, Benoit. > =20 > > Regards > > Emile > > -----------------------------------------------------------------------= - > > *De :* Benoit Claise [mailto:bclaise@cisco.com] > *Envoy=E9 :* mardi 3 mai 2005 17:33 > *=C0 :* STEPHAN Emile RD-CORE-LAN > *Cc :* ipfix-protocol@net.doit.wisc.edu > *Objet :* Re: [ipfix-protocol] new version of the IPFIX protocol=20 > draft: draft-ietf-ipfix-protocol-12.txt > > =20 > > Dear Emile, > > > Dear Benoit, > > =20 > > What is the max length of a fixed length field ? Is it 65534 ? > > The draft says: > >Field Length =20 > > The length of the corresponding encoded Information Element, = =20 > > in octets. Refer to [IPFIX-INFO]. The field length may be =20 > > smaller than the definition in [IPFIX-INFO] if reduced size =20 > > encoding is used (see section 6.2). The value 65535 is =20 > > reserved for variable length Information Element (see =20 > > section 7). The Field Length MAY NOT 0.=20 > >=20 > >So we don't specify what the maximum length is, we simply say that 65535= is reserved. Obviously this is below 65535.=20 > >Anyway, the length is specify by the information model=20 > >> Does that make sense as the max length of an IPFIX msg is 65535 ? >> > IMHO, this offers the maximum of flexibility. > > =20 > > At large, in the future IPFIX will need to define new kind of field=20 > types. The current definition of 'Field Length' must be prepared for=20 > that. I propose to reserve the MSB of 'Field Length' for future usage. > > How to export in UDP an IPFIX Message whose length is above 65535 is=20 > not that such a trivial issue! > So I propose to start with IPFIX 1.0, get some adoption, see the=20 > limitations, and go from there. > > Regards, Benoit. > > =20 > > Regards > > Emile > > =20 > > -----------------------------------------------------------------------= - > > *De :* majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] *De=20 > la part de* Benoit Claise > *Envoy=E9 :* mardi 19 avril 2005 01:43 > *=C0 :* ipfix-protocol@net.doit.wisc.edu=20 > ; me > *Cc :* Paul Aitken > *Objet :* [ipfix-protocol] new version of the IPFIX protocol draft:=20 > draft-ietf-ipfix-protocol-12.txt > > =20 > > Dear all, > > I just posted a new version of the IPFIX protocol draft, with the=20 > feedback from Paul Aitken's thorough review. > > Here are the list of changes: > - Some cross references were wrong > - Flow Record definition exactly similar to the one in [IPFIX-ARCH] > - Template definition exactly similar to the one in [IPFIX-ARCH] > - As deduced from section 9, the source ID definition now contains:=20 > the source ID MUST NOT be 0 > - The Field Length is completed with:** **The value 65535 is reserved=20 > for variable length Information Element (see section 7). The Field=20 > Length MAY NOT 0. > - one mistake corrected in figure O > - correction: In most cases the length of the Information Element will=20 > be less than 256 **255** octets. > - correction: The IPFIX Message Header 16-bit Length field limits the=20 > length of a IPFIX Message to 65536 **65535** octets including the heade= r. > - section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops=20 > ;) BTW, the TCP sections now speaks of TCP connection as opposed to=20 > TCP association > - added the 2 sentences > > When the TCP connection restarts, the Exporting Process MUST resend=20 > > all the Template Records. =20 > > =20 > > When an TCP connection is closed, the Collecting Process MUST=20 > > discard all templates received over that connection and stop=20 > > decoding IPFIX Messages that use those templates.=20 > >- A couple of mistakes in the examples. > >=20 > >I advice to review the changes at http://ietf.levkowetz.com/drafts/ipfix= /, once the draft is published.=20 > >=20 > >Regards, Benoit. > > =20 > > =20 > > =20 > >** ** > > - A lot of editorial corrections and improvements > > =20 > --------------080000050903050806010309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Emile,

Hi Benoit,

 

The info model (section 2.1) is designed to be managed dynamically by IANA without moving to a new protocol version. So I consider that more flexibility must be given to the specification of Information Elements in the info model. Let's take a real example:

Downcasting is currently defined in the protocol specification. Consequently it will not be possible to use them in the future with new field types.

I don't understand why?

So Downcasting may be moved in the section 2.1 of the info model.

The agreement was that the I.E. must define its maximum length. This was required by the database guys who wanted to be able to define their schemas.
If an exporter doesn't have to use the full length, why export it? This is a protocol issue and not an information model issue.

 

What about replacing "dataType - One of the types listed in section 3.1 of this document…" with" dataType - Types listed in section 3.1 of this document…" ?

I don't get the point with the more flexibility argument.

Or what about defining a downcasting keyword in the MAY list of this section?

See above.

Regards, Benoit.

 

Regards

Emile

De : Benoit Claise [mailto:bclaise@cisco.com]
Envoyé : mardi 3 mai 2005 17:33
À : STEPHAN Emile RD-CORE-LAN
Cc : ipfix-protocol@net.doit.wisc.edu
Objet : Re: [ipfix-protocol] new version of the IPFIX protocol draft: draft-ietf-ipfix-protocol-12.txt

 

Dear Emile,


Dear Benoit,

 

What is the max length of a fixed length field ? Is it 65534 ?

The draft says: 

Field Length  
           The length of the corresponding encoded Information Element,  
           in octets.  Refer to [IPFIX-INFO].  The field length may be  
           smaller than the definition in [IPFIX-INFO] if reduced size  
           encoding is used (see section 6.2).  The value 65535 is    
           reserved for variable length Information Element (see  
           section 7). The Field Length MAY NOT 0. 
 
So we don't specify what the maximum length is, we simply say that 65535 is reserved. Obviously this is below 65535. 
Anyway, the length is specify by the information model

Does that make sense as the max length of an IPFIX msg is 65535 ?

IMHO, this offers the maximum of flexibility.

 

At large, in the future IPFIX will need to define new kind of field types. The current definition of  'Field Length' must be prepared for that. I propose to reserve the MSB of 'Field Length' for future usage.

How to export in UDP an IPFIX Message whose length is above 65535 is not that such a trivial issue!
So I propose to start with IPFIX 1.0, get some adoption, see the limitations, and go from there.

Regards, Benoit.

 

Regards

Emile

 

De : majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] De la part de Benoit Claise
Envoyé : mardi 19 avril 2005 01:43
À : ipfix-protocol@net.doit.wisc.edu; me
Cc : Paul Aitken
Objet : [ipfix-protocol] new version of the IPFIX protocol draft: draft-ietf-ipfix-protocol-12.txt

 

Dear all,

I just posted a new version of the IPFIX protocol draft, with the feedback from Paul Aitken's thorough review.

Here are the list of changes:
- Some cross references were wrong
- Flow Record definition exactly similar to the one in [IPFIX-ARCH]
- Template definition exactly similar to the one in [IPFIX-ARCH]
- As deduced from section 9, the source ID definition now contains: the source ID MUST NOT be 0
- The Field Length is completed with: The value 65535 is reserved for variable length Information Element (see section 7). The Field Length MAY NOT 0.
- one mistake corrected in figure O
- correction: In most cases the length of the Information Element will be less than 256 255 octets.
- correction: The IPFIX Message Header 16-bit Length field limits the length of a IPFIX Message to 65536 65535 octets including the header.
- section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops ;) BTW, the TCP sections now speaks of TCP connection as opposed to TCP association
- added the 2 sentences

   When the TCP connection restarts, the Exporting Process MUST resend 
   all the Template Records.  
     
   When an TCP connection is closed, the Collecting Process MUST 
   discard all templates received over that connection and stop 
   decoding IPFIX Messages that use those templates. 
- A couple of mistakes in the examples.
 
I advice to review the changes at http://ietf.levkowetz.com/drafts/ipfix/, once the draft is published. 
 
Regards, Benoit.

 

     

 

 

- A lot of editorial corrections and improvements

 


--------------080000050903050806010309-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 4 13:09:43 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01209 for ; Wed, 4 May 2005 13:09:42 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DTNAS-0006Zh-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 May 2005 11:56:12 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DTNAQ-0006Zb-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 04 May 2005 11:56:11 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 18:56:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C550CA.2753E96C" Subject: [ipfix-protocol] RE: info model flexibility Date: Wed, 4 May 2005 18:56:01 +0200 Message-ID: Thread-Topic: info model flexibility Thread-Index: AcVQtgQ62JBUU8PWS++JAVWVvvGfawADVmPA From: "STEPHAN Emile RD-CORE-LAN" To: "Benoit Claise" Cc: , "Juergen Quittek" X-OriginalArrivalTime: 04 May 2005 16:56:02.0642 (UTC) FILETIME=[2782B320:01C550CA] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------_=_NextPart_001_01C550CA.2753E96C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Benoit, =20 Currently downcasting is a property of the protocol. To give flexibility = to new Information Elements definition it must be an Information Element = property. In the following example foo definition says that it can be = downcasted as B and C. That is not feasible currently because = downcasting is hardcoded in the protocol. =20 Name: foo Description: "" Abstract Data Type: A ElementId: 555 Dowcasting: B and C =20 There is another benefit to define downcasting in the info model: It = will be possible to limit downcasting to a subset of integer (e.g. = unsigned64 to unsigned32 only instead of unsigned64 to unsigned32 or to = unsigned16 or to octet). =20 =20 Regards Emile =20 =20 ________________________________ De : Benoit Claise [mailto:bclaise@cisco.com]=20 Envoy=E9 : mercredi 4 mai 2005 16:32 =C0 : STEPHAN Emile RD-CORE-LAN Cc : ipfix-protocol@net.doit.wisc.edu; Juergen Quittek Objet : Re: info model flexibility =20 Hi Emile, Hi Benoit, =20 The info model (section 2.1) is designed to be managed dynamically by = IANA without moving to a new protocol version. So I consider that more = flexibility must be given to the specification of Information Elements = in the info model. Let's take a real example: Downcasting is currently defined in the protocol specification. = Consequently it will not be possible to use them in the future with new = field types.=20 I don't understand why? =20 So Downcasting may be moved in the section 2.1 of the info model. The agreement was that the I.E. must define its maximum length. This was = required by the database guys who wanted to be able to define their = schemas. If an exporter doesn't have to use the full length, why export it? This = is a protocol issue and not an information model issue.=20 =20 What about replacing "dataType - One of the types listed in section 3.1 = of this document..." with" dataType - Types listed in section 3.1 of = this document..." ? I don't get the point with the more flexibility argument. Or what about defining a downcasting keyword in the MAY list of this = section? See above. Regards, Benoit. =20 Regards Emile ________________________________ De : Benoit Claise [mailto:bclaise@cisco.com]=20 Envoy=E9 : mardi 3 mai 2005 17:33 =C0 : STEPHAN Emile RD-CORE-LAN Cc : ipfix-protocol@net.doit.wisc.edu Objet : Re: [ipfix-protocol] new version of the IPFIX protocol draft: = draft-ietf-ipfix-protocol-12.txt =20 Dear Emile, Dear Benoit, =20 What is the max length of a fixed length field ? Is it 65534 ?=20 The draft says:=20 Field Length =20 The length of the corresponding encoded Information Element, = in octets. Refer to [IPFIX-INFO]. The field length may be =20 smaller than the definition in [IPFIX-INFO] if reduced size =20 encoding is used (see section 6.2). The value 65535 is =20 reserved for variable length Information Element (see =20 section 7). The Field Length MAY NOT 0.=20 =20 So we don't specify what the maximum length is, we simply say that 65535 = is reserved. Obviously this is below 65535.=20 Anyway, the length is specify by the information model=20 Does that make sense as the max length of an IPFIX msg is 65535 ? IMHO, this offers the maximum of flexibility. =20 At large, in the future IPFIX will need to define new kind of field = types. The current definition of 'Field Length' must be prepared for = that. I propose to reserve the MSB of 'Field Length' for future usage. How to export in UDP an IPFIX Message whose length is above 65535 is not = that such a trivial issue! So I propose to start with IPFIX 1.0, get some adoption, see the = limitations, and go from there. Regards, Benoit. =20 Regards Emile =20 ________________________________ De : majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] De la = part de Benoit Claise Envoy=E9 : mardi 19 avril 2005 01:43 =C0 : ipfix-protocol@net.doit.wisc.edu; me Cc : Paul Aitken Objet : [ipfix-protocol] new version of the IPFIX protocol draft: = draft-ietf-ipfix-protocol-12.txt =20 Dear all,=20 I just posted a new version of the IPFIX protocol draft, with the = feedback from Paul Aitken's thorough review. Here are the list of changes: - Some cross references were wrong - Flow Record definition exactly similar to the one in [IPFIX-ARCH] - Template definition exactly similar to the one in [IPFIX-ARCH] - As deduced from section 9, the source ID definition now contains: the = source ID MUST NOT be 0 - The Field Length is completed with: The value 65535 is reserved for = variable length Information Element (see section 7). The Field Length = MAY NOT 0.=20 - one mistake corrected in figure O - correction: In most cases the length of the Information Element will = be less than 256 255 octets. - correction: The IPFIX Message Header 16-bit Length field limits the = length of a IPFIX Message to 65536 65535 octets including the header. - section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops ;) = BTW, the TCP sections now speaks of TCP connection as opposed to TCP = association - added the 2 sentences When the TCP connection restarts, the Exporting Process MUST resend=20 all the Template Records. =20 =20 When an TCP connection is closed, the Collecting Process MUST=20 discard all templates received over that connection and stop=20 decoding IPFIX Messages that use those templates.=20 - A couple of mistakes in the examples. =20 I advice to review the changes at = http://ietf.levkowetz.com/drafts/ipfix/, once the draft is published.=20 =20 Regards, Benoit. =20 =20 =20 =20 - A lot of editorial corrections and improvements =20 =20 ------_=_NextPart_001_01C550CA.2753E96C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Benoit,

 

Currently = downcasting is a property of the protocol. To give flexibility to new Information = Elements definition it must be an Information Element property. In the following example foo = definition says that it can be downcasted as B and C. That is not feasible = currently because downcasting is hardcoded in the protocol.

 

Name:=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = foo

Description:=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ""

Abstract Data = Type:=A0=A0=A0=A0=A0 A

ElementId:=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 555

Dowcasting: =A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 B and C

 

There is another = benefit to define downcasting in the info model: It will be possible to limit = downcasting to a subset of integer (e.g. unsigned64 to unsigned32 only instead of = unsigned64 to unsigned32 or to unsigned16 or to octet).

 

 

Regards

Emile

 

 

De : Benoit Claise = [mailto:bclaise@cisco.com]
Envoy=E9 : mercredi = 4 mai 2005 16:32
=C0 : STEPHAN Emile = RD-CORE-LAN
Cc : = ipfix-protocol@net.doit.wisc.edu; Juergen Quittek
Objet : Re: info = model flexibility

 

Hi Emile,

Hi = Benoit,

 

The info model = (section 2.1) is designed to be managed dynamically by IANA without moving to a = new protocol version. So I consider that more flexibility must be given to = the specification of Information Elements in the info model. Let's take a = real example:

Downcasting is currently defined in the protocol = specification. Consequently it will not be possible to use them in the future with new = field types.

I don't understand why?

 



So Downcasting may be moved in the section 2.1 of the info = model.

The agreement was that the I.E. must define = its maximum length. This was required by the database guys who wanted to be = able to define their schemas.
If an exporter doesn't have to use the full length, why export it? This = is a protocol issue and not an information model issue.

 

What about replacing "dataType - One of the types = listed in section 3.1 of this document…" with" dataType - Types = listed in section 3.1 of this document…" ?

I don't get the point with the more = flexibility argument.

Or what about defining a downcasting keyword in the MAY list = of this section?

See above.

Regards, Benoit.

 

Regards

Emile

De : Benoit Claise [mailto:bclaise@cisco.com]
Envoy=E9 : mardi 3 = mai 2005 17:33
=C0 : STEPHAN Emile = RD-CORE-LAN
Cc : = ipfix-protocol@net.doit.wisc.edu
Objet : Re: = [ipfix-protocol] new version of the IPFIX protocol draft: = draft-ietf-ipfix-protocol-12.txt

 

Dear = Emile,

Dear Benoit,

 

What is the max length of a = fixed length field ? Is it 65534 ?

The draft says: 

Field Length  =

       &nbs=
p;   The length of the corresponding encoded Information =
Element,  
       &nbs=
p;   in octets.  Refer to [IPFIX-INFO].  The =
field length may be  
       &nbs=
p;   smaller than the definition in [IPFIX-INFO] if =
reduced size  
       &nbs=
p;   encoding is used (see section 6.2).  The value =
65535 is    
       &nbs=
p;   reserved for variable length Information Element =
(see  
       &nbs=
p;   section 7). The Field Length MAY NOT 0. =

 
So we don't specify what the maximum length =
is, we simply say that 65535 is reserved. Obviously this is below 65535. =

Anyway, the length is specify by the =
information model

Does that make sense as the max = length of an IPFIX msg is 65535 ?

IMHO, this = offers the maximum of flexibility.

 

At large, in the future IPFIX = will need to define new kind of field types. The current definition of  'Field = Length' must be prepared for that. I propose to reserve the MSB of 'Field = Length' for future usage.

How to export = in UDP an IPFIX Message whose length is above 65535 is not that such a trivial issue!
So I propose to start with IPFIX 1.0, get some adoption, see the = limitations, and go from there.

Regards, Benoit.

 

Regards

Emile

 

De : majordomo listserver [mailto:majordomo@mil.doit.wis= c.edu] De la part de Benoit = Claise
Envoy=E9 : mardi 19 = avril 2005 01:43
=C0 : ipfix-protocol@net.doit.= wisc.edu; me
Cc : Paul Aitken
Objet : = [ipfix-protocol] new version of the IPFIX protocol draft: = draft-ietf-ipfix-protocol-12.txt

 

Dear all,

I just posted a new version of the IPFIX protocol draft, with the = feedback from Paul Aitken's thorough review.

Here are the list of changes:
- Some cross references were wrong
- Flow Record definition exactly similar to the one in [IPFIX-ARCH]
- Template definition exactly similar to the one in [IPFIX-ARCH]
- As deduced from section 9, the source ID definition now contains: the = source ID MUST NOT be 0
- The Field Length is completed with: = The value 65535 is reserved for variable length Information Element (see = section 7). The Field Length MAY NOT 0.
- one mistake corrected in figure O
- correction: In most cases the length of the Information Element will = be less than 256 255 octets.
- correction: The IPFIX Message Header 16-bit Length field limits the = length of a IPFIX Message to 65536 65535 octets including the header.
- section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops ;) = BTW, the TCP sections now speaks of TCP connection as opposed to TCP = association
- added the 2 sentences

   When the TCP connection =
restarts, the Exporting Process MUST resend =

   all the Template =
Records.  
     
   When an TCP connection is =
closed, the Collecting Process MUST 
   discard all templates =
received over that connection and stop 
   decoding IPFIX Messages =
that use those templates. 
- A couple of mistakes in the =
examples.
 
I advice to review the changes at http://ietf.levkowetz.co=
m/drafts/ipfix/, once the draft is published. =

 
Regards, Benoit.



 



      =




 



 



- A lot of editorial corrections and =
improvements

 

 

------_=_NextPart_001_01C550CA.2753E96C-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Ferra_4398@jmco.com Wed May 4 14:05:36 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08683 for ; Wed, 4 May 2005 14:05:35 -0400 (EDT) Received: from chello084113192047.4.14.vie.surfer.at ([84.113.192.47] helo=jmco.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DTO3y-0003Vw-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 May 2005 12:53:35 -0500 From: "Ferran Troutman" To: "Selma Kilpatrick" Subject: =?iso-8859-1?Q?VlAGR=E0_V=E0LL1UM_CI=E0LISS?= Date: Wed, 4 May 2005 13:53:21 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C54EF7.42791A21" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?84.113.192.47 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C54EF7.42791A21 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, bare save for the spread of canvas on her sprit. bustle - the clatter of many feet, the shouts of hoarse voices, a Major Mallard went ahead to announce him. and fell to sobbing like a child. of being able to pick and choose the crews for his augmented flee bullied and browbeat him into silence. thieving and murder? half the peril with which it was fraught for himself. He turned the transaction. Don't leave me! Don't leave me here alone! she cried in terror The Colonel swung upon him furiously. Out of this! he commande avoided her when it was possible, and was frigidly civil when it would never be an end. Have a nice day. ------=_NextPart_000_0013_01C54EF7.42791A21 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello, Do you want to spend Iess on = your p=EDlIs?
 
V=ECAGGRA V=E0LLIUM Cl=E0LIS and = many other.
 
Save over 7 0 % with PahrmacyByyMail SHOP.
 
Have a nice day.
 
 
 
 
bare save for the spread of canvas on her
sprit. = bustle - the clatter of many feet, the shouts of hoarse voices,
a = Major Mallard went ahead to announce
him. = and fell to sobbing like a
child. = of being able to pick and choose the crews for his augmented
flee = bullied and browbeat him into
silence. = thieving and
murder? = half the peril with which it was fraught for himself. He
turned = the
transaction. = Don't leave me! Don't leave me here alone! she cried in
terror = The Colonel swung upon him furiously. Out of this! he
commande = avoided her when it was possible, and was frigidly civil when
it = would never be an
end. =
------=_NextPart_000_0013_01C54EF7.42791A21-- From 50jay@accesspro.net Thu May 5 23:14:14 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27334 for ; Thu, 5 May 2005 23:14:13 -0400 (EDT) Received: from [211.186.145.180] (helo=211.186.145.180) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DTt0K-0001l9-00 for ipfix-list@mil.doit.wisc.edu; Thu, 05 May 2005 21:55:54 -0500 Message-ID: <11f301c551c6$b377aa2e$556672fc@accesspro.net> From: "TJ Meds Ltd." <50jay@accesspro.net> To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?VmFsaXVtIC0gd2hvbGVzYWxlIHByaWNl?= Date: Thu, 05 May 2005 23:01:31 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_056B588A.8F070CA7" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?211.186.145.180 This is a multi-part message in MIME format. ------=_NextPart_000_0000_056B588A.8F070CA7 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_297025F0.4177F1A0" ------=_NextPart_001_0001_297025F0.4177F1A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit VALIUM - $1.10/pill XANAX - $1.07/pill http://www.popularmeds.biz Anti-Depressants: Paxil, Prozac, Zoloft Pain Relief: Celebrex, Soma, Vioxx Weight Loss: Meridia, Xenical Other: Levitra, Propecia, Ambien _________________________________________________________________________ To change your mail details, go here _________________________________________________________________________ ------=_NextPart_001_0001_297025F0.4177F1A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

VALIUM - $1.10/pill
XANAX - $1.07/pill

http://www.popularmeds.biz

Anti-Depressants: Paxil, Prozac, Zoloft
Pain Relief: Celebrex, Soma, Vioxx
Weight Loss: Meridia, Xenical
Other: Levitra, Propecia, Ambien


_________________________________________________________________________
To change your mail details, go here
_________________________________________________________________________

------=_NextPart_001_0001_297025F0.4177F1A0-- ------=_NextPart_000_0000_056B588A.8F070CA7-- From Dots@jamesrsmith.com Thu May 5 23:52:12 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00430 for ; Thu, 5 May 2005 23:52:11 -0400 (EDT) Received: from [62.38.141.81] (helo=jamesrsmith.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DTtgF-0002xM-00 for ipfix-list@mil.doit.wisc.edu; Thu, 05 May 2005 22:39:16 -0500 From: "Prema Dotson" To: "Corneliu Silverman" Subject: =?iso-8859-1?Q?CIAL=ECS_C1AL=ECS_VlAGGR=E0?= Date: Thu, 5 May 2005 23:38:52 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C54EF7.427AF4DC" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C54EF7.427AF4DC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, them. They went in rags, some almost naked; they dwelt in squalo herd of a hundred head of cattle driven in by negro slaves. Captain Hobart has testified to what he knows - that he found me Down the long avenue between those golden walls of cane standing the derision that was in his soul. torment could bring no regrets, he had kept the thought of her ev for three days, I will undertake to raise the ransom you demand, hands behind his back, and mildly regarded the buccaneer in silen Containing his indignant amazement, his lordship delivered himsel Spaniard limb from limb upon the spot. And if they now obeyed a parting gift from us, and ye can join Don Miguel in the fort fo their reach. Will you please call James, and do as I say - and a Have a nice day. ------=_NextPart_000_0013_01C54EF7.427AF4DC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello, Do you want to spend Iess on = your p=EDIls?
 
V=EDAGRA V=E0LLlUM Cl=E0LLlS and = many other.
 
Save over 7 5 % with PahrmacyBByMail SHOP.
 
Have a nice day.
 
 
 
 
them. They went in rags, some almost naked; they dwelt in
squalo = herd of a hundred head of cattle driven in by negro
slaves. = Captain Hobart has testified to what he knows - that he found
me = Down the long avenue between those golden walls of cane
standing = the derision that was in his
soul. = torment could bring no regrets, he had kept the thought of her
ev = for three days, I will undertake to raise the ransom you
demand, = hands behind his back, and mildly regarded the buccaneer in
silen = Containing his indignant amazement, his lordship delivered
himsel = Spaniard limb from limb upon the spot. And if they now
obeyed = a parting gift from us, and ye can join Don Miguel in the fort
fo = their reach. Will you please call James, and do as I say - and
a =
------=_NextPart_000_0013_01C54EF7.427AF4DC-- From majordomo@mil.doit.wisc.edu Fri May 6 12:35:09 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07897 for ; Fri, 6 May 2005 12:35:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DU5Vb-0002PB-00 for ipfix-list@mil.doit.wisc.edu; Fri, 06 May 2005 11:16:59 -0500 Received: from dog.tcb.net ([64.78.150.133]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DU5Va-0002P6-00 for ipfix-info@net.doit.wisc.edu; Fri, 06 May 2005 11:16:58 -0500 Received: from [205.168.100.50] (dhcp1.tcb.net [205.168.100.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 3EAE26461C; Fri, 6 May 2005 10:17:48 -0600 (MDT) In-Reply-To: <4278D8B1.2030003@cisco.com> References: <426E5295.8080602@cisco.com> <7ab543168fd86ef01096ded6d744219f@tcb.net> <4278D8B1.2030003@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipfix-info@net.doit.wisc.edu From: Danny McPherson Subject: Re: [ipfix-info] BGP related Information Elements Date: Fri, 6 May 2005 10:16:56 -0600 To: Benoit Claise X-Mailer: Apple Mail (2.622) Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit On May 4, 2005, at 8:14 AM, Benoit Claise wrote: > I think we have a technical problem right now in IPFIX. We can't > report an AS_SET. How can we report that the bgpDstAdjacentASNumber is > not a single unsigned16, but list of unsigned16? This is not possible! Right.. > So a quick and dirty solution... why not say: export 0 for AS_SET. > Anyway, reporting the AS_SET is not that useful on the collector. If > AS_SET = (100, 200, 300), it means that most specific routes of this > aggregate prefix comes from either 100, either 200, either 300. This would have to apply uniformly across all these elements, as any of these could return AS_SET: 16 bgpSourceAsNumber 17 bgpDestinationAsNumber 128 bgpNextAdjacentAsNumber 129 bgpPreviousAdjacentAsNumber 149 ipNextHopAsNumber I would suspect that 16, 17 and 149 would very frequently reside within the local AS - which would most intuitively be represented by '0', I think.. For that matter, any of these could return local AS (or is it no_adjacent_AS? :-) Given my admittedly terse review of the draft, I don't see behavior defined for where these values should be derived, and in particular, how local AS (or no AS?) should be reported. Do you envision local AS being reported as a function of the router knowing what AS the local BGP process resides in? Else that local AS value isn't added to the path until advertised to an eBGP peer. I'd be a bit cautious about using '0', and perhaps specify that local AS (and no AS) always return '0'. This would align with the BGP Spec: [snip from BGP spec] When a BGP speaker originates a route then: a) the originating speaker includes its own AS number in a path segment of type AS_SEQUENCE in the AS_PATH attribute of all UPDATE messages sent to an external peer. (In this case, the AS number of the originating speaker's autonomous system will be the only entry the path segment, and this path segment will be the only segment in the AS_PATH attribute). b) the originating speaker includes an empty AS_PATH attribute in all UPDATE messages sent to internal peers. (An empty AS_PATH attribute is one whose length field contains the value zero). [/snip] So given b) above, returning zero for local AS wold seem intuitive. As for accommodating AS_SET, I'm not quite sure. Would it be unreasonable to report multiple elements of the same type here if an AS_SET is returned, or is this a bad idea (I expect so)? To further complicate things, I suspect we'll be seeing this in deployments within a couple years, per AS number depletion: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-09.txt I'm not sure if we want to worry about it now or define new elements down the road.. Regarding 149, ipNextHopAsNumber: ----- 5.6.3 ipNextHopAsNumber Description: The autonomous system (AS) number of the next IP hop to which packets of this flow are forwarded. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 149 Status: current Reference: See RFC 1771 for a description of BGP-4 and see RFC 1930 a definition of the AS number. ----- Is this element returning the AS number for the IP address reported in the BGP NEXT_HOP attribute associated with the destination prefix, or it the RIB/FIB IP "next hop" used to reach that destination? This should be stated explicitly. >> >> Note the "Previous" in the name above. Also, should you say >> something about >> source and destination prefixes here and above, it might help >> implementers, per >> this would be a "first" or "leftmost" AS segment in the AS_PATH for >> the source >> IP prefix in the BGP Loc-RIB that contains the source IP prefix, >> while above it's >> the destination prefix, etc.. > > Any proposal? Not sure if these are any better, but: 5.4.4 bgpSourceAsNumber Description: The first (origin) autonomous system (AS) number for the prefix containing the source address in the IP packet header in a packet of this flow. 5.4.5 bgpDestinationAsNumber Description: The first (origin) autonomous system (AS) number for the prefix containing the destination address in the IP packet header in a packet of this flow. And I'd still like to see similar information elements added for AS_CONFED_SET & AS_CONFED_SEQUENCE. -danny -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Odhr@jepps.com Fri May 6 14:13:03 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16351 for ; Fri, 6 May 2005 14:13:03 -0400 (EDT) Received: from [209.205.201.66] (helo=jepps.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DU7Ae-000698-00 for ipfix-list@mil.doit.wisc.edu; Fri, 06 May 2005 13:03:28 -0500 From: "Odhra Ngo" To: "Catharine Tanner" Subject: =?iso-8859-1?Q?VA11=EDUM_Cl=C1LlSS_Vl=C0GRRA?= Date: Fri, 6 May 2005 14:03:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C5527C.427BBF73" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?209.205.201.66 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C5527C.427BBF73 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, that stirred through the purple darkness of the tropical night. Captain's future wife. Don Miguel. Hate was now this unfortunate man's daily bread, and M. de Rivarol bit his lip in chagrin. His gloomy eye smouldered were being plentifully supplied by others. And... oh, no marrer! Much obliged to ye, Old Wolf - faithful If you please, he said. cord and cranium the black inserted a short length of metal, roun on the gun-deck upon the wine and the fresh meats fetched out to liberty ourselves. The consequences may be appalling. But it is Blood ordered a prompt jettisoning of the forward guns, anchors, Have a nice day. ------=_NextPart_000_0008_01C5527C.427BBF73 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello, Do you want to spend LESS on = your MED=ECCAT=EDONS?
 
V=C1L1UM CIAL=EDS VlAGRR=C0 and = many other.
 
Save over 8 0 % with PharmacyByyMAlL STORE.
 
Have a nice day.
 
 
 
 
 
that stirred through the purple darkness of the tropical
night. = Captain's future
wife. = Don Miguel. Hate was now this unfortunate man's daily bread,
and = M. de Rivarol bit his lip in chagrin. His gloomy eye smouldered
= were being plentifully supplied by
others. = And... oh, no marrer! Much obliged to ye, Old Wolf -
faithful = If you please, he
said. = cord and cranium the black inserted a short length of metal,
roun = on the gun-deck upon the wine and the fresh meats fetched out
to = liberty ourselves. The consequences may be appalling. But it
is = Blood ordered a prompt jettisoning of the forward guns,
anchors, =
------=_NextPart_000_0008_01C5527C.427BBF73-- From majordomo@mil.doit.wisc.edu Sat May 7 19:13:34 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27606 for ; Sat, 7 May 2005 19:13:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DUY9S-0003t7-00 for ipfix-list@mil.doit.wisc.edu; Sat, 07 May 2005 17:52:02 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DUY9Q-0003sm-00 for ipfix-protocol@net.doit.wisc.edu; Sat, 07 May 2005 17:52:00 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id BBA081BAC4D; Sun, 8 May 2005 00:51:58 +0200 (CEST) Date: Sun, 08 May 2005 00:52:15 +0200 From: Juergen Quittek To: Lutz Mark , Stewart Bryant Cc: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Encoding of IPFIX Data Types Message-ID: <37766A1A1380EDD67968F1D7@[192.168.0.112]> In-Reply-To: <4278B9CA.9090602@fokus.fraunhofer.de> References: <42774A6A.7040106@fokus.fraunhofer.de> <42776CFE.9050404@cisco.com> <4278B9CA.9090602@fokus.fraunhofer.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit --On 5/4/2005 2:02 PM +0200 Lutz Mark wrote: > > Hi Steward, > >> There are three possible ways to send a string: >> >> 1) Fixed length >> 2) Short variable length >> 3) Long variable length. >> >> In case 1, you put the length in the template and the string >> is always that length, and if your string is shorter you have >> to pad. >> >> In case 2 and 3 you use a special length value in the template >> which says that the length is encoded at the start of the string. > > thank you for the clarification. > I suggest to change section 6.1.5. > > What about: > The data type string represents a finite length string of valid > characters of the Unicode character encoding set. It is expected > that strings will be encoded in UTF-8 format. The string is sent as > an array of octets using an information element of fixed or variable > length. The length of the information element specifies the length > of the octetarray. I support Lutz' proposal. Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > Best regards, > Lutz > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sat May 7 20:05:51 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00303 for ; Sat, 7 May 2005 20:05:51 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DUYyD-0005tI-00 for ipfix-list@mil.doit.wisc.edu; Sat, 07 May 2005 18:44:29 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DUYyC-0005tD-00 for ipfix-protocol@net.doit.wisc.edu; Sat, 07 May 2005 18:44:28 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id F2A981BAC4D; Sun, 8 May 2005 01:44:26 +0200 (CEST) Date: Sun, 08 May 2005 01:44:43 +0200 From: Juergen Quittek To: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] One correction in the "octets" information elements Message-ID: In-Reply-To: <427881C3.90200@cisco.com> References: <427881C3.90200@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, --On 5/4/2005 10:03 AM +0200 Benoit Claise wrote: > Juergen, > > We realized that the Information Element #1 octetDeltaCount, > which is in line with NetFlow version 9, is not correctly specified. > > 5.9.1 octetDeltaCount > Description: > The number of octets since the previous report (if any) in > incoming packets for this flow at the Observation Point. The > number of octets include IP header(s) and IP payload. > > -> New Description: > The number of octets since the previous report (if any) in > incoming packets for this flow at the Observation Point. The > number of octets exclude the data link header and trailer. > > This allows to account for the length of MPLS labels, for the ISL bytes, etc... I see the following problems with this change. - This implies that we count more than just the IP packet. Since this is counter is fundamental for IPFIX, we would need to discuss precisely what is measured. I do not like the inclusion of non-IP octets in the count to be hidden in these three lines. - How useful would this information be? How would the collector know that the MPLS labels are included in the count? - Even if the collector knows that MPLS labels are included in the count, it would not be able to just subtract them for calculating the pure IP octet number, because it does not necessarily known how many labels are on the label stack. - Which information elements should a device use that supports MPLS but is able to calculate the precise IP octet count, for example at the end of the MPLS tunnel where both counts (with and without labels) are available? Instead of defining another information element for this case, I would rather define a new one for the IP+MPLS octet counter. - The definition of data link header and trailer is vague. Do we have a reference defining these terms? Without such a definition, Some people may consider MPLS as a data link layer protocol particularly since this is correct for some applications of GMPLS. - I am not sure which other technologies besides MPLS would potentially include octets in the stream that do not belong to IP but are counted by this counter. Best regards, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > Several I.E. below the 128 should be updated > octetDeltaCount #1, postOctetDeltaCount #23, > octetTotalCount #85, > postMulticastOctetCount #20 > > And to be consistent amongst the I.E., the I.E. above 128 should be > updated as well > postOctetTotalCount #160, > droppedOctetDeltaCount #132, > droppedOctetTotalCount #134 > Regards, Benoit. > > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From StrinInga5855@josserand.com Sun May 8 11:20:21 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22727 for ; Sun, 8 May 2005 11:20:20 -0400 (EDT) Received: from dyn-83-153-31-112.ppp.tiscali.fr ([83.153.31.112] helo=josserand.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DUnIQ-0007Sw-00 for ipfix-list@mil.doit.wisc.edu; Sun, 08 May 2005 10:02:18 -0500 From: "Inga Stringer" To: "Griogair Wetzel" Subject: =?iso-8859-1?Q?V=E0LLlUM_CIALL=ECS_Vl=E0GRA?= Date: Sun, 8 May 2005 11:02:14 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C5527C.427E29F6" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C5527C.427E29F6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, standing out to sea. There she go, he said. Hispaniola, which was but ten miles off. This was the course urg for a broad hat of plaited straw that sheltered his unkempt golde niece.... We want her as a hostage for our safety. Having thus emptied her basket, she called her negro, and without Blood, he thrust his face into the Captain's. Infanta was merely kept afloat by artifice, and the San Felipe wa came thrusting forward through the little throng of gaping men, never another shot that might assist their baffled and bewildered anything, I am too modest, pardi! M. d'Ogeron is reputed a wealt Have a nice day. ------=_NextPart_000_0008_01C5527C.427E29F6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello, How would you like to = save on your p=EDlIs?
 
V=C0LIUMM C=EDALLIS ViAGR=E0 and = many other.
 
Save over 70% with PharaamcyByMAlL SHOP.
 
Have a nice day.
 
 
 
 
standing out to sea. There she go, he
said. = Hispaniola, which was but ten miles off. This was the course
urg = for a broad hat of plaited straw that sheltered his unkempt
golde = niece.... We want her as a hostage for our
safety. = Having thus emptied her basket, she called her negro, and
without = Blood, he thrust his face into the
Captain's. = Infanta was merely kept afloat by artifice, and the San Felipe
wa = came thrusting forward through the little throng of gaping
men, = never another shot that might assist their baffled and
bewildered = anything, I am too modest, pardi! M. d'Ogeron is reputed a
wealt =
------=_NextPart_000_0008_01C5527C.427E29F6-- From majordomo@mil.doit.wisc.edu Mon May 9 05:25:33 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18964 for ; Mon, 9 May 2005 05:25:33 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DV4D3-00071x-00 for ipfix-list@mil.doit.wisc.edu; Mon, 09 May 2005 04:05:53 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DV4D2-00071N-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 09 May 2005 04:05:52 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4995on07200; Mon, 9 May 2005 05:05:51 -0400 (EDT) Received: from [10.61.65.196] (ams-clip-vpn-dhcp452.cisco.com [10.61.65.196]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4995iK07814; Mon, 9 May 2005 11:05:49 +0200 (CEST) Message-ID: <427F27E7.4070604@cisco.com> Date: Mon, 09 May 2005 11:05:43 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] One correction in the "octets" information elements References: <427881C3.90200@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, > Hi Benoit, > > --On 5/4/2005 10:03 AM +0200 Benoit Claise wrote: > >> Juergen, >> >> We realized that the Information Element #1 octetDeltaCount, >> which is in line with NetFlow version 9, is not correctly specified. >> >> 5.9.1 octetDeltaCount >> Description: >> The number of octets since the previous report (if any) in >> incoming packets for this flow at the Observation Point. The >> number of octets include IP header(s) and IP payload. >> >> -> New Description: >> The number of octets since the previous report (if any) in >> incoming packets for this flow at the Observation Point. The >> number of octets exclude the data link header and trailer. >> >> This allows to account for the length of MPLS labels, for the ISL >> bytes, etc... > > > I see the following problems with this change. > > - This implies that we count more than just the IP packet. > Since this is counter is fundamental for IPFIX, we would need > to discuss precisely what is measured. I do not like the > inclusion of non-IP octets in the count to be hidden in these > three lines. > > - How useful would this information be? Just one example: capacity planning with a MPLS core, when you want to know exactly what has been sent and not only the IP part of the packet. > How would the collector > know that the MPLS labels are included in the count? Counted by default. > > - Even if the collector knows that MPLS labels are included in the > count, it would not be able to just subtract them for calculating > the pure IP octet number, because it does not necessarily known > how many labels are on the label stack. If you really want to do it, you can export the number of labels as a different I.E. > > - Which information elements should a device use that supports MPLS > but is able to calculate the precise IP octet count, for example > at the end of the MPLS tunnel where both counts (with and without > labels) are available? Instead of defining another information > element for this case, I would rather define a new one for the > IP+MPLS octet counter. Defining a new set of counters might prove to be the only remaining solution. I would keep the I.E. #1 (octetDeltaCount) for IP + MPLS, as this is what NetFlow version 9 does now. > > - The definition of data link header and trailer is vague. > Do we have a reference defining these terms? > Without such a definition, Some people may consider MPLS > as a data link layer protocol particularly since this is > correct for some applications of GMPLS. > > - I am not sure which other technologies besides MPLS would potentially > include octets in the stream that do not belong to IP but are counted > by this counter. ISL, dot1q Regards, Benoit. > > Best regards, > > Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon May 9 07:02:42 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28166 for ; Mon, 9 May 2005 07:02:37 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DV5wH-00048p-00 for ipfix-list@mil.doit.wisc.edu; Mon, 09 May 2005 05:56:41 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DV5wG-00048k-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 09 May 2005 05:56:40 -0500 Received: from [192.168.0.112] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id EEC651BACA1; Mon, 9 May 2005 12:56:38 +0200 (CEST) Date: Mon, 09 May 2005 12:56:07 +0200 From: Juergen Quittek To: Benoit Claise Cc: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] One correction in the "octets" information elements Message-ID: <734945E7C5440C3DB70E6368@753F3B888A9969457862729D> In-Reply-To: <427F27E7.4070604@cisco.com> References: <427881C3.90200@cisco.com> <427F27E7.4070604@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit --On 5/9/2005 11:05 AM +0200 Benoit Claise wrote: > Juergen, > >> Hi Benoit, >> >> --On 5/4/2005 10:03 AM +0200 Benoit Claise wrote: >> >>> Juergen, >>> >>> We realized that the Information Element #1 octetDeltaCount, >>> which is in line with NetFlow version 9, is not correctly specified. >>> >>> 5.9.1 octetDeltaCount >>> Description: >>> The number of octets since the previous report (if any) in >>> incoming packets for this flow at the Observation Point. The >>> number of octets include IP header(s) and IP payload. >>> >>> -> New Description: >>> The number of octets since the previous report (if any) in >>> incoming packets for this flow at the Observation Point. The >>> number of octets exclude the data link header and trailer. >>> >>> This allows to account for the length of MPLS labels, for the ISL >>> bytes, etc... >> >> >> I see the following problems with this change. >> >> - This implies that we count more than just the IP packet. >> Since this is counter is fundamental for IPFIX, we would need >> to discuss precisely what is measured. I do not like the >> inclusion of non-IP octets in the count to be hidden in these >> three lines. >> >> - How useful would this information be? > > Just one example: capacity planning with a MPLS core, when you want to know exactly what has been sent and not only the IP part of the packet. > >> How would the collector >> know that the MPLS labels are included in the count? > > Counted by default. > >> >> - Even if the collector knows that MPLS labels are included in the >> count, it would not be able to just subtract them for calculating >> the pure IP octet number, because it does not necessarily known >> how many labels are on the label stack. > > If you really want to do it, you can export the number of labels as a different I.E. > >> >> - Which information elements should a device use that supports MPLS >> but is able to calculate the precise IP octet count, for example >> at the end of the MPLS tunnel where both counts (with and without >> labels) are available? Instead of defining another information >> element for this case, I would rather define a new one for the >> IP+MPLS octet counter. > > Defining a new set of counters might prove to be the only remaining solution. > I would keep the I.E. #1 (octetDeltaCount) for IP + MPLS, as this is what NetFlow version 9 does now. What about renaming #1 to subIpOctetDeltaCount and introducing a new one for pure IP that will then inherit the name octetDeltaCount? (Sub-IP was the name of the IETF area that dealt with MPLS.) We probably would have to do this for all counters of octets in packets, i.e. postOctetDeltaCount #23, octetTotalCount #85, postMulticastOctetCount #20, postOctetTotalCount #160, droppedOctetDeltaCount #132, droppedOctetTotalCount #134. Cheers, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de >> >> - The definition of data link header and trailer is vague. >> Do we have a reference defining these terms? >> Without such a definition, Some people may consider MPLS >> as a data link layer protocol particularly since this is >> correct for some applications of GMPLS. >> >> - I am not sure which other technologies besides MPLS would potentially >> include octets in the stream that do not belong to IP but are counted >> by this counter. > > ISL, dot1q > > Regards, Benoit. > >> >> Best regards, >> >> Juergen > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon May 9 07:15:34 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29284 for ; Mon, 9 May 2005 07:15:33 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DV6A9-0004PC-00 for ipfix-list@mil.doit.wisc.edu; Mon, 09 May 2005 06:11:01 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DV6A8-0004P1-00 for ipfix-info@net.doit.wisc.edu; Mon, 09 May 2005 06:11:00 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j49BAxd15151; Mon, 9 May 2005 07:10:59 -0400 (EDT) Received: from [10.61.65.196] (ams-clip-vpn-dhcp452.cisco.com [10.61.65.196]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j49BAgK01003; Mon, 9 May 2005 13:10:43 +0200 (CEST) Message-ID: <427F4532.8050202@cisco.com> Date: Mon, 09 May 2005 13:10:42 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny McPherson CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] BGP related Information Elements References: <426E5295.8080602@cisco.com> <7ab543168fd86ef01096ded6d744219f@tcb.net> <4278D8B1.2030003@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Danny and all, In order to continue the discussion with a clear basis, here is the list of proposed BGP-related I.E.s. I've been trying to insert all suggestions. This should answer some of your questions below. Feel free to review and to propose some new text if some improvements are required. | 16 | bgpSourceAsNumber | 17 | bgpDestinationAsNumber | 18 | bgpNextHopIpV4Address | 63 | bgpNextHopIpV6Address | 128 | bgpNextHopAsNumber | 129 | ipNextHopAsNumber 5.4.4 bgpSourceAsNumber Description: The autonomous system (AS) number of the source address in the IP packet headers of this flow. In case of AS-SET, the value of 0 is reported. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 16 Status: current Reference: See RFC 1771 for a description of BGP-4. 5.4.5 bgpDestinationAsNumber Description: The autonomous system (AS) number of the destination address in the IP packet headers this flow. In case of AS-SET, the value of 0 is reported. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 17 Status: current Reference: See RFC 1771 for a description of BGP-4. 5.4.7 bgpNextHopIpV4Address Description: The IPv4 address of the next BGP hop to which packets of this flow are forwarded. Abstract Data Type: ipv4Address Data Type Semantics: identifier ElementId: 18 Status: current Reference: See RFC 1771 for a description of BGP-4. 5.4.8 bgpNextHopIpV6Address Description: The IPv6 address of the next BGP hop to which packets of this flow are forwarded. Abstract Data Type: ipv6Address Data Type Semantics: identifier ElementId: 63 Status: current Reference: See RFC 1771 for a description of BGP-4. 5.4.6 bgpDstAdjacentASNumber Description: The autonomous system (AS) number of the first AS in the AS path to which packets of this flow are forwarded, deduced by looking up the source IP address of the flow in the BGP routing information base. In case of AS-SET, the value of 0 is reported. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 128 Status: current Reference: See RFC 1771 for a description of BGP-4. 5.4.6 bgpSrcAdjacentASNumber Description: The autonomous system (AS) number of the last AS in the AS path from which packets of this flow arrived, deduced by looking up the source IP address of the flow in the BGP routing information base. In case of BGP asymmetry, the bgpSrcAdjacentASNumber might not be able to report the correct value. In case of AS-SET, the value of 0 is reported. Data Type Semantics: identifier ElementId: 129 Status: current Reference: See RFC 1771 for a description of BGP-4. See inline. > > On May 4, 2005, at 8:14 AM, Benoit Claise wrote: > >> I think we have a technical problem right now in IPFIX. We can't >> report an AS_SET. How can we report that the bgpDstAdjacentASNumber >> is not a single unsigned16, but list of unsigned16? This is not >> possible! > > > Right.. > >> So a quick and dirty solution... why not say: export 0 for AS_SET. >> Anyway, reporting the AS_SET is not that useful on the collector. If >> AS_SET = (100, 200, 300), it means that most specific routes of this >> aggregate prefix comes from either 100, either 200, either 300. > > > This would have to apply uniformly across all these elements, as > any of these could return AS_SET: > > 16 bgpSourceAsNumber > 17 bgpDestinationAsNumber > 128 bgpNextAdjacentAsNumber > 129 bgpPreviousAdjacentAsNumber > 149 ipNextHopAsNumber > > I would suspect that 16, 17 and 149 would very frequently > reside within the local AS BTW, typo 149 -> 129. I don't see how the local AS would be reported with the definitions of 16/17. The definition of 129 has been changed. I guess it's ok now. > - which would most intuitively be > represented by '0', I think.. For that matter, any of these > could return local AS (or is it no_adjacent_AS? :-) > > Given my admittedly terse review of the draft, I don't see > behavior defined for where these values should be derived, > and in particular, how local AS (or no AS?) should be > reported. Do you envision local AS being reported as a > function of the router knowing what AS the local BGP process > resides in? Else that local AS value isn't added to the path > until advertised to an eBGP peer. > > I'd be a bit cautious about using '0', and perhaps specify > that local AS (and no AS) always return '0'. This would > align with the BGP Spec: > > [snip from BGP spec] > When a BGP speaker originates a route then: > > a) the originating speaker includes its own AS number in a path > segment of type AS_SEQUENCE in the AS_PATH attribute of all UPDATE > messages sent to an external peer. (In this case, the AS number of > the originating speaker's autonomous system will be the only entry > the path segment, and this path segment will be the only segment > in the AS_PATH attribute). > > b) the originating speaker includes an empty AS_PATH attribute in > all UPDATE messages sent to internal peers. (An empty AS_PATH > attribute is one whose length field contains the value zero). > > [/snip] > > So given b) above, returning zero for local AS wold seem intuitive. > > As for accommodating AS_SET, I'm not quite sure. Would it be > unreasonable to report multiple elements of the same type here if > an AS_SET is returned, or is this a bad idea (I expect so)? > One solution could be to specify multiple new AS-SET related I.E., such mplsLabelStackEntryX in MPLS. My personal view is that (in order to finish this IPFIX work who has been lasting to long IMHO ;)), we should post the draft with the I.E.s we require right now, and use the IANA procedure for any other I.E.s. Otherwise, I fear the job will never be finished. > > To further complicate things, I suspect we'll be seeing > this in deployments within a couple years, per AS number > depletion: > > http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-09.txt > > I'm not sure if we want to worry about it now or define > new elements down the road.. > > Regarding 149, ipNextHopAsNumber: > > ----- > 5.6.3 ipNextHopAsNumber > Description: > The autonomous system (AS) number of the next IP hop to which > packets of this flow are forwarded. > > Abstract Data Type: unsigned16 > > Data Type Semantics: identifier > > ElementId: 149 > > Status: current > Reference: See RFC 1771 for a description of BGP-4 and see RFC 1930 a > definition of the AS number. > ----- > > Is this element returning the AS number for the IP address reported > in the BGP NEXT_HOP attribute associated with the destination prefix, > or it the RIB/FIB IP "next hop" used to reach that destination? This > should be stated explicitly. I hope the new definition above is OK now. Regards, Benoit. > >>> >>> Note the "Previous" in the name above. Also, should you say >>> something about >>> source and destination prefixes here and above, it might help >>> implementers, per >>> this would be a "first" or "leftmost" AS segment in the AS_PATH for >>> the source >>> IP prefix in the BGP Loc-RIB that contains the source IP prefix, >>> while above it's >>> the destination prefix, etc.. >> >> >> Any proposal? > > > Not sure if these are any better, but: > > 5.4.4 bgpSourceAsNumber > Description: > The first (origin) autonomous system (AS) number for the > prefix containing the source address in the IP packet header > in a packet of this flow. > > 5.4.5 bgpDestinationAsNumber > Description: > The first (origin) autonomous system (AS) number for the > prefix containing the destination address in the IP packet > header in a packet of this flow. > > > And I'd still like to see similar information elements added for > AS_CONFED_SET & AS_CONFED_SEQUENCE. As expressed above, if you require them, make a proposal. Regards, Benoit. > > -danny -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From UllaRucker1808@fwdougherty.com Mon May 9 10:51:27 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21535 for ; Mon, 9 May 2005 10:51:27 -0400 (EDT) Received: from [200.90.80.197] (helo=fwdougherty.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DV9T6-0004Nr-00 for ipfix-list@mil.doit.wisc.edu; Mon, 09 May 2005 09:42:48 -0500 From: "Ulla Rucker" To: "Bernd Howard" Subject: =?iso-8859-1?Q?VA11=ECUM_C=ECALLIS_ViAGRR=C1?= Date: Mon, 9 May 2005 10:42:42 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C55D8F.427F76E2" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C55D8F.427F76E2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Farrell, said the officer. should have been false to his parole. And when presently Don Die Fiendish, his lordship agreed. Devil's work. Again you misapprehend me, cried Lord Julian, between concern a the patient's pulse. Firm and regular, he announced at last, a which they should remember. He would take a leaf out of the book Nor were the losses already detailed the full total of those suff She had gone off with this fellow Levasseur, and... and Peter of the court. It was all so grotesque, such a mockery of justice A moment they stood looking into each other's eyes. and strode out. It is Lord Gildoy, he panted. He is sore wounded ... at He took you prisoner, did he - along with Miss Bishop there? Have a nice day. ------=_NextPart_000_0008_01C55D8F.427F76E2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hello, How would you like to = save on your p=EDlIs?
 
VALL=EDUM ClAL=EDS Vl=C0GRA and = many other.
 
Save over 70% with Medications-By-Mail SHOP.
 
Have a nice day.
 
 
 
 
Farrell, said the
officer. = should have been false to his parole. And when presently Don
Die = Fiendish, his lordship agreed. Devil's
work. = Again you misapprehend me, cried Lord Julian, between concern
a = the patient's pulse. Firm and regular, he announced at last,
a = which they should remember. He would take a leaf out of the
book = Nor were the losses already detailed the full total of those
suff = She had gone off with this fellow Levasseur, and... and
Peter = of the court. It was all so grotesque, such a mockery of
justice = A moment they stood looking into each other's
eyes. = and strode
out. = It is Lord Gildoy, he panted. He is sore wounded ...
at = He took you prisoner, did he - along with Miss Bishop
there? =
------=_NextPart_000_0008_01C55D8F.427F76E2-- From majordomo@mil.doit.wisc.edu Mon May 9 14:57:19 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19122 for ; Mon, 9 May 2005 14:57:19 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DVD94-0001Cp-00 for ipfix-list@mil.doit.wisc.edu; Mon, 09 May 2005 13:38:22 -0500 Received: from mrout3.yahoo.com ([216.145.54.173]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DVD93-0001Ck-00 for ipfix-info@net.doit.wisc.edu; Mon, 09 May 2005 13:38:21 -0500 Received: from [66.228.162.78] (snapdragon.corp.yahoo.com [66.228.162.78]) by mrout3.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j49ISXl2085645; Mon, 9 May 2005 11:28:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:x-accept-language: mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=dtGGpUx/cJ7CgFvpmCWyBMJh8cKN3KcOSI4UvJkatqWF9N4lgXtGVogwob+9O85b Message-ID: <427FABD1.4010605@yahoo-inc.com> Date: Mon, 09 May 2005 11:28:33 -0700 From: Eric Ji User-Agent: Mozilla Thunderbird 0.9 (X11/20041116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: Danny McPherson , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] BGP related Information Elements References: <426E5295.8080602@cisco.com> <7ab543168fd86ef01096ded6d744219f@tcb.net> <4278D8B1.2030003@cisco.com> <427F4532.8050202@cisco.com> In-Reply-To: <427F4532.8050202@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit, Nice work. I'd propose to remove bgpSrcAdjacentASNumber. It's not uncommon that BGP asymmetry happens a lot in real world, and this element may cause problem in real use for applications built on, if it reports wrong information. And there's no easy way to verify that inside IPFIX itself. Regards, Eric Benoit Claise wrote: > Danny and all, > > In order to continue the discussion with a clear basis, here is the list > of proposed BGP-related I.E.s. I've been trying to insert all suggestions. > This should answer some of your questions below. > Feel free to review and to propose some new text if some improvements > are required. > > | 16 | bgpSourceAsNumber | 17 | > bgpDestinationAsNumber > | 18 | bgpNextHopIpV4Address > | 63 | bgpNextHopIpV6Address > | 128 | bgpNextHopAsNumber > | 129 | ipNextHopAsNumber > > 5.4.4 bgpSourceAsNumber > Description: > The autonomous system (AS) number of the source address in the IP > packet headers of this flow. In case of AS-SET, the value of 0 > is reported. > > Abstract Data Type: unsigned16 > > Data Type Semantics: identifier > > ElementId: 16 > > Status: current > Reference: See RFC 1771 for a description of BGP-4. > > > 5.4.5 bgpDestinationAsNumber > Description: > The autonomous system (AS) number of the destination address in > the IP packet headers this flow. In case of AS-SET, the value > of 0 is reported. > > Abstract Data Type: unsigned16 > > Data Type Semantics: identifier > > ElementId: 17 > > Status: current > Reference: See RFC 1771 for a description of BGP-4. > > > 5.4.7 bgpNextHopIpV4Address > Description: > The IPv4 address of the next BGP hop to which packets of this flow > are forwarded. > > Abstract Data Type: ipv4Address > > Data Type Semantics: identifier > > ElementId: 18 > > Status: current > Reference: See RFC 1771 for a description of BGP-4. > > > 5.4.8 bgpNextHopIpV6Address > Description: > The IPv6 address of the next BGP hop to which packets of this flow > are forwarded. > > Abstract Data Type: ipv6Address > > Data Type Semantics: identifier > > ElementId: 63 > > Status: current > Reference: See RFC 1771 for a description of BGP-4. > > 5.4.6 bgpDstAdjacentASNumber > Description: > The autonomous system (AS) number of the first AS in the AS path to > which packets of this flow are forwarded, deduced by looking up the > source IP address of the flow in the BGP routing information base. In > case of AS-SET, the value of 0 is reported. > > Abstract Data Type: unsigned16 > > Data Type Semantics: identifier > > ElementId: 128 > > Status: current > > Reference: See RFC 1771 for a description of BGP-4. > > 5.4.6 bgpSrcAdjacentASNumber > > Description: > The autonomous system (AS) number of the last AS in the AS path from > which packets of this flow arrived, deduced by looking up the source IP > address of the flow in the BGP routing information base. In case of BGP > asymmetry, the bgpSrcAdjacentASNumber might not be able to report the > correct value. In case of AS-SET, the value of 0 is reported. > > Data Type Semantics: identifier > > ElementId: 129 > > Status: current > > Reference: See RFC 1771 for a description of BGP-4. > > > > See inline. > >> >> On May 4, 2005, at 8:14 AM, Benoit Claise wrote: >> >>> I think we have a technical problem right now in IPFIX. We can't >>> report an AS_SET. How can we report that the bgpDstAdjacentASNumber >>> is not a single unsigned16, but list of unsigned16? This is not >>> possible! >> >> >> >> Right.. >> >>> So a quick and dirty solution... why not say: export 0 for AS_SET. >>> Anyway, reporting the AS_SET is not that useful on the collector. If >>> AS_SET = (100, 200, 300), it means that most specific routes of this >>> aggregate prefix comes from either 100, either 200, either 300. >> >> >> >> This would have to apply uniformly across all these elements, as >> any of these could return AS_SET: >> >> 16 bgpSourceAsNumber >> 17 bgpDestinationAsNumber >> 128 bgpNextAdjacentAsNumber >> 129 bgpPreviousAdjacentAsNumber >> 149 ipNextHopAsNumber >> >> I would suspect that 16, 17 and 149 would very frequently >> reside within the local AS > > > BTW, typo 149 -> 129. > I don't see how the local AS would be reported with the definitions of > 16/17. > The definition of 129 has been changed. I guess it's ok now. > >> - which would most intuitively be >> represented by '0', I think.. For that matter, any of these >> could return local AS (or is it no_adjacent_AS? :-) >> >> Given my admittedly terse review of the draft, I don't see >> behavior defined for where these values should be derived, >> and in particular, how local AS (or no AS?) should be >> reported. Do you envision local AS being reported as a >> function of the router knowing what AS the local BGP process >> resides in? Else that local AS value isn't added to the path >> until advertised to an eBGP peer. >> >> I'd be a bit cautious about using '0', and perhaps specify >> that local AS (and no AS) always return '0'. This would >> align with the BGP Spec: >> >> [snip from BGP spec] >> When a BGP speaker originates a route then: >> >> a) the originating speaker includes its own AS number in a path >> segment of type AS_SEQUENCE in the AS_PATH attribute of all UPDATE >> messages sent to an external peer. (In this case, the AS number of >> the originating speaker's autonomous system will be the only entry >> the path segment, and this path segment will be the only segment >> in the AS_PATH attribute). >> >> b) the originating speaker includes an empty AS_PATH attribute in >> all UPDATE messages sent to internal peers. (An empty AS_PATH >> attribute is one whose length field contains the value zero). >> >> [/snip] >> >> So given b) above, returning zero for local AS wold seem intuitive. >> >> As for accommodating AS_SET, I'm not quite sure. Would it be >> unreasonable to report multiple elements of the same type here if >> an AS_SET is returned, or is this a bad idea (I expect so)? >> > One solution could be to specify multiple new AS-SET related I.E., such > mplsLabelStackEntryX in MPLS. > > My personal view is that (in order to finish this IPFIX work who has > been lasting to long IMHO ;)), we should post the draft with the I.E.s > we require right now, and use the IANA procedure for any other I.E.s. > Otherwise, I fear the job will never be finished. > >> >> To further complicate things, I suspect we'll be seeing >> this in deployments within a couple years, per AS number >> depletion: >> >> http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-09.txt >> >> I'm not sure if we want to worry about it now or define >> new elements down the road.. >> >> Regarding 149, ipNextHopAsNumber: >> >> ----- >> 5.6.3 ipNextHopAsNumber >> Description: >> The autonomous system (AS) number of the next IP hop to which >> packets of this flow are forwarded. >> >> Abstract Data Type: unsigned16 >> >> Data Type Semantics: identifier >> >> ElementId: 149 >> >> Status: current >> Reference: See RFC 1771 for a description of BGP-4 and see RFC 1930 a >> definition of the AS number. >> ----- >> >> Is this element returning the AS number for the IP address reported >> in the BGP NEXT_HOP attribute associated with the destination prefix, >> or it the RIB/FIB IP "next hop" used to reach that destination? This >> should be stated explicitly. > > > I hope the new definition above is OK now. > > Regards, Benoit. > >> >>>> >>>> Note the "Previous" in the name above. Also, should you say >>>> something about >>>> source and destination prefixes here and above, it might help >>>> implementers, per >>>> this would be a "first" or "leftmost" AS segment in the AS_PATH for >>>> the source >>>> IP prefix in the BGP Loc-RIB that contains the source IP prefix, >>>> while above it's >>>> the destination prefix, etc.. >>> >>> >>> >>> Any proposal? >> >> >> >> Not sure if these are any better, but: >> >> 5.4.4 bgpSourceAsNumber >> Description: >> The first (origin) autonomous system (AS) number for the >> prefix containing the source address in the IP packet header >> in a packet of this flow. >> >> 5.4.5 bgpDestinationAsNumber >> Description: >> The first (origin) autonomous system (AS) number for the >> prefix containing the destination address in the IP packet >> header in a packet of this flow. >> >> >> And I'd still like to see similar information elements added for >> AS_CONFED_SET & AS_CONFED_SEQUENCE. > > > As expressed above, if you require them, make a proposal. > > Regards, Benoit. > >> >> -danny > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon May 9 15:43:57 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25116 for ; Mon, 9 May 2005 15:43:57 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DVE2h-0003bo-00 for ipfix-list@mil.doit.wisc.edu; Mon, 09 May 2005 14:35:51 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DVE2g-0003b0-00 for ipfix-info@net.doit.wisc.edu; Mon, 09 May 2005 14:35:50 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j49JZnA21635; Mon, 9 May 2005 15:35:49 -0400 (EDT) Received: from [10.61.65.196] (ams-clip-vpn-dhcp452.cisco.com [10.61.65.196]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j49JZlK20106; Mon, 9 May 2005 21:35:47 +0200 (CEST) Message-ID: <427FBB91.6000502@cisco.com> Date: Mon, 09 May 2005 21:35:45 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Ji CC: Danny McPherson , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] BGP related Information Elements References: <426E5295.8080602@cisco.com> <7ab543168fd86ef01096ded6d744219f@tcb.net> <4278D8B1.2030003@cisco.com> <427F4532.8050202@cisco.com> <427FABD1.4010605@yahoo-inc.com> In-Reply-To: <427FABD1.4010605@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Eric, > > Nice work. I'd propose to remove bgpSrcAdjacentASNumber. It's not > uncommon that BGP asymmetry happens a lot in real world, and this > element may cause problem in real use for applications built on, if it > reports wrong information. And there's no easy way to verify that > inside IPFIX itself. I share with your concern. However, I propose to keep this I.E.s for 2 reasons. 1. This BGP asymmetry and peer source AS / asymmetry issue is not new: we do already export this value in NetFlow version 9 today. 2. you will have a wrong value for bgpSrcAdjacentASNumber only in the case of multi-access interfaces (typically an ethernet interface at an IXP). In other interface types, you would be able to deduce if the value is correct or not, i.e. if there is some asymmetry Regards, Benoit. > > Regards, > Eric > > > Benoit Claise wrote: > >> Danny and all, >> >> In order to continue the discussion with a clear basis, here is the >> list of proposed BGP-related I.E.s. I've been trying to insert all >> suggestions. >> This should answer some of your questions below. >> Feel free to review and to propose some new text if some improvements >> are required. >> >> | 16 | bgpSourceAsNumber | 17 | >> bgpDestinationAsNumber >> | 18 | bgpNextHopIpV4Address >> | 63 | bgpNextHopIpV6Address >> | 128 | bgpNextHopAsNumber >> | 129 | ipNextHopAsNumber >> >> 5.4.4 bgpSourceAsNumber >> Description: >> The autonomous system (AS) number of the source address in the IP >> packet headers of this flow. In case of AS-SET, the value >> of 0 is reported. >> >> Abstract Data Type: unsigned16 >> >> Data Type Semantics: identifier >> >> ElementId: 16 >> >> Status: current >> Reference: See RFC 1771 for a description of BGP-4. >> >> >> 5.4.5 bgpDestinationAsNumber >> Description: >> The autonomous system (AS) number of the destination address in >> the IP packet headers this flow. In case of AS-SET, the >> value of 0 is reported. >> >> Abstract Data Type: unsigned16 >> >> Data Type Semantics: identifier >> >> ElementId: 17 >> >> Status: current >> Reference: See RFC 1771 for a description of BGP-4. >> >> >> 5.4.7 bgpNextHopIpV4Address >> Description: >> The IPv4 address of the next BGP hop to which packets of this flow >> are forwarded. >> >> Abstract Data Type: ipv4Address >> >> Data Type Semantics: identifier >> >> ElementId: 18 >> >> Status: current >> Reference: See RFC 1771 for a description of BGP-4. >> >> >> 5.4.8 bgpNextHopIpV6Address >> Description: >> The IPv6 address of the next BGP hop to which packets of this flow >> are forwarded. >> >> Abstract Data Type: ipv6Address >> >> Data Type Semantics: identifier >> >> ElementId: 63 >> >> Status: current >> Reference: See RFC 1771 for a description of BGP-4. >> 5.4.6 bgpDstAdjacentASNumber >> Description: >> The autonomous system (AS) number of the first AS in the AS path to >> which packets of this flow are forwarded, deduced by looking up the >> source IP address of the flow in the BGP routing information base. In >> case of AS-SET, the value of 0 is reported. >> >> Abstract Data Type: unsigned16 >> >> Data Type Semantics: identifier >> >> ElementId: 128 >> >> Status: current >> >> Reference: See RFC 1771 for a description of BGP-4. >> >> 5.4.6 bgpSrcAdjacentASNumber >> >> Description: >> The autonomous system (AS) number of the last AS in the AS path >> from which packets of this flow arrived, deduced by looking up the >> source IP address of the flow in the BGP routing information base. In >> case of BGP asymmetry, the bgpSrcAdjacentASNumber might not be able >> to report the correct value. In case of AS-SET, the value of 0 is >> reported. >> >> Data Type Semantics: identifier >> >> ElementId: 129 >> >> Status: current >> >> Reference: See RFC 1771 for a description of BGP-4. >> >> >> >> See inline. >> >>> >>> On May 4, 2005, at 8:14 AM, Benoit Claise wrote: >>> >>>> I think we have a technical problem right now in IPFIX. We can't >>>> report an AS_SET. How can we report that the bgpDstAdjacentASNumber >>>> is not a single unsigned16, but list of unsigned16? This is not >>>> possible! >>> >>> >>> >>> >>> Right.. >>> >>>> So a quick and dirty solution... why not say: export 0 for AS_SET. >>>> Anyway, reporting the AS_SET is not that useful on the collector. >>>> If AS_SET = (100, 200, 300), it means that most specific routes of >>>> this aggregate prefix comes from either 100, either 200, either 300. >>> >>> >>> >>> >>> This would have to apply uniformly across all these elements, as >>> any of these could return AS_SET: >>> >>> 16 bgpSourceAsNumber >>> 17 bgpDestinationAsNumber >>> 128 bgpNextAdjacentAsNumber >>> 129 bgpPreviousAdjacentAsNumber >>> 149 ipNextHopAsNumber >>> >>> I would suspect that 16, 17 and 149 would very frequently >>> reside within the local AS >> >> >> >> BTW, typo 149 -> 129. >> I don't see how the local AS would be reported with the definitions >> of 16/17. >> The definition of 129 has been changed. I guess it's ok now. >> >>> - which would most intuitively be >>> represented by '0', I think.. For that matter, any of these >>> could return local AS (or is it no_adjacent_AS? :-) >>> >>> Given my admittedly terse review of the draft, I don't see >>> behavior defined for where these values should be derived, >>> and in particular, how local AS (or no AS?) should be >>> reported. Do you envision local AS being reported as a >>> function of the router knowing what AS the local BGP process >>> resides in? Else that local AS value isn't added to the path >>> until advertised to an eBGP peer. >>> >>> I'd be a bit cautious about using '0', and perhaps specify >>> that local AS (and no AS) always return '0'. This would >>> align with the BGP Spec: >>> >>> [snip from BGP spec] >>> When a BGP speaker originates a route then: >>> >>> a) the originating speaker includes its own AS number in a path >>> segment of type AS_SEQUENCE in the AS_PATH attribute of all UPDATE >>> messages sent to an external peer. (In this case, the AS number of >>> the originating speaker's autonomous system will be the only entry >>> the path segment, and this path segment will be the only segment >>> in the AS_PATH attribute). >>> >>> b) the originating speaker includes an empty AS_PATH attribute in >>> all UPDATE messages sent to internal peers. (An empty AS_PATH >>> attribute is one whose length field contains the value zero). >>> >>> [/snip] >>> >>> So given b) above, returning zero for local AS wold seem intuitive. >>> >>> As for accommodating AS_SET, I'm not quite sure. Would it be >>> unreasonable to report multiple elements of the same type here if >>> an AS_SET is returned, or is this a bad idea (I expect so)? >>> >> One solution could be to specify multiple new AS-SET related I.E., >> such mplsLabelStackEntryX in MPLS. >> >> My personal view is that (in order to finish this IPFIX work who has >> been lasting to long IMHO ;)), we should post the draft with the >> I.E.s we require right now, and use the IANA procedure for any other >> I.E.s. Otherwise, I fear the job will never be finished. >> >>> >>> To further complicate things, I suspect we'll be seeing >>> this in deployments within a couple years, per AS number >>> depletion: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-09.txt >>> >>> I'm not sure if we want to worry about it now or define >>> new elements down the road.. >>> >>> Regarding 149, ipNextHopAsNumber: >>> >>> ----- >>> 5.6.3 ipNextHopAsNumber >>> Description: >>> The autonomous system (AS) number of the next IP hop to which >>> packets of this flow are forwarded. >>> >>> Abstract Data Type: unsigned16 >>> >>> Data Type Semantics: identifier >>> >>> ElementId: 149 >>> >>> Status: current >>> Reference: See RFC 1771 for a description of BGP-4 and see RFC >>> 1930 a >>> definition of the AS number. >>> ----- >>> >>> Is this element returning the AS number for the IP address reported >>> in the BGP NEXT_HOP attribute associated with the destination prefix, >>> or it the RIB/FIB IP "next hop" used to reach that destination? This >>> should be stated explicitly. >> >> >> >> I hope the new definition above is OK now. >> >> Regards, Benoit. >> >>> >>>>> >>>>> Note the "Previous" in the name above. Also, should you say >>>>> something about >>>>> source and destination prefixes here and above, it might help >>>>> implementers, per >>>>> this would be a "first" or "leftmost" AS segment in the AS_PATH >>>>> for the source >>>>> IP prefix in the BGP Loc-RIB that contains the source IP prefix, >>>>> while above it's >>>>> the destination prefix, etc.. >>>> >>>> >>>> >>>> >>>> Any proposal? >>> >>> >>> >>> >>> Not sure if these are any better, but: >>> >>> 5.4.4 bgpSourceAsNumber >>> Description: >>> The first (origin) autonomous system (AS) number for the >>> prefix containing the source address in the IP packet header >>> in a packet of this flow. >>> >>> 5.4.5 bgpDestinationAsNumber >>> Description: >>> The first (origin) autonomous system (AS) number for the >>> prefix containing the destination address in the IP packet >>> header in a packet of this flow. >>> >>> >>> And I'd still like to see similar information elements added for >>> AS_CONFED_SET & AS_CONFED_SEQUENCE. >> >> >> >> As expressed above, if you require them, make a proposal. >> >> Regards, Benoit. >> >>> >>> -danny >> >> >> >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Wern@josho.com Tue May 10 11:36:19 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06660 for ; Tue, 10 May 2005 11:36:19 -0400 (EDT) Received: from p508a1877.dip0.t-ipconnect.de ([80.138.24.119] helo=josho.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DVWHj-00019c-00 for ipfix-list@mil.doit.wisc.edu; Tue, 10 May 2005 10:04:36 -0500 From: "Wojtek Werner" To: "Vreni Ennis" Subject: =?iso-8859-1?Q?C=ECALLlS_V=C1LIUM_Vl=C0GRRA?= Date: Tue, 10 May 2005 11:04:31 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C56E3B.4280CD7F" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (dnsbl.njabl.org) Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C56E3B.4280CD7F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, precipitate an explosion of hatred from which no human power coul So that ye can be charitable in some ways! He laughed softly. Captain Blood thrust a parchment under Calverley's bulging eyes. darkness came gliding from the wharf, with well-greased rowlocks, Seeing him thus, and perceiving his real nature, which was plain them. Came the creak of blocks and the rattle of slatting sails his blue eyes. Atropos, and Captain Yberville of the Lachesis. His excellency changed colour. He sat quite still, staring at th The end of it all was that he gave a promise at once to make the station on the main deck. continue as a curb upon these Spanish scoundrels. Have a nice day. ------=_NextPart_000_0008_01C56E3B.4280CD7F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hello, How WouId you Iike to = save on your p=EDlIs?
 
Vl=C0GRA V=E0LL1UM C1=C0LlSS and = many other.
 
Save over 70% with PharmacyByMMail STORE.
 
Have a nice day.
 
 
 
 
precipitate an explosion of hatred from which no human power
coul = So that ye can be charitable in some ways! He laughed
softly. = Captain Blood thrust a parchment under Calverley's bulging
eyes. = darkness came gliding from the wharf, with well-greased
rowlocks, = Seeing him thus, and perceiving his real nature, which was
plain = them. Came the creak of blocks and the rattle of slatting sails
= his blue
eyes. = Atropos, and Captain Yberville of the
Lachesis. = His excellency changed colour. He sat quite still, staring at
th = The end of it all was that he gave a promise at once to make
the = station on the main
deck. = continue as a curb upon these Spanish
scoundrels. =
------=_NextPart_000_0008_01C56E3B.4280CD7F-- From majordomo@mil.doit.wisc.edu Tue May 10 17:54:51 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25218 for ; Tue, 10 May 2005 17:54:51 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DVcW7-0001LS-00 for ipfix-list@mil.doit.wisc.edu; Tue, 10 May 2005 16:43:51 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DVcW6-0001Kc-00 for ipfix-info@net.doit.wisc.edu; Tue, 10 May 2005 16:43:50 -0500 Received: from [66.228.162.78] (snapdragon.corp.yahoo.com [66.228.162.78]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j4ALhWZK049759; Tue, 10 May 2005 14:43:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:x-accept-language: mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=NjoZ383730osTTlJyfv9jOKGZnYcDD632zN8ffjc5+XAB+86PCuJDUoECpB8XN9g Message-ID: <42812B04.8090807@yahoo-inc.com> Date: Tue, 10 May 2005 14:43:32 -0700 From: Eric Ji User-Agent: Mozilla Thunderbird 0.9 (X11/20041116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: Danny McPherson , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] BGP related Information Elements References: <426E5295.8080602@cisco.com> <7ab543168fd86ef01096ded6d744219f@tcb.net> <4278D8B1.2030003@cisco.com> <427F4532.8050202@cisco.com> <427FABD1.4010605@yahoo-inc.com> <427FBB91.6000502@cisco.com> In-Reply-To: <427FBB91.6000502@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit, Now that it's already used, I have no issue with keeping it, given that its limitation is well documented. Another minor points, we may change the following wording, "In case of AS-SET, the value of 0 is reported." to "In case of AS-SET, and can't be easily retrieved from BGP, the value 0 is reported." That leaves space for other ways to get this information now, such as through ebgp neighbor AS for edge routers. And it doesnt close the door for new ways to discover this later on, such as examining the exit point or topology. Regards, Eric Benoit Claise wrote: > Eric, > >> >> Nice work. I'd propose to remove bgpSrcAdjacentASNumber. It's not >> uncommon that BGP asymmetry happens a lot in real world, and this >> element may cause problem in real use for applications built on, if it >> reports wrong information. And there's no easy way to verify that >> inside IPFIX itself. > > > I share with your concern. > However, I propose to keep this I.E.s for 2 reasons. > 1. This BGP asymmetry and peer source AS / asymmetry issue is not new: > we do already export this value in NetFlow version 9 today. > 2. you will have a wrong value for bgpSrcAdjacentASNumber only in the > case of multi-access interfaces (typically an ethernet interface at an > IXP). In other interface types, you would be able to deduce if the value > is correct or not, i.e. if there is some asymmetry > > Regards, Benoit. > >> >> Regards, >> Eric >> >> >> Benoit Claise wrote: >> >>> Danny and all, >>> >>> In order to continue the discussion with a clear basis, here is the >>> list of proposed BGP-related I.E.s. I've been trying to insert all >>> suggestions. >>> This should answer some of your questions below. >>> Feel free to review and to propose some new text if some improvements >>> are required. >>> >>> | 16 | bgpSourceAsNumber | 17 | >>> bgpDestinationAsNumber >>> | 18 | bgpNextHopIpV4Address >>> | 63 | bgpNextHopIpV6Address >>> | 128 | bgpNextHopAsNumber >>> | 129 | ipNextHopAsNumber >>> >>> 5.4.4 bgpSourceAsNumber >>> Description: >>> The autonomous system (AS) number of the source address in the IP >>> packet headers of this flow. In case of AS-SET, the value >>> of 0 is reported. >>> >>> Abstract Data Type: unsigned16 >>> >>> Data Type Semantics: identifier >>> >>> ElementId: 16 >>> >>> Status: current >>> Reference: See RFC 1771 for a description of BGP-4. >>> >>> >>> 5.4.5 bgpDestinationAsNumber >>> Description: >>> The autonomous system (AS) number of the destination address in >>> the IP packet headers this flow. In case of AS-SET, the >>> value of 0 is reported. >>> >>> Abstract Data Type: unsigned16 >>> >>> Data Type Semantics: identifier >>> >>> ElementId: 17 >>> >>> Status: current >>> Reference: See RFC 1771 for a description of BGP-4. >>> >>> >>> 5.4.7 bgpNextHopIpV4Address >>> Description: >>> The IPv4 address of the next BGP hop to which packets of this flow >>> are forwarded. >>> >>> Abstract Data Type: ipv4Address >>> >>> Data Type Semantics: identifier >>> >>> ElementId: 18 >>> >>> Status: current >>> Reference: See RFC 1771 for a description of BGP-4. >>> >>> >>> 5.4.8 bgpNextHopIpV6Address >>> Description: >>> The IPv6 address of the next BGP hop to which packets of this flow >>> are forwarded. >>> >>> Abstract Data Type: ipv6Address >>> >>> Data Type Semantics: identifier >>> >>> ElementId: 63 >>> >>> Status: current >>> Reference: See RFC 1771 for a description of BGP-4. >>> 5.4.6 bgpDstAdjacentASNumber >>> Description: >>> The autonomous system (AS) number of the first AS in the AS path to >>> which packets of this flow are forwarded, deduced by looking up the >>> source IP address of the flow in the BGP routing information base. In >>> case of AS-SET, the value of 0 is reported. >>> >>> Abstract Data Type: unsigned16 >>> >>> Data Type Semantics: identifier >>> >>> ElementId: 128 >>> >>> Status: current >>> >>> Reference: See RFC 1771 for a description of BGP-4. >>> >>> 5.4.6 bgpSrcAdjacentASNumber >>> >>> Description: >>> The autonomous system (AS) number of the last AS in the AS path >>> from which packets of this flow arrived, deduced by looking up the >>> source IP address of the flow in the BGP routing information base. In >>> case of BGP asymmetry, the bgpSrcAdjacentASNumber might not be able >>> to report the correct value. In case of AS-SET, the value of 0 is >>> reported. >>> >>> Data Type Semantics: identifier >>> >>> ElementId: 129 >>> >>> Status: current >>> >>> Reference: See RFC 1771 for a description of BGP-4. >>> >>> >>> >>> See inline. >>> >>>> >>>> On May 4, 2005, at 8:14 AM, Benoit Claise wrote: >>>> >>>>> I think we have a technical problem right now in IPFIX. We can't >>>>> report an AS_SET. How can we report that the bgpDstAdjacentASNumber >>>>> is not a single unsigned16, but list of unsigned16? This is not >>>>> possible! >>>> >>>> >>>> >>>> >>>> >>>> Right.. >>>> >>>>> So a quick and dirty solution... why not say: export 0 for AS_SET. >>>>> Anyway, reporting the AS_SET is not that useful on the collector. >>>>> If AS_SET = (100, 200, 300), it means that most specific routes of >>>>> this aggregate prefix comes from either 100, either 200, either 300. >>>> >>>> >>>> >>>> >>>> >>>> This would have to apply uniformly across all these elements, as >>>> any of these could return AS_SET: >>>> >>>> 16 bgpSourceAsNumber >>>> 17 bgpDestinationAsNumber >>>> 128 bgpNextAdjacentAsNumber >>>> 129 bgpPreviousAdjacentAsNumber >>>> 149 ipNextHopAsNumber >>>> >>>> I would suspect that 16, 17 and 149 would very frequently >>>> reside within the local AS >>> >>> >>> >>> >>> BTW, typo 149 -> 129. >>> I don't see how the local AS would be reported with the definitions >>> of 16/17. >>> The definition of 129 has been changed. I guess it's ok now. >>> >>>> - which would most intuitively be >>>> represented by '0', I think.. For that matter, any of these >>>> could return local AS (or is it no_adjacent_AS? :-) >>>> >>>> Given my admittedly terse review of the draft, I don't see >>>> behavior defined for where these values should be derived, >>>> and in particular, how local AS (or no AS?) should be >>>> reported. Do you envision local AS being reported as a >>>> function of the router knowing what AS the local BGP process >>>> resides in? Else that local AS value isn't added to the path >>>> until advertised to an eBGP peer. >>>> >>>> I'd be a bit cautious about using '0', and perhaps specify >>>> that local AS (and no AS) always return '0'. This would >>>> align with the BGP Spec: >>>> >>>> [snip from BGP spec] >>>> When a BGP speaker originates a route then: >>>> >>>> a) the originating speaker includes its own AS number in a path >>>> segment of type AS_SEQUENCE in the AS_PATH attribute of all UPDATE >>>> messages sent to an external peer. (In this case, the AS number of >>>> the originating speaker's autonomous system will be the only entry >>>> the path segment, and this path segment will be the only segment >>>> in the AS_PATH attribute). >>>> >>>> b) the originating speaker includes an empty AS_PATH attribute in >>>> all UPDATE messages sent to internal peers. (An empty AS_PATH >>>> attribute is one whose length field contains the value zero). >>>> >>>> [/snip] >>>> >>>> So given b) above, returning zero for local AS wold seem intuitive. >>>> >>>> As for accommodating AS_SET, I'm not quite sure. Would it be >>>> unreasonable to report multiple elements of the same type here if >>>> an AS_SET is returned, or is this a bad idea (I expect so)? >>>> >>> One solution could be to specify multiple new AS-SET related I.E., >>> such mplsLabelStackEntryX in MPLS. >>> >>> My personal view is that (in order to finish this IPFIX work who has >>> been lasting to long IMHO ;)), we should post the draft with the >>> I.E.s we require right now, and use the IANA procedure for any other >>> I.E.s. Otherwise, I fear the job will never be finished. >>> >>>> >>>> To further complicate things, I suspect we'll be seeing >>>> this in deployments within a couple years, per AS number >>>> depletion: >>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-09.txt >>>> >>>> I'm not sure if we want to worry about it now or define >>>> new elements down the road.. >>>> >>>> Regarding 149, ipNextHopAsNumber: >>>> >>>> ----- >>>> 5.6.3 ipNextHopAsNumber >>>> Description: >>>> The autonomous system (AS) number of the next IP hop to which >>>> packets of this flow are forwarded. >>>> >>>> Abstract Data Type: unsigned16 >>>> >>>> Data Type Semantics: identifier >>>> >>>> ElementId: 149 >>>> >>>> Status: current >>>> Reference: See RFC 1771 for a description of BGP-4 and see RFC >>>> 1930 a >>>> definition of the AS number. >>>> ----- >>>> >>>> Is this element returning the AS number for the IP address reported >>>> in the BGP NEXT_HOP attribute associated with the destination prefix, >>>> or it the RIB/FIB IP "next hop" used to reach that destination? This >>>> should be stated explicitly. >>> >>> >>> >>> >>> I hope the new definition above is OK now. >>> >>> Regards, Benoit. >>> >>>> >>>>>> >>>>>> Note the "Previous" in the name above. Also, should you say >>>>>> something about >>>>>> source and destination prefixes here and above, it might help >>>>>> implementers, per >>>>>> this would be a "first" or "leftmost" AS segment in the AS_PATH >>>>>> for the source >>>>>> IP prefix in the BGP Loc-RIB that contains the source IP prefix, >>>>>> while above it's >>>>>> the destination prefix, etc.. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Any proposal? >>>> >>>> >>>> >>>> >>>> >>>> Not sure if these are any better, but: >>>> >>>> 5.4.4 bgpSourceAsNumber >>>> Description: >>>> The first (origin) autonomous system (AS) number for the >>>> prefix containing the source address in the IP packet header >>>> in a packet of this flow. >>>> >>>> 5.4.5 bgpDestinationAsNumber >>>> Description: >>>> The first (origin) autonomous system (AS) number for the >>>> prefix containing the destination address in the IP packet >>>> header in a packet of this flow. >>>> >>>> >>>> And I'd still like to see similar information elements added for >>>> AS_CONFED_SET & AS_CONFED_SEQUENCE. >>> >>> >>> >>> >>> As expressed above, if you require them, make a proposal. >>> >>> Regards, Benoit. >>> >>>> >>>> -danny >>> >>> >>> >>> >>> >>> >>> -- >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>> message body >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe ipfix" in message body >>> Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> >>> > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 11 02:51:41 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07159 for ; Wed, 11 May 2005 02:51:41 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DVkjd-0004ak-00 for ipfix-list@mil.doit.wisc.edu; Wed, 11 May 2005 01:30:21 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DVkjc-0004af-00 for ipfix-info@net.doit.wisc.edu; Wed, 11 May 2005 01:30:20 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4B6UJO01645; Wed, 11 May 2005 02:30:19 -0400 (EDT) Received: from [10.61.81.32] (ams-clip-vpn-dhcp4385.cisco.com [10.61.81.32]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4B6UHK26023; Wed, 11 May 2005 08:30:17 +0200 (CEST) Message-ID: <4281A678.8080808@cisco.com> Date: Wed, 11 May 2005 08:30:16 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Ji CC: Danny McPherson , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] BGP related Information Elements References: <426E5295.8080602@cisco.com> <7ab543168fd86ef01096ded6d744219f@tcb.net> <4278D8B1.2030003@cisco.com> <427F4532.8050202@cisco.com> <427FABD1.4010605@yahoo-inc.com> <427FBB91.6000502@cisco.com> <42812B04.8090807@yahoo-inc.com> In-Reply-To: <42812B04.8090807@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Eric, > Benoit, > > Now that it's already used, I have no issue with keeping it, given > that its limitation is well documented. > > Another minor points, we may change the following wording, > "In case of AS-SET, the value of 0 is reported." to > "In case of AS-SET, and can't be easily retrieved from BGP, the value > 0 is reported." > That leaves space for other ways to get this information now, such as > through ebgp neighbor AS for edge routers. And it doesnt close the > door for new ways to discover this later on, such as examining the > exit point or topology. Do you want to say "In case of AS-SET or can't be easily retrieved from BGP, the value 0 is reported."? Because, even with AS-SET, the AS can be easily retrieved. The issue is to export it in IPFIX :) Regards, Benoit. > > Regards, > Eric > > > Benoit Claise wrote: > >> Eric, >> >>> >>> Nice work. I'd propose to remove bgpSrcAdjacentASNumber. It's not >>> uncommon that BGP asymmetry happens a lot in real world, and this >>> element may cause problem in real use for applications built on, if >>> it reports wrong information. And there's no easy way to verify that >>> inside IPFIX itself. >> >> >> >> I share with your concern. >> However, I propose to keep this I.E.s for 2 reasons. >> 1. This BGP asymmetry and peer source AS / asymmetry issue is not >> new: we do already export this value in NetFlow version 9 today. >> 2. you will have a wrong value for bgpSrcAdjacentASNumber only in the >> case of multi-access interfaces (typically an ethernet interface at >> an IXP). In other interface types, you would be able to deduce if the >> value is correct or not, i.e. if there is some asymmetry >> >> Regards, Benoit. >> >>> >>> Regards, >>> Eric >>> >>> >>> Benoit Claise wrote: >>> >>>> Danny and all, >>>> >>>> In order to continue the discussion with a clear basis, here is the >>>> list of proposed BGP-related I.E.s. I've been trying to insert all >>>> suggestions. >>>> This should answer some of your questions below. >>>> Feel free to review and to propose some new text if some >>>> improvements are required. >>>> >>>> | 16 | bgpSourceAsNumber | 17 | >>>> bgpDestinationAsNumber >>>> | 18 | bgpNextHopIpV4Address >>>> | 63 | bgpNextHopIpV6Address >>>> | 128 | bgpNextHopAsNumber >>>> | 129 | ipNextHopAsNumber >>>> >>>> 5.4.4 bgpSourceAsNumber >>>> Description: >>>> The autonomous system (AS) number of the source address in the IP >>>> packet headers of this flow. In case of AS-SET, the value >>>> of 0 is reported. >>>> >>>> Abstract Data Type: unsigned16 >>>> >>>> Data Type Semantics: identifier >>>> >>>> ElementId: 16 >>>> >>>> Status: current >>>> Reference: See RFC 1771 for a description of BGP-4. >>>> >>>> >>>> 5.4.5 bgpDestinationAsNumber >>>> Description: >>>> The autonomous system (AS) number of the destination address in >>>> the IP packet headers this flow. In case of AS-SET, the >>>> value of 0 is reported. >>>> >>>> Abstract Data Type: unsigned16 >>>> >>>> Data Type Semantics: identifier >>>> >>>> ElementId: 17 >>>> >>>> Status: current >>>> Reference: See RFC 1771 for a description of BGP-4. >>>> >>>> >>>> 5.4.7 bgpNextHopIpV4Address >>>> Description: >>>> The IPv4 address of the next BGP hop to which packets of this >>>> flow >>>> are forwarded. >>>> >>>> Abstract Data Type: ipv4Address >>>> >>>> Data Type Semantics: identifier >>>> >>>> ElementId: 18 >>>> >>>> Status: current >>>> Reference: See RFC 1771 for a description of BGP-4. >>>> >>>> >>>> 5.4.8 bgpNextHopIpV6Address >>>> Description: >>>> The IPv6 address of the next BGP hop to which packets of this >>>> flow >>>> are forwarded. >>>> >>>> Abstract Data Type: ipv6Address >>>> >>>> Data Type Semantics: identifier >>>> >>>> ElementId: 63 >>>> >>>> Status: current >>>> Reference: See RFC 1771 for a description of BGP-4. >>>> 5.4.6 bgpDstAdjacentASNumber >>>> Description: >>>> The autonomous system (AS) number of the first AS in the AS path >>>> to which packets of this flow are forwarded, deduced by looking up >>>> the source IP address of the flow in the BGP routing information >>>> base. In case of AS-SET, the value of 0 is reported. >>>> >>>> Abstract Data Type: unsigned16 >>>> >>>> Data Type Semantics: identifier >>>> >>>> ElementId: 128 >>>> >>>> Status: current >>>> >>>> Reference: See RFC 1771 for a description of BGP-4. >>>> >>>> 5.4.6 bgpSrcAdjacentASNumber >>>> >>>> Description: >>>> The autonomous system (AS) number of the last AS in the AS path >>>> from which packets of this flow arrived, deduced by looking up the >>>> source IP address of the flow in the BGP routing information base. >>>> In case of BGP asymmetry, the bgpSrcAdjacentASNumber might not be >>>> able to report the correct value. In case of AS-SET, the value of 0 >>>> is reported. >>>> >>>> Data Type Semantics: identifier >>>> >>>> ElementId: 129 >>>> >>>> Status: current >>>> >>>> Reference: See RFC 1771 for a description of BGP-4. >>>> >>>> >>>> >>>> See inline. >>>> >>>>> >>>>> On May 4, 2005, at 8:14 AM, Benoit Claise wrote: >>>>> >>>>>> I think we have a technical problem right now in IPFIX. We can't >>>>>> report an AS_SET. How can we report that the >>>>>> bgpDstAdjacentASNumber is not a single unsigned16, but list of >>>>>> unsigned16? This is not possible! >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Right.. >>>>> >>>>>> So a quick and dirty solution... why not say: export 0 for AS_SET. >>>>>> Anyway, reporting the AS_SET is not that useful on the collector. >>>>>> If AS_SET = (100, 200, 300), it means that most specific routes >>>>>> of this aggregate prefix comes from either 100, either 200, >>>>>> either 300. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This would have to apply uniformly across all these elements, as >>>>> any of these could return AS_SET: >>>>> >>>>> 16 bgpSourceAsNumber >>>>> 17 bgpDestinationAsNumber >>>>> 128 bgpNextAdjacentAsNumber >>>>> 129 bgpPreviousAdjacentAsNumber >>>>> 149 ipNextHopAsNumber >>>>> >>>>> I would suspect that 16, 17 and 149 would very frequently >>>>> reside within the local AS >>>> >>>> >>>> >>>> >>>> >>>> BTW, typo 149 -> 129. >>>> I don't see how the local AS would be reported with the definitions >>>> of 16/17. >>>> The definition of 129 has been changed. I guess it's ok now. >>>> >>>>> - which would most intuitively be >>>>> represented by '0', I think.. For that matter, any of these >>>>> could return local AS (or is it no_adjacent_AS? :-) >>>>> >>>>> Given my admittedly terse review of the draft, I don't see >>>>> behavior defined for where these values should be derived, >>>>> and in particular, how local AS (or no AS?) should be >>>>> reported. Do you envision local AS being reported as a >>>>> function of the router knowing what AS the local BGP process >>>>> resides in? Else that local AS value isn't added to the path >>>>> until advertised to an eBGP peer. >>>>> >>>>> I'd be a bit cautious about using '0', and perhaps specify >>>>> that local AS (and no AS) always return '0'. This would >>>>> align with the BGP Spec: >>>>> >>>>> [snip from BGP spec] >>>>> When a BGP speaker originates a route then: >>>>> >>>>> a) the originating speaker includes its own AS number in a path >>>>> segment of type AS_SEQUENCE in the AS_PATH attribute of all UPDATE >>>>> messages sent to an external peer. (In this case, the AS number of >>>>> the originating speaker's autonomous system will be the only entry >>>>> the path segment, and this path segment will be the only segment >>>>> in the AS_PATH attribute). >>>>> >>>>> b) the originating speaker includes an empty AS_PATH attribute in >>>>> all UPDATE messages sent to internal peers. (An empty AS_PATH >>>>> attribute is one whose length field contains the value zero). >>>>> >>>>> [/snip] >>>>> >>>>> So given b) above, returning zero for local AS wold seem intuitive. >>>>> >>>>> As for accommodating AS_SET, I'm not quite sure. Would it be >>>>> unreasonable to report multiple elements of the same type here if >>>>> an AS_SET is returned, or is this a bad idea (I expect so)? >>>>> >>>> One solution could be to specify multiple new AS-SET related I.E., >>>> such mplsLabelStackEntryX in MPLS. >>>> >>>> My personal view is that (in order to finish this IPFIX work who >>>> has been lasting to long IMHO ;)), we should post the draft with >>>> the I.E.s we require right now, and use the IANA procedure for any >>>> other I.E.s. Otherwise, I fear the job will never be finished. >>>> >>>>> >>>>> To further complicate things, I suspect we'll be seeing >>>>> this in deployments within a couple years, per AS number >>>>> depletion: >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-09.txt >>>>> >>>>> I'm not sure if we want to worry about it now or define >>>>> new elements down the road.. >>>>> >>>>> Regarding 149, ipNextHopAsNumber: >>>>> >>>>> ----- >>>>> 5.6.3 ipNextHopAsNumber >>>>> Description: >>>>> The autonomous system (AS) number of the next IP hop to which >>>>> packets of this flow are forwarded. >>>>> >>>>> Abstract Data Type: unsigned16 >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 149 >>>>> >>>>> Status: current >>>>> Reference: See RFC 1771 for a description of BGP-4 and see RFC >>>>> 1930 a >>>>> definition of the AS number. >>>>> ----- >>>>> >>>>> Is this element returning the AS number for the IP address reported >>>>> in the BGP NEXT_HOP attribute associated with the destination prefix, >>>>> or it the RIB/FIB IP "next hop" used to reach that destination? This >>>>> should be stated explicitly. >>>> >>>> >>>> >>>> >>>> >>>> I hope the new definition above is OK now. >>>> >>>> Regards, Benoit. >>>> >>>>> >>>>>>> >>>>>>> Note the "Previous" in the name above. Also, should you say >>>>>>> something about >>>>>>> source and destination prefixes here and above, it might help >>>>>>> implementers, per >>>>>>> this would be a "first" or "leftmost" AS segment in the AS_PATH >>>>>>> for the source >>>>>>> IP prefix in the BGP Loc-RIB that contains the source IP prefix, >>>>>>> while above it's >>>>>>> the destination prefix, etc.. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Any proposal? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Not sure if these are any better, but: >>>>> >>>>> 5.4.4 bgpSourceAsNumber >>>>> Description: >>>>> The first (origin) autonomous system (AS) number for the >>>>> prefix containing the source address in the IP packet header >>>>> in a packet of this flow. >>>>> >>>>> 5.4.5 bgpDestinationAsNumber >>>>> Description: >>>>> The first (origin) autonomous system (AS) number for the >>>>> prefix containing the destination address in the IP packet >>>>> header in a packet of this flow. >>>>> >>>>> >>>>> And I'd still like to see similar information elements added for >>>>> AS_CONFED_SET & AS_CONFED_SEQUENCE. >>>> >>>> >>>> >>>> >>>> >>>> As expressed above, if you require them, make a proposal. >>>> >>>> Regards, Benoit. >>>> >>>>> >>>>> -danny >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>> message body >>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>> "unsubscribe ipfix" in message body >>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>> >>>> >>>> >> >> >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 11 04:45:04 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13839 for ; Wed, 11 May 2005 04:45:03 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DVmlS-0001tm-00 for ipfix-list@mil.doit.wisc.edu; Wed, 11 May 2005 03:40:22 -0500 Received: from c3p0.cc.swin.edu.au ([136.186.1.30] helo=swin.edu.au) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DVmlR-0001tg-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 11 May 2005 03:40:21 -0500 Received: from swin.edu.au (szander.caia.swin.edu.au [136.186.229.100]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id SAA563940; Wed, 11 May 2005 18:40:03 +1000 (EST) Message-ID: <4281C54E.8060107@swin.edu.au> Date: Wed, 11 May 2005 18:41:50 +1000 From: Sebastian Zander Organization: Swinburne University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] One correction in the "octets" information elements References: <427881C3.90200@cisco.com> <427F27E7.4070604@cisco.com> <734945E7C5440C3DB70E6368@753F3B888A9969457862729D> In-Reply-To: <734945E7C5440C3DB70E6368@753F3B888A9969457862729D> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > > --On 5/9/2005 11:05 AM +0200 Benoit Claise wrote: > >> Juergen, >> >>> Hi Benoit, >>> >>> --On 5/4/2005 10:03 AM +0200 Benoit Claise wrote: >>> >>>> Juergen, >>>> >>>> We realized that the Information Element #1 octetDeltaCount, >>>> which is in line with NetFlow version 9, is not correctly specified. >>>> >>>> 5.9.1 octetDeltaCount >>>> Description: >>>> The number of octets since the previous report (if any) in >>>> incoming packets for this flow at the Observation Point. The >>>> number of octets include IP header(s) and IP payload. >>>> >>>> -> New Description: >>>> The number of octets since the previous report (if any) in >>>> incoming packets for this flow at the Observation Point. The >>>> number of octets exclude the data link header and trailer. >>>> >>>> This allows to account for the length of MPLS labels, for the ISL >>>> bytes, etc... >>> >>> >>> >>> I see the following problems with this change. >>> >>> - This implies that we count more than just the IP packet. >>> Since this is counter is fundamental for IPFIX, we would need >>> to discuss precisely what is measured. I do not like the >>> inclusion of non-IP octets in the count to be hidden in these >>> three lines. >>> >>> - How useful would this information be? >> >> >> Just one example: capacity planning with a MPLS core, when you want to >> know exactly what has been sent and not only the IP part of the packet. >> >>> How would the collector >>> know that the MPLS labels are included in the count? >> >> >> Counted by default. >> >>> >>> - Even if the collector knows that MPLS labels are included in the >>> count, it would not be able to just subtract them for calculating >>> the pure IP octet number, because it does not necessarily known >>> how many labels are on the label stack. >> >> >> If you really want to do it, you can export the number of labels as a >> different I.E. >> >>> >>> - Which information elements should a device use that supports MPLS >>> but is able to calculate the precise IP octet count, for example >>> at the end of the MPLS tunnel where both counts (with and without >>> labels) are available? Instead of defining another information >>> element for this case, I would rather define a new one for the >>> IP+MPLS octet counter. >> >> >> Defining a new set of counters might prove to be the only remaining >> solution. >> I would keep the I.E. #1 (octetDeltaCount) for IP + MPLS, as this is >> what NetFlow version 9 does now. > > > What about renaming #1 to subIpOctetDeltaCount and introducing a new one > for pure IP > that will then inherit the name octetDeltaCount? > (Sub-IP was the name of the IETF area that dealt with MPLS.) > We probably would have to do this for all counters of octets in packets, > i.e. > > postOctetDeltaCount #23, octetTotalCount #85, postMulticastOctetCount #20, > postOctetTotalCount #160, droppedOctetDeltaCount #132, > droppedOctetTotalCount #134. having both counter types seems to be a good idea. cheers, Sebastian -- Sebastian Zander http://caia.swin.edu.au -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed May 11 14:34:31 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03686 for ; Wed, 11 May 2005 14:34:31 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DVviy-0000oE-00 for ipfix-list@mil.doit.wisc.edu; Wed, 11 May 2005 13:14:24 -0500 Received: from mrout1.yahoo.com ([216.145.54.171]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DVvix-0000o8-00 for ipfix-info@net.doit.wisc.edu; Wed, 11 May 2005 13:14:23 -0500 Received: from [66.228.162.78] (snapdragon.corp.yahoo.com [66.228.162.78]) by mrout1.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j4BIDnRn019144; Wed, 11 May 2005 11:13:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:x-accept-language: mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=xB7OuGYF8M4+hMXcxSvk5mrn2+EH9tGEY7KZ9cwbGnNM1rT1IegHLGYQtE+mpsef Message-ID: <42824B5D.2090209@yahoo-inc.com> Date: Wed, 11 May 2005 11:13:49 -0700 From: Eric Ji User-Agent: Mozilla Thunderbird 0.9 (X11/20041116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: Danny McPherson , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] BGP related Information Elements References: <426E5295.8080602@cisco.com> <7ab543168fd86ef01096ded6d744219f@tcb.net> <4278D8B1.2030003@cisco.com> <427F4532.8050202@cisco.com> <427FABD1.4010605@yahoo-inc.com> <427FBB91.6000502@cisco.com> <42812B04.8090807@yahoo-inc.com> <4281A678.8080808@cisco.com> In-Reply-To: <4281A678.8080808@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit, I think I didn't express well. What I meant was is to get _the_ AS, i.e., the real single adjacent AS. We can't get that from AS_SET. But under certain situations, it can be get from BGP other part rather than ASpath, as said in previous email, or new ways to discover it later on. So I proposed to add that line, to keep the door open for those. Then the exporter would do a best effort on this, and report 0 only when all current methods fails. Regards, Eric Benoit Claise wrote: > Eric, > >> Benoit, >> >> Now that it's already used, I have no issue with keeping it, given >> that its limitation is well documented. >> >> Another minor points, we may change the following wording, >> "In case of AS-SET, the value of 0 is reported." to >> "In case of AS-SET, and can't be easily retrieved from BGP, the value >> 0 is reported." >> That leaves space for other ways to get this information now, such as >> through ebgp neighbor AS for edge routers. And it doesnt close the >> door for new ways to discover this later on, such as examining the >> exit point or topology. > > > Do you want to say "In case of AS-SET or can't be easily retrieved from > BGP, the value 0 is reported."? > Because, even with AS-SET, the AS can be easily retrieved. The issue is > to export it in IPFIX :) > > Regards, Benoit. > >> >> Regards, >> Eric >> >> >> Benoit Claise wrote: >> >>> Eric, >>> >>>> >>>> Nice work. I'd propose to remove bgpSrcAdjacentASNumber. It's not >>>> uncommon that BGP asymmetry happens a lot in real world, and this >>>> element may cause problem in real use for applications built on, if >>>> it reports wrong information. And there's no easy way to verify that >>>> inside IPFIX itself. >>> >>> >>> >>> >>> I share with your concern. >>> However, I propose to keep this I.E.s for 2 reasons. >>> 1. This BGP asymmetry and peer source AS / asymmetry issue is not >>> new: we do already export this value in NetFlow version 9 today. >>> 2. you will have a wrong value for bgpSrcAdjacentASNumber only in the >>> case of multi-access interfaces (typically an ethernet interface at >>> an IXP). In other interface types, you would be able to deduce if the >>> value is correct or not, i.e. if there is some asymmetry >>> >>> Regards, Benoit. >>> >>>> >>>> Regards, >>>> Eric >>>> >>>> >>>> Benoit Claise wrote: >>>> >>>>> Danny and all, >>>>> >>>>> In order to continue the discussion with a clear basis, here is the >>>>> list of proposed BGP-related I.E.s. I've been trying to insert all >>>>> suggestions. >>>>> This should answer some of your questions below. >>>>> Feel free to review and to propose some new text if some >>>>> improvements are required. >>>>> >>>>> | 16 | bgpSourceAsNumber | 17 | >>>>> bgpDestinationAsNumber >>>>> | 18 | bgpNextHopIpV4Address >>>>> | 63 | bgpNextHopIpV6Address >>>>> | 128 | bgpNextHopAsNumber >>>>> | 129 | ipNextHopAsNumber >>>>> >>>>> 5.4.4 bgpSourceAsNumber >>>>> Description: >>>>> The autonomous system (AS) number of the source address in the IP >>>>> packet headers of this flow. In case of AS-SET, the value >>>>> of 0 is reported. >>>>> >>>>> Abstract Data Type: unsigned16 >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 16 >>>>> >>>>> Status: current >>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>> >>>>> >>>>> 5.4.5 bgpDestinationAsNumber >>>>> Description: >>>>> The autonomous system (AS) number of the destination address in >>>>> the IP packet headers this flow. In case of AS-SET, the >>>>> value of 0 is reported. >>>>> >>>>> Abstract Data Type: unsigned16 >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 17 >>>>> >>>>> Status: current >>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>> >>>>> >>>>> 5.4.7 bgpNextHopIpV4Address >>>>> Description: >>>>> The IPv4 address of the next BGP hop to which packets of this >>>>> flow >>>>> are forwarded. >>>>> >>>>> Abstract Data Type: ipv4Address >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 18 >>>>> >>>>> Status: current >>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>> >>>>> >>>>> 5.4.8 bgpNextHopIpV6Address >>>>> Description: >>>>> The IPv6 address of the next BGP hop to which packets of this >>>>> flow >>>>> are forwarded. >>>>> >>>>> Abstract Data Type: ipv6Address >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 63 >>>>> >>>>> Status: current >>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>> 5.4.6 bgpDstAdjacentASNumber >>>>> Description: >>>>> The autonomous system (AS) number of the first AS in the AS path >>>>> to which packets of this flow are forwarded, deduced by looking up >>>>> the source IP address of the flow in the BGP routing information >>>>> base. In case of AS-SET, the value of 0 is reported. >>>>> >>>>> Abstract Data Type: unsigned16 >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 128 >>>>> >>>>> Status: current >>>>> >>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>> >>>>> 5.4.6 bgpSrcAdjacentASNumber >>>>> >>>>> Description: >>>>> The autonomous system (AS) number of the last AS in the AS path >>>>> from which packets of this flow arrived, deduced by looking up the >>>>> source IP address of the flow in the BGP routing information base. >>>>> In case of BGP asymmetry, the bgpSrcAdjacentASNumber might not be >>>>> able to report the correct value. In case of AS-SET, the value of 0 >>>>> is reported. >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 129 >>>>> >>>>> Status: current >>>>> >>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>> >>>>> >>>>> >>>>> See inline. >>>>> >>>>>> >>>>>> On May 4, 2005, at 8:14 AM, Benoit Claise wrote: >>>>>> >>>>>>> I think we have a technical problem right now in IPFIX. We can't >>>>>>> report an AS_SET. How can we report that the >>>>>>> bgpDstAdjacentASNumber is not a single unsigned16, but list of >>>>>>> unsigned16? This is not possible! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Right.. >>>>>> >>>>>>> So a quick and dirty solution... why not say: export 0 for AS_SET. >>>>>>> Anyway, reporting the AS_SET is not that useful on the collector. >>>>>>> If AS_SET = (100, 200, 300), it means that most specific routes >>>>>>> of this aggregate prefix comes from either 100, either 200, >>>>>>> either 300. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> This would have to apply uniformly across all these elements, as >>>>>> any of these could return AS_SET: >>>>>> >>>>>> 16 bgpSourceAsNumber >>>>>> 17 bgpDestinationAsNumber >>>>>> 128 bgpNextAdjacentAsNumber >>>>>> 129 bgpPreviousAdjacentAsNumber >>>>>> 149 ipNextHopAsNumber >>>>>> >>>>>> I would suspect that 16, 17 and 149 would very frequently >>>>>> reside within the local AS >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> BTW, typo 149 -> 129. >>>>> I don't see how the local AS would be reported with the definitions >>>>> of 16/17. >>>>> The definition of 129 has been changed. I guess it's ok now. >>>>> >>>>>> - which would most intuitively be >>>>>> represented by '0', I think.. For that matter, any of these >>>>>> could return local AS (or is it no_adjacent_AS? :-) >>>>>> >>>>>> Given my admittedly terse review of the draft, I don't see >>>>>> behavior defined for where these values should be derived, >>>>>> and in particular, how local AS (or no AS?) should be >>>>>> reported. Do you envision local AS being reported as a >>>>>> function of the router knowing what AS the local BGP process >>>>>> resides in? Else that local AS value isn't added to the path >>>>>> until advertised to an eBGP peer. >>>>>> >>>>>> I'd be a bit cautious about using '0', and perhaps specify >>>>>> that local AS (and no AS) always return '0'. This would >>>>>> align with the BGP Spec: >>>>>> >>>>>> [snip from BGP spec] >>>>>> When a BGP speaker originates a route then: >>>>>> >>>>>> a) the originating speaker includes its own AS number in a path >>>>>> segment of type AS_SEQUENCE in the AS_PATH attribute of all UPDATE >>>>>> messages sent to an external peer. (In this case, the AS number of >>>>>> the originating speaker's autonomous system will be the only entry >>>>>> the path segment, and this path segment will be the only segment >>>>>> in the AS_PATH attribute). >>>>>> >>>>>> b) the originating speaker includes an empty AS_PATH attribute in >>>>>> all UPDATE messages sent to internal peers. (An empty AS_PATH >>>>>> attribute is one whose length field contains the value zero). >>>>>> >>>>>> [/snip] >>>>>> >>>>>> So given b) above, returning zero for local AS wold seem intuitive. >>>>>> >>>>>> As for accommodating AS_SET, I'm not quite sure. Would it be >>>>>> unreasonable to report multiple elements of the same type here if >>>>>> an AS_SET is returned, or is this a bad idea (I expect so)? >>>>>> >>>>> One solution could be to specify multiple new AS-SET related I.E., >>>>> such mplsLabelStackEntryX in MPLS. >>>>> >>>>> My personal view is that (in order to finish this IPFIX work who >>>>> has been lasting to long IMHO ;)), we should post the draft with >>>>> the I.E.s we require right now, and use the IANA procedure for any >>>>> other I.E.s. Otherwise, I fear the job will never be finished. >>>>> >>>>>> >>>>>> To further complicate things, I suspect we'll be seeing >>>>>> this in deployments within a couple years, per AS number >>>>>> depletion: >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-09.txt >>>>>> >>>>>> I'm not sure if we want to worry about it now or define >>>>>> new elements down the road.. >>>>>> >>>>>> Regarding 149, ipNextHopAsNumber: >>>>>> >>>>>> ----- >>>>>> 5.6.3 ipNextHopAsNumber >>>>>> Description: >>>>>> The autonomous system (AS) number of the next IP hop to which >>>>>> packets of this flow are forwarded. >>>>>> >>>>>> Abstract Data Type: unsigned16 >>>>>> >>>>>> Data Type Semantics: identifier >>>>>> >>>>>> ElementId: 149 >>>>>> >>>>>> Status: current >>>>>> Reference: See RFC 1771 for a description of BGP-4 and see RFC >>>>>> 1930 a >>>>>> definition of the AS number. >>>>>> ----- >>>>>> >>>>>> Is this element returning the AS number for the IP address reported >>>>>> in the BGP NEXT_HOP attribute associated with the destination prefix, >>>>>> or it the RIB/FIB IP "next hop" used to reach that destination? This >>>>>> should be stated explicitly. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I hope the new definition above is OK now. >>>>> >>>>> Regards, Benoit. >>>>> >>>>>> >>>>>>>> >>>>>>>> Note the "Previous" in the name above. Also, should you say >>>>>>>> something about >>>>>>>> source and destination prefixes here and above, it might help >>>>>>>> implementers, per >>>>>>>> this would be a "first" or "leftmost" AS segment in the AS_PATH >>>>>>>> for the source >>>>>>>> IP prefix in the BGP Loc-RIB that contains the source IP prefix, >>>>>>>> while above it's >>>>>>>> the destination prefix, etc.. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Any proposal? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Not sure if these are any better, but: >>>>>> >>>>>> 5.4.4 bgpSourceAsNumber >>>>>> Description: >>>>>> The first (origin) autonomous system (AS) number for the >>>>>> prefix containing the source address in the IP packet header >>>>>> in a packet of this flow. >>>>>> >>>>>> 5.4.5 bgpDestinationAsNumber >>>>>> Description: >>>>>> The first (origin) autonomous system (AS) number for the >>>>>> prefix containing the destination address in the IP packet >>>>>> header in a packet of this flow. >>>>>> >>>>>> >>>>>> And I'd still like to see similar information elements added for >>>>>> AS_CONFED_SET & AS_CONFED_SEQUENCE. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> As expressed above, if you require them, make a proposal. >>>>> >>>>> Regards, Benoit. >>>>> >>>>>> >>>>>> -danny >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>> message body >>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>> "unsubscribe ipfix" in message body >>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>> >>>>> >>>>> >>> >>> >>> > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Plamen627@elftman.com Wed May 11 16:02:02 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15965 for ; Wed, 11 May 2005 16:02:02 -0400 (EDT) Received: from [81.215.112.100] (helo=elftman.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DVxIz-0005Ao-00 for ipfix-list@mil.doit.wisc.edu; Wed, 11 May 2005 14:55:46 -0500 From: "Plamen Olivares" To: "Ken Chatman" Subject: =?iso-8859-1?Q?C=EDALlSS_V=E0LLlUM_ViAGRR=C1?= Date: Wed, 11 May 2005 15:55:37 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C5767A.42826339" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C5767A.42826339 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Captain Blood a chair. understand from the first that you are simply in the position of that we sail under articles that admit no ambiguities. You have Meanwhile Ogle was growing impatient. His arm still gripped by wildly a moment upon the shoulders of his father, as if beseechin moved had she not cared - had she not felt that in what he did th But if I command you to go - to make the attempt? he asked. doll-tearsheets and dunghill-queans from the Old World, and all t All day the Dutch brig was in sight, though by evening she had aware of the intent. come for less. We depart again upon your assurance that you cann Have a nice day. ------=_NextPart_000_0008_01C5767A.42826339 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hello, How WouId you Iike to = save on your p=EDlIs?
 
V=ECAGRA V=E0L1UM CIAL=EDSS and = many other.
 
Save over 70% with PharmacyByMaill STORE.
 
Have a nice day.
 
 
 
 
Captain Blood a
chair. = understand from the first that you are simply in the position
of = that we sail under articles that admit no ambiguities. You
have = Meanwhile Ogle was growing impatient. His arm still gripped
by = wildly a moment upon the shoulders of his father, as if
beseechin = moved had she not cared - had she not felt that in what he did
th = But if I command you to go - to make the attempt? he
asked. = doll-tearsheets and dunghill-queans from the Old World, and all
t = All day the Dutch brig was in sight, though by evening she
had = aware of the
intent. = come for less. We depart again upon your assurance that you
cann =
------=_NextPart_000_0008_01C5767A.42826339-- From majordomo@mil.doit.wisc.edu Thu May 12 06:27:29 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12070 for ; Thu, 12 May 2005 06:27:28 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWAcq-0006YP-00 for ipfix-list@mil.doit.wisc.edu; Thu, 12 May 2005 05:09:04 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWAcp-0006YJ-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 12 May 2005 05:09:03 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4CA92418010; Thu, 12 May 2005 06:09:02 -0400 (EDT) Received: from [10.61.80.112] (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4CA90K18662; Thu, 12 May 2005 12:09:00 +0200 (CEST) Message-ID: <42832B3C.8010004@cisco.com> Date: Thu, 12 May 2005 12:09:00 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: STEPHAN Emile RD-CORE-LAN CC: Stewart Bryant , Lutz Mark , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Encoding of IPFIX Data Types References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030903030109000005060905" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------030903030109000005060905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-rtp.cisco.com id j4CA92418010 Content-Transfer-Encoding: quoted-printable Emile, Draft changed. 6.2 Reduced Size Encoding of Integer Types=20 =20 Information Elements containing integer, _string, and octetarray_ type= s in the information model MAY be encoded using fewer octets than those=20 implied by their type in the information model definition [IPFIX-INFO]= , =20 based on the assumption that the smaller type is sufficient to carry=20 any value the Exporter may need to deliver. =20 Regards, Benoit. >Dear Stewart, Lutz > >I suggest that section 6.2 defines the reduced size encoding not only fo= r integer but for string and array too. That will clarify the link to sec= tion 6.2 in section "3.2 Field Specifier".=20 > >Regards >Emile > =20 > >>-----Message d'origine----- >>De : majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] De la pa= rt >>de Stewart Bryant >>Envoy=E9 : mardi 3 mai 2005 14:22 >>=C0 : Lutz Mark >>Cc : ipfix-protocol@net.doit.wisc.edu >>Objet : Re: [ipfix-protocol] Encoding of IPFIX Data Types >> >> >> >>Lutz Mark wrote: >> >> =20 >> >>> > 6.1.5 string and octetarray >>> > >>> > The data type string represents a finite length string of valid >>> > characters of the Unicode character encoding set. It is expected >>> > that strings will be encoded in UTF-8 format. The string is sent = as >>> > an array of octets. The length of the string and the octetArray = is >>> > encoded as described in Section 7 (Variable Length Information >>> > Element). The length is followed by that many octets as encoded = in >>> > the length. >>> >>>The section implies that you have to use variable length IEs to >>>export strings and octetarrays (or does the text mean that you >>>have to send the length twice? It's not clear to me). >>> =20 >>> >>There are three possible ways to send a string: >> >>1) Fixed length >>2) Short variable length >>3) Long variable length. >> >>In case 1, you put the length in the template and the string >>is always that length, and if your string is shorter you have >>to pad. >> >>In case 2 and 3 you use a special length value in the template >>which says that the length is encoded at the start of the string. >> >> =20 >> >>>I suggest to change the text to allow the export of strings and >>>octetarrays in an IE of fixed length. >>> >>>For example: >>> >>> The data type string represents a finite length string of valid >>> characters of the Unicode character encoding set. It is expected >>> that strings will be encoded in UTF-8 format. The string is sent as >>> an array of octets. The length of the information element >>> specifies the length of the octedarray. >>> =20 >>> >>This is only true for fixed length strings. >> >>Regards >> >>Stewart >> >> =20 >> >>>Regards, >>>Lutz >>> >>> >>>-- >>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in messa= ge >>>body >>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>"unsubscribe ipfix" in message body >>>Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> >>> =20 >>> >>-- >>Help mailto:majordomo@net.doit.wisc.edu and say "help" in messag= e >>body >>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>"unsubscribe ipfix" in message body >>Archive http://ipfix.doit.wisc.edu/archive/ >> =20 >> > >-- >Help mailto:majordomo@net.doit.wisc.edu and say "help" in message= body >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >"unsubscribe ipfix" in message body >Archive http://ipfix.doit.wisc.edu/archive/ > =20 > --------------030903030109000005060905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Emile,

Draft changed.
 6.2      Reduced Size Encoding of Integer Types 
 
   Information Elements containing integer, string, and octetarray types
   in the information model MAY be encoded using fewer octets than those 
   implied by their type in the information model definition [IPFIX-INFO],  
   based on the assumption that the smaller type is sufficient to carry 
   any value the Exporter may need to deliver.
Regards, Benoit.
Dear Stewart, Lutz

I suggest that section 6.2 defines the reduced size encoding not only for integer but for string and array too. That will clarify the link to section 6.2 in section "3.2 Field Specifier". 

Regards
Emile
  
-----Message d'origine-----
De : majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] De la part
de Stewart Bryant
Envoyé : mardi 3 mai 2005 14:22
À : Lutz Mark
Cc : ipfix-protocol@net.doit.wisc.edu
Objet : Re: [ipfix-protocol] Encoding of IPFIX Data Types



Lutz Mark wrote:

    
 > 6.1.5   string and octetarray
 >
 >   The data type string represents a finite length string of valid
 >   characters of the Unicode character encoding set.  It is expected
 >   that strings will be encoded in UTF-8 format. The string is sent as
 >   an array of octets.  The length of the string and the octetArray is
 >   encoded as described in Section 7 (Variable Length Information
 >   Element).  The length is followed by that many octets as encoded in
 >   the length.

The section implies that you have to use variable length IEs to
export strings and octetarrays (or does the text mean that you
have to send the length twice? It's not clear to me).
      
There are three possible ways to send a string:

1) Fixed length
2) Short variable length
3) Long variable length.

In case 1, you put the length in the template and the string
is always that length, and if your string is shorter you have
to pad.

In case 2 and 3 you use a special length value in the template
which says that the length is encoded at the start of the string.

    
I suggest to change the text to allow the export of strings and
octetarrays in an IE of fixed length.

For example:

   The data type string represents a finite length string of valid
   characters of the Unicode character encoding set. It is expected
   that strings will be encoded in UTF-8 format. The string is sent as
   an array of octets. The length of the information element
   specifies the length of the octedarray.
      
This is only true for fixed length strings.

Regards

Stewart

    
Regards,
Lutz


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/


      
--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message
body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/
    

--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

--------------030903030109000005060905-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu May 12 06:27:36 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12090 for ; Thu, 12 May 2005 06:27:35 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWAde-0006aA-00 for ipfix-list@mil.doit.wisc.edu; Thu, 12 May 2005 05:09:54 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWAdd-0006a5-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 12 May 2005 05:09:53 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4CA9lU18062; Thu, 12 May 2005 06:09:52 -0400 (EDT) Received: from [10.61.80.112] (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4CA9kK19287; Thu, 12 May 2005 12:09:46 +0200 (CEST) Message-ID: <42832B6A.8040007@cisco.com> Date: Thu, 12 May 2005 12:09:46 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lutz Mark CC: Stewart Bryant , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Encoding of IPFIX Data Types References: <42774A6A.7040106@fokus.fraunhofer.de> <42776CFE.9050404@cisco.com> <4278B9CA.9090602@fokus.fraunhofer.de> In-Reply-To: <4278B9CA.9090602@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Lutz, Draft changed. I would like to add the last sentence, in order to specify that we must pad with NUL character. What about: The data type string represents a finite length string of valid characters of the Unicode character encoding set. It is expected that strings will be encoded in UTF-8 format. The string is sent as an array of octets using an information element of fixed or variable length. The length of the information element specifies the length of the octetarray. In case of fixed length Information Element, if padding is required, padding MUST be composed of NUL character(s). Regards, Benoit. > > Hi Steward, > >> There are three possible ways to send a string: >> >> 1) Fixed length >> 2) Short variable length >> 3) Long variable length. >> >> In case 1, you put the length in the template and the string >> is always that length, and if your string is shorter you have >> to pad. >> >> In case 2 and 3 you use a special length value in the template >> which says that the length is encoded at the start of the string. > > > thank you for the clarification. > I suggest to change section 6.1.5. > > What about: > The data type string represents a finite length string of valid > characters of the Unicode character encoding set. It is expected > that strings will be encoded in UTF-8 format. The string is sent as > an array of octets using an information element of fixed or variable > length. The length of the information element specifies the length > of the octetarray. > > Best regards, > Lutz > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu May 12 07:03:50 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14259 for ; Thu, 12 May 2005 07:03:50 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWBGW-0000YY-00 for ipfix-list@mil.doit.wisc.edu; Thu, 12 May 2005 05:50:04 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWBGV-0000YT-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 12 May 2005 05:50:03 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4CAnxp20404; Thu, 12 May 2005 06:49:59 -0400 (EDT) Received: from [10.61.80.112] (ams-clip-vpn-dhcp4209.cisco.com [10.61.80.112]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4CAnuK21046; Thu, 12 May 2005 12:49:56 +0200 (CEST) Message-ID: <428334D4.9040708@cisco.com> Date: Thu, 12 May 2005 12:49:56 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: STEPHAN Emile RD-CORE-LAN CC: ipfix-protocol@net.doit.wisc.edu, Juergen Quittek Subject: [ipfix-protocol] Re: info model flexibility References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070305060709050904030507" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------070305060709050904030507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-rtp.cisco.com id j4CAnxp20404 Content-Transfer-Encoding: quoted-printable Dear Emile, > Dear Benoit, > > =20 > > Currently downcasting is a property of the protocol. To give=20 > flexibility to new Information Elements definition it must be an=20 > Information Element property. In the following example foo definition=20 > says that it can be downcasted as B and C. That is not feasible=20 > currently because downcasting is hardcoded in the protocol. > > =20 > > Name: foo > > Description: "" > > Abstract Data Type: A > > ElementId: 555 > > Dowcasting: B and C > > =20 > > There is another benefit to define downcasting in the info model: It=20 > will be possible to limit downcasting to a subset of integer (e.g.=20 > unsigned64 to unsigned32 only instead of unsigned64 to unsigned32 or=20 > to unsigned16 or to octet). > I think this is the wrong approach: downcasting should be part of the=20 protocol. The IPFIX device, based on what he knows, should decide=20 whether downcasting is the appropriate choice. It should also decide to=20 which type to downcast. For example: the IPFIX device is the only one to=20 know, based on its architecture, to which type it could downcast an=20 ingressInterface. Regards, Benoit. > =20 > > =20 > > Regards > > Emile > > =20 > > =20 > > -----------------------------------------------------------------------= - > > *De :* Benoit Claise [mailto:bclaise@cisco.com] > *Envoy=E9 :* mercredi 4 mai 2005 16:32 > *=C0 :* STEPHAN Emile RD-CORE-LAN > *Cc :* ipfix-protocol@net.doit.wisc.edu; Juergen Quittek > *Objet :* Re: info model flexibility > > =20 > > Hi Emile, > > Hi Benoit, > > =20 > > The info model (section 2.1) is designed to be managed dynamically by=20 > IANA without moving to a new protocol version. So I consider that more=20 > flexibility must be given to the specification of Information Elements=20 > in the info model. Let's take a real example: > > Downcasting is currently defined in the protocol specification.=20 > Consequently it will not be possible to use them in the future with=20 > new field types. > > I don't understand why? > > =20 > > > > So Downcasting may be moved in the section 2.1 of the info model. > > The agreement was that the I.E. must define its maximum length. This=20 > was required by the database guys who wanted to be able to define=20 > their schemas. > If an exporter doesn't have to use the full length, why export it?=20 > This is a protocol issue and not an information model issue. > > =20 > > What about replacing "dataType - One of the types listed in section=20 > 3.1 of this document..." with" dataType - Types listed in section 3.1=20 > of this document..." ? > > I don't get the point with the more flexibility argument. > > Or what about defining a downcasting keyword in the MAY list of this=20 > section? > > See above. > > Regards, Benoit. > > =20 > > Regards > > Emile > > -----------------------------------------------------------------------= - > > *De :* Benoit Claise [mailto:bclaise@cisco.com] > *Envoy=E9 :* mardi 3 mai 2005 17:33 > *=C0 :* STEPHAN Emile RD-CORE-LAN > *Cc :* ipfix-protocol@net.doit.wisc.edu > *Objet :* Re: [ipfix-protocol] new version of the IPFIX protocol=20 > draft: draft-ietf-ipfix-protocol-12.txt > > =20 > > Dear Emile, > > Dear Benoit, > > =20 > > What is the max length of a fixed length field ? Is it 65534 ? > > The draft says: > >Field Length =20 > > The length of the corresponding encoded Information Element, = =20 > > in octets. Refer to [IPFIX-INFO]. The field length may be =20 > > smaller than the definition in [IPFIX-INFO] if reduced size =20 > > encoding is used (see section 6.2). The value 65535 is =20 > > reserved for variable length Information Element (see =20 > > section 7). The Field Length MAY NOT 0.=20 > >=20 > >So we don't specify what the maximum length is, we simply say that 65535= is reserved. Obviously this is below 65535.=20 > >Anyway, the length is specify by the information model=20 > >> Does that make sense as the max length of an IPFIX msg is 65535 ? >> > IMHO, this offers the maximum of flexibility. > > =20 > > At large, in the future IPFIX will need to define new kind of field=20 > types. The current definition of 'Field Length' must be prepared for=20 > that. I propose to reserve the MSB of 'Field Length' for future usage. > > How to export in UDP an IPFIX Message whose length is above 65535 is=20 > not that such a trivial issue! > So I propose to start with IPFIX 1.0, get some adoption, see the=20 > limitations, and go from there. > > Regards, Benoit. > > =20 > > Regards > > Emile > > =20 > > -----------------------------------------------------------------------= - > > *De :* majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] *De=20 > la part de* Benoit Claise > *Envoy=E9 :* mardi 19 avril 2005 01:43 > *=C0 :* ipfix-protocol@net.doit.wisc.edu=20 > ; me > *Cc :* Paul Aitken > *Objet :* [ipfix-protocol] new version of the IPFIX protocol draft:=20 > draft-ietf-ipfix-protocol-12.txt > > =20 > > Dear all, > > I just posted a new version of the IPFIX protocol draft, with the=20 > feedback from Paul Aitken's thorough review. > > Here are the list of changes: > - Some cross references were wrong > - Flow Record definition exactly similar to the one in [IPFIX-ARCH] > - Template definition exactly similar to the one in [IPFIX-ARCH] > - As deduced from section 9, the source ID definition now contains:=20 > the source ID MUST NOT be 0 > - The Field Length is completed with:** **The value 65535 is reserved=20 > for variable length Information Element (see section 7). The Field=20 > Length MAY NOT 0. > - one mistake corrected in figure O > - correction: In most cases the length of the Information Element will=20 > be less than 256 **255** octets. > - correction: The IPFIX Message Header 16-bit Length field limits the=20 > length of a IPFIX Message to 65536 **65535** octets including the heade= r. > - section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops=20 > ;) BTW, the TCP sections now speaks of TCP connection as opposed to=20 > TCP association > - added the 2 sentences > > When the TCP connection restarts, the Exporting Process MUST resend=20 > > all the Template Records. =20 > > =20 > > When an TCP connection is closed, the Collecting Process MUST=20 > > discard all templates received over that connection and stop=20 > > decoding IPFIX Messages that use those templates.=20 > >- A couple of mistakes in the examples. > >=20 > >I advice to review the changes at http://ietf.levkowetz.com/drafts/ipfix= /, once the draft is published.=20 > >=20 > >Regards, Benoit. > > =20 > > =20 > > =20 > >** ** > > - A lot of editorial corrections and improvements > > =20 > > =20 > --------------070305060709050904030507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Emile,

Dear Benoit,

 

Currently downcasting is a property of the protocol. To give flexibility to new Information Elements definition it must be an Information Element property. In the following example foo definition says that it can be downcasted as B and C. That is not feasible currently because downcasting is hardcoded in the protocol.

 

Name:                          foo

Description:                 ""

Abstract Data Type:      A

ElementId:                    555

Dowcasting:                 B and C

 

There is another benefit to define downcasting in the info model: It will be possible to limit downcasting to a subset of integer (e.g. unsigned64 to unsigned32 only instead of unsigned64 to unsigned32 or to unsigned16 or to octet).

I think this is the wrong approach: downcasting should be part of the protocol. The IPFIX device, based on what he knows, should decide whether downcasting is the appropriate choice. It should also decide to which type to downcast. For example: the IPFIX device is the only one to know, based on its architecture,  to which type it could downcast an ingressInterface.

Regards, Benoit.

 

 

Regards

Emile

 

 

De : Benoit Claise [mailto:bclaise@cisco.com]
Envoyé : mercredi 4 mai 2005 16:32
À : STEPHAN Emile RD-CORE-LAN
Cc : ipfix-protocol@net.doit.wisc.edu; Juergen Quittek
Objet : Re: info model flexibility

 

Hi Emile,

Hi Benoit,

 

The info model (section 2.1) is designed to be managed dynamically by IANA without moving to a new protocol version. So I consider that more flexibility must be given to the specification of Information Elements in the info model. Let's take a real example:

Downcasting is currently defined in the protocol specification. Consequently it will not be possible to use them in the future with new field types.

I don't understand why?

 



So Downcasting may be moved in the section 2.1 of the info model.

The agreement was that the I.E. must define its maximum length. This was required by the database guys who wanted to be able to define their schemas.
If an exporter doesn't have to use the full length, why export it? This is a protocol issue and not an information model issue.

 

What about replacing "dataType - One of the types listed in section 3.1 of this document…" with" dataType - Types listed in section 3.1 of this document…" ?

I don't get the point with the more flexibility argument.

Or what about defining a downcasting keyword in the MAY list of this section?

See above.

Regards, Benoit.

 

Regards

Emile

De : Benoit Claise [mailto:bclaise@cisco.com]
Envoyé : mardi 3 mai 2005 17:33
À : STEPHAN Emile RD-CORE-LAN
Cc : ipfix-protocol@net.doit.wisc.edu
Objet : Re: [ipfix-protocol] new version of the IPFIX protocol draft: draft-ietf-ipfix-protocol-12.txt

 

Dear Emile,

Dear Benoit,

 

What is the max length of a fixed length field ? Is it 65534 ?

The draft says: 

Field Length  
           The length of the corresponding encoded Information Element,  
           in octets.  Refer to [IPFIX-INFO].  The field length may be  
           smaller than the definition in [IPFIX-INFO] if reduced size  
           encoding is used (see section 6.2).  The value 65535 is    
           reserved for variable length Information Element (see  
           section 7). The Field Length MAY NOT 0. 
 
So we don't specify what the maximum length is, we simply say that 65535 is reserved. Obviously this is below 65535. 
Anyway, the length is specify by the information model

Does that make sense as the max length of an IPFIX msg is 65535 ?

IMHO, this offers the maximum of flexibility.

 

At large, in the future IPFIX will need to define new kind of field types. The current definition of  'Field Length' must be prepared for that. I propose to reserve the MSB of 'Field Length' for future usage.

How to export in UDP an IPFIX Message whose length is above 65535 is not that such a trivial issue!
So I propose to start with IPFIX 1.0, get some adoption, see the limitations, and go from there.

Regards, Benoit.

 

Regards

Emile

 

De : majordomo listserver [mailto:majordomo@mil.doit.wisc.edu] De la part de Benoit Claise
Envoyé : mardi 19 avril 2005 01:43
À : ipfix-protocol@net.doit.wisc.edu; me
Cc : Paul Aitken
Objet : [ipfix-protocol] new version of the IPFIX protocol draft: draft-ietf-ipfix-protocol-12.txt

 

Dear all,

I just posted a new version of the IPFIX protocol draft, with the feedback from Paul Aitken's thorough review.

Here are the list of changes:
- Some cross references were wrong
- Flow Record definition exactly similar to the one in [IPFIX-ARCH]
- Template definition exactly similar to the one in [IPFIX-ARCH]
- As deduced from section 9, the source ID definition now contains: the source ID MUST NOT be 0
- The Field Length is completed with: The value 65535 is reserved for variable length Information Element (see section 7). The Field Length MAY NOT 0.
- one mistake corrected in figure O
- correction: In most cases the length of the Information Element will be less than 256 255 octets.
- correction: The IPFIX Message Header 16-bit Length field limits the length of a IPFIX Message to 65536 65535 octets including the header.
- section 10.4.1.2 referred to SCTP while it was a TCP section. Ooops ;) BTW, the TCP sections now speaks of TCP connection as opposed to TCP association
- added the 2 sentences

   When the TCP connection restarts, the Exporting Process MUST resend 
   all the Template Records.  
     
   When an TCP connection is closed, the Collecting Process MUST 
   discard all templates received over that connection and stop 
   decoding IPFIX Messages that use those templates. 
- A couple of mistakes in the examples.
 
I advice to review the changes at http://ietf.levkowetz.com/drafts/ipfix/, once the draft is published. 
 
Regards, Benoit.

 

     

 

 

- A lot of editorial corrections and improvements

 

 


--------------070305060709050904030507-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu May 12 20:09:03 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25228 for ; Thu, 12 May 2005 20:09:02 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWNRh-0007Zi-00 for ipfix-list@mil.doit.wisc.edu; Thu, 12 May 2005 18:50:25 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWNRg-0007Zc-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 12 May 2005 18:50:24 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4CNoNL09238 for ; Thu, 12 May 2005 19:50:23 -0400 (EDT) Received: from [10.49.4.218] (bclaise-isdn-home.cisco.com [10.49.4.218]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4CNoLK26188 for ; Fri, 13 May 2005 01:50:21 +0200 (CEST) Message-ID: <4283EBBD.7050307@cisco.com> Date: Fri, 13 May 2005 01:50:21 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] new version of the IPFIX protocol draft:draft-ietf-ipfix-protocol-14.txt Content-Type: multipart/alternative; boundary="------------070801020204050902090906" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------070801020204050902090906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I just posted a new version of the IPFIX protocol draft. Changes: - Source ID definition modified - Sections "3.4.2 Options Template Record Format" and "3.4.2.1 Scope" improved - Added "The Scope Field Count MAY NOT be zero." under the Scope Field Count for completeness (note it was already in the section 3.4.2.1) - Section "6.1.5 string and octetarray" improved - Section "6.2 Reduced Size Encoding of Integer Types" now contains the string and octetarray types - Source ID clarification: Remove "The Exporting Process MUST NOT transmit IPFIX Messages with more than one Source ID value inside any single stream. " Remove "The Collecting Process MUST verify that only one Source ID value is used inside each stream. If the Collecting Process detects that more than one Source ID has been received within a stream, it MUST discard the IPFIX Message, reset the SCTP association, and SHOULD log the error." Remove "IPFIX Messages with a Source ID of zero MUST be discarded by the Collecting Process." Regards, Benoit --------------070801020204050902090906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I just posted a new version of the IPFIX protocol draft.

Changes:
- Source ID definition modified
- Sections "3.4.2   Options Template Record Format" and "3.4.2.1 Scope" improved
- Added "The Scope Field Count MAY NOT be zero." under the Scope Field Count for completeness (note it was already in the section 3.4.2.1)
- Section "6.1.5   string and octetarray" improved
- Section "6.2 Reduced Size Encoding of Integer Types" now contains the string and octetarray types 
- Source ID clarification:
	Remove "The Exporting Process MUST NOT transmit IPFIX Messages with more 
   than one Source ID value inside any single stream. "
	Remove "The Collecting Process MUST verify that only one Source ID value is 
   used inside each stream. If the Collecting Process detects that more 
   than one Source ID has been received within a stream, it MUST 
   discard the IPFIX Message, reset the SCTP association, and SHOULD 
   log the error."
	Remove "IPFIX Messages with a Source ID of zero MUST be discarded by the  
   Collecting Process."

Regards, Benoit

--------------070801020204050902090906-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Platt@gastwirth.com Thu May 12 22:16:12 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05255 for ; Thu, 12 May 2005 22:16:10 -0400 (EDT) Received: from 81-202-53-243.user.ono.com ([81.202.53.243] helo=gastwirth.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DWPXd-00047Z-00 for ipfix-list@mil.doit.wisc.edu; Thu, 12 May 2005 21:04:43 -0500 From: "Pepe Platt" To: "Savina Sweeney" Subject: =?iso-8859-1?Q?C=ECALISS_V=C01iUM_Vl=C0GGRA?= Date: Thu, 12 May 2005 22:04:38 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C56EAA.42840B36" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?81.202.53.243 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C56EAA.42840B36 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, considered, said Mr. Blood. man of considerable parts, from what else this Cahusac told me. Whom have you here with you? What servants? he demanded sharpl days. Then on a brisker note he added: We dine in an hour, and invitation. half-mile away, and a vision of her face went with him, tinted wi which had been so thoroughly simulated. They set themselves to Now don't be rash. My men are within their rights, as you are Have a nice day. ------=_NextPart_000_0008_01C56EAA.42840B36 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello, = How would you like to spend Iess on your druggs?
 
 
Save over 60 % with = PharamcyByMaill SHOP.
 
Have a nice day.
 
considered, said Mr.
Blood. = man of considerable parts, from what else this Cahusac told me.
= Whom have you here with you? What servants? he demanded
sharpl = days. Then on a brisker note he added: We dine in an hour,
and = invitation
. = half-mile away, and a vision of her face went with him, tinted
wi = which had been so thoroughly simulated. They set themselves
to = Now don't be rash. My men are within their rights, as you
are =
------=_NextPart_000_0008_01C56EAA.42840B36-- From majordomo@mil.doit.wisc.edu Fri May 13 06:09:08 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29373 for ; Fri, 13 May 2005 06:09:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWWq5-00002c-00 for ipfix-list@mil.doit.wisc.edu; Fri, 13 May 2005 04:52:13 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWWq4-00002U-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 13 May 2005 04:52:12 -0500 Received: from [10.147.67.235] (i4dhcp235 [10.147.67.235]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j4D9q8O21326; Fri, 13 May 2005 11:52:08 +0200 (MEST) Message-ID: <428478C8.4090603@fokus.fraunhofer.de> Date: Fri, 13 May 2005 11:52:08 +0200 From: Tanja Zseby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] One correction in the "octets" information elements References: <427881C3.90200@cisco.com> <427F27E7.4070604@cisco.com> <734945E7C5440C3DB70E6368@753F3B888A9969457862729D> In-Reply-To: <734945E7C5440C3DB70E6368@753F3B888A9969457862729D> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.fraunhofer.de id j4D9q8O21326 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Hi J=FCrgen and Benoit, I think that it is extremely important to have the IP octet counter=20 consistent, so that always the same is counted regardless of the traffic=20 (e.g. whether it is MPLS or not). So I would prefer to have one counter=20 that only counts the IP octets. Since counting IP+MPLS may be of=20 advantage for capacity planing etc., I think the best solution is to=20 provide a further counter as J=FCrgen proposed. Regards Tanja Juergen Quittek wrote: > > > --On 5/9/2005 11:05 AM +0200 Benoit Claise wrote: > >> Juergen, >> >>> Hi Benoit, >>> >>> --On 5/4/2005 10:03 AM +0200 Benoit Claise wrote: >>> >>>> Juergen, >>>> >>>> We realized that the Information Element #1 octetDeltaCount, >>>> which is in line with NetFlow version 9, is not correctly specified. >>>> >>>> 5.9.1 octetDeltaCount >>>> Description: >>>> The number of octets since the previous report (if any) in >>>> incoming packets for this flow at the Observation Point. The >>>> number of octets include IP header(s) and IP payload. >>>> >>>> -> New Description: >>>> The number of octets since the previous report (if any) in >>>> incoming packets for this flow at the Observation Point. The >>>> number of octets exclude the data link header and trailer. >>>> >>>> This allows to account for the length of MPLS labels, for the ISL >>>> bytes, etc... >>> >>> >>> >>> I see the following problems with this change. >>> >>> - This implies that we count more than just the IP packet. >>> Since this is counter is fundamental for IPFIX, we would need >>> to discuss precisely what is measured. I do not like the >>> inclusion of non-IP octets in the count to be hidden in these >>> three lines. >>> >>> - How useful would this information be? >> >> >> Just one example: capacity planning with a MPLS core, when you want=20 >> to know exactly what has been sent and not only the IP part of the=20 >> packet. >> >>> How would the collector >>> know that the MPLS labels are included in the count? >> >> >> Counted by default. >> >>> >>> - Even if the collector knows that MPLS labels are included in the >>> count, it would not be able to just subtract them for calculating >>> the pure IP octet number, because it does not necessarily known >>> how many labels are on the label stack. >> >> >> If you really want to do it, you can export the number of labels as a=20 >> different I.E. >> >>> >>> - Which information elements should a device use that supports MPLS >>> but is able to calculate the precise IP octet count, for example >>> at the end of the MPLS tunnel where both counts (with and without >>> labels) are available? Instead of defining another information >>> element for this case, I would rather define a new one for the >>> IP+MPLS octet counter. >> >> >> Defining a new set of counters might prove to be the only remaining=20 >> solution. >> I would keep the I.E. #1 (octetDeltaCount) for IP + MPLS, as this is=20 >> what NetFlow version 9 does now. > > > What about renaming #1 to subIpOctetDeltaCount and introducing a new=20 > one for pure IP > that will then inherit the name octetDeltaCount? > (Sub-IP was the name of the IETF area that dealt with MPLS.) > We probably would have to do this for all counters of octets in=20 > packets, i.e. > > postOctetDeltaCount #23, octetTotalCount #85, postMulticastOctetCount=20 > #20, > postOctetTotalCount #160, droppedOctetDeltaCount #132,=20 > droppedOctetTotalCount #134. > > Cheers, > > Juergen --=20 Dipl.-Ing. Tanja Zseby =09 Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de=09 Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------= -------------=20 "Living on earth is expensive but it includes a free trip around the sun.= " (Anonymous) -------------------------------------------------------------------------= ------------- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 13 10:28:44 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20631 for ; Fri, 13 May 2005 10:28:44 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWaqD-0003JB-00 for ipfix-list@mil.doit.wisc.edu; Fri, 13 May 2005 09:08:37 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWaqC-0003J6-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 13 May 2005 09:08:36 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4DE8Zq05632; Fri, 13 May 2005 10:08:35 -0400 (EDT) Received: from [10.61.82.33] (ams-clip-vpn-dhcp4642.cisco.com [10.61.82.33]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4DE8XK11074; Fri, 13 May 2005 16:08:33 +0200 (CEST) Message-ID: <4284B4DF.8020502@cisco.com> Date: Fri, 13 May 2005 16:08:31 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tanja Zseby CC: Juergen Quittek , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] One correction in the "octets" information elements References: <427881C3.90200@cisco.com> <427F27E7.4070604@cisco.com> <734945E7C5440C3DB70E6368@753F3B888A9969457862729D> <428478C8.4090603@fokus.fraunhofer.de> In-Reply-To: <428478C8.4090603@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-rtp.cisco.com id j4DE8Zq05632 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Dear all, I've been thinking about this issue for some time and I'm wondering if=20 we're not going in the wrong direction. Let me explain Tanja is right that IPFIX needs some consistent counters definitions.=20 After all, these counters are the fundamental information elements in=20 IPFIX, as Juergen explained. Personally, I see some value in exporting counters with "The number of=20 octets exclude the data link header and trailer." as opposed to "The=20 number of octets include IP header(s) and IP payload.". However, I=20 understand both the pros and cons arguments. These pros and cons arguments logically lead to the creation of two=20 series of counters, one for subIP and one for IP. Note that a series is composed of counters for all the combinations of=20 (pre/post, delta/total, dropped or not, multicast or not), so A LOT OF=20 counters. If we start to systematically multiply the number of counters per=20 technology, we will have so many to choose from that it can be a risk=20 for interoperability. Another risk is that we could multiply the counterS for any new=20 technology to monitor: MPLS? ISL? dot1q? something else in the future?=20 If we want to be complete, we should duplicate all the counters each time. Maybe we want to take a step back, and keep a single series of counters.=20 If the consensus is "The number of octets include IP header(s) and IP=20 payload." as it was initially in the draft, fair enough. At least we=20 would keep IPFIX simple. If a vendor would like to use a very specific I.E. (ex: number of octets=20 including the MPLS labels length), this could still be done with an=20 enterprise-specific I.E., with an extra I.E (example: exporting the=20 number of labels would allow to recompute the MPLS + IP length), with a=20 request to IANA for one specific I.E. In this last case, it would be=20 based on customer requests, so a good reason, as opposed trying to=20 specify a full set of I.E. at the IPFIX information model creation time. In conclusion, I don't think multiplying all the counters is a good=20 choice for the future adoption of IPFIX. Feedback? Regards, Benoit. > Hi J=FCrgen and Benoit, > > I think that it is extremely important to have the IP octet counter=20 > consistent, so that always the same is counted regardless of the=20 > traffic (e.g. whether it is MPLS or not). So I would prefer to have=20 > one counter that only counts the IP octets. Since counting IP+MPLS may=20 > be of advantage for capacity planing etc., I think the best solution=20 > is to provide a further counter as J=FCrgen proposed. > > Regards > Tanja > > > Juergen Quittek wrote: > >> >> >> --On 5/9/2005 11:05 AM +0200 Benoit Claise wrote: >> >>> Juergen, >>> >>>> Hi Benoit, >>>> >>>> --On 5/4/2005 10:03 AM +0200 Benoit Claise wrote: >>>> >>>>> Juergen, >>>>> >>>>> We realized that the Information Element #1 octetDeltaCount, >>>>> which is in line with NetFlow version 9, is not correctly specified. >>>>> >>>>> 5.9.1 octetDeltaCount >>>>> Description: >>>>> The number of octets since the previous report (if any) in >>>>> incoming packets for this flow at the Observation Point. The >>>>> number of octets include IP header(s) and IP payload. >>>>> >>>>> -> New Description: >>>>> The number of octets since the previous report (if any) in >>>>> incoming packets for this flow at the Observation Point. The >>>>> number of octets exclude the data link header and trailer. >>>>> >>>>> This allows to account for the length of MPLS labels, for the ISL >>>>> bytes, etc... >>>> >>>> >>>> >>>> >>>> I see the following problems with this change. >>>> >>>> - This implies that we count more than just the IP packet. >>>> Since this is counter is fundamental for IPFIX, we would need >>>> to discuss precisely what is measured. I do not like the >>>> inclusion of non-IP octets in the count to be hidden in these >>>> three lines. >>>> >>>> - How useful would this information be? >>> >>> >>> >>> Just one example: capacity planning with a MPLS core, when you want=20 >>> to know exactly what has been sent and not only the IP part of the=20 >>> packet. >>> >>>> How would the collector >>>> know that the MPLS labels are included in the count? >>> >>> >>> >>> Counted by default. >>> >>>> >>>> - Even if the collector knows that MPLS labels are included in the >>>> count, it would not be able to just subtract them for calculating >>>> the pure IP octet number, because it does not necessarily known >>>> how many labels are on the label stack. >>> >>> >>> >>> If you really want to do it, you can export the number of labels as=20 >>> a different I.E. >>> >>>> >>>> - Which information elements should a device use that supports MPLS >>>> but is able to calculate the precise IP octet count, for example >>>> at the end of the MPLS tunnel where both counts (with and without >>>> labels) are available? Instead of defining another information >>>> element for this case, I would rather define a new one for the >>>> IP+MPLS octet counter. >>> >>> >>> >>> Defining a new set of counters might prove to be the only remaining=20 >>> solution. >>> I would keep the I.E. #1 (octetDeltaCount) for IP + MPLS, as this is=20 >>> what NetFlow version 9 does now. >> >> >> >> What about renaming #1 to subIpOctetDeltaCount and introducing a new=20 >> one for pure IP >> that will then inherit the name octetDeltaCount? >> (Sub-IP was the name of the IETF area that dealt with MPLS.) >> We probably would have to do this for all counters of octets in=20 >> packets, i.e. >> >> postOctetDeltaCount #23, octetTotalCount #85, postMulticastOctetCount=20 >> #20, >> postOctetTotalCount #160, droppedOctetDeltaCount #132,=20 >> droppedOctetTotalCount #134. >> >> Cheers, >> >> Juergen > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 13 10:54:44 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22581 for ; Fri, 13 May 2005 10:54:43 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWbPh-00050s-00 for ipfix-list@mil.doit.wisc.edu; Fri, 13 May 2005 09:45:17 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWbPg-00050n-00 for ipfix-info@net.doit.wisc.edu; Fri, 13 May 2005 09:45:16 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4DEjBa21447; Fri, 13 May 2005 10:45:11 -0400 (EDT) Received: from [10.61.82.33] (ams-clip-vpn-dhcp4642.cisco.com [10.61.82.33]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4DEj5K14281; Fri, 13 May 2005 16:45:05 +0200 (CEST) Message-ID: <4284BD70.2010700@cisco.com> Date: Fri, 13 May 2005 16:45:04 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Ji CC: Danny McPherson , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] BGP related Information Elements References: <426E5295.8080602@cisco.com> <7ab543168fd86ef01096ded6d744219f@tcb.net> <4278D8B1.2030003@cisco.com> <427F4532.8050202@cisco.com> <427FABD1.4010605@yahoo-inc.com> <427FBB91.6000502@cisco.com> <42812B04.8090807@yahoo-inc.com> <4281A678.8080808@cisco.com> <42824B5D.2090209@yahoo-inc.com> In-Reply-To: <42824B5D.2090209@yahoo-inc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Eric, Then the wording should be something like this: "In case the BGP AS can't be easily retrieved (for example in case of AS-SET), the value 0 is reported." So this sentence should replace all the instances of "In case of AS-SET, the value of 0 is reported." in the proposal at http://ipfix.doit.wisc.edu/archive/2796.html Do we all agree? If not, you should propose your own text. Regards, benoit. > Benoit, > > I think I didn't express well. What I meant was is to get _the_ AS, > i.e., the real single adjacent AS. We can't get that from AS_SET. But > under certain situations, it can be get from BGP other part rather > than ASpath, as said in previous email, or new ways to discover it > later on. So I proposed to add that line, to keep the door open for > those. Then the exporter would do a best effort on this, and report 0 > only when all current methods fails. > > Regards, > Eric > > > Benoit Claise wrote: > >> Eric, >> >>> Benoit, >>> >>> Now that it's already used, I have no issue with keeping it, given >>> that its limitation is well documented. >>> >>> Another minor points, we may change the following wording, >>> "In case of AS-SET, the value of 0 is reported." to >>> "In case of AS-SET, and can't be easily retrieved from BGP, the >>> value 0 is reported." >>> That leaves space for other ways to get this information now, such >>> as through ebgp neighbor AS for edge routers. And it doesnt close >>> the door for new ways to discover this later on, such as examining >>> the exit point or topology. >> >> >> >> Do you want to say "In case of AS-SET or can't be easily retrieved >> from BGP, the value 0 is reported."? >> Because, even with AS-SET, the AS can be easily retrieved. The issue >> is to export it in IPFIX :) >> >> Regards, Benoit. >> >>> >>> Regards, >>> Eric >>> >>> >>> Benoit Claise wrote: >>> >>>> Eric, >>>> >>>>> >>>>> Nice work. I'd propose to remove bgpSrcAdjacentASNumber. It's not >>>>> uncommon that BGP asymmetry happens a lot in real world, and this >>>>> element may cause problem in real use for applications built on, >>>>> if it reports wrong information. And there's no easy way to verify >>>>> that inside IPFIX itself. >>>> >>>> >>>> >>>> >>>> >>>> I share with your concern. >>>> However, I propose to keep this I.E.s for 2 reasons. >>>> 1. This BGP asymmetry and peer source AS / asymmetry issue is not >>>> new: we do already export this value in NetFlow version 9 today. >>>> 2. you will have a wrong value for bgpSrcAdjacentASNumber only in >>>> the case of multi-access interfaces (typically an ethernet >>>> interface at an IXP). In other interface types, you would be able >>>> to deduce if the value is correct or not, i.e. if there is some >>>> asymmetry >>>> >>>> Regards, Benoit. >>>> >>>>> >>>>> Regards, >>>>> Eric >>>>> >>>>> >>>>> Benoit Claise wrote: >>>>> >>>>>> Danny and all, >>>>>> >>>>>> In order to continue the discussion with a clear basis, here is >>>>>> the list of proposed BGP-related I.E.s. I've been trying to >>>>>> insert all suggestions. >>>>>> This should answer some of your questions below. >>>>>> Feel free to review and to propose some new text if some >>>>>> improvements are required. >>>>>> >>>>>> | 16 | bgpSourceAsNumber | 17 | >>>>>> bgpDestinationAsNumber >>>>>> | 18 | bgpNextHopIpV4Address >>>>>> | 63 | bgpNextHopIpV6Address >>>>>> | 128 | bgpNextHopAsNumber >>>>>> | 129 | ipNextHopAsNumber >>>>>> >>>>>> 5.4.4 bgpSourceAsNumber >>>>>> Description: >>>>>> The autonomous system (AS) number of the source address in >>>>>> the IP >>>>>> packet headers of this flow. In case of AS-SET, the >>>>>> value of 0 is reported. >>>>>> >>>>>> Abstract Data Type: unsigned16 >>>>>> >>>>>> Data Type Semantics: identifier >>>>>> >>>>>> ElementId: 16 >>>>>> >>>>>> Status: current >>>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>>> >>>>>> >>>>>> 5.4.5 bgpDestinationAsNumber >>>>>> Description: >>>>>> The autonomous system (AS) number of the destination address in >>>>>> the IP packet headers this flow. In case of AS-SET, the >>>>>> value of 0 is reported. >>>>>> >>>>>> Abstract Data Type: unsigned16 >>>>>> >>>>>> Data Type Semantics: identifier >>>>>> >>>>>> ElementId: 17 >>>>>> >>>>>> Status: current >>>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>>> >>>>>> >>>>>> 5.4.7 bgpNextHopIpV4Address >>>>>> Description: >>>>>> The IPv4 address of the next BGP hop to which packets of >>>>>> this flow >>>>>> are forwarded. >>>>>> >>>>>> Abstract Data Type: ipv4Address >>>>>> >>>>>> Data Type Semantics: identifier >>>>>> >>>>>> ElementId: 18 >>>>>> >>>>>> Status: current >>>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>>> >>>>>> >>>>>> 5.4.8 bgpNextHopIpV6Address >>>>>> Description: >>>>>> The IPv6 address of the next BGP hop to which packets of >>>>>> this flow >>>>>> are forwarded. >>>>>> >>>>>> Abstract Data Type: ipv6Address >>>>>> >>>>>> Data Type Semantics: identifier >>>>>> >>>>>> ElementId: 63 >>>>>> >>>>>> Status: current >>>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>>> 5.4.6 bgpDstAdjacentASNumber >>>>>> Description: >>>>>> The autonomous system (AS) number of the first AS in the AS >>>>>> path to which packets of this flow are forwarded, deduced by >>>>>> looking up the source IP address of the flow in the BGP routing >>>>>> information base. In case of AS-SET, the value of 0 is reported. >>>>>> >>>>>> Abstract Data Type: unsigned16 >>>>>> >>>>>> Data Type Semantics: identifier >>>>>> >>>>>> ElementId: 128 >>>>>> >>>>>> Status: current >>>>>> >>>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>>> >>>>>> 5.4.6 bgpSrcAdjacentASNumber >>>>>> >>>>>> Description: >>>>>> The autonomous system (AS) number of the last AS in the AS >>>>>> path from which packets of this flow arrived, deduced by looking >>>>>> up the source IP address of the flow in the BGP routing >>>>>> information base. In case of BGP asymmetry, the >>>>>> bgpSrcAdjacentASNumber might not be able to report the correct >>>>>> value. In case of AS-SET, the value of 0 is reported. >>>>>> >>>>>> Data Type Semantics: identifier >>>>>> >>>>>> ElementId: 129 >>>>>> >>>>>> Status: current >>>>>> >>>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>>> >>>>>> >>>>>> >>>>>> See inline. >>>>>> >>>>>>> >>>>>>> On May 4, 2005, at 8:14 AM, Benoit Claise wrote: >>>>>>> >>>>>>>> I think we have a technical problem right now in IPFIX. We >>>>>>>> can't report an AS_SET. How can we report that the >>>>>>>> bgpDstAdjacentASNumber is not a single unsigned16, but list of >>>>>>>> unsigned16? This is not possible! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Right.. >>>>>>> >>>>>>>> So a quick and dirty solution... why not say: export 0 for AS_SET. >>>>>>>> Anyway, reporting the AS_SET is not that useful on the >>>>>>>> collector. If AS_SET = (100, 200, 300), it means that most >>>>>>>> specific routes of this aggregate prefix comes from either >>>>>>>> 100, either 200, either 300. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This would have to apply uniformly across all these elements, as >>>>>>> any of these could return AS_SET: >>>>>>> >>>>>>> 16 bgpSourceAsNumber >>>>>>> 17 bgpDestinationAsNumber >>>>>>> 128 bgpNextAdjacentAsNumber >>>>>>> 129 bgpPreviousAdjacentAsNumber >>>>>>> 149 ipNextHopAsNumber >>>>>>> >>>>>>> I would suspect that 16, 17 and 149 would very frequently >>>>>>> reside within the local AS >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> BTW, typo 149 -> 129. >>>>>> I don't see how the local AS would be reported with the >>>>>> definitions of 16/17. >>>>>> The definition of 129 has been changed. I guess it's ok now. >>>>>> >>>>>>> - which would most intuitively be >>>>>>> represented by '0', I think.. For that matter, any of these >>>>>>> could return local AS (or is it no_adjacent_AS? :-) >>>>>>> >>>>>>> Given my admittedly terse review of the draft, I don't see >>>>>>> behavior defined for where these values should be derived, >>>>>>> and in particular, how local AS (or no AS?) should be >>>>>>> reported. Do you envision local AS being reported as a >>>>>>> function of the router knowing what AS the local BGP process >>>>>>> resides in? Else that local AS value isn't added to the path >>>>>>> until advertised to an eBGP peer. >>>>>>> >>>>>>> I'd be a bit cautious about using '0', and perhaps specify >>>>>>> that local AS (and no AS) always return '0'. This would >>>>>>> align with the BGP Spec: >>>>>>> >>>>>>> [snip from BGP spec] >>>>>>> When a BGP speaker originates a route then: >>>>>>> >>>>>>> a) the originating speaker includes its own AS number in a path >>>>>>> segment of type AS_SEQUENCE in the AS_PATH attribute of all >>>>>>> UPDATE >>>>>>> messages sent to an external peer. (In this case, the AS >>>>>>> number of >>>>>>> the originating speaker's autonomous system will be the only >>>>>>> entry >>>>>>> the path segment, and this path segment will be the only segment >>>>>>> in the AS_PATH attribute). >>>>>>> >>>>>>> b) the originating speaker includes an empty AS_PATH attribute in >>>>>>> all UPDATE messages sent to internal peers. (An empty AS_PATH >>>>>>> attribute is one whose length field contains the value zero). >>>>>>> >>>>>>> [/snip] >>>>>>> >>>>>>> So given b) above, returning zero for local AS wold seem intuitive. >>>>>>> >>>>>>> As for accommodating AS_SET, I'm not quite sure. Would it be >>>>>>> unreasonable to report multiple elements of the same type here if >>>>>>> an AS_SET is returned, or is this a bad idea (I expect so)? >>>>>>> >>>>>> One solution could be to specify multiple new AS-SET related >>>>>> I.E., such mplsLabelStackEntryX in MPLS. >>>>>> >>>>>> My personal view is that (in order to finish this IPFIX work who >>>>>> has been lasting to long IMHO ;)), we should post the draft with >>>>>> the I.E.s we require right now, and use the IANA procedure for >>>>>> any other I.E.s. Otherwise, I fear the job will never be finished. >>>>>> >>>>>>> >>>>>>> To further complicate things, I suspect we'll be seeing >>>>>>> this in deployments within a couple years, per AS number >>>>>>> depletion: >>>>>>> >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-09.txt >>>>>>> >>>>>>> I'm not sure if we want to worry about it now or define >>>>>>> new elements down the road.. >>>>>>> >>>>>>> Regarding 149, ipNextHopAsNumber: >>>>>>> >>>>>>> ----- >>>>>>> 5.6.3 ipNextHopAsNumber >>>>>>> Description: >>>>>>> The autonomous system (AS) number of the next IP hop to which >>>>>>> packets of this flow are forwarded. >>>>>>> >>>>>>> Abstract Data Type: unsigned16 >>>>>>> >>>>>>> Data Type Semantics: identifier >>>>>>> >>>>>>> ElementId: 149 >>>>>>> >>>>>>> Status: current >>>>>>> Reference: See RFC 1771 for a description of BGP-4 and see >>>>>>> RFC 1930 a >>>>>>> definition of the AS number. >>>>>>> ----- >>>>>>> >>>>>>> Is this element returning the AS number for the IP address reported >>>>>>> in the BGP NEXT_HOP attribute associated with the destination >>>>>>> prefix, >>>>>>> or it the RIB/FIB IP "next hop" used to reach that destination? >>>>>>> This >>>>>>> should be stated explicitly. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I hope the new definition above is OK now. >>>>>> >>>>>> Regards, Benoit. >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> Note the "Previous" in the name above. Also, should you say >>>>>>>>> something about >>>>>>>>> source and destination prefixes here and above, it might help >>>>>>>>> implementers, per >>>>>>>>> this would be a "first" or "leftmost" AS segment in the >>>>>>>>> AS_PATH for the source >>>>>>>>> IP prefix in the BGP Loc-RIB that contains the source IP >>>>>>>>> prefix, while above it's >>>>>>>>> the destination prefix, etc.. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Any proposal? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Not sure if these are any better, but: >>>>>>> >>>>>>> 5.4.4 bgpSourceAsNumber >>>>>>> Description: >>>>>>> The first (origin) autonomous system (AS) number for the >>>>>>> prefix containing the source address in the IP packet header >>>>>>> in a packet of this flow. >>>>>>> >>>>>>> 5.4.5 bgpDestinationAsNumber >>>>>>> Description: >>>>>>> The first (origin) autonomous system (AS) number for the >>>>>>> prefix containing the destination address in the IP packet >>>>>>> header in a packet of this flow. >>>>>>> >>>>>>> >>>>>>> And I'd still like to see similar information elements added for >>>>>>> AS_CONFED_SET & AS_CONFED_SEQUENCE. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> As expressed above, if you require them, make a proposal. >>>>>> >>>>>> Regards, Benoit. >>>>>> >>>>>>> >>>>>>> -danny >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>> message body >>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>> "unsubscribe ipfix" in message body >>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 13 11:42:39 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25288 for ; Fri, 13 May 2005 11:42:39 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWcEG-0006UI-00 for ipfix-list@mil.doit.wisc.edu; Fri, 13 May 2005 10:37:32 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWcEF-0006UD-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 13 May 2005 10:37:31 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.13) with ESMTP id j4DFbRT4013527 for ; Fri, 13 May 2005 11:37:29 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id j4DFbPTa013522 for ; Fri, 13 May 2005 11:37:25 -0400 Received: from ioannes.indigo.cert.org (ioannes.indigo.cert.org [10.60.10.57]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id j4DFbOCK013520; Fri, 13 May 2005 11:37:24 -0400 (EDT) Received: from [128.237.224.173] (vpn-10-25-4-3.remote.cert.org [10.25.4.3]) by ioannes.indigo.cert.org (8.12.8/8.12.8/2.42.1.1) with ESMTP id j4DFbOaj032194; Fri, 13 May 2005 11:37:24 -0400 In-Reply-To: <4284B4DF.8020502@cisco.com> References: <427881C3.90200@cisco.com> <427F27E7.4070604@cisco.com> <734945E7C5440C3DB70E6368@753F3B888A9969457862729D> <428478C8.4090603@fokus.fraunhofer.de> <4284B4DF.8020502@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-252486760" Message-Id: <09db4594d61a790daa44dd171c06bfab@cert.org> Content-Transfer-Encoding: 7bit Cc: ipfix-protocol@net.doit.wisc.edu, Juergen Quittek , Tanja Zseby From: Brian Trammell Subject: Re: [ipfix-protocol] One correction in the "octets" information elements Date: Fri, 13 May 2005 11:37:20 -0400 To: Benoit Claise X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.622) X-Spam-Status: No, hits=-2.4 required=5 tests=ALL_TRUSTED checker=SpamAssassin version=3.000003 X-Scanned-By: MIMEDefang 2.51 on 192.88.209.10 Precedence: bulk Sender: majordomo listserver --Apple-Mail-5-252486760 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Benoit, I strongly agree, for two reasons. From a protocol simplicity standpoint, IPFIX is basically a key-value protocol with a flat key space. The issue at hand seems to come up quite often for flat key spaces, that is, at some point it seems to make sense to "tree up" the key space a little, and suddenly you've got combinatorial explosion and you're completely out of bits. Given that it seems like we don't want to tear the protocol down to the studs and throw out the flatness of the key space (thereby making "real" implementations infeasible on the router side), avoiding this combinatorial explosion is a very good thing. Second, and this is a little more selfish, I'm interested in IPFIX for network security applications. IP is really all that matters to me, because it's all that's visible at the end-node. I'm not an operator, and I'm not well-versed in either of the dark arts of MPLS or capacity planning in general, but it seems label sized should be relatively estimable; that is, by looking at the packet counters you can roughly account for sub-IP overhead on your network. It doesn't seem that the results WRT capacity planning from this admittedly less-optimal solution are significantly worse than counting every last sub-IP octet. One concern: from the router-side implementation standpoint, are there performance implications for mandating that only IP octets be counted on an MPLS network? Regards, Brian On May 13, 2005, at 10:08 AM, Benoit Claise wrote: > Dear all, > > I've been thinking about this issue for some time and I'm wondering if > we're not going in the wrong direction. Let me explain > > Tanja is right that IPFIX needs some consistent counters definitions. > After all, these counters are the fundamental information elements in > IPFIX, as Juergen explained. > > Personally, I see some value in exporting counters with "The number of > octets exclude the data link header and trailer." as opposed to "The > number of octets include IP header(s) and IP payload.". However, I > understand both the pros and cons arguments. > These pros and cons arguments logically lead to the creation of two > series of counters, one for subIP and one for IP. > Note that a series is composed of counters for all the combinations of > (pre/post, delta/total, dropped or not, multicast or not), so A LOT OF > counters. > > If we start to systematically multiply the number of counters per > technology, we will have so many to choose from that it can be a risk > for interoperability. > Another risk is that we could multiply the counterS for any new > technology to monitor: MPLS? ISL? dot1q? something else in the future? > If we want to be complete, we should duplicate all the counters each > time. > > Maybe we want to take a step back, and keep a single series of > counters. If the consensus is "The number of octets include IP > header(s) and IP payload." as it was initially in the draft, fair > enough. At least we would keep IPFIX simple. > > If a vendor would like to use a very specific I.E. (ex: number of > octets including the MPLS labels length), this could still be done > with an enterprise-specific I.E., with an extra I.E (example: > exporting the number of labels would allow to recompute the MPLS + IP > length), with a request to IANA for one specific I.E. In this last > case, it would be based on customer requests, so a good reason, as > opposed trying to specify a full set of I.E. at the IPFIX information > model creation time. > > In conclusion, I don't think multiplying all the counters is a good > choice for the future adoption of IPFIX. > Feedback? > > Regards, Benoit. > -- Brian H. Trammell / MTS, CERT/NetSA / / 412.268.9748 --Apple-Mail-5-252486760 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFChMmz4/8LCZ4pwvYRAhJLAKC5VZEKRcHy3jitdoqK9Ac12fOPawCgzUTD yoWyp/FNCK3Bl3zqdNq/XEU= =8pBd -----END PGP SIGNATURE----- --Apple-Mail-5-252486760-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 13 11:49:44 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25986 for ; Fri, 13 May 2005 11:49:43 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWcBq-0006Sl-00 for ipfix-list@mil.doit.wisc.edu; Fri, 13 May 2005 10:35:02 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWcBp-0006SM-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 13 May 2005 10:35:01 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 13 May 2005 17:35:01 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4DFYvVe000477; Fri, 13 May 2005 17:34:57 +0200 (MEST) Received: from cisco.com (ams-clip-vpn-dhcp291.cisco.com [10.61.65.35]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA01124; Fri, 13 May 2005 16:34:55 +0100 (BST) Message-ID: <4284C91F.7060000@cisco.com> Date: Fri, 13 May 2005 16:34:55 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tanja Zseby CC: Juergen Quittek , Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] One correction in the "octets" information elements References: <427881C3.90200@cisco.com> <427F27E7.4070604@cisco.com> <734945E7C5440C3DB70E6368@753F3B888A9969457862729D> <428478C8.4090603@fokus.fraunhofer.de> In-Reply-To: <428478C8.4090603@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit I have been out of the loop, so sorry for jumping into the middle of the thread. Tanja Zseby wrote: > Hi Jürgen and Benoit, > > I think that it is extremely important to have the IP octet counter > consistent, so that always the same is counted regardless of the traffic > (e.g. whether it is MPLS or not). So I would prefer to have one counter > that only counts the IP octets. I agree. We need this simple counter, no matter what else we do. > Since counting IP+MPLS may be of > advantage for capacity planing etc., I think the best solution is to > provide a further counter as Jürgen proposed. Do we want to have one counter per type, or a compound counter that is the bitmask of included fields, followed by value itself. i.e. to define an IE of the form: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | | | | | | | | | 64 bit Counter value......... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ^ ^ ^ ^ ^ ^ ^ ^ | | | | | +-+-+- Reserved must be zero | | | | +------- Datalink trailer | | | +--------- Payload | | +----------- IP header | +------------- MPLS label Stack +--------------- datalink header This would allow the exporter to provide a counter of whatever type the application needed. - Stewart > > Regards > Tanja > > > Juergen Quittek wrote: > >> >> >> --On 5/9/2005 11:05 AM +0200 Benoit Claise wrote: >> >>> Juergen, >>> >>>> Hi Benoit, >>>> >>>> --On 5/4/2005 10:03 AM +0200 Benoit Claise wrote: >>>> >>>>> Juergen, >>>>> >>>>> We realized that the Information Element #1 octetDeltaCount, >>>>> which is in line with NetFlow version 9, is not correctly specified. >>>>> >>>>> 5.9.1 octetDeltaCount >>>>> Description: >>>>> The number of octets since the previous report (if any) in >>>>> incoming packets for this flow at the Observation Point. The >>>>> number of octets include IP header(s) and IP payload. >>>>> >>>>> -> New Description: >>>>> The number of octets since the previous report (if any) in >>>>> incoming packets for this flow at the Observation Point. The >>>>> number of octets exclude the data link header and trailer. >>>>> >>>>> This allows to account for the length of MPLS labels, for the ISL >>>>> bytes, etc... >>>> >>>> >>>> >>>> >>>> I see the following problems with this change. >>>> >>>> - This implies that we count more than just the IP packet. >>>> Since this is counter is fundamental for IPFIX, we would need >>>> to discuss precisely what is measured. I do not like the >>>> inclusion of non-IP octets in the count to be hidden in these >>>> three lines. >>>> >>>> - How useful would this information be? >>> >>> >>> >>> Just one example: capacity planning with a MPLS core, when you want >>> to know exactly what has been sent and not only the IP part of the >>> packet. >>> >>>> How would the collector >>>> know that the MPLS labels are included in the count? >>> >>> >>> >>> Counted by default. >>> >>>> >>>> - Even if the collector knows that MPLS labels are included in the >>>> count, it would not be able to just subtract them for calculating >>>> the pure IP octet number, because it does not necessarily known >>>> how many labels are on the label stack. >>> >>> >>> >>> If you really want to do it, you can export the number of labels as a >>> different I.E. >>> >>>> >>>> - Which information elements should a device use that supports MPLS >>>> but is able to calculate the precise IP octet count, for example >>>> at the end of the MPLS tunnel where both counts (with and without >>>> labels) are available? Instead of defining another information >>>> element for this case, I would rather define a new one for the >>>> IP+MPLS octet counter. >>> >>> >>> >>> Defining a new set of counters might prove to be the only remaining >>> solution. >>> I would keep the I.E. #1 (octetDeltaCount) for IP + MPLS, as this is >>> what NetFlow version 9 does now. >> >> >> >> What about renaming #1 to subIpOctetDeltaCount and introducing a new >> one for pure IP >> that will then inherit the name octetDeltaCount? >> (Sub-IP was the name of the IETF area that dealt with MPLS.) >> We probably would have to do this for all counters of octets in >> packets, i.e. >> >> postOctetDeltaCount #23, octetTotalCount #85, postMulticastOctetCount >> #20, >> postOctetTotalCount #160, droppedOctetDeltaCount #132, >> droppedOctetTotalCount #134. >> >> Cheers, >> >> Juergen > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri May 13 14:42:26 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12976 for ; Fri, 13 May 2005 14:42:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWetY-0005LN-00 for ipfix-list@mil.doit.wisc.edu; Fri, 13 May 2005 13:28:20 -0500 Received: from mrout1.yahoo.com ([216.145.54.171]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWetX-0005LI-00 for ipfix-info@net.doit.wisc.edu; Fri, 13 May 2005 13:28:19 -0500 Received: from [66.228.162.78] (snapdragon.corp.yahoo.com [66.228.162.78]) by mrout1.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j4DIRIDK037199; Fri, 13 May 2005 11:27:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:x-accept-language: mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=iSzbwomg7Q6cuzB75PLVAtfIFOjYr5ZJpBwJcSE3ChXUcHi0pGGhSxF6bkAKqv7o Message-ID: <4284F186.9060500@yahoo-inc.com> Date: Fri, 13 May 2005 11:27:18 -0700 From: Eric Ji User-Agent: Mozilla Thunderbird 0.9 (X11/20041116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: Danny McPherson , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] BGP related Information Elements References: <426E5295.8080602@cisco.com> <7ab543168fd86ef01096ded6d744219f@tcb.net> <4278D8B1.2030003@cisco.com> <427F4532.8050202@cisco.com> <427FABD1.4010605@yahoo-inc.com> <427FBB91.6000502@cisco.com> <42812B04.8090807@yahoo-inc.com> <4281A678.8080808@cisco.com> <42824B5D.2090209@yahoo-inc.com> <4284BD70.2010700@cisco.com> In-Reply-To: <4284BD70.2010700@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit, That's good. I agree with that. Regards, Eric Benoit Claise wrote: > Eric, > > Then the wording should be something like this: > "In case the BGP AS can't be easily retrieved (for example in case of > AS-SET), the value 0 is reported." > > So this sentence should replace all the instances of "In case of AS-SET, > the value of 0 is reported." in the proposal at > http://ipfix.doit.wisc.edu/archive/2796.html > > Do we all agree? If not, you should propose your own text. > > Regards, benoit. > >> Benoit, >> >> I think I didn't express well. What I meant was is to get _the_ AS, >> i.e., the real single adjacent AS. We can't get that from AS_SET. But >> under certain situations, it can be get from BGP other part rather >> than ASpath, as said in previous email, or new ways to discover it >> later on. So I proposed to add that line, to keep the door open for >> those. Then the exporter would do a best effort on this, and report 0 >> only when all current methods fails. >> >> Regards, >> Eric >> >> >> Benoit Claise wrote: >> >>> Eric, >>> >>>> Benoit, >>>> >>>> Now that it's already used, I have no issue with keeping it, given >>>> that its limitation is well documented. >>>> >>>> Another minor points, we may change the following wording, >>>> "In case of AS-SET, the value of 0 is reported." to >>>> "In case of AS-SET, and can't be easily retrieved from BGP, the >>>> value 0 is reported." >>>> That leaves space for other ways to get this information now, such >>>> as through ebgp neighbor AS for edge routers. And it doesnt close >>>> the door for new ways to discover this later on, such as examining >>>> the exit point or topology. >>> >>> >>> >>> >>> Do you want to say "In case of AS-SET or can't be easily retrieved >>> from BGP, the value 0 is reported."? >>> Because, even with AS-SET, the AS can be easily retrieved. The issue >>> is to export it in IPFIX :) >>> >>> Regards, Benoit. >>> >>>> >>>> Regards, >>>> Eric >>>> >>>> >>>> Benoit Claise wrote: >>>> >>>>> Eric, >>>>> >>>>>> >>>>>> Nice work. I'd propose to remove bgpSrcAdjacentASNumber. It's not >>>>>> uncommon that BGP asymmetry happens a lot in real world, and this >>>>>> element may cause problem in real use for applications built on, >>>>>> if it reports wrong information. And there's no easy way to verify >>>>>> that inside IPFIX itself. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I share with your concern. >>>>> However, I propose to keep this I.E.s for 2 reasons. >>>>> 1. This BGP asymmetry and peer source AS / asymmetry issue is not >>>>> new: we do already export this value in NetFlow version 9 today. >>>>> 2. you will have a wrong value for bgpSrcAdjacentASNumber only in >>>>> the case of multi-access interfaces (typically an ethernet >>>>> interface at an IXP). In other interface types, you would be able >>>>> to deduce if the value is correct or not, i.e. if there is some >>>>> asymmetry >>>>> >>>>> Regards, Benoit. >>>>> >>>>>> >>>>>> Regards, >>>>>> Eric >>>>>> >>>>>> >>>>>> Benoit Claise wrote: >>>>>> >>>>>>> Danny and all, >>>>>>> >>>>>>> In order to continue the discussion with a clear basis, here is >>>>>>> the list of proposed BGP-related I.E.s. I've been trying to >>>>>>> insert all suggestions. >>>>>>> This should answer some of your questions below. >>>>>>> Feel free to review and to propose some new text if some >>>>>>> improvements are required. >>>>>>> >>>>>>> | 16 | bgpSourceAsNumber | 17 | >>>>>>> bgpDestinationAsNumber >>>>>>> | 18 | bgpNextHopIpV4Address >>>>>>> | 63 | bgpNextHopIpV6Address >>>>>>> | 128 | bgpNextHopAsNumber >>>>>>> | 129 | ipNextHopAsNumber >>>>>>> >>>>>>> 5.4.4 bgpSourceAsNumber >>>>>>> Description: >>>>>>> The autonomous system (AS) number of the source address in >>>>>>> the IP >>>>>>> packet headers of this flow. In case of AS-SET, the >>>>>>> value of 0 is reported. >>>>>>> >>>>>>> Abstract Data Type: unsigned16 >>>>>>> >>>>>>> Data Type Semantics: identifier >>>>>>> >>>>>>> ElementId: 16 >>>>>>> >>>>>>> Status: current >>>>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>>>> >>>>>>> >>>>>>> 5.4.5 bgpDestinationAsNumber >>>>>>> Description: >>>>>>> The autonomous system (AS) number of the destination address in >>>>>>> the IP packet headers this flow. In case of AS-SET, the >>>>>>> value of 0 is reported. >>>>>>> >>>>>>> Abstract Data Type: unsigned16 >>>>>>> >>>>>>> Data Type Semantics: identifier >>>>>>> >>>>>>> ElementId: 17 >>>>>>> >>>>>>> Status: current >>>>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>>>> >>>>>>> >>>>>>> 5.4.7 bgpNextHopIpV4Address >>>>>>> Description: >>>>>>> The IPv4 address of the next BGP hop to which packets of >>>>>>> this flow >>>>>>> are forwarded. >>>>>>> >>>>>>> Abstract Data Type: ipv4Address >>>>>>> >>>>>>> Data Type Semantics: identifier >>>>>>> >>>>>>> ElementId: 18 >>>>>>> >>>>>>> Status: current >>>>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>>>> >>>>>>> >>>>>>> 5.4.8 bgpNextHopIpV6Address >>>>>>> Description: >>>>>>> The IPv6 address of the next BGP hop to which packets of >>>>>>> this flow >>>>>>> are forwarded. >>>>>>> >>>>>>> Abstract Data Type: ipv6Address >>>>>>> >>>>>>> Data Type Semantics: identifier >>>>>>> >>>>>>> ElementId: 63 >>>>>>> >>>>>>> Status: current >>>>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>>>> 5.4.6 bgpDstAdjacentASNumber >>>>>>> Description: >>>>>>> The autonomous system (AS) number of the first AS in the AS >>>>>>> path to which packets of this flow are forwarded, deduced by >>>>>>> looking up the source IP address of the flow in the BGP routing >>>>>>> information base. In case of AS-SET, the value of 0 is reported. >>>>>>> >>>>>>> Abstract Data Type: unsigned16 >>>>>>> >>>>>>> Data Type Semantics: identifier >>>>>>> >>>>>>> ElementId: 128 >>>>>>> >>>>>>> Status: current >>>>>>> >>>>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>>>> >>>>>>> 5.4.6 bgpSrcAdjacentASNumber >>>>>>> >>>>>>> Description: >>>>>>> The autonomous system (AS) number of the last AS in the AS >>>>>>> path from which packets of this flow arrived, deduced by looking >>>>>>> up the source IP address of the flow in the BGP routing >>>>>>> information base. In case of BGP asymmetry, the >>>>>>> bgpSrcAdjacentASNumber might not be able to report the correct >>>>>>> value. In case of AS-SET, the value of 0 is reported. >>>>>>> >>>>>>> Data Type Semantics: identifier >>>>>>> >>>>>>> ElementId: 129 >>>>>>> >>>>>>> Status: current >>>>>>> >>>>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>>>> >>>>>>> >>>>>>> >>>>>>> See inline. >>>>>>> >>>>>>>> >>>>>>>> On May 4, 2005, at 8:14 AM, Benoit Claise wrote: >>>>>>>> >>>>>>>>> I think we have a technical problem right now in IPFIX. We >>>>>>>>> can't report an AS_SET. How can we report that the >>>>>>>>> bgpDstAdjacentASNumber is not a single unsigned16, but list of >>>>>>>>> unsigned16? This is not possible! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Right.. >>>>>>>> >>>>>>>>> So a quick and dirty solution... why not say: export 0 for AS_SET. >>>>>>>>> Anyway, reporting the AS_SET is not that useful on the >>>>>>>>> collector. If AS_SET = (100, 200, 300), it means that most >>>>>>>>> specific routes of this aggregate prefix comes from either >>>>>>>>> 100, either 200, either 300. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This would have to apply uniformly across all these elements, as >>>>>>>> any of these could return AS_SET: >>>>>>>> >>>>>>>> 16 bgpSourceAsNumber >>>>>>>> 17 bgpDestinationAsNumber >>>>>>>> 128 bgpNextAdjacentAsNumber >>>>>>>> 129 bgpPreviousAdjacentAsNumber >>>>>>>> 149 ipNextHopAsNumber >>>>>>>> >>>>>>>> I would suspect that 16, 17 and 149 would very frequently >>>>>>>> reside within the local AS >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> BTW, typo 149 -> 129. >>>>>>> I don't see how the local AS would be reported with the >>>>>>> definitions of 16/17. >>>>>>> The definition of 129 has been changed. I guess it's ok now. >>>>>>> >>>>>>>> - which would most intuitively be >>>>>>>> represented by '0', I think.. For that matter, any of these >>>>>>>> could return local AS (or is it no_adjacent_AS? :-) >>>>>>>> >>>>>>>> Given my admittedly terse review of the draft, I don't see >>>>>>>> behavior defined for where these values should be derived, >>>>>>>> and in particular, how local AS (or no AS?) should be >>>>>>>> reported. Do you envision local AS being reported as a >>>>>>>> function of the router knowing what AS the local BGP process >>>>>>>> resides in? Else that local AS value isn't added to the path >>>>>>>> until advertised to an eBGP peer. >>>>>>>> >>>>>>>> I'd be a bit cautious about using '0', and perhaps specify >>>>>>>> that local AS (and no AS) always return '0'. This would >>>>>>>> align with the BGP Spec: >>>>>>>> >>>>>>>> [snip from BGP spec] >>>>>>>> When a BGP speaker originates a route then: >>>>>>>> >>>>>>>> a) the originating speaker includes its own AS number in a path >>>>>>>> segment of type AS_SEQUENCE in the AS_PATH attribute of all >>>>>>>> UPDATE >>>>>>>> messages sent to an external peer. (In this case, the AS >>>>>>>> number of >>>>>>>> the originating speaker's autonomous system will be the only >>>>>>>> entry >>>>>>>> the path segment, and this path segment will be the only segment >>>>>>>> in the AS_PATH attribute). >>>>>>>> >>>>>>>> b) the originating speaker includes an empty AS_PATH attribute in >>>>>>>> all UPDATE messages sent to internal peers. (An empty AS_PATH >>>>>>>> attribute is one whose length field contains the value zero). >>>>>>>> >>>>>>>> [/snip] >>>>>>>> >>>>>>>> So given b) above, returning zero for local AS wold seem intuitive. >>>>>>>> >>>>>>>> As for accommodating AS_SET, I'm not quite sure. Would it be >>>>>>>> unreasonable to report multiple elements of the same type here if >>>>>>>> an AS_SET is returned, or is this a bad idea (I expect so)? >>>>>>>> >>>>>>> One solution could be to specify multiple new AS-SET related >>>>>>> I.E., such mplsLabelStackEntryX in MPLS. >>>>>>> >>>>>>> My personal view is that (in order to finish this IPFIX work who >>>>>>> has been lasting to long IMHO ;)), we should post the draft with >>>>>>> the I.E.s we require right now, and use the IANA procedure for >>>>>>> any other I.E.s. Otherwise, I fear the job will never be finished. >>>>>>> >>>>>>>> >>>>>>>> To further complicate things, I suspect we'll be seeing >>>>>>>> this in deployments within a couple years, per AS number >>>>>>>> depletion: >>>>>>>> >>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-09.txt >>>>>>>> >>>>>>>> I'm not sure if we want to worry about it now or define >>>>>>>> new elements down the road.. >>>>>>>> >>>>>>>> Regarding 149, ipNextHopAsNumber: >>>>>>>> >>>>>>>> ----- >>>>>>>> 5.6.3 ipNextHopAsNumber >>>>>>>> Description: >>>>>>>> The autonomous system (AS) number of the next IP hop to which >>>>>>>> packets of this flow are forwarded. >>>>>>>> >>>>>>>> Abstract Data Type: unsigned16 >>>>>>>> >>>>>>>> Data Type Semantics: identifier >>>>>>>> >>>>>>>> ElementId: 149 >>>>>>>> >>>>>>>> Status: current >>>>>>>> Reference: See RFC 1771 for a description of BGP-4 and see >>>>>>>> RFC 1930 a >>>>>>>> definition of the AS number. >>>>>>>> ----- >>>>>>>> >>>>>>>> Is this element returning the AS number for the IP address reported >>>>>>>> in the BGP NEXT_HOP attribute associated with the destination >>>>>>>> prefix, >>>>>>>> or it the RIB/FIB IP "next hop" used to reach that destination? >>>>>>>> This >>>>>>>> should be stated explicitly. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I hope the new definition above is OK now. >>>>>>> >>>>>>> Regards, Benoit. >>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> Note the "Previous" in the name above. Also, should you say >>>>>>>>>> something about >>>>>>>>>> source and destination prefixes here and above, it might help >>>>>>>>>> implementers, per >>>>>>>>>> this would be a "first" or "leftmost" AS segment in the >>>>>>>>>> AS_PATH for the source >>>>>>>>>> IP prefix in the BGP Loc-RIB that contains the source IP >>>>>>>>>> prefix, while above it's >>>>>>>>>> the destination prefix, etc.. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Any proposal? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Not sure if these are any better, but: >>>>>>>> >>>>>>>> 5.4.4 bgpSourceAsNumber >>>>>>>> Description: >>>>>>>> The first (origin) autonomous system (AS) number for the >>>>>>>> prefix containing the source address in the IP packet header >>>>>>>> in a packet of this flow. >>>>>>>> >>>>>>>> 5.4.5 bgpDestinationAsNumber >>>>>>>> Description: >>>>>>>> The first (origin) autonomous system (AS) number for the >>>>>>>> prefix containing the destination address in the IP packet >>>>>>>> header in a packet of this flow. >>>>>>>> >>>>>>>> >>>>>>>> And I'd still like to see similar information elements added for >>>>>>>> AS_CONFED_SET & AS_CONFED_SEQUENCE. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> As expressed above, if you require them, make a proposal. >>>>>>> >>>>>>> Regards, Benoit. >>>>>>> >>>>>>>> >>>>>>>> -danny >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>>> message body >>>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>>> "unsubscribe ipfix" in message body >>>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> -- >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>> message body >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe ipfix" in message body >>> Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> >>> > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From LutzEll@garysmithagency.com Fri May 13 21:37:19 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00170 for ; Fri, 13 May 2005 21:37:18 -0400 (EDT) Received: from ip212-226-143-21.adsl.kpnqwest.fi ([212.226.143.21] helo=garysmithagency.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DWlJE-0006vH-00 for ipfix-list@mil.doit.wisc.edu; Fri, 13 May 2005 20:19:17 -0500 From: "Lutz Ellsworth" To: "Hudson Bowens" Subject: =?iso-8859-1?Q?Re:_C1=E0L1S_VA11=ECUM_VlAGGR=C1?= Date: Fri, 13 May 2005 21:19:13 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C57858.42855211" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?212.226.143.21 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C57858.42855211 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, departed fuming, and on the morrow the Clotho weighed anchor and On, now, Jeremy! cried Blood. Straight into them before they intent upon reaching it before darkness should come down upon the Very early next morning, before the heat of the day came to rende fetched the Colonel. twenty guns and a hundred and fifty men apiece. His lordship's smile brought lines like gashes into his leathery he bade them. Truss him, wrist and heel, but don't hurt him - n There was a ripple of laughter in the galleries, instantly quelle such heaps upon the beds of the six Spaniards that by the time sh waiting-woman who was grovelling at her feet in a state of terror there on the day-bed. He had been a fortnight in Port Royal, his Have a nice day. ------=_NextPart_000_0008_01C57858.42855211 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello, = How would you like to spend Iess on yoour druggs?
 
V a r i l  V l u
i g a C a is a i m and many other.
 
Save over 60 % with = PhaarmacyByMAlL STORE.
 
Have a nice day.
 
departed fuming, and on the morrow the Clotho weighed anchor
and = On, now, Jeremy! cried Blood. Straight into them before
they = intent upon reaching it before darkness should come down upon
the = Very early next morning, before the heat of the day came to
rende = fetched the
Colonel. = twenty guns and a hundred and fifty men
apiece. = His lordship's smile brought lines like gashes into his
leathery = he bade them. Truss him, wrist and heel, but don't hurt him -
n = There was a ripple of laughter in the galleries, instantly
quelle = such heaps upon the beds of the six Spaniards that by the time
sh = waiting-woman who was grovelling at her feet in a state of
terror = there on the day-bed. He had been a fortnight in Port Royal,
his =
------=_NextPart_000_0008_01C57858.42855211-- From majordomo@mil.doit.wisc.edu Sat May 14 06:26:59 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20348 for ; Sat, 14 May 2005 06:26:59 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWtay-0002rs-00 for ipfix-list@mil.doit.wisc.edu; Sat, 14 May 2005 05:10:08 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWtax-0002rn-00 for ipfix-info@net.doit.wisc.edu; Sat, 14 May 2005 05:10:07 -0500 Received: from [192.168.0.112] (dialin-145-254-185-213.arcor-ip.net [145.254.185.213]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 24D6A1BAC99; Sat, 14 May 2005 12:10:00 +0200 (CEST) Date: Sat, 14 May 2005 00:56:24 +0200 From: Juergen Quittek To: Benoit Claise , Eric Ji Cc: Danny McPherson , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] BGP related Information Elements Message-ID: In-Reply-To: <4281A678.8080808@cisco.com> References: <426E5295.8080602@cisco.com> <7ab543168fd86ef01096ded6d744219f@tcb.net> <4278D8B1.2030003@cisco.com> <427F4532.8050202@cisco.com> <427FABD1.4010605@yahoo-inc.com> <427FBB91.6000502@cisco.com> <42812B04.8090807@yahoo-inc.com> <4281A678.8080808@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Can't we be a bit more elaborate than just stating "in case of AS_SET"? This is well established slang among experts. But a maybe a more commonly understood alternative phrasing that is more appropriate for a standard specification would be "if AS path information for this flow is only available as unordered AS set (and not as ordered AS sequence)". Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 5/11/2005 8:30 AM +0200 Benoit Claise wrote: > Eric, > >> Benoit, >> >> Now that it's already used, I have no issue with keeping it, given >> that its limitation is well documented. >> >> Another minor points, we may change the following wording, >> "In case of AS-SET, the value of 0 is reported." to >> "In case of AS-SET, and can't be easily retrieved from BGP, the value >> 0 is reported." >> That leaves space for other ways to get this information now, such as >> through ebgp neighbor AS for edge routers. And it doesnt close the >> door for new ways to discover this later on, such as examining the >> exit point or topology. > > Do you want to say "In case of AS-SET or can't be easily retrieved from BGP, the value 0 is reported."? > Because, even with AS-SET, the AS can be easily retrieved. The issue is to export it in IPFIX :) > > Regards, Benoit. > >> >> Regards, >> Eric >> >> >> Benoit Claise wrote: >> >>> Eric, >>> >>>> >>>> Nice work. I'd propose to remove bgpSrcAdjacentASNumber. It's not >>>> uncommon that BGP asymmetry happens a lot in real world, and this >>>> element may cause problem in real use for applications built on, if >>>> it reports wrong information. And there's no easy way to verify that >>>> inside IPFIX itself. >>> >>> >>> >>> I share with your concern. >>> However, I propose to keep this I.E.s for 2 reasons. >>> 1. This BGP asymmetry and peer source AS / asymmetry issue is not >>> new: we do already export this value in NetFlow version 9 today. >>> 2. you will have a wrong value for bgpSrcAdjacentASNumber only in the >>> case of multi-access interfaces (typically an ethernet interface at >>> an IXP). In other interface types, you would be able to deduce if the >>> value is correct or not, i.e. if there is some asymmetry >>> >>> Regards, Benoit. >>> >>>> >>>> Regards, >>>> Eric >>>> >>>> >>>> Benoit Claise wrote: >>>> >>>>> Danny and all, >>>>> >>>>> In order to continue the discussion with a clear basis, here is the >>>>> list of proposed BGP-related I.E.s. I've been trying to insert all >>>>> suggestions. >>>>> This should answer some of your questions below. >>>>> Feel free to review and to propose some new text if some >>>>> improvements are required. >>>>> >>>>> | 16 | bgpSourceAsNumber | 17 | >>>>> bgpDestinationAsNumber >>>>> | 18 | bgpNextHopIpV4Address >>>>> | 63 | bgpNextHopIpV6Address >>>>> | 128 | bgpNextHopAsNumber >>>>> | 129 | ipNextHopAsNumber >>>>> >>>>> 5.4.4 bgpSourceAsNumber >>>>> Description: >>>>> The autonomous system (AS) number of the source address in the IP >>>>> packet headers of this flow. In case of AS-SET, the value >>>>> of 0 is reported. >>>>> >>>>> Abstract Data Type: unsigned16 >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 16 >>>>> >>>>> Status: current >>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>> >>>>> >>>>> 5.4.5 bgpDestinationAsNumber >>>>> Description: >>>>> The autonomous system (AS) number of the destination address in >>>>> the IP packet headers this flow. In case of AS-SET, the >>>>> value of 0 is reported. >>>>> >>>>> Abstract Data Type: unsigned16 >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 17 >>>>> >>>>> Status: current >>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>> >>>>> >>>>> 5.4.7 bgpNextHopIpV4Address >>>>> Description: >>>>> The IPv4 address of the next BGP hop to which packets of this >>>>> flow >>>>> are forwarded. >>>>> >>>>> Abstract Data Type: ipv4Address >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 18 >>>>> >>>>> Status: current >>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>> >>>>> >>>>> 5.4.8 bgpNextHopIpV6Address >>>>> Description: >>>>> The IPv6 address of the next BGP hop to which packets of this >>>>> flow >>>>> are forwarded. >>>>> >>>>> Abstract Data Type: ipv6Address >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 63 >>>>> >>>>> Status: current >>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>> 5.4.6 bgpDstAdjacentASNumber >>>>> Description: >>>>> The autonomous system (AS) number of the first AS in the AS path >>>>> to which packets of this flow are forwarded, deduced by looking up >>>>> the source IP address of the flow in the BGP routing information >>>>> base. In case of AS-SET, the value of 0 is reported. >>>>> >>>>> Abstract Data Type: unsigned16 >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 128 >>>>> >>>>> Status: current >>>>> >>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>> >>>>> 5.4.6 bgpSrcAdjacentASNumber >>>>> >>>>> Description: >>>>> The autonomous system (AS) number of the last AS in the AS path >>>>> from which packets of this flow arrived, deduced by looking up the >>>>> source IP address of the flow in the BGP routing information base. >>>>> In case of BGP asymmetry, the bgpSrcAdjacentASNumber might not be >>>>> able to report the correct value. In case of AS-SET, the value of 0 >>>>> is reported. >>>>> >>>>> Data Type Semantics: identifier >>>>> >>>>> ElementId: 129 >>>>> >>>>> Status: current >>>>> >>>>> Reference: See RFC 1771 for a description of BGP-4. >>>>> >>>>> >>>>> >>>>> See inline. >>>>> >>>>>> >>>>>> On May 4, 2005, at 8:14 AM, Benoit Claise wrote: >>>>>> >>>>>>> I think we have a technical problem right now in IPFIX. We can't >>>>>>> report an AS_SET. How can we report that the >>>>>>> bgpDstAdjacentASNumber is not a single unsigned16, but list of >>>>>>> unsigned16? This is not possible! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Right.. >>>>>> >>>>>>> So a quick and dirty solution... why not say: export 0 for AS_SET. >>>>>>> Anyway, reporting the AS_SET is not that useful on the collector. >>>>>>> If AS_SET = (100, 200, 300), it means that most specific routes >>>>>>> of this aggregate prefix comes from either 100, either 200, >>>>>>> either 300. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> This would have to apply uniformly across all these elements, as >>>>>> any of these could return AS_SET: >>>>>> >>>>>> 16 bgpSourceAsNumber >>>>>> 17 bgpDestinationAsNumber >>>>>> 128 bgpNextAdjacentAsNumber >>>>>> 129 bgpPreviousAdjacentAsNumber >>>>>> 149 ipNextHopAsNumber >>>>>> >>>>>> I would suspect that 16, 17 and 149 would very frequently >>>>>> reside within the local AS >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> BTW, typo 149 -> 129. >>>>> I don't see how the local AS would be reported with the definitions >>>>> of 16/17. >>>>> The definition of 129 has been changed. I guess it's ok now. >>>>> >>>>>> - which would most intuitively be >>>>>> represented by '0', I think.. For that matter, any of these >>>>>> could return local AS (or is it no_adjacent_AS? :-) >>>>>> >>>>>> Given my admittedly terse review of the draft, I don't see >>>>>> behavior defined for where these values should be derived, >>>>>> and in particular, how local AS (or no AS?) should be >>>>>> reported. Do you envision local AS being reported as a >>>>>> function of the router knowing what AS the local BGP process >>>>>> resides in? Else that local AS value isn't added to the path >>>>>> until advertised to an eBGP peer. >>>>>> >>>>>> I'd be a bit cautious about using '0', and perhaps specify >>>>>> that local AS (and no AS) always return '0'. This would >>>>>> align with the BGP Spec: >>>>>> >>>>>> [snip from BGP spec] >>>>>> When a BGP speaker originates a route then: >>>>>> >>>>>> a) the originating speaker includes its own AS number in a path >>>>>> segment of type AS_SEQUENCE in the AS_PATH attribute of all UPDATE >>>>>> messages sent to an external peer. (In this case, the AS number of >>>>>> the originating speaker's autonomous system will be the only entry >>>>>> the path segment, and this path segment will be the only segment >>>>>> in the AS_PATH attribute). >>>>>> >>>>>> b) the originating speaker includes an empty AS_PATH attribute in >>>>>> all UPDATE messages sent to internal peers. (An empty AS_PATH >>>>>> attribute is one whose length field contains the value zero). >>>>>> >>>>>> [/snip] >>>>>> >>>>>> So given b) above, returning zero for local AS wold seem intuitive. >>>>>> >>>>>> As for accommodating AS_SET, I'm not quite sure. Would it be >>>>>> unreasonable to report multiple elements of the same type here if >>>>>> an AS_SET is returned, or is this a bad idea (I expect so)? >>>>>> >>>>> One solution could be to specify multiple new AS-SET related I.E., >>>>> such mplsLabelStackEntryX in MPLS. >>>>> >>>>> My personal view is that (in order to finish this IPFIX work who >>>>> has been lasting to long IMHO ;)), we should post the draft with >>>>> the I.E.s we require right now, and use the IANA procedure for any >>>>> other I.E.s. Otherwise, I fear the job will never be finished. >>>>> >>>>>> >>>>>> To further complicate things, I suspect we'll be seeing >>>>>> this in deployments within a couple years, per AS number >>>>>> depletion: >>>>>> >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-09.txt >>>>>> >>>>>> I'm not sure if we want to worry about it now or define >>>>>> new elements down the road.. >>>>>> >>>>>> Regarding 149, ipNextHopAsNumber: >>>>>> >>>>>> ----- >>>>>> 5.6.3 ipNextHopAsNumber >>>>>> Description: >>>>>> The autonomous system (AS) number of the next IP hop to which >>>>>> packets of this flow are forwarded. >>>>>> >>>>>> Abstract Data Type: unsigned16 >>>>>> >>>>>> Data Type Semantics: identifier >>>>>> >>>>>> ElementId: 149 >>>>>> >>>>>> Status: current >>>>>> Reference: See RFC 1771 for a description of BGP-4 and see RFC >>>>>> 1930 a >>>>>> definition of the AS number. >>>>>> ----- >>>>>> >>>>>> Is this element returning the AS number for the IP address reported >>>>>> in the BGP NEXT_HOP attribute associated with the destination prefix, >>>>>> or it the RIB/FIB IP "next hop" used to reach that destination? This >>>>>> should be stated explicitly. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I hope the new definition above is OK now. >>>>> >>>>> Regards, Benoit. >>>>> >>>>>> >>>>>>>> >>>>>>>> Note the "Previous" in the name above. Also, should you say >>>>>>>> something about >>>>>>>> source and destination prefixes here and above, it might help >>>>>>>> implementers, per >>>>>>>> this would be a "first" or "leftmost" AS segment in the AS_PATH >>>>>>>> for the source >>>>>>>> IP prefix in the BGP Loc-RIB that contains the source IP prefix, >>>>>>>> while above it's >>>>>>>> the destination prefix, etc.. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Any proposal? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Not sure if these are any better, but: >>>>>> >>>>>> 5.4.4 bgpSourceAsNumber >>>>>> Description: >>>>>> The first (origin) autonomous system (AS) number for the >>>>>> prefix containing the source address in the IP packet header >>>>>> in a packet of this flow. >>>>>> >>>>>> 5.4.5 bgpDestinationAsNumber >>>>>> Description: >>>>>> The first (origin) autonomous system (AS) number for the >>>>>> prefix containing the destination address in the IP packet >>>>>> header in a packet of this flow. >>>>>> >>>>>> >>>>>> And I'd still like to see similar information elements added for >>>>>> AS_CONFED_SET & AS_CONFED_SEQUENCE. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> As expressed above, if you require them, make a proposal. >>>>> >>>>> Regards, Benoit. >>>>> >>>>>> >>>>>> -danny >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>> message body >>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>> "unsubscribe ipfix" in message body >>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>> >>>>> >>>>> >>> >>> >>> > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sat May 14 06:26:59 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20350 for ; Sat, 14 May 2005 06:26:59 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWtas-0002rl-00 for ipfix-list@mil.doit.wisc.edu; Sat, 14 May 2005 05:10:02 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWtar-0002rd-00 for ipfix-protocol@net.doit.wisc.edu; Sat, 14 May 2005 05:10:01 -0500 Received: from [192.168.0.112] (dialin-145-254-185-213.arcor-ip.net [145.254.185.213]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 3F8E61BAC4D; Sat, 14 May 2005 12:09:57 +0200 (CEST) Date: Fri, 13 May 2005 19:46:51 +0200 From: Juergen Quittek To: Benoit Claise , Tanja Zseby Cc: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] One correction in the "octets" information elements Message-ID: <88FB29D0C8180412F4E43463@753F3B888A9969457862729D> In-Reply-To: <4284B4DF.8020502@cisco.com> References: <427881C3.90200@cisco.com> <427F27E7.4070604@cisco.com> <734945E7C5440C3DB70E6368@753F3B888A9969457862729D> <428478C8.4090603@fokus.fraunhofer.de> <4284B4DF.8020502@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Dear all, Independent of what we choose, I think it is important having a very clear definition of the octet counter. If we go for the inclusion of MPLS labels and other sub-IP components, then doubt that "The number of octets excluding the data link header and trailer." is clear enough. Would we have an RFC or other reference that defines what is the data link header (and why the MPLS label isn't one? Thanks, Juergen --=20 Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 5/13/2005 4:08 PM +0200 Benoit Claise wrote: > Dear all, > > I've been thinking about this issue for some time and I'm wondering if we're not going in the wrong direction. Let me explain > > Tanja is right that IPFIX needs some consistent counters definitions. After all, these counters are the fundamental information elements in IPFIX, as Juergen explained. > > Personally, I see some value in exporting counters with "The number of octets exclude the data link header and trailer." as opposed to "The number of octets include IP header(s) and IP payload.". However, I understand both the pros and cons arguments. > These pros and cons arguments logically lead to the creation of two series of counters, one for subIP and one for IP. > Note that a series is composed of counters for all the combinations of (pre/post, delta/total, dropped or not, multicast or not), so A LOT OF counters. > > If we start to systematically multiply the number of counters per technology, we will have so many to choose from that it can be a risk for interoperability. > Another risk is that we could multiply the counterS for any new technology to monitor: MPLS? ISL? dot1q? something else in the future? If we want to be complete, we should duplicate all the counters each time. > > Maybe we want to take a step back, and keep a single series of counters. If the consensus is "The number of octets include IP header(s) and IP payload." as it was initially in the draft, fair enough. At least we would keep IPFIX simple. > > If a vendor would like to use a very specific I.E. (ex: number of octets including the MPLS labels length), this could still be done with an enterprise-specific I.E., with an extra I.E (example: exporting the number of labels would allow to recompute > the MPLS + IP length), with a request to IANA for one specific I.E. In this last case, it would be based on customer requests, so a good reason, as opposed trying to specify a full set of I.E. at the IPFIX information model creation time. > > In conclusion, I don't think multiplying all the counters is a good choice for the future adoption of IPFIX. > Feedback? > > Regards, Benoit. > >> Hi J=FCrgen and Benoit, >> >> I think that it is extremely important to have the IP octet counter >> consistent, so that always the same is counted regardless of the >> traffic (e.g. whether it is MPLS or not). So I would prefer to have >> one counter that only counts the IP octets. Since counting IP+MPLS may >> be of advantage for capacity planing etc., I think the best solution >> is to provide a further counter as J=FCrgen proposed. >> >> Regards >> Tanja >> >> >> Juergen Quittek wrote: >> >>> >>> >>> --On 5/9/2005 11:05 AM +0200 Benoit Claise wrote: >>> >>>> Juergen, >>>> >>>>> Hi Benoit, >>>>> >>>>> --On 5/4/2005 10:03 AM +0200 Benoit Claise wrote: >>>>> >>>>>> Juergen, >>>>>> >>>>>> We realized that the Information Element #1 octetDeltaCount, >>>>>> which is in line with NetFlow version 9, is not correctly specified. >>>>>> >>>>>> 5.9.1 octetDeltaCount >>>>>> Description: >>>>>> The number of octets since the previous report (if any) in >>>>>> incoming packets for this flow at the Observation Point. The >>>>>> number of octets include IP header(s) and IP payload. >>>>>> >>>>>> -> New Description: >>>>>> The number of octets since the previous report (if any) in >>>>>> incoming packets for this flow at the Observation Point. The >>>>>> number of octets exclude the data link header and trailer. >>>>>> >>>>>> This allows to account for the length of MPLS labels, for the ISL >>>>>> bytes, etc... >>>>> >>>>> >>>>> >>>>> >>>>> I see the following problems with this change. >>>>> >>>>> - This implies that we count more than just the IP packet. >>>>> Since this is counter is fundamental for IPFIX, we would need >>>>> to discuss precisely what is measured. I do not like the >>>>> inclusion of non-IP octets in the count to be hidden in these >>>>> three lines. >>>>> >>>>> - How useful would this information be? >>>> >>>> >>>> >>>> Just one example: capacity planning with a MPLS core, when you want >>>> to know exactly what has been sent and not only the IP part of the >>>> packet. >>>> >>>>> How would the collector >>>>> know that the MPLS labels are included in the count? >>>> >>>> >>>> >>>> Counted by default. >>>> >>>>> >>>>> - Even if the collector knows that MPLS labels are included in the >>>>> count, it would not be able to just subtract them for calculating >>>>> the pure IP octet number, because it does not necessarily known >>>>> how many labels are on the label stack. >>>> >>>> >>>> >>>> If you really want to do it, you can export the number of labels as >>>> a different I.E. >>>> >>>>> >>>>> - Which information elements should a device use that supports MPLS >>>>> but is able to calculate the precise IP octet count, for example >>>>> at the end of the MPLS tunnel where both counts (with and without >>>>> labels) are available? Instead of defining another information >>>>> element for this case, I would rather define a new one for the >>>>> IP+MPLS octet counter. >>>> >>>> >>>> >>>> Defining a new set of counters might prove to be the only remaining >>>> solution. >>>> I would keep the I.E. #1 (octetDeltaCount) for IP + MPLS, as this is >>>> what NetFlow version 9 does now. >>> >>> >>> >>> What about renaming #1 to subIpOctetDeltaCount and introducing a new >>> one for pure IP >>> that will then inherit the name octetDeltaCount? >>> (Sub-IP was the name of the IETF area that dealt with MPLS.) >>> We probably would have to do this for all counters of octets in >>> packets, i.e. >>> >>> postOctetDeltaCount #23, octetTotalCount #85, postMulticastOctetCount >>> # 20, >>> postOctetTotalCount #160, droppedOctetDeltaCount #132, >>> droppedOctetTotalCount #134. >>> >>> Cheers, >>> >>> Juergen >> >> >> > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sat May 14 06:27:00 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20364 for ; Sat, 14 May 2005 06:26:59 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DWtb3-0002s0-00 for ipfix-list@mil.doit.wisc.edu; Sat, 14 May 2005 05:10:14 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DWtb2-0002rv-00 for ipfix-info@net.doit.wisc.edu; Sat, 14 May 2005 05:10:12 -0500 Received: from [192.168.0.112] (dialin-145-254-185-213.arcor-ip.net [145.254.185.213]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 41F6C1BAC9E; Sat, 14 May 2005 12:10:07 +0200 (CEST) Date: Sat, 14 May 2005 02:06:44 +0200 From: Juergen Quittek To: Benoit Claise , Danny McPherson Cc: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] BGP related Information Elements Message-ID: <83C6144649716CD66FE73B54@753F3B888A9969457862729D> In-Reply-To: <427F4532.8050202@cisco.com> References: <426E5295.8080602@cisco.com> <7ab543168fd86ef01096ded6d744219f@tcb.net> <4278D8B1.2030003@cisco.com> <427F4532.8050202@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, --On 5/9/2005 1:10 PM +0200 Benoit Claise wrote: > Danny and all, > > In order to continue the discussion with a clear basis, here is the list of proposed BGP-related I.E.s. I've been trying to insert all suggestions. > This should answer some of your questions below. > Feel free to review and to propose some new text if some improvements are required. > >| 16 | bgpSourceAsNumber | 17 | bgpDestinationAsNumber >| 18 | bgpNextHopIpV4Address >| 63 | bgpNextHopIpV6Address >| 128 | bgpNextHopAsNumber >| 129 | ipNextHopAsNumber > > 5.4.4 bgpSourceAsNumber > Description: > The autonomous system (AS) number of the source address in the IP > packet headers of this flow. In case of AS-SET, the value of 0 is reported. If the source IP address is not a flow key, then the source address is potentially only in one (the first) header. Therefore "headers" might not be appropriate. Suggestion: The autonomous system (AS) number of the source IP address of this flow. If AS path information for this flow is only available as unordered AS set (and not as ordered AS sequence), then the value of this Information Element is 0. > Abstract Data Type: unsigned16 > > Data Type Semantics: identifier > > ElementId: 16 > > Status: current > Reference: See RFC 1771 for a description of BGP-4. > > > 5.4.5 bgpDestinationAsNumber > Description: > The autonomous system (AS) number of the destination address in > the IP packet headers this flow. In case of AS-SET, the value of 0 is reported. There is an "of" missing in this description. But anyway, my suggestion is the same then above except the "source" is replaced by "destination" > Abstract Data Type: unsigned16 > > Data Type Semantics: identifier > > ElementId: 17 > > Status: current > Reference: See RFC 1771 for a description of BGP-4. > > > 5.4.7 bgpNextHopIpV4Address > Description: > The IPv4 address of the next BGP hop to which packets of this flow > are forwarded. Coming back to the issue raised by Danny: What if there is no next BGP hop? We may be measuring in the destination IP address' domain or even at the destination IP address itself. Shall we set the value of this IE to 0.0.0.0 in this case? > Abstract Data Type: ipv4Address > > Data Type Semantics: identifier > > ElementId: 18 > > Status: current > Reference: See RFC 1771 for a description of BGP-4. > > > 5.4.8 bgpNextHopIpV6Address > Description: > The IPv6 address of the next BGP hop to which packets of this flow > are forwarded. dito. > Abstract Data Type: ipv6Address > > Data Type Semantics: identifier > > ElementId: 63 > > Status: current > Reference: See RFC 1771 for a description of BGP-4. > > 5.4.6 bgpDstAdjacentASNumber > Description: > The autonomous system (AS) number of the first AS in the AS path to > which packets of this flow are forwarded, deduced by looking up the What is the value of this IE if the path is empty? If it is 0 there might be confusion with the AS_SET case. > source IP address of the flow in the BGP routing information base. Shouldn't we replace "source IP address" with "destination IP address"? > In case of AS-SET, the value of 0 is reported. > > Abstract Data Type: unsigned16 > > Data Type Semantics: identifier > > ElementId: 128 > > Status: current > > Reference: See RFC 1771 for a description of BGP-4. > > 5.4.6 bgpSrcAdjacentASNumber > > Description: > The autonomous system (AS) number of the last AS in the AS path > from which packets of this flow arrived, deduced by looking up the > source IP address of the flow in the BGP routing information base. > In case of BGP asymmetry, the bgpSrcAdjacentASNumber might not be > able to report the correct value. In case of AS-SET, the value of 0 > is reported. I am not sure an IE is an actor that is capable of "reporting" something by itself. What about replacing OLD "In case of BGP asymmetry, the bgpSrcAdjacentASNumber might not be able to report the correct value." with NEW "If the BGP AS path to the source IP address of this flow is asymmetric, then the value of this Information Element may be incorrect." ? Or, even cleaner: "Description: The autonomous system (AS) number of the first AS in the AS path to the source IP address of this flow. If the AS path to the source IP address of the flow is symmetric, then the value of this Information Element indicates the AS number of the AS from which packets of this flow arrived. If AS path information for this flow is only available as unordered AS set (and not as ordered AS sequence), then the value of this Information Element is 0.. Still remaining: What is the value of this IE when measuring at the source IP address? Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > Data Type Semantics: identifier > > ElementId: 129 > > Status: current > > Reference: See RFC 1771 for a description of BGP-4. > > > > See inline. > >> >> On May 4, 2005, at 8:14 AM, Benoit Claise wrote: >> >>> I think we have a technical problem right now in IPFIX. We can't >>> report an AS_SET. How can we report that the bgpDstAdjacentASNumber >>> is not a single unsigned16, but list of unsigned16? This is not >>> possible! >> >> >> Right.. >> >>> So a quick and dirty solution... why not say: export 0 for AS_SET. >>> Anyway, reporting the AS_SET is not that useful on the collector. If >>> AS_SET = (100, 200, 300), it means that most specific routes of this >>> aggregate prefix comes from either 100, either 200, either 300. >> >> >> This would have to apply uniformly across all these elements, as >> any of these could return AS_SET: >> >> 16 bgpSourceAsNumber >> 17 bgpDestinationAsNumber >> 128 bgpNextAdjacentAsNumber >> 129 bgpPreviousAdjacentAsNumber >> 149 ipNextHopAsNumber >> >> I would suspect that 16, 17 and 149 would very frequently >> reside within the local AS > > BTW, typo 149 -> 129. > I don't see how the local AS would be reported with the definitions of 16/17. > The definition of 129 has been changed. I guess it's ok now. > >> - which would most intuitively be >> represented by '0', I think.. For that matter, any of these >> could return local AS (or is it no_adjacent_AS? :-) >> >> Given my admittedly terse review of the draft, I don't see >> behavior defined for where these values should be derived, >> and in particular, how local AS (or no AS?) should be >> reported. Do you envision local AS being reported as a >> function of the router knowing what AS the local BGP process >> resides in? Else that local AS value isn't added to the path >> until advertised to an eBGP peer. >> >> I'd be a bit cautious about using '0', and perhaps specify >> that local AS (and no AS) always return '0'. This would >> align with the BGP Spec: >> >> [snip from BGP spec] >> When a BGP speaker originates a route then: >> >> a) the originating speaker includes its own AS number in a path >> segment of type AS_SEQUENCE in the AS_PATH attribute of all UPDATE >> messages sent to an external peer. (In this case, the AS number of >> the originating speaker's autonomous system will be the only entry >> the path segment, and this path segment will be the only segment >> in the AS_PATH attribute). >> >> b) the originating speaker includes an empty AS_PATH attribute in >> all UPDATE messages sent to internal peers. (An empty AS_PATH >> attribute is one whose length field contains the value zero). >> >> [/snip] >> >> So given b) above, returning zero for local AS wold seem intuitive. >> >> As for accommodating AS_SET, I'm not quite sure. Would it be >> unreasonable to report multiple elements of the same type here if >> an AS_SET is returned, or is this a bad idea (I expect so)? >> > One solution could be to specify multiple new AS-SET related I.E., such mplsLabelStackEntryX in MPLS. > > My personal view is that (in order to finish this IPFIX work who has been lasting to long IMHO ;)), we should post the draft with the I.E.s we require right now, and use the IANA procedure for any other I.E.s. Otherwise, I fear the job will never be > finished. > >> >> To further complicate things, I suspect we'll be seeing >> this in deployments within a couple years, per AS number >> depletion: >> >> http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-09.txt >> >> I'm not sure if we want to worry about it now or define >> new elements down the road.. >> >> Regarding 149, ipNextHopAsNumber: >> >> ----- >> 5.6.3 ipNextHopAsNumber >> Description: >> The autonomous system (AS) number of the next IP hop to which >> packets of this flow are forwarded. >> >> Abstract Data Type: unsigned16 >> >> Data Type Semantics: identifier >> >> ElementId: 149 >> >> Status: current >> Reference: See RFC 1771 for a description of BGP-4 and see RFC 1930 a >> definition of the AS number. >> ----- >> >> Is this element returning the AS number for the IP address reported >> in the BGP NEXT_HOP attribute associated with the destination prefix, >> or it the RIB/FIB IP "next hop" used to reach that destination? This >> should be stated explicitly. > > I hope the new definition above is OK now. > > Regards, Benoit. > >> >>>> >>>> Note the "Previous" in the name above. Also, should you say >>>> something about >>>> source and destination prefixes here and above, it might help >>>> implementers, per >>>> this would be a "first" or "leftmost" AS segment in the AS_PATH for >>>> the source >>>> IP prefix in the BGP Loc-RIB that contains the source IP prefix, >>>> while above it's >>>> the destination prefix, etc.. >>> >>> >>> Any proposal? >> >> >> Not sure if these are any better, but: >> >> 5.4.4 bgpSourceAsNumber >> Description: >> The first (origin) autonomous system (AS) number for the >> prefix containing the source address in the IP packet header >> in a packet of this flow. >> >> 5.4.5 bgpDestinationAsNumber >> Description: >> The first (origin) autonomous system (AS) number for the >> prefix containing the destination address in the IP packet >> header in a packet of this flow. >> >> >> And I'd still like to see similar information elements added for >> AS_CONFED_SET & AS_CONFED_SEQUENCE. > > As expressed above, if you require them, make a proposal. > > Regards, Benoit. > >> >> -danny > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Antigon@karenhooper.com Sun May 15 21:08:18 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07400 for ; Sun, 15 May 2005 21:08:17 -0400 (EDT) Received: from lsanca2-ar39-4-63-232-171.lsanca2.dsl-verizon.net ([4.63.232.171] helo=karenhooper.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DXTm0-0001Nu-00 for ipfix-list@mil.doit.wisc.edu; Sun, 15 May 2005 19:47:58 -0500 From: "Antigonus Houle" To: "Hodel Menard" Subject: =?iso-8859-1?Q?Re:_V=E0LL1UM_V=ECAGGRA_C1=C1LlSS?= Date: Sun, 15 May 2005 20:47:54 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C577E3.4287EDBA" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C577E3.4287EDBA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, of her and went up the ladder. He was clad in drawers of hairy, not, he told himself, to be deceived by her delicate exterior, he Petit Goave, where the interview was to take place. The Baron, freed the prisoners held as hostages, and even the negro slaves, The Captain swung round, and for an instant looked as if he would Ogle, however, continued to give proof that his knowledge of gunn He told it me. That is why I esteemed him - for the calm fortit All day the Dutch brig was in sight, though by evening she had I understand, sir. Let me present Captain Blood. Had he been as mistaken in her feelings towards himself as he fine and his magnetism so compelling, that she cast her silly were. The swiftly executed boarding manoeuvre had caught them ourselves; we must depend entirely upon our small arms, and how Have a nice day. ------=_NextPart_000_0008_01C577E3.4287EDBA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello, = do you want to spend Iess on your ddruugs?
 
V a r i l  V l u
i g a C a is a i m and many other.
 
Save over 7 0 %  with = PPharmacyByMaiI SHOP.
 
Have a nice day.
 
of her and went up the ladder. He was clad in drawers of
hairy, = not, he told himself, to be deceived by her delicate exterior,
he = Petit Goave, where the interview was to take place. The
Baron, = freed the prisoners held as hostages, and even the negro
slaves, = The Captain swung round, and for an instant looked as if he
would = Ogle, however, continued to give proof that his knowledge of
gunn = He told it me. That is why I esteemed him - for the calm
fortit = All day the Dutch brig was in sight, though by evening she
had = I understand, sir. Let me present Captain
Blood. = Had he been as mistaken in her feelings towards himself as
he = fine and his magnetism so compelling, that she cast her
silly = were. The swiftly executed boarding manoeuvre had caught
them = ourselves; we must depend entirely upon our small arms, and
how =
------=_NextPart_000_0008_01C577E3.4287EDBA-- From StuShult1361@johnscott.com Tue May 17 01:42:27 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19530 for ; Tue, 17 May 2005 01:42:16 -0400 (EDT) Received: from 220-139-246-159.dynamic.hinet.net ([220.139.246.159] helo=johnscott.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DXuUg-0001km-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 May 2005 00:19:51 -0500 From: "Stu Shultz" To: "Lester Turpin" Subject: =?iso-8859-1?Q?Re:_V=ECAGGRA_V=C1LLlUM_C=ECALlSS?= Date: Tue, 17 May 2005 01:19:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C55D31.42897EF2" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C55D31.42897EF2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Ye don't say! he repeated, and came to lean beside her. And w Captain Blood thrust a parchment under Calverley's bulging eyes. guns and eight small. Next in importance was the Salvador with was afflicted mainly at the moment by the thought that he was at The Admiral's face flamed scarlet. He half raised his hand to st with you to Speightstown, or even farther north, where you will b Bishop glared at him; then shrugging heavily, he took up the pen Mr. Blood, greatly daring, ventured down at dusk into the town. that here prevarication would avail you little. For we always ha He was menacing on that. For the moment I must accept what I fi - of Governor Steed's lady, whom he shamelessly and cynically should the Arabella be doing here, when he had left her in Jamaic And we have in the boat below two chests containing fifty thousa Have a nice day. ------=_NextPart_000_0008_01C55D31.42897EF2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello, = do you want too spend Iess on your drrugs?
 
C A l I G A V L U
l L S V A R A l M and many other.
 
Save over 7 5 %  with = PharamcyByMMAlL SHOP.
 
Have a nice day.
 
Ye don't say! he repeated, and came to lean beside her. And
w = Captain Blood thrust a parchment under Calverley's bulging
eyes. = guns and eight small. Next in importance was the Salvador
with = was afflicted mainly at the moment by the thought that he was
at = The Admiral's face flamed scarlet. He half raised his hand to
st = with you to Speightstown, or even farther north, where you will
b = Bishop glared at him; then shrugging heavily, he took up the
pen = Mr. Blood, greatly daring, ventured down at dusk into the
town. = that here prevarication would avail you little. For we always
ha = He was menacing on that. For the moment I must accept what I
fi = - of Governor Steed's lady, whom he shamelessly and
cynically = should the Arabella be doing here, when he had left her in
Jamaic = And we have in the boat below two chests containing fifty
thousa =
------=_NextPart_000_0008_01C55D31.42897EF2-- From majordomo@mil.doit.wisc.edu Wed May 18 07:06:13 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05710 for ; Wed, 18 May 2005 07:06:13 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DYLzq-0005VJ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 18 May 2005 05:41:50 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DYLzp-0005VE-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 18 May 2005 05:41:49 -0500 Received: from [192.168.0.112] (HSI-KBW-082-212-051-164.hsi.kabelbw.de [82.212.51.164]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 266C61BAC4D for ; Wed, 18 May 2005 12:41:45 +0200 (CEST) Date: Wed, 18 May 2005 12:39:28 +0200 From: Juergen Quittek To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] terminology nit Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, I have a small comment on the IPFIX terminology as stated in version -13 of the protocol draft. > Template > > Template is an ordered sequence of pairs, used to > completely identify the structure and semantics of a particular set ^^^^^^^^ > of information that needs to be communicated from an IPFIX Device to > a Collector. Each Template is uniquely identifiable by means of a > Template ID. The current phrasing is not fully correct. The Template ID _identifies_ "structure and semantics of a particular set of information". But the Template itself does more: It specifies it. I suggest replacing 'identify' with 'specify'. Thanks, Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From BargerJud@jdv.com Sun May 22 07:03:59 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05762 for ; Sun, 22 May 2005 07:03:58 -0400 (EDT) Received: from [211.59.205.179] (helo=jdv.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DZnpW-0002Zx-00 for ipfix-list@mil.doit.wisc.edu; Sun, 22 May 2005 05:37:10 -0500 From: "Judas Barger" To: "Amenhotep Patrick" Subject: Trying It By Yoursself Date: Sun, 22 May 2005 05:37:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01C55EBA.366D7C00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C55EBA.366D7C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, see what your Catholic King will have to say to it."of the shed where = the Governor was standing at the moment."Why not? In those days = you had some claim upon my kindness. YouIt was the Dutch Admiral = who answered him. "Vould he go dere ifTheir glances met, sullen = defiance braving dull anger, surprise, andfusion they made up a = monstrous passion.ventured once - and once only - to beard him = frankly about it.guardianship. It was perhaps his one mistake. = But the goodness ofat a delusive shadow.But to all he manifested = an indifference which, as the weeks passedlong, inactive waiting = was straining the nerves of both Lordwho inspired confidence by = the very confidence he displayed incool and fragrant. As they = went, he considered her admiringly, andher guns."Don't fling your = French at me, man," snapped Hobart. "Speakround fort that guarded = that narrow entrance. The fort was ------=_NextPart_000_0060_01C55EBA.366D7C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello, 

l am dating a much younger woman (21).  Before we began dating I was hearing
stories of guys younger than me taking Vitamin V.
 
Guys in their 20's and thirties were using VlAGRRA and so I decided that I needed
that same edge the younger guys were getting.
 
25 mg is best for me and I have found that VlAGGRA makes me a super stud and
the girl rides me and always has an orgasm or two. It has made me much better
in bed and I give her some very long and extended foreplay now.
 
It has really helped my confidence knowing that if needed I can give it to her any time she wants it.
 
V. has to be the greatest invention since sliced bread. 
 
Try it with PhraamacyByMail = Shop.
 
 
 
deluge that = now caught him. He had come up rubbing his hands and
Royal = there was no effort he would spare, no nerve he would = not
Blood, who confronted him, a sudden sternness in his face = and in
but unmistakably her own.
He saw her start, and stop, = and instantly made amends. "You alarm
Colonel Bishop was of = another opinion. In his view there was a
At sight of the = doctor, dressed and booted, the case of instruments
became a = very welcome guest. M. d'Ogeron was in the Captain's debt
men = to reenforce him on his arrival. What I have come to = propose
his share of plunder as a special reward. Next came = the Arabella.
in his eyes.
"Sure, now, I am not constraining = you at all. I'm giving you a
him time to reply: "Thus much = being clear, shall we come to
it after. That'll cool Colonel = Bishop's heat, maybe."
now the mischievousness that normally = inhabited her fresh young
lout'll be all night getting = there."
------=_NextPart_000_0060_01C55EBA.366D7C00-- From HorParri@javagamepark.com Mon May 23 08:12:38 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19519 for ; Mon, 23 May 2005 08:12:38 -0400 (EDT) Received: from [200.5.220.62] (helo=javagamepark.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DaBXw-0003oV-00 for ipfix-list@mil.doit.wisc.edu; Mon, 23 May 2005 06:56:41 -0500 From: "Horacio Parris" To: "Booker Quinn" Subject: Better Coontrol Date: Mon, 23 May 2005 06:56:45 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C55F8E.7DC53C80" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C55F8E.7DC53C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, touched me very deeply. It made me see clearly my error and mydo the = facts. I have enlisted for you the men that you desired mewas = taking place. Blood, although the man chiefly, if not solely,at = least he kept that vow strictly to himself.dangerous offence, that = fleet, well served by a southerly breeze,the rest of the fleet, = she was alone and at a disadvantage. Itit. Rather did the = contemplation of their misery increase thewas no ship to which = they could retreat, and here they must prevailThe giant rolled his = single bloodthirsty eye, and sneered, thrustingpractised courtier, = he bore about him the atmosphere of the greathard-a-port!"to be in = great trouble of mind over these events. I found himimpeccably = Spanish, and was not Don Esteban there to confirm him?"Captain = Blood!" said his lordship sharply in reproof. "Upon myto the = rallying ground on Castle Field by wives and daughters,She swung = to him with some impatience, her eyes aswim in tears. "You ------=_NextPart_000_0031_01C55F8E.7DC53C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello, 

l am dating a much younger woman (21).  Before we began dating I was hearing
stories of guys younger than me taking Vitamin V.
 
Guys in their 20's and thirties were using VlAGRRA and so I decided that I needed
that same edge the younger guys were getting.
 
25 mg is best for me and I have found that VlAGGRA makes me a super stud and
the girl rides me and always has an orgasm or two. It has made me much better
in bed and I give her some very long and extended foreplay now.
 
It has really helped my confidence knowing that if needed I can give it to her any time she wants it.
 
V. has to be the greatest invention since sliced bread. 
 
Try it with PhramacyByMail = Shopp.
 
 
 
have been = saved. If only I could have spoken to him again before
"It = will be unfortunate for everybody. I advised your father = to
Bishop rapped out an oath, and then, shaken by a sudden = fear: "Who
contribute. Give me leave for three days on = parole, and I will see
"Is it now? Glory be, I wonder ye can = pick it out from the rest."
desperate fury of men who know that = retreat is impossible, for there
debtor, should come by the = money to buy a wherry. But this he knew
his irritation. "You = should be broke for it. You bring the King's
to be hanged in = Port Royal."
"Can you give me until morning for reflection? My = head aches so
"But is he mad, to leave his post at such a = time?" Blood was amazed.
fraught with loss of dignity. But = there were those volunteers that
should have been false to his = parole. And when presently Don Diego
ventured once - and once = only - to beard him frankly about it.
He turned now upon the = slave a countenance that was inflamed by heat
what's happened = to you. D' ye think we can do without a = navigator
------=_NextPart_000_0031_01C55F8E.7DC53C80-- From 5bry@access-one.com Mon May 23 20:18:13 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17182 for ; Mon, 23 May 2005 20:18:13 -0400 (EDT) Received: from smtp.doit.wisc.edu ([144.92.9.43]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DaMt7-0005HP-00 for ipfix-list@mil.doit.wisc.edu; Mon, 23 May 2005 19:03:13 -0500 Received: from 220.86.131.196 ([220.86.131.196]) by smtp.doit.wisc.edu (8.13.3/8.12.6) with SMTP id j4O00r7T108702 for ; Mon, 23 May 2005 19:00:58 -0500 Message-ID: <7efc01c55ff2$7ce10229$258f63ec@access-one.com> From: "Kendra L. Brown" <5bry@access-one.com> To: ipfix-list@mil.doit.wisc.edu Subject: Cheap software Date: Mon, 23 May 2005 23:50:07 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_780F2952.B5B3A6E3" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0000_780F2952.B5B3A6E3 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_781A4076.BA4FDBF4" ------=_NextPart_001_0001_781A4076.BA4FDBF4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get all the software possible for bottom prices! We sell software 2-6 times cheaper than retail price. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Visio 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... For full list of products go: http://www.software-disks.com Best, Kendra Brown _____________________________________________________ To be taken out, go: http://www.software-disks.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_781A4076.BA4FDBF4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
C A l I G A V L U
l L S V A R A l M and many other.
Get all the software possible for bottom prices!
We sell software 2-6 times cheaper than retail price.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Visio 2003 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... For full list of products go:

http://www.software-disks.com

Best,
Kendra Brown


_____________________________________________________
To be taken out, go: http://www.software-disks.com/uns.htm
_____________________________________________________

------=_NextPart_001_0001_781A4076.BA4FDBF4-- ------=_NextPart_000_0000_780F2952.B5B3A6E3-- From Po@johnsonsfurniture.c.cnri.reston.va.us Tue May 24 07:07:32 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17594 for ; Tue, 24 May 2005 07:07:32 -0400 (EDT) Received: from adsl78.dyn243.pacific.net.sg ([210.24.243.78] helo=johnsonsfurniture.c) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DaWwS-0003Hj-00 for ipfix-list@mil.doit.wisc.edu; Tue, 24 May 2005 05:47:20 -0500 From: "Po Begay" To: "Hengist Figueroa" Subject: She Thinkss I'm a God Date: Tue, 24 May 2005 05:02:47 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01C56047.BC6AFD80" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (dnsbl.njabl.org) Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_004A_01C56047.BC6AFD80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, "Faith, it's in better case I am for mirth than your lordship. = Foranother. Already he had hit upon that other. For such a = voyage aIt was a crestfallen Captain Blood who presided aver that = hastilyShe looked away from him again, and found that her sight = wasmariners he had brought from France. He had left behind him = atthe toilers found breath to croak a ribald buccaneering ditty:La = Guayra by a guarda-costa; and if ye hadn't lost La Foudre, andwe = get out again unless we accept the terms of Monsieur the = Admiralbutton-holes was in the Spanish fashion. But the long, = stout,Bishop's fleet.trial, upon a charge of high treason. We = know that he was not"If you will sail with me again," the Captain = answered him, "you mayfragments before their occupants could = extricate themselves. Theof the Captain's, and fell into step = beside him.fellow-slaves at work there. Despair went with him. = What tormentsnecessary to have recourse to other means of torture. = Not all his ------=_NextPart_000_004A_01C56047.BC6AFD80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello, 

l am dating a much younger woman (21).  Before we began dating I was hearing
stories of guys younger than me taking Vitamin V.
 
Guys in their 20's and thirties were using VlAGRRA and so I decided that I needed
that same edge the younger guys were getting.
 
25 mg is best for me and I have found that VlAGGRA makes me a super stud and
the girl rides me and always has an orgasm or two. It has made me much better
in bed and I give her some very long and extended foreplay now.
 
It has really helped my confidence knowing that if needed I can give it to her any time she wants it.
 
V. has to be the greatest invention since sliced bread. 
 
Try it with PhramacyByMaiil = Shop.
 
 
 
Yet short of = some such measure, it appeared to Colonel Bishop
"Y'amaze me!" = he gasped. "On my soul, y'amaze me! To have recovered
had = said - that these buccaneers must prove the sharp edge of = any
were due.
danger, and stood about to pick up such = survivors as contrived to
skilled in their use, who was = certainly no coward, and a papist only
"It would be humiliating = to send for me if you treat me like an enemy."
queen."
day, = which was the 5th of April, M. de Rivarol entered the city = and
"My God!" said she. "And you can laugh!"
"It's an = achievement," he admitted. "But then, I have not fared = as
above the smoke and flames, and through his telescope Blood = made out
alarmed by the lad's blubbering. He crossed to Pitt's = side, and
rocked gently with idly flapping sails under the lee = of the long
One of the boats bumped alongside the Arabella, and = up the entrance
He paused a moment. There was a hum of = approval from his comrades,
------=_NextPart_000_004A_01C56047.BC6AFD80-- From majordomo@mil.doit.wisc.edu Tue May 24 19:00:54 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03264 for ; Tue, 24 May 2005 19:00:53 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dai6V-0002if-00 for ipfix-list@mil.doit.wisc.edu; Tue, 24 May 2005 17:42:27 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dai6U-0002ia-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 24 May 2005 17:42:26 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4OMgNJ14646; Wed, 25 May 2005 00:42:23 +0200 (CEST) Received: from [10.61.65.150] (ams-clip-vpn-dhcp406.cisco.com [10.61.65.150]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4OMgMF09653; Wed, 25 May 2005 00:42:22 +0200 (CEST) Message-ID: <4293ADCE.2020108@cisco.com> Date: Wed, 25 May 2005 00:42:22 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] terminology nit References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Thanks Juergen. Done. Nevil, you should do the same change in IPFIX-ARCH. Regards, Benoit. > Dear all, > > I have a small comment on the IPFIX terminology as stated in version -13 > of the protocol draft. > >> Template >> >> Template is an ordered sequence of pairs, used to >> completely identify the structure and semantics of a particular set > > ^^^^^^^^ > >> of information that needs to be communicated from an IPFIX Device to >> a Collector. Each Template is uniquely identifiable by means of a >> Template ID. > > > The current phrasing is not fully correct. > The Template ID _identifies_ "structure and semantics of a particular set > of information". But the Template itself does more: It specifies it. > > I suggest replacing 'identify' with 'specify'. > > Thanks, > > Juergen > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From PetricaSouz9252@jpanderson.com Wed May 25 07:05:29 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28798 for ; Wed, 25 May 2005 07:05:28 -0400 (EDT) Received: from [210.121.224.4] (helo=jpanderson.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DatK6-00030o-00 for ipfix-list@mil.doit.wisc.edu; Wed, 25 May 2005 05:41:14 -0500 From: "Petrica Souza" To: "Kagiso Stanford" Subject: Re: 25mg did the trrick Date: Wed, 25 May 2005 05:41:35 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C56116.526D5980" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?210.121.224.4 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C56116.526D5980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, he turned cold from head to foot at the mere thought of what = mightinconvenient fellow in the prow. Their first attention must = be fordirections they set about getting under way.Six ships of = that fleet were instantly refitted for sea. There"So I should = have thought. But I have the information from a Majora surly, = ungracious beast at all times, readier with the lash ofbefore we = make land.""Aye, but by then, morbleu, the matter will be settled. = I shallColonel Bishop from the yardarm, and by thus finally = stifling theour presence aboard the Milagrosa."all the = circumstances. "Decidedly I think I had the last word"It's the = lucky man ye are entirely, Colonel, though ye don't guesstongue of = land. He announced that its armament was less = formidable"Good-morning to ye, ma'am," was his greeting as he = overtook her;the graceful, elegant young trifler from St. James's, = Lord Juliantheir Captain and refrained, it was only because the = sudden steely ------=_NextPart_000_0017_01C56116.526D5980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
King of England = was not even the illegitimate child of the lateOur new = great offer:
VlAGchance to = discuss the matter with his chosen partner. As a resultRA = Csix months later, when the battle = of Sedgemoor was fought.lALlS VALlM. de Rivarol, intrigued by his mirth, scowled upon = himUM LEVlPeter Blood prayed = that the offer might be rejected. For no reasonTRA anthose sturdy, experienced buccaneers. = Unhesitatingly all threwd many other
 
for VERY REASONABLE PRfive pearls each of the size of a sparrow's egg. There = werelCES.
 
With each purchase you concerned."get:
 
  • Top quaIdebtor, should come by the = money to buy a wherry. But this he = knewity
  • Home deIifine coat of = biscuit-coloured taffetas, and climbed upon the = plank.very
  • Total confidentiaIitthe ship, and = stood blinking in the sunlight.y
    •  
    Just try us and you will not be disappoAnd so, joined now by the other = stragglers, and numbering in all ainted!
     
    ------=_NextPart_000_0017_01C56116.526D5980-- From HudsCassidy@jstarmotors.com Thu May 26 04:12:51 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09732 for ; Thu, 26 May 2005 04:12:51 -0400 (EDT) Received: from [61.111.101.36] (helo=jstarmotors.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DbD6N-00000a-00 for ipfix-list@mil.doit.wisc.edu; Thu, 26 May 2005 02:48:24 -0500 From: "Hudson Cassidy" To: "Abner Wong" Subject: Re: Really Works Excellennt Date: Thu, 26 May 2005 02:48:50 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01C561C7.5AD19D00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?61.111.101.36 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_002A_01C561C7.5AD19D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The marplot was the mad-dog Spanish Admiral, whom they = encounteredneeding."gallows.miserably.of my own. You'll be = wishing me to land you at Port Royal."thrusts upon us - is not for = such as M. de Rivarol. His angerabout the hall, sounding the = wainscoting with the butt of a pistol.Arabella, whilst Ogle the = gunner, whom he had summoned, wasshould remember that His Catholic = Majesty and the King of Englandwhen I tell you that the Spanish = fleet guarding the bottle-neck exitwas locked for the night, and = all within it asleep by now - it wasfire-ship in charge of = Wolverstone, with a crew of six volunteers,of it took him, and he = yielded to it."You are overwrought, ma'am. I...."lay ahead. Two = years ago he had himself considered a raid upon theto receive him, = and with them were some hundreds of his buccaneers. ------=_NextPart_000_002A_01C561C7.5AD19D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, Ppresent circumstances warranted. He was disposed to be = optimistic.harmacyByMail SHOP W"In pain, is he? I hope he is, the damned piratical dog. = But willelcomes you!
     
    Our new great offeBut by evening the Admiral's equanimity was not quite so = perfect.r:
    do my best," = said she.VlAGRA of any = records in which their fate may be traced. That lack = ofClALlS VALlUCHAPTER = XXM LEHis excellency jumped; = there was a sudden stir among his officers.VlTRA and = manyFive miles out at sea from Port = Royal, whence the details of the other
     
    for VERY REASONABLE PRlCthem."ES.
     
    With eachtwo = hundred pounds besides imprisonment. It would ruin me. = You'll purchase you get:
     
  • Top Farrell," said the = officer.quaIity
  • Home deIivconcerned to abate the = pride of Spain and plant the Lilies of = Franceery
  • Total confLevasseur stared at him = foolishly agape. Behind him pressed = hisidentiaIity
    •  
    Just try us and you will not be disappoindangerous offence, that fleet, well served = by a southerly breeze,ted!
     
    ------=_NextPart_000_002A_01C561C7.5AD19D00-- From Argy8234@cruz.com Fri May 27 00:02:06 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12436 for ; Fri, 27 May 2005 00:02:05 -0400 (EDT) Received: from [221.159.15.48] (helo=cruz.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DbVjf-0006RQ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 26 May 2005 22:42:11 -0500 From: "Argyros Royal" To: "Harrietta Ferrara" Subject: Re: 25 mg Works Wonderss Date: Thu, 26 May 2005 22:42:39 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C5626E.2107A180" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?221.159.15.48 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C5626E.2107A180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, the street met at last the glance of those hostile eyes that watchedWell, = then: he saw in me one who made it impossible that he shouldM. de = Rivarol bit his lip in chagrin. His gloomy eye smouldered asPLANS OF = ESCAPEStarboard to starboard the two ships swung against each other = withoverseas governors. But these, either - like the Governor of = TortugaHa! Wolverstone vented an ejaculation of sneering mirth. = Forsaid, through his teeth. My God, what a reckoning there will = besufficiently expressed the fact. I can see that, fool; just as = Ilately as yesterday would have turned pale under his frown, = facesHaving spoken so, gloatingly, evilly, he sank back again, = andSuch was the fleet of which the gauntlet was to be run by = Captainof thought, observing and connecting. Having exhausted them, = heshrug his lordship made the required surrender.On my soul, that = swarthy rascal has given his lordship a scare.But where is my = brother? Why has he not come, himself, to ------=_NextPart_000_0010_01C5626E.2107A180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, do you want to spend Iess on your dYou said you vould show us zome vine dings. = Vhere are dese vinerrugs?
     
    The PHARMBut it had been an unpromising beginning, and = there was more toACY-BY-MAlL SHOP  offeCaptain Blood bowed again. In vain M. de = Rivarol looked searchinglyrs you a great = deaI
     
    VlAGA man who = sailed with them, a Frenchman named Cahusac, whom I foundRA = VALin bitterness, it must be because = that bitterness was anterior tolUM ClAmoment the unfortunate slave stood powerless, his wrists = pinionedLlS LTo Levasseur's = relief, Captain Blood not only agreed, but pronouncedEVlTRA = and many other.
     
    With each purchase you getIt was in his mind to slink back in the night, once his work = at:
  • Great He did. I forgive you the = impertinence.Prices
  • Tsuspicion that he had formed, and = approached the fort as nearly asop quaIity
  • Home deguns and eight small. Next in = importance was the Salvador withIivery
  • Total confidentiwere being plentifully = supplied by others.aIity
    •  
    Try us and you will not be disappointeparole, you tyke of = Spain?d!
    ------=_NextPart_000_0010_01C5626E.2107A180-- From BellaPickens_610@keithshomes.com Fri May 27 20:13:55 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16690 for ; Fri, 27 May 2005 20:13:54 -0400 (EDT) Received: from bzq-80-50-105.red.bezeqint.net ([82.80.50.105] helo=keithshomes.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DbodD-0000mB-00 for ipfix-list@mil.doit.wisc.edu; Fri, 27 May 2005 18:52:50 -0500 From: "Bella Pickens" To: "Aku Cerda" Subject: Re: Reallyy Works Very Good Date: Fri, 27 May 2005 18:53:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C56317.443A5B80" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?82.80.50.105 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C56317.443A5B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, which Captain Blood had been guilty.man to apply to me. Still, = considering that ye willingly did meproceedings of that ghastly = day.ingenious Colonel Bishop knew a dozen ways - some of them = quiteCussy, the Governor of French Hispaniola, who desires a word = withIf the Spaniards had reached it, there would be lights. He = knocked,Aye, man, aye! Bishop assented hastily.way, with a full, = round, weather-beaten face whose mouth wasJealousy, that troubler of = reason, had been over-busy with his witsthat's the game he played or = not I can't tell ye; but here he ismore. Answer me this, sir: When = you cozened Captain Hobart withCaribbean who would have denied = himself the pleasure of stringingscarcely ruffled the sapphire = surface of the Caribbean, came aHe turned now upon the slave a = countenance that was inflamed by heatbehind to extort it whilst = fitting their ships for sea. Let Bloodof furniture smashed and = overthrown, the shouts and laughter of ------=_NextPart_000_0015_01C56317.443A5B80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, do youI'll = be after telling you. Rivarol is a fool to take this chance, = want to spend Iess on your drrugs?
     
    The PHIs there anybody else who shares Captain = Blood's opinion?ARMACY-BY-MAlL SHOP  offers yoOn a wide cobbled space on the sea front they = found a guard ofu a great deaI
     
    VlAfrom the soles = of his riding-boots to the crown of his periwig. HeGRA = VALlSpeightstown, and others still = farther north. What may have beenUM ClALby the fierce glare of the Judge and the = voice of the crier.lS I do not = think that Pitt is guilty in this merely of specialLEVlTRA and = many other.
     
    With eimpiously = appropriated for the purpose of a corps-de-garde. I haveach = purchase you get:
  • Great Prichad escaped his = notice.es
  • Top quaIithey had cause for = congratulation, I am unable to say in the = absencety
  • Htruth, which he withheld from = Mademoiselle d'Ogeron, was that inome = deIivery
  • Total word of a damned = pirate....confidentiaIity
    •  
    Try us aa tap at = the door, and an elderly negro slave presented himself.nd you = will not be disappointed!
    ------=_NextPart_000_0015_01C56317.443A5B80-- From Jay5755@jcpenneyeservices.c.cnri.reston.va.us Sun May 29 14:18:00 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01123 for ; Sun, 29 May 2005 14:17:59 -0400 (EDT) Received: from 61-216-76-120.dynamic.hinet.net ([61.216.76.120] helo=jcpenneyeservices.c) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DcS2X-0007XL-00 for ipfix-list@mil.doit.wisc.edu; Sun, 29 May 2005 12:57:34 -0500 From: "Jaymes Andrew" To: "Ling Berrios" Subject: Re: yoou need it Date: Sun, 29 May 2005 17:57:30 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C564A1.CA82A900" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?61.216.76.120 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C564A1.CA82A900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, she was swept past on the swift ebb.Be welcome aboard the Cinco Llagas, = Colonel, darling, a voicechosen representatives of their = followers.which they should remember. He would take a leaf out of = the bookAh, perro ingles! he shouted, and flung forward to his = death.How now, rogue? Would you waste our time with idle = subterfuge?lordship can't smell a papist at four paces.in to the = harbour mouth, within saker shot of Rivarol's threeName of God! swore = the gunner, which did no justice at all to anThere was more than = sunlight to make the Breton pirate blink. AndSlowly, majestically, = she was entering the bay. Already one or twoand in silence.devil = with Nuttall! Whether he gives surety for the boat or not,Spanish = morions on their heads, overshadowing their faces, andbitterly.there = is one captain. So. He swung again to the startled Colonel. ------=_NextPart_000_0004_01C564A1.CA82A900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello,
     
    My boyfriend beganprisoners were all pinioned, and guarded by four buccaneers = with having problems with erections (he's older) and I = suggested he look into VlAGRRA.
     
        Boy, am I glad he = did!
     
    The first time he tried it, one 50 mg piIl did = nothing so he took another and that was a mistake. Three hours later = he was still rock hard and had come multiple times (so had I)!! Since = then a single 50 mg dose does it very well--he's now good for almost = 2 hours of good hard sex that leaves boin that cursed wood. There was Pitt here ready to his hand, = andth of us worn out.
     
        - Bobbie, 21 on my defence, as your lordship promised that = I should be heard.female USA
     
    ------=_NextPart_000_0004_01C564A1.CA82A900-- From FarmerPirkko@johnhcarter.com Mon May 30 12:42:27 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26539 for ; Mon, 30 May 2005 12:42:26 -0400 (EDT) Received: from [211.220.204.4] (helo=johnhcarter.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dcn2w-0003wE-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 May 2005 11:23:23 -0500 From: "Pirkko Farmer" To: "Cindra Kenney" Subject: Re: you maybe neeed it Date: Mon, 30 May 2005 16:23:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C5655D.D03DC480" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C5655D.D03DC480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I pray you do, and in God's name be brief, man. For if I am to beShe = didn't pretend to understand him, and she didn't make the attempt.and = to stir up war and rebellion to depose his said lord the Kingdeal = upon your time, I hear. Youth and good looks, Doctor Blood!before = him in all those wild years of filibustering. He had usedBishop = delivered himself.towards the end of May, when the heat was beginning = to growof Don Miguel, and the grinning faces of the men at the guns = in theacknowledge the hospitality I am offering you. It may be poor, = butHe stalked out, and his three captains - although they thought = himat sight of his dejected countenance, and the deep frown that = scarredthat, and you cancel the articles; cancel the articles, and = yougreeting by a series of grunts of vague but apparently = ill-humouredheld Peter Blood were choked by the desire to supplant = and destroywas slower; but it was none the less steady. She was = already withinHenri, this is foolish! You are not behaving as my = friend. ------=_NextPart_000_0035_01C5655D.D03DC480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello,
     
    My boyfriend began having problems with erections = (he's older) and I suggesteBlood = pointed to the middle chaser; Have that gun hauled back,d he = look into VlAGRRA.
     
        Boy, am I glad he = did!
     
    The first time he tried it, one 50 mg piIl did = nothing so he took another and that was a mistake. Three hours later = he was still rock hard and had come multiple times (so had I)!! Since = then a single 50 mg dose does it very well--he's now good for almost = 2 hours of good harGovernor's house - = which Captain Blood had appropriated to hisd sex that leaves = both of us worn out.
     
        - Bobbiecan to ease his sufferings, or I swear to you = that I'll forsake at, 21 female USA
     
    ------=_NextPart_000_0035_01C5655D.D03DC480-- From majordomo@mil.doit.wisc.edu Mon May 30 16:04:55 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10350 for ; Mon, 30 May 2005 16:04:55 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DcqOv-0005Wa-00 for ipfix-list@mil.doit.wisc.edu; Mon, 30 May 2005 14:58:17 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DcqOs-0005WT-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 30 May 2005 14:58:15 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4UJwEl02713 for ; Mon, 30 May 2005 21:58:14 +0200 (CEST) Received: from [10.61.65.164] (ams-clip-vpn-dhcp420.cisco.com [10.61.65.164]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j4UJwDF24675 for ; Mon, 30 May 2005 21:58:13 +0200 (CEST) Message-ID: <429B7055.2020304@cisco.com> Date: Mon, 30 May 2005 21:58:13 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] new version of the IPFIX protocol draft:draft-ietf-ipfix-protocol-15.txt Content-Type: multipart/alternative; boundary="------------050705060204030405060406" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------050705060204030405060406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I just posted a new version of the IPFIX protocol draft, which is now fully in line with the latest version of the IPFIX-INFO, posted today by Juergen. Changes: - section 4 updated to be inline with the new version of IPFIX-INFO. Note that the introduction text is now compliant with RFC2119 keywords - added in section 8 * *If a specific Information Element is required by a Template but is not available in observed packets, the Exporting Process MAY choose to export Flow Records without this Information Element in a Data Record defined by a new Template. - "Template" definition updated Regards, Benoit --------------050705060204030405060406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

    I just posted a new version of the IPFIX protocol draft, which is now fully in line with the latest version of the IPFIX-INFO, posted today by Juergen.

    Changes:
    - section 4 updated to be inline with the new version of IPFIX-INFO.
       Note that the introduction text is now compliant with RFC2119 keywords
    - added in section 8 
       If a specific Information Element is required by a Template but is 
   not available in observed packets, the Exporting Process MAY choose 
   to export Flow Records without this Information Element in a Data 
   Record defined by a new Template. 
 
- "Template" definition updated
    Regards, Benoit

    --------------050705060204030405060406-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Corn5798@kapit.com Tue May 31 08:56:23 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06568 for ; Tue, 31 May 2005 08:56:23 -0400 (EDT) Received: from amontpellier-252-1-6-214.w81-251.abo.wanadoo.fr ([81.251.50.214] helo=kapit.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dd60B-0001UV-00 for ipfix-list@mil.doit.wisc.edu; Tue, 31 May 2005 07:37:47 -0500 From: "Klemen Cornish" To: "Chesley Leslie" Subject: Re: Really Workks Good Date: Tue, 31 May 2005 07:37:44 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C565DD.8AC0DC00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C565DD.8AC0DC00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, bedgown and slippers as he was. But the doctor eluded that toomore than = was asked.vouchsafed him a malignant smile, before he turned to meet = thehad so served the last of them her basket was empty, and there = waswhining and complaining when things are not as smooth as a = conventLevasseur gathered himself up with an oath of amazement. He = hadlure the Captain aside with some tale of hidden treasure, when = thisthe rest of the fleet, she was alone and at a disadvantage. ItIt = was the Dutch Admiral who answered him. Vould he go dere ifalmost as = a part of himself. A moment she rocked after her release,together = with these some half-dozen Spaniards in like case, thescore of sturdy = rogues whom his whistle had summoned, wereweathered last night's = storm.though perilously overcrowded, could yet contain them. = Next,his near escape of the yardarm and the running noose.What's = this? Do you tell us that you are a physician? ------=_NextPart_000_0051_01C565DD.8AC0DC00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Hello, do you need toWho was that runagate? he asked with terrible suavity. = Leaning spend Iess on your druggs?
     
    Save ovofficer in the Royal Navy. Fling him overboard and have done = wither 70% with PharrmaPresently, he said, you will suffer me to place you under = cover.cyByMail Shop
     
    VlCatholic = Spain.AGRA That is how you will = reason. Not so, however, reasoned CaptainVALlUM a similar course might be similarly effective = with Captain Blood.ClALlS LEVlTgreat harbour to the distant hills. Thus for a little while, = myRA and many other.
     
    With each pShe = didn't pretend to understand him, and she didn't make the = attempt.urchase you get:
     
  • Top quaOh! She = stared at him, bridling a little. You have a goodIity
  • BESTBut it had been = an unpromising beginning, and there was more to PRlCES
  • Total confidenbe = sent aboard one of the ships of the fleet. He pointed to = thetiaIity
  • Home deIivGovernor-General. I perceive your object, and I believe = ye'reery
    • ------=_NextPart_000_0051_01C565DD.8AC0DC00-- From majordomo@mil.doit.wisc.edu Tue May 31 11:21:26 2005 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18076 for ; Tue, 31 May 2005 11:21:26 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dd8Em-0007df-00 for ipfix-list@mil.doit.wisc.edu; Tue, 31 May 2005 10:01:00 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dd8El-0007dV-00 for ipfix-as@net.doit.wisc.edu; Tue, 31 May 2005 10:00:59 -0500 Received: from [10.147.67.235] (i4dhcp235 [10.147.67.235]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j4VF0vm03413 for ; Tue, 31 May 2005 17:00:58 +0200 (MEST) Message-ID: <429C7C29.8020001@fokus.fraunhofer.de> Date: Tue, 31 May 2005 17:00:57 +0200 From: Tanja Zseby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-as@net.doit.wisc.edu Subject: [ipfix-as] new version of IPFIX-AS draft Content-Type: multipart/alternative; boundary="------------090600040105050203080301" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------090600040105050203080301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, I submitted a new version of the IPFIX applicability statement draft-ietf-ipfix-as-05.txt. Main chnages are the improvement of the accounting example something more on further opportunities to use IPFIX, some more limitations and some restructuring. Please send me your comments, especially if you see further opportunities what to do with ipfix or further limitations (not sure that I remember all comments from the last meeting). Regards Tanja -- Dipl.-Ing. Tanja Zseby Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- --------------090600040105050203080301 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all,

    I submitted a new version of the IPFIX applicability statement draft-ietf-ipfix-as-05.txt. Main chnages are the improvement of the accounting example something more on further opportunities to use IPFIX, some more limitations and some restructuring.
    Please send me your comments, especially if you see further opportunities what to do with ipfix or further limitations (not sure that I remember all comments from the last meeting    ).

    Regards
    Tanja
    -- 
Dipl.-Ing. Tanja Zseby			    	      	
Fraunhofer Institute FOKUS			Email: zseby@fokus.fraunhofer.de	
Kaiserin-Augusta-Allee 31			Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------
    --------------090600040105050203080301-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/