Subject: [lmap] Fwd: Results of IETF-conflict review for draft-cisco-sla-protocol-03

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 24 Oct 2012 19:33:55 +0200

Hi everybody,

is the group aware of the 'Cisco Service Level Assurance Protocol' which also 
seems to provide some kind of measurement framework? See below.

Mirja

----------  Forwarded Message  ----------

Subject: Results of IETF-conflict review for draft-cisco-sla-protocol-03
Date: Friday 12 October 2012, 17:05:52
From: The IESG <[email-masked]>
To: "Nevil Brownlee" <[email-masked]>, 
[email-masked], [email-masked]
CC: [email-masked], The IESG <[email-masked]>, [email-masked]

The IESG has completed a review of draft-cisco-sla-protocol-03 consistent
with RFC5742.

The IESG has no problem with the publication of 'Cisco Service Level
Assurance Protocol' <draft-cisco-sla-protocol-03.txt> as an Informational
RFC.

The IESG has concluded that this work is related to IETF work done in WG IP
Performance Metrics (IPPM), but this relationship does not prevent
publishing

The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-cisco-sla-protocol/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-cisco-sla-protocol/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

-------------------------------------------------------

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: Al Morton <[email-masked]>
Date: Wed, 24 Oct 2012 13:56:41 -0400

>seems to provide some kind of measurement framework? See below.

Folks who crossed-over from IPPM-list certainly are,
it was proposed in IPPM as Informational, but ended-up
in RFC Editor's queue.

You're right that it provides a similar capability to TWAMP,
active measurements with a low-complexity responder.

Al

---

From: Brian Trammell <[email-masked]>
Date: Thu, 25 Oct 2012 16:54:49 +0200

hi Al, Mirja, all,

I missed CSLAP[*] when it came briefly through IPPM, but having had a look at it since then, I'd presume that it would be another potential active measurement technology to think about controlling through LMAP, like OWAMP and TWAMP.

In any case, what's defined there just provide the measurement client and server and the protocol between them, in LMAP draft terminology. Missing from the specification are the control of the CSLAP sender by the measurement controller, and the reporting of results from the CSLAP sender (the measurement client to measurement controller). 

For the control protocol I suppose the configuration parameters would have some mapping to the fields of the defined UDP measurement control message, so if supporting CSLAP turns out to be an LMAP requirement then the control message specification would be a starting point to defining them. 

However, for the result reporting protocol, the specification is completely silent on the subject of both the calculated metrics and the format of reported results, so without more information it would be hard to say where to start.

Best regards,

Brian

* I have no idea whether this is an accepted acronym for this protocol, but calling it just SLA would be a trivial terminology collision, so no.

On Oct 24, 2012, at 7:56 PM, Al Morton <[email-masked]> wrote:

> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: Al Morton <[email-masked]>
Date: Thu, 25 Oct 2012 14:18:49 -0400

Hi Brian,

You gave a good account of the current protocol*
capabilities, especially where you identify the missing
pieces.  These are partly covered by the list of items I
suggested IPPM might work next, to address the LMAP initiative:
http://www.ietf.org/mail-archive/web/lmap/current/msg00055.html
Marcelo noted the need for a new registry explicitly on that list,
and there's also a need to develop details on measurement methodology
beyond the parameter settings for metrics, now that I've thought
about it some more.

There is real/new work needed on the measurement front, to address
passive as well as active techniques, wireless as well as wired, and what
we're now calling "reactive networks" (and attempting to define
in a useful way in IPPM right now).

regards,
Al

* (I've referred to the protocol as IPSLAv2, but authors should name it)

At 10:54 AM 10/25/2012, Brian Trammell wrote:
>hi Al, Mirja, all,
>
>I missed CSLAP[*] when it came briefly through IPPM, but having had 
>a look at it since then, I'd presume that it would be another 
>potential active measurement technology to think about controlling 
>through LMAP, like OWAMP and TWAMP.
>
>In any case, what's defined there just provide the measurement 
>client and server and the protocol between them, in LMAP draft 
>terminology. Missing from the specification are the control of the 
>CSLAP sender by the measurement controller, and the reporting of 
>results from the CSLAP sender (the measurement client to measurement 
>controller).
>
>For the control protocol I suppose the configuration parameters 
>would have some mapping to the fields of the defined UDP measurement 
>control message, so if supporting CSLAP turns out to be an LMAP 
>requirement then the control message specification would be a 
>starting point to defining them.
>
>However, for the result reporting protocol, the specification is 
>completely silent on the subject of both the calculated metrics and 
>the format of reported results, so without more information it would 
>be hard to say where to start.
>
>Best regards,
>
>Brian
>
>* I have no idea whether this is an accepted acronym for this 
>protocol, but calling it just SLA would be a trivial terminology 
>collision, so no.
>