Subject: Re: [ippm] draft-cisco-sla-protocol

From: <[email-masked]>
Date: Wed, 4 Apr 2012 09:25:47 +0200

Henk, Matt,

I support work on draft-cisco-sla-protocol by the IPPM WG. A good next step would be to discuss how the draft can make progress:

- work on this draft within the IPPM WG (or another one)?
- maintain it as Informational (in which case it should be published after a brief review)?
- if published as Informational - do we think it preceeds TWAMP or do we want or need a new Standards Track problem statement and solution draft?

Regards,

Ruediger

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 12 Apr 2012 13:20:02 +0200

Ruediger, others,

> I support work on draft-cisco-sla-protocol by the IPPM WG. A good next step would be to discuss how the draft can make progress:

Noted.  The logical next step (to me) seems that people interested speak
up and start reviewing/commenting on the document.  If/when it becomes
clear that there is sufficient interest in the WG to work on this
_and_ the WG is interested in finding a generic solution to the problem
(that is, one that can be implemented by others as well), then we can
pick it up as a WG item.  If this is not the case, then I'd suggest that
the authors take all comments into account and ask for the document to be
published as an individual submission RFC.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
                                          http://www.uijterwaal.nl
                                          Phone: +31.6.55861746
------------------------------------------------------------------------------

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project)

---

From: Al Morton <[email-masked]>
Date: Thu, 12 Apr 2012 08:20:35 -0400

At 07:20 AM 4/12/2012, Henk Uijterwaal wrote:
>Ruediger, others,
>
> > I support work on draft-cisco-sla-protocol by the IPPM WG. A good 
> next step would be to discuss how the draft can make progress:
>
>pick it up as a WG item.  ...

Hi Henk,

To save you some cycles, I've compiled all the other
messages to ippm-list with comments on draft-cisco-sla-protocol.
Messages have been appearing sporadically since the beginning
of the year, so the trend may not have been evident.

Here's the beginning of the thread, four responses
offering to review, and comments already on the
draft:

Murtaza's invitation to review:
http://www.ietf.org/mail-archive/web/ippm/current/msg02754.html

Al's reply and comments:
http://www.ietf.org/mail-archive/web/ippm/current/msg02758.html

Greg Dowd's reply to Al message & comment:
http://www.ietf.org/mail-archive/web/ippm/current/msg02761.html

Tiziano Ionta's offer to work on the draft:
http://www.ietf.org/mail-archive/web/ippm/current/msg02765.html

Len Ciavattone's offer to work on the draft:
http://www.ietf.org/mail-archive/web/ippm/current/msg02791.html

Also, Yaakov Stein offered to work on the draft at the IPPM
session at IETF-83.

hope this helps,
Al

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 16 Apr 2012 11:48:09 +0200

Hi Al, others,

>> > I support work on draft-cisco-sla-protocol by the IPPM WG. A good next step
>> would be to discuss how the draft can make progress:
>>

Yes, I saw those mails and I agree that there is a trend.

So, let me rephrase ;-)

It appears that there is interest in this work (besides the authors
from Al, Greg, Tiziano, Len, Yaakov and Ruediger).  The question to
be answered is, I think, whether the WG is interested in finding
a generic solution to the problem discussed in this draft (that is,
something that can be implemented by anybody).  Speak up in
support or disagreement.

Henk

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 17 Apr 2012 12:23:53 -0400

> something that can be implemented by anybody).  Speak up in

As responsible AD, I share some concerns similar to what
Steve raised.

I think it definitely makes sense to document what has
been done to-date with Cisco's SLA protocol as an
Informational RFC that describes the protocol and hopefully
describes it in the context of the IPPM OWAMP/TWAMP as to
how it differs.  I don't think that has to be done by the
IPPM WG.  It should be done either on the ISE-track or as
AD-sponsored, in my opinion.

If there's strong motivation for IPPM to develop another
protocol, I have not understood it yet, and would like to
understand why we would initiate work on a new protocol
rather than patching OWAMP/TWAMP.

-- 
Wes Eddy
MTI Systems

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 18 Apr 2012 10:31:10 +0200

Wes,

> AD-sponsored, in my opinion.

The ISE asked if IPPM could pick this up, as he preferred a review by
IPPM rather than do this himself.  When the authors announced the existence
of this draft on the IPPM list, a handful of people spoke up and said they
were interested in the topic.

Henk

---

From: Al Morton <[email-masked]>
Date: Wed, 18 Apr 2012 09:18:08 -0400

Wes,
appending more to Henk's response, below.

> >rather than patching OWAMP/TWAMP.

I will give this a shot, as briefly as possible.

