Subject: RE: [ipfix-data] Data doc - Section 7.11

From: "Reinaldo Penno"<[email-masked]>
Date: Mon, 15 Apr 2002 10:19:20 -0700

Hello Paul,

correct. SHOULD or MAY could be used in the text.

thanks,

Reinaldo

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, April 15, 2002 8:41 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: Juergen Quittek; Norseth, KC; [email-masked]
>Subject: Re: [ipfix-data] Data doc - Section 7.11
>
>
>Reinaldo Penno wrote:
>> 
>> My concern with the "virtual" wording is that there is nothing
>> "virtual" about the modified packet. Virtual implies the
>> original/actual packet is more real than the modified one, which is
>> not. The modified packet can actually be more "real" if you are doing
>> NAT, for instance. My opinion is that another terminology sould be
>> used.
>> 
>> As for the first question, imagine you receive a packet and you apply
>> several services to it (NAT, insertion of content, whatever) and you
>> want to report that (the services applied) on flow records.
>> 
>> So, the order in which you apply these services matters and so the
>> order in which you report them. As I said, if you apply NAT and then
>> some firewall (possibly dropping the packet), but on the flow records
>> you say the other way around, you will get the wrong picture. This is
>> a easy example, but you can expand that for all other services that
>> modify, drop, tunnel a packet.
>
>	If you are saying that if more than one of these fields
>	are reported in a flow then they must be in order,that 
>	seems reasonable to me too. But we are NOT saying you must 
>	report the fields in the first place, correct?
>
>> 
>> regards,
>> 
>> Reinaldo
>> 
>> >-----Original Message-----
>> >From: Juergen Quittek [mailto:[email-masked]]
>> >Sent: Friday, April 12, 2002 6:42 PM
>> >To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC;
>> >[email-masked]
>> >Cc: [email-masked]
>> >Subject: RE: [ipfix-data] Data doc - Section 7.11
>> >
>> >
>> >Hi Reinaldo,
>> >
>> >With 'reflect the order of the operstions performed', do you mean
>> >finding out what is the original and what the modified header field?
>> >
>> >I had a long discussion on the modified scheme versus the modified
>> >scheme with Paul:
>> >
>> >The virtual scheme:
>> >  Any source-related header field in an arriving packet is called
>> >  actual. Any destination-reated header field in a leaving packet
>> >  is called actual. Actual values are the ones usually reported.
>> >
>> >  If the value of a source-related header field in a leaving packet
>> >  differs from its value in the arriving packet, then this value is
>> >  called 'virtual'. If the value of a destination-related header
>> >  field in an arriving packet differs from its value in the leaving
>> >  packet, then this value is called 'virtual'.
>> >
>> >The modified scheme:
>> >  The value of a header field in an arriving packet is called
>> original.
>> >  Original values are the ones usually reported.
>> >  If the value of a header field is modified in the leaving packet,
>> >  then it may be reported as the 'modified' value.
>> >
>> >In the end we preferred the virtual scheme. But please feel free
>> >to convince us that the modified scheme is more appropriate.
>> >
>> >    Juergen
>> >
>> >
>> >--On 12 April 2002 11:45 -0700 Reinaldo Penno
>> ><[email-masked]> wrote:
>> >
>> >>
>> >> Hello Juergen,
>> >>
>> >> thanks for the comments. answers inline
>> >>
>> >>> -----Original Message-----
>> >>> From: Juergen Quittek [mailto:[email-masked]]
>> >>> Sent: Friday, April 12, 2002 4:30 AM
>> >>> To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC;
>> >>> [email-masked]
>> >>> Cc: [email-masked]
>> >>> Subject: Re: [ipfix-data] Data doc - Section 7.11
>> >>>
>> >>>
>> >>> Hi Reinaldo,
>> >>>
>> >>> --On 09 April 2002 14:49 -0700 Reinaldo Penno
>> >>> <[email-masked]> wrote:
>> >>>
>> >>>>
>> >>>> In the data doc there was a part that Paul disagrees (or
>> >>> used to) with me. I'm okay with finding other names anyway,
>> >>> but IMO the description is better this way
>> >>>>
>> >>>> Basically I wanted to change section on NAT/source
>> >>> virtual/destination virtual to:
>> >>>>
>> >>>> 7.11. Middlebox and other Services
>> >>>
>> >>> Having to choose between "Virtual Information" and "Middlebox and
>> >>> other Services", I prefer the first one, because it is as general
>> >>> as "other services" and it better reflects a meter's 
>view: It does
>> 
>> >>> not care that much about functions and applications/services
>> running
>> >>> additionally on the same box, it just cares about what such
>> >>> applications do with packets or beterr with packet headers. Then
>> >>> the concept of virtual and actual values of header fields seem so
>> >>> be an adequate and sufficient view of what is happening.
>> >>
>> >> no problem, I can change the name. Do you think the
>> >description is adequate?
>> >>
>> >>>>
>> >>>> An exporter may be involved in providing services that require
>> >>>> application level intelligence and/or transform or filter
>> >>> content such
>> >>>
>> >>> I don't think there will be any router or other exporter device
>> >>> that deserves the attribute 'intelligent'. These boxes are SO
>> dumb!
>> >>> Just work with them and you'll see :-)
>> >>
>> >> he!he! Some of them are a little more 'intelligent'..
>> >>
>> >>>
>> >>>> as middlebox and OPES respectively.
>> >>>>
>> >>>> When the exporter is involved on these types of services
>> >the order of
>> >>>> the IEs that contain information associated with these service
>> MUST
>> >>>> reflect the order of the operations performed.
>> >>>
>> >>> No. We should not have a MUST here. This would mean that you
>> >>> cannot add middlebox functions to your box without updating the
>> >>> IPFIX software/hardware. You could not run the same 
>implementation
>> 
>> >>> on boxes with different functionality. It is nice if the IPFIX
>> >>> device reflects middlebox functions, but a MAY should be
>> >>> appropriate.
>> >>
>> >> What I meant by the above phrase is that the order on which
>> >these services are applied are very important ans o should be
>> >the reporting. If you apply NAT and then layer 2/3 tunneling
>> >is different than the other way around. If the exporter does not
>> >> indicate this, you might get misleading data in the end.
>> >>
>> >> So, my point was if you are ptoviding these service you
>> >SHOULD be able to report them on the order they were applied.
>> >I think that's reasonable.
>> >>
>> >>>
>> >>>>
>> >>>> Each type field of the following IEs contain the type of
>> operation
>> >>>> performed on the packet. The currently available types are:
>> >>>>
>> >>>> 1. - NAT
>> >>>> 2. - LSNAT
>> >>>> 3. - Twice NAT
>> >>>> 4. - Request Routing [KRR]
>> >>>> 5. - Outgoing L3 Tunnel
>> >>>> 6. - Incoming L3 Tunnel
>> >>>> 7. - Outgoing L2 Tunnel
>> >>>> 8. - Incoming L2 Tunnel
>> >>>> 9. - OPES (several sub-services here)
>> >>>> 10. - others...
>> >>>>
>> >>>> 6.12.1.  Modified Source Address
>> >>>>
>> >>>> This information element contains the source address of the flow
>> as
>> >>>> transmitted by the Exporter after a middlebox, OPES or
>> >>> similar service
>> >>>
>> >>> What is a OPES similar service? This is rather unclear,
>> particularly
>> >>> if you request a MUST to support it. I prefer Paul's term
>> >'redirecting
>> >>> packets/flows'.
>> >>>
>> >>>    Juergen
>> >>>
>> >>>> was applied to the packet. It may be different than the
>> >>> source address
>> >>>> information element, which contains the original source
>> >>> address of the packet.
>> >>>>
>> >>>> The address is defined the same as for Source Address.
>> >>>>
>> >>>> Template ID: ###   Field Type: ###   Size: ###
>> >>>>
>> >>>> 6.12.2.  Modified Source Port
>> >>>>
>> >>>> This information element contains the source port of the flow as
>> >>>> transmitted by the exporter after a middlebox, OPES or
>> >>> similar service
>> >>>> was applied to the packet. It may be different than the source
>> port
>> >>>> information element, which contains the original source port
>> >>> of the packet.
>> >>>>
>> >>>> Template ID: ###   Field Type: ###   Size: ###
>> >>>>
>> >>>> 6.12.3.  Modified Destination Address
>> >>>>
>> >>>> This information element contains the destination address
>> >of the flow
>> >>>> as transmitted by the exporter after a middlebox, OPES 
>or similar
>> 
>> >>>> service was applied to the packet. It might be 
>different than the
>> 
>> >>>> destination address information element, which contains
>> >the original
>> >>>> destination address of the packet.
>> >>>>
>> >>>> Template ID: ###   Field Type: ###   Size: ###
>> >>>>
>> >
>> >
>> >
>