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

From: "Reinaldo Penno"<[email-masked]>
Date: Tue, 9 Apr 2002 14:49:55 -0700

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

An exporter may be involved in providing services that require 
application level intelligence and/or transform or filter content such 
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.

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 
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: ###

6.12.4.  Destination Virtual Port 

This information element contains the destination 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 destination 
port information element, which contains the original destination port 
of the packet.  

Template ID: ###   Field Type: ###   Size: ###

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 12 Apr 2002 13:30:08 +0200

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:
>

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.
> 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 :-)

> 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.

> 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

> information element, which contains the original source address of the packet.
>

--
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/