TWAMP looks a lot like OWAMP because, when a protocol for
a two-way test with low-complexity responder architecture
was proposed, OWAMP-folks wanted the design to "just use OWAMP
in two directions, you're done." The compromise was to extend
OWAMP for two-directional use, and therefore pull more
implementors closer to a full OWAMP-compliant system over time.
Years on, we found that we had to separate the protocols because
TWAMP-only and OWAMP-only hosts could not negotiate a common mode
of operation.

Taking TWAMP through IESG also brought a surprise. The Security ADs
had agreed not to block OWAMP if we never used the same (non-standard,
in their eyes) security features again, and here we were with TWAMP
doing exactly the same thing.  Sam Hartman ultimately Abstained, and
Pasi Eronen and I worked out a compromise one night in Dublin where
I would investigate using TLS on TWAMP-Control and try to get IPPM
interested to add it. I presented a very do-able plan at the next
IETF face2face and on ippm-list, but no one was interested.

Also, many of the enhancements/new TWAMP features have been fixes
for the sort of thing testers expect in a protocol (symmetrical packet
size, for one).  And we have the baggage of TWAMP specs written to
reference OWAMP as much as possible, making reading and understanding
TWAMP about as hard as possible. The hoped-for benefit of getting more
implementors to consider OWAMP has never happened, AFAICT, and the
low-complexity responder architecture actually precludes it
(OWAMP is for test hosts that are peers in processing power, sync, etc.).

In summary, we have a two-way measurement protocol spec that could really
use a lot of work to resolve issues of clarity, existing patches, plus
unusual security features, and if Henk's poll earlier this year is accurate,
no one willing to do the work. And it is a lot of work.

So when I saw a simple and independent spec for the two-way testing
protocol function that resolves many of TWAMP's shortcomings
and fits nicely with the low-complexity responder architecture,
I was very interested. Why spend my time re-writing TWAMP, when
a successful outcome would look a lot like draft-cisco-sla-protocol?

If draft-cisco-sla-protocol can't be done as an IPPM WG doc,
then I'd like to see it go forward as AD-sponsored and
reviewed frequently on the IPPM list.

regards,
Al

---

From: Steve Baillargeon <[email-masked]>
Date: Wed, 18 Apr 2012 10:03:06 -0400

Hi

>>In summary, we have a two-way measurement protocol spec that could really use a lot of work to resolve issues of clarity, existing patches, plus unusual security features, and if Henk's poll earlier this year is accurate, no one willing to do the work. And it is a lot of work.

I agree that TWAMP is far from perfect. I also agree the contribution level at the IPPM is fairly low (except for Al who drives most of the new contributions) but I do not necessarily agree the poll represent an industry consensus. As far as I know, many vendors have already implemented TWAMP and I suspect most of them are expecting the WG to improve it over time. I know it requires work but I assume it will also be work to improve the IPR-protected IP SLA protocol over time. On the other hand, I suspect these new IP SLA related contributions will mostly come from Cisco and Al.

>>So when I saw a simple and independent spec for the two-way testing protocol function that resolves many of TWAMP's shortcomings and fits nicely with the low-complexity responder architecture, I was very interested. Why spend my time re-writing TWAMP, when a successful outcome would look a lot like draft-cisco-sla-protocol? 

It sounds like Al has already decided to pull the plug on OWAMP and TWAMP. Is it the consensus of the WG?
Do we need a draft comparing the pros and cons of Cisco IP SLA vs TWAMP in order to make a better decision?

-Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Al Morton
Sent: April-18-12 9:18 AM
To: Henk Uijterwaal; Wesley Eddy
Cc: [email-masked]; [email-masked]
Subject: Re: [ippm] draft-cisco-sla-protocol

Wes,

At 04:31 AM 4/18/2012, Henk Uijterwaal wrote:
>Wes,
>
> > I think it definitely makes sense to document what has been done 
> > to-date with Cisco's SLA protocol as an Informational RFC that 
> > describes the protocol and hopefully describes it in the context of 
> > the IPPM OWAMP/TWAMP as to how it differs.  I don't think that has 
> > to be done by the IPPM WG.  It should be done either on the 
> > ISE-track or as AD-sponsored, in my opinion.
>
>IPPM rather than do this himself.  When the authors announced the 
>existence of this draft on the IPPM list, a handful of people spoke up 
>and said they were interested in the topic.

At 12:23 PM 4/17/2012, Wesley Eddy wrote:
> >If there's strong motivation for IPPM to develop another protocol, I 
> >have not understood it yet, and would like to understand why we would 
> >initiate work on a new protocol rather than patching OWAMP/TWAMP.

