Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split?

From: "Cucchiara, Joan" <[email-masked]>
Date: Thu, 1 Feb 2001 11:56:00 -0500

> -----Original Message-----
> From: Cole, Robert G (Bob), ALSVC [mailto:[email-masked]]
> Sent: Thursday, February 01, 2001 10:04 AM
> To: [email-masked]; stanislav shalunov
> Cc: [email-masked]'
> Subject: RE: [ippm] Re: draft-ietf-ippm-owdp: should it be split?
> 
> 
> Joan,
> 
> I am not suggesting that OWDP-test will be developed and deployed with
> no means to set up the parameters for the test-plane.
> 
> 
> > > Therefore, some vendors may not implement OWDP-Control at all.
> > 
> > I disagree here.  The control-plane (at least as far as the 
> > draft-ietf-ippm-owdp-01.txt is concerned) sets up parameters for the
> > test-plane. 
> > 
> Rather, there will be other means to set up the parameters, 
> e.g., thru the
> draft-kalbfleisch-sspmmib-00.txt  ( sorry but I incorretly wrote the
> reference to this
> last time).  Clearly, we must ensure that the other means support
> the correct and sufficient set of parameters necessary to run 
> OWDP-test.

Hi Bob,

Thank you for the clarification, I understand now what you mean by
vendors may not support the OWDP control-plane at all and may opt for
some other control mechanism.

I don't really see any problem with having multiple methods 
of control to set up the test-plane.  So basically, I think we agree.

However, for an IETF standard, I think that one method of
setting up the test needs to be the adopted for the standard. 
If I'm Vendor A and your Vendor B and I want to act as the
sender and communicate to you are a receiver, without a
definitive method of control, how does Vendor A communicate
with Vendor B?  

Assuming Vendor B supports all methods of control seems overly
complex.  Assuming that Vendor A attempts different methods of
control until Vendor B responds to one of them, seems very
inefficient.  I am concerned that this approach is going to
drag out the adoption of any control method and the hope
of ever getting a one-way delay mechanism as "commonplace"
as PING would be NIL.

An analogy would be the current diffserv PIB
in RAP and the diffserv MIB being developed in SNMPCONF,
one could argue that PIBs/COPS+ and MIBs/SNMPCONF for this
specific instance of diffserv configuration are two different
mechanism which produce the same result (meaning the
PIB == MIB in this scenario).  Even though the 
mechanisms are very different the same data would be
manipulated and the same end results occur and this
was intentionally the goal of the SNMPCONF wg when they
undertook designing a Diffserv MIB.

I would even go so far as to say, different control mechanisms
may imply different protocols.  To extend the above anaology, one could
probably use COPS+ and/or SNMPCONF to also set up the
test-plane.  I wouldn't necessarily mandate that every device
that wants to support one-way delay test-plane needs to 
also support SNMPCONF and COPS+ in addition to the TCP mechanism
proposed in draft-ietf-ippm-owdp-01.txt.  I certainly don't view
these as the same protocol.  

In summary, I believe that one of the major motivations for vendors 
to implement an IETF standard is interoperability
with other vendors.  Starting with one control method and one
test-plane would achieve interoperability faster and more directly.

   Thanks, Joan

> 
> Thanks,
> Bob 
> _______________________________________________
> ippm mailing list
> [email-masked]
> http://mailhost.advanced.org/mailman/listinfo/ippm
> 
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Mon, 5 Feb 2001 14:18:56 +0100 (CET)

Joan,

> In summary, I believe that one of the major motivations for vendors to
> implement an IETF standard is interoperability with other vendors.
> Starting with one control method and one test-plane would achieve
> interoperability faster and more directly.

But in that case, I think we should take a step back and discuss
requirements for the control protocol first, then design it from there.

IIRC, the OWDP-C in the draft is (close to) the mechanism chosen by one of
the implementations and this is now being promoted to a standard.
However, there are other OWD implementations and they have come up with
totally different OWDP-C's based on slightly different requirements and
implementation choices.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: [email-masked]
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.5354414
1016 AB Amsterdam                    Fax: +31.20.5354445
The Netherlands                   Mobile: +31.6.55861746
------------------------------------------------------------------------------

As long as you don't tell your friends how I played the hand,
then I won't tell my friends how you defended it.                 (Anonymous)

---

From: stanislav shalunov <[email-masked]>
Date: 05 Feb 2001 13:02:02 -0500

"Henk Uijterwaal (RIPE-NCC)" <[email-masked]> writes:

> IIRC, the OWDP-C in the draft is (close to) the mechanism chosen by
> one of the implementations and this is now being promoted to a
> standard.

Which implementation do you mean?  Not Surveyor's as far as I know
Surveyor's implementation.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Sex is the mathematics urge sublimated.                 -- M. C. Reed.
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Tue, 6 Feb 2001 11:08:23 +0100 (CET)

> Surveyor's implementation.

No?  I know Sunil or Matt described Surveyor's setup mechanism somewhere,
a long time ago and OWDP-C looked remarkably like what I remember from
that.

My memory must be worse that I thought ;-)

Henk

---

From: stanislav shalunov <[email-masked]>
Date: 06 Feb 2001 15:08:34 -0500

"Henk Uijterwaal (RIPE-NCC)" <[email-masked]> writes:

> No?  I know Sunil or Matt described Surveyor's setup mechanism
> somewhere, a long time ago and OWDP-C looked remarkably like what I
> remember from that.

Surveyor depends on issuing shell commands through SSH, depends on
system PRNG being the same on all hosts, has no
authentication/encryption aside from what is passed through SSH, does
data collection out-of-band, allows no open mode, etc., etc., etc.

If similarities exist, they are coincidental--if you're doing the same
simple thing it's possible the method will be somewhat similar to one
of the existing models.

"Computer Science is no more about computers than astronomy is about
telescopes."					-- E. W. Dijkstra
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Tue, 6 Feb 2001 21:14:26 +0100 (CET)

> simple thing it's possible the method will be somewhat similar to one

OK, you win! Ignore my comment.

Henk