Subject: [ippm] Barry Leiba's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 04 Sep 2019 09:53:12 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-ippm-stamp-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm sure this will be easy to either explain to me or re-phrase:

Sections 4 and 6 both say something like "MUST be agreed by all users of the
network".  What does that really mean?  How is it remotely possible to get
agreement from all users of your network?  How is it remotely possible that
they could understand what you're asking them to agree to?

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 10 Sep 2019 14:00:57 -0700

Hi Barry,
thank you for your pointed question. Please find my explanation and the
proposed updated below under the GIM>> tag.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/

GIM>> Yes, looking at the bigger picture, at the Internet rather than only
at the domain where the test will be performed makes such condition
unattainable. Would s/network/network domain where the test is planned/  so
that it reads as:

... MUST be agreed by all users on the network domain where the test is
planned ...

make it clearer and the number of parties involved reasonable, practical?
As for what the could be the question users will be asked, I think that it
should verify whether the application that has the port number assigned is
active as the same number will be used as the destination port number in
the STAMP test.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 Sep 2019 20:15:07 -0400

Hi, Greg, and thanks for the response.

I think a minor rephrasing of the requirement isn't enough, really.
As I understand it now, after other discussion, it's not that you need
agreement from the users, but that you should put a paragraph (or
maybe a separate section, to highlight the point) that says that this
is not intended for use on the open Internet nor on production
networks, and gives examples of what it *is* intended for... perhaps
test networks, production networks during advertised maintenance
windows, that sort of thing.  And then you don't need to say that the
network's users need to agree, but simply that they need to be aware
that performance testing will be happening during period X, and that
disruptions to normal network operation are possible.  You'd need to
come up with text that the working group agrees with, of course, but I
think that if you do it will address my concern as well as some of the
others that were raised.

Does that make sense?

Barry

On Tue, Sep 10, 2019 at 5:01 PM Greg Mirsky <[email-masked]> wrote:
>
> Hi Barry,
> thank you for your pointed question. Please find my explanation and the proposed updated below under the GIM>> tag.
>
> Regards,
> Greg
>
> On Wed, Sep 4, 2019 at 9:53 AM Barry Leiba via Datatracker <[email-masked]> wrote:
>>
> GIM>> Yes, looking at the bigger picture, at the Internet rather than only at the domain where the test will be performed makes such condition unattainable. Would s/network/network domain where the test is planned/  so that it reads as:
>
> ... MUST be agreed by all users on the network domain where the test is planned ...
>
> As for what the could be the question users will be asked, I think that it should verify whether the application that has the port number assigned is active as the same number will be used as the destination port number in the STAMP test.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 10 Sep 2019 17:34:37 -0700

Hi Barry,
thank you for the clarification. Yes, I agree that a new section can state
it more clearly and give sufficient examples, as you've suggested.
I'll work on it and will share when it is ready.

Regards,
Greg

On Tue, Sep 10, 2019 at 5:15 PM Barry Leiba <[email-masked]> wrote:

> >> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > GIM>> Yes, looking at the bigger picture, at the Internet rather than
> only at the domain where the test will be performed makes such condition
> > As for what the could be the question users will be asked, I think that
> it should verify whether the application that has the port number assigned
> is active as the same number will be used as the destination port number in
> the STAMP test.
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 Sep 2019 20:51:36 -0400

Thanks, Greg; I look forward to it.

b

On Tue, Sep 10, 2019 at 8:35 PM Greg Mirsky <[email-masked]> wrote:
>
> Hi Barry,
> thank you for the clarification. Yes, I agree that a new section can state it more clearly and give sufficient examples, as you've suggested.

---

From: Henrik Nydell <[email-masked]>
Date: Wed, 11 Sep 2019 10:42:23 +0200

The STAMP test (As for RFC5357 TWAMP and for example Cisco IP-SLA , Huawei
U.2520, Juniper RPM and other in-line test functions) is indeed intended to
be used on production networks to enable the operator to assess service
level agreements based on delay, jitter and loss. So the rephrasing needs
to be done keeping that in mind, and I see no implications on using it over
the Internet either. The agreement on UDP ports to use needs to be done
between the session-sender and the session-reflector only. Intermediate
nodes or other users of the network need not be aware of the STAMP test or
the ports it uses. It is in fact desirable that the STAMP packets are not
distinguishable from other traffic on the network, but are treated just
like any user traffic in the class of service they are transmitted.

Best
Henrik

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>
<https://www.facebook.com/accedian/>  <https://twitter.com/Accedian>
<https://www.linkedin.com/company/accedian-networks?originalSubdomain=ca>
<http://www.accedian.com>
*accedian.com <http://accedian.com>*