TWAMP looks a lot like OWAMP because, when a protocol for a two-way test with low-complexity responder architecture was proposed, OWAMP-folks wanted the design to "just use OWAMP in two directions, you're done." The compromise was to extend OWAMP for two-directional use, and therefore pull more implementors closer to a full OWAMP-compliant system over time.
Years on, we found that we had to separate the protocols because TWAMP-only and OWAMP-only hosts could not negotiate a common mode of operation.

Taking TWAMP through IESG also brought a surprise. The Security ADs had agreed not to block OWAMP if we never used the same (non-standard, in their eyes) security features again, and here we were with TWAMP doing exactly the same thing.  Sam Hartman ultimately Abstained, and Pasi Eronen and I worked out a compromise one night in Dublin where I would investigate using TLS on TWAMP-Control and try to get IPPM interested to add it. I presented a very do-able plan at the next IETF face2face and on ippm-list, but no one was interested.

Also, many of the enhancements/new TWAMP features have been fixes for the sort of thing testers expect in a protocol (symmetrical packet size, for one).  And we have the baggage of TWAMP specs written to reference OWAMP as much as possible, making reading and understanding TWAMP about as hard as possible. The hoped-for benefit of getting more implementors to consider OWAMP has never happened, AFAICT, and the low-complexity responder architecture actually precludes it (OWAMP is for test hosts that are peers in processing power, sync, etc.).

In summary, we have a two-way measurement protocol spec that could really use a lot of work to resolve issues of clarity, existing patches, plus unusual security features, and if Henk's poll earlier this year is accurate, no one willing to do the work. And it is a lot of work.

So when I saw a simple and independent spec for the two-way testing protocol function that resolves many of TWAMP's shortcomings and fits nicely with the low-complexity responder architecture, I was very interested. Why spend my time re-writing TWAMP, when a successful outcome would look a lot like draft-cisco-sla-protocol?

If draft-cisco-sla-protocol can't be done as an IPPM WG doc, then I'd like to see it go forward as AD-sponsored and reviewed frequently on the IPPM list.

regards,
Al

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

---

From: Al Morton <[email-masked]>
Date: Wed, 18 Apr 2012 10:47:52 -0400

At 10:03 AM 4/18/2012, Steve Baillargeon wrote:

>Al wrote:
> >So when I saw a simple and independent spec for the two-way 
> testing protocol >function that resolves many of TWAMP's 
> shortcomings and fits nicely with the >low-complexity responder 
> architecture, I was very interested. Why spend my >time re-writing 
> TWAMP, when a successful outcome would look a lot like 
> draft->cisco-sla-protocol?
>

Your over-reaction is unnecessary, and don't put words in my mouth.
The intended status of draft-cisco-sla-protocol is Informational, so
it would not Update or Obsolete any of IPPM's Standards Track protocols.

Al

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 19 Apr 2012 08:40:44 +0200

On 18/04/2012 16:03, Steve Baillargeon wrote:
>>> unusual security features, and if Henk's poll earlier this year is
>>> accurate, no one willing to do the work. And it is a lot of work.
> 
> I agree that TWAMP is far from perfect. I also agree the contribution level
> at the IPPM is fairly low (except for Al who drives most of the new
> contributions) but I do not necessarily agree the poll represent an industry
> consensus.

TWAMP does what it is supposed to be doing, perhaps it isn't perfect, but it
is good enough.  The way the spec is written down, is not.  TWAMP started
by taking another protocol (OWAMP), the first document just listed what has
to be changed and there have been many modifications since then.  The result
is that the current TWAMP spec is scattered of a number of documents and
not everything is written down clearly.  People do feel the need for a single
document that describes TWAMP from top to bottom and can be used by somebody
who wants to implement it.

Creating this document is mainly a matter of editing, all the elements are
there, "all" that the editor has to do, is take them, put them into a logical
order and make sure that the text is consistent.  "all" is an understatement,
as it is a lot of work.  Currently there doesn't seem to be anybody who
has the time, money and knowledge available to take on this job.  That was
the outcome of the poll: we need it, but we don't have time to do it now.

> It sounds like Al has already decided to pull the plug on OWAMP and TWAMP. Is
> it the consensus of the WG? Do we need a draft comparing the pros and cons of
> Cisco IP SLA vs TWAMP in order to make a better decision?

I don't think the working group has reached a consensus on anything yet, the
only thing that happened is that an individual submission draft was announced
to the group and people have said that this is interesting and should be
discussed.

Henk

---

From: Jérôme Benoit <[email-masked]>
Date: Mon, 23 Apr 2012 20:56:13 +0200

On Wed, 18 Apr 2012 10:03:06 -0400
Steve Baillargeon <[email-masked]> wrote:

