Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

From: "Reinaldo Penno"<[email-masked]>
Date: Tue, 12 Feb 2002 00:18:27 -0800

Comments:

First ol all, would you guys mind if I rewrite this whole section using the
words "private side" and "public side" so we align our nomenclature to
RFC2663? 

Also, the subsection titles refer to "virtual" this and that, but the IEs
refer to "outside" and "inside". So, we need some unified terminology. I
also think that using inside and outside can cause confusion since the
exporter/collector does not know what's inside and outside. See
draft-iab-unsaf-considerations-01.html  

other stuff. 

1 ---- 

In 5.11.6.

"A type field contains the type of translation performed on the source port.
The following types are currently available:

1. - NAT
2. - LSNAT
3. - Web Cache"

Could we elaborate a bit more on what we mean by webcache? The exporter is
not the webcache per se, so maybe we should change it to "application
redirection".

Now, even in this case, application redirection/webcache is itself a form of
NAT. Or can also mean changing only L2 addresses (MAC addresses) in the
Direct Server Return case. So this option needs some splitting (more options
to be more specific). 

2 ---- 

In 5.11.6 and 5.11.7 is said that

"The Source Virtual IE contains the source address/port of the flow as
*transmitted* by the Exporter."

then in 5.11.18 and 5.11.9

"The Destination Virtual IE contains the destination address of the
flow/port as *received* by the Exporter"

It should be *transmited* by the exporter, ie, you need an almost complete
5-tuple set of IEs for the private side and for the public side.

3 ----

Also in 5.11.8 (Destination Virtual Address IE)

"The Destination Virtual IE contains the destination address of the flow as
received by the Exporter. It is generally different than the destination
port number, which contains the actual destination address of the flow."

I've already read this 3 times but maybe is getting late... but the
destination address of the flow is always different than the destination
port number. One is a port number, the other is a IP address.

I suggest to change it to.

"The Destination Virtual IE contains the destination address of the flow as
trasnmited by the Exporter. It might be different than the destination
source address, which contains the original destination address of the
flow."

BTW, what is LSNAT?

4 ---- 

5.14.4.  Internal queue priority

"A switch may map several of its internal priority queues into a Premium,
High, Medium or Low category."

I couldn't grasp this one. Wouldn't this be a vendor extension IE? Not only
the number of queues but even the names are vendor specific. 

5 ---- 

"5.10.1.  Source Address Netmask IE

The number of bits in the CIDR netmask, as defined in RFC 1519, for the
source address.

5.10.2.  Destination Address Netmask IE

The CIDR netmask, as defined in RFC 1519, for the destination address."

We should use the same definition for both (or bits or netmask).

6 ----

"5.9.3.  Egress ATM Subinterface"

Instead of "Subinterface", how about the old "circuit"? "Egress ATM Circuit"

7 ----

"5.9.4.  EGRESS_FRAME_RELAY_SUBINTERFACE IE

The egress DLCI for the flow is provided in this IE. ITU Q.922 defines the
DLCI range."

Can we just call it "EGRESS_FRAME_RELAY_DLCI"? The definition mentions DLCI
but we call it subinterface in the title?

8 ----

"5.11.4.  Source VLAN ID IE"

Shouldn't we also have an IE for the priority bits (802.1p)?

regards,

Reinaldo

---

From: "Reinaldo Penno"<[email-masked]>
Date: Tue, 12 Feb 2002 05:04:25 -0800

Juergen,

comments inline..

>-----Original Message-----
>From: Juergen Quittek [mailto:[email-masked]]
>Sent: Tuesday, February 12, 2002 4:43 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth;
>[email-masked]
>Cc: data; [email-masked]
>Subject: RE: [ipfix] Draft updates - Comments on the data model 
>
>
>--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote:
>
>>
>> Comments:
>>
>> First ol all, would you guys mind if I rewrite this whole
>> section using the words "private side" and "public side" so
>> we align our nomenclature to RFC2663?
>
>Why risking further inconsistencies? Just refer to RFC 2663.
>All you want to introduce is well explained there.

