Subject: [ipfix] Configuration & MIBS

From: "K.C. Norseth" <[email-masked]>
Date: Tue, 12 Feb 2002 23:23:27 -0700

Answer to the recent comments on the Architecture DraftAn email from Mike Mcfadden and Dave Harrington brought up the issues of mibs and management.  As Dave explained itt, it is almost expected that a mib be written as part of the WG for configuration of basic objects and monitoring.  This  is not in the charter, but we need to think about this.  How much could the RTFM mibs be used?  Would a config mib and a monitoring mib be useful?

What do people say?  This does not have to be answered as part of our work here, but it should be addressed at least in Minneapolis. ( I have my absestos suit on now).

K.C.
  ----- Original Message ----- 
  From: Kevin Zhang 
  To: [email-masked] ; Reinaldo Penno ; K.C. Norseth ; [email-masked] 
  Sent: Tuesday, February 12, 2002 8:19 AM
  Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

  Hi All,
     
    My views on the points raised by Will -
     
    The exporter configuration might be outside the scope of IPFIX; however, a negotiation process that allows the exporter and collector to sync on a protocol and information model is the best way to achieve interoperability and satisfy application requirements in the meantime; It is within the scope of the IPFIX WG.  Furthermore, a probe can be an exporter that has far more monitoring/metering flexibility.  By insisting on a rigid design, we are excluding an important segment of IPFIX users. 
     
    With regard to underlying transport, it was mentioned explicitly in our charter that the transport protocol has to be congestion aware.  I do believe there are situations that UDP might be used when it does not interfere other traffic (such as over LAN, see the architecture draft).  If transport layer can be negotiated (in-band or out-band), we can accommodate both reliable and unreliable transport protocols. 
     
    Thanks,
     
    Kevin

     
     -----Original Message-----
    From: majordomo listserver [mailto:[email-masked]]On Behalf Of Will Eatherton
    Sent: Tuesday, February 12, 2002 12:37 AM
    To: Reinaldo Penno; K.C. Norseth; [email-masked]
    Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

      Lets be more clear cut then this. I dont want to have a major architectural SHOULD on something we believe is fundamentally flawed and will occupy signficant group time to spec if it is left in.  We need a clear decision to move forward.  A spec that includes SHOULDS for all proposed features is weak.
       
      WIll
        -----Original Message-----
        From: majordomo listserver [mailto:[email-masked]]On Behalf Of Reinaldo Penno
        Sent: Monday, February 11, 2002 8:57 PM
        To: K.C. Norseth; [email-masked]; [email-masked]
        Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

        Hello Norseth,
         
        I think the right question to answer is not if it is "necessary", since you can always pay somebody to be some sort of CLI configuration master and do everything by hand.  
        I think the right question is if it should be on the architecture document or not and with whihch level of compliance. 
         
        I think it should be on the arch document and maybe putting it with a SHOULD instead of a MUST will make (most) people happy.
         
        cheers,
         
        Reinaldo

         -----Original Message-----
        From: K.C. Norseth [mailto:[email-masked]]
        Sent: Monday, February 11, 2002 8:25 PM
        To: [email-masked]; [email-masked]
        Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

          Will,

          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)

            - no transport negotiation (which transport)

             - no capability negotiation

            Will

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

              Reinaldo

---

From: [email-masked]
Date: Wed, 13 Feb 2002 13:41:27 +0100 (CET)

Hi KC,

Thanks for putting emphasis on the issue. My position is the following:

A MIB for configuring the Meter/exporter would be a useful thing,
although MIBs are probably more often used for monitoring than for
configuration. Maybe this MIB could also be used to monitor configuration
and operation of the meter/exporter. But I do not believe, that we 
need another MIB for reading metered data. The Meter MIB is defined 
and should serve this purpose sufficiently.

However, all of these issues should be discussed when our working
group is close to finishing its current tasks. When we have stable 
versions of all our planned documents, we can discuss with our AD
about re-chartering ideas.

Maybe our view of MIB or other configuration requirements have
developed further until then.