-- 

Avis de confidentialité

Les
 informations contenues dans le présent 
message et dans toute pièce qui 
lui est jointe sont confidentielles et 
peuvent être protégées par le 
secret professionnel. Ces informations sont 
à l’usage exclusif de son ou
 de ses destinataires. Si vous recevez ce 
message par erreur, veuillez 
s’il vous plait communiquer immédiatement 
avec l’expéditeur et en 
détruire tout exemplaire. De plus, il vous est 
strictement interdit de 
le divulguer, de le distribuer ou de le reproduire 
sans l’autorisation 
de l’expéditeur. Merci.

Confidentiality notice

This

 e-mail message and any attachment hereto contain confidential 
information 
which may be privileged and which is intended for the 
exclusive use of its 
addressee(s). If you receive this message in error,
 please inform sender 
immediately and destroy any copy thereof. 
Furthermore, any disclosure, 
distribution or copying of this message 
and/or any attachment hereto 
without the consent of the sender is 
strictly prohibited. Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 24 Sep 2019 10:19:04 -0700

Hi Barry,
thank you for your suggestions. Based on your comments, the authors decided
to add a new Operational Consideration section:
NEW TEXT:
5.  Operational Considerations

   STAMP is intended to be used on production networks to enable the
   operator to assess service level agreements based on packet delay,
   delay variation, and loss.  Using STAMP over the Internet, especially
   when STAMP test packets are transmitted with the destination UDP port
   number from the User Ports range, the possible impact of the STAMP
   test packets MUST be thoroughly analyzed.  The use of STAMP for each
   case MUST be agreed by users of nodes hosting the Session-Sender and
   Session-Reflector before starting the STAMP test session.

   Also, the use of the well-known port number as the destination UDP
   port number in STAMP test packets transmitted by a Session-Sender
   would not impede the ability to measure performance in an Equal Cost
   Multipath environment and analysis in Section 5.3 [RFC8545] fully
   applies to STAMP.

As the new section includes the discussion of using port numbers from the
User Ports range, the Security Considerations section has been updated to
avoid the duplication (please see the attached working version and the
diff).

Much appreciate your comments on the updated text.

Regards,
Greg

On Tue, Sep 10, 2019 at 5:51 PM Barry Leiba <[email-masked]> wrote:

> > thank you for the clarification. Yes, I agree that a new section can
> state it more clearly and give sufficient examples, as you've suggested.
> >> > thank you for your pointed question. Please find my explanation and
> the proposed updated below under the GIM>> tag.
> >> >
> >> > Regards,
> >> > Greg
> >> >
> >> > As for what the could be the question users will be asked, I think
> that it should verify whether the application that has the port number
> assigned is active as the same number will be used as the destination port
> number in the STAMP test.
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Sep 2019 13:29:33 -0400

Greg, this looks good, and many thanks for that!  Minor typo:

   Using STAMP over the Internet, especially
   when STAMP test packets are transmitted with the destination UDP port
   number from the User Ports range, the possible impact of the STAMP
   test packets MUST be thoroughly analyzed.

It should say "When using STAMP over the Internet..."

I'll clear the DISCUSS when this is posted as a draft revision.

Barry

On Tue, Sep 24, 2019 at 1:19 PM Greg Mirsky <[email-masked]> wrote:
>
> Hi Barry,
> thank you for your suggestions. Based on your comments, the authors decided to add a new Operational Consideration section:
> NEW TEXT:
> As the new section includes the discussion of using port numbers from the User Ports range, the Security Considerations section has been updated to avoid the duplication (please see the attached working version and the diff).
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 24 Sep 2019 13:29:30 -0700

Hi Barry,
great catch, thank you!
I've posted the new version
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-08>.

Kind regards,
Greg

On Tue, Sep 24, 2019 at 10:29 AM Barry Leiba <[email-masked]>
wrote:

> > thank you for your suggestions. Based on your comments, the authors
> decided to add a new Operational Consideration section:
> > NEW TEXT:
> > As the new section includes the discussion of using port numbers from
> the User Ports range, the Security Considerations section has been updated
> to avoid the duplication (please see the attached working version and the
> diff).
> >
> >> >> > thank you for your pointed question. Please find my explanation
> and the proposed updated below under the GIM>> tag.
> >> >> >
> >> >> > Regards,
> >> >> > Greg
> >> >> >
> >> >> > GIM>> Yes, looking at the bigger picture, at the Internet rather
> than only at the domain where the test will be performed makes such
> condition unattainable. Would s/network/network domain where the test is
> planned/  so that it reads as:
> >> >> >