Subject: [ipfix] Re: Comments on LFAP Version 5.0

From: [email-masked]
Date: Tue, 01 Oct 2002 11:50:08 -0400

> Reinaldo Penno wrote:
> 
> Hello paul,
> 
> during the process of evaluating LFAP I read the base + data model
> draft again. I have some general suggestions/questions (I'm doing this
> for all candidates...).
> 
> a) In section 2 there is a typo
> 
> "then the CCE MUSST terminate the TCP"...
> 
> b)
> 
> I think on the text below you mean
>  "...reachable from the CCE"
> 

	Actually I do mean FAS. The CCE might be able to 
	reach the FAS but another FAS may not be able to
	reach it. I think the example is if the IP address
	is NATed, the FAS cannot contact the other server
	given that IP address.

> 4.1   FAS IP Address IE
>      This is the IP Address of a device running a Flow Accounting
> Server
>      that may or may not be reachable from the FAS. The CCE uses this
> IE
>      in the Connection Request message. IE format is:
> 
> c) In section 4.2 there is a typo
> 
> "The record descriptor consist of two fields the first
>      field is the length of the fixed information field. The second
> is"
> 
> Maybe it should be ....of two fields. The first field is the lenght of
> the fixed information field, the second..."

	Yep.

> 
> d) In section 5.11 there is a typo..
> 
> "The FAS sends a Keep Alive
>      (KA) messge so the CCE can determine "
> 
> s/messge/message
> 
> e)
> 
> In regards to 5.12 (below), why the CCE cannot use DR also? How the
> CCE terminates a lfap session gracefully (perhaps indicating some
> error code if needed?)
> 

	Since the CCE initiates the connection it is the
	one which needs to be redirected. I'm not sure
	what it means to redirect the listener.

	The LFAP server, at the moment, does not need
	to know why the CCE disconnected. If there is a
	need for the info, I would use an AR message to 
	send it, not the DR.

> "5.12  Disconnect Request (DR) Message
> 
>      A DR message is sent only by the FAS to request the CCE
> disconnect.
>      It can be sent when the FAS is in the Send State or Connected
>      State. DR messages may contain one optional IE which is the FAS
> IP
>      Address IE. The FAS may suggest an alternative FAS by supplying
> the
>      FAS IP Address IE. Status is set to SUCCESS in DR messages.
> 
>     The Optional IE that can be transmitted in a DR message is a:
>          FAS IP Address IE"
> 
> f) Would you be so kind to give a concrete example on how the lfap
> packet would look like when the mulitple record format explained in
> section 4.2 is used? This IE is mentioned in this section and nowhere
> else in both drafts (base and data model). Except when you say in the
> data model "The multiple record IE MUST NOT be used.". Is this IE
> being used or not?

	Today it is mostly used in the FUN message. For example,

	 Note - FIXED-START, FIXED-END, FORMAT-START, FORMAT-END,
		 RECORD-START, RECORD-END do not exist in the message
		 they were added for readability

	type=multi-record, len = 84
	Fixed-Info-len = 16   Record-format-len = 12

	___ FIXED START____
	type = time,  len = 4, value = 9:00
	type = state, len = 4, value = active
	____FIXED-END_____

	____FORMAT-START__
	type = flow id, len = 12
	type = bytes,   len = 8
	type = packets, len = 8
	____FORMAT-END____

	____RECORD-START__
	1.1.5
	3773
	45
	____RECORD-END___

	____RECORD-START_
	1.1.67
	67990
	145
	____RECORD-END___
	
	...

	So each flow is updated with time, state, flowid, bytes, packets.
	The time and state are listed only once, the rest are given
	for each flow.

	There was restriction on using multiple record format in
	the FAR message. It was supposed to be lifted in LFAP V5
	but that change didn't make it in. I'll need to do an update
	to fix that.

> 
> g) I liked the detailed explanations on the protocol machinery, and
> actually liked the application level intelligence that lfap provides
> but IMHO I feel something similar could be done in respect to examples
> of packet formats in order to help understand the draft.  Is it
> possible to give some concrete examples on the packet format?
> 
> For example (lfap header + mandatory IEs), (lfap header + mandatory
> IEs + some optional IEs) for some flows? Some examples of what I'm
> talking about can be found in section 10 of
> draft-bclaise-netflow-9-00.txt.

	Yes, I can do that. I'll work on it this week
	and send out the examples to the list.

> 
> h) In regards the Flow ID IE in the data model I could ask you for
> clarifications, but I wouldn't know what to ask for, it's just that it
> seems this concept deserves more wording to better understand it. For
> example, how is the flow identifier exactly prefix choosen? What
> happens in a fail-over scenario (CCE crashes, FAS crashes, both crash,
> etc) in regards to this Flow ID IE?

	I can add more text on that and provide an example of
	how it is done today. For now, here are the details.

	Flow ID = Prefix(8 bytes) + CCE ID (4 bytes)

	Basically the FAS picks a globally unique 8 byte prefix.
	Today that is done by using the FAS server's IP address in
	the first 4 bytes. The second 4 bytes is a monotonically
	increasing number. The initial value is picked at random.
	There are other ways to pick a unique prefix, this is how
	it's done today.

	The CCE ID is a monotonically increasing number starting
	at 1.

	This 12 byte value uniquely identifies a flow across
	all FAS's and all CCE's. 
	
	If the CCE crashes, it will get a new prefix from the FAS.
	It will start its CCE ID from 1 and increment from there.

	If the FAS crashes, the CCE can continue to use the prefix.
	Existing flows keep their flow ID and are merely reported
	to the new FAS. New flows also operate as normal (i.e. just
	increment the CCE-ID).

	When the FAS comes back up, the last prefix given out is
	in persisted storage, so it continues to hand out
	prefixes in order.

	If they both crash, the FAS and CCE operate as described
	above.

	Paul

> regards,
> Reinaldo

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/