Subject: [ipfix-arch] Answer to the recent comments on the Architecture Draft

From: "Reinaldo Penno"<[email-masked]>
Date: Sat, 9 Feb 2002 22:30:24 -0800

Hello Juergen,

let me address your concerns in one email, although some of these items were
already discussed ad-nauseum.

Here it goes.

1 - General Stuff:

:
:The draft distributed by KC discusses a lot of far related
:issues, but some essential components of the architecture are
:(so far) rather poorly described. This is different in the 
:I-D of Ganesh and Benoit.
:
:So why don't we take some text from it. I think their intention
:is to contribute to the joint document (see their title).

I really do not know what you mean by this. Are you trying to help them? 

:Please consider that the meter will be built partially in hardware 
:which is costly. Here we can save a lot by reducing some functions.
:The data collector implemented by software can be much more flexible
:with less cost.

huh? What are you talking about? okay, then *your* meter or who else you are
going to supply CHIPs to is going to be built partially in hardware. Please
do not generalize. The meter can be a PC-probe running some software.

:So lets have a protocol which is more flexible as NetFlow version
:1-7, 

I will not comment on that too much...Basically we are not here to
reverse-engineer Netflow, but to incorporate some good ideas from it.

:but not much more complicated, in order to be successfully
:accepted by hardware vendors and application programmers.

ohh, please...Then Netflow is just right?

2 - Middlebox:

:In my view this section is completely useless in its current 
:state. What does it say about the architecture?
:
:It states that if you meter on a firewall you can do this,
:you can do that. Maybe you can do even other things.
:Yes, a firewall can silently drop packets, drop them
:and export them, or drop them and send a message about this.
:But this is not a text book. What is the suggestion for the
:architecture?

This is the first draft of the architecutre document. In the next
interaction we will propose  what methods SHOULD be supported if you offer
firewall services.

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.

:
:My suggestion is deleting this section, and replacing it by
:a more general paragraph added to the description of the 
:metering process, which is a subsection missing in section 4.
:There we can discuss packet drop at an observation point. 
:Something like:
:
:    Observed packets might be dropped at an observation point.
:    If the meter can observe also the act of dropping it may
:    add information on this to the flow record.

Well, I disagree with this. This is on the other hand is too generic. In the
architecture document we need to set some sort of expectations on the
behavior of the exporter when other services running on the same device can
alter the result of measurement process.

:
:Then I suggest to add two IEs to section 9:

This is already there...

<snip>..<snip>

:We do not need a lecture on what is a NAT and what is a 'twice NAT'.
:This is (or should be) covered by other RFCs focussing on this issue.

My argument is the same as before. Some people confuse technical writing
with bad writing. I think that providing a small introductory section and
associted reference is a good writing practice that is followed in several
RFC/I-D. Of course , you feel free to dsagree.
 
:I suggest to replace sections 6.4.2. and 6.4.3. by a more general 
:discussion of the issue in section 4, for eample:
:
:    Observed packets might be modified at an observation point.
:    Examples are changing the MPLS label, changing the DiffServ Code 
:    point at DiffServ markers, replacing IP addresses and port numbers 
:    at NATs, and even the increment of the TTL field.
:

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

:This comment refers to sections 6.4.2. Tunneling in the draft 
:distributed by KC.
:
:The statement in the first paragraph is clearly an applicability
:statement. It does not belong to section 6 titled 'Architectural
:Requirements', but to a section called 'Applicability'. Or, if 
:we will have a seaprate draft on applicability, we should move 
:it there.

Just like the NAT case, issues and behavior related to

*Tunnel terminates on exporter

*Tunnel initiates on exporter

*Exporter implements tunnel switching

should be discussed and the set of expectations established. In the case of
tunnel switching for instance, we should/must export the flows of the
incoming and outgoing tunnel. 

:This comment refers to sections 6.4.5. VPNs in the draft
:distributed by KC.
:
:The first two paragraphs and subsection 6.4.5.1 (without
:6.4.5.1.1. and 6.4.5.1.2.) belong to a section on applicability 
:statements and not to the IPFIX architectural requirements.

The portion of text you mentioned is a introduction to the problem
statement. I could have just written section 6.4.5.1.2. directly, but again,
I consider that good practice and several RFC/I-D follow this model.
Somebody that do not understand VPN will just be lost. 

For that matter, the bottom line is that this whole draft is not explicitly
directed to you or even the people of this mailing list, but to a much wider
audience (the whole IETF and beyond).
 
:
: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?

3 - Capability Negotiation:

:I think that configuration should be done out of band. Either 
:by another
:protocol or MIB (for which to develop we are not chartered) or by
:traditional CLI (as usual).

We are not chartered to do a protocol, so the point is moot. The capability
negotiation (or advertisment some people prefer it) would then by definition
be "another protocol".

