Subject: [lmap] FW: [ippm] Fwd: draft-mornulo-ippm-registry-columns-00.txt

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 1 Oct 2013 10:05:56 -0400

Hi all,

Folks who are interested in LMAP know how important it will be to 
establish a registry for the metrics we intend to control and report about.

Please take a look at the various registry drafts, especially the latest
proposals below, and send your comments to the IPPM wg (where this work
will be undertaken eventually, according to their charter). 

It is fairly easy to imagine using a registry and evaluate its construction 
when you have application already in mind, and LMAP fills that bill.

regards,
Al

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> marcelo bagnulo braun
> Sent: Monday, September 30, 2013 12:48 PM
> To: [email-masked]
> Subject: [ippm] Fwd: New Version Notification for draft-mornulo-ippm-
> registry-columns-00.txt
> 
> Hi,
> 
> After further discussion with several folks, we have produced yet two
> other drafts, namely draft-mornulo-ippm-registry-columns and
> draft-mornulo-ippm-registry.
> 
> - one draft (draft-mornulo-ippm-registry-00) uses the RFC6390 template
> in a strict manner.
> 
> - the other draft (draft-mornulo-ippm-registry-columns-00) adapts the
> RFC6390 into something that may be more appropriate for a registry
> template (as opposed to a metric template)
> 
> In particular some concerns that were raised during the discussions were:
> 
>   - Measurement Description is really the Measurement Definition
>   - Measurement Points are really Run-time parameters (column not needed)
>   - it's fine to have guidance on measurement timing and clock sync in
> an RFC
>     (but not needed in the registry), so Measurement Timing column not
> needed.
> 
> 
> I personally fine with either of them and it think it is much more
> important to agree and move forward than the differences between the two
> drafts.
> 
> Comments?
> 
> Regards, marcelo
> 
> 
> -------- Mensaje original --------
> Asunto: 	New Version Notification for
> draft-mornulo-ippm-registry-columns-00.txt
> Fecha: 	Mon, 30 Sep 2013 09:45:38 -0700
> De: 	[email-masked]
> Para: 	Al Morton <[email-masked]>, Philip Eardley
> <[email-masked]>, Marcelo Bagnulo <[email-masked]>, Al C.
> Morton <[email-masked]>
> 
> 
> 
> A new version of I-D, draft-mornulo-ippm-registry-columns-00.txt
> has been successfully submitted by Marcelo Bagnulo and posted to the
> IETF repository.
> 
> Filename:	 draft-mornulo-ippm-registry-columns
> Revision:	 00
> Title:		 A(nother) Registry for Performance Metrics
> Creation date:	 2013-09-30
> Group:		 Individual Submission
> Number of pages: 13
> URL:             http://www.ietf.org/internet-drafts/draft-mornulo-ippm-
> registry-columns-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-mornulo-ippm-
> registry-columns
> Htmlized:        http://tools.ietf.org/html/draft-mornulo-ippm-registry-
> columns-00
> 
> 
> Abstract:
>     This memo investigates a scheme to organize registry entries,
>     especially those defined in RFCs prepared in the IP Performance
>     Metrics (IPPM) Working Group of the IETF, and applicable to all IETF
>     metrics.  Three aspects make IPPM metric registration difficult: (1)
>     Use of the Type-P notion to allow users to specify their own packet
>     types. (2) Use of flexible input variables, called Parameters in IPPM
>     definitions, some which determine the quantity measured and others
>     which should not be specified until execution of the measurement. (3)
>     Allowing flexibility in choice of statistics to summarize the results
>     on a stream of measurement packets.  Specifically, this memo proposes
>     a way to organize registry entries into columns that are well-
>     defined, permiting consistent development of entries over time.
>     Also, this fosters development of registry entries based on existing
>     reference RFCs for performance metrics, and requires expert review
>     for every entry before IANA action.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Mon, 7 Oct 2013 13:46:47 +0000

Marcelo, Al,

    Knowing the first question out of any Op's guys mouth when you ask him to do a test ... I came up with  this..

  I suggest that the "test name" label be expanded so that it may accommodate at least 3 levels of hierarchy in describing what type of test it is.
I'm meaning a highest order test descriptor that would allow universal understanding of the type of test, and more importantly its impact.
The attributes of the test would be placed behind this field...

Example - Test Name composite view of the hierarchy I'm suggesting

The Fields should be industry / customer recognizable so they correlate their results 

1) Test Class (purpose)
	Capacity
	Site specific testing (Webpage load)
	Performance ( 
	Monitoring (SLA type / OAM type)
	Availability
	
2) Assumed service life cycle (turn-up, live, out-of-service)
2) Test type (Protocol)
3) Code origin (test engine source in case of duplicates types that perform differently)
4) Impact (how much capacity does it eat) - low, med, ..., all
5) Network context  (Segmented or end to end) 
6) One way / Two way 

Example - 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C (AL)
Sent: Tuesday, October 01, 2013 9:06 AM
To: [email-masked]
Subject: [lmap] FW: [ippm] Fwd: draft-mornulo-ippm-registry-columns-00.txt

Hi all,

Folks who are interested in LMAP know how important it will be to establish a registry for the metrics we intend to control and report about.

Please take a look at the various registry drafts, especially the latest proposals below, and send your comments to the IPPM wg (where this work will be undertaken eventually, according to their charter). 

It is fairly easy to imagine using a registry and evaluate its construction when you have application already in mind, and LMAP fills that bill.

regards,
Al

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of marcelo bagnulo braun
> important to agree and move forward than the differences between the 
> two drafts.
> 
> Comments?
> 
> Regards, marcelo
> 
> 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> 
_______________________________________________
lmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lmap

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Mon, 7 Oct 2013 13:54:24 +0000

Oops -- pulled the trigger too fast..(clicked send by mistake... )

BTW-- I just don't see this in the current stream of fields, I don't have a preference where they go but I think they are important.

Best regards,
Mike 

Here's a fuller set. 

1) Test Class (purpose)
	Capacity (throughput)
	Site specific testing (Webpage load)
	Performance (stress testing)
	Monitoring (SLA type / OAM type)
	Availability (CC oriented - may include multipath)
	
2) Assumed service life cycle (turn-up, live, out-of-service)
	Forced OOS (out of service) required - speaks to the urgency of the test
	Live yet Polite test (may stop if customer traffic impacts results)
	Live low impact
	Passive no impact

3) Test type (Protocol)
	TCP
	UDP
	....

4) Code origin (test engine source in case of duplicates types that perform differently)
	Special test engines should be called out so results match if they exist
	(Vendor ID / Engine Code) type field would work here

5) Impact (how much capacity does it eat) - low, med, ..., all
	For OAM tests = X megs
	CPU clicks required for code (recommend reserving / helps CAC to be understood)
	Memory required (same same)

6) Network context  (Segmented or end to end) 
	End to end is = QoE
	Segment tests generally mean two tests run at once, one end-to-end, the other from one end to a segment.
	i.e. - segmented means you need two test results to read the tea leaves.

7) One way / Two way 
	No-symmetrical comes into play here..

Example - 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C (AL)
Sent: Tuesday, October 01, 2013 9:06 AM
To: [email-masked]
Subject: [lmap] FW: [ippm] Fwd: draft-mornulo-ippm-registry-columns-00.txt

Hi all,

regards,
Al