agreed. 
>
>>
>> Also, the subsection titles refer to "virtual" this and that,
>> but the IEs refer to "outside" and "inside". So, we need some
>> unified terminology. I also think that using inside and outside
>> can cause confusion since the exporter/collector does not know
>> what's inside and outside. See draft-iab-unsaf-considerations-01.html
>
>I still have problems with "virtual", "inside", and "outside".
>This applies to firewalls and IPv4 NATs, but not to several other
>boxes. Why not using more general terms, such as "received" and
>"transmitted" or "original" and "modified". These terms would
>apply to a wider range of boxes (what is "inside" for a NAT-PT?).

well, then we are in agressive agreement(;-) That's exactly what I wrote.

>
>This would make the draft more independent from certain NAT/firewall
>scenarios and would be understandable even for people who do not care
>about NAT issues at all.
>
>Reinaldo, you talked about good writing. I think this includes
>avoiding irrelevant information (while still remaining clearly
>understandable).

I would also prefer different terms. Anybody against changing? Paul?

>[...]
>> "The Destination Virtual IE contains the destination address of
>> the flow/port as *received* by the Exporter"
>>
>> It should be *transmited* by the exporter, ie, you need an almost
>> complete 5-tuple set of IEs for the private side and for the
>> public side.
>
>You see, it already gets confusing. "received/original destination"
>would have been a much better choice of term compared to "virtual
>destination".
>
>    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
>
>
>

---

From: "Norseth, KC" <[email-masked]>
Date: Tue, 12 Feb 2002 08:46:50 -0500

There is a need to do some rewrite in the data, to make the source look like
one document.  Currently, the document is of 2 definit design styles.  If
someone can help with that, it would be great.  Just let me know what
section so we are not working on the same piece.  I will be focusing on this
myself.

K.C.

|-----Original Message-----
|From: Juergen Quittek [mailto:[email-masked]] 
|Sent: Tuesday, February 12, 2002 5:43 AM
|To: Reinaldo Penno; K.C. Norseth; [email-masked]
|Cc: data; Calato, Paul
|Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on 
|the data model 
|
|
|--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote:
|
|>
|> Comments:
|>
|> First ol all, would you guys mind if I rewrite this whole section 
|> using the words "private side" and "public side" so we align our 
|> nomenclature to RFC2663?
|
|Why risking further inconsistencies? Just refer to RFC 2663. 
|All you want to introduce is well explained there.
|
|>
|> Also, the subsection titles refer to "virtual" this and 
|that, but the 
|> IEs refer to "outside" and "inside". So, we need some unified 
|> terminology. I also think that using inside and outside can cause 
|> confusion since the exporter/collector does not know what's 
|inside and 
|> outside. See draft-iab-unsaf-considerations-01.html
|
|I still have problems with "virtual", "inside", and "outside". 
|This applies to firewalls and IPv4 NATs, but not to several 
|other boxes. Why not using more general terms, such as 
|"received" and "transmitted" or "original" and "modified". 
|These terms would apply to a wider range of boxes (what is 
|"inside" for a NAT-PT?).
|
|This would make the draft more independent from certain 
|NAT/firewall scenarios and would be understandable even for 
|people who do not care about NAT issues at all.
|
|Reinaldo, you talked about good writing. I think this includes 
|avoiding irrelevant information (while still remaining clearly 
|understandable).
|
|> other stuff.
|>
|[...]
|>
|> then in 5.11.18 and 5.11.9
|>
|> "The Destination Virtual IE contains the destination address of the 
|> flow/port as *received* by the Exporter"
|>
|> It should be *transmited* by the exporter, ie, you need an almost 
|> complete 5-tuple set of IEs for the private side and for the public 
|> side.
|
|You see, it already gets confusing. "received/original 
|destination" would have been a much better choice of term 
|compared to "virtual destination".
|
|    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
|
|
|
|--
|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/
|

---

From: "Reinaldo Penno"<[email-masked]>
Date: Tue, 12 Feb 2002 05:04:25 -0800

Juergen,

comments inline..

agreed.

---

From: "Norseth, KC" <[email-masked]>
Date: Tue, 12 Feb 2002 08:46:50 -0500

K.C.

---

From: "Reinaldo Penno"<[email-masked]>
Date: Tue, 12 Feb 2002 06:03:48 -0800

Hello K.C.
 
I cannot access the URL of the drafts anymore...
 
Anyway, I can work on the sections I commented on. The ones related to
NAT/Firewall/Cache/etc and 5.14.4, 5.10.1, 5.10.2, 5.9.3, 5.9.4. 5.11.4 and
I can come up the IEs for 802.1p. I believe Juergen already wrote some text
for NAT sections also.
 
regards,
 
Reinaldo

-----Original Message-----
From: Norseth, KC [mailto:[email-masked]]
Sent: Tuesday, February 12, 2002 5:47 AM
To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth;
[email-masked]
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data
model 

K.C. 

|From: Juergen Quittek [ mailto:[email-masked]
<mailto:[email-masked]> ] 
<http://www.ccrle.nec.de>  
|Help        mailto:[email-masked]
<mailto:[email-masked]>  and say "help" 
|Unsubscribe mailto:[email-masked]
<mailto:[email-masked]>  and say 
<http://ipfix.doit.wisc.edu/archive/>  
|

---

From: "Norseth, KC" <[email-masked]>
Date: Tue, 12 Feb 2002 09:44:51 -0500

Hi Reinaldo,
 
sounds good.
 
5.12 - NAT
5.14.4 - Internal Queue Priority
5.10.1-2 - netmask
5.9.3-4 - ATM & Frame Relay
5.11.4 - VLAN.  (I duped VLAN, it is also 5.14.11), just make one.
 
Sorry on the URL down.  It has small bandwidth and unfortunately, if it
doesn't come back up on its own, It will be down until I can get to it this
afternoon. I can send anyone the drafts if they cannot access my url.  I
have the documents in both Word and Text format.
 
K.C.

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Tuesday, February 12, 2002 7:04 AM
To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data
model 

Hello K.C.

 
regards,
 
Reinaldo

-----Original Message-----
From: Norseth, KC [mailto:[email-masked]]
Sent: Tuesday, February 12, 2002 5:47 AM
To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth;
[email-masked]
Cc: data; Calato, Paul

K.C. 

