Subject: RE: middlebox issues (was: [ipfix-arch] Answer to the recent comm ents on the Architecture Draft)

From: "Reinaldo Penno"<[email-masked]>
Date: Mon, 11 Feb 2002 18:06:58 -0800

Juergen,

comments inline.

:-----Original Message-----
:From: Juergen Quittek [mailto:[email-masked]]
:Sent: Monday, February 11, 2002 3:18 AM
:To: Penno, Reinaldo [SC9:T327:EXCH]; [email-masked];
:[email-masked]
:Subject: middlebox issues (was: [ipfix-arch] Answer to the recent
:comments on the Architecture Draft)
:
:
:> As far the text book statement, I disagree. Some people
:> confuse technical writing with bad writing. I think that
:> providing a small introductory section and associated reference
:> is a good writing practice. Of course , you feel free to disagree.
:
:Thank you for allowing me to disagree. I just mentioned text books,
:because it should explain the difference. Writing a good text book
:need good writing skills as well as writing good standards
:documents. However, the goals of both kinds of documentd are
:different.
:
:In standard documents you wat to have a clear and unambigous
:definiton or description of technical issues. Now, if we are
:writing a standard document concerning flow information export
:we should definitely explain in detail what is a flow what
:is the metering process and the export process.
:
:However, when we talk about NATs in our document, we should not
:try to define them again, but rather refer to another document
:containing a definition agreed on by NAT experts. In this case
:RFC 2663 would serve well. Otherwise we risk to create
:ambiguities by having differences in the two definitions.

right, but in the NAT section would say it would be good to write only
"refer to RFC2663"? I put only one paragraph, I will try to shorten it.

:
:May be the three lines I suggested are too generic, but I do
:not see a reason yet, why we have to distinguish dropping
:on a firewall, drooping on a router, dropping at a traffic
:shaper, ...
:

I would say that dropping on a firewall is a administrative dropping. It's
different , for instance , from when you drop fragmented TCP/UDP packets
when running NAPT. The same goes for policing and shaping respectively.
There is a good discussion on this idea in 

http://community.roxen.com/developers/idocs/drafts/draft-iab-nat-implication
s-09.html.
http://community.roxen.com/developers/idocs/drafts/draft-iab-unsaf-considera
tions-01.html

:>
:> Same as above, this is too generic (specially in the case NAT).
:> I think we should set a minimum set of architectural considerations
:> when dealing with NAT. For instance, that is composed of two flows,
:> that in the case of twice NAT you should/must export both flows
:> (private and public) or otherwise notify the collector, etc, etc
:
:So you consider these to be two flows? Why then having the extra
:fields you call virtual address, virtual port, etc, if you anyway
:report two different flows? Just a reference to the other flow
:would be fine.

I debated this issue before. If the definition of one flow is a 5-tuple,
then NAT is by definition composed of two flows. Now, you can report the two
flows separate or in the same flow record. Reporting them separte means
providing something to bind them.

Toughts?

:
:I think we would go very well with a generic coverage of all
:middleboxes modifying packet headers (other than TTL). Particularly,
:after you already suggested that the modified field contains
:a tag indicating the reason for modification (NAT, DSCP marking, ...).
:

What about OPES? Should we say that in the case an OPES service in running
on the same box the number of packets in the flow MUST be exported?

See
http://community.roxen.com/developers/idocs/drafts/draft-iab-opes-01.html

:>
:
:
:I still would remove these sections, but I do not insist in all the
:cuts I suggested. So let's go on and try to get more text

Again, I can shorten them and just make a reference.

:>
:>
:> :
:> :Section 6.4.5.1.1. makes a good point in requesting an IE for
:> :the VPN-ID. However, the statement "MUST include VPN-ID in the
:> :exported flow record" is too strong. We may require that it
:> :MUST be able to do so, but the user should be free o configure
:> :export such that VPN-ID is not exported.
:>
:> Can you elaborate on why not exporting this?
:
:I did not say "forbid export", but just "not require export
:all times". Users should be able to select and configure
:themselves what fields to be exported.

okay..But I guess the information would be useless. It the same case as
twice NAT. 

thanks for the comments,

Reinaldo