Subject: IETF: RTFM in CABINET room

From: Nevil Brownlee <[email-masked]>
Date: Mon, 8 Nov 1999 16:14:51 +0000

Hello all:

1) The five RTFM Internet Drafts were published on 4 Nov 99
   as RFCs 2720-2724.  RFC 2720 is the (Proposed Standard)
   Meter MIB.

2) I'm sorry to have given such short notice of the informal
   RTFM get-together at IETF.

3) The get-together at IETF will be held at lunchtime Wednesday
   10 Nov in the CABINET ROOM;  we'll start at about 1140.
                 ************                        ****

4) Topics for dicussion (please feel free to suggest more):
   - Monitoring QoS.  Does anyone have experience to report?  
     What attributes are useful for this?  DSCodePoint?  
     To/FromBitRate? ??
   - Multiport implementations of the RTFM meter (e.g. in a 
     router).  Any experience reports on this?
   - Multicast attributes.  DestMulticastCount (INTEGER, count 
     attribute) and IsMulticast (INTEGER, address attribute) have
     been suggested.  Any other ideas?
   - IPv6.  The capability for metering this is available in 
    NeTraMet v4.3.  Any experience to report with using this?

Cheers, Nevil

+---------------------------------------------------------------------+
| Nevil Brownlee                     Director, Technology Development |
| Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
|   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand |
+---------------------------------------------------------------------L

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 08 Nov 1999 18:13:30 +0100

Hello Neville,

Unfortunately, neither myself or one of my colleagues will
be able to meet you at this IETF meeting. Instead, I will
use this message for reporting on the issues you listed.

I hope, we will meet again at one of the upcoming IETF
meetings.

>    10 Nov in the CABINET ROOM;  we'll start at about 1140.

We have built one for an MPLS multicast system over ATM.
For simplification we collected data about each interface
at the switch controller and forwarded it to NeFlowMet
via NetFlow. In the next stage we intend to build a similar
system for an Linux-based router. We assume that we cannot
just use NeTraMet and run it on all interfaces, because
then we would have to compare packets at different interface
in order to avoid counting them twice.

>      been suggested.  Any other ideas?

DestMulticastCount is really an improvement. It gives you
useful information you cannot get otherwise via the Meter MIB.
Contrarily, whether or not introduce IsMulticast is a question
of convenience.
In a rule file you can substitute the check
    IsMulticast & 255 = 1: xxx,yyy;
with
    DestPeerAddress & 224.0.0.0 = 224.0.0.0: xxx,yyy;
So there is no real gain beyond readability.
But in the MIB, I find it convenient having a flow attribute
which immediately tells me whether the flow is a multicast flow
or not.
However, one can argue, that you can compute this attribute
with reasonable effort from the DestPeerAddress.
 
>     NeTraMet v4.3.  Any experience to report with using this?

We ran NeTraMet in our IPv6 test bed and we encountered some
problems, e.g. IPv6 icmp packets were assigned a peer type 6,
which is not defined in the MIB. Also we had problems viewing
IPv6 addresses. We have scheduled to work on fixing this before
the end of the year. If we manage to do so, we will send you
our patches.

Best wishes,

    Juergen
-- 
Juergen Quittek    [email-masked]   http://www.ccrle.nec.de
NEC Europe Ltd., C&C Research Laboratories  Tel: +49 30 254230-19
Hardenbergplatz 2, 10623 Berlin, Germany    Fax: +49 30 254230-99