Re: [ippm] OWAMP draft - draft*ietf-ippm-owdp-14.txt

"sharee mcnab" <sharee.mcnab@alliedtelesyn.co.nz> writes:

> At ATR, we've been looking into OWAMP (as well as TWAMP) and had the
> following questions.  Perhaps the authors or others could answer
> these questions?

I can't speak about TWAMP, of which I only have limited knowledge.
It seems that your questions apply to OWAMP, though.

> A.  Page 5.  Section 2, paragraph 2.  States OWAMP-control messages
> use a "Well-known port number" (ie 0-1023).  Is it planned to
> designate & register a defined OWAMP port number for OWAMP-control
> messages?

IANA will only designate the port number after the IESG approves the
draft.  The IESG is currently still in the process of considering it.

> B.  Page 14. Section 3.5 Generally Server-> Sender/Receiver
> interactions for setting up tests and retrieving test data are
> undefined for the more general architecture where the various
> modules are on separate hosts.  This obviously impacts
> interoperability in the more general architecture.  Is it be worth
> extending the standard to include these interactions or
> alternatively defining the standard to limited architectures, maybe
> with an extension for the more general case?

The undefined interactions are meant to support OWAMP-Control access
to devices that speak some other control protocol (perhaps SNMP or
some proprietary protocol such as command names over SSH or whatever),
but do not speak OWAMP-Control, yet are capable of being taught to
speak the simpler OWAMP-Test.  If you have no such devices to support,
there's no need to separate the roles---simply talk OWAMP-Control
directly to the device you want to talk OWAMP-Test to.

> C.  Section 3.5, second to last paragraph.  Setting the Conf-Sender
> and Conf-Receiver seems inconsequential when it is the
> Control-Client speaking to the Server.  Surely this is only of
> importance when the Server is speaking to the Sender/Receiver.

The two fields Conf-Sender and Conf-Receiver being set mean that the
client is asking the server to configure the sender and the receiver,
respectively.

> Also, what is to stop the sender & receiver checking the sender/
> receiver address field to determine if they are the receiver or
> sender?

They should indeed do so to understand if they need to configure
themselves or some third host.  Many OWAMP servers will only be
administratively able to configure themselves.  Others might have some
hosts that they might also be able to configure.

> D.  The OWAMP draft has a strong emphasis on security and
> encryption.  It is not clear to me though that there are enough
> implementation details in the draft to enable interoperability with
> regards to security keys?  Is this the intention or is it planned to
> have limited interoperability in authenticated and encrypted modes?

The protocol's use of cryptography is fully specified and different
implementations should interoperate in all modes.

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

Just my 0.086g of Ag.

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm