Subject: RE: [ippm] Way to store traceroutes

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 17 Jan 2005 14:03:42 +0100

Hi Andy,
the purpose of our draft is to define a file format in order to store
traceroute measurements and not a MIB module.
The confusion is maybe created by the fact that we just kept the names
from the disman draft-RFC in order to facilitate comprehension of the
fields itself.

By the way, I do not know if the IPPM list agrees on this.
Does the IPPM charter want to define a MIB module for traceroute
measurements?

Best regards,
Saverio

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]]
> Sent: 17 January 2005 10:53
> To: Andy Bierman; Saverio Niccolini
> Cc: [email-masked]; [email-masked]
> Subject: RE: [ippm] Way to store traceroutes
> 
> Hi Andy,
> 
> --On 14.01.2005 20:25 Uhr +0100 Andy Bierman wrote:
> 
> > At 07:59 AM 1/14/2005, Saverio Niccolini wrote:
> >> Dear all,
> >> thanks a lot for your useful suggestions.
> >
> > This work is already established in the DISMAN WG.  See RFC 2925,
> > or its update (in progress):
> > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-
> 06.txt
> 
> Saverio and Sandra already had a look at the DISMAN-TRACEROUTE-MIB.
> 
> > I strongly urge you to work with the DISMAN WG to resolve
> > perceived deficiencies with the RemOps MIB, rather than
> > create a spin-off MIB.
> 
> As editor of draft-ietf-disman-remops-mib-v2-06.txt I wonder
> what you consider as 'perceived deficiencies with the RemOps MIB'.
> 
> In the context of IPPM, there is certainly the deficiency, that
> you can only store measurements that were performed locally and that
> the tables for storing measurement results are read-only.
> 
> But anyway, does the IPPM WG plan to store traceroute results in a
MIB?
> 
> Thanks,
> 
>     Juergen
> --
> Juergen Quittek        [email-masked]       Tel: +49 6221
90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221
90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
> http://www.netlab.nec.de
> 
> 
> > Andy
> >
> >
> >
> >> We have tried to draft a "traceroute object" based on what we
discussed
> >> on the list and what we had in mind. We think this will serve as a
> >> starting point of our information model.
> >>
> >> We have taken the disman draft as a starting point and we have
erased
> >> some fields not useful in the scope of our draft (that we do not
> specify
> >> here), moreover we have added and changed other ones:
> >>
> >> NEW fields:
> >> 1) traceRouteResultsLastGoodPathDuration (duration of single
running of
> >> the last good traceroute path determination)
> >> 2) traceRouteResultsLastRun (when the last traceroute with these
> >> characteristics was launched)
> >> 3) traceRouteHopsASNumber (AS number of the hop)
> >>
> >> CHANGED fields:
> >> 1) traceRouteProbeHistoryTime (timestamp of when the traceroute
probe
> >> came back) was changed to traceRouteProbeHistorySentTime (timestamp
of
> >> when the traceroute probe was sent)
> >>
> >>
> >> Please find here how the "traceroute object" looks like right now:
> >>
> >> --traceRouteObjects
> >>  |
> >>  +--traceRouteCtlTable
> >>  |  |
> >>  |  +--traceRouteCtlEntry
> >>  |     |
> >>  |     +--traceRouteCtlOwnerIndex
> >>  |     +--traceRouteCtlTestName
> >>  |     +--traceRouteCtlTargetAddressType
> >>  |     +--traceRouteCtlTargetAddress
> >>  |     +--traceRouteCtlByPassRouteTable
> >>  |     +--traceRouteCtlDataSize
> >>  |     +--traceRouteCtlTimeOut
> >>  |     +--traceRouteCtlProbesPerHop
> >>  |     +--traceRouteCtlPort
> >>  |     +--traceRouteCtlMaxTtl
> >>  |     +--traceRouteCtlDSField
> >>  |     +--traceRouteCtlSourceAddressType
> >>  |     +--traceRouteCtlSourceAddress
> >>  |     +--traceRouteCtlIfIndex
> >>  |     +--traceRouteCtlMiscOptions
> >>  |     +--traceRouteCtlMaxFailures
> >>  |     +--traceRouteCtlDontFragment
> >>  |     +--traceRouteCtlInitialTtl
> >>  |     +--traceRouteCtlDescr
> >>  |     +--traceRouteCtlMaxRows
> >>  |     +--traceRouteCtlCreateHopsEntries
> >>  |     +--traceRouteCtlType
> >>  |
> >>  +--traceRouteResultsTable
> >>  |  |
> >>  |  +--traceRouteResultsEntry
> >>  |     |
> >>  |     +--traceRouteResultsOperStatus
> >>  |     +--traceRouteResultsIpTgtAddrType
> >>  |     +--traceRouteResultsIpTgtAddr
> >>  |     +--traceRouteResultsTestAttempts
> >>  |     +--traceRouteResultsTestSuccesses
> >>  |     +--traceRouteResultsLastGoodPath
> >>  |     +--traceRouteResultsLastGoodPathDuration
> >>  |     +--traceRouteResultsLastRun
> >>  |
> >>  +--traceRouteProbeHistoryTable
> >>  |  |
> >>  |  +--traceRouteProbeHistoryEntry
> >>  |     |
> >>  |     +--traceRouteProbeHistoryIndex
> >>  |     +--traceRouteProbeHistoryHopIndex
> >>  |     +--traceRouteProbeHistoryProbeIndex
> >>  |     +--traceRouteProbeHistoryHAddrType
> >>  |     +--traceRouteProbeHistoryHAddr
> >>  |     +--traceRouteProbeHistoryResponse
> >>  |     +--traceRouteProbeHistoryStatus
> >>  |     +--traceRouteProbeHistorySentTime
> >>  |
> >>  +--traceRouteHopsTable
> >>     |
> >>     +--traceRouteHopsEntry
> >>        |
> >>        +--traceRouteHopsHopIndex
> >>        +--traceRouteHopsIpTgtAddressType
> >>        +--traceRouteHopsIpTgtAddress
> >>        +--traceRouteHopsASNumber
> >>        +--traceRouteHopsMinRtt
> >>        +--traceRouteHopsMaxRtt
> >>        +--traceRouteHopsAverageRtt
> >>        +--traceRouteHopsRttSumOfSquares
> >>        +--traceRouteHopsSentProbes
> >>        +--traceRouteHopsProbeResponses
> >>
> >> We believe that most of the fields are self-explaining, for the
unclear
> >> ones please refer to the disman draft:
> >>
http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-
> 06.t
> >> xt
> >>
> >> Looking forward to receive your comments.
> >>
> >> Best regards,
> >> Saverio Niccolini
> >>
> >> ============================================================
> >> Dr. Saverio Niccolini
> >> Research Staff Member
> >> Network Laboratories, NEC Europe Ltd.
> >> Kurfuerstenanlage 36, D-69115 Heidelberg
> >> Tel.     +49 (0)6221 90511-18
> >> Fax:     +49 (0)6221 90511-55
> >> e-mail:  [email-masked]
> >> ============================================================
> >>
> >>
> >> _______________________________________________
> >> ippm mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/ippm
> >
> > _______________________________________________
> > ippm mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ippm
> 
> 
> 

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 17 Jan 2005 17:36:48 +0100

Saverio,

>Does the IPPM charter want to define a MIB module for traceroute

Given the lack of interest in the previous MIB we discussed, and
the lack of expertise to review any proposal, I'd say: NO.

Henk

> > >> Looking forward to receive your comments.

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad.                 (Tom Verlaine)

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 Jan 2005 09:25:27 -0800

>the lack of expertise to review any proposal, I'd say: NO.

And since this seems to be an extension to a standard developed in the 
DISMAN WG, if this work belongs anywhere in the IETF, it's DISMAN. 

Andy

>[email-masked] https://www1.ietf.org/mailman/listinfo/ippm

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 Jan 2005 09:25:27 -0800

Andy

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 17 Jan 2005 17:36:48 +0100

Saverio,

Henk