"traditional CLI (as usual)". Let me be straight to the point here to avoid
tip-toeing around the issue. Are you talking about Cisco routers? How come
you say this is the usual method? For whom? Tons of vendors support some
form of HTTP or GUI configuration.

:
:Adding configuration to the protocol would make it very complicated.
:We would need another data model just for configuring the device.
:In my view this significanlty violates the general KISS requirement
:every IP protocol should meet.
:

Are you saying that PPP, BGP and OSPF are bad designed protocols?

:
:As for capability negotiations, I have the same concern about keeping
:it simple. Definitely, I do not like to have any NEGOTIATION. If we
:really think it is necessary we might have the data collector 
:requesting
:

Again this is a question of semantics. For me what BGP does is negotiation,
you may call it a "multi-step" advertisement.

:But even this complicates an implementation significantly. If we 
:consider several collectors receiving data from the same reporter, 
:then we have to save a record format for each collector, configure 
:the metering process such that all collectors are covered and export 
:individual records to each collector.
:

That's exactly why we should have a capability <negotiation,advertisement>.
Unless you are suggesting that for the first time in history exporters and
collectors from different vendors will have exactly the same capabilities. 

Let's suppose the exporters in your example above have different levels of
compliance to the standard, have vendor-extensions, etc. This is the more
general case and in fact I doubt that in a big heterogeneus network all the
componenets will be from a single vendor.

:This would be a lot of work to implement it on a router. Much easier
:is having a single configuration via CLI including a specification of
:collectors to which identical records are to be sent. 
:

So,instead of just saying to exporter what is the IP addres of the
collectors (from different vendors) and have them figure out what are the
capabilities, you are saying that "it's easier" (sic) to this by command
line? Are you talking about Cisco routers or maybe your personal
preferences?

regards,

Reinaldo

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 11 Feb 2002 09:42:52 +0100

Hi Reinaldo,

First of all, I separated my comments into several emails
covering different subject. As you noticed, I covered
different subjects in these messages. And my experience is
that discussing several issues in parallel with the same subject
line is a bad idea, because then it is harder to follow
discussions on the individual subjects.

Therefore, I split again my responses to your message.
Here is the first one.

--On 09 February 2002 22:30 -0800 Reinaldo Penno <[email-masked]> wrote:

>
> Hello Juergen,
>
> let me address your concerns in one email, although some of these items were already discussed ad-nauseum.
>
> Here it goes.
>
> 1 - General Stuff:
>
> :

What do you mean by "helping THEM"? Is there a 'us' and 'them'?
They are members of the design team. My intention is to help US
in making good progress.

For what would Ganesh and Benoit need my help? For futher making
technically good contributions to this working group? I think that
so far, they made the most substancial contributions to our
architecture discussion - technically speaking.

I agree, that they should have told us earlier, how much effort
they already spent in the architecture. But I think beyond his
they did everything right. They just compiled all their
contributions in the I-D text format and distributed them.
It was a decision of the design team at the last phone conference
that they should submit their contributions as an individual I-D.
This is exactly the working groups are recommended to exchange
and discuss contributions of the size of theirs.

My point is that I am confused about the fact that KC ignored
everything they wrote when compiling the design team's draft,
particularly because issues covered by Ganesh's and Benoit's
draft are not covered in the drqaft he distributed. Is a later
integration planned?

Cheers,

    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: Juergen Quittek <[email-masked]>
Date: Mon, 11 Feb 2002 11:01:56 +0100

Hi Reinaldo,

--On 09 February 2002 22:30 -0800 Reinaldo Penno wrote:
> huh? What are you talking about? okay, then *your* meter or who else
> you are going to supply CHIPs to is going to be built partially in hardware.
> Please do not generalize. The meter can be a PC-probe running some software.

Sorry, I guess you got me wrong. I did not say all implementations
of the meter must be in hardware. I just said that there will be
hardware-supported implementations of the meter (at least this is
my plan at NEC). Therefore I like to have an eye on not making
hardare implementations too costly, particularly when choosing the
features of the meter.

I do not understand why you concluded that I generalize and ignore
software implementations.
> reverse-engineer Netflow, but to incorporate some good ideas from it.

I fully agree. Particularly, we do not have to re-engineer anything,
because we have Cisco engineers on board.
> ohh, please...Then Netflow is just right?

Well, if you had read my explicit statement a few lines above,
you would know that I do not think that NetFlow 1-7 is what we need.

But I definitely think that we should define something that easily
intergrated into router products. Therefore cost of development
and cost of production are not to be completely ignored.

Cheers,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 11 Feb 2002 12:17:32 +0100

Hi Reinaldo,

--On 09 February 2002 22:30 -0800 Reinaldo Penno wrote:
 [...]
> This is the first draft of the architecutre document. In the
> next interaction we will propose what methods SHOULD be
> supported if you offer firewall services.

OK, let's continue discussion when we have the concrete text.

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