Best wishes,

    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

"K.C. Norseth" <[email-masked]> wrote:

> Answer to the recent comments on the Architecture DraftAn email from
> Mike Mcfadden and Dave Harrington brought up the issues of mibs and
> management.  As Dave explained itt, it is almost expected that a mib be
> written as part of the WG for configuration of basic objects and
> monitoring.  This  is not in the charter, but we need to think about
> this.  How much could the RTFM mibs be used?  Would a config mib and a
> monitoring mib be useful?
> 
> What do people say?  This does not have to be answered as part of our
> work here, but it should be addressed at least in Minneapolis. ( I have
> my absestos suit on now).
> 
> 
> K.C.
>     The exporter configuration might be outside the scope of IPFIX;
> however, a negotiation process that allows the exporter and collector to
> sync on a protocol and information model is the best way to achieve
> interoperability and satisfy application requirements in the meantime;
> It is within the scope of the IPFIX WG.  Furthermore, a probe can be an
> exporter that has far more monitoring/metering flexibility.  By
> insisting on a rigid design, we are excluding an important segment of
> IPFIX users. 
>      
>     With regard to underlying transport, it was mentioned explicitly in
> our charter that the transport protocol has to be congestion aware.  I
> do believe there are situations that UDP might be used when it does not
> interfere other traffic (such as over LAN, see the architecture draft). 
> If transport layer can be negotiated (in-band or out-band), we can
> accommodate both reliable and unreliable transport protocols. 
>      
>     Thanks,
>      
>     Kevin
>      
>      
>      
>      
>       Lets be more clear cut then this. I dont want to have a major
> architectural SHOULD on something we believe is fundamentally flawed and
> will occupy signficant group time to spec if it is left in.  We need a
> clear decision to move forward.  A spec that includes SHOULDS for all
> proposed features is weak.
>        
>       WIll
>         From: majordomo listserver
> [mailto:[email-masked]]On Behalf Of Reinaldo Penno
>         Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the
> recent comments on the Architecture Draft)
> 
> 
>         Hello Norseth,
>          
>         I think the right question to answer is not if it is
> "necessary", since you can always pay somebody to be some sort of CLI
> configuration master and do everything by hand.  
>         I think the right question is if it should be on the
> architecture document or not and with whihch level of compliance. 
>          
>         I think it should be on the arch document and maybe putting it
> with a SHOULD instead of a MUST will make (most) people happy.
>          
>         cheers,
>          
>         Reinaldo
>          
>          
>           | - 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.
>             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)
> 
>               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.
> 

--
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: Michael MacFaden <[email-masked]>
Date: Wed, 13 Feb 2002 10:24:21 -0800

On Wed, Feb 13, 2002 at 01:41:27PM +0100, [email-masked] wrote:
>configuration. 

Folks,

A MIB module defines a technology's standard interface
to the managment plane. It is not the same thing as the Simple 
Network Management Protocol v1/v2c/v3. 

RFC 2571 depicts the architecture of the IETF standard management framework. 
One versatile component of this framework is the Structure of Management Information 
(SMIv2) RFC 2578-80 which defines the contents of MIB modules.

IETF standard MIB modules should expose the common configuration knobs 
found in the underlying technology and rarely should a MIB module define
additional new knobs. (Kinda like architecture plans).

A MIB module is a concise guide to implementors in their design of 
a configuration interface (CLI, XML, XYZ, whatever) 
to manage a given techology. 

Also note: there is only one MIB.

>Maybe this MIB could also be used to monitor configuration

In addition to general security requirements, there is always a general 
management requirement. 

In practice, we have found it useful to instrument LFAP via CLI/SNMP to keep 
track of collection systems.

>about re-chartering ideas.

I agree. I suggest that the underlying technology clearly
define recommended default settings as well as what common things
one can change as well as monitor and if possible the impact of the
change. For example: BGP finally being able to handle temporary disconnects 
when software upgrades are done to a device/support switching to redundant
cpus.

>developed further until then.

Indeed. 

Regards,
Mike MacFaden