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

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

Juergen,

if it's the packet, the src/dest address or whatever the argument remains. I
think it's fair to say that "virtual" is not the best terminology to be
used. I'm sure we can find a better term. As I said it implies that the
original packet/header/field/whatever is more real (whatever this means)
than the original/actual.

Not to mention that in cases where you have twice/bi-directional NAT this
can be a source of confusion.

thanks,

Reinaldo

>-----Original Message-----
>From: Juergen Quittek [mailto:[email-masked]]
>Sent: Monday, April 15, 2002 9:55 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]; Norseth, KC;
>[email-masked]
>Cc: [email-masked]
>Subject: RE: [ipfix-data] Data doc - Section 7.11
>
>
>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: ###
>>>>>>
>>>
>>>
>
>
>

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 16 Apr 2002 09:38:41 +0200

Reinaldo,

--On 15 April 2002 10:04 -0700 Reinaldo Penno <[email-masked]> wrote:

>
> Juergen,
>
> if it's the packet, the src/dest address or whatever the argument
> remains. I think it's fair to say that "virtual" is not the best
> terminology to be used. I'm sure we can find a better term. As I said
> it implies that the original
> packet/header/field/whatever is more real (whatever this means) than
> the original/actual.

Well, it is more real in some way. As in the example I gave you
with a NAT replacing the original source address by its own one
it might be quite intuitive to call this destination address
virtual.

But I see your point. The semantics of 'original' value and
'modified' value of a header field changed at the observation
point is much more clear and potentially easier to reason about
than the concept of 'virtual' value and 'actual' value of a
header field.

I had been arguing pro original/modified and contra actual/vritual
for along time with Paul until he convinced me, but I still see
good reasons for both alternatives.

Are there others than Reinaldo, Paul and me having an opinion on
what concept we should prefer for the IPFIX info model?

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

>
> Not to mention that in cases where you have twice/bi-directional NAT
> this can be a source of confusion.
>
> thanks,
>
> 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/