|From: Juergen Quittek [mailto:[email-masked]

---

From: "Reinaldo Penno"<[email-masked]>
Date: Tue, 12 Feb 2002 06:52:05 -0800

Hello K.C.
 
The NAT part includes 5.11.6, 5.11.7, 5.11.8 and 5.11.9. Can you send me
both docs in word format?
 
thanks,
 
Reinaldo

-----Original Message-----
From: Norseth, KC [mailto:[email-masked]]
Sent: Tuesday, February 12, 2002 6:45 AM
To: Penno, Reinaldo [SC9:T327:EXCH]; 'Juergen Quittek'; K.C. Norseth
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data
model 

Hi Reinaldo,
 
sounds good.
 
5.12 - NAT

K.C.

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Tuesday, February 12, 2002 7:04 AM
To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data
model 

Hello K.C.

 
regards,
 
Reinaldo

-----Original Message-----
From: Norseth, KC [mailto:[email-masked]]
Sent: Tuesday, February 12, 2002 5:47 AM
To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth;
[email-masked]
Cc: data; Calato, Paul

K.C.

---

From: "Reinaldo Penno"<[email-masked]>
Date: Tue, 12 Feb 2002 20:53:49 -0800

Hello Paul,

the problem with the "virtual" word is that there is no way to find out what
is "virtual" and what is not. So, the "virtual" can be actually the real
one.  This is the same thing as outside and inside. See
draft-iab-unsaf-considerations-01.txt. In the case of twice NAT where Src,
Dest and Port may change it's really a mess.

regards,

Reinaldo

>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, February 12, 2002 9:04 AM
>To: Juergen Quittek
>Cc: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth;
>[email-masked]; data
>Subject: Re: [ipfix] Draft updates - Comments on the data model
>
>
>
>Comments in-line...
>
>Juergen Quittek wrote:
>> 
>	I thought I addressed this already buit let me try
>	again. BTW - I believe this my proposal is not
>	at all specific to NAT/firewall. Maybe an example is 
>	the best way to explain it. Using your terminology it
>	looks like this
>
>	Flow on the way out...
>
>		C -> IP-R gets translated to C -> IP-A
>
>	Gets reported as
>
>		Src              = C
>		Dest-Received    = IP-O
>		Dest-Transmitted = IP-A
>
>	On the way back
>
>		IP-A -> C  gets translated to IP-O -> C
>
>	Gets Reported as
>
>		Src-Received    = IP-A
>		Src-Transmitted = IP-O
>		Dest            = C
>
>
>
>	Now suppose I want to find all the flows to and from 
>	my virtual IP. First I need a list of virtual IP's so
>	I can find them. Then I need to search both the received
>	and transmitted fields for both Src and Dest. It can be
>	done but it can also be easier (maybe not easier for
>	the IPFIX protocol but that's not what we're here for).
>
>	If reported as I proposed it looks like this...
>
>
>
>		Src            = C
>		Dest-virtual   = IP-O
>		Dest-Actual    = IP-A
>
>		Src-virtual    = IP-O
>		Src-Actal      = IP-A
>		Dest           = C
>
>	Now if I want to see all the traffic for my
>	virtual IP's I just look for flows that have
>	the same src or dest virtual address. I don't
>	need a list and the query is simple. Also, the
>	data in the fields is clear. The actual field
>	is where the packet actually came from or
>	went to. The virtual is the requested source
>	or destination.
>
>
>	This work for ANY packet that gets re-directed for ANY
>	reason. Even if IP's are not actually modified. Such
>	as MAC based re-direction.
>
>
>>

---

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 13 Feb 2002 13:01:21 -0800

Hi Paul,

complementing what Juergen said, in the same NAT box you can have several
inside and outsides. You can have bi-directional NAT, twice bi-directional
NAT, etc. What is iniside for one can be outside for another.

Anyway, I think for the NAT stuff we should you expand the list from LFAP to
indicate what type of NAT/Application redirection/etc was made in the
packet. Beside just saying it was modified. there are several combinations,
but we should put only the more commons. Vendors can expand it as they wish.

regards,

Reinaldo

>Sent: Wednesday, February 13, 2002 5:59 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: Juergen Quittek; K.C. Norseth; [email-masked]; data
>From that draft....
>   However, as a side effect of address
>   translation, communicating endpoints on either side of the middlebox
>   do not know how to refer to themselves using addresses that are
>   applicable in the other realm -- the address translation is locked
>   within the middlebox. 
>
>
>I assumed it was the "middlebox" doing the reporting. In that
>case it has all the info needed. If not, then I agree
>trying to figure it out after the fact would be dificult.
>
>Paul
>
>Reinaldo Penno wrote:
>> 
>> Hello Paul,
>> 
>> the problem with the "virtual" word is that there is no way to find
>> out what is "virtual" and what is not. So, the "virtual" can be
>> actually the real one.  This is the same thing as outside and inside.
>> See draft-iab-unsaf-considerations-01.txt. In the case of twice NAT
>> where Src, Dest and Port may change it's really a mess.
>> 
>> regards,
>> 
>> Reinaldo
>>

---

From: "Reinaldo Penno"<[email-masked]>
Date: Wed, 13 Feb 2002 13:01:21 -0800

Hi Paul,

regards,

Reinaldo