> Well, I disagree with this. This is on the other hand is too
> generic. In the architecture document we need to set some sort
> of expectations on the behavior of the exporter when other
> services running on the same device can alter the result of
> measurement process.

I do not think we need to have service specific expectations.
We can be open to implementations on a firewall to report on
packet dropping or not. Otherwise you could not run a general
prupose software implementation on a firewall, if it cannot
report on firewall specific dropping.

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

> :Then I suggest to add two IEs to section 9:

Thank you. I already found it and sent my more concrete
comments on it to the architecture volunteers list.
> My argument is the same as before. Some people confuse
> technical writing with bad writing. I think that providing a
> small introductory section and associted reference is a good
> writing practice that is followed in several RFC/I-D.
> Of course, you feel free to dsagree.

As mentioned above I distinguish good textbook writing from
good conference paper writing and good standard document writing.

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

> should be discussed and the set of expectations established. In the
> case of tunnel switching for instance, we should/must export the flows
> of the incoming and outgoing tunnel.

Similar to one of my statements above, I would not like to disallow
a general pupose software implementation of IPFIX to run on a tunnel
switch and to ignore all tunnel considerations by just monitoring the
IP stack.

This should be possible and the default case of our architecture!
Specific things like support of tunneling is nice to have, but should
definitely be optional.

> statement. I could have just written section 6.4.5.1.2. directly,
> but again, I consider that good practice and several RFC/I-D follow
> this model. Somebody that do not understand VPN will just be lost.
>
> For that matter, the bottom line is that this whole draft is not
> explicitly directed to you or even the people of this mailing list,
> but to a much wider audience (the whole IETF and beyond).

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

Cheers,

    Juergen

---

From: "Will Eatherton" <[email-masked]>
Date: Mon, 11 Feb 2002 07:24:00 -0800

Answer to the recent comments on the Architecture DraftGroup,

Cisco's interest in IPFIX  was to help establish a non-proprietary protocol
similar to netflow but more flexible allowing us to add value to our
customers (and do so in a timely manner).  If IPFIX goes down a path along
the lines as being advocated recent threads by Reinaldo,  it is unclear if
the added burden of the protocol will be make it worth the benefits of a
non-proprietary protocol.  Given it seems I have seen roughly the same
conversation occur 3 times in past several day, It is unclear if further
email discussion on this topic will resolve the underlying question as to
the scope of IPFIX.  It seems time for an official call on what is in/out of
scope for IPFIX.  As has been mentioned here multiple times we would like to
hear :
- the exporter configuration is out of the scope of this document   (the
exporter configuration out of band)

- no transport negotiation (which transport)

 - no capability negotiation

Will

  Reinaldo

---

From: "K.C. Norseth" <[email-masked]>
Date: Mon, 11 Feb 2002 21:25:23 -0700

Answer to the recent comments on the Architecture DraftWill,

I agree. Let's go for the wg concensus.  What do people say?

| - the exporter configuration is out of the scope of this document   (the exporter configuration out of band)

Configuration I think is out of scope, unless we hook it to an existing mib or something.  I so, we can refer to that mib or process.
|- no transport negotiation (which transport)

we need to define the action of each transport type.

| - no capability negotiation

Nice, but necessary?

K.C.
  ----- Original Message ----- 
  From: Will Eatherton 
  To: Reinaldo Penno ; [email-masked] ; [email-masked] 
  Cc: [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Monday, February 11, 2002 8:24 AM
  Subject: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

  Group,
   
  Cisco's interest in IPFIX  was to help establish a non-proprietary protocol similar to netflow but more flexible allowing us to add value to our customers (and do so in a timely manner).  If IPFIX goes down a path along the lines as being advocated recent threads by Reinaldo,  it is unclear if the added burden of the protocol will be make it worth the benefits of a non-proprietary protocol.  Given it seems I have seen roughly the same conversation occur 3 times in past several day, It is unclear if further email discussion on this topic will resolve the underlying question as to the scope of IPFIX.  It seems time for an official call on what is in/out of scope for IPFIX.  As has been mentioned here multiple times we would like to hear :  
  - the exporter configuration is out of the scope of this document   (the exporter configuration out of band)

  Will

    I will not comment on that too much...Basically we are not here to reverse-engineer Netflow, but to incorporate some good ideas from it.

    Reinaldo

---

From: Michael MacFaden <[email-masked]>
Date: Tue, 12 Feb 2002 00:47:57 -0800

>| - the exporter configuration is out of the scope of this document   (the exporter configuration out of band)

Inband configuration makes the protocol more complex 
as well as being prone to additional security risks.

So I'd prefer in-band configuration not be part of the scope of the 
current effort. 

That said, I would not wan to rule out experimentation 
or future ability to add such a feature in a way that
can be cleanly discovered in a mixed envionment. 

An SNMP MIB module should be made available to monitor
the various components and to define, if any, standard 
configuration objects.

Mike MacFaden