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

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

Instead of "virtual", two suggestion for terminology from 2663, so we are
consistent with the current NAT terminology.

1 - "translated" (this is the easiest one, comes from the NAT acronym)
2 - "mapped" (comes from the terminology used in 2663)

regards,

Reinaldo

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, April 15, 2002 9:57 AM
>To: Juergen Quittek
>Cc: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC;
>[email-masked]
>Subject: Re: [ipfix-data] Data doc - Section 7.11
>
>
>
>Maybe the picture you drew on your PC would
>be helpful.
>
>Paul
>
>Juergen Quittek wrote:
>> 
>> Reinaldo,
>> 
>> --On 12 April 2002 23:05 -0700 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,
>> 
>> Not the packet is virtual, but the header entry for source
>> or destination addresses may be virtual. If a NAT replaces
>> the source address by its own one while forwarding a packet,
>> then I think it is acceptable calling the modified source
>> address field in the leaving packet 'virtual'.
>> 
>>     Juergen
>> 
>> > 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.
>> >
>> > 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: ###
>> >>>>>
>> >>
>> >>
>