> Hi
> 
> >>In summary, we have a two-way measurement protocol spec that could
> >>really use a lot of work to resolve issues of clarity, existing
> >>patches, plus unusual security features, and if Henk's poll earlier
> >>this year is accurate, no one willing to do the work. And it is a
> >>lot of work.
> 
> I agree that TWAMP is far from perfect. I also agree the contribution
> level at the IPPM is fairly low (except for Al who drives most of the
> new contributions) but I do not necessarily agree the poll represent
> an industry consensus. As far as I know, many vendors have already
> implemented TWAMP and I suspect most of them are expecting the WG to
> improve it over time. I know it requires work but I assume it will
> also be work to improve the IPR-protected IP SLA protocol over time.
> On the other hand, I suspect these new IP SLA related contributions
> will mostly come from Cisco and Al.

The measurement control side of OWAMP, TWAMP or cisco-sla protocol are
not NAT friendly and mostly because of the datagram-based protocol, it
make them hard (or impossible) to extent. There's also the high
traffic for large-scale measurement, just to control the measurement.
That's why I still think that a datagram-based approach for measurement
control is just a real bad idea. 

Regards,

-- 
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D

---

From: "Jeff W. Boote" <[email-masked]>
Date: Mon, 23 Apr 2012 13:50:40 -0600

> control is just a real bad idea. 

The 'control side' of OWAMP is TCP:861 and not datagram based. The 'measurement' is datagram based, because it is measuring the speed of datagrams.

Jeff

---

From: Jérôme Benoit <[email-masked]>
Date: Mon, 23 Apr 2012 23:27:19 +0200

> The 'control side' of OWAMP is TCP:861 and not datagram based. The 'measurement' is datagram based, because it is measuring the speed of datagrams.

I suppose you've misread the RFC :)
Even the "Hello" response from the control server is a datagram.  
There's no single ABNF rules in these RFCs.

I'm just saying that none of these RFCs met my needs to run large scale
measurement campaign from the network edge so we've chosen a RESTful API
and JSON syntax to express a way to control the measurement tools' set of functionnalities
and capabilities.

Cheers.

---

From: Al Morton <[email-masked]>
Date: Mon, 23 Apr 2012 17:48:31 -0400

At 05:27 PM 4/23/2012, Jérôme Benoit wrote:
>...I'm just saying that none of these RFCs met my needs to run large scale
>and JSON syntax to express a way to control the 
>measurement tools' set of functionnalities and capabilities.

Interesting, care to share some specs with ippm?
Al

---

From: Jérôme Benoit <[email-masked]>
Date: Tue, 24 Apr 2012 00:49:27 +0200

Le Mon, Apr 23, 2012 at 05:48:31PM -0400, Al Morton a écrit:
> >and JSON syntax to express a way to control the measurement tools'
> >set of functionnalities and capabilities.
> 

Sure, we're a FOSS project for the best and the worse.

The best : the measurement agent code is readable and under heavy
developement, we still lack a stable API to manipulate packets in a
asynchronous way and a syntax to describe some common packets train.
The worse : the lack of documentation on the active probe already
doable.

An example of JSON file to run an active measurement: 

{"probe":
// The probe definition part 
	// The probe module to load
        {"name":["delay","round_trip","icmp","bin"]
	// The definition that will define how to send the probe : the
	// time part
        ,"send":
		// The time sequence definition : repeat 3 times
                {"seq":
                        {"repeat":
                                {"count":3
				// repeat periodically each period (that
				// can be poisson, gamma, uniform time
				// sequence, some time sequence can be
				// composed, some not
                                ,"seq":{"periodic":{"period":3.0}}
                                }
                        }
                }
	// The definition that define how to receive the send probe : the time
	// part
        ,"recv":
                {"seq":
                        {"repeat":
                                {"count":2
                                ,"seq":{"periodic":{"period":0.50}}
                                }
                        }
                }
	// How to run the probe 
        ,"parallel":
                [
                        {"mark":null
			// The probe definition keywork that contain
			// probe specific syntax, here landmark name and
			// ICMP type 8 packet size
                        ,"data":
                                {"host":"free.fr"
                                ,"size":16
                                }
                        }
			,{"mark":null
                        ,"data":
                                {"host":"google.fr"
                                ,"size":16
                                }
                        }
                ]
        }
// Where to write the result, might be file, RESTful server URI, stdout
,"sample":
        {"file":"-"
        }
}

It's just an example to show the basic ideas for active probing.
Security mechanism are lacking and the syntax might be refined but in
versionned fashion. 
The very few documentation is in French (we're a French FOSS project).
We plan te write a full documentation.

Time